📚 课程目录第4章网络服务密码资产发现基础

4. 网络服务密码资产发现基础

密码资产发现的第一步，不是直接去翻代码或查证书，而是先回答一个更基础的问题：网络里到底有哪些服务在对外提供密码能力？这些服务用的是哪种协议、哪种算法、密钥长度多少、证书或策略配置成什么样？端口扫描、服务识别与协议探测，正是把"看不见的密码使用"变成"可枚举的资产条目"的三级递进手段。本节围绕 HTTPS、SSH、IPsec 三类典型服务，讲清楚每一步该看什么、怎么判断、结果如何落成资产记录。

从端口到服务：先建立候选面

端口扫描的作用是缩小范围，而不是直接下结论。常见密码相关服务的默认端口分布有较强规律：HTTPS 通常在 443/TCP，HTTP 在 80/TCP；SSH 在 22/TCP；IPsec 的 IKE 协商使用 500/UDP，NAT-T 场景下使用 4500/UDP；此外 8443、9443 等常作为管理面 HTTPS 的替代端口，2222 常被用作 SSH 改端口。扫描时建议采用"常用端口 + 全端口抽样"的组合：先对 1–1024 及上述高频端口做 TCP SYN 扫描，再对全端口做一次快速探测，避免只盯默认端口而漏掉改端口部署的服务。

# 示例：常用端口快速扫描（示例参数，非实测结果）
nmap -sS -Pn -p 22,80,443,500,4500,8443,9443,2222 10.20.30.0/24

# 示例：全端口抽样，仅关注开放状态
nmap -sS -Pn -p- --min-rate 2000 10.20.30.15

扫描结果只说明"端口开放"，开放不等于"密码服务在用"。例如 443 端口可能跑的是普通 Web 应用而非 TLS；500/UDP 开放也可能只是防火墙放行。因此必须进入第二步：服务识别。

服务识别：确认协议与实现

服务识别通过发送协议特征探测包并比对响应指纹，判断端口背后真实的协议与软件版本。对密码资产而言，重点抓三类信息：协议类型（TLS/SSH/IKE）、软件与版本（OpenSSH 8.9、nginx 1.24、strongSwan 5.9 等）、以及协议特有的能力字段。版本信息直接关联算法支持范围——例如较老的 OpenSSH 可能仍启用 ssh-rsa（SHA-1）主机密钥算法，而新版本默认已禁用。

# 示例：服务与版本识别
nmap -sV -Pn -p 22,443,500 10.20.30.15

# 示例输出片段（合理假设）
# 22/tcp  open  ssh     OpenSSH 8.9p1 Ubuntu
# 443/tcp open  ssl/http nginx 1.24.0
# 500/udp open  isakmp  strongSwan

识别到协议后，才进入真正决定"密码资产画像"的协议探测环节。三类服务的探测重点各不相同。

HTTPS：从证书与握手枚举算法

HTTPS 的密码资产集中在 TLS 握手参数与证书上。探测时应获取：支持的 TLS 版本（1.2/1.3）、密钥交换组（如 X25519、secp256r1）、对称套件（如 TLS_AES_128_GCM_SHA256）、签名算法，以及服务器证书的公钥算法与长度（RSA 2048、ECDSA P-256 等）。这些字段共同决定了该服务当前的密码强度与合规状态。

# 示例：枚举 TLS 版本与套件
nmap --script ssl-enum-ciphers -p 443 10.20.30.15

# 示例：查看证书公钥算法与有效期
openssl s_client -connect 10.20.30.15:443 -servername example.local </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -E "Public Key Algorithm|Public-Key|Signature Algorithm|Not After"

判读要点：若仍协商出 TLS 1.0/1.1，或套件中出现 CBC 模式与 SHA-1 签名，应标记为弱配置；证书公钥若为 RSA 1024，则属于需要优先整改的资产。把这些字段逐项填入资产记录，HTTPS 条目才算完整。

SSH：抓主机密钥与算法协商

SSH 的密码资产体现在主机密钥算法、密钥交换算法、加密算法与 MAC 算法四组协商列表上。探测时读取服务端 banner 与算法列表，即可判断是否仍支持 ssh-rsa（SHA-1）、diffie-hellman-group1-sha1 等已被淘汰的算法。

# 示例：读取 SSH 主机密钥与算法列表
ssh-keyscan -T 5 -t rsa,ecdsa,ed25519 10.20.30.15

# 示例：查看协商算法（详细模式）
ssh -vv -o BatchMode=yes -o ConnectTimeout=5 probe@10.20.30.15 2>&1 \
  | grep -E "peer server KEXINIT|host key algorithms|ciphers"

若主机密钥列表中仍出现 ssh-rsa 且无 ed25519，说明该资产的主机身份认证依赖 SHA-1 签名，属于算法清单中需要标注"待迁移"的条目。注意 ssh-keyscan 只读取公钥，不涉及登录，适合批量资产发现。

IPsec：探测 IKE 协商能力

IPsec 的密码资产不在 TCP 端口上，而在 IKE 协商中。IKEv1 与 IKEv2 使用不同的载荷结构，探测时需确认：对端支持的 IKE 版本、加密算法（如 AES-CBC-256）、完整性算法（SHA-256/SHA-1）、DH 组（group 14/19/20）以及认证方式（预共享密钥或证书）。

# 示例：IKE 服务探测（工具与参数为示例）
ike-scan -M --showbackoff 10.20.30.15

# 示例：指定 IKEv2 探测
ike-scan -2 --trans=5,2,1,2 10.20.30.15

判读要点：若响应显示仅支持 DH group 2（1024 位）或完整性算法仅 SHA-1，则该 IPsec 网关在算法清单中应标记为弱配置；若同时支持 group 19/20 与 SHA-256 以上，则可归入合规候选。IKE 探测对防火墙策略敏感，未响应不代表服务不存在，需结合配置面或管理端信息交叉确认。

把探测结果落成资产记录

三类服务的探测输出格式不同，但最终要收敛到同一张资产表，才能支撑后续的算法清单构建。建议每条记录至少包含：资产标识（IP 与端口）、协议类型、软件与版本、关键算法字段、密钥长度、弱配置标记、探测时间与探测方式。以本节示例为例，一台主机可能同时产生三条记录：443 端口 nginx 1.24 支持 TLS 1.3 与 X25519，标记为合规候选；22 端口 OpenSSH 8.9 仍开放 ssh-rsa，标记待迁移；500/UDP strongSwan 仅支持 DH group 2，标记弱配置。同一 IP 下不同服务的结论可以完全不同，这正是按服务而非按主机建账的原因。

探测时优先使用只读、不触发登录或认证的方式：ssh-keyscan 只取公钥，openssl s_client 只做握手，ike-scan 只发协商探测。避免使用会尝试口令登录的脚本，以免触发账户锁定或告警。

端口未响应不等于服务不存在。IPsec 的 500/UDP 常被防火墙过滤，SSH 可能仅对管理网段开放。对未响应目标应结合配置管理库、CMDB 或管理端信息交叉确认，并在资产记录中注明"探测受限"，而不是直接判定为无密码资产。

完成一轮发现后，应对结果做一次一致性校验：同一服务多次探测的算法列表是否稳定、证书有效期是否临近、版本号是否与厂商公告匹配。校验通过后，这批记录才可作为算法清单的输入，进入下一阶段的算法归类与风险分级。