发布于21小时前21小时 背景在授权内网渗透中，测试机通常无法直接访问服务器网段，只能登录一台受控跳板机。此时不建议在跳板机上随意安装扫描器，更稳妥的做法是在 Kali 上通过 SSH 动态转发建立 SOCKS 通道，再使用 Nmap 的 TCP Connect 模式完成低速、可审计的服务验证。本文场景假设已取得书面授权：Kali 地址为 192.0.2.20，SSH 跳板机为 192.0.2.10，允许测试的目标仅为 10.20.30.11、10.20.30.12 和 10.20.30.15。示例不包含口令猜测、漏洞利用和持久化操作。通过 SOCKS 扫描时，目标看到的连接来源通常是跳板机，而不是 Kali。测试前应将跳板机地址加入临时扫描白名单，并明确时间窗口和速率上限。工具安装与环境确认Kali 官方仓库中的 nmap、proxychains4 和 OpenSSH 客户端已经足够。尽量使用 apt 安装，不要从不明网盘下载二进制文件。sudo apt update sudo apt install --yes nmap proxychains4 openssh-client nmap --version proxychains4 -h 2>&1 | head ssh -V # 保存已安装软件版本，便于报告复现 dpkg-query -W nmap proxychains4 openssh-client | tee tool-versions.txt sha256sum tool-versions.txt如果必须离线传递 deb 包，可在联网的同版本 Kali 上执行 apt download，并同时传递 SHA-256 清单。不要直接混用不同 Debian/Kali 发行版本的软件包，否则容易出现库依赖和行为差异。问题定位：先确认链路，而不是直接全网扫描常见误判包括：SSH 动态转发没有成功、ProxyChains 配置仍指向默认端口、目标网段被跳板机防火墙阻断，以及把 SOCKS 环境下的主机发现失败误认为目标离线。SSH 只负责建立 TCP 转发，不会自动提供 ICMP、ARP 或二层发现能力。Nmap 的 SYN 扫描依赖原始套接字，不能直接穿过普通 SOCKS 代理。UDP 扫描、操作系统识别和大部分 traceroute 功能不适合经此链路执行。经 SOCKS 使用 Nmap 时，应采用 -sT，并根据已批准的目标使用 -Pn。-Pn 只表示跳过主机发现，不代表目标一定在线；最终结论应结合端口状态和服务响应。操作步骤一：建立仅监听本机的 SOCKS 通道使用专用审计账号登录跳板机。-N 表示不执行远端命令，-D 建立动态转发，ExitOnForwardFailure 可避免转发失败后 SSH 仍保持一个看似正常的会话。ssh -N -D 127.0.0.1:1080 \ -o ExitOnForwardFailure=yes \ -o ServerAliveInterval=30 \ -o ServerAliveCountMax=3 \ [email protected]另开终端检查监听地址。必须看到 127.0.0.1:1080，而不是 0.0.0.0:1080，后者可能把代理端口暴露给同网段其他主机。ss -lntp | grep ':1080' ssh -G [email protected] | grep -E 'hostname|user|proxy|forward'操作步骤二：为本次任务建立独立 ProxyChains 配置不建议直接修改全局 /etc/proxychains4.conf。复制一份任务配置，便于留档和避免影响其他终端。mkdir -p case-2025-001/{config,logs,output} cp /etc/proxychains4.conf case-2025-001/config/proxychains.conf sed -i 's/^dynamic_chain/# dynamic_chain/' case-2025-001/config/proxychains.conf sed -i 's/^#strict_chain/strict_chain/' case-2025-001/config/proxychains.conf sed -i 's/^socks4[[:space:]]\+127.0.0.1[[:space:]]\+9050/# &/' case-2025-001/config/proxychains.conf cat >> case-2025-001/config/proxychains.conf <<'EOF' socks5 127.0.0.1 1080 EOF grep -E '^(strict_chain|proxy_dns|socks)' case-2025-001/config/proxychains.confstrict_chain 可以确保流量必须经过指定代理；proxy_dns 可减少域名查询从 Kali 本地网络泄漏。不过本次范围使用 IP 地址，扫描命令同时加 -n，避免不必要的反向解析。操作步骤三：建立明确的授权目标清单不要把整个 RFC1918 网段直接交给扫描器。将审批单中的目标逐行写入文件，并在执行前复核。cat > case-2025-001/config/scope.txt <<'EOF' 10.20.30.11 10.20.30.12 10.20.30.15 EOF nl -ba case-2025-001/config/scope.txt sha256sum case-2025-001/config/scope.txt | tee case-2025-001/config/scope.sha256如果范围以网段形式下发，建议先让资产负责人提供有效地址清单。必须扫描网段时，应通过防火墙出口规则再次限制跳板机只能访问获批网段，不能只依赖操作人员输入正确命令。操作步骤四：小范围验证代理链路先选择一个已知开放的管理端口做单点验证，确认路径正常后再扩大端口范围。ProxyChains 输出出现 chain OK 只代表代理连接建立成功，仍需关注 Nmap 返回的 open、closed 或 filtered。proxychains4 -q -f case-2025-001/config/proxychains.conf \ nmap -sT -Pn -n -p 22 --reason \ --connect-timeout 3s --max-retries 1 \ 10.20.30.11状态通常含义后续动作open完成 TCP 三次握手，服务接受连接执行最小化服务识别closed收到 RST，主机通常可达但端口未监听记录即可，不应反复重试filtered超时或收到过滤类响应检查跳板机路由、防火墙和访问控制操作步骤五：低速枚举常见服务通过 SOCKS 执行 -sT 时，每个探测都建立完整 TCP 连接，服务端日志量通常高于半开扫描。因此应限制端口、并发和重试次数，不建议直接使用 -p-、-T5。UTC=$(date -u +%Y%m%dT%H%M%SZ) script -q -f case-2025-001/logs/session-$UTC.txt -c \ 'proxychains4 -q -f case-2025-001/config/proxychains.conf \ nmap -sT -Pn -n \ -p 22,80,443,445,3389,5432,6379,8080,8443 \ --reason --version-light \ --max-rate 20 --max-retries 1 --host-timeout 90s \ -iL case-2025-001/config/scope.txt \ -oA case-2025-001/output/service-check' sha256sum case-2025-001/output/service-check.* \ case-2025-001/logs/session-$UTC.txt \ | tee case-2025-001/output/evidence.sha256-oA 会同时生成普通文本、XML 和 grepable 格式。报告取证优先保留 XML，因为其中包含扫描参数、时间、端口原因和服务指纹；普通文本适合人工快速阅读。漏洞验证：只使用非破坏性脚本确认配置问题发现开放端口后，不要立即运行 vuln 脚本集合。先针对具体服务使用 banner、证书和安全配置类脚本，避免触发登录、写入或高负载行为。proxychains4 -q -f case-2025-001/config/proxychains.conf \ nmap -sT -Pn -n -p 22,80,443,445 \ --script banner,http-title,http-headers,ssl-cert,ssl-enum-ciphers,ssh-hostkey,smb2-security-mode \ --script-timeout 20s --max-retries 1 --max-rate 10 \ -iL case-2025-001/config/scope.txt \ -oA case-2025-001/output/config-validation脚本结果需要人工复核。例如 ssl-enum-ciphers 报告支持旧协议，只能说明该监听端口接受相应握手；还应确认前端负载均衡、SNI 和实际业务域名。HTTP Host 不正确时，默认站点返回的标题和响应头也可能与目标业务无关。对于 HTTPS 虚拟主机，可在已知业务域名的前提下单独验证 SNI。域名应来自授权资产清单，不能通过撞库式枚举获取。proxychains4 -q -f case-2025-001/config/proxychains.conf \ curl --socks5-hostname 127.0.0.1:1080 \ --connect-timeout 5 --max-time 15 \ --resolve app.internal.example:443:10.20.30.12 \ -D case-2025-001/output/app-headers.txt \ -o /dev/null 端：保存终端会话、Nmap XML、任务配置和 SHA-256 清单。跳板机端：Debian 系通常检查 /var/log/auth.log，也可使用 journalctl -u ssh 核对登录和断开时间。目标端：核对主机防火墙、Web 访问日志、SSH 日志及 Windows 安全日志。由于扫描经过 SSH 隧道，目标侧源地址通常记录为跳板机内网地址。时间基准：各节点应同步 NTP，并在报告中明确使用 UTC 或本地时区。# 在跳板机上由管理员执行，按 UTC 时间窗口核对 SSH 会话 sudo journalctl -u ssh \ --since '2025-03-01 02:00:00 UTC' \ --until '2025-03-01 03:00:00 UTC' # 检查输出是否被修改 sha256sum -c case-2025-001/output/evidence.sha256常见故障排查现象可能原因排查方法ProxyChains 提示 socket errorSSH 隧道退出或端口配置错误用 ss 检查 127.0.0.1:1080，并查看 SSH 终端错误所有端口均 filtered跳板机没有目标路由，或出口 ACL 拒绝由跳板机管理员检查 ip route、nftables 和边界防火墙日志扫描非常慢目标丢包、重试过多或脚本等待超时缩小端口范围，设置 max-retries、host-timeout 和 script-timeout服务版本结果不稳定代理延迟、负载均衡或服务主动断开使用 version-light，并通过协议级客户端做一次定向复核域名解析到错误地址本地 DNS 泄漏或内外网分裂解析使用 -n、proxy_dns，或按资产清单使用 curl --resolve权限边界与跳板机加固动态转发本质上给测试人员提供了从跳板机发起任意 TCP 连接的能力，不能仅靠口头约束。建议使用专用短期账号、密钥认证、来源地址限制和跳板机出口 ACL。测试结束后立即撤销密钥和临时规则。# sshd_config 中针对专用账号的示例基线 Match User auditor AuthenticationMethods publickey AllowTcpForwarding local GatewayPorts no X11Forwarding no PermitTTY no MaxSessions 1 AllowTcpForwarding local 仍然允许该账号建立动态转发，并不会限制 SOCKS 最终访问的目标。真正的目标范围应由跳板机 nftables、云安全组或上游防火墙实施白名单。修改 sshd_config 前先执行 sshd -t 校验，并保持现有管理会话，避免配置错误导致失联。风险与修复建议若发现管理端口对普通办公网开放，应通过主机防火墙或网络 ACL 限制到运维网和指定跳板机。若 SSH 暴露弱算法，应升级 OpenSSH，并在兼容性验证后禁用旧版密钥交换、CBC 和 SHA-1 类算法。若 TLS 支持过时协议或弱密码套件，应在实际终止 TLS 的负载均衡器、反向代理或应用服务器上修复，不能只修改后端节点。若 SMB 签名未强制，应评估旧系统兼容性后，通过域策略逐步启用客户端和服务器端签名要求。若数据库、Redis 等中间件直接暴露在跨区网络，应同时落实监听地址、网络隔离和应用层认证，避免只依赖端口隐藏。跳板机应记录 SSH 登录、配置变更和出口连接日志，并为授权扫描设置独立时间窗口，避免与真实入侵告警混淆。总结SSH SOCKS、ProxyChains 和 Nmap 的组合适合在无法直接路由到目标网段时进行受控的 TCP 服务验证。关键不是扩大扫描能力，而是明确其限制：只能可靠承载 TCP Connect 类探测，目标侧看到的是跳板机地址，且每个探测都可能形成完整连接和日志。实际执行时应坚持精确目标清单、小端口集、低速率、原始结果留存和双侧日志核对。发现问题后再使用协议级工具做最小化复核，比直接运行大范围漏洞脚本更容易控制风险，也更便于给出可验证的修复建议。 服务器、云资产与权限边界梳理示意 工具配置、参数调优与结果校验示意
21小时前21小时 这里有个容易踩坑的点：SSH -D 提供的是 SOCKS TCP 转发，不能透传 Nmap 的 SYN、UDP、ICMP 或 ARP 探测。因此不要用默认扫描方式，建议明确指定 -sT -Pn -n，让 Nmap 走系统 connect()，再由 proxychains 接管。 先建立只监听本机的 SOCKS5： ssh -N \ -D 127.0.0.1:1080 \ -o ExitOnForwardFailure=yes \ -o ServerAliveInterval=30 \ -o ServerAliveCountMax=3 \ user@jump-host /etc/proxychains4.conf 可做最小配置： strict_chain proxy_dns tcp_connect_time_out 8000 tcp_read_time_out 15000 [ProxyList] socks5 127.0.0.1 1080 建议先验证目标端口确实能从跳板侧访问，而不是直接扫整个网段： proxychains4 -q nc -vz 10.20.30.10 443 proxychains4 -q curl --connect-timeout 5 \ 确认链路正常后再用 Nmap 做 TCP Connect 扫描： proxychains4 -q nmap \ -sT -Pn -n --open \ -T3 --max-retries 2 --host-timeout 2m \ -p 22,80,443,445,3389 \ 10.20.30.10 扩大到网段时最好先限定业务相关端口，避免 SOCKS 链路因大量并发连接变得不稳定： proxychains4 -q nmap \ -sT -Pn -n --open \ --max-rate 30 --max-retries 1 \ -p 22,80,443,445,3389 \ 10.20.30.0/24 几个结果解释上的注意点： -Pn 是必要的，因为主机发现阶段的 ICMP/SYN 探测通常无法通过 SOCKS；但这也意味着每个地址都会进入端口探测。 -n 可避免本地 DNS 查询泄漏，也减少无意义的解析等待；若目标依赖内网域名，先单独确认 DNS 解析路径。 -sS、-sU、OS 指纹识别和部分依赖原始报文的 NSE 脚本不适用于这种链路。 超时不一定代表端口被过滤，也可能是跳板路由、防火墙策略、SOCKS 握手超时或 SSH 通道拥塞。最好在跳板机上用 nc -vz 交叉验证。 不要假设 Nmap 的 --proxies 能代理完整扫描流程；通过 SOCKS 做基础端口验证时，proxychains 配合 -sT 更直观。 如果目的是持续、完整地验证较大内网暴露面，与其长期套 SOCKS，不如在授权范围内使用 SSH 路由转发或在跳板侧直接运行扫描器，再把结果文件传回。这样对 UDP、主机发现和指纹识别的支持会更可靠。
创建帐户或登录后发表意见