分类 系统运维 下的文章

[TL;DR] 这是系列文章的第三篇,讲述了我的公司是如何将基础设施从PaaS移植到Docker上的。

  • 第一部分:谈论了我接触Docker之前的经历;
  • 第二部分:一步步搭建一个安全而又私有的registry。

在系列文章的最后一篇里,我们将用一个实例来学习如何自动化整个部署过程。

基本的Rails应用程序

现在让我们启动一个基本的Rails应用。为了更好的展示,我使用Ruby 2.2.0和Rails 4.1.1

在终端运行:

$ rvm use 2.2.0
$ rails new  && cd docker-test

创建一个基本的控制器:

$ rails g controller welcome index

……,然后编辑 routes.rb ,以便让该项目的根指向我们新创建的welcome#index方法:

root 'welcome#index'  

在终端运行 rails s ,然后打开浏览器,登录http://localhost:3000,你会进入到索引界面当中。我们不准备给应用加上多么神奇的东西,这只是一个基础的实例,当我们将要创建并部署容器的时候,用它来验证一切是否运行正常。

安装webserver

我们打算使用Unicorn当做我们的webserver。在Gemfile中添加 gem 'unicorn'gem 'foreman'然后将它bundle起来(运行 bundle install命令)。

启动Rails应用时,需要先配置好Unicorn,所以我们将一个unicorn.rb文件放在config目录下。这里有一个Unicorn配置文件的例子,你可以直接复制粘贴Gist的内容。

接下来,在项目的根目录下添加一个Procfile,以便可以使用foreman启动应用,内容为下:

web: bundle exec unicorn -p $PORT -c ./config/unicorn.rb  

现在运行foreman start命令启动应用,一切都将正常运行,并且你将能够在http://localhost:5000上看到一个正在运行的应用。

构建一个Docker镜像

现在我们构建一个镜像来运行我们的应用。在这个Rails项目的根目录下,创建一个名为Dockerfile的文件,然后粘贴进以下内容:

# 基于镜像 ruby 2.2.0
FROM ruby:2.2.0

# 安装所需的库和依赖
RUN apt-get update && apt-get install -qy nodejs postgresql-client sqlite3 --no-install-recommends && rm -rf /var/lib/apt/lists/*

# 设置 Rails 版本
ENV RAILS_VERSION 4.1.1

# 安装 Rails
RUN gem install rails --version "$RAILS_VERSION"

# 创建代码所运行的目录 
RUN mkdir -p /usr/src/app  
WORKDIR /usr/src/app

# 使 webserver 可以在容器外面访问
EXPOSE 3000

# 设置环境变量
ENV PORT=3000

# 启动 web 应用
CMD ["foreman","start"]

# 安装所需的 gems 
ADD Gemfile /usr/src/app/Gemfile  
ADD Gemfile.lock /usr/src/app/Gemfile.lock  
RUN bundle install --without development test

# 将 rails 项目(和 Dockerfile 同一个目录)添加到项目目录
ADD ./ /usr/src/app

# 运行 rake 任务
RUN RAILS_ENV=production rake db:create db:migrate  

使用上述Dockerfile,执行下列命令创建一个镜像(确保boot2docker已经启动并在运行当中):

$ docker build -t localhost:5000/your_username/docker-test .

然后,如果一切正常,长长的日志输出的最后一行应该类似于:

Successfully built 82e48769506c  
$ docker images
REPOSITORY                                       TAG                 IMAGE ID            CREATED              VIRTUAL SIZE  
localhost:5000/your_username/docker-test         latest              82e48769506c        About a minute ago   884.2 MB  

让我们运行一下容器试试!

$ docker run -d -p 3000:3000 --name docker-test localhost:5000/your_username/docker-test

通过你的boot2docker虚拟机的3000号端口(我的是http://192.168.59.103:3000),你可以观察你的Rails应用。(如果不清楚你的boot2docker虚拟地址,输入$ boot2docker ip命令查看。)

使用shell脚本进行自动化部署

前面的文章(指文章1和文章2)已经告诉了你如何将新创建的镜像推送到私有registry中,并将其部署在服务器上,所以我们跳过这一部分直接开始自动化进程。

我们将要定义3个shell脚本,然后最后使用rake将它们捆绑在一起。

清除

每当我们创建镜像的时候,

  • 停止并重启boot2docker;
  • 去除Docker孤儿镜像(那些没有标签,并且不再被容器所使用的镜像们)。

在你的工程根目录下的clean.sh文件中输入下列命令。

echo Restarting boot2docker...  
boot2docker down  
boot2docker up

echo Exporting Docker variables...  
sleep 1  
export DOCKER_HOST=tcp://192.168.59.103:2376  
export DOCKER_CERT_PATH=/Users/user/.boot2docker/certs/boot2docker-vm  
export DOCKER_TLS_VERIFY=1

sleep 1  
echo Removing orphaned images without tags...  
docker images | grep "<none>" | awk '{print $3}' | xargs docker rmi  

给脚本加上执行权限:

$ chmod +x clean.sh

构建

构建的过程基本上和之前我们所做的(docker build)内容相似。在工程的根目录下创建一个build.sh脚本,填写如下内容:

docker build -t localhost:5000/your_username/docker-test .  

记得给脚本执行权限。

部署

最后,创建一个deploy.sh脚本,在里面填进如下内容:

# 打开 boot2docker 到私有注册库的 SSH 连接
boot2docker ssh "ssh -o 'StrictHostKeyChecking no' -i /Users/username/.ssh/id_boot2docker -N -L 5000:localhost:5000 [email protected] &" &

# 在推送前先确认该 SSH 通道是开放的。
echo Waiting 5 seconds before pushing image.

echo 5...  
sleep 1  
echo 4...  
sleep 1  
echo 3...  
sleep 1  
echo 2...  
sleep 1  
echo 1...  
sleep 1

# Push image onto remote registry / repo
echo Starting push!  
docker push localhost:5000/username/docker-test  

如果你不理解这其中的含义,请先仔细阅读这部分第二部分

给脚本加上执行权限。

使用rake将以上所有绑定

现在的情况是,每次你想要部署你的应用时,你都需要单独运行这三个脚本。

  1. clean
  2. build
  3. deploy / push

这一点都不费工夫,可是事实上开发者比你想象的要懒得多!那么咱们就索性再懒一点!

我们最后再把工作好好整理一番,我们现在要将三个脚本通过rake捆绑在一起。

为了更简单一点,你可以在工程根目录下已经存在的Rakefile中添加几行代码,打开Rakefile文件,把下列内容粘贴进去。

namespace :docker do  
  desc "Remove docker container"
  task :clean do
    sh './clean.sh'
  end

  desc "Build Docker image"
  task :build => [:clean] do
    sh './build.sh'
  end

  desc "Deploy Docker image"
  task :deploy => [:build] do
    sh './deploy.sh'
  end
end  

即使你不清楚rake的语法(其实你真应该去了解一下,这玩意太酷了!),上面的内容也是很显然的吧。我们在一个命名空间(docker)里声明了三个任务。

三个任务是:

  • rake docker:clean
  • rake docker:build
  • rake docker:deploy

Deploy独立于build,build独立于clean。所以每次我们输入命令运行的时候。

$ rake docker:deploy

所有的脚本都会按照顺序执行。

测试

现在我们来看看是否一切正常,你只需要在app的代码里做一个小改动:

$ rake docker:deploy

接下来就是见证奇迹的时刻了。一旦镜像文件被上传(第一次可能花费较长的时间),你就可以ssh登录产品服务器,并且(通过SSH管道)把docker镜像拉取到服务器并运行了。多么简单!

也许你需要一段时间来习惯,但是一旦成功,它几乎与用Heroku部署一样简单。

备注:像往常一样,请让我了解到你的意见。我不敢保证这种方法是最好,最快,或者最安全的Docker开发的方法,但是这东西对我们确实奏效。


via: http://cocoahunter.com/2015/01/23/docker-3/

作者:Michelangelo Chasseur 译者:DongShuaike 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

今天,我们来学习一下在 CentOS 7.x 中如何用 nmcli(Network Manager Command Line Interface:网络管理命令行接口)进行网卡绑定。

网卡(接口)绑定是将多块 网卡 逻辑地连接到一起从而允许故障转移或者提高吞吐率的方法。提高服务器网络可用性的一个方式是使用多个网卡。Linux 绑定驱动程序提供了一种将多个网卡聚合到一个逻辑的绑定接口的方法。这是个新的实现绑定的方法,并不影响 linux 内核中旧绑定驱动。

网卡绑定为我们提供了两个主要的好处:

  1. 高带宽
  2. 冗余/弹性

现在让我们在 CentOS 7 上配置网卡绑定吧。我们需要决定选取哪些接口配置成一个组接口(Team interface)。

运行 ip link 命令查看系统中可用的接口。

 $ ip link

ip link

这里我们使用 eno16777736eno33554960 网卡在 “主动备份” 模式下创建一个组接口。(译者注:关于不同模式可以参考:多网卡的7种bond模式原理)

按照下面的语法,用 nmcli 命令为网络组接口创建一个连接。

# nmcli con add type team con-name CNAME ifname INAME [config JSON]

CNAME 指代连接的名称,INAME 是接口名称,JSON (JavaScript Object Notation) 指定所使用的处理器(runner)。JSON 语法格式如下:

'{"runner":{"name":"METHOD"}}' 

METHOD 是以下的其中一个:broadcast、activebackup、roundrobin、loadbalance 或者 lacp

1. 创建组接口

现在让我们来创建组接口。这是我们创建组接口所使用的命令。

 # nmcli con add type team con-name team0 ifname team0 config '{"runner":{"name":"activebackup"}}'

nmcli con create

运行 # nmcli con show 命令验证组接口配置。

# nmcli con show

显示组接口

2. 添加从设备

现在让我们添加从设备到主设备 team0。这是添加从设备的语法:

# nmcli con add type team-slave con-name CNAME ifname INAME master TEAM

在这里我们添加 eno16777736eno33554960 作为 team0 接口的从设备。

# nmcli con add type team-slave con-name team0-port1 ifname eno16777736 master team0

# nmcli con add type team-slave con-name team0-port2 ifname eno33554960 master team0

添加从设备到 team

再次用命令 #nmcli con show 验证连接配置。现在我们可以看到从设备配置信息。

#nmcli con show

显示从设备配置

3. 分配 IP 地址

上面的命令会在 /etc/sysconfig/network-scripts/ 目录下创建需要的配置文件。

现在让我们为 team0 接口分配一个 IP 地址并启用这个连接。这是进行 IP 分配的命令。

# nmcli con mod team0 ipv4.addresses "192.168.1.24/24 192.168.1.1"
# nmcli con mod team0 ipv4.method manual
# nmcli con up team0

分配 ip

4. 验证绑定

#ip add show team0 命令验证 IP 地址信息。

#ip add show team0

验证 ip 地址

现在用 teamdctl 命令检查 主动备份 配置功能。

# teamdctl team0 state

teamdctl 检查主动备份

现在让我们把激活的端口断开连接并再次检查状态来确认主动备份配置是否像希望的那样工作。

# nmcli dev dis eno33554960

断开激活端口连接

断开激活端口后再次用命令 #teamdctl team0 state 检查状态。

# teamdctl team0 state

teamdctl 检查断开激活端口连接

是的,它运行良好!!我们会使用下面的命令连接回到 team0 的断开的连接。

#nmcli dev con eno33554960

nmcli dev 连接断开的连接

我们还有一个 teamnl 命令可以显示 teamnl 命令的一些选项。

用下面的命令检查在 team0 运行的端口。

# teamnl team0 ports

teamnl 检查端口

显示 team0 当前活动的端口。

# teamnl team0 getoption activeport

显示 team0 活动端口

好了,我们已经成功地配置了网卡绑定 :-) ,如果有任何反馈,请告诉我们。


via: http://linoxide.com/linux-command/interface-nics-bonding-linux/

作者:Arun Pyasi 译者:ictlyh 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

[TL;DR] 这是系列的第二篇文章,这系列讲述了我的公司如何把基础服务从PaaS迁移到Docker上

  • 第一篇文章: 我谈到了接触Docker之前的经历;
  • 第三篇文章: 我展示如何使创建镜像的过程自动化以及如何用Docker部署一个Rails应用。

为什么需要搭建一个私有的registry呢?嗯,对于新手来说,Docker Hub(一个Docker公共仓库)只允许你拥有一个免费的私有版本库(repo)。其他的公司也开始提供类似服务,但是价格可不便宜。另外,如果你需要用Docker部署一个用于生产环境的应用,恐怕你不希望将这些镜像放在公开的Docker Hub上吧!

这篇文章提供了一个非常务实的方法来处理搭建私有Docker registry时出现的各种错综复杂的情况。我们将会使用一个运行于DigitalOcean(之后简称为DO)的非常小巧的512MB VPS 实例。并且我会假定你已经了解了Docker的基本概念,因为我必须集中精力在复杂的事情上!

本地搭建

首先你需要安装boot2docker以及docker CLI。如果你已经搭建好了基本的Docker环境,你可以直接跳过这一步。

从终端运行以下命令(我假设你使用OS X,使用 HomeBrew 来安装相关软件,你可以根据你的环境使用不同的包管理软件来安装):

brew install boot2docker docker  

如果一切顺利(想要了解搭建docker环境的完整指南,请参阅 http://boot2docker.io/) ,你现在就能够通过如下命令启动一个 Docker 运行于其中的虚拟机:

boot2docker up  

按照屏幕显示的说明,复制粘贴book2docker在终端输出的命令。如果你现在运行docker ps命令,终端将有以下显示。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES  

好了,Docker已经准备就绪,这就够了,我们回过头去搭建registry。

创建服务器

登录进你的DO账号,选择一个预安装了Docker的镜像文件,创建一个新的Drople。(本文写成时选择的是 Image > Applications > Docker 1.4.1 on 14.04)

你将会以邮件的方式收到一个根用户凭证。登录进去,然后运行docker ps命令来查看系统状态。

搭建AWS S3

我们现在将使用Amazo Simple Storage Service(S3)作为我们registry/repository的存储层。我们将需要创建一个桶(bucket)以及用户凭证(user credentials)来允许我们的docker容器访问它。

登录到我们的AWS账号(如果没有,就申请一个http://aws.amazon.com/),在控制台选择S3(Simpole Storage Service)。

点击 Create Bucket,为你的桶输入一个名字(把它记下来,我们一会需要用到它),然后点击Create

OK!我们已经搭建好存储部分了。

设置AWS访问凭证

我们现在将要创建一个新的用户。退回到AWS控制台然后选择IAM(Identity & Access Management)。

在dashboard的左边,点击Users。然后选择 Create New Users

如图所示:

输入一个用户名(例如 docker-registry)然后点击Create。写下(或者下载csv文件)你的Access Key以及Secret Access Key。回到你的用户列表然后选择你刚刚创建的用户。

在Permission section下面,点击Attach User Policy。之后在下一屏,选择Custom Policy。

custom policy的内容如下:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SomeStatement",
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::docker-registry-bucket-name/*",       
        "arn:aws:s3:::docker-registry-bucket-name"
      ]
    }
  ]
}

这个配置将允许用户(也就是regitstry)来对桶上的内容进行操作(读/写)(确保使用你之前创建AWS S3时使用的桶名)。总结一下:当你想把你的Docker镜像从你的本机推送到仓库中时,服务器就会将他们上传到S3。

安装registry

现在回过头来看我们的DO服务器,SSH登录其上。我们将要使用一个官方Docker registry镜像

输入如下命令,开启registry。

docker run \  
         -e SETTINGS_FLAVOR=s3 \
         -e AWS_BUCKET=bucket-name \
         -e STORAGE_PATH=/registry \
         -e AWS_KEY=your_aws_key \
         -e AWS_SECRET=your_aws_secret \
         -e SEARCH_BACKEND=sqlalchemy \
         -p 5000:5000 \
         --name registry \
         -d \
         registry

Docker将会从Docker Hub上拉取所需的文件系统分层(fs layers)并启动守护容器(daemonised container)。

测试registry

如果上述操作奏效,你可以通过ping命令,或者查找它的内容来测试registry(虽然这个时候容器还是空的)。

我们的registry非常基础,而且没有提供任何“验明正身”的方式。因为添加身份验证可不是一件轻松事(至少我认为没有一种部署方法是简单的,像是为了证明你努力过似的),我觉得“查询/拉取/推送”仓库内容的最简单方法就是通过SSH通道的未加密连接(通过HTTP)。

打开SSH通道的操作非常简单:

ssh -N -L 5000:localhost:5000 root@your_registry.com

这条命令建立了一条从registry服务器(前面执行docker run命令的时候我们见过它)的5000号端口到本机的5000号端口之间的 SSH 管道连接。

如果你现在用浏览器访问 http://localhost:5000/v1/_ping,将会看到下面这个非常简短的回复。

{}

这个意味着registry工作正常。你还可以通过登录 http://localhost:5000/v1/search 来查看registry内容,内容相似:

{
  "num_results": 2,
  "query": "",
  "results": [
    {
      "description": "",
      "name": "username/first-repo"
    },
    {
      "description": "",
      "name": "username/second-repo"
    }
  ]
}

创建一个镜像

我们现在创建一个非常简单的Docker镜像,来检验我们新弄好的registry。在我们的本机上,用如下内容创建一个Dockerfile(这里只有一点代码,在下一篇文章里我将会展示给你如何将一个Rails应用绑定进Docker容器中。):

#  ruby 2.2.0 的基础镜像
FROM ruby:2.2.0

MAINTAINER Michelangelo Chasseur <[email protected]>  

并创建它:

docker build -t localhost:5000/username/repo-name .  

localhost:5000这个部分非常重要:Docker镜像名的最前面一个部分将告知docker push命令我们将要把我们的镜像推送到哪里。在我们这个例子当中,因为我们要通过SSH管道连接远程的私有registry,localhost:5000精确地指向了我们的registry。

如果一切顺利,当命令执行完成返回后,你可以输入docker images命令来列出新近创建的镜像。执行它看看会出现什么现象?

推送到仓库

接下来是更好玩的部分。实现我所描述的东西着实花了我一点时间,所以如果你第一次读的话就耐心一点吧,跟着我一起操作。我知道接下来的东西会非常复杂(如果你不自动化这个过程就一定会这样),但是我保证到最后你一定都能明白。在下一篇文章里我将会使用到一大波shell脚本和Rake任务,通过它们实现自动化并且用简单的命令实现部署Rails应用。

你在终端上运行的docker命令实际上都是使用boot2docker虚拟机来运行容器及各种东西。所以当你执行像docker push some_repo这样的命令时,是boot2docker虚拟机在与registry交互,而不是我们自己的机器。

接下来是一个非常重要的点:为了将Docker镜像推送到远端的私有仓库,SSH管道需要在boot2docker虚拟机上配置好,而不是在你的本地机器上配置。

有许多种方法实现它。我给你展示最简短的一种(可能不是最容易理解的,但是能够帮助你实现自动化)

在这之前,我们需要对 SSH 做最后一点工作。

设置 SSH

让我们把boot2docker 的 SSH key添加到远端服务器的“已知主机”里面。我们可以使用ssh-copy-id工具完成,通过下面的命令就可以安装上它了:

brew install ssh-copy-id  

然后运行:

ssh-copy-id -i /Users/username/.ssh/id_boot2docker [email protected]  

用你ssh key的真实路径代替/Users/username/.ssh/id_boot2docker

这样做能够让我们免密码登录SSH。

现在我们来测试以下:

boot2docker ssh "ssh -o 'StrictHostKeyChecking no' -i /Users/michelangelo/.ssh/id_boot2docker -N -L 5000:localhost:5000 [email protected] &" &  

分开阐述:

  • boot2docker ssh允许你以参数的形式传递给boot2docker虚拟机一条执行的命令;
  • 最后面那个&表明这条命令将在后台执行;
  • ssh -o 'StrictHostKeyChecking no' -i /Users/michelangelo/.ssh/id_boot2docker -N -L 5000:localhost:5000 [email protected] &是boot2docker虚拟机实际运行的命令;

    • -o 'StrictHostKeyChecking no'——不提示安全问题;
    • -i /Users/michelangelo/.ssh/id_boot2docker指出虚拟机使用哪个SSH key来进行身份验证。(注意这里的key应该是你前面添加到远程仓库的那个)
    • 最后我们将打开一条端口5000映射到localhost:5000的SSH通道。

从其他服务器上拉取

你现在将可以通过下面的简单命令将你的镜像推送到远端仓库:

docker push localhost:5000/username/repo_name  

在下一篇文章中,我们将会了解到如何自动化处理这些事务,并且真正地容器化一个Rails应用。请继续收听!

如有错误,请不吝指出。祝你Docker之路顺利!


via: http://cocoahunter.com/2015/01/23/docker-2/

作者:Michelangelo Chasseur 译者:DongShuaike 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

本文向你介绍如何在 nginx 服务器上设置健壮的 SSL 安全机制。我们通过禁用 SSL 压缩来降低 CRIME 攻击威胁;禁用协议上存在安全缺陷的 SSLv3 及更低版本,并设置更健壮的 加密套件 cipher suite 来尽可能启用 前向安全性 Forward Secrecy ;此外,我们还启用了 HSTS 和 HPKP。这样我们就拥有了一个健壮而可经受考验的 SSL 配置,并可以在 Qually Labs 的 SSL 测试中得到 A 级评分。

如果不求甚解的话,可以从 https://cipherli.st 上找到 nginx 、Apache 和 Lighttpd 的安全设置,复制粘帖即可。

本教程在 Digital Ocean 的 VPS 上测试通过。如果你喜欢这篇教程,想要支持作者的站点的话,购买 Digital Ocean 的 VPS 时请使用如下链接:https://www.digitalocean.com/?refcode=7435ae6b8212

本教程可以通过发布于 2014/1/21 的 SSL 实验室测试的严格要求(我之前就通过了测试,如果你按照本文操作就可以得到一个 A+ 评分)。

你可以从下列链接中找到这方面的进一步内容:

我们需要编辑 nginx 的配置,在 Ubuntu/Debian 上是 /etc/nginx/sited-enabled/yoursite.com,在 RHEL/CentOS 上是 /etc/nginx/conf.d/nginx.conf

本文中,我们需要编辑443端口(SSL)的 server 配置中的部分。在文末你可以看到完整的配置例子。

在编辑之前切记备份一下配置文件!

野兽攻击(BEAST)和 RC4

简单的说, 野兽攻击 BEAST 就是通过篡改一个加密算法的 密码块链 CBC,cipher block chaining 的模式,从而可以对部分编码流量悄悄解码。更多信息参照上面的链接。

针对 野兽攻击 BEAST ,较新的浏览器已经启用了客户端缓解方案。推荐方案是禁用 TLS 1.0 的所有加密算法,仅允许 RC4 算法。然而,针对 RC4 算法的攻击也越来越多 ,很多已经从理论上逐步发展为实际可行的攻击方式。此外,有理由相信 NSA 已经实现了他们所谓的“大突破”——攻破 RC4 。

禁用 RC4 会有几个后果。其一,当用户使用老旧的浏览器时,比如 Windows XP 上的 IE 会用 3DES 来替代 RC4。3DES 要比 RC4 更安全,但是它的计算成本更高,你的服务器就需要为这些用户付出更多的处理成本。其二,RC4 算法能减轻 野兽攻击 BEAST 的危害,如果禁用 RC4 会导致 TLS 1.0 用户会换到更容易受攻击的 AES-CBC 算法上(通常服务器端的对 野兽攻击 BEAST 的“修复方法”是让 RC4 优先于其它算法)。我认为 RC4 的风险要高于 野兽攻击 BEAST 的风险。事实上,有了客户端缓解方案(Chrome 和 Firefox 提供了缓解方案), 野兽攻击 BEAST 就不是什么大问题了。而 RC4 的风险却在增长:随着时间推移,对加密算法的破解会越来越多。

怪物攻击(FREAK)

怪物攻击 FREAK 是一种中间人攻击,它是由来自 INRIA、微软研究院和 IMDEA 的密码学家们所发现的。 怪物攻击 FREAK 的缩写来自“ RSA 出口密钥因子分解 Factoring RSA-EXPORT Keys

这个漏洞可上溯到上世纪九十年代,当时美国政府禁止出口加密软件,除非其使用编码密钥长度不超过512位的出口加密套件。

这造成了一些现在的 TLS 客户端存在一个缺陷,这些客户端包括: 苹果的 SecureTransport 、OpenSSL。这个缺陷会导致它们会接受出口降级 RSA 密钥,即便客户端并没有要求使用出口降级 RSA 密钥。这个缺陷带来的影响很讨厌:在客户端存在缺陷,且服务器支持出口降级 RSA 密钥时,会发生中间人攻击,从而导致连接的强度降低。

攻击分为两个组成部分:首先是服务器必须接受“ 出口降级 RSA 密钥 export grade RSA ”。

中间人攻击可以按如下流程:

  • 在客户端的 Hello 消息中,要求标准的 RSA 加密套件。
  • 中间人攻击者修改该消息为 ‘输出级 RSA 密钥’ export RSA
  • 服务器回应一个512位的输出级 RSA 密钥,并以其长期密钥签名。
  • 由于 OpenSSL/SecureTransport 的缺陷,客户端会接受这个弱密钥。
  • 攻击者根据 RSA 模数分解因子来恢复相应的 RSA 解密密钥。
  • 当客户端编码 ‘预主密码’ pre-master secret 给服务器时,攻击者现在就可以解码它并恢复 TLS 的 ‘主密码’ master secret
  • 从这里开始,攻击者就能看到了传输的明文并注入任何东西了。

本文所提供的加密套件不启用输出降级加密,请确认你的 OpenSSL 是最新的,也强烈建议你将客户端也升级到新的版本。

心血漏洞(Heartbleed)

心血漏洞 Heartbleed 是一个于2014年4月公布的 OpenSSL 加密库的漏洞,它是一个被广泛使用的传输层安全(TLS)协议的实现。无论是服务器端还是客户端在 TLS 中使用了有缺陷的 OpenSSL,都可以被利用该缺陷。由于它是因 DTLS 心跳扩展(RFC 6520)中的输入验证不正确(缺少了边界检查)而导致的,所以该漏洞根据“心跳”而命名。这个漏洞是一种缓存区超读漏洞,它可以读取到本不应该读取的数据。

哪个版本的 OpenSSL 受到 心血漏洞 Heartbleed 的影响?

各版本情况如下:

  • OpenSSL 1.0.1 直到 1.0.1f (包括)存在该缺陷
  • OpenSSL 1.0.1g 没有该缺陷
  • OpenSSL 1.0.0 分支没有该缺陷
  • OpenSSL 0.9.8 分支没有该缺陷

这个缺陷是2011年12月引入到 OpenSSL 中的,并随着 2012年3月14日 OpenSSL 发布的 1.0.1 而泛滥。2014年4月7日发布的 OpenSSL 1.0.1g 修复了该漏洞。

升级你的 OpenSSL 就可以避免该缺陷。

SSL 压缩(罪恶攻击 CRIME)

罪恶攻击 CRIME 使用 SSL 压缩来完成它的魔法,SSL 压缩在下述版本是默认关闭的: nginx 1.1.6及更高/1.0.9及更高(如果使用了 OpenSSL 1.0.0及更高), nginx 1.3.2及更高/1.2.2及更高(如果使用较旧版本的 OpenSSL)。

如果你使用一个早期版本的 nginx 或 OpenSSL,而且你的发行版没有向后移植该选项,那么你需要重新编译没有一个 ZLIB 支持的 OpenSSL。这会禁止 OpenSSL 使用 DEFLATE 压缩方式。如果你禁用了这个,你仍然可以使用常规的 HTML DEFLATE 压缩。

SSLv2 和 SSLv3

SSLv2 是不安全的,所以我们需要禁用它。我们也禁用 SSLv3,因为 TLS 1.0 在遭受到降级攻击时,会允许攻击者强制连接使用 SSLv3,从而禁用了 前向安全性 forward secrecy

如下编辑配置文件:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

卷毛狗攻击(POODLE)和 TLS-FALLBACK-SCSV

SSLv3 会受到卷毛狗漏洞(POODLE)的攻击。这是禁用 SSLv3 的主要原因之一。

Google 提出了一个名为 TLS\_FALLBACK\_SCSV 的SSL/TLS 扩展,它用于防止强制 SSL 降级。如果你升级 到下述的 OpenSSL 版本会自动启用它。

  • OpenSSL 1.0.1 带有 TLS\_FALLBACK\_SCSV 1.0.1j 及更高。
  • OpenSSL 1.0.0 带有 TLS\_FALLBACK\_SCSV 1.0.0o 及更高。
  • OpenSSL 0.9.8 带有 TLS\_FALLBACK\_SCSV 0.9.8zc 及更高。

更多信息请参照 NGINX 文档

加密套件(cipher suite)

前向安全性 Forward Secrecy 用于在长期密钥被破解时确保会话密钥的完整性。 完备的前向安全性 PFS,Perfect Forward Secrecy 是指强制在每个/每次会话中推导新的密钥。

这就是说,泄露的私钥并不能用来解密(之前)记录下来的 SSL 通讯。

提供 完备的前向安全性 PFS,Perfect Forward Secrecy 功能的是那些使用了一种 Diffie-Hellman 密钥交换的短暂形式的加密套件。它们的缺点是系统开销较大,不过可以使用椭圆曲线的变体来改进。

以下两个加密套件是我推荐的,之后Mozilla 基金会也推荐了。

推荐的加密套件:

ssl_ciphers 'AES128+EECDH:AES128+EDH';

向后兼容的推荐的加密套件(IE6/WinXP):

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

如果你的 OpenSSL 版本比较旧,不可用的加密算法会自动丢弃。应该一直使用上述的完整套件,让 OpenSSL 选择一个它所支持的。

加密套件的顺序是非常重要的,因为其决定了优先选择哪个算法。上述优先推荐的算法中提供了PFS(完备的前向安全性)。

较旧版本的 OpenSSL 也许不能支持这个算法的完整列表,AES-GCM 和一些 ECDHE 算法是相当新的,在 Ubuntu 和 RHEL 中所带的绝大多数 OpenSSL 版本中不支持。

优先顺序的逻辑

  • ECDHE+AESGCM 加密是首选的。它们是 TLS 1.2 加密算法,现在还没有广泛支持。当前还没有对它们的已知攻击。
  • PFS 加密套件好一些,首选 ECDHE,然后是 DHE。
  • AES 128 要好于 AES 256。有一个关于 AES256 带来的安全提升程度是否值回成本的讨论,结果是显而易见的。目前,AES128 要更值一些,因为它提供了不错的安全水准,确实很快,而且看起来对时序攻击更有抵抗力。
  • 在向后兼容的加密套件里面,AES 要优于 3DES。在 TLS 1.1及其以上,减轻了针对 AES 的 野兽攻击 BEAST 的威胁,而在 TLS 1.0上则难以实现该攻击。在非向后兼容的加密套件里面,不支持 3DES。
  • RC4 整个不支持了。3DES 用于向后兼容。参看 #RC4\_weaknesses 中的讨论。

强制丢弃的算法

  • aNULL 包含了非验证的 Diffie-Hellman 密钥交换,这会受到 中间人 MITM 攻击
  • eNULL 包含了无加密的算法(明文)
  • EXPORT 是老旧的弱加密算法,是被美国法律标示为可出口的
  • RC4 包含的加密算法使用了已弃用的 ARCFOUR 算法
  • DES 包含的加密算法使用了弃用的数据加密标准(DES)
  • SSLv2 包含了定义在旧版本 SSL 标准中的所有算法,现已弃用
  • MD5 包含了使用已弃用的 MD5 作为哈希算法的所有算法

更多设置

确保你也添加了如下行:

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

在一个 SSLv3 或 TLSv1 握手过程中选择一个加密算法时,一般使用客户端的首选算法。如果设置了上述配置,则会替代地使用服务器端的首选算法。

前向安全性和 Diffie Hellman Ephemeral (DHE)参数

前向安全性 Forward Secrecy 的概念很简单:客户端和服务器协商一个永不重用的密钥,并在会话结束时销毁它。服务器上的 RSA 私钥用于客户端和服务器之间的 Diffie-Hellman 密钥交换签名。从 Diffie-Hellman 握手中获取的预主密钥会用于之后的编码。因为预主密钥是特定于客户端和服务器之间建立的某个连接,并且只用在一个限定的时间内,所以称作 短暂模式 Ephemeral

使用了前向安全性,如果一个攻击者取得了一个服务器的私钥,他是不能解码之前的通讯信息的。这个私钥仅用于 Diffie Hellman 握手签名,并不会泄露预主密钥。Diffie Hellman 算法会确保预主密钥绝不会离开客户端和服务器,而且不能被中间人攻击所拦截。

所有版本的 nginx(如1.4.4)都依赖于 OpenSSL 给 Diffie-Hellman (DH)的输入参数。不幸的是,这意味着 Diffie-Hellman Ephemeral(DHE)将使用 OpenSSL 的默认设置,包括一个用于密钥交换的1024位密钥。因为我们正在使用2048位证书,DHE 客户端就会使用一个要比非 DHE 客户端更弱的密钥交换。

我们需要生成一个更强壮的 DHE 参数:

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

然后告诉 nginx 将其用作 DHE 密钥交换:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

OCSP 装订(Stapling)

当连接到一个服务器时,客户端应该使用 证书吊销列表 CRL,Certificate Revocation List 在线证书状态协议 OCSP,Online Certificate Status Protocol 记录来校验服务器证书的有效性。CRL 的问题是它已经增长的太大了,永远也下载不完了。

OCSP 更轻量级一些,因为我们每次只请求一条记录。但是副作用是当连接到一个服务器时必须对第三方 OCSP 响应器发起 OCSP 请求,这就增加了延迟和带来了潜在隐患。事实上,CA 所运营的 OCSP 响应器非常不可靠,浏览器如果不能及时收到答复,就会静默失败。攻击者通过 DoS 攻击一个 OCSP 响应器可以禁用其校验功能,这样就降低了安全性。

解决方法是允许服务器在 TLS 握手中发送缓存的 OCSP 记录,以绕开 OCSP 响应器。这个机制节省了客户端和 OCSP 响应器之间的通讯,称作 OCSP 装订。

客户端会在它的 CLIENT HELLO 中告知其支持 status\_request TLS 扩展,服务器仅在客户端请求它的时候才发送缓存的 OCSP 响应。

大多数服务器最多会缓存 OCSP 响应48小时。服务器会按照常规的间隔连接到 CA 的 OCSP 响应器来获取刷新的 OCSP 记录。OCSP 响应器的位置可以从签名的证书中的 授权信息访问 Authority Information Access 字段中获得。

HTTP 严格传输安全(HSTS)

如有可能,你应该启用 HTTP 严格传输安全(HSTS),它会引导浏览器和你的站点之间的通讯仅通过 HTTPS。

HTTP 公钥固定扩展(HPKP)

你也应该启用 HTTP 公钥固定扩展(HPKP)

公钥固定的意思是一个证书链必须包括一个白名单中的公钥。它确保仅有白名单中的 CA 才能够为某个域名签署证书,而不是你的浏览器中存储的任何 CA。

我已经写了一篇关于 HPKP 的背景理论及在 Apache、Lighttpd 和 NGINX 中配置例子的文章

配置范例

server {

  listen [::]:443 default_server;

  ssl on;
  ssl_certificate_key /etc/ssl/cert/raymii_org.pem;
  ssl_certificate /etc/ssl/cert/ca-bundle.pem;

  ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_session_cache shared:SSL:10m;

  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  add_header Strict-Transport-Security max-age=63072000;
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;

  root /var/www/;
  index index.html index.htm;
  server_name raymii.org;

}

结尾

如果你使用了上述配置,你需要重启 nginx:

# 首先检查配置文件是否正确
/etc/init.d/nginx configtest
# 然后重启
/etc/init.d/nginx restart

现在使用 SSL Labs 测试来看看你是否能得到一个漂亮的“A”。当然了,你也得到了一个安全的、强壮的、经得起考验的 SSL 配置!


via: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

作者:Remy van Elst 译者:wxy 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

30. 用密码保护 GRUB

用密码保护你的 boot 引导程序这样你就可以在启动时获得额外的安全保障。同时你也可以在实物层面获得保护。通过在引导时给 GRUB 加锁防止任何无授权访问来保护你的服务器。

首先备份两个文件,这样如果有任何错误出现,你可以有回滚的选择。备份 ‘/etc/grub2/grub.cfg’ 为 ‘/etc/grub2/grub.cfg.old’。

# cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.old

同样,备份 ‘/etc/grub.d/10\_linux’ 为 ‘/etc/grub.d/10\_linux.old’。

# cp /etc/grub.d/10_linux /etc/grub.d/10_linux.old

打开文件 ‘/etc/grub.d/10\_linux’ 并在文件末尾添加下列行。

cat <<EOF
set superusers="tecmint"
Password tecmint avi@123
EOF

密码保护 Grub

密码保护 Grub

注意在上面的文件中,用你自己的用户名和密码代替 “tecmint” 和 “avi@123”。

现在通过运行下面的命令生成新的 grub.cfg 文件。

# grub2-mkconfig --output=/boot/grub2/grub.cfg

生成 Grub 文件

生成 Grub 文件

创建 grub.cfg 文件之后,重启机器并敲击 ‘e’ 进入编辑。你会发现它会要求你输入 “有效验证” 来编辑 boot 菜单。

有密码保护的 Boot 菜单

有密码保护的 Boot 菜单

输入登录验证之后,你就可以编辑 grub boot 菜单。

Grub 菜单文件

Grub 菜单文件

你也可以用加密的密码代替上一步的明文密码。首先按照下面推荐的生成加密密码。

# grub2-mkpasswd-pbkdf2

[两次输入密码]

生成加密的 Grub 密码

生成加密的 Grub 密码

打开 ‘/etc/grub.d/10\_linux’ 文件并在文件末尾添加下列行。

cat <<EOF
set superusers=”tecmint”
Password_pbkdf2 tecmint
grub.pbkdf2.sha512...你的加密密码...
EOF

加密 Grub 密码

加密 Grub 密码

用你系统上生成的密码代替原来的密码,别忘了交叉检查密码。

同样注意在这种情况下你也需要像上面那样生成 grub.cfg。重启并敲击 ‘e’ 进入编辑,会提示你输入用户名和密码。

我们已经介绍了大部分工业标准发行版 RHEL 7 和 CentOS 7 安装后必要的操作。如果你发现我们缺少了一些点或者你有新的东西可以扩充这篇文章,你可以和我们一起分享,我们会通过扩充在这篇文章中包括你的分享。


via: http://www.tecmint.com/things-to-do-after-minimal-rhel-centos-7-installation/6/

作者:vishek Kumar 译者:ictlyh 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

25. 安装 Linux Malware Detect (LMD)

Linux Malware Detect (LMD) 是 GNU GPLv2 协议下发布的开源 Linux 恶意程序扫描器,它是特别为面临威胁的主机环境所设计的。LMD 完整的安装、配置以及使用方法可以查看:

26. 用 Speedtest-cli 测试服务器带宽

speedtest-cli 是用 python 写的用于测试网络下载和上传带宽的工具。关于 speedtest-cli 工具的完整安装和使用请阅读我们的文章用命令行查看 Linux 服务器带宽

27. 配置 Cron 任务

这是最广泛使用的软件工具之一。它是一个任务调度器,比如,现在安排一个以后可以自动运行的作业。它用于未处理记录的日志和维护,以及其它日常工作,比如常规备份。所有的调度都写在文件 /etc/crontab 中。

crontab 文件包含下面的 6 个域:

    分          时                日期                      月份                  星期                  命令
(0-59)           (0-23)       (1-31)                (1/jan-12/dec)       (0-6/sun-sat)          Command/script

Crontab 域

Crontab 域

要在每天 04:30 运行一个 cron 任务(比如运行 /home/$USER/script.sh)。

分             时         日期              月份      星期                  命令
30              4             *              *       *            speedtest-cli

就把下面的条目增加到 crontab 文件 ‘/etc/crontab/’。

30  4  *  *  *  /home/$user/script.sh

把上面一行增加到 crontab 之后,它会在每天的 04:30 am 自动运行,输出取决于脚本文件的内容。另外脚本也可以用命令代替。关于更多 cron 任务的例子,可以阅读Linux 上的 11 个 Cron 任务例子

28. 安装 Owncloud

Owncloud 是一个基于 HTTP 的数据同步、文件共享和远程文件存储应用。更多关于安装 owncloud 的内容,你可以阅读这篇文章:在 Linux 上创建个人/私有云存储

29. 启用 Virtualbox 虚拟化

虚拟化是创建虚拟操作系统、硬件和网络的过程,是当今最热门的技术之一。我们会详细地讨论如何安装和配置虚拟化。

我们的最小化 CentOS 服务器是一个无用户界面服务器(LCTT 译注:无用户界面[headless]服务器指没有监视器和鼠标键盘等外设的服务器)。我们通过安装下面的软件包,让它可以托管虚拟机,虚拟机可通过 HTTP 访问。

# yum groupinstall 'Development Tools' SDL kernel-devel kernel-headers dkms

安装开发工具

安装开发工具

更改工作目录到 ‘/etc/yum.repos.d/’ 并下载 VirtualBox 库。

# wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc

安装刚下载的密钥。

# rpm --import oracle_vbox.asc

升级并安装 VirtualBox。

# yum update && yum install virtualbox-4.3

下一步,下载和安装 VirtualBox 扩展包。

# wget http://download.virtualbox.org/virtualbox/4.3.12/Oracle_VM_VirtualBox_Extension_Pack-4.3.12-93733.vbox-extpack
# VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.3.12-93733.vbox-extpack

安装 VirtualBox 扩展包

安装 VirtualBox 扩展包

正在安装 VirtualBox 扩展包

正在安装 VirtualBox 扩展包

添加用户 ‘vbox’ 用于管理 VirtualBox 并把它添加到组 vboxusers 中。

# adduser vbox
# passwd vobx
# usermod -G vboxusers vbox

安装 HTTPD 服务器。

# yum install httpd

安装 PHP (支持 soap 扩展)。

# yum install php php-devel php-common php-soap php-gd

下载 phpVirtualBox(一个 PHP 写的开源的 VirtualBox 用户界面)。

# wget http://sourceforge.net/projects/phpvirtualbox/files/phpvirtualbox-4.3-1.zip

解压 zip 文件并把解压后的文件夹复制到 HTTP 工作目录。

# unzip phpvirtualbox-4.*.zip
# cp phpvirtualbox-4.3-1 -R /var/www/html

下一步,重命名文件 /var/www/html/phpvirtualbox/config.php-example 为 var/www/html/phpvirtualbox/config.php。

# mv config.php.example config.php

打开配置文件并添加我们上一步创建的 ‘username ’ 和 ‘password’。

# vi config.php

最后,重启 VirtualBox 和 HTTP 服务器。

# service vbox-service restart
# service httpd restart

转发端口并从一个有用户界面的服务器上访问它。

http://192.168.0.15/phpvirtualbox-4.3-1/

登录 PHP Virtualbox

登录 PHP Virtualbox

PHP Virtualbox 面板

PHP Virtualbox 面板


via: http://www.tecmint.com/things-to-do-after-minimal-rhel-centos-7-installation/5/

作者:Avishek Kumar 译者:ictlyh 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出