怎么配置 Web 服务器禁止针对 Web 应用内部服务的非法外部请求指南

WAF核心原理是作为反向代理深度解析HTTP/HTTPS流量，通过协议还原、规则匹配与防护动作三阶段拦截SQL注入、XSS等OWASP攻击，并支持IP黑白名单、行为分析与虚拟补丁等多层防御机制。

要让 Web 服务器拒绝针对内部服务的非法外部请求，核心思路是：**不暴露、不响应、不转发**。这不是单一配置能解决的问题，而是需要在边界（WAF/反向代理）、服务层（Web 服务器）、应用层（代码与框架）三处协同设防。下面分场景给出可直接落地的关键操作。

一、用 WAF 或反向代理拦截非公开路径和方法

这是第一道防线，适合所有架构，无需改代码。

• 禁止访问内部管理路径：如 /actuator/、/admin/、/druid/、/swagger-ui.html 等默认暴露的监控或调试接口。在 WAF（如华为云 WAF、ModSecurity）中配置精准访问防护规则，匹配 URL 路径并设置动作为“拦截”。
• 限制 HTTP 方法范围：对非 API 入口路径（如静态资源目录 /static/、/images/），只允许 GET 和 HEAD；对后台管理接口，禁用 TRACE、OPTIONS、DELETE 等非常规方法。例如在 Nginx 中：

  location /admin/ {<br>  limit_except GET HEAD { deny all; }<br>}

• 封禁非可信来源 IP：将内部服务（如运维后台、配置中心）的访问权限严格限定在内网 IP 段（如 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16），外部请求直接 403 拒绝。

二、Web 服务器层面关闭冗余功能与接口

避免因默认配置导致内部服务意外暴露。

• 禁用 WebDAV、Server-Side Includes（SSI）、CGI 等高风险模块：Apache 中注释掉 LoadModule dav_module；Nginx 默认不启用 CGI，但需确认未通过 fastcgi_pass 错误指向内部服务地址。
• 隐藏服务器标识头：关闭 Server、X-Powered-By 等响应头，防止攻击者识别后端技术栈并针对性探测。Nginx 配置：server_tokens off;；Tomcat 在 conf/server.xml 中设置 server=" " 和 suppressHTTPHeaders="true"。
• 关闭目录浏览：确保 autoindex off（Nginx）或 listings=false（Tomcat 的 web.xml 中 default servlet 配置）生效，避免路径猜测后直接列出文件结构。

三、应用层加固：最小权限 + 显式白名单

即使请求绕过前置防护，也要让它在应用入口就被拒之门外。

• Spring Boot 应用示例：在 application.yml 中关闭敏感端点，或仅限本地访问：

  management:<br>  endpoints:<br>    web:<br>      exposure:<br>        include: "health,info"<br>  endpoint:<br>    health:<br>      show-details: never<br>  server:<br>    address: 127.0.0.1

• 使用 Spring Security 限定内部接口访问源：

  @Configuration<br>public class SecurityConfig {<br>  @Bean<br>  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {<br>    http.authorizeHttpRequests(authz -> authz<br>      .requestMatchers("/actuator/**").hasIpAddress("127.0.0.1/32")<br>      .requestMatchers("/internal/**").hasIpAddress("10.0.0.0/8")<br>      .anyRequest().authenticated());<br>    return http.build();<br>  }<br>}

• 禁用 Tomcat 内置非必要 Servlet：编辑 $CATALINA_HOME/conf/web.xml，将 DefaultServlet 和 InvokerServlet 的 <load-on-startup></load-on-startup> 设为 -1，或直接注释掉相关 servlet-mapping。

四、验证与持续监控

配置不是一劳永逸，必须验证效果并建立反馈机制。

• 用 curl -v http://your-domain.com/actuator/env 和 curl -X TRACE http://your-domain.com/ 测试是否返回 403 或 405，而非 200 或 500。
• 开启 WAF 或 Nginx 的访问日志，筛选出对 /druid/、/admin/、/console 等路径的请求，确认是否全部被拦截并记录。
• 定期扫描（如使用 Nikto、Nmap）检查服务器是否仍暴露危险路径或方法，纳入 CI/CD 安全检查环节。

不复杂但容易忽略。真正起效的不是某一条规则，而是从流量入口到应用逻辑层层收紧的“拒绝惯性”。