PHP后门需定位、清除、堵入口三步，不能仅靠删除；低权限运行无法阻止后门，反因Web进程合法写权限被利用；须结合函数扫描、权限管控、解析禁用与运行时防护。
PHP后门无法靠“删除”一劳永逸，必须先定位、再清除、最后堵住入口；低权限账户运行本身不阻止后门生成，反而可能掩盖写入行为——攻击者常利用Web进程（如www-data）的有限权限完成上传和执行。
怎么快速定位PHP后门文件
后门通常伪装成正常文件，但有固定行为模式：异常的base64_decode、eval、assert、system、shell_exec调用，或非常规文件名（如.jpg.php、wp-config-backup.php）。不要只依赖文件名判断，重点查内容。
- 用
grep -r --include="*.php" "eval\|assert\|system\|shell_exec\|passthru\|exec\|base64_decode\|str_rot13" /var/www/扫描可疑函数调用 - 检查最近修改的PHP文件：
find /var/www/ -name "*.php" -mtime -7 -ls - 关注非标准路径下的PHP文件，比如
/var/www/html/uploads/、/var/www/html/wp-content/plugins/等可写目录 - 注意空格、不可见字符、混淆变量名（如
$a=$_POST['x'];@eval($a);），简单grep可能漏掉，需配合php -l语法检查+人工抽检
删完就安全？得看Web服务器权限配置
低权限运行（如Apache用www-data用户）不是防护手段，而是默认配置。它不能阻止后门生成，因为Web进程本就需要往上传目录、缓存目录、日志目录写文件——攻击者正是利用这个合法权限完成落盘。
- 上传目录（如
/uploads/）应禁用PHP解析：location ~* ^/uploads/.*\.php$ { deny all; }（Nginx）或<files> Order Deny,Allow Deny from all </files>（Apache） - 确保
open_basedir限制在Web根目录内，防止后门跨目录读取敏感文件（如/etc/passwd） - 关闭危险函数比删文件更有效：在
php.ini中设置disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec（注意部分CMS需要curl_exec，别误杀） - Web目录下不应存在可写+可执行的组合权限，尤其
wp-content这类目录，应设为755，文件为644，且属主不是www-data
为什么“删后门”常失败？关键在持久化入口
很多清理只盯着.php文件，却忽略后门可能藏在数据库、隐藏系统用户、定时任务、或通过已篡改的合法插件持续再生。
立即学习“PHP免费学习笔记（深入）”；
- 检查
crontab -u www-data -l和/etc/cron.d/下是否有异常任务（如每分钟wget某远程PHP文件） - WordPress站点要查
wp_options表里的active_plugins、cron字段，以及wp_users里多出的管理员账号 - 查看
ps aux | grep php，确认有没有脱离Web服务器启动的独立PHP进程（如监听端口、反向连接） - 用
lsof -i :80或netstat -tulpn确认是否还有未授权监听服务
真正难处理的是那种不落地、纯内存执行的后门（如通过preg_replace的/e修饰符注入，或利用PHP-FPM socket直接传入恶意opcode），这种连文件都不存在，只能靠流量分析或启用php-sandbox类扩展做运行时拦截——多数运维会忽略这点。
