网站被攻击后应立即冻结可疑入口、检查权限配置、确认是否存在Web Shell；重点扫描可写目录中的异常PHP文件，收紧chmod权限至644/755/600，禁用php.ini中危险函数并限制open_basedir，Nginx/Apache须禁用上传目录的PHP解析。
网站被攻击后，第一反应不是重装或删库，而是立即冻结可疑入口、检查权限配置、确认是否已存在 Web Shell。PHP 环境本身不危险，危险的是默认宽松的权限、暴露的错误信息、未禁用的危险函数和可写目录里混入的 .php 文件。
查有没有 Web Shell：重点扫描可写目录 + 异常 PHP 文件
攻击者植入的后门通常藏在上传目录、缓存目录或任意可写子目录中，文件名可能伪装成图片（shell.jpg.php）、日志（access.log）或带随机字符串（a1b2c3.php）。
- 先定位所有 PHP 可执行目录：
find /var/www/html -type d -perm -o+w—— 找出其他用户可写的目录，这些是高危区 - 再查非标准位置的 PHP 文件：
find /var/www/html -name "*.php" ! -path "/var/www/html/*.php" -ls—— 排除主程序目录，揪出隐藏脚本 - 检查最近修改的 PHP 文件：
find /var/www/html -name "*.php" -mtime -7 -ls—— 攻击后门往往在 7 天内创建 - 用
file命令验证文件真实类型：file /var/www/html/uploads/shell.jpg.php，避免被扩展名欺骗
chmod 权限必须立刻收紧：644/755/600 不是建议，是底线
权限设成 777 或 755 给整个 /var/www/html 目录，等于把钥匙挂在门把手上。Linux 权限模型不认“信任”，只认“是否允许”。
-
.php脚本文件一律chmod 644：所有者读写，组和其他人只读 —— 即便被上传，也无法被覆盖或执行（除非配合include漏洞） - 目录统一
chmod 755：禁止其他用户写入，但保留执行位（Web 服务器需要进入目录） - 配置文件（如
config.php、.env）必须chmod 600：连同组用户都不能读，防止数据库密码泄露 - 上传目录（如
/var/www/html/uploads）不能给x权限，应设为755并配合 Web 服务器禁用 PHP 解析：location ~* \.php$ { deny all; }（Nginx）
php.ini 必改的三项：关显示、禁函数、锁路径
攻击者第一步就是访问 phpinfo.php 或触发报错，看版本、扩展、路径。生产环境的 php.ini 不该有任何“方便调试”的残留。
立即学习“PHP免费学习笔记（深入）”；
-
display_errors = Off：绝不能留On，否则 SQL 错误直接暴露表结构和绝对路径 -
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec：禁用全部命令执行函数，RCE 漏洞利用门槛直接拉高 -
open_basedir = /var/www/html:/tmp：限制 PHP 只能访问指定目录，../路径遍历失效，file_get_contents('/etc/passwd')返回 false - 顺手加一句：
expose_php = Off—— 隐藏X-Powered-By头，减少指纹识别成功率
别忽略 Web 服务器层：Nginx/Apache 的配置才是最后一道墙
PHP 层加固了，不代表请求进不来。很多 Web Shell 就靠绕过 PHP 配置，直传恶意文件再通过 Nginx 错误配置执行。
- Nginx 中上传目录必须禁用 PHP 解析：
location ^~ /uploads/ { location ~ \.php$ { deny all; } } - Apache 要确保
.htaccess生效且包含：php_flag engine off（针对上传目录） - 删除所有无用的测试文件：
rm -f /var/www/html/phpinfo.php /var/www/html/test.php /var/www/html/info.php - 检查虚拟主机是否启用
AllowOverride None，避免被 .htaccess 覆盖安全策略
真正容易被忽略的，是上传目录的权限和 Web 服务器对它的解析控制——两者缺一不可。设了 600 但没禁 PHP 解析，或禁了解析却给了 777 权限，都等于白做。加固不是堆配置，而是让每一层拒绝它不该处理的东西。
