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