Linux安全环境搭建：13年运维实战指南

　　去年九月那场安全事故，我现在想起来还后怕——凌晨三点被监控告警吵醒，控制台里全是SSH暴力破解的日志，/var/log/secure文件大到用vim打开都卡顿。更离谱的是，安全组规则里居然还留着三年前测试用的22端口开放记录，产品经理当时说“就开半小时测完就关”，结果谁都没记得删。后来查日志发现，攻击者从我们一台被挖矿的测试机（那台机器还是设计组借去跑渲染的）当跳板，扫了整个子网，连中台服务器的MySQL弱口令都试出来了。

文章配图，仅供参考

　　说到SSH，我真是受够了那些“方便”的配置。去年刚接手这个项目时，发现所有服务器的/etc/ssh/sshd_config里都开着PermitRootLogin yes，PasswordAuthentication yes，甚至还有UseDNS yes——这玩意儿在内网根本用不上，还会拖慢登录速度。我改完配置重启服务，结果测试组说“登录变慢了”，我一看日志，好家伙，他们的测试脚本里硬编码了DNS反查，改完UseDNS no后，登录时间从3秒降到0.5秒。更绝的是，安全组里居然还开着2222端口，说是“备用SSH”，结果被扫描器抓到，成了攻击者的重点目标——现在那台机器的/var/log/auth.log里，全是“Failed password for root from 192.0.2.1”的记录，IP地址换着花样来，跟走马灯似的。

　　防火墙规则也是个坑。去年双十一前，设计组说要跑个静态资源生成脚本，需要临时开放8081端口。我让他们走Nginx反向代理，他们说“太麻烦，直接开防火墙就行”。结果那台机器的iptables规则里，ACCEPT规则排在最前面，DROP规则在最后面——攻击者只要扫到8081端口，直接就能连进来，根本不用管后面的DROP。我查日志时发现，那台机器的/var/log/nginx/access.log里全是404，但/var/log/messages里全是“Connection refused on port 8081”——攻击者试了半小时，发现端口不通，转头就去扫其他机器了。后来我强制要求所有防火墙规则必须用“默认拒绝，白名单放行”的策略，结果设计组又抱怨“影响工作效率”——我直接把监控截图甩群里：那台机器的8081端口被扫了5万次，其中2000次是已知的Webshell上传流量。

　　最让我无语的是，有些“安全措施”根本就是自欺欺人。比如那个“定期改密码”的政策——运维组要求所有服务器密码每90天改一次，结果大家为了方便，全用“Password123!”这种弱口令，或者干脆把密码写在/etc/hosts文件里。我查过几台机器的/etc/shadow，发现好多用户的密码哈希值都没变过——他们改密码时，只是把“Password123!”改成“Password123!!”，或者加个数字后缀。后来我强制要求所有服务器禁用密码登录，只用SSH密钥，结果测试组说“密钥文件太大，上传慢”——我直接把他们的密钥文件压缩后，用scp传上去，解压时间从10秒降到2秒。

　　现在我的策略很简单：所有服务器默认关闭所有端口，只开必要的SSH（22）和HTTPS（443），其他端口必须走跳板机加VPN；SSH禁用root登录，禁用密码登录，只允许密钥登录；防火墙规则用“默认拒绝，白名单放行”的策略，规则按严格程度排序；定期审计/var/log/secure和/var/log/auth.log，发现异常登录立刻封IP。上周五下班前，我还把所有服务器的SSH配置备份了一份，存到私有的Git仓库里——上次那台被挖矿的测试机，就是因为配置被篡改后没备份，导致我花了半天时间才恢复。

　　当然，我也知道这些措施不是万能的。比如那个跳板机，如果被攻破，整个内网就完了；还有那些SSH密钥，如果泄露了，攻击者照样能登录。但至少现在，控制台里不再是一片红，/var/log/secure文件也不会大到用vim打开都卡顿了。下一步我打算把所有服务器的日志集中到ELK里，用Kibana做可视化监控——不过这事儿得跟产品经理和后端组商量，他们最近又在催新功能上线，可能没时间管安全。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!