Kali 渗透工具实战：用 Nmap 与 curl 验证 Web 管理入口暴露并保留证据

发布于7小时前7小时

背景：端口开放不等于漏洞成立

在授权内网测试中，经常遇到这样的资产：443 是业务入口，8443 疑似管理后台，8080 则不清楚是应用端口还是反向代理。直接把“端口开放”写成漏洞，结论通常站不住；启动大范围脚本扫描，又容易给业务带来不必要的压力。

这里使用 Kali 上的 Nmap、curl 和 OpenSSL，完成一条可复现的验证链：确认监听服务、正确访问 HTTPS 虚拟主机、验证匿名访问边界，再通过服务端日志核对请求。全程不进行口令猜测、目录爆破、写操作或漏洞利用。

示例地址 192.0.2.10 是文档保留地址，audit.example.test 是示例域名。执行前替换成授权实验环境中的地址和域名，并确认测试时间、来源 IP、端口与允许访问的路径。

一、安装工具并记录环境

优先使用 Kali 官方软件仓库，不要从不明站点下载所谓“增强版扫描器”。以下命令假定系统已经配置正确的官方仓库；如果安装失败，先排查源配置、DNS、系统时间及签名错误，不要通过关闭签名校验解决。

sudo apt update
sudo apt install --no-install-recommends nmap curl openssl ca-certificates

umask 077
OUT="audit-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"

{
  date -u +%FT%TZ
  nmap --version
  curl --version
  openssl version
} > "$OUT/tool-versions.txt"

ip route get 192.0.2.10 > "$OUT/route.txt"

后续命令在同一个 Bash 会话执行，复用 OUT 变量。route.txt 记录的是本机选路与源地址，不一定等于目标看到的来源：经过 NAT、VPN 或代理时，应以边界设备和目标日志为准。工具版本同样值得保存，不同 TLS 后端和 Nmap 指纹库可能影响结果。

二、用 Nmap 定位服务，不先跑漏洞脚本

nmap -sT -sV --version-light -Pn -n \
  -p 80,443,8080,8443 \
  --max-rate 10 --max-retries 1 --host-timeout 180s \
  --reason -oA "$OUT/services" \
  192.0.2.10

-sT 使用 TCP connect 扫描，不依赖原始套接字权限，但会建立完整连接，也可能产生应用侧日志。
-sV --version-light 进行轻量服务识别。它仍会发送应用层探测，并不等于只发 TCP 握手。
-Pn 跳过主机发现，适合目标已确认且 ICMP 被过滤的情况；它不会让未授权目标变成可测目标。
--max-rate 10 用于限制扫描探测包发送速率，不是所有服务识别连接和后续 HTTP 请求的统一限流器。
--max-retries 1 减少重试，但会增加丢包环境中的漏报可能。超时或 filtered 应在约定窗口内复核，不能直接认定服务不存在。
-oA 同时保存普通文本、XML 和 grepable 输出，方便复核与资产比对。

本流程不使用 -A 或批量 NSE 漏洞脚本。先明确服务类型和授权边界，再决定是否需要针对性验证。Nmap 给出的产品名称与版本只是指纹判断，不能单凭它认定某个 CVE 已经成立。

三、排查 HTTPS 访问异常：先分清 SNI、证书与 Host

直接访问 404。原因往往不是目标不可达，而是客户端没有使用正确的域名。HTTPS 站点选择涉及 TLS 阶段的 SNI，以及 HTTP 阶段的 Host；只增加一个 Host 请求头不能可靠解决证书选择问题。

openssl s_client \
  -connect 192.0.2.10:8443 \
  -servername audit.example.test \
  -verify_hostname audit.example.test \
  -CAfile ./lab-root-ca.pem \
  -verify_return_error \
  < /dev/null > "$OUT/tls.txt" 2>&1

lab-root-ca.pem 应通过可信渠道取得。检查输出中的证书链、域名匹配和验证结果；服务器证书过期、缺少中间证书、本机时间错误，都可能造成失败。不要把 curl -k 当成长期解决方案，否则会把证书信任问题掩盖掉。

四、用 curl 验证匿名访问边界

下面只请求资产负责人确认可以读取的三个路径。示例不跟随重定向、不提交表单、不携带登录态，也不保存响应正文；如果这些路径不在授权清单中，应先替换或删除。

TEST_ID="audit-$(date -u +%Y%m%dT%H%M%SZ)"
printf '%s\n' "$TEST_ID" > "$OUT/test-id.txt"

for path in / /admin/ /api/me; do
  case "$path" in
    /) name=root ;;
    /admin/) name=admin ;;
    /api/me) name=api-me ;;
  esac

  curl --silent --show-error --noproxy '*' \
    --connect-timeout 5 --max-time 15 \
    --resolve audit.example.test:8443:192.0.2.10 \
    --cacert ./lab-root-ca.pem \
    -H "X-Audit-ID: $TEST_ID-$name" \
    --dump-header "$OUT/$name.headers" \
    --output /dev/null \
    --write-out 'http=%{http_code} remote=%{remote_ip} tls_verify=%{ssl_verify_result} total=%{time_total}\n' \
    " \
    > "$OUT/$name.metrics" 2> "$OUT/$name.stderr"

  rc=$?
  printf 'curl_exit=%s\n' "$rc" >> "$OUT/$name.metrics"
  sleep 1
done

--resolve 将指定域名和端口固定到测试 IP，同时保留正确的 SNI、Host 和证书域名校验。--noproxy '*' 避免环境变量中的代理意外改变链路；如果授权要求通过指定代理访问，就应改用明确的代理配置并记录出口，不能直接照搬这一项。

这里使用 GET 而不是 HEAD，因为有些应用对两者实现不同。GET 也不保证业务完全无副作用，因此路径仍需预先确认。没有加入 -L，是为了避免跳转到未授权域名，或掩盖入口最初返回的状态。

五、如何判断结果，避免误报

curl_exit=0 只说明请求传输完成，不代表鉴权正常。curl 默认不会因为 HTTP 403 或 500 就返回非零退出码。
http=000 不是 HTTP 状态码，应结合 stderr 排查连接、TLS、超时等错误。
302 需要检查响应头中的 Location。跳转登录页只能证明该路径发生了跳转，不能证明所有后台 API 都受保护。
401/403 表示该请求被拒绝，但不能据此推出整个管理面权限边界正确。
200 可能只是登录页、单页应用外壳，甚至是带业务错误码的 JSON，不等于匿名越权成功。

若需要确认 200 响应的业务含义，应在明确的数据读取授权下，对单个端点进行最小必要检查。优先使用专门准备的无敏感数据测试对象；不要为了“证明影响”批量获取真实用户资料。响应头也可能包含 Set-Cookie，证据文件同样需要按敏感资料管理。

六、用服务端日志确认请求落点

在有运维协作权限时，可由管理员在 Nginx 的 http 上下文定义专用日志格式，并在被测 server 中启用。不要仅凭客户端返回结果判断请求一定到达了预期应用。

# 放在 http 上下文
log_format audit_json escape=json
  '{"time":"$time_iso8601","remote":"$remote_addr",'
  '"host":"$host","method":"$request_method","uri":"$uri",'
  '"status":$status,"upstream":"$upstream_addr",'
  '"upstream_status":"$upstream_status",'
  '"audit_id":"$http_x_audit_id"}';

# 放在被测 server 上下文
access_log /var/log/nginx/audit_access.log audit_json;

由管理员执行 nginx -t，确认配置通过后再按维护流程重载。测试完成后，用 test-id.txt 中的值关联访问日志，再结合应用认证日志核对：请求是否命中预期虚拟主机、是否转发到上游、拒绝发生在哪一层。

X-Audit-ID 是客户端可控的关联标签，不是身份凭据。这里记录 $uri 而非完整查询串，也不记录 Cookie、Authorization 或请求正文，减少日志泄露风险。如果前面还有代理，$remote_addr 可能只是代理地址；真实来源应通过经过正确配置的可信代理链确认，不能无条件信任 X-Forwarded-For。

七、风险收敛与修复复测

管理端口不需要对业务网开放时，应通过监听地址、防火墙、安全组或管理 VPN 收敛；仅隐藏入口路径不构成访问控制。
匿名请求确实读取了受保护数据时，应修复服务端认证与对象级授权，不能只增加前端登录跳转。
若业务入口有认证而直连应用端口没有，应同时收敛后端端口的网络暴露，并检查应用自身的认证边界。
修复证书链与域名配置，确保正常访问不依赖跳过校验；复测时沿用原来的 SNI、域名和目标 IP。
复测不仅要看到客户端被拒绝，还要确认日志中的处理层符合设计，避免把网络故障误认为权限修复。

总结

这套流程的重点不是扫描得更广，而是让渗透工具输出形成可核验的证据链：Nmap 确认服务，OpenSSL 排查 TLS，curl 验证明确的访问边界，日志确认请求落点。交付时保留工具版本、命令参数、测试时间、来源与出口、响应头及关联日志；“发现入口”“疑似风险”和“已验证越权”应分开描述。

7小时前7小时

这类验证建议分成“端口可达、HTTP 行为、证据固化”三步做，前提是目标在明确授权范围内。不要直接跑全套 NSE，管理入口确认通常用低影响探测就够了。

先记录时间、测试源地址和目标范围，再检查常见管理端口：

date -u +"%Y-%m-%dT%H:%M:%SZ"
ip route get <TARGET_IP>

sudo nmap -Pn -sT -sV --version-light \
  -p 80,443,8080,8443,9090 \
  --script http-title,http-headers \
  --reason -oA evidence/web-admin <TARGET_IP>

-oA 会同时保留普通文本、XML 和 grepable 结果，后续复核比截图可靠。若站点依赖 Host 头，直接扫 IP 可能只看到默认页，需要按实际域名验证：

curl --silent --show-error --location --max-redirs 5 \
  --connect-timeout 5 --max-time 15 \
  --resolve admin.example.internal:443:<TARGET_IP> \
  --dump-header evidence/headers.txt \
  --output evidence/body.html \
  --write-out 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\nurl=%{url_effective}\ncontent_type=%{content_type}\n' \

建议同时保留 TLS 证书信息，用于证明访问的确落到了对应资产，而不是中间代理或错误虚拟主机：

openssl s_client -connect <TARGET_IP>:443 \
  -servername admin.example.internal </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256 \
  > evidence/certificate.txt

证据目录最后生成哈希，并记录工具版本：

nmap --version > evidence/tool-versions.txt
curl --version >> evidence/tool-versions.txt
find evidence -type f -print0 | sort -z | xargs -0 sha256sum \
  > evidence/SHA256SUMS

判定“暴露”时不要只看出现登录页，至少还要说明：测试源所在网络、是否未经 VPN/堡垒机即可访问、最终状态码和跳转链、服务监听地址，以及边界 ACL/WAF 是否生效。若返回 401/403，说明入口仍然可达，只是有应用层限制，不能直接写成“未暴露”。

另外注意脱敏：响应头里的 Set-Cookie、CSRF Token、内部主机名和页面中的账号信息不应原样放进报告。验证到登录页或明确的管理产品标识即可，不必尝试口令、默认凭据或爆破。

登录