openssl升级版本，防止 Heartbleed 漏洞

接自：

昨天晚上看rss订阅，貌似openssl又爆漏洞了，而且还很大的。作为一个伪技术宅，我就还是升级下，装逼下，以此表明我还是关注互联网的。openssl升级版本，防止 Heartbleed 漏洞

贴下知乎的回答：

另外有一个测试网站是否受到影响的服务： （现在长期503）

根 据页面上的介绍，这个 OpenSSL 的实现漏洞可以在握手阶段获取到主机上的敏感内存数据，甚至包括 SSL 证书私钥！漏洞2012年出现，昨天（2014年4月7日）才刚刚被修复。想问一下知乎上的信息安全专业人士们，这个漏洞的可利用性和影响范围究竟有多 大？如果是，那么这个曾今的 0day 是否被广泛利用？

很严重的漏洞，涉及开启了Heartbeat扩展的OpenSSL版本1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

刚才在我们的服务器（Gentoo）上看了一下，用的正是1.0.1c的受威胁版本，不过我们并没有开启Heartbeat，所以并不会受到实际威胁，但还是打上了补丁，以备不时之需。

如果你只是想检测一下你的服务器受不受威胁，现在有一款现成的工具可以用

也可以直接使用下面的OpenSSL命令来判断：

/usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'

1	/usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'

这个命令只告诉你是否有启用Heartbeat，但并不能说明是否受到威胁，还需要结合OpenSSL的版本进行判断。

Hacker News上面有人给出了这段脚本，能检测Alexa Top Million网站开启Heartbeat的服务器：

INPUT=websites.csv OLDIFS=$IFS IFS=, [ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; } while read rank website do echo "checking $website for heartbeat..." echo -e "quit\n" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' done < $INPUT IFS=$OLDIFS

1 2 3 4 5 6 7 8 9 10

INPUT=websites.csv   OLDIFS=$IFS   IFS=,   [ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; }   while read rank website   do     echo "checking $website for heartbeat..."     echo -e "quit\n" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'   done < $INPUT   IFS=$OLDIFS

跑了一小会儿，但好像并没发现什么有价值的信息。其实Heartbeat作为CRM在OpenSSL中用到的机会本就不多，再加上大网站的反应都很迅速，不容易出现大的纰漏。至于0Day发布之前有没有被人利用旧不得而知了。

现在各大发行版都已经打上补丁，请各位尽快更新。

当然，还可以参考《》

我是用的Centos ，目前官方说受威胁的版本是1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1 。在OpenSSL 1.0.1g版本中“ Heartbleed”漏洞被修复。所有centos6.5的系统运行OpenSSL 1.0.1e (openssl-1.0.1e-16.el6_5.4) 都会受到威胁，貌似只有6.5的会受到威胁。

先查看你的openssl版本,命令如下：

#openssl    version

或者

#openssl version  -a    //加 -a参数会显示更详细

又或

#yum info openssl     //redhat系列的可以用

ubuntu 和debian 可以用下面的命令：

#dpkg-query -l 'openssl'

好吧，哥用的就是OpenSSL 1.0.1f ，受威胁的版本。呵呵，真坑。不过没开启  Heartbleed ，又没设置https访问，没影响，不过还是升级下。

输入升级openssl版本的命令：

#yum clean all && yum update "openssl*"       //redhat系列可用这个

ubuntu和debian可以使用下面的命令：

#apt-get update
#apt-get upgrade

OpenSuSE使用下面的命令：

#zypper update

确保你安装的是openssl-1.0.1e-16.el6_5.7版本  或者更新的版本。yum源中没有这个包的话，只能自己去下载rpm包安装了。我估计是肯定有的。

为毛安装openssl-1.0.1e-16.el6_5.7 版本呢？因为这个版本已经修复了，见 。还有个原因是我的yum源里没openssl-1.0.1g版本。

然后再执行以下命令，检查还有哪些进程仍然在使用被删掉的旧版本openssl库 ：

#lsof   -n | grep ssl | grep DEL

没有就是正常了。有的话，那你就必须重新每个使用旧版本openssl库的进程了。所以，我懒得一个个重启了，又是小博客，直接重启服务器了。

如果可能的话，建议重新生成ssl 私钥，改密码之类的。

注意：还可以用下面这条命令检查你安装的这个版本的openssl时候打好了补丁，因为每次修复漏洞，打补丁后，软件包本身都会在日志(change-log)里记录这些信息。命令如下：

# rpm -q --changelog openssl-1.0.1e | grep -B 1 CVE-2014-0160    // CVE-2014-0160是这个漏洞的代码，可以去openssl的官网查的

显示：

* Mon Apr 07 2014 Tom谩拧 Mr谩z 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

说明这个版本已经修复了这个漏洞。

##########################################################################

2014. 4.9更新         直接源码安装openssl1.0.1g版本。

先下载openssl 1.0.1g版本，命令如下：

#wget  -c   

再下载这个版本的md5校验包：

#wget -c  .md5

然后校验下的openssl包是否被恶意修改过：

#md5sum openssl-1.0.1g.tar.gz | awk '{print $1;}' | cmp - openssl-1.0.1g.tar.gz.md5

如果校验没问题，再接着解压包，命令：

#tar   -zvxf      openssl-1.0.1g.tar.gz    //解压openssl-1.0.1g.tar.gz

进入这个解压缩的目录：

#cd   openssl-1.0.1g

输入下面的命令进行编译，安装，我直接设置了一些重要的参数，因为其他的参数对于我来说就根本没用。如果需要参数，自己添加就是。输入：

#./config shared zlib  && make && make install

或者你什么参数都不加，完全用默认的：

#./config  && make && make install

话大概五六分中编译安装完。没出问题的话，继续输入下面的命令，手动软链新的openssl二进制文件：

ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl
ln -s /usr/local/ssl/include/openssl /usr/include/openssl

配置库文件搜索路径：

#echo  "/usr/local/ssl/lib"  >>  /etc/ld.so.conf

#ldconfig -v

最后重启下服务器(重启进程麻烦的)，输入：

#reboot

重启后，输入下面的命令检测下openssl 的版本：

#openssl   version

显示：

OpenSSL 1.0.1g 7 Apr 2014

——————————————————————————————————————————————————————

还有php编译时，是否制定了openssl目录。我们直接查看php探针，就是 保存到a.php，然后放到你网站的根目录。在打开这个a.php文件。看显示openssl 那几栏，如下：

openssl

OpenSSL support	enabled
OpenSSL Library Version	OpenSSL 1.0.1g 7 Apr 2014
OpenSSL Header Version	OpenSSL 1.0.1g 7 Apr 2014

如果不是1.0.1g版本，那就重新编译下php。指定openssl的目录。

可以使用下面的命令，查看php版本和编译参数：

#php   -v     #查看php版本

# /usr/local/php/bin/php -i | grep configure   #查看php编译所用的参数

用这个命令显示的编译结果都有单引号包住了，要删掉。同时将其中的--with-openssl  改为：

--with-openssl=/usr/local/ssl/

然后重新编译即可，只是编译参数变了，但不改变php的版本。

因为我用的军哥lnmp，懒得自己去下载了。直接用他的php升级脚本upgrade_php.sh  来重新编译安装php。但是这个升级脚本不准升级到同版本。使用的时候会显示：

#echo "Error: The upgrade PHP Version is the same as the old Version!!"

只要将

if [ "$php_version" == "$old_php_version" ]; then
echo "Error: The upgrade PHP Version is the same as the old Version!!"
exit 1
fi
cho "=================================================="
echo "You want to upgrade php version to $php_version"
echo "=================================================="

这几行用#注释掉就可以了。然后进入lnmp加压的目录，执行：

#sh   upgrade_php.sh

选择你要的php版本，就可以升级了。

——————————————————————————————————————————-————————

还有就是nginx的，如果你的nginx使用的是静态的openssl库，那就也要重新编译安装nginx。参见参考文章：

1. 概述
    当前爆出了Openssl漏洞，会泄露隐私信息，涉及的机器较多，环境迥异，导致修复方案都有所不同。不少服务器使用的Nginx，是静态编译 opensssl，直接将openssl编译到nginx里面去了，这就意味着，单纯升级openssl是没有任何效果，Nginx不会加载外部的 openssl动态链接库的，必须将nginx重新编译才可以根治。

2. 识别Nginx是否是静态编译的

  以下三种方法都可以确认Nginx是否静态编译Openssl。

   2.1 查看Nginx编译参数

       输入以下指令，查看Nginx的编译参数:
# ./sbin/nginx -V
如果编译参数中含有--with-openssl=...，则表明Nginx是静态编译Openssl，如下所示：

nginx version: nginx/1.4.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/opt/app/nginx --with-http_ssl_module --with-openssl=/opt/app/openssl-1.0.1e --add-module=/opt/app/ngx_cache_purge-2.1

2.2 查看Nginx的依赖库

      为进一步确认，可以查看一下程序的依赖库，输入以下指令： 

# ldd `which nginx` | grep ssl
显示
libssl.so.10 => /usr/lib/libssl.so.10 (0xb76c6000)

注意：如果输出中不包含libssl.so的文件()，就说明是静态编译的Openssl的

再输入命令以确定openssl以确定库所属的openssl版本，但是不会太详细，比如本应该是1.0.1e.5.7，但是却只输出1.0.1e：

# strings  /usr/lib/libssl.so.10 | grep "^OpenSSL "
OpenSSL 1.0.1e-fips 11 Feb 2013

2.3 查看Nginx打开的文件

      也可以通过查看Nginx打开的文件来查看是否静态编译，输入以下指令：

# ps aux | grep nginx
# lsof -p 111111<这里换成Nginx的进程PID>  | grep ssl

如果没有打开Openssl的库文件，就说明是静态编译Openssl的，如下图所：

3. 重新编译Nginx

在互联网公司里，很少有统一的Nginx版本，都是各部门根据自己的业务需求选择相应的插件，然后自己编译的，所以在编译的时候一定要注意插件这块，不 要忘记编译某些插件，尽量保持Nginx特性不变，下面的方法可以给大家参考一下，但是一定要经过测试才可以上线啊。

至于nginx编译，我这里就省略了。可继续参考《重新编译Nginx指导手册【修复静态编译Openssl的Nginx漏洞 】[Openssl Heartbleed] 》，或者参考上面的php升级的方法重新编译nginx。

还有Open\v\p\n之类的，可能也需要重装下

建议升级后，再次进行heartbleed测试，测试网站自己百度下，360也有，git也上有工具。