Go 主机安全面试：Linux SSH 隧道与端口转发检测

Linux 主机被入侵后，攻击者不一定马上落地后门服务，也可能用 ssh -L、ssh -R、ssh -D 做端口转发，把内网服务暴露出去，或者把被控主机变成代理跳板。面试官通常会追问：怎样区分合法运维跳板和异常隧道？只看 22 端口连接够不够？Go Agent 如何把进程、网络连接、登录会话和命令行证据串起来？

岗位场景

Linux 主机
  -> 采集进程启动、命令行、登录会话、网络连接和本地监听端口
  -> 识别 ssh/scp/socat/chisel/frp 等隧道或代理工具行为
  -> 关联 ssh -L/-R/-D 参数、本地监听、远端连接、用户和父进程
  -> 区分堡垒机运维、CI 发布、数据库代理和攻击者横向移动
  -> 输出可解释的隧道转发告警，并支持客户复盘连接路径

这类题考的是 Linux 进程与 socket 关联、SSH 端口转发原理、攻击链还原、误报治理和 Go 侧低开销采集设计。

高频面试题

1. SSH 隧道检测为什么不能只看连接 22 端口？

简洁答案：连接 22 端口只能说明有 SSH 会话，不能说明它是否在做端口转发；真正要关注的是 SSH 进程参数、本地监听、远端转发、动态代理端口和后续访问内网服务的行为组合。

关键知识点：

• 普通 SSH 登录、文件传输、配置管理和隧道转发都会连接 22 端口。
• ssh -L 会在本地监听端口，把流量转到远端目标。
• ssh -R 会在远端监听端口，把流量转回本机或内网目标，风险通常更高。
• ssh -D 会启动 SOCKS 代理，常用于内网探测和横向移动。
• 攻击者也可能用非 22 端口、域名 C2 或跳板机绕过简单规则。

Go 落地思路：

• 采集 process_exec 时保留 argv，不要只保留拼接后的命令行字符串。
• 采集网络连接时记录 pid、local_addr、remote_addr、state 和连接方向。
• 检测层按 host + pid + start_time 关联 SSH 进程、监听端口和外联连接。

type TunnelEvidence struct {
	HostID     string
	PID        int
	StartTime  int64
	User       string
	Args       []string
	ListenPort int
	RemoteAddr string
	Reason     []string
}

2. ssh -L、ssh -R、ssh -D 的安全含义有什么区别？

简洁答案：-L 是本地端口转发，常用于访问远端内网服务；-R 是远端端口转发，可能把内网服务反向暴露给外部；-D 是动态 SOCKS 代理，常用于把整台主机当代理入口。

关键知识点：

参数	行为	常见风险
-L local:target:port	本地监听，转发到远端目标	运维常用，需结合用户和目标判断
-R remote:target:port	远端监听，转回本机或内网	容易形成反向入口，风险更高
-D local_port	本地 SOCKS 代理	可用于内网扫描、代理浏览和横向移动
-N / -f	不执行远端命令、后台运行	和隧道组合时更可疑
ExitOnForwardFailure	转发失败即退出	常见于稳定隧道脚本

Go 落地思路：

• 参数解析不要只用 strings.Contains(cmdline, "-R")，要处理 -R8080:host:80 和 -R 8080:host:80 两种形式。
• 对 -R、-D、-N -f 组合提高风险分。
• 规则输出时写清楚“转发方向”和“目标服务”，否则客户很难判断影响面。

3. Linux 上如何把 SSH 进程和监听端口关联起来？

简洁答案：用进程启动事件确定 SSH 进程，再从 netlink、/proc/net/tcp* 或 eBPF socket 事件拿 socket inode，最后通过 /proc/<pid>/fd 反查进程持有的 socket。

关键知识点：

• ss -lntp 的本质也是把 socket 和进程关联起来。
• /proc/net/tcp 能看到本地地址、远端地址、状态和 inode，但不能直接给出命令行。
• /proc/<pid>/fd/* 中的 socket:[inode] 可以和网络表关联。
• 短生命周期连接容易错过，监听端口相对稳定，更适合作为隧道证据。
• 容器和 host network 会影响端口归属判断。

Go 落地思路：

• 优先监听 netlink socket 事件，周期性 procfs 快照作为补偿。
• 对 SSH 相关进程触发一次小范围 fd 扫描，不全量扫描所有进程所有 fd。
• 进程退出后要保留事件快照，避免客户排查时证据已消失。

func isSocketFD(target string) bool {
	return strings.HasPrefix(target, "socket:[") && strings.HasSuffix(target, "]")
}

4. 如何识别攻击者利用 SSH 隧道做内网横向移动？

简洁答案：看隧道建立前后的行为链：异常登录或 Web RCE 后启动 SSH 隧道，随后出现到内网数据库、Redis、RDP、Kubernetes API 或业务管理端口的连接，这比单点命中更可信。

关键知识点：

• 横向移动常见目标包括 3306、5432、6379、9200、6443、3389、5985 等。
• 攻击链要关注“入口账号、父进程、隧道参数、目标网段、后续扫描或认证失败”。
• ssh -D 后不一定能从命令行看到最终目标，需要从后续连接和代理端口访问模式推断。
• 合法运维也会访问内网服务，必须结合时间、账号、资产角色和审批基线。

Go 落地思路：

• 为每个 SSH 隧道维护短窗口上下文，例如 5 到 15 分钟。
• 同一用户或同一进程树在窗口内访问多个内网网段时提高风险分。
• 输出链路证据：login -> ssh tunnel -> local socks/listen -> internal service access。

5. 只靠命令行参数检测 SSH 隧道有什么问题？

简洁答案：命令行参数容易缺失、被截断、被 wrapper 隐藏，也可能通过配置文件、控制连接或其他工具实现转发，所以参数只是强证据之一，不能作为唯一证据。

关键知识点：

• /proc/<pid>/cmdline 在进程退出后不可读，权限不足时也会失败。
• OpenSSH 可以通过 ~/.ssh/config 配置 LocalForward、RemoteForward 和 DynamicForward。
• autossh、systemd、脚本 wrapper 可能让真正的 ssh 参数分散在配置文件或环境变量里。
• socat、ncat、chisel、frp 也能完成类似转发，不一定出现 ssh。

Go 落地思路：

• 命令行命中作为 reason_code，网络监听和连接行为作为补证据。
• 对 ssh 配置文件只采集必要摘要，例如路径、owner、mtime、Forward 指令数量，不上传私钥或敏感内容。
• 把工具识别做成小规则集，不引入复杂 DSL。

6. 如何降低 SSH 隧道规则的误报？

简洁答案：不要把所有端口转发都当攻击，要按资产角色、用户、目标、时间窗口、父进程和历史基线分层评分，并给客户可维护的窄白名单。

关键知识点：

• 数据库管理员、SRE、堡垒机、CI/CD 和备份系统可能合法使用端口转发。
• 长期固定的 user + host + target + port 组合风险低于首次出现的组合。
• 深夜首次出现、普通 Web 用户启动、目标为敏感网段或带 -R/-D -N -f 组合更可疑。
• 白名单应带过期时间和条件范围，不能只按进程名放行。

Go 落地思路：

• 先做评分，不要一个 bool 直接告警。
• allowlist 条件至少包含用户、源主机、目标地址、端口和命令模式。
• 告警抑制按“同一隧道指纹”去重，保留首次出现和参数变化。

type TunnelFingerprint struct {
	User   string
	Mode   string
	Local  string
	Remote string
	Target string
}

7. Agent 资源有限时，SSH 隧道检测怎么做得轻？

简洁答案：先用低成本事件筛选候选进程，再对候选做短窗口关联和小范围快照；避免全量高频扫描网络表、全量读取所有用户 SSH 配置或对所有连接做复杂规则。

关键知识点：

• 进程执行事件比周期性扫描更及时，但事件源可能丢失。
• 网络表扫描成本和主机连接数相关，高并发机器要限频。
• SSH 配置文件可能很多，且包含敏感信息，不能粗暴上传。
• 高价值证据要优先保留，低价值重复连接可以聚合。

Go 落地思路：

• 用有界队列连接采集层和检测层，避免网络风暴拖垮 Agent。
• 对候选进程设置采集预算，例如 fd 最多扫描 64 个、配置文件最多读取前 N KB。
• 暴露指标：候选进程数、关联成功率、扫描耗时、丢弃事件数和告警数。

8. 客户反馈“这是正常运维隧道”，Go 研发怎么排查？

简洁答案：先复盘告警证据是否完整，再确认用户、来源、目标、审批和历史基线；如果确实是正常行为，把白名单收敛到具体隧道指纹，并沉淀回放样本防止规则退化。

关键知识点：

1. 确认告警中的 pid、start_time、user、cmdline 和监听端口是否一致。
2. 查看 SSH 登录来源、父进程、tty、工作目录和执行时间。
3. 确认目标地址是否为客户批准的数据库、堡垒机或办公网。
4. 检查是否伴随扫描、认证失败、异常下载、提权或持久化动作。
5. 判断是正常隧道、规则阈值过低、基线缺失，还是攻击链证据不足。

Go 落地思路：

• Debug dump 只包含必要字段，敏感参数、用户名和内网地址按策略脱敏。
• 离线 replay 使用同一套规则逻辑复现告警，避免线上线下判断不一致。
• 白名单变更记录规则版本、操作者、过期时间和命中次数。

通俗答案

SSH 隧道检测不是“看到 ssh 就报警”，而是回答三个问题：谁在建隧道、隧道通向哪里、它被用来访问了什么。正常运维通常有固定账号、固定目标、固定时间和审批记录；攻击者更常出现在异常入口之后，用 -R 或 -D 建立代理，再访问内网敏感服务。

最小可用链路可以这样理解：

异常登录或 Web RCE
  -> ssh -D/-R/-L 启动
  -> 本地或远端出现监听端口
  -> 访问内网敏感服务或多个网段
  -> 告警输出隧道方向、目标、用户和关联行为

Go 落地要点

• 事件模型要稳定：进程、网络、登录、文件配置分别标准化，再在检测层关联。
• 进程唯一键不要只用 PID，至少加上 host_id + boot_id + pid + start_time。
• 参数解析要覆盖短参数合并、参数和值分离、配置文件 Forward 指令和 wrapper 场景。
• 检测规则先支持高价值组合：ssh -R、ssh -D -N -f、Web 用户启动隧道、首次出现目标、后续访问敏感端口。
• 资源控制要前置：候选进程触发式采集、有限 fd 扫描、网络表限频、有界队列和指标观测。
• 告警解释要面向排查：展示用户、父进程、转发模式、监听端口、目标地址、后续连接和降噪依据。

学习要点

• 掌握 SSH local/remote/dynamic forwarding 的方向差异和典型命令形态。
• 理解 Linux socket 与进程关联：netlink、/proc/net/tcp*、/proc/<pid>/fd、socket inode。
• 能把登录、进程、网络和配置文件事件组合成攻击链证据。
• 能说明误报来源：堡垒机、DBA、SRE、CI/CD、备份任务和固定代理。
• 能设计 Go Agent 的低开销采集、缓存、限流、指标和离线回放能力。

小练习/复盘题

1. 设计一个 SSHTunnelEvent 结构体，要求能表达 -L、-R、-D 三种转发模式。
2. 写一个参数解析函数，区分 -R8080:127.0.0.1:80 和 -R 8080:127.0.0.1:80。
3. 给出三种合法 SSH 隧道场景，并说明白名单应该包含哪些条件。
4. 设计一条规则：异常 SSH 登录后 10 分钟内启动 ssh -D，随后访问多个内网敏感端口。
5. 解释为什么只看 remote_port == 22 不能判断 SSH 隧道风险。
6. 如果线上误报暴增，你会先看哪些指标来判断是采集风暴、规则问题还是客户运维变更？