从一次未授权访问排查谈内网 Web 服务暴露面治理

背景

内网 Web 服务未授权访问是很多安全事件的起点。它不一定表现为高危漏洞，有时只是一个调试接口、一个默认后台、一个临时部署的管理端口，但一旦被纳入横向移动路径，就会放大成真实风险。

这篇文章整理一次常见的内网排查思路，重点放在暴露面识别、风险判断、日志验证和治理闭环上。内容不涉及攻击控制或绕过类操作，适合作为企业内网自查、红队复盘后的加固参考。

问题场景

某业务内网中存在多个历史系统，包含 Java 管理后台、Node.js 调试服务、Prometheus 指标接口、对象存储控制台以及若干临时测试页面。安全巡检时发现部分接口无需认证即可访问，其中部分接口返回了敏感运行信息。

典型表现包括：

• 管理后台直接访问，无登录或默认弱认证。
• 调试端口暴露，如 Spring Boot Actuator、Node inspector、Swagger UI。
• 指标接口泄露主机名、服务名、数据库连接状态等信息。
• 测试接口返回配置片段、异常堆栈或内部 IP。
• 反向代理配置不严，导致内部路径可被直接访问。

技术分析

未授权访问的本质不是“有没有漏洞利用代码”，而是访问控制边界失效。常见原因主要有三类。

1. 服务自身缺少认证

一些组件默认面向内网可信环境设计，部署时如果没有补充认证，就会形成裸露接口。例如指标系统、任务调度后台、配置中心、文件管理台等。

排查时可以关注这些路径或特征，但应限制在授权范围内：

/actuator
/actuator/env
/actuator/health
/swagger-ui/
/v2/api-docs
/metrics
/debug/pprof/
/admin
/console
/api/config

2. 网关或反向代理策略不一致

很多系统前面有 Nginx、Ingress 或 API Gateway。常见问题是页面入口做了认证，但内部 API、静态调试页面或历史路径没有纳入策略。

例如只保护了根路径：

location / {
    proxy_pass 
    auth_request /auth;
}

但单独配置的管理路径没有认证：

location /internal/ {
    proxy_pass 
}

这种情况在服务迁移、灰度发布、临时联调时比较常见。

3. 网络边界假设失效

“只在内网开放”并不等于安全。办公网、测试网、容器网段、VPN 网段、CI/CD Runner 所在网络都可能访问到这些服务。一旦某台机器被钓鱼、弱口令或供应链问题影响，内网未授权服务会成为风险放大器。

关键步骤

一、资产梳理

建议先从现有资产数据开始，不要直接盲扫全网。可以综合 CMDB、Kubernetes Service、Ingress、Nginx 配置、云安全组、Prometheus target、注册中心数据进行交叉比对。

如果是在授权环境中做端口确认，可以用较保守的方式进行服务识别：

nmap -sT -Pn -p 80,443,8080,8081,9000,9090,3000,5000 --open 10.10.0.0/24

对 Web 服务做标题和状态码采集即可，不建议一开始使用高强度漏洞扫描。

httpx -l hosts.txt -title -status-code -tech-detect -follow-host-redirects

二、识别高风险接口

识别时重点看返回内容，而不是只看状态码。HTTP 200 不一定有风险，HTTP 401/403 也不一定安全，因为可能存在部分路径未保护。

可重点记录以下信息：

• 是否存在认证流程，认证是否覆盖所有敏感路径。
• 页面是否暴露系统版本、组件名称、环境标识。
• 接口是否返回配置、Token、数据库地址、队列地址。
• 是否能查看任务、日志、文件列表、运行状态。
• 是否存在调试页面或交互式接口文档。

对于 Spring Boot Actuator，通常重点确认暴露端点范围，而不是尝试修改环境或触发危险操作。安全排查只需要判断是否泄露敏感信息即可。

curl -i 
curl -i  日志可以初步筛选敏感路径：
grep -E "actuator|swagger|metrics|console|admin|debug|api-docs" access.log | awk '{print $1,$4,$7,$9}' | sort | uniq -c | sort -nr | head
如果使用 Kubernetes Ingress，可结合网关日志、Pod 日志、审计日志判断访问来源。重点关注：
非业务网段访问管理端口。
大量 404/403 后跟随敏感路径命中。
User-Agent 异常，如批量扫描器特征。
短时间内遍历多个服务相同路径。
访问后是否出现异常登录、配置读取、服务重启等事件。
四、风险分级
未授权访问的风险不能只按“是否需要登录”判断，需要结合返回内容和操作能力。
风险等级
典型情况
处理建议
高
可查看配置、密钥、日志、任务、文件或具备管理操作能力
立即下线暴露入口，轮换相关凭据，排查历史访问
中
泄露服务版本、内部路径、主机名、依赖组件、接口文档
补充认证和访问控制，隐藏调试信息
低
仅返回健康状态或无敏感信息，但缺少明确访问控制
纳入基线治理，限制来源网段
五、修复与加固
修复时不要只在应用层加一个登录页，最好从网络、网关、应用三层同时收敛。
管理端口与业务端口分离，管理端口只允许运维网段访问。
网关层统一认证，不允许历史路径绕过。
禁用生产环境 Swagger、调试页面、测试接口。
Actuator 仅暴露 health、info 等必要端点，敏感端点关闭。
指标接口通过专用采集链路访问，不直接对大网段开放。
配置中心、任务平台、对象存储控制台必须接入统一身份认证。
清理默认账户和历史测试账户。
Spring Boot Actuator 的最小暴露示例：
management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=never
management.server.port=9001
Nginx 可用来源限制作为兜底，但不要把它当作唯一认证方式：
location /actuator/ {
    allow 10.20.0.0/16;
    deny all;
    proxy_pass 
}
如果有统一认证网关，建议敏感路径全部纳入认证策略：
location /admin/ {
    auth_request /auth;
    proxy_pass 
}

location /swagger-ui/ {
    auth_request /auth;
    proxy_pass 
}
注意点
不要在未授权环境中进行批量探测，内网服务稳定性通常比外部服务更脆弱。
确认风险时以读取证明为主，不要执行修改、重启、删除、任务触发等操作。
发现密钥、Token、数据库连接串后，应按泄露处理，不要只关闭页面。
修复后要做回归验证，确认同类路径、同类服务、同类网段都已覆盖。
将规则沉淀到发布流程中，新服务上线前自动检查管理端口和调试接口。
治理闭环建议
比较有效的做法是把未授权访问治理前移到上线流程，而不是靠季度扫描兜底。
在 CI/CD 中检查配置文件，禁止生产环境开启调试端点。
Ingress 或 Nginx 配置变更进入代码评审，重点看认证覆盖范围。
资产系统定期同步注册中心、Kubernetes、云资源数据。
安全扫描结果关联负责人和服务生命周期，避免无人认领。
对管理后台、调试接口、指标接口建立统一命名和访问规范。
总结
未授权访问看起来是基础问题，但在真实环境里经常反复出现。根因通常不是某个开发少写了登录判断，而是资产不清、边界假设过时、网关策略不一致、临时服务长期存在。
排查这类问题时，建议从资产面开始，结合路径识别、日志验证和风险分级，最后落到访问控制、凭据轮换和上线基线。这样处理一次，后续同类问题才会明显减少。
内网不是天然可信区。任何能返回敏感运行信息、配置内容或管理能力的 Web 服务，都应该有明确的认证、授权和访问边界。