云服务器安全漏洞修复方法?

说起云服务器的安全漏洞，我到现在都记得第一次被入侵的场景。那是一个周末的早晨，我习惯性地登录服务器查看监控，发现系统的登录日志里多了一条陌生的IP记录，时间是凌晨三点多。当时脑子嗡的一下，那种感觉怎么说呢，就像是你出门后发现忘了锁门，回来一看家里确实进人了。后来查了一圈，发现是Redis的一个漏洞被人利用了，黑客拿到了服务器的权限，还植入了一个挖矿程序。CPU跑得比飞机引擎还热，业务自然也就崩了。

那次之后我花了很长时间学习安全漏洞的修复方法。今天就把这些经验好好梳理一下，希望对正在运维云服务器的朋友有所帮助。这不是什么高深的理论，都是真金白银换来的教训。

先说一个最基本的认知。云服务器上的安全漏洞，大概可以分为这么几类。操作系统层面的漏洞，比如内核或者系统组件的问题。应用软件的漏洞，像Nginx、MySQL、Redis这些常见服务都可能出问题。配置不当引入的漏洞，这个说实话比代码漏洞还常见，因为配置稍微写错一个地方，就等于把门打开了。还有一类是弱密码和权限失控，别看这个听起来简单，实际上翻车的人最多。

先讲一个操作系统的典型案例。前些年有一个叫Dirty Pipe的内核漏洞曝光的时候，我们公司有好几台服务器都中招了。这个漏洞可以让普通用户往只读文件里写数据，什么意思呢，就是你一个没有管理员权限的普通账号，居然可以修改系统的关键文件，获取管理员权限。当时这个漏洞的利用代码很快就传开了，攻击者遍地都是。

修复这种漏洞的方法其实说起来不复杂，就是把内核升级到打了补丁的版本。但实际操作起来有几个要注意的地方。云服务器的内核跟传统物理机不太一样，很多云服务商用的是定制版的内核，不能直接拿上游的通用内核去升级，否则可能导致系统起不来。我们当时的做法是先去云服务商的控制台看看，他们通常会在漏洞披露后的一两天内推出修复后的内核版本。然后通过系统的包管理工具进行升级，比如用yum update kernel或者apt-get upgrade linux-image这样的命令。升级完之后需要重启云主机，新内核才能生效。

这里有一个小技巧跟大家分享一下。升级内核之前，最好先确认一下当前正在使用的内核版本，用uname -r就可以看到。然后把新内核的版本记下来，重启之后再检查一遍，确保确实切换到新版本了。有些朋友升级完忘了重启，以为漏洞已经修复了，但实际上跑的还是老内核，那就等于白忙活了。另外云主机重启可能会影响业务，所以尽量选在业务低峰期操作，并且提前做好预案。

再来说说应用软件的漏洞修复。Redis未授权访问这个漏洞，我想做运维的朋友应该都不陌生。我前面说的那次入侵，就是栽在这个坑里的。那个版本的Redis默认配置是没有开启认证的，而且绑定在了所有的网络接口上。等于说谁知道了你的IP地址，都可以直接连上去读写数据。攻击者利用这个漏洞，写入了一个定时任务，然后挖矿程序就跑起来了。

修复这个漏洞其实很简单，就几步的事。第一步，修改Redis的配置文件，加上requirepass这一项，设置一个足够复杂的密码。第二步，把bind那一行改成只监听内网IP或者127.0.0.1，不要暴露在公网上。第三步，如果有条件的话，用防火墙把Redis的端口限制住，只允许特定的IP地址访问。做完这些之后重启Redis服务，漏洞就算堵住了。

但是这里有一个细节很多人会忽略。当你的Redis已经被人入侵了，光是改配置是不够的，因为攻击者可能已经在系统里留下了后门。正确的做法是，先把Redis服务停掉，然后检查系统里有没有可疑的计划任务、SSH公钥、启动脚本等等。我那次就是吃了这个亏，改了配置重启之后，第二天发现挖矿程序又跑起来了。后来一查，攻击者在crontab里写了一个定时任务，每半小时下载一次挖矿程序，所以光是堵住Redis的洞没用，得先把系统里的残留清理干净。

MySQL的安全漏洞修复也是一个值得说道的话题。有一次我们给客户做安全巡检，发现他们的一台云服务器上的MySQL版本非常老，存在一个叫做CVE-2016-6662的漏洞，攻击者可以通过这个漏洞拿到服务器的控制权限。客户的运维人员觉得这个漏洞的风险评级虽然高，但利用起来有一定条件，所以一直拖着没修。

结果两个月后，那台服务器果然被入侵了。攻击者利用这个漏洞拿到权限后，把数据库里的用户表给拖走了，然后勒索比特币。这件事给我们敲响了警钟，高危漏洞的修复真的不能拖，你觉得自己这台服务器不重要，攻击者可不会这么想，他们会全网扫描，逮到一个是一个。

MySQL的漏洞修复方法相对简单，就是升级到安全版本。但在云服务器上做这个事情之前，有几个准备工作要做好。先用mysqldump把所有的数据库备份一遍，万一升级出问题还能恢复。然后去MySQL的官网看一下Release Notes，确认新版本跟你现有的应用是否兼容。有些小版本升级是兼容的，可以直接替换二进制文件，有些大版本升级可能需要调整配置文件或者应用程序代码。在正式环境升级之前，最好能有一台测试机先试一下，确认没有问题再操作生产环境。

配置不当引发的漏洞，这个类别说实话是最让人头痛的。因为漏洞不是软件的bug，而是你自己设置错了。我有一个朋友的公司就出过这种事。他们的云服务器上跑了Jenkins，用来做持续集成。为了方便，他们把Jenkins的登录认证关掉了，任何人都可以访问。而且Jenkins是以root权限运行的，这意味着谁控制了Jenkins，谁就控制了整台服务器。

有一天他们发现服务器上多了一些奇怪的进程，排查之后才发现Jenkins被人利用了。攻击者通过Jenkins的脚本命令行功能，执行了系统命令，下载了一个反弹shell的木马。修复这个漏洞不仅仅是把认证打开那么简单。他们需要先确认攻击者到底做了哪些操作，有没有植入后门，有没有修改系统文件，有没有在其他地方埋藏恶意程序。这个过程非常耗时，最后不得已，他们选择重装了云服务器，从头搭建了一套环境，这次把安全配置做得严严实实。这个教训告诉我们，不要图一时方便而牺牲安全，看似省了几分钟的配置时间，后面可能要花几天甚至几周来弥补。

还有一个非常常见但经常被忽视的漏洞，就是云服务器的SSH配置。不少人装完系统第一件事就是关掉防火墙，或者把SSH的密码认证开着，用了一个很简单的密码。我见过最夸张的一次，一台云服务器的root密码是123456，而且22端口直接暴露在公网上。这种服务器在互联网上存活的时间通常不会超过几个小时，很快就会被扫描程序发现，然后被暴力破解。

修复SSH相关的安全问题，有几个标准动作。第一，如果条件允许，完全禁用密码认证，只使用SSH密钥登录。这样就算有人知道了你的用户名，没有密钥文件也进不来。第二，修改SSH的默认端口，虽然这个办法很初级，但能挡住大部分的自动扫描程序。第三，安装fail2ban这样的工具，自动封禁多次尝试登录失败的IP地址。第四，在云服务商的安全组规则里，把22端口只开放给特定的IP段，如果公司的出口IP是固定的，那就只允许公司的IP访问SSH，其他IP一概拒绝。

权限失控也是一个挺大的隐患。很多应用在云服务器上运行时，为了方便，直接用了root账号。这种做法相当于把所有鸡蛋放在一个篮子里，任何一个应用出了问题，整个系统就完蛋了。正确的做法是给每个应用分配单独的账号，只赋予它完成任务所需的最小权限。比如说一个跑Web服务的应用，它的账号只需要对网站目录有读权限，对日志目录有写权限，其他地方一律不能动。这样即使应用被攻破了，攻击者能做的事情也非常有限，没法搞垮整台服务器。

我自己的一个习惯是，每次配置完一台新的云服务器，都会跑一遍权限审计。看看哪些账号有sudo权限，这些sudo权限是否真的有必要，那些已经不再使用的账号有没有及时清理掉，家目录的权限设置是否正确，有没有不该对外开放的文件被设成了777。这些看起来琐碎的检查，往往能堵住很多潜在的漏洞。

另外一种容易被忽略的漏洞是云服务器的镜像和快照。有些团队喜欢用公共镜像快速部署服务器，但这些公共镜像里面可能预装了一些自己不需要的服务，比如FTP、Telnet等老旧的协议，这些服务本身就存在不少已知的漏洞。如果你的云服务器上跑了这些服务却没有用到，那就是白白增加了攻击面。

修复这类漏洞的方法是做减法。登录服务器后，用netstat或者ss命令查看一下，哪些端口处于监听状态，确认每一个端口对应的服务是不是必需的。如果不是必需的，就把对应的服务停掉，并且从系统里卸载掉。有一个叫Nmap的扫描工具，你可以从外部扫描自己的云服务器，看看暴露了哪些端口，跟预期的是否一致。这种外部视角的检查非常有价值，很多时候你觉得配置没问题，但实际扫出来才发现开了不该开的端口。

软件供应链的漏洞最近几年越来越多。所谓的供应链漏洞，就是你用的某个开源软件或者库本身是安全的，但是它的依赖项出了问题。比如说你写了一个Python应用，用到了某个第三方库，这个库又依赖了另一个库，那个库的某个版本有安全漏洞。这种情况下，修复起来就比较麻烦，因为你需要理清楚整个依赖链条。

应对这个问题有几个常用的方法。用依赖扫描工具检查项目里所有的依赖项，这些工具会比对已知的漏洞数据库，找出存在安全隐患的版本。然后升级有问题的依赖库到安全版本，如果升级不了，就找替代的库。另外尽量保持依赖库的版本不要太老，定期做一次全面的依赖更新，而不是等到漏洞曝光了再紧急修复。这就像定期体检一样，平时花点时间，比出了大问题再抢救要好得多。

前面讲的大部分是被动修复，就是漏洞已经知道了，我们去补上。但实际上更好的做法是主动发现漏洞，在别人利用之前就把漏洞堵住。云服务器上有一些很好的实践可以参考。比如定期做漏洞扫描，很多云服务商提供了免费的漏洞扫描服务，可以自动检测云服务器上存在的常见漏洞。虽然扫描工具不能发现所有问题，但至少能把那些已知的高危漏洞找出来，这已经能解决大部分问题了。

另外建立变更管理的流程也很重要。很多安全漏洞是因为配置变更引入的。比如运维人员临时开了一个端口测试，测试完之后忘了关。或者是开发人员为了调试方便，临时把防火墙关了，然后就忘了恢复。这些临时变更如果没有人跟踪和复核，很容易成为安全短板。我们的做法是，所有的配置变更都要有记录，并且设置一个自动恢复的时间，比如说临时开放端口只保留两个小时，时间一到自动关掉。这样就算有人忘了，系统也会帮你兜底。

说实话，安全漏洞的修复工作有时候挺枯燥的，也需要耐心。但每当你发现并修复了一个高危漏洞，那种踏实的感觉是很真实的。你知道自己不是在应付差事，而是在实实在在地保护业务和数据。这个工作没有捷径可走，就是靠一点一滴的积累和坚持。

最后想说的是，安全漏洞的修复不是一次性的工作，而是一个持续的过程。新的漏洞每天都在被发现，你的云服务器也需要持续地关注和维护。不要觉得今天把所有漏洞都修好了就万事大吉了，明天可能就冒出来一个新的。建立一套常规的安全运维机制，定期检查、定期升级、定期审计，把这变成一种习惯，而不是每次出了问题才手忙脚乱地去补救。只有这样，你的云服务器才能真正地跑得稳、跑得久。