威胁动态观察：边界设备失陷后的内网越权链路，如何授权验证与留痕

背景：从边界入口到内网权限边界

近期公开威胁通报中，反复出现一类值得关注的攻击链：攻击者先利用暴露在公网的 VPN、网关或远程管理服务取得入口，再借助过宽的网络访问策略、复用凭据或主机权限，向业务网段移动。风险往往不止于边界设备本身，而在于该设备能否访问不应触达的内网服务，以及相关访问是否能被审计发现。

下面以企业授权演练为例：测试范围仅包含一台测试用 VPN 出口主机、一个指定业务网段和明确批准的端口。目标是验证网络边界与日志闭环，不尝试利用漏洞、提取真实凭据或访问业务数据。

问题定位：先确认范围，再核对实际路径

• 将授权范围写清楚：出口主机地址、目标网段、允许验证的 TCP 端口、测试时间窗及联系人。未列入范围的地址不做探测。
• 在出口主机和目标服务器分别记录时间、源地址、测试账号及测试工单号，确认两端时钟已同步。
• 先检查路由和策略，再做单端口连通性验证。若边界策略显示拒绝，但目标侧仍收到连接，应优先排查其他网卡、静态路由、云安全组或中间代理。

技术分析：用最小验证确认权限边界

演练中常见的配置问题包括：VPN 地址池被加入通用办公网白名单；管理端口对整个内网开放；临时测试规则没有到期时间；目标主机的主机防火墙与网络防火墙规则不一致。验证时应区分“路由可达”和“服务可访问”：前者只说明存在网络路径，后者才说明特定端口策略允许连接。

以下命令应在已授权的测试出口主机上执行。把地址和端口替换为工单明确批准的值，不要对整个网段扫描。

# 记录演练上下文，便于与两端日志关联
 date -Is
 ip route get 10.20.30.15

# 仅验证获批的单个 TCP 端口；-z 不发送应用层请求，设置短超时
nc -vz -w 2 10.20.30.15 8443

# 查看本机到目标的连接状态；测试结束后再次采集作为留痕
ss -tn dst 10.20.30.15

目标 Linux 主机可按发行版检查认证与防火墙日志。不同系统的日志位置可能不同，journald 环境优先使用 journalctl：

# 按测试时间窗查看 SSH 认证事件；时间范围替换为实际演练窗口
journalctl -u ssh --since "2025-03-08 10:00:00" --until "2025-03-08 10:15:00"

# Debian/Ubuntu 常见路径：按出口主机地址检索
sudo grep -E "10\.20\.1\.25" /var/log/auth.log

# 查看 nftables 规则及计数器，确认对应链是否命中
sudo nft list ruleset -a

对于 Web 管理服务，应同时检查反向代理访问日志、应用认证日志和边界设备日志。仅凭一次 TCP 握手无法证明应用层认证是否有效；如需验证登录边界，应使用专用测试账号、无敏感权限的测试租户，并保留请求时间、响应状态码和审计事件编号，不在生产业务账号上试错。

操作步骤：从基线到复测

• 保存演练前策略快照，包括 VPN 地址池、路由、边界 ACL、主机防火墙和云安全组；导出时注意脱敏密钥与真实账号。
• 从批准的出口主机对指定目标和端口进行一次低频连接测试，同时在目标侧确认源地址、时间和结果。不要使用高并发或广泛端口扫描替代边界验证。
• 对预期应拒绝的连接，确认边界设备记录了拒绝事件，目标主机没有建立会话；对预期允许的管理流量，确认身份认证、授权结果和会话审计均可关联。
• 变更策略后重复同一组测试，并比较前后日志与规则命中计数。测试结束后撤销临时规则和测试账号，检查是否仍有遗留会话。

风险与修复建议

• 按业务关系收紧访问控制：将“VPN 用户可访问内网”拆分为用户组、目标主机和必要端口的精确规则，默认拒绝其余流量。
• 管理面与业务面分离。管理接口仅允许来自专用跳板机或运维网段，并启用多因素认证；禁止边界设备管理面直接暴露公网。
• 对临时规则设置负责人、工单编号和自动到期时间；在配置审查中检查过宽网段、重复规则和长期未命中的例外项。
• 集中保留 VPN 登录、策略变更、认证失败、目标主机防火墙拒绝及管理操作日志。统一时间源，并设置告警关联规则，例如同一 VPN 会话短时间访问多个非授权管理端口。
• 若发现异常访问，先保全边界与主机日志、确认会话和规则变更时间线，再按应急流程隔离受影响账号或主机。不要在未留存证据前清理日志或重置设备。

总结

当前值得跟踪的威胁趋势，不只是边界设备可能成为入口，更是入口后的权限边界是否足够细、访问是否可审计。授权演练应以明确范围、单点低影响验证和双端日志核对为核心；修复后用相同测试复测，才能证明策略确实收敛，而不是只在配置界面上看起来安全。

这类验证建议不要直接按“拿边界设备继续打内网”的方式做，重点应放在：确认边界身份是否能跨越信任边界、能访问到什么资源，以及证据能否在独立日志面闭环。边界设备本机日志在失陷后只能作为线索，不能作为唯一证据。

先把授权范围写成可执行矩阵：

• 明确源地址、测试账号、目标网段、允许协议和时间窗口。
• 禁止使用真实域管、备份管理员、虚拟化平台管理员凭据。
• 预设停止条件：发现生产凭据、触发账号锁定、目标异常重启或出现非预期写入时立即停止。
• 每一步使用唯一标识，例如在请求头、用户名或工单备注中加入 VAL-20250308-01，方便跨设备关联。

链路验证可以分三层做，避免一上来就执行高风险利用：

1. 网络层：从授权测试源验证边界管理区是否能到达域控、运维平台、备份网和虚拟化管理网。优先使用 TCP 握手验证，不做服务爆破。
2. 身份层：检查边界设备保存的 LDAP、RADIUS、SNMP、API、SSH 凭据是否被复用，以及这些账号是否拥有超出设备接入所需的权限。
3. 权限层：使用专门测试账号访问无敏感数据的验证对象，确认是否存在“普通设备账号可修改组策略、创建计划任务、读取凭据库”等越权。

网络可达性建议只探测明确批准的端口，并保留时间戳：

date -u +"%Y-%m-%dT%H:%M:%SZ"
for item in \
  "10.10.10.10 88" \
  "10.10.10.10 389" \
  "10.10.20.15 445" \
  "10.10.30.20 443"
do
  set -- $item
  timeout 3 bash -c "echo >/dev/tcp/$1/$2" \
    && echo "$1:$2 reachable" \
    || echo "$1:$2 blocked"
done

身份权限不要只看账号名称，重点核对嵌套组和委派。Windows 域环境可以先做只读检查：

Get-ADUser "edge-radius-svc" -Properties MemberOf,LastLogonDate,PasswordLastSet |
  Select-Object SamAccountName,Enabled,LastLogonDate,PasswordLastSet,MemberOf

Get-ADPrincipalGroupMembership "edge-radius-svc" |
  Select-Object Name,GroupCategory,GroupScope

Get-ADComputer -Filter * -Properties PrincipalsAllowedToDelegateToAccount |
  Where-Object {$_.PrincipalsAllowedToDelegateToAccount} |
  Select-Object Name,PrincipalsAllowedToDelegateToAccount

如果要验证“能否写入”，建议预建隔离 OU、测试共享目录或测试 API 对象，仅对该对象做一次创建、读取、删除，并在对象名中带验证编号。不要在生产主机上通过创建服务、计划任务或修改注册表来证明权限。

留痕方面至少保证三份独立证据：

• 边界设备：认证、配置变更、管理员会话、VPN 会话和策略命中日志。
• 内网目标：Windows 安全日志、Linux auditd、应用审计日志。
• 旁路或集中日志：防火墙流量日志、NetFlow、EDR、SIEM、远程 syslog。最好使用边界设备无法删除的账号和存储。

Windows 侧可重点关联这些事件：4624/4625 登录、4648 显式凭据、4672 特权登录、4688 进程创建、4728/4732 加组、4768/4769 Kerberos 票据、5140/5145 共享访问。按测试窗口导出时不要只截图：

$start = Get-Date "2025-03-08 14:00:00"
$end   = Get-Date "2025-03-08 15:00:00"

Get-WinEvent -FilterHashtable @{
  LogName   = "Security"
  Id        = 4624,4625,4648,4672,4688,4728,4732,4768,4769,5140,5145
  StartTime = $start
  EndTime   = $end
} | Export-Clixml .\VAL-20250308-01-security.xml

Get-FileHash .\VAL-20250308-01-security.xml -Algorithm SHA256

Linux 目标建议临时增加针对测试账号和关键目录的审计规则，而不是全量开启导致日志被淹没：

auditctl -w /etc/sudoers -p wa -k val_priv_change
auditctl -w /etc/ssh/sshd_config -p wa -k val_ssh_change
auditctl -a always,exit -F arch=b64 -S execve -F euid=0 -k val_root_exec

ausearch -k val_priv_change -i
ausearch -k val_root_exec -ts recent -i

验证结束后应删除临时规则并记录变更：

auditctl -W /etc/sudoers -k val_priv_change
auditctl -W /etc/ssh/sshd_config -k val_ssh_change
auditctl -d always,exit -F arch=b64 -S execve -F euid=0 -k val_root_exec

最终报告不要只写“可横向移动”，而应给出完整闭环：起点身份、网络路径、目标资源、实际获得的最小权限、对应日志事件、检测是否告警，以及哪条配置导致信任跨越。例如“VPN 服务账号因嵌套组获得服务器本地管理员权限”比“边界失陷可进入内网”更便于整改。整改优先级通常是撤销复用凭据、拆分认证域、限制管理面访问源、清理嵌套高权组，并把边界日志实时发送到不可回写的集中存储。