nginx118漏洞

nginx在2018年爆出的那个CVE-2018-16843，说白了就是个内存泄漏。攻击者不需要什么高级技巧，只要持续发送特定格式的畸形请求，就能让worker进程的内存像漏水的桶一样慢慢淌光。等内存耗尽，nginx直接罢工，网站就白屏了。

我见过太多运维栽在这上面。有个朋友管的电商平台，平时流量不大，某天突然收到一堆告警，服务器负载飙到80%。他第一反应是数据库出问题，查了半天没结果。最后看nginx错误日志，全是"upstream prematurely closed connection"。后来才发现是有人在用工具对着他的nginx发了几个小时的特殊请求，每个请求都带着超长的HTTP头。nginx解析这些头的时候，每次都会分配一小块内存，但释放的时候没处理干净，日积月累就把4G内存吃完了。

这个漏洞的恶心之处在于它不需要什么高权限。普通用户就能触发，只要你的nginx暴露在公网上。而且官方修复补丁出来之前，网上已经有人公开了利用代码。那段时间我检查过的服务器里，至少有三分之一没打补丁。有些是嫌重启麻烦，有些根本不知道自己用的版本有问题。

修复方案其实不复杂。官方在1.15.6版本里做了修复，核心改动就是调整了内存池的分配策略。但很多人忽略了一个细节——光升级nginx不够，你得确认编译的时候用的是系统自带的pcre库，还是自己编译的静态版本。如果用了静态链接的pcre，那必须重新编译整个nginx才能生效。我见过有人只替换了二进制文件，结果漏洞照样存在，因为底下的pcre库还是老版本。

更实际的做法是加一层防护。在nginx配置里限制单个请求头的大小，比如large_client_header_buffers 4 8k，把缓冲区设小一点。再配合client_header_timeout和client_body_timeout，让那些慢速攻击自动断开。这些参数平时没人会去调，但关键时刻真能挡住一部分攻击流量。

还有个容易被忽略的点——日志。默认的access_log会记录每个请求的完整头部，如果攻击者故意构造超长头，日志文件会疯涨。我建议把日志级别调到warn以上，或者干脆把access_log关掉，只保留error_log。毕竟业务日志可以后续从其他渠道获取，但服务器别被日志撑爆才是首要任务。

这事儿过去五年多了，但类似的坑还在不断出现。nginx的新版本时不时会冒出新的内存问题，比如CVE-2021-23017那个DNS解析器的漏洞。每次看到这种新闻，我都会想起那次半夜帮朋友排查的经历。技术这东西，永远不能指望一劳永逸。你唯一能做的，就是保持警惕，及时更新，别嫌麻烦。