HVV 应急溯源基础 ——Web中间件与 PHP 安全加固配置指南（三）

本文围绕主流 Web 中间件与 PHP 的典型错误配置场景展开梳理，汇总漏洞成因、排查命令与落地加固手段，既适合护网蓝队应急安全排查使用，也可作为 Web 服务安全基线巡检、等保合规自查的实操参考资料。

文章目录

• • 文章简介
  • Apache中间件安全加固
  • • [1. 目录遍历问题及解决方法](#1. 目录遍历问题及解决方法)
    • [2. 版本信息泄露问题及解决方法](#2. 版本信息泄露问题及解决方法)
    • [3. 页面报错导致信息泄露及解决方法](#3. 页面报错导致信息泄露及解决方法)
    • [4. 多后缀文件解析漏洞及解决方法](#4. 多后缀文件解析漏洞及解决方法)
    • • 漏洞原理
      • 解决方法
  • Nginx中间件安全加固
  • • 与Tomcat中间件的比较
    • [1. 目录遍历问题及解决方法](#1. 目录遍历问题及解决方法)
    • [2. 信息泄露问题及解决方法](#2. 信息泄露问题及解决方法)
    • [3. 路径解析漏洞及解决方法](#3. 路径解析漏洞及解决方法)
  • Tomcat中间件安全加固
  • • [1. War包后门文件部署及解决方法](#1. War包后门文件部署及解决方法)
    • [2. 目录遍历问题及解决方法](#2. 目录遍历问题及解决方法)
    • [3. PUT上传问题及解决方法](#3. PUT上传问题及解决方法)
    • • 产生原因
      • 加固解决步骤
  • 总结

---

文章简介

在护网攻防、日常 Web 安全基线巡检场景中，Nginx、Apache、Tomcat 作为主流 Web 中间件，承担着客户端请求转发、业务数据交互的核心作用，可屏蔽底层操作系统与网络协议差异，实现前端、服务端、数据库之间的数据通信。不当的中间件与 PHP 参数配置极易引发目录遍历、信息泄露、命令执行等高危漏洞，成为攻击者入侵 Web 服务的主要突破口。

本节针对三款常用 Web 中间件及 PHP 程序开展不安全配置隐患排查，并给出标准化安全加固方案。

大家也可以看之前写的文章：

• HVV应急溯源基础------Linux 系统安全加固配置指南（一）
• HVV应急溯源基础------Linux 系统安全加固配置指南（二）
• 如果想了解具体的应急溯源专栏：等保应急响应（靶场）

---

Apache中间件安全加固

Apache HTTP Server（简称Apache）是一款开源网页服务器软件，支持跨操作系统部署，凭借良好的兼容性与稳定性得到广泛应用，是当前主流的Web服务中间件之一。但不合理的配置会引发各类高危安全漏洞，常见风险包含文件解析漏洞、远程命令执行、目录遍历、任意文件上传等，极易被攻击者利用入侵业务系统。

1. 目录遍历问题及解决方法

目录遍历是Apache最典型的配置类安全隐患，攻击者可借助该漏洞遍历站点目录结构、读取下载数据库配置、账号密钥等敏感文件，造成核心业务数据泄露。针对该漏洞，可通过修改主配置文件关闭目录索引功能完成修复：

1. 在Ubuntu、Debian 系统中，编辑/etc/apache2/apache2.conf配置文件，将配置项Options Indexes FollowSymLinks修改为Options FollowSymLinks；
2. 在CentOS 系统中，修改/etc/httpd/conf/httpd.conf配置文件，同样移除配置里的Indexes参数，即可关闭站点目录浏览权限，防范目录遍历攻击。

修改后的apache2.conf文件内容如下：

<Directory /var/www/>
  Options FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

修改前以及修改后效果对比：

2. 版本信息泄露问题及解决方法

本次测试环境使用的是Apache 2.4.41版本，默认配置下，服务器错误页面、HTTP响应头部会直接对外暴露中间件版本、操作系统等指纹信息。攻击者可通过搜集该类敏感信息，针对性查找对应版本的公开漏洞，以此发起定向入侵攻击，存在较高安全风险。

为防范Apache版本信息泄露，需要根据不同操作系统修改对应的服务主配置文件：

1. 在Ubuntu、Debian系列系统中，修改apache2.conf配置文件；
2. 在CentOS系列系统中，修改httpd.conf配置文件。

可以添加下面两条命令来隐藏版本信息：

ServerSignature Off
ServerTokens Prod

只需在对应配置文件的末尾添加隐藏版本信息的参数，重启Apache服务即可生效。配置前，访问异常页面会明文展示Apache版本信息；完成加固配置后，服务将不再返回详细版本指纹，有效规避版本泄露风险。

3. 页面报错导致信息泄露及解决方法

网站异常报错页面往往会附带中间件版本、服务器路径等敏感内容，极易被攻击者用来收集服务指纹，除了直接关闭报错详情展示外，还可以通过错误页面重定向的方式进行防护。

在不同操作系统中修改对应的Apache主配置文件：Ubuntu、Debian系统编辑apache2.conf，CentOS系统编辑httpd.conf，在配置文件末尾添加配置语句：

ErrorDocument 404 /404.html

配置生效后，当网站出现404访问异常时，会自动跳转到自定义的404静态页面，不再返回服务器原生报错详情，从根源上避免报错页面泄露Apache版本、服务器路径等敏感信息。

4. 多后缀文件解析漏洞及解决方法

漏洞原理

Apache具备多后缀文件解析特性，针对info.php.png这类带有多个后缀的文件，服务会从文件名末尾向前逐个识别后缀，一旦遇到无法识别的格式，就会向前匹配PHP这类可执行脚本后缀并解析运行。

解决方法

该文件在Windows系统下会被默认判定为图片，却能被Apache当作PHP脚本执行。若网站仅限制用户上传图片格式文件，攻击者便可借助该机制上传带图片后缀的PHP木马文件，绕过前端上传白名单校验，最终触发恶意代码执行，非法控制服务器，具体漏洞利用效果如图：

针对该安全漏洞，可通过配置文件添加多后缀解析访问限制完成防护。在Ubuntu、Debian系统中编辑apache2.conf，CentOS系统则修改httpd.conf，写入如下拦截配置：

<Files ~ "\.(php.)">
Order Allow,Deny
Deny from all
</Files>

保存配置后重启Apache服务 ，即可拦截带有多PHP后缀格式的文件解析请求。加固完成后，即便攻击者上传info.php.png格式的恶意文件，Apache也不会再将其解析为PHP脚本执行，成功规避文件上传类解析攻击，加固后的访问效果如图：

Nginx中间件安全加固

Nginx属于轻量级Web与反向代理服务器，具备内存占用低、高并发处理能力强的优势，既可以承载静态网页访问，也能够通过CGI协议解析PHP、Perl等动态脚本语言。若Nginx配置不当，极易产生文件解析、目录遍历、缓冲区溢出等各类安全漏洞，成为攻击者入侵业务系统的突破口。

与Tomcat中间件的比较

1. 目录遍历问题及解决方法

目录遍历是Nginx典型的配置类安全风险，开启目录索引后，攻击者能够直接浏览站点目录结构，下载网站配置、数据库密钥等敏感文件，造成核心数据泄露。

针对该漏洞，需要修改Nginx主配置文件完成加固：

• 在Ubuntu、Debian系统中编辑/etc/nginx/nginx.conf
• CentOS系统则修改/usr/local/nginx/conf/nginx.conf

将配置项autoindex on修改为autoindex off，关闭目录自动索引功能。配置生效后，用户将无法直接访问站点目录列表，从源头修复目录遍历安全隐患；

autoindex on  ➟  autoindex off

2. 信息泄露问题及解决方法

本次实验环境部署的是nginx/1.18.0（Ubuntu）版本，默认配置下，服务器的响应头、错误页面会直接返回Nginx的详细版本号与操作系统信息。攻击者可凭借该服务指纹检索对应版本的公开漏洞，发起定向渗透攻击。

为规避版本信息泄露风险，需要修改Nginx主配置文件nginx.conf，将配置参数server_tokens on修改为server_tokens off。

server_tokens on ➟  server_tokens off

配置生效前，访问异常页面会明文展示Nginx版本信息，完成配置并重启服务后，服务将不再对外暴露中间件版本详情，有效降低攻击者的漏洞探测范围，加固后的展示效果如图：

3. 路径解析漏洞及解决方法

Nginx路径解析漏洞属于典型配置不当引发的安全缺陷，触发原理如下：

1. 当访问info.jpg/x.php这类特殊路径时，若php.ini配置中cgi.fix_pathinfo=1，PHP会自动向上回溯校验路径，在/x.php文件不存在时，自动截取上层路径尝试解析info.jpg。
2. 若PHP-FPM配置文件www.conf中的security.limit_extensions参数为空，FastCGI解析器不会限制可执行脚本后缀，会直接将jpg、png等图片格式文件当作PHP脚本执行。

攻击者可利用网站图片上传功能，上传嵌入恶意PHP代码的图片木马，再通过构造上述特殊访问路径绕过上传白名单限制，最终触发漏洞执行webshell，非法控制服务器，漏洞利用效果如图：

解决步骤具体如下：

1. 编辑php.ini配置文件，注释cgi.fix_pathinfo=0所在配置行，关闭PHP的路径自动修复回溯功能，从根源阻断路径回溯解析行为。
2. 打开fpm/pool.d/www.conf配置文件，修改security.limit_extensions参数，将参数值设置为.php，仅允许FastCGI解析后缀为.php的脚本文件。
3. 保存全部配置文件，重启Nginx与PHP-FPM服务使配置生效。

加固完成后，即便攻击者构造info.jpg/x.php类恶意访问请求，服务也不会将图片文件解析执行，成功防御该路径解析类攻击，加固后的安全访问效果如图：

Tomcat中间件安全加固

产生原因：

Tomcat是开源免费的轻量级Web应用服务器，多用于中小型业务系统，也是开发调试JSP程序的常用中间件。一旦配置不规范，会产生管理后台弱口令、PUT上传、远程代码执行等诸多安全漏洞。

1. War包后门文件部署及解决方法

Tomcat默认开启Manager管理后台远程访问时，若管理员配置了简单弱口令，攻击者可借助BurpSuite工具对后台登录接口实施暴力破解。成功猜解账号密码后，攻击者可将JSP木马打包为war压缩包，通过Tomcat管理后台上传部署，待服务自动解压发布后，即可使用蚁剑等工具连接Web木马，直接获取目标服务器远程Shell权限，实现主机入侵控制；

# 生成war包
jar -cvf shell.war*

解决步骤：

1. 设置高强度管理账号密码
   进入Tomcat的conf目录，编辑tomcat-users.xml配置文件，修改账号对应的password字段，将密码设置为8～16位，由大小写英文字母、数字、特殊符号组合而成，避免弱口令被暴力破解；

<role rolename="tomcat"/>
<role rolename="manager-gui"/>
<role rolename="admin-gui"/>
<role rolename="manager-script"/>
<role rolename="admin-script"/>
<user username="admin" password="admin" roles="tomcat,manager-gui,admin-gui,admin-script,manager-script"/>

2. 限制Manager后台仅本地IP访问
   打开路径/webapps/manager/META-INF下的context.xml配置文件，通过访问权限规则配置，仅放行127.0.0.1本地回环地址访问管理后台，拒绝所有远程主机的访问请求；

<Context antiResourceLocking="false" privileged="true" >
  <CookieProcessor className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
      sameSiteCookies="strict" />
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
  allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
  <Manager sessionAttributeValueClassNameFilter="java\.lang\.(?:Boolean|Integer|Long|Number|String)|org
\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
</Context>

2. 目录遍历问题及解决方法

通过访问目标网站，查看是否存在目录遍历安全问题，攻击者可利用该漏洞，下载及查看目标网站敏感数据、了解网站目录结构等信息：

对于使用Tomcat中间件的网站，可以通过修改conf/web.xml配置文件，将listing值由false修改为true，便可以修复目录遍历安全问题：

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>true</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

加固方式为将<param-value>true</param-value>修改为<param-value>false</param-value>，关闭目录自动索引展示，保存配置后重启 Tomcat 即可修复该安全隐患。

3. PUT上传问题及解决方法

产生原因

当Tomcat部署在Windows系统中且服务器开启了PUT等危险HTTP请求方法时，攻击者可先通过OPTIONS请求探测网站支持的请求方式，若返回GET、PUT、DELETE、MOVE等方法，便可利用这些扩展请求实现文件上传、删除、修改等恶意操作。

OPTIONS获取目标网站支持的请求方式

Tomcat默认由JspServlet处理JSP、JSPX脚本文件，该Servlet默认不支持PUT请求，无法直接上传JSP木马，但在Windows环境下攻击者可通过构造1.jsp/或1.jsp%20这类特殊路径绕过限制，借助PUT方式上传JSP恶意脚本，再通过蚁剑连接木马，从而获取目标服务器远程控制权限：

加固解决步骤

修改Tomcat全局web.xml配置文件，找到DefaultServlet配置段，将其中readonly参数的配置值从false修改为true，开启只读访问模式，禁用PUT、DELETE等具备文件写入、删除能力的危险请求方法，保存配置后重启Tomcat服务即可彻底修复PUT文件上传漏洞，加固配置效果如下：

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>true</param-value>
    </init-param>
    <init-param>
        <param-name>readonly</param-name> # 修改处
        <param-value>true</param-value> # 修改为true
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

总结

本次实验针对Apache、Nginx、Tomcat 三款主流Web中间件开展安全加固测试，三类中间件的安全隐患大多源于默认配置过于宽松，集中表现为目录遍历、服务版本信息泄露、文件解析漏洞、后台弱口令、危险HTTP方法开放五类高频风险。通过修改对应配置文件，关闭目录自动索引、隐藏中间件版本标识、限制非法脚本解析、收紧后台访问权限、禁用PUT等危险请求，能够从源头拦截攻击者利用配置缺陷实现信息窃取、恶意文件上传与远程服务器控制。

本次中间件加固全程遵循最小权限安全原则，一方面屏蔽服务器敏感指纹与目录信息，最大限度缩小攻击面，避免攻击者通过信息搜集精准匹配漏洞发起渗透；另一方面严格约束脚本解析范围、后台访问来源与文件操作权限，从底层封堵文件上传、远程代码执行等高危攻击路径，全方位提升Web业务服务的整体安全防护能力。