linux系统漏洞如何手动修复

上个月我帮朋友修一台CentOS 7服务器，系修复被植入挖矿程序，统漏CPU飙到300%。洞何查了半天，手动根源是系修复个老漏洞——内核版本停在3.10，攻击者利用脏牛变种直接提权。统漏手动修复这事，洞何真不能光靠yum update了事。手动

先定位漏洞，系修复别瞎补

手动修复第一步不是统漏打补丁，是洞何搞清楚你面对的是什么。用yum check-update列出可用更新，手动再用yum info看具体版本差异。系修复但更关键的统漏是查CVE编号——去NVD或Red Hat CVE数据库搜你系统版本对应的漏洞列表。比如OpenSSL的洞何Heartbleed，影响的是1.0.1到1.0.1f，你系统如果跑1.0.2g，那根本不用修。

我习惯先跑一遍lynis audit system，它给的输出比你自己瞎翻日志靠谱多了。不过记住，lynis只是参考，它有时会误报。

内核漏洞：手动编译是下策

内核出问题，最省事的是装发行版提供的更新内核。但有些生产环境不能随便重启，这时候你得手动打补丁。拿脏牛（CVE-2016-5195）举例，如果厂商没给对应内核补丁，你可以下载官方patch文件，用patch -p1手动应用，然后重新编译内核模块。但说实话，手动编译内核风险极高——我干过一次，编译完模块加载直接panic，最后只好用GRUB引导旧内核恢复。除非你特别有把握，否则别在生产机这么玩。

用户态软件漏洞：改配置比升级快

很多漏洞不需要升级二进制包。比如Nginx的目录穿越漏洞，如果只是配置不当引起，你改改nginx.conf里的alias路径就能堵住。OpenSSH的某些信息泄露漏洞，你可以在sshd_config里禁用特定算法，比如加上KexAlgorithms -diffie-hellman-group14-sha1。这些操作不用重启服务，nginx -s reload或systemctl reload sshd就生效。

上周我处理一个vsftpd的漏洞，就是版本太旧。但对方不想升级，怕影响现有FTP账号权限。我直接改了vsftpd.conf，把anonymous_enable=NO，然后限制本地用户目录范围——漏洞利用条件直接被掐断了。有时候绕开问题比解决问题更实际。

依赖库的坑：你必须手动验证

最烦的是动态链接库漏洞。你用ldd /usr/bin/curl会看到一堆.so文件，其中任何一个有漏洞都可能被利用。手动修复思路是：先查这个库被哪些关键程序依赖，比如libssl.so.1.1被ssh、curl、wget共用。然后去发行版仓库找修复版本，用rpm -Uvh强制升级——但千万注意，库版本更新可能导致依赖它的老程序崩溃。我踩过坑：升级libgcrypt后，GPG签名验证直接失败，回滚又怕漏洞还在，最后只能临时下载静态编译的GPG工具应急。

真遇到这种情况，你最好写个脚本，记录升级前后所有依赖该库的程序列表，逐个测试启动是否正常。

别忽略配置文件里的定时任务

攻击者常把后门写在cron里。手动修复时，crontab -l和cat /etc/crontab必须查。有些漏洞本身不会直接给你root，但配合一个cron任务就能提权。比如某个web应用有文件写入漏洞，攻击者写了个脚本到/var/spool/cron/，定时执行。你光升级应用没用，得把这个定时任务删掉，还得检查/root/.ssh/authorized_keys有没有异常公钥。

修完必须验证，不然等于没修

打完补丁或改完配置，别急着收工。用nmap --script vulners扫描本机端口，看漏洞是否还探测得到。更直接的方法是写个PoC测试——比如针对某个CVE的公开exploit代码，在测试环境跑一遍确认失效。但生产机别这么干，用openssl version -a或nginx -V检查版本号是否已包含修复commit。

手动修复这事，本质上是个权衡——你花时间硬怼漏洞，还是花时间迁移到新系统。很多时候，前者只是拖延，后者才是根治。