多媒体服务器安全审计：90%漏洞源于3个忽视配置

　　我越来越觉得“多媒体服务器安全审计：90%漏洞源于3个忽视配置”是错的。

文章配图，仅供参考

　　我原以为问题出在“没关 debug 端口”，结果抓包发现 nginx 配置里那行 rewrite ^/api/(.)$ /debug/$1 break; 根本没生效，因为 upstream 定义里多写了两个空格，而上游那个用 go 写的鉴权中间件压根没校验 path prefix，它只校验 header 里的 X-Auth-Token——但 token 是明文塞进 query string 的，被缓存到 CDN 日志里，连 WAF 规则都懒得拦截这种“非攻击流量”。

　　所以现在我听见有人说“三个配置项漏了就炸”，我冷眼看他掏手机翻 checklist。哪三个？location 块里加了 auth_basic off；RTMP module 的 on_publish 指向了一个 404 的 HTTP 地址；还有……哦对，ffmpeg -re -i 里硬编码了 /var/www/html/live/xxx.flv 路径，连目录遍历防护都不用，直接 curl 'rtp://x.x.x.x:1935/live/xxx.flv?../../../../etc/passwd' 就能拿到响应头里 Content-Length: 1212。这算“配置漏洞”？不，这是把容器当物理机使、把流媒体服务当静态文件托管用、把鉴权当装饰贴纸糊在入口门框上——可没人管这叫“配置”，他们管这叫“部署惯性”。

　　我删过十七个站的 nginx.conf，试了三个月，就为验证一件事：只要 client_max_body_size 大于 100M，不管你怎么写 limit_except POST，只要后端用的是 node.js 的 formidable 库 + 默认 multipart 解析，上传一个带 .php 扩展名的 .mp4 文件，再在 URL 里加个 ;a.php，Apache 就会照单执行——而 nginx 那句 try_files $uri =404; 在遇到 /live/xxx.mp4;a.php 时根本不起作用，它真·去查文件了。小陈当时蹲在监控屏前，一边敲 docker exec -it xxx sh，一边骂：“谁TM在 build 镜像的时候把 /usr/bin/php 放进去了？！” 我没吭声，因为我上周亲手改的 Dockerfile，理由是“方便调试”。

　　优胜劣汰倒是真的。上个月老李的视频平台被扫出六个未授权访问，他连夜重写鉴权层，用 gRPC 代替 HTTP callback，连日志都切成毫秒级分片。我昨天翻他 GitHub 提交记录，发现他在 proto 文件里加了一行注释：// keepalive_timeout 不能设成 0，否则 ffmpeg 推流断连后不会触发 on_disconnect。这话我三年前在阿里云钉钉群里说过，他还点赞了。结果现在他 repo 里 commit id 是 f7b9c32，内容是把 keepalive_timeout 改回了 0，因为“测试环境压测吞吐高”。

　　对了，上礼拜我去机房巡检，看见新来的实习生在调试 WebRTC 信令服务，他把 STUN 地址配成 stun:localhost:3478，然后在 NAT 后面跑 coturn——我刚想开口，他掏出手机给我看抖音同款音效 SDK 文档截图，上面写着“stun 服务建议本地部署以降低延迟”。我点点头，转身就走。这事我也可能就运气好，没赶上他导出的 ICE 候选者里混着 docker0 网卡的私有 IP 和 port，没赶上那个被遗忘在角落的 peerconnection.onicecandidate 回调里，正往 WebSocket 上发 base64 编码的 candidate 字符串，其中包含 host:172.17.0.2 的字段。至于原理我说不清，反正 RFC 5245 里没写“必须校验 candidate.host 是否属于受信网段”。

　　还有一事：我昨天重启一台旧服务器，系统盘只剩 12G，/var/log/journal 里堆着二十七万条 “Failed to open memory stream for journald.”，但我懒得清，因为一清 journalctl 就会崩，而崩之前它会先 fork 出三千个子进程刷屏输出 “No space left on device”——这个错误和我们上次被黑无关，但它让 grep -r “auth_fail” 的速度从 0.8 秒变成 43 秒。所以你现在问我安全漏洞在哪？我只能告诉你，我刚收到通知，公司要换新的 SIEM 平台，对接接口文档第七页写着：“支持解析 H.264 Annex-B 格式 NALU 时间戳字段”。我问售前这玩意儿跟日志分析有啥关系，他说：“老板觉得高端。”

　　我现在每次审计，第一件事是翻 /proc//environ，第二件事是查有没有 cron 任务在每天三点自动执行 find / -name ".so" -exec strings {} \\; | grep -i "admin"。第三件事？第三件事是看团队里谁的 VS Code 主题是 Tomorrow Night Bright。因为用这个主题的人，有六成概率在 .gitignore 里漏掉了 .env.local，而里面写着 S3_ACCESS_KEY=AKIA...——这个细节和“三个忽视配置”没关系，但它出现在我们上个月被攻破的第五台机器上。我没记错的话，当时攻陷链路是：从 Telegram 频道扒下的 demo 视频链接 → 解析出 embedded subtitle URL → 拿到 AWS S3 presigned URL 有效期 → 反向推导出 key ID → brute-force 最后四字节密钥 → 下载原始 mkv 文件 → 从末尾 2048 字节提取出硬编码的 admin token。整套流程里，nginx 配置文件一个字母都没动。

　　所以别跟我说什么“三个配置”，真要列，我给你列十个。但第十个一定是：没人在乎 ffmpeg -i 输入路径里藏了 $() 命令替换，直到某天客户上传个叫 “$(id).mp4” 的文件，然后 /var/log/audit/audit.log 里多出一条 type=SYSCALL msg=audit(1701273600.123:45678) arch=c000003e syscall=59 success=yes。这事我也可能就运气好，没碰上 auditd 被 disable 的机器。

（编辑：站长网）

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