Kali 渗透工具实战：通过 SSH 动态代理使用 Proxychains 与 Nmap 验证内网服务

背景

在授权渗透测试中，测试机往往无法直接访问目标内网，只能登录一台受控跳板机。例如 Kali 位于外部测试区，跳板机同时连接管理网与目标网，目标范围为 10.20.30.0/24。此时可以使用 OpenSSH 建立 SOCKS5 动态代理，再让 Proxychains 接管 Nmap 的 TCP 连接。

以下操作应限定在书面授权的目标、端口和测试时间内。动态代理会扩大 Kali 的网络可达范围，不能把“隧道建立成功”理解为获得整个内网的测试许可。

工具安装与版本确认

Kali 中优先使用官方 APT 仓库安装，不建议从不明网盘下载修改过的二进制文件。安装前先检查软件来源和候选版本。

sudo apt update
apt-cache policy proxychains4 nmap openssh-client
sudo apt install proxychains4 nmap openssh-client

proxychains4 --version
nmap --version
ssh -V

如果测试环境要求留存工具基线，可同时记录包版本与文件校验值。

dpkg-query -W proxychains4 nmap openssh-client
sha256sum /usr/bin/proxychains4 /usr/bin/nmap /usr/bin/ssh

问题定位

建立代理前先确认 Kali 没有直接路由，避免误判扫描流量实际经过的路径。

ip route get 10.20.30.15
traceroute -n 10.20.30.15
nc -vz -w 3 10.20.30.15 443

常见现象是目标不可达或连接超时，但跳板机可以访问目标端口。应由跳板机管理员在其本机验证路由与防火墙策略，而不是直接在跳板机上进行无范围限制的扫描。

建立 SSH 动态代理

以下命令仅监听 Kali 本机的 127.0.0.1:1080，不对局域网开放代理端口。ExitOnForwardFailure 可以避免端口绑定失败后 SSH 仍保持连接。

mkdir -p logs
script -af logs/tunnel-session.log

ssh -vv -N \
  -D 127.0.0.1:1080 \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  [email protected]

# 另开终端检查监听状态
ss -lntp | grep 1080

如果日志出现 administratively prohibited，通常不是 Proxychains 故障，而是服务端禁用了 TCP 转发，或者 PermitOpen 没有放行目标。不要通过更换工具绕过该限制，应由跳板机管理员按授权范围调整。

配置 Proxychains

建议为每次项目创建独立配置文件，不直接修改系统全局配置。strict_chain 可以确保连接必须经过指定代理；proxy_dns 用于避免域名解析泄漏到 Kali 所在网络。

cat > proxychains-project.conf <<'EOF'
strict_chain
proxy_dns
tcp_connect_time_out 8000
tcp_read_time_out 15000

[ProxyList]
socks5 127.0.0.1 1080
EOF

先用单个已知服务验证链路。若目标使用虚拟主机，应保留正确的 Host 头，而不是仅访问 IP。

proxychains4 -q -f ./proxychains-project.conf \
  curl -I --connect-timeout 5 

proxychains4 -q -f ./proxychains-project.conf \
  curl -kI --connect-timeout 5 \
  -H 'Host: app.test.internal'  Nmap TCP 验证
Proxychains 只能接管基于 connect() 的 TCP 连接，因此 Nmap 必须使用 -sT。SYN 扫描、UDP 扫描、ICMP 探测和大部分原始报文功能不能通过普通 SOCKS5 隧道转发。由于主机发现也可能绕过代理，需要使用 -Pn；使用 IP 目标时配合 -n 禁止额外 DNS 查询。
cat > approved_targets.txt <<'EOF'
10.20.30.15
10.20.30.20
EOF

proxychains4 -q -f ./proxychains-project.conf \
  nmap -sT -Pn -n \
  --max-retries 2 \
  --host-timeout 60s \
  -p 22,80,443,445,3389,8080 \
  -iL approved_targets.txt \
  -oA logs/authorized-tcp-check
不建议直接通过 SOCKS 对整个网段执行全端口扫描。每个 TCP 连接都要经过 SSH 通道，容易造成超时、日志噪声和跳板机资源占用。实际项目中应先根据资产清单检查少量批准端口，再对确认开放的服务进行轻量识别。
proxychains4 -q -f ./proxychains-project.conf \
  nmap -sT -Pn -n -sV --version-light \
  --script banner,http-title,http-headers \
  -p 80,443,8080 10.20.30.15 \
  -oA logs/service-validation-10.20.30.15
这里选用的脚本主要读取 Banner 和 HTTP 响应头，通常不会修改目标状态。执行其他 NSE 脚本前应查看脚本分类和源码，尤其避免未经确认运行 intrusive、brute、dos 类脚本。
常见故障排查
所有端口都显示 filtered：检查 SSH 的 -vv 输出、Proxychains 超时配置，以及跳板机到目标的路由和出口防火墙。
目标被 Nmap 判断为 down：确认是否遗漏 -Pn。SOCKS 不能代理 Nmap 默认的 ICMP 或原始报文主机发现。
使用 -sS 后没有正常结果：改为 -sT。-sS 依赖原始套接字，不会按预期经过 Proxychains。
IP 可以访问但域名失败：检查 proxy_dns，并确认目标域名是否只能由内网 DNS 解析。内网 DNS 服务器也必须在授权范围内。
结果间歇性超时：降低并发和端口数量，不要使用激进的 --min-rate。SSH 隧道延迟与直连扫描不同。
sudo 后代理失效：尽量不要使用 sudo。-sT 不要求原始套接字权限，普通用户运行也能避免环境和动态库加载行为变化。
跳板机权限边界
服务端应使用临时测试账号，并限制只能进行本地 TCP 转发。PermitOpen 不支持用它替代完整的网络访问控制，适合明确列出少量目标与端口；更大范围仍应由主机防火墙限制。
Match User tester
    AllowTcpForwarding local
    GatewayPorts no
    X11Forwarding no
    AllowAgentForwarding no
    PermitTTY no
    MaxSessions 0
    PermitOpen 10.20.30.15:443 10.20.30.15:8080 10.20.30.20:445
修改 sshd_config 后先执行 sshd -t 检查语法，再通过维护窗口重载服务，避免因配置错误中断现有管理连接。
sudo sshd -t
sudo systemctl reload ssh
sudo journalctl -u ssh.service --since '30 minutes ago'
日志留痕与结果复核
Nmap 的 -oA 会同时生成普通文本、XML 和 grepable 格式，便于复核与后续导入。测试记录至少应包含操作人、授权目标、跳板机、开始结束时间、工具版本和原始输出。SSH 服务端日志可用于确认账号、公钥指纹和登录时间，但不应把它当作完整的转发流量审计。
ls -lh logs/
sha256sum logs/* > logs/SHA256SUMS
nmap --resume logs/authorized-tcp-check.nmap
如果需要精确记录转发目的地址，应在跳板机出口防火墙、流量审计设备或集中日志平台侧完成，并限制日志访问权限，避免把目标地址、账号信息和响应内容散落在个人终端历史中。
风险与修复建议
测试结束后终止 SSH 隧道，确认 1080 端口不再监听，并撤销临时账号、公钥及 PermitOpen 配置。
禁止将 SOCKS 监听地址改为 0.0.0.0；否则同网段其他主机可能借用该代理访问目标内网。
跳板机应实施最小权限、来源 IP 限制、多因素认证、临时凭据和出口访问控制。
对验证到的服务分别处理：关闭非必要端口，限制管理接口来源，升级存在已知漏洞的版本，清理默认账号，并补充主机与网络侧审计。
复测时使用相同目标清单和端口集合，确认修复后端口状态、服务版本及访问控制均符合预期，而不是简单以“扫描不到”为结论。
总结
OpenSSH、Proxychains 与 Nmap 的组合适合在授权范围内验证少量内网 TCP 服务。关键点不是把扫描命令套上一层代理，而是理解 SOCKS 只能承载 TCP connect 连接，因此需要使用 -sT、-Pn 和明确的目标列表。同时应从跳板机权限、出口控制、日志留存和测试后清理四个方面约束隧道，保证验证过程可追溯、可复现，也不会突破既定权限边界。