做云上流量分析，听我一句劝，先把手里的鼠标放下，把下面这四条"严禁"刻在脑子里：
- 严禁一开流日志就全量灌进日志平台（信我，第二天财务就会找你喝茶，日志存储和索引费用直接爆炸）。
- 严禁没建基线就凭感觉判断异常（没有基线，你的告警平台就是个垃圾堆，误报一堆，最后"狼来了"没人信）。
- 严禁发现可疑IP就一刀切封禁（你封的可能根本不是黑客，而是CDN节点、合作伙伴固定出口，或者云平台的健康检查探针，业务直接瘫痪）。
- 严禁只看入站不看东西向（外网打进来的往往只是试探，内网横向移动才是真正要命的）。
处置总原则就一句话："先开日志留痕，再建基线；先定位会话，再决定处置"。别一上来就拔网线、封IP，先把现场保住。
一、 正确开局：想清楚再动手
动手前，先想清楚分析目标。是排查安全设备刚报的告警？还是日常巡检找潜在异常？目标不同，收敛方向完全不同。
接着确认流日志的覆盖范围：哪些VPC？哪些弹性网卡（ENI）？有没有包含东西向流量？日志存在哪个集中式日志服务里？保留多少天？
排查时，按 "外部入站→内部东西向→出站外连" 三条链路往下收敛。把流量分成三类来看：
- 正常业务流量：符合业务逻辑的源目IP和端口，流量大小在预期范围内。
- 疑似异常：陌生地域IP、高频短连接、非标准端口、非常规时间的突发流量。
- 确认恶意：C2回连、已知矿池地址、暴力破解来源。
二、 排查主链路与实操命令
1. 开启VPC流日志
别全量开！优先开核心业务VPC和关键弹性网卡。
控制台操作建议 ：找到网络管理 -> VPC -> 流日志 -> 创建。采集范围先选"特定子网"或"特定弹性网卡"，流量类型强烈建议先选
Reject（仅记录拒绝的流量） 跑一周，评估日志量和费用后，再考虑切换为All。
bash
# 通用云CLI示例（请根据实际使用的云平台CLI工具替换对应命令）
cli-tool vpc create-flow-log \
--resource-id vpc-xxxxxxxxxxxx \
--resource-type VPC \
--traffic-type REJECT \
--log-destination-type log-service \
--log-project "security-log-project" \
--log-store "vpc-flowlog-reject"⚠️ 生产环境风险 ：开启
All前必须评估日志量。高并发业务的全量流日志每天可能产生数十GB数据，直接写入会导致日志平台存储成本失控，甚至影响日志平台本身的写入性能。
2. 查询与统计（通用日志分析SQL）
以下SQL语法兼容主流云厂商的日志分析引擎（如SPL/ClickHouse）。
sql
-- 统计TOP 10 来源IP
* | SELECT srcaddr, count(*) as cnt GROUP BY srcaddr ORDER BY cnt DESC LIMIT 10
-- 统计TOP 10 目的端口
* | SELECT dstport, count(*) as cnt GROUP BY dstport ORDER BY cnt DESC LIMIT 10
-- 统计被拒绝连接的比例（action为REJECT或DROP）
* | SELECT action, count(*) as cnt, round(count(*) * 100.0 / sum(count(*)) over(), 2) as percentage GROUP BY action3. 查找东西向异常
sql
-- 查找内网IP之间互访突增（假设内网段为10.0.0.0/8 和 192.168.0.0/16）
srcaddr: (10.* OR 192.168.*) AND dstaddr: (10.* OR 192.168.*) |
SELECT srcaddr, dstaddr, dstport, count(*) as cnt
GROUP BY srcaddr, dstaddr, dstport
ORDER BY cnt DESC
LIMIT 20现象：如果看到某个内网IP在疯狂扫描其他内网IP的22、3389、445端口，且action多为ACCEPT或REJECT交替，大概率是被攻破后在横向移动。
4. 出站外连分析
sql
-- 查找连接陌生公网IP，特别是矿池常见端口
dstaddr NOT IN (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) AND dstport IN (3333, 4444, 5555, 8888, 14444)5. 结合安全组/NACL与威胁情报
看到可疑IP，先去查该实例绑定的安全组和网络ACL规则，看是误放行还是被绕过了。拿着IP去 AbuseIPDB 或 VirusTotal 搜一下。如果是恶意IP，再上机抓包。
bash
# 在可疑实例上抓包确认
# 注意：抓包会消耗CPU和磁盘I/O，生产环境慎用，务必限定时间和包数量
tcpdump -i eth0 -nn -c 2000 host <可疑IP> and port <可疑端口> -w /tmp/suspicious.pcap三、 高频现场逐个拆
1. 横向移动
- 现象：内网一台Web服务器被破，流日志显示它开始扫描同VPC下数据库服务器的3306端口。
- 命令 ：
srcaddr: <被破WebIP> AND dstport: 3306 - 处理：立刻在安全组层面切断该Web服务器对数据库端口的访问，遵循最小权限原则，只允许特定应用IP访问。
2. C2外连
- 现象：内网某台机器，每隔5分钟向同一个境外IP的443端口发起一次短连接，且连接时间极度规律（心跳特征）。
- 命令 ：
srcaddr: <内网IP> AND action: ACCEPT | SELECT dstaddr, date_trunc('minute', __time__) as t, count(*) GROUP BY dstaddr, t ORDER BY t - 处理：断网隔离实例（修改安全组拒绝所有出入站），提取内存dump分析进程，排查crontab定时任务或驻留后门。
3. 挖矿流量
- 现象：CPU飙高，流日志显示大量外连矿池域名解析后的IP，端口多为3333/14444。
- 命令：同上面的出站外连分析。
- 处理：安全组封禁出站矿池IP，上机杀掉挖矿进程，清理定时任务和SSH公钥。
4. 暴力破解来源
- 现象：流日志显示某个公网IP对你的22端口发起了几千次连接，大部分是REJECT，但中间夹杂了几个ACCEPT，且ACCEPT后该源IP的出站流量突增。
- 命令 ：
srcaddr: <公网IP> AND dstport: 22 - 处理：确认是爆破成功后，立刻修改密码/禁用密码登录改用密钥，安全组封禁该源IP，排查系统是否被植入后门。
5. 异常大流量
- 现象：某台非CDN源站的机器，出站流量突然达到几百Mbps。
- 命令 ：
srcaddr: <内网IP> | SELECT sum(bytes) as total_bytes GROUP BY srcaddr - 处理：可能是数据外泄，也可能是被当成代理肉鸡。立刻限速或断网，排查业务代码是否有漏洞或被植入代理脚本。
6. 云平台健康检查/监控误报
- 现象：看到大量来自特定IP段（如100.64.0.0/10或平台文档声明的探针网段）对你的80/443端口发起高频探测。
- 处理：这是云平台的负载均衡健康检查或云监控探针。千万别封！去控制台把这些IP段加入业务安全组白名单。
7. 公网扫描器扫描暴露面
- 现象：凌晨时段，大量不同公网IP对你的全端口进行扫描，流日志里全是REJECT。
- 处理：这是全网常态。只要安全组配置正确（只开必要端口），直接忽略。如果REJECT日志太多影响分析，可以在流日志配置里过滤掉REJECT，或者在日志平台里建个白名单视图。
四、 处置与落地策略
发现异常后，怎么处置？分四档，代价和风险递增：
- 观察：只看不动，用于收集更多上下文，确认是不是误报。
- 限流：通过云防火墙或高防清洗，限制该IP的并发连接数或带宽。适用于疑似CC攻击或爬虫。
- 封禁：在安全组或网络ACL中直接Drop。适用于确认恶意的IP。
- 隔离实例：直接停止实例或断开弹性网卡。适用于实例本身已经被完全控制（如挖矿、C2）。
⚠️ 生产环境风险：封禁前必须验证IP性质！一定要查威胁情报，并且确认它不在你的业务白名单（如CDN回源IP、合作方IP、云平台健康检查IP）里。
东西向异常，定位到具体实例后，直接改该实例的安全组。入站异常，如果是大流量攻击，用云防火墙或高防清洗；如果是精准攻击，用安全组封禁。
处置完，一定要回到流日志平台，搜一下那个IP或端口，确认异常流量已经消失，才算闭环。
五、 根因分析
流量异常只是表象，根因往往在这几个地方：
- 暴露面过大：安全组开了0.0.0.0/0的22/3389，被全网扫描爆破。
- 弱口令：RDP或SSH密码太简单，被字典跑出来了。
- Web漏洞：Log4j2、Shiro反序列化等，被直接打入内网。
- 供应链投毒：引入了带后门的第三方SDK，初始化时回连C2。
- 内网无隔离：VPC内所有机器互通，一台被破，全网遭殃。
怎么定位？把流日志时间线、主机登录日志（/var/log/secure或Windows事件日志）、Web访问日志（Nginx/Apache access.log） 放在一起看。流日志告诉你"什么时候、谁、访问了哪里"，登录日志告诉你"谁登录了系统"，Web日志告诉你"利用了哪个URL"。三者一交叉，攻击链路和责任定位就清清楚楚了。
六、 事后加固要点
- 流日志长期开启并归档：核心VPC的流日志必须开，日志至少保留180天，满足合规和溯源需求。
- 流量基线建模：跑一个月正常流量，算出每个IP的日均连接数、外连IP数量，超过基线3倍才告警。
- 威胁情报联动：把流日志里的目的IP，每天自动和云端威胁情报库撞库，发现恶意IP直接告警。
- 网络微隔离：抛弃大网段互通，安全组细化到端口和源IP，网络ACL作为最后一道防线。
- 出站方向白名单：内网机器除了业务必须的域名/IP，禁止直接访问公网。用NAT网关的SNAT规则或云防火墙控制出站。
- 异常流量告警规则：在日志平台配置规则，如"单IP 1分钟内连接内网不同IP超过50个"、"外连矿池端口"等。
- 定期流量审计报告：每个月出一份报告，看看哪些安全组规则是冗余的，哪些IP外连了不该去的地方。
七、 总结高频踩坑
最后，总结一下大家最容易踩的坑，希望对你们有帮助：
- 一开流日志费用爆炸：没评估日志量就开全量，一定要先开Reject或者抽样开。
- 没基线乱报警：把正常业务高峰当成了异常，天天处理误报，最后狼来了。
- 封IP误伤CDN/健康检查：没查清楚IP归属就封，导致业务大面积不可用。
- 只看入站忽略东西向：外网防守得铁桶一般，内网一台机器被破后如入无人之境。
- 日志保留太短查不到历史：只留7天，黑客潜伏了半个月，溯源时抓瞎。
- 只封IP不堵入口：封了攻击者IP，但他利用的Web漏洞还在，换个IP接着打。
云上安全没有银弹，流日志也不是万能的，但它是你排查网络问题的"黑匣子"。把流日志用好，把基线建好，遇到事儿才不会慌。
如果你觉得这篇实战复盘对你有帮助，或者在生产环境里用过这些招数，欢迎在评论区交流你的踩坑经验。
别忘了点赞、收藏、转发三连，你的支持是我继续输出硬核实战的动力！我们下期见。