php后门需人工审计+权限清理+运行时拦截，因其常伪装成正常文件或藏于数据库、PHP扩展、配置项中；多用户空间隔离可防横向渗透但无法清除已存在的后门。
PHP后门无法靠“一键删除”解决，必须人工审计+权限清理+运行时拦截；多用户空间隔离（如 PHP-FPM pool 隔离、容器或 vhost 级资源限制）能显著抬高攻击者横向渗透门槛，但对已获得 Web 用户权限的后门进程本身无清除能力。
怎么定位和删掉 PHP 后门文件
后门不是某个固定文件，而是被植入的恶意 PHP 代码片段，常伪装成图片、缓存、日志或正常业务文件。不能只删 shell.php 就算完事。
- 用
find扫描可疑扩展和修改时间：find /var/www -name "*.php" -mtime -7 -type f（重点看近 7 天新增或修改的.php文件） - 检查可写目录下非预期的 PHP 文件：
find /var/www -type f -name "*.php" -writable 2>/dev/NULL - 用
grep搜索典型后门特征函数：grep -r "eval|assert|system|passthru|exec|shell_exec|base64_decode|gzinflate" /var/www --include="*.php" - 注意混淆写法，比如
$a='e'.'v'.'a'.'l'; $a($_POST['x'])，需结合 AST 分析或动态行为监控（如 mod_security 规则或 php-spy） - 删完后立刻重置所有相关账户密码（FTP、数据库、CMS 后台），并检查 crontab 和 .bash_history 是否有持久化指令
为什么单纯删文件不等于清除后门
很多后门已脱离文件形态：写入数据库字段（如 wordpress 的 wp_options 表中 option_value 字段）、注入到 PHP 扩展（如自定义 .so）、或通过 auto_prepend_file 配置全局加载——这些删文件完全无效。
- 检查
php.ini中是否被篡改：auto_prepend_file、disable_functions、extension项 - 查 Web 服务器配置（如 nginx 的
fastcgi_param PHP_VALUE）是否在请求级覆盖了 PHP 设置 - 检查数据库中是否藏有 PHP 代码（尤其 CMS 的主题选项、插件设置、评论内容等字段）
- 若使用宝塔、cPanel 等面板，确认其后台用户未被添加恶意计划任务或反向代理规则
多用户空间隔离（PHP-FPM pool）防后门的实际效果
它不防上传型后门，但能阻止一个站点被黑后直接读取其他站点的 wp-config.php 或数据库凭证——前提是配置正确且没共用存储。
立即学习“PHP免费学习笔记（深入）”；
- 每个 pool 必须设独立
user/group，且文档根目录属主严格匹配（如www-data:site1，不可用www-data:www-data全局组） - 禁用
catch_workers_output = yes，避免错误日志泄露敏感路径 - 启用
php_admin_value[open_basedir]限制单个 pool 只能访问自己目录，例如：php_admin_value[open_basedir] = "/home/site1/:/tmp/" - 注意：如果多个站点共用同一 mysql 实例且账号权限过大（如
GRANT ALL ON *.*），隔离仍可能被绕过
真正有效的后门防御组合动作
没有银弹。隔离只是其中一环，关键在“不让恶意代码跑起来”和“让跑起来的也拿不到东西”。
- Web 服务器层加规则：用 ModSecurity 或 Nginx 的
if ($request_uri ~ ".php$") { ... }限制上传目录禁止执行 PHP - 禁用危险函数：在 php.ini 中设
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source - 文件系统级防护：把网站目录设为
chown root:www-data+chmod 750，Web 进程仅可读不可写 - 定期比对文件哈希（如用
sha256sum建 baseline），比杀软扫描更可靠
最常被忽略的一点：很多所谓“隔离”失败，是因为管理员用同一个 ssh 账号运维所有站点，一旦该账号泄漏，隔离形同虚设。权限最小化，得从人开始。