AWS帳號快速認證 AWS VPC Flow Logs 流量日誌分析：如何定位異常大流量攻擊與內網掃描？
一、为什么 VPC Flow Logs 值得认真看
很多人第一次接触 VPC Flow Logs，会把它当成一份“有点像网络日志”的记录表，真正遇到攻击时才发现，它往往是最先能给出方向的证据。CloudTrail 负责告诉你谁调用了什么 API，WAF 负责挡住一部分公网请求，安全组和网络 ACL 负责控制访问边界，而 Flow Logs 记录的，是 VPC 里真实发生过的流量往来。它不直接告诉你“这就是攻击”，但它能告诉你流量从哪里来、到哪里去、用了什么端口、传了多少字节、有没有被放行。对排查异常大流量攻击和内网扫描来说，这些信息已经足够让很多问题浮出水面。
如果只看平均流量曲线，很多异常都容易被掩盖。比如某台业务服务器平时每分钟只有几 MB 的出站流量，突然在凌晨连续几个小时保持高位，或者某个内网地址在短时间内对几十个网段端口发起连接尝试，这些都不会在系统日志里被完整体现，却会在 Flow Logs 里留下清晰的痕迹。真正有价值的地方，不在于“看见了日志”，而在于你能不能把零散的记录拼成一条行为链。
二、先读懂 Flow Logs 的关键字段
分析之前，先把最常用的字段记牢。Flow Logs 的记录格式可以配置，但核心字段基本绕不开：srcaddr、dstaddr、srcport、dstport、protocol、packets、bytes、start、end、action 和 log-status。它们不是简单的文本，而是复原一条网络行为的骨架。
srcaddr 和 dstaddr 分别是源地址和目标地址，决定了流量的方向。srcport 和 dstport 则告诉你连接走的是哪个端口，常见服务一眼就能认出来，比如 80、443、22、3306、6379、5432。protocol 用来判断是 TCP、UDP 还是 ICMP。packets 和 bytes 是分析“大流量”的核心，前者能反映连接是否碎片化，后者能直接说明传输了多少数据。start 和 end 给出时间范围，action 则告诉你这条流量是 ACCEPT 还是 REJECT。log-status 还会提示日志是否完整、是否丢失，这一点在高峰期特别重要。
很多人只盯着 bytes，但真正排查时，packets 也很有用。比如某个连接 bytes 很大、packets 也很大，常见于持续传输、批量同步、数据外传；如果 bytes 不算特别夸张，但 packets 数量极高，可能是大量短连接，或扫描、探测、重试行为。再比如，一个源地址对很多目的地址都出现少量 bytes、少量 packets 的访问，往往不是业务流量，而是自动化探测。
1. Flow Logs 能看到什么，不能看到什么
Flow Logs 的强项是“网络层行为”，弱项是“应用层内容”。它能看见连接建立、流量大小、拒绝情况，却看不到 HTTP 请求路径、账号密码、SQL 语句正文这些内容。所以，别指望它单独回答“攻击者做了什么”，但它能告诉你“攻击从哪台机器开始，先连了谁，再连了谁，流量是不是异常放大”。这就已经足够把调查范围从整个 VPC 缩小到具体主机和时间段。
AWS帳號快速認證 另一个容易忽略的点是，Flow Logs 不是包级抓取，它更像是按连接或时间窗口汇总后的记录。也就是说，少量极短连接可能被看成一条记录，而不是一包一包展开。理解这一点很重要，否则你会误把“记录条数不多”当成“流量不大”。
三、如何判断异常大流量攻击
所谓“大流量攻击”，不一定只有传统意义上的 DDoS。更常见的场景包括：被控实例向外持续回连下载工具，业务服务器被入侵后向外大量上传数据，某个中间件端口被恶意批量请求拖高流量，或者在内部横向扩散过程中不断产生连接和重试。判断这类问题，先看两个维度：有没有“突增”，以及是不是“持续”。
突增很好理解。平时某台实例平均每 5 分钟只产生几十 MB 出站流量，某一段时间突然涨到几 GB，且没有对应业务变更、发布、备份或批处理任务，这就是第一层警报。持续则更危险。很多真实攻击不是单点爆发，而是稳定维持一段时间，既不触发短期阈值，也不容易被监控图上的噪声淹没。Flow Logs 的价值就在于，它能帮你把“哪台机器在什么时间段持续把流量打高”找出来。
1. 从 bytes 入手，先找异常源
实战里，最有效的方法通常不是一上来就看所有记录，而是先按 srcaddr 聚合 bytes，找出出站流量最高的前几名。若某个实例的出站流量远高于历史基线，先别急着下结论，先确认它是不是本来就承担下载、备份、日志转发、CDN 回源、数据同步等职责。排除正常业务后，再看它连接的 dstaddr 是否分散、dstport 是否异常、协议是否单一。
如果一台业务实例对外发起大量 443 端口连接，目的地址分布很散，而且 bytes 增长与业务请求没有对应关系，就要警惕恶意外联、数据外传或下载器行为。若目的地址集中在少数几个陌生公网 IP，且连接时间长、bytes 持续增加，往往说明它在做持续传输，而不是偶发访问。
2. 从 dstaddr 和 dstport 看流量意图
目的地址和端口能帮助你区分“正常业务”与“异常访问”。如果异常流量都打到同一个内部地址，且端口集中在数据库、缓存、管理后台端口，比如 3306、6379、5432、9200、11211、22、3389，那么要考虑是不是有人在尝试打服务、取数或登录。若是对外流量，端口集中在 80、443 并不代表安全，因为很多下载、回连、代理通信也会走这两个端口。此时要结合目的 IP 是否新出现、是否属于已知供应商、是否在正常白名单中来判断。
如果某台机器的流量峰值来自少量大包传输，且目标固定，可能是文件传输、备份、镜像拉取；如果目标不固定、连接极其分散、频率很高，则更像扫描或对外探测。判断时不要只看单条记录，而要把同一时间段内的 srcaddr、dstaddr、dstport 放到一起看。
3. 结合 action 看拒绝流量是否在“撞门”
很多攻击在初期并不会直接成功，它们会先产生大量 REJECT 记录。比如外部扫描器不断尝试连接未开放端口，安全组拦截后日志里会出现大量拒绝；又比如内部某台主机被感染后尝试访问更多地址，但被网络 ACL 或安全组挡住。REJECT 本身不等于风险解除，恰恰相反，它常常说明攻击者已经开始试探边界。
如果短时间内某个 dstaddr 出现成百上千条来自不同 srcaddr 的 REJECT，说明它在被探测；如果某个 srcaddr 向大量 dstaddr 发起 REJECT 请求，说明它很可能在进行扫描。这个判断非常实用，因为很多安全团队只关注 ACCEPT 记录，最后把大部分试探阶段的信号都忽略了。
四、内网扫描的典型特征
内网扫描比大流量攻击更隐蔽，因为它不一定制造很高的 bytes，总流量看上去也许并不夸张，但它的连接模式很有规律。一个正常业务主机通常只和少量固定服务通信，而扫描行为则相反：目的地址多、端口多、单次连接短、失败率高、时间集中。只要抓住这个反差，识别并不难。
1. 一源多目标，像撒网一样扩散
最典型的模式是一个源地址在短时间内访问大量内部 IP。比如同一个 srcaddr 在几分钟内对 10.0.1.0/24、10.0.2.0/24、10.0.3.0/24 的多个主机发起连接，dstport 还不断变化，可能是 22、80、135、139、445、3306、3389 等组合。这种行为通常不是业务动作，而是资产探测、漏洞扫描或蠕虫式扩散。
真正的内网扫描有一个很重要的特征：它不是“和一台机器说很多话”，而是“对很多机器说同样的话”。所以你可以把同一时段内的流量按 srcaddr 分组，再看它连接过多少个不同 dstaddr。如果某个源地址的目的地址数量远超同类主机，就值得重点核查。
2. 多端口试探，像在找门缝
还有一种常见模式是同一批目标 IP 被反复试不同端口。比如对同一个内部网段，先扫 22，再扫 80，再扫 443，再扫 3389，接着又扫 1433、3306、6379。这个过程通常有较强的自动化特征，时间间隔很短，端口序列也很机械。即使每次连接都被拒绝，日志里还是会留下规律极强的痕迹。
如果只看单条记录，这种行为并不显眼；但把端口分布按时间画出来，模式会非常清楚。扫描器往往为了尽快覆盖更多资产，会牺牲随机性，所以在时间窗口内会呈现高度均匀或高度重复的分布。正常运维批量检查虽然也会触发多端口访问，但通常会限定在已知资产和少量必要端口，范围没那么散。
AWS帳號快速認證 3. packets 少、连接多，不等于无害
很多扫描的每条记录 bytes 并不高，甚至只有几十字节到几百字节，但 packets 和连接条数会非常多。这种情况下，单纯看流量图会低估风险，因为它的目标不是搬运数据，而是枚举目标和确认存活状态。尤其在横向移动前，攻击者常常先做存活探测，再尝试登录或利用漏洞，整个过程在 Flow Logs 中会表现为大量短连接、低流量、高离散度。
所以，分析内网扫描时，别只盯着总字节数。看“连接次数”“目标数量”“端口数量”“拒绝比例”同样重要。很多时候，正是这些看起来不大的数字，把一次入侵的前半段暴露出来。
五、实战排查：从现象到根因
真正落地时，建议按“先缩小范围，再确认性质，最后串联上下文”的顺序来做。不要一开始就翻全量日志，那样只会浪费时间。先从监控告警、费用异常、带宽飙升、应用卡顿、实例 CPU 异常、连接数异常这些现象切入，再用 Flow Logs 把可疑主机和时间窗口圈出来。
AWS帳號快速認證 1. 先找时间窗口
任何分析都要先定位时间。比如某台数据库服务器在 2 点到 3 点之间出站流量明显增大，那就把查询范围先锁在这个小时内。因为 Flow Logs 数据量大，时间窗口越精确，越容易看出模式。很多攻击并不是全天候存在，而是会在业务低谷时发力，试图避开人工巡检。你只要把问题时段抓准，线索会清晰很多。
2. 再找“异常主机”
按 srcaddr 和 dstaddr 分别聚合 bytes、packets 和连接数，找出明显偏离基线的主机。对于出站异常，重点看 srcaddr；对于被扫描或被攻击的对象，重点看 dstaddr。找主机时不要只看绝对值，还要看相对位置。某些大机器本来流量就大，但它的模式稳定；真正异常的主机，往往是在短期内突然冲到排行榜前列，且伴随连接结构变化。
3. 再做横向关联
找到可疑主机后，继续看它在同一时间段是否还访问了其他资产。比如一台跳板机先连了多台服务器的 22 端口，随后又去碰数据库端口和文件共享端口，这种串联就很像横向移动。再结合服务器侧的登录日志、进程启动日志、任务计划、容器编排事件，就能判断它是在正常运维，还是已经被利用。
如果发现某个主机先对外建立高流量连接，随后开始在内网横扫多个地址，这通常说明它可能先被控，再被用作跳板或扫描器。这个前后顺序很重要，因为它决定了你要先隔离哪台机器、先保留哪部分证据。
六、用 Athena、CloudWatch Logs Insights 思路做分析
不管你用的是 Athena 还是日志查询工具，核心思路都一样：先聚合，再排序，再过滤。对于大流量攻击，先按时间窗口统计 srcaddr 的 bytes 总和；对于内网扫描，先按 srcaddr 统计不同 dstaddr 的数量，再统计不同 dstport 的数量；对于拒绝探测，则筛出 action=REJECT 的记录，观察是否集中在某些目标或端口。
如果你习惯做表格化分析，可以把同一时间段的日志导出后，按源地址、目标地址、端口、字节数和包数做透视汇总。很多异常模式在原始日志里看不清，汇总后却一目了然。比如某个源地址访问了 200 个目标 IP，但每个目标只发了 1 到 2 条记录，这种“广撒网”的特征，一眼就能认出来。
查询时还要注意两个细节。第一，日志可能有延迟，不要只盯着实时窗口的一小段结果，适当往前后扩 10 到 15 分钟，避免漏掉前奏和尾声。第二，记录不完整时要谨慎解释，如果 log-status 显示丢失或未记录完全，说明高峰期可能出现采样或投递问题，这时更要结合其他监控源交叉验证。
七、发现异常后，应该怎么处置
分析的最终目的不是“知道发生了什么”，而是“尽快止损”。一旦 Flow Logs 指向异常大流量或内网扫描，处置顺序通常应该是：先控制扩散，再保留证据，最后做根因修复。很多团队一上来就删机器、重建环境，结果把关键线索一起清掉，后续复盘很难做实。
如果是大流量外联，先确认是否存在数据外传、挖矿、下载器、代理转发或远控通道，再决定是否隔离实例、收紧安全组、阻断异常目的 IP。如果是内网扫描，优先检查源主机是否异常、是否存在可疑进程、定时任务、脚本、容器或凭证泄露，再根据风险范围限制该主机对其他网段的访问。对于已经确认被滥用的主机，务必保留磁盘快照、内存证据和相关日志，避免事后无法还原。
更重要的是，把这次事件沉淀成规则。比如哪些 dstport 在你们环境里本就不应该被访问，哪些 srcaddr 应该固定、哪些大流量属于正常任务，哪些网段之间不允许互通。Flow Logs 的价值不只是事后调查，更在于把这些判断标准变成长期规则。只要标准清楚，下一次异常出现时，你就不会再从零开始。
八、把 Flow Logs 变成日常防线
很多团队对 Flow Logs 的态度，停留在“出事以后再查”。这样做当然能救急，但不能真正提升防护能力。更好的方式，是把它变成日常基线的一部分。你可以为关键子网建立常见通信画像，记录正常的源、目的、端口、流量范围和时间段，定期回看是否有偏移。只要基线建立起来，异常就不再是模糊感觉，而是可量化的偏差。
对于互联网入口、跳板机、数据库子网、文件交换区和生产核心网段，建议分别建立不同的观察重点。入口侧重点看外部来源和高频拒绝；数据库侧重点看异常源、异常端口和跨网段访问；生产核心网则重点看突发出站流量和未经授权的东西向通信。分层看，才不会让一张日志表承载所有期待。
归根结底，VPC Flow Logs 不是用来“证明系统安全吗”，而是用来告诉你“流量行为有没有偏离常识”。一旦你把常识建立起来，异常大流量攻击和内网扫描就不再神秘。它们会在记录里露出各自的轮廓：大流量会在 bytes 上失控，扫描会在目标和端口上失控，而真正熟练的攻击者，只是试图把这两种失控藏得更深一点。日志不会替你做判断，但它会给你最可靠的起点。
