运维新手必避的5大服务器配置坑，第3个90%人中招

　　九月份那台新上线的业务服务器，我原以为配置完就万事大吉了——结果凌晨三点被监控群@全员，说流量突增到平时十倍。爬起来一看，好家伙，/tmp目录下多了个.ssh/authorized_keys2文件，权限还设成644，直接被人塞了公钥。后来查日志，发现是三天前某个运维同事手滑把SSH端口改成了2222，没改防火墙规则，被扫描器逮个正着。这他妈就是第一个坑：开放高危端口却不锁IP，跟裸奔有什么区别？

　　第二个坑更离谱。上周帮测试组搭环境，他们说要装Docker，我顺手把/var/lib/docker挂载到单独分区——结果第二天发现磁盘爆了。查半天才反应过来，测试组那帮人直接在容器里跑压力测试，日志文件把分区塞满，连systemd都挂掉了。更绝的是，他们为了“方便”，把宿主机/etc/hosts文件权限改成了777，现在谁都能往里面塞条目。我敢打包票，至少一半运维新手栽过这种“图方便”的坑。

　　第三个坑才是重头戏——SSH配置里的PermitRootLogin。上周三凌晨两点，安全组突然甩过来一张截图：某台生产服务器的root密码被暴力破解，攻击IP来自乌克兰。我翻配置文件一看，PermitRootLogin还设成yes，密码认证也没关。最骚的是，这服务器是三个月前刚交接的，前运维离职前特意在交接文档里写了“已禁用root登录”，结果新人接手后，可能觉得“按文档操作太麻烦”，又偷偷改回去了。我后来问过五个不同团队的运维，四个都承认干过这种事——90%这个数，真没夸张。

　　说到日志，第四个坑差点让我背锅。上个月某业务线说被注入攻击，安全组让我溯源。我翻Nginx日志，发现大量POST请求带单引号，但WAF没拦截。查配置才发现，运维同事为了“减少误报”，把WAF的SQL注入规则集从“严格模式”调成了“宽松模式”，还把日志级别从debug改成了error——结果攻击记录全被吞了，连攻击者的IP都只能靠TCP连接日志拼凑。更搞笑的是，他还在交接文档里写了“已优化WAF性能”，安全组差点以为是我配置有问题。

　　第五个坑跟备份有关。上周五要恢复某台数据库，发现备份文件是空的。查备份脚本，发现运维同事把mysqldump的输出重定向到了/dev/null，理由是“怕备份文件占空间”。我问他“那数据存哪了？”，他说“存内存里了，反正每天重启服务器”。我当场就懵了——这他妈是2025年，不是2005年，还有人用这种“备份方式”？后来发现，他连crontab里的备份任务都注释掉了，只在文档里写了“已配置自动备份”。

　　对了，说到日志，昨天翻某台服务器的auth.log，发现连续三天凌晨三点有来自192.168.1.100的SSH登录尝试——这IP是内网某个开发机的，但那台机子上周就报废了。我原以为是谁忘了关端口，结果查监控发现，是某个运维同事用那台机子做跳板机，离职前没删SSH密钥，现在被人当后门用了。更绝的是，他还在交接文档里写了“已清理所有密钥”，结果/root/.ssh/authorized_keys里还留着三条。

文章配图，仅供参考

　　不过话说回来，我也说不准这些坑到底能不能完全避免。毕竟运维这行，坑太多，新坑叠旧坑，有时候你觉得自己避开了，结果一抬头，发现又掉进另一个坑里了。就像上周那台服务器，我以为关了PermitRootLogin就万事大吉，结果第二天发现，运维同事为了“方便”，又开了个允许密码认证的普通用户，权限还设成了sudoers——这他妈比root登录还危险。

（编辑：站长网）

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