结论先行：内网攻击之所以能长期潜伏，核心原因是东西向流量没有记录——边界设备看不到主机之间的访问，抽样镜像又覆盖不全。微隔离在每个工作负载侧记录了全量连接与阻断数据，把这份数据接入告警规则，就能识别端口扫描、异常访问、主机失联等行为。难点不在能不能检测，而在规则怎么配才不把告警变成噪音。
为什么传统检测手段在内网失灵
- 镜像覆盖不全：核心交换机镜像端口有限，虚拟化主机之间的流量根本不经过物理链路，镜像拿不到。
- 基于地址的行为分析不可靠：云环境地址频繁变化，昨天画好的基线今天就失效。
- 抽样丢证据：真实攻击往往是低频慢速的，正好落在抽样之外。
- 主机侧没有数据：被攻陷的主机不会主动上报，外部观察又看不到它内部发生了什么。
微隔离的数据位置恰好补上了这段：策略执行点在每台主机上，进出该主机的每一次连接尝试都会被记录，无论是否放行。
四类值得先配的检测场景
| 场景 | 典型特征 | 建议处置 |
|---|---|---|
| 端口扫描 | 单个源在短时间内向大量端口或大量目的地址发起连接 | 先告警并核对，确认后隔离该源 |
| 异常访问 | 访问关系明显偏离学习基线，例如办公终端直连数据库端口 | 与业务方核对，确属异常的加入阻断 |
| 主机失联 | 客户端长时间不上报心跳，或资产离线 | 排查是被卸载、主机已下线还是被攻击者处理过 |
| 阻断激增 | 某台主机的阻断日志在短时间内成倍增长 | 判断是策略配错还是真的在被扫 |
告警规则怎么配才不吵
- 先定基线再开异常：让系统先学习一到两周的正常访问关系，基线稳定后再启用异常检测，否则第一周就会被误报淹没。
- 阈值分层：同一条规则设两级阈值，低阈值只记录不通知，高阈值才告警，避免小幅波动就响。
- 按资产重要度分级：核心业务域的异常访问当天处理，普通域汇总进周报，让注意力花在重要的地方。
- 同源合并：同一源在短时间内的同类事件合并成一条，避免一条扫描动作刷出上千条通知。
- 写清处置动作：每条规则都要明确"告警之后做什么、谁来做、多久内做"，否则规则只是一堆通知。
从告警到处置的闭环
- 告警接进工单或安全管理平台，不要留在微隔离界面里等人主动去看；
- 疑似失陷的主机先加入隔离组，切断它到所有业务的连接，再慢慢取证，不要边查边扩散；
- 事后把这次的攻击路径回写成策略，堵住同类路径，同一条路不再走第二遍；
- 每季度复盘一次规则命中率，删掉长期零命中的，也删掉长期刷屏的。
常见坑
- 学习期太短就开检测，误报把真实事件淹掉，之后运维直接把告警静音；
- 只告警不处置，规则配了等于没配，时间一长没人再看；
- 忽略运维通道，把正常的堡垒机访问与运维扫描当成攻击，反复误报；
- 规则只增不减，两年后几百条规则无人维护。
奇摩在金融与制造客户的微隔离运营中，通常把告警规则数量控制在一个运维能真正维护的规模内——宁可少几条，也要每条都有人认领。若您需要一起设计检测规则与处置流程，欢迎预约咨询。