90%服务器漏洞源于这3类配置疏漏

　　一个月前，测试提了个阻断 bug：/api/v2/user/export 返回 500，但只在凌晨三点以后复现。我盯着日志里那行“connection reset by peer”，手已经摸到 SSH 密钥了——结果发现是 Nginx upstream timeout 设成三十秒，而下游 Python 服务里 psycopg2 的 statement_timeout 居然设成了四十五秒。不是配置冲突，是压根没人知道这俩玩意儿得对齐。我原以为是数据库连接池漏了，结果连进 psql 查 pg_stat_activity 都没查，先去翻了上游的 Dockerfile 里那行注释：“# 为兼容旧客户端已调高超时”——你猜怎么着？那客户端三年前就下线了。

　　工位右屏壁纸还是上个月换的《2012》剧照，地球裂开那张；左屏 Chrome DevTools 切在 Network tab，但 Filter 栏里还留着“/healthz”没删。键盘空格键卡过两次，每次都是按下去有回弹但不触发，得补一下指尖力度——这事儿跟配置疏漏没关系，纯粹机械老化，但你看运维谁管这个？没人管。隔壁组后端老张端着保温杯路过，水溅出来一滴在桌沿，顺着我那份刚打出来的 AWS Security Hub 报告边沿流下去，把“Critical”三个字洇开了点，像被水泡过的墨粉。

文章配图，仅供参考

　　90%服务器漏洞源于这3类配置疏漏。不是我编的，也不是审计报告抄来的——是上周我们被红队摸进内网后，他们撤出时留下的 Slack 截图里写的：“三处配置缺陷覆盖全部利用链”。我说实话，那个截图我敢打包票是真货：红队头儿用的深灰主题，状态栏显示 14:37，Chrome 地址栏右侧还挂着 uBlock Origin 图标，图标角标是 18。至于“90%”这个数？我说不准，但我知道，他们扫完三十七台跳板机之后，停在第七台没动——因为那台机器 /etc/ssh/sshd_config 里 PermitRootLogin yes 后面多打了两个空格，导致 reload 失败、配置回滚到上个月备份，而那个备份里 MaxAuthTries 是 12。这事我亲眼看见日志里报错，也亲手改回来的。

　　第一类：权限粒度粗暴。比如给 Jenkins Agent 账号加 sudo 权限，非得写 “ALL=(ALL) NOPASSWD: ALL” 才安心？我见过最离谱的是把 docker.sock 挂给 CI 容器，再顺手把容器 run 在 host 网络里——还美其名曰“提升构建速度”。上上周产品上线前半小时，PM 冲进机房喊“快把日志级别切成 DEBUG！老板要看实时用户行为！”——结果那条 curl 命令直接打进了生产环境 Kibana，他连 Basic Auth 都没输对，但 kibana.yml 里 xpack.security.authc.providers 的顺序早被人改过，把 http:basic 放在了 file:realm 前面，所以默认走的是匿名入口。这哪是功能？这是筛子。

　　第二类：日志与监控错配。Kafka 服务器 log.retention.hours 设成一百六十八（七天），可 Logstash 配置里 input 插件用的是 file{}，start_position => "beginning"，且没有 exclude => [".gz"]——意味着每天凌晨 roll 的压缩包也会被读一次。这不是漏日志，是主动制造噪音。我们昨天刚把 Grafana 告警阈值从 95% CPU 拉到 99%，因为某次扩容后自动伸缩组启用了新 AMI，里面 systemd-journald 的 RateLimitIntervalSec 居然被改成十秒——结果所有服务启动瞬间狂喷 thousand lines/sec 的 journal，CPU 直接顶满。我盯着 top 里那个 journald 进程看了八分钟，直到后端老李过来问：“你那边磁盘 IO 崩了吗？”我才发现 df -h 里 /var/log/journal 下三百七十二个节点全占满了。

　　第三类……第三类最气人。TLS 证书路径写死在 config.json 里，而部署脚本每次都会 chmod 644 ——包括那个 pem 文件。上周五凌晨三点零七分，证书续期失败，nginx reload 报错：PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line)。我 ssh 进去看，证书开头居然是乱码。倒不是被篡改了，是续期脚本跑完 certbot renew，又执行了一次 sed -i 's/\
$//' /etc/letsencrypt/live/xxx/fullchain.pem——而那台机器的 shell 是 dash 不是 bash，sed 解析 \
时崩了，把整个文件头搞成二进制垃圾。这事我不怪脚本，我怪自己——三个月前 code review 时，看到那段 sed 就该骂人。结果我说了句“应该没问题”，就点了 approve。现在想起来，手指还在发麻。

　　说到 PR review，上月我拒掉一个前端 PR，就因为 .env.production 里写了 VUE_APP_API_BASE=https://dev-api.example.com。提交人是个实习同学，我批注说“这种写法迟早炸”。她回：“可是本地 mock 模式需要啊。”我说：“mock 应该跑 webpack dev server，不是靠改生产环境变量。”——她没回。第二天，我在生产 nginx 日志里看见 /mock/user.json 被访问了十九次，User-Agent 是 curl/7.68.0，IP 是运维堡垒机。后来查到是某个值班同事想测接口，随手 curl 了一下，而那个路由规则居然没配 deny all；它匹配到了 location ~ ^/mock/ {}，然后 proxy_pass 给了 upstream dev-mock-server——可那台 server 十个月没重启过，上面还开着调试模式，/admin/console 页面连 basic auth 都没加。我删掉这条 location 规则的时候，汤洒了一滴在键盘上，刚好落在 Q 键右边那条缝里，到现在还没干透。

　　优胜劣汰这点倒是真——去年我们砍掉两个老旧监控模块，换 Prometheus Operator，结果新集群 rollout 第三天，Alertmanager 的 webhook_configs 里 slack_configs 的 channel 字段少了个井号，告警全发进 #general 而不是 #alerts。群里吵了一小时，有人甩出 YAML 片段说“这里格式没错”，我截图指出 YAML parser 把 channel: alerts 实际解析成 map[alerts:]，因为没加引号。最后谁赢了？没赢。运维组当晚把全部 Slack webhook 加了引号；SRE 组在 Confluence 更新了模板；而 PM 下午三点准时开会讲“本季度用户体验升级成果”。我关掉 Slack，右屏壁纸上地球裂开的光斑正滑过时区线，像某种缓慢的、不容辩驳的失效。

　　下周我打算把 ansible-playbook 里的所有 set_fact: { timeout: 30 } 全替成 with_items + loop_control，至少能看清哪个任务真在超时。但说实话，我也不确定是不是真有用——毕竟有些东西，你盯着看越久，越觉得不是配置错了，是整个抽象层本身就在松动。比如我昨天修完那个 PostgreSQL 超时，顺手改了 pg_hba.conf 的 hostssl 行顺序，重启后 psql -h 又连不上了……我重读了 man 5 pg_hba.conf，又翻了 pg_controldata 输出，最终发现是因为 pg_ctl stop 时没加 -m fast，wal 日志里留了个孤儿 checkpoint 记录，导致 recovery 期间忽略部分 ssl 选项。这已经不是配置疏漏了，这是 Postgres 在用自己的方式提醒你：别太相信你自己写的每一行 config。

　　先不写了。后端老李刚微信问我：“/v3/reports/summary 接口又慢，是不是 CDN 缓存没清？”——我还没回。他不知道那个接口压根没走 CDN，路径在 nginx 里被 rewrite 成了 /internal/report/v3/summary，而 internal location 段里，proxy_buffering off; 这行配置……我昨天下午删的。我以为它影响的是上传。现在我得去确认一下。

（编辑：站长网）

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