llbzow 的摸鱼日记 (づ￣ 3￣)づ

1.1 机制分析#

Windows 平台的 OpenSSH 实现与 Linux 存在关键差异：

• 普通用户：密钥读取其主目录下的 ~/.ssh/authorized_keys。
• 管理员组（Administrators 组）用户：OpenSSH 默认会读取全局配置文件 C:\ProgramData\ssh\administrators_authorized_keys，而非用户个人的 .ssh 目录。
• 严格的 ACL 限制：出于安全防护，Windows 对该全局授权文件的权限控制极为苛刻。若文件中包含了除 SYSTEM 和 Administrators 之外其他账户的任何读写权限，OpenSSH 服务将直接拒绝该公钥认证。

1.2 配置步骤#

若要成功配置 Administrators 组用户的公钥登录，需使用管理员权限打开 PowerShell，并依次执行以下命令：

1
$adminKeys = "C:\ProgramData\ssh\administrators_authorized_keys"
2

3
# 1. 写入 SSH 公钥
4
"ssh-ed25519 AAAAC3NzaC... your-comment" | Out-File -Encoding utf8 -Append $adminKeys
5

6
# 2. 移除普通已认证用户的访问权限 (防止因权限过宽被 OpenSSH 拒绝)
7
icacls $adminKeys /remove "NT AUTHORITY\Authenticated Users"
8

9
# 3. 禁用继承，确保仅 SYSTEM 和 Administrators 拥有完全控制权限
10
icacls $adminKeys /inheritance:r
11
icacls $adminKeys /grant "SYSTEM:F"
12
icacls $adminKeys /grant "Administrators:F"

通过以上步骤，即可在不降低系统安全性的前提下，打通安全的 SSH 远程运维管理隧道。

2.1 代理协议局限性#

若直接通过远程建立的 SOCKS 代理运行网络扫描工具（如 Nmap）：

• SOCKS 代理只支持 TCP/UDP 传输，无法承载 ICMP 协议。这导致常规的 Ping 扫描直接失效。
• 当执行 TCP 端口扫描时，由于代理握手延迟和网络状态变化，会导致大量本已开放的端口被误报为关闭（False Negative）。

2.2 解决方案：跳板机本地执行 PowerShell 扫描#

为保证数据精准度，应当使用轻量化的脚本上传至跳板机本地执行，利用跳板机本地网络栈直接进行 TCP 445 (SMB) 端口的快速扫描。

以下是一个简易的多线程/超时控制探测思路，配合 Windows 内置的 nbtstat 命令，可以在短时间内精确抓取存活主机的 NetBIOS 名称，快速梳理资产：

1
# 简易端口存活探测代码段
2
$subnet = "192.0.2." # RFC 5737 文档保留网段
3
1..254 | ForEach-Object -Parallel {
4
    $ip = "$using:subnet$_"
5
    $tcpClient = New-Object System.Net.Sockets.TcpClient
6
    $connection = $tcpClient.BeginConnect($ip, 445, $null, $null)
7
    $wait = $connection.AsyncWaitHandle.WaitOne(150, $false) # 150ms 超时控制
8
    if ($wait) {
9
        $tcpClient.EndConnect($connection)
10
        Write-Output "[+] Active SMB Target: $ip"
11
        # 配合 nbtstat 抓取主机名
12
        nbtstat -A $ip | Select-String "UNIQUE" | Select-Object -First 1
13
    }
14
    $tcpClient.Close()
15
}

通过在跳板机上本地执行此类轻量探测，可以完美避开远程 SOCKS 代理带来的漏报问题。

3.1 路由特征与 ICMP 行为特征推理#

在排查某些特定出口流量时，可能会遇到如下现象： 对出口测试地址执行 tracert 路由跟踪，发现跳数较少且时延明显低于远端链路。

• 逻辑推理：
  • 较低时延表明出口设备可能位于较近的网络边界，但不能单独作为物理位置结论。
  • 但若在本地 ARP 缓存表（arp -a）中找不到该公网 IP 对应的 MAC 地址，则证明它并非处于同一二层网络直连。
  • 结论：这通常意味着局域网的默认网关启用了 ICMP 代理，或者网关设备在检测到目标为自身公网 IP 时，执行了本地 NAT Hairpin（发卡弯） 环回路由。

3.2 物理网关定位与流量反查协作手段#

当网关管理页面未开放（或因网络桥接等原因无法从当前网段远程访问），且需要精确定位具体物理设备与流量源头时，可采取如下物理-逻辑联动协作手段：

1. MAC 地址反查物理端口： 在授权条件下登录核心二层交换机，查询示例 MAC（如 02-00-00-00-00-01）对应的上联端口。实际排障记录只在受控渠道中流转。
2. 网关 NAT 连接日志反查： 在物理定位并获得网关管理权限后，提取网关设备的 NAT 映射/连接状态日志，通过过滤特定时间段、特定外部目标 IP，反查与其通信的内网源私有 IP（例如追溯某异常外部连接是由内网哪台 PC 发起）。
3. 结合 DHCP 租约记录： 在 DHCP 环境下，IP 地址随时可能换租。因此在定位到内网源 IP 后，必须对照 DHCP 租约日志中的 MAC 地址分配历史，以防因 IP 换租导致误判，最终完成对物理终端的精确锁定。