背景
云厂商告警说一台 Ubuntu 主机在对外发起异常连接。第一反应很容易变成追着目标地址加黑名单，或者把所有出站都当成可疑流量。但这类问题最怕的是把不同性质的连接混在一起：SSH 返回包、云厂商 agent 的本地链路、业务端口和真正新发起的公网 HTTPS 连接，处置方式完全不同。
这次复盘的核心，不是记住某个目标地址，而是形成一条可以复用的本机证据链。
这次解决了什么
排查目标有三个：
- 告警时间窗内到底有没有主机主动发起的新连接。
- 哪些连接只是 SSH、agent 或业务白名单流量。
- 本机如何临时收敛出站，同时保留足够日志继续定位。
关键过程
先按连接性质分流，而不是按目标地址逐个判断。SSH 回包看源端口，云厂商 agent 看 link-local 链路，业务连接看已知端口和进程；剩下的新发起 443 SYN 才进入高优先级排查。
第二步是在 OUTPUT 链最前面挂一个收敛规则：放行回环、已建立连接和明确业务端口；对其余新发起外连记录日志并阻断。这样既能降低风险，又能让后续日志只显示真正值得看的尝试连接。
第三步用 journalctl -k -n 0 -f 观察新日志，用 ss -tanp state syn-sent 抓仍在尝试连接的进程。这个组合比盯着云侧 IP 列表更接近事实，因为它能把“谁在本机发起”暴露出来。
踩坑
最大的坑是把告警目标地址当成唯一事实。目标地址可能变化，云侧聚合也可能滞后；真正稳定的是本机时间窗、连接状态、进程和防火墙日志。
另一个坑是把 SSH 相关流量误判成攻击流量。远程登录本身会产生回包，如果不先区分连接方向，就可能把自己的维护通道也当成异常。
最后方案
默认排查顺序固定为：先对齐云厂商告警时间窗，再看本机日志覆盖范围，然后按 SSH、agent、业务、未知新连接四类拆开。需要临时止血时，先在本机做可回滚的出站收敛，并保留 EGRESS_BLOCK 这类高信噪比日志。
这套方法的价值在于，它不会把“封得更狠”误当成“找到了真因”。它先把风险降下来，再逼近发起者。
以后怎么做
以后遇到“这台机器是不是还在往外打”的问题，先不要从目标地址开始。先回答四个问题：告警窗口是什么，主机日志是否覆盖，连接是回包还是新发起，进程证据在哪里。只有这四件事对上了，云侧规则调整才有意义。