彻底封堵phpMyAdmin /setup路径：别让一个配置入口毁掉整个安全体系

不少技术人员在加固phpMyAdmin安全时，第一反应就是直接删除/setup目录。坦白说，这种做法看似干脆利落，但实际上并不牢靠——攻击者完全可能借助Web服务器的解析漏洞或残留配置，直接访问该目录中的PHP文件，例如/setup/lib/common.inc.php。真正行之有效的方案，是从服务器层面彻底阻断路径访问。

为什么单纯删除目录或修改权限不可靠

先来剖析典型的安全盲区。你可能遇到过这样一种怪现象：https://your-site.com/phpmyadmin/setup/页面明明返回了404，但访问日志里却充斥着针对该路径的GET请求；或者页面看似无法打开，可攻击者直接用curl就能绕过，直接请求/setup/index.php?step=2触发安装逻辑。

背后的原因其实并不复杂：

• Apache和Nginx只要检测到目录存在，并且PHP模块处于启用状态，就会尝试解析该路径下的PHP文件——哪怕你仅仅修改了权限或目录名称。
• chmod 644或重命名这类操作，只能让文件不可执行，但Web服务器仍然可以读取并返回源码。尤其是当php_flag engine off配置未能生效时，情况会更加尴尬。
• 部分一键安装包（例如AMPPS）默认给/setup开启了AllowOverride All，导致.htaccess中的规则反而被绕过，安全策略形同虚设。

因此，关键问题在于：真正危险的并不是目录本身存在，而是服务器仍然允许执行其中的任意PHP脚本。这个细节最容易被忽略，也最常被PoC利用。

Apache下的正确配置：用彻底拒绝访问

正确的做法，是在虚拟主机配置中直接写入拒绝规则，而不是依赖.htaccess。推荐写法如下：

    Require all denied

这里有三个关键点需要特别留意：

• 路径必须与实际安装路径完全一致。建议先用ls -l /etc/apache2/conf-enabled/确认符号链接指向的真实目录，否则规则不会生效。
• 千万不要写成Deny from all——这是旧版Apache的语法，新版已经弃用。
• 不要依赖RewriteRule来返回404，因为它只能拦截GET和POST请求，而OPTIONS或HEAD请求仍可能穿透规则，暴露信息。

Nginx下的正确写法：用location =精确匹配

很多人在Nginx上容易犯两个低级错误：要么用location /phpmyadmin/setup这种前缀匹配，结果误杀了/phpmyadmin/setup_xxx；要么用location ~ ^/phpmyadmin/setup这种正则匹配，不仅开销大，还容易遗漏。

正确的做法其实很简洁，直接放入server块内：

location = /phpmyadmin/setup {    return 404;}location = /phpmyadmin/setup/ {    return 404;}

需要注意以下几点：

• 如果phpMyAdmin部署在子路径下（例如/pma），必须同步修改为location = /pma/setup，不能直接照搬。
• 不要使用deny all——Nginx不支持该指令，配置会直接报错。
• 添加第二行/phpmyadmin/setup/是为了拦截末尾带斜杠的请求，否则可能会被自动重定向绕过，导致规则失效。

删除目录前最好想清楚：你是否真的不再需要setup向导

话说回来，如果你后续还需要手动调整config.inc.php（例如新增多服务器配置、切换认证方式），那么把/setup目录彻底删除就等于自断退路，后续只能靠手写或临时恢复备份来补救。

更稳妥的做法是分两步走：

• 先按上面的规则把访问彻底屏蔽掉，确保安全性。
• 保留目录，但清空其中所有PHP文件：sudo find /usr/share/phpmyadmin/setup -name "*.php" -delete。
• 最后只留一个空壳目录，里面放一个index.html，内容写

  Disabled

  。这样既能防止扫描，又给自己留了后路。

归根结底，安全配置这件事，最怕的就是“我以为够安全了”。一个路径的防护看似不起眼，但往往是整个防线中最容易被撕开的突破口。