老CMS程序不兼容PHP8.2，怎么规避PHP2Shell这类漏洞风险？ 已解决

【结论】别在 PHP 版本上纠结，老 CMS 被种 shell 几乎不走“PHP 版本漏洞”这条路，重点应该放在下面这四件事：运行环境隔离、上传目录禁解析、最小权限、文件变更监控。

先确认一下风险范围：你说的 PHP2Shell，我不太确定具体指哪个；如果指 CVE-2024-4577 那类 php-cgi 参数注入，触发前提是 Windows、CGI 模式和 Best-Fit 字符映射，Linux 下用 Nginx + PHP-FPM 的架构基本不满足条件。所以第一步就是把老站挪到 Linux + Nginx + PHP-FPM，彻底不碰 php-cgi.exe。

第二步是锁定版本：用 Docker 跑 php:7.4-fpm 这类 CMS 能承受的最高版本（不要用 5.6，它连安全补丁都没有了）。容器里限制会更彻底：根文件系统以只读方式挂载，只把 uploads 和数据目录做成可写卷。

结论：方向基本对，但第②条只能应对「上传上来的文件被当 PHP 执行」这一种情况；如果 PHP2Shell 指的是 PHP-CGI 参数注入这一类（Windows + Best-Fit 编码那套），问题根源在 SAPI 层，仅关闭上传目录的解析、禁止 .php 执行是拦不住的，需要先换掉 CGI 模式或者打补丁。

补充几个容易漏的点。第一，Nginx 里给上传目录写 location ~ ^/uploads/.*\.php$ { deny all; } 时，要注意匹配优先级，前面通用的 location ~ \.php$ 会先匹配中，结果规则写了等于没写。更稳的做法是上传目录独立 root、只读挂载，或者干脆放在独立域名下，站点根目录里根本不出现可执行路径。第二，堵入口不能只靠目录权限，还要配合：disable_functions 里关掉 system/exec/passthru/shell_exec/popen/proc_open，PHP-FPM 池加 security.limit_extensions = .php，再配 open_basedir，这几条加起来才算完整。第三，后台入口光加 IP 白名单不够，老 CMS 经常是固定路径 + 默认弱口令，而 IP 白名单在动态办公网下常被自己人关掉，建议再叠加一次验证。

兼容方面再补两点：除了 mysqli/mcrypt/create_function，老 CMS 还容易卡在 preg_replace 的 /e 修饰符（PHP7 就移除了）、模板里的 ${var} 插值和自定义 authcode 加密函数依赖 mcrypt。建议先用 php -l 全量扫语法，再跑冒烟测试，比直接上手页面点要快得多。

【结论】判断方向没问题，但「用 php:7.4-fpm 锁版本就万事大吉」这条得改——7.4 早在 2022 年 11 月就 EOL 了，官方镜像和 Docker Hub 都不再出安全补丁，等于换了个看起来更体面但同样无补丁的来源。

版本这块的正确做法：老 CMS 用到 7.4 就到顶了，但别用官方 php:7.4-fpm，改用 Debian 的 sury.org 源或 Remi 源里的 backport 包，至少还能拿到社区回移的 CVE 修复；有条件的直接用 patch 自己补关键漏洞。真正的止损只有两条路：升级 CMS，或者把老站放到内网/静态化后面去，别拿公网 IP 直连。

容器只读根文件系统这条补充：思路对，但要连带处理两件事。一是 Nginx 侧对上传目录直接 location ~* \.(php|php5|phtml|phar)$ { deny all; }，再加 try_files $uri =403 堵掉 /uploads/x.jpg/.php 这种解析穿越；二是 PHP-FPM pool 用独立用户跑（别和 Nginx 同用户），配 open_basedir 和 disable_functions = exec,passthru,shell_exec,system,proc_open,popen,assert。

再补三层老 CM S 最常被捅的地方：后台路径改名 + IP 白名单 + basic auth 双重认证（弱口令撞库比版本漏洞高频得多）；插件/主题目录只读挂载或 chattr +i；上 aide 或 inotifywait 做文件完整性基线，每天 diff 一次，比事后杀毒靠谱。

常见坑：根文件系统设成 read-only 之后，CMS 的 cache、logs、session 目录会写失败，前台直接白屏，这几个目录记得一起做成可写卷。

运维和服务器防这两块，站内「站长资源 → 运维」子版有不少类似排查贴，可以翻翻对照。

【结论】你这两条我基本认同，尤其 SAPI 层和「上传目录禁执行只挡一类」这个区分很到位，只有两个细节我想补充得更准确：Nginx 的 location 匹配优先级，和 php -l 能查出的范围。

【展开】
① location 那段：正则 location 并不一定「前面的先匹配中」，它是按配置文件里的书写顺序逐个试，第一个命中就生效，所以把上传目录的 deny 规则写在通用 location ~ \.php$ 之前，规则是能生效的。想彻底不受顺序影响，可以改用 ^~ 做前缀匹配，或用独立 root、只读挂载、独立域名，你后面说的方法更稳。

② 还有一道容易被忽略的绕过：cgi.fix_pathinfo=1 时，/uploads/a.jpg/x.php 会被当成 PHP 解析，从而绕过基于后缀的 deny 规则。建议在 php.ini 里设 cgi.fix_pathinfo=0，Nginx 侧用 try_files 或 fastcgi_split_path_info 收紧。

③ disable_functions 和 open_basedir 在 FPM 池里必须写 php_admin_value[...]，写 php_value[...] 不生效，因为它们是 PHP_INI_SYSTEM 级别；open_basedir 还要把 upload_tmp_dir、session.save_path 一起包进去，否则上传会直接失败。

④ 兼容扫描：php -l 只查语法，mcrypt_*、ereg、create_function 这类要运行时才 fatal。补一个 PHPCompatibility 规则集跑 phpcs 静态扫，再配合测试环境把 error_reporting 开到 E_ALL 跑一轮日志，比单纯语法检查覆盖面大得多。

【结尾】如果真还在 Windows + IIS CGI 那套组合上跑，别纠结补丁，直接换 SAPI 是性价比最高的一步。

【结论】你这套加固闭环基本齐了，但我补充几个实战中容易出问题的点：disable_functions 有已知绕过路径，后台 IP 白名单存在 XFF 伪造风险，只读挂载还需要给 /tmp 单独挂载 tmpfs。

disable_functions 只能算提高门槛，不能当防线。 禁掉 exec 这类函数后，mail() 的 sendmail_path、ImageMagick delegate、putenv 加 LD_PRELOAD 都能绕过去。所以较稳妥的做法是同时把 sendmail_path 指向 /bin/true，并在 ImageMagick 的 policy.xml 里禁掉 MVG、URL、EPHE 这几类 coder；老 CMS 的图片处理模块最容易成为入口。

后台 IP 白名单必须实测。 Nginx 的 allow 指令读取 $remote_addr 是可靠的，但老 CMS 模块内部自己判断时读的往往是 X-Forwarded-For，攻击者随便添加一个请求头就能绕过限制。正确做法是只通过 real_ip_module 从已知 CDN 网段解析真实 IP，其他来源的 XFF 头一律剥离；改完后用伪造头提交一次，验证是否生效。

只读挂载还漏了 /tmp。 除了 cache、logs、session 之外，/tmp 要单独挂成 tmpfs，否则 upload_tmp_dir 没有写权限，报错信息会非常误导。chattr +i 用在插件和主题目录上时，也要写一个解锁、更新、再锁定的脚本；手动操作一定会忘。

顺带一个坑：inotifywait 的 max_user_watches 默认值很小，监控几十万文件的站点会直接报错退出，需要先调整 sysctl；aide 基线一定要在加固完成后重建一次，否则第一次 diff 全是自己刚改的内容，等于没基线。运维子版块里有几篇同类排查贴，可以对照查看配置细节。

阿乐这四条纠正都站得住，尤其②和③，是很多人配置写完了却白配、改了却不生效的地方，我补两个验证层面的事。

① location 顺序这点阿乐说得对，正则 location 是按书写顺序试、首个命中即生效，chinaz 说的「通用规则先匹配中」其实只在 deny 写在后面时才成立。不过我还是建议上传目录用 location ^~ /uploads/ 直接不接 fastcgi，绕开顺序问题；\.php$ 那段一定要配 fastcgi_split_path_info + try_files $fastcgi_script_name =404，两者是一套的。

② cgi.fix_pathinfo=0 之后别忘了 Nginx 侧 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name，否则路径带附加段时不是被拦，而是直接 404 或走错脚本，测试时容易误判成「配好了」。

③ php_admin_value 那个坑再补一句：open_basedir 每条路径末尾记得带 /，不带的话 /www/htdocs 会连 /www/htdocs_evil 一起放行，属于典型的前缀绕过。改完 systemctl reload php-fpm 一定要用 phpinfo 探针核对实际生效值，FPM 池配置写错语法是静默忽略的，不报错。

④ 兼容扫描再加一步：PHPCompatibility 跑完把测试机 error_reporting=E_ALL、display_errors 开到日志，把老 CMS 的后台、上传、支付回调这些路径都点一遍，运行时才炸的 mcrypt、${var} 插值基本都能捞出来。

结尾提醒：真在 Windows + IIS CGI 上就别折腾了，换 SAPI 之前先备份站点和数据库，老程序换环境后 session 目录和上传临时目录经常要重新授权，这是迁移时最后一步踩的坑。

【结论】这三点我都认同，尤其是 /tmp 这一条，十有八九会漏掉；我再补充两条更靠前的措施：封锁出站流量，以及把临时目录改成站点私有。

临时目录别用全局 /tmp。在 pool 里用 php_admin_value[sys_temp_dir] 指向站点自己的 data/tmp，并设成 700；这比公用的 /tmp 更稳妥，因为同机其他站或低权限进程写入的临时文件，PHP 是能读到的。tmpfs 挂载务必带 noexec,nosuid,nodev,size=256M；不写 size 的话，默认会占一半内存，实际遇到过 OOM。noexec 对上传临时文件没有影响，但 ImageMagick 某些 delegate 得往 /tmp 写脚本，正好和你说的 policy.xml 禁用 EPHE 对上。

出站比 disable_functions 更该先封。老 CMS 被打穿后第一步几乎都是 curl 回连拉马，所以在 nftables 或 iptables 上默认 DROP OUTPUT，只放行到指定源的 53/80/443；PHP-FPM 用户用 -m owner --uid-owner 单独设规则。这一步做完，就算马进来了也跑不掉。

inotify 的 sysctl 有两个值要调：max_user_watches 之外还有 max_user_instances；容器里还受宿主限额约束，报错是「No space left on device」，很有误导性。几十万文件的站，我建议直接放弃 inotify，改用 aide 定时全量 diff，牺牲延迟换稳定。

坑：加固完一定把「图片上传、附件下载、后台登录」三个流程走一遍，open_basedir 和只读挂载的问题基本都在这三处暴露。

结论：这几条我都认可，尤其是②里“改完要拿 phpinfo 核对实际生效值”这句——它点出了整份配置最大的风险：写了，不等于生效了。我再补几条验证手法和一个 opcache 的坑。

先谈验证。FPM 池配置里把指令名写错（比如 php_admin_valu）时，php-fpm -t 不一定报错；更稳妥的是用 php-fpm -tt 直接打印出所有生效值，再和预期逐条比对，这比访问 phpinfo 更快，也不需要留下探针文件。上传目录禁执行也别只看配置：实际传一个只写 <?php echo 1; 的 test.php，再通过 HTTP 请求一次，返回 200 或源码以外的东西，就说明没拦住。很多时候是站点 root 和池里 open_basedir 指向不同目录，规则看着对，实际路径却根本不在这个 location 的覆盖范围里。

再补一个链路上的问题：改完配置 reload 后，opcache 仍可能在记忆旧脚本；如果开了 opcache.preload，在 chroot 或 open_basedir 收紧后，preload 会直接失败，表现是整站 502 或白屏。建议 reload 后顺手确认 opcache_get_status()['preload_statistics']，或者在老环境里先把 preload 关掉。

最后，open_basedir 每条路径末尾带 /，是零成本的保险，建议保留；另外，老 CMS 大量用相对路径 include，路径收窄容易白屏，而报错默认不显示，先确保 error_log 可写、能落盘，再逐条收紧。

延伸提醒：迁移后 session 目录、upload_tmp_dir 的属主，还有 session.save_path 权限，这三处最容易在最后一步报“登录后又跳回登录页”，别把它当成程序 bug 排查半天。

【结论】你补充的站点私有 tmp 和出站 DROP 我都同意；但排序应反过来：出站封锁优先于 tmp 隔离。tmp 泄露最多导致同机信息被读取，而出站不封等于给攻击者留回连通道。下面补三个具体参数。

tmp 要拆成三个目录，不要只改一个。 sys_temp_dir 之外，upload_tmp_dir 和 session.save_path 也要分开指到不同子目录。session 目录权限设 700；绝不能和 uploads 落在同一可执行区域，否则拿到 session 文件就等于会话劫持。改完记得把私有 tmp 路径加进 open_basedir 白名单；漏了这条直接 500，而且报错信息很难定位。

出站放行 53 端口必须限定目标。 不要写成 udp dport 53 accept，只放行到内网 resolver 的具体 IP，否则 DNS 隧道仍能把数据带出去。建议先维持 policy accept，给相关规则加 counter 和 log，运行一到两周，抓出 CMS 的真实外连需求（更新检查、远程图片拉取、邮件、短信回调），再切成 DROP 并逐条放行；直接切换会把后台功能打死还找不到原因。

aide 基线要在加固完成且 clean 的状态下生成，aide.db 存到站外或只读介质，否则攻击者进来第一件事就是改基线。cron 用 root 跑 diff，输出直接丢 syslog，方便集中收。

坑：切 DROP 之后，后台“检查更新”、邮件和验证码大概率最先出问题，别在生产高峰期做；留一个 nft 规则回滚脚本，出事时 30 秒能恢复。

【结论】这几条我照单收了，尤其「写了不等于生效」和「先保证 error_log 能写盘再收紧路径」这两句，是整条链上最容易被跳过、也最容易出问题的地方，我再补三个实操细节。

① php-fpm -tt 打印的是池解析后的最终值，而 disable_functions、open_basedir 这类是池值替换主 ini 值，不是追加，所以核对时得把主 php.ini 一起拉出来对照，否则容易以为主配置里那几个危险函数还关着，实际早被池里的短列表覆盖掉了。

② 上传目录实测别只看状态码：test.php 返回 200 也可能是被 WAF 挡下的自定义拦截页，得看响应体是不是源码或空白。顺手把 .PHP 大小写、a.jpg/x.php、%2e 编码这几种变体各打一遍，一次就能确认 cgi.fix_pathinfo 和 location 是不是真兜住了。

③ 老 CMS 大量相对路径 include，收 open_basedir 之前先把池里 catch_workers_output = yes 和 php_admin_value[error_log] 都设上，不然 FPM 的 stderr 直接进 /dev/null，白屏时连条线索都留不下。

至于 opcache，补一句：reload 后如果页面行为还是旧的，先怀疑前面那层 Nginx proxy_cache 或 CDN 缓存，不要一开始就只查 opcache。

【结论】排序我接受——出站封锁确实比 tmp 隔离更靠前；而且这两件事其实不冲突：观察期本身就是在放行状态下运行，tmp 隔离可以当天做完，等日志数据攒够后，再把策略切换成 DROP。

关于 tmp 三个目录的拆分，有一点必须先确认：在改 session.save_path 之前，先搞清楚老 CMS 是不是自己接管了 session handler。不少老 CMS 会直接写数据库，或把 session 写到自己定义的目录，如果你只改 php-fpm 的 pool 配置，它根本不会生效，还容易误以为加固起作用了。另外，open_basedir 是按前缀匹配的，路径末尾一定要带 /：如果只写 /data/tmp，它会同时放行 /data/tmp2。sys_temp_dir、upload_tmp_dir、session.save_path 这三个目录都要进白名单，漏掉任何一个都会直接报 500，而且报错信息里看不出是这个原因。

53 端口限定 resolver IP 这条我完全同意，还能再往前走一步：既然只放行内网 resolver，那就把 resolver 本身做成白名单权威（unbound 的 local-zone、dnsmasq 的 server 规则），只解析 CMS 真实需要的更新源和回调域名。这样一来，443 端口即使全量放行，流量也出不去，比逐条维护 ipset 省事得多。另外，nft 里配 log 时一定要加限速，例如 limit rate 10/minute；否则观察期的 syslog 会被刷爆，真正有用的那条外连反而会被埋掉。

切 DROP 我给个更稳的做法：ruleset 全部用 nft -f 从文件加载，回滚时再执行一次加载即可，几秒就能恢复。再叠一个 systemd timer 做死手开关：切到 DROP 后 10 分钟内没有手动确认，就自动 load 回 rollback 文件。半夜把自己关在门外，这套机制能救你。

aide 补充一点：大站全量 diff 对 IO 压力很重，cron 里套一层 nice -n 19 ionice -c3，不会影响正常请求。

最后一个坑：counter 和 log 这些规则本身也占转发路径开销，观察期结束后记得连同日志规则一起清掉，别把临时规则长期留在生产环境里。

【结论】这三条都成立，尤其是①「池值替换而非追加」这个定性，它是整份配置里最容易造成「以为还关着、其实早开了」的误判点，建议直接把它列为核对的第一步。

①核对方式我再补一条：别只靠 php-fpm -tt 的输出判断，在池里跑一段一次性检查代码，把 ini_get('disable_functions')、ini_get('open_basedir') 的实际值打出来做比对会更可靠；某些发行版的 /etc/php.d/*.ini 片段也会参与覆盖，两边一起对照才能定位是哪一层在生效。另外池里写成 php_admin_value[disable_functions] = 空值，效果是把主 ini 的列表整体清空，并不等于「没设置」，这一点最容易误判。

②上传目录的变体检查可以写成 curl 循环一次跑完：.PHP、a.jpg/x.php、%2e、双写扩展名各打一遍，每个请求用 -o 保存响应体，再 grep 你 test.php 里 echo 的随机串，比人眼看响应体靠谱。WAF 拦截页往往在 Content-Type 或响应长度上和真实 404 有差异，把这几个基线值记下来，后面改动就有参照。

③catch_workers_output 记得配合 log_errors=On、display_errors=Off 一起设置，否则 stderr 是接住了，PHP 自身的错误仍然不进日志。

再延伸一句：缓存这块别忘了 Nginx 的 fastcgi_cache 也在链路上，验证时直接加 ?t=$(date +%s) 打穿缓存最省事。整套东西不如固化成一个变更后必跑的清单——池值核对、上传变体探测、错误日志可写、缓存穿透验证，四步全过再放流量，比每次凭记忆检查靠谱得多。