DDoS攻击溯源实战：三步用IP查询锁定攻击源ASN与地理位置

凌晨两点接到电话，一台出口防火墙被攻击流量打满，业务监控连续告警，带宽直接飙到接近8Gbps。登录设备一看，TCP SYN包像潮水一样涌进来，几百万条半连接堆在连接表里，正常用户根本排不上队。那一刻真正体会到一句话：抗D不光是扛流量，更关键的是搞清楚这批流量从哪来，怎么让它停下来。这个“搞清楚从哪来”的过程，就是DDoS攻击溯源。

我们常说的DDoS攻击溯源，本质上没有想象中那么玄乎，就是基于网络流量和日志记录，一步步缩小攻击来源的范围，直到锁定到某个运营商、某个机房，或者某个具体网段。我在实际处置里用的方法，概括下来就是三步：先从日志和抓包里提取攻击IP；再用IP查询工具把IP归属到对应的ASN自治系统号和地理位置；最后根据归属结果做横向关联，确认处置和封禁方案。整个过程熟练之后，十分钟之内就能跑完第一轮。

这篇文章就把我这套“三步用IP查询锁定攻击源ASN和地理位置”的完整方法写出来，里面有具体的命令、工具选型、参数解读，也有这几年踩过的一些坑。适合正在学安全运营、应急响应的朋友，也适合被DDoS打得焦头烂额、想快速摸清攻击底细的入门运维。

1. 为什么溯源到ASN和地理位置，就够用了

刚开始做安全的朋友容易有一个误区：以为DDoS溯源就是要揪出攻击者本人，拿到他的真实姓名、身份证号、门牌号。坦白说，在现实对抗里这个目标基本不成立。攻击者往往躲在肉鸡、代理池、反射服务器后面，你看到的每一个源IP，可能都只是被利用的工具，而不是攻击者的主机。所以实战中的溯源目标要现实得多：定位到“哪个网络的机器在打我”，然后去找这个网络的运营方要说法、做封禁、拉黑，让流量尽快停下来。

ASN就是对“哪个网络”这一问题的标准答案。ASN全称是Autonomous System Number，自治系统编号，它标识了一个拥有独立路由策略的网络实体。简单理解，互联网是由无数个“自治系统”拼起来的，每个运营商、每个大型IDC、每个云厂商都有自己的ASN。一个ASN下面通常挂着几十上百个网段，所有从这些网段出去的流量，在BGP路由表里都会归到这个ASN名下。所以当我们说“攻击来自AS64500”，其实就是在说“攻击流量来自AS64500这家机构管理的网段”。

那地理位置又是怎么回事？IP地理定位并不是GPS级别的精确坐标，它是根据whois注册资料、路由节点延迟测量、运营商公开数据综合估算出来的，一般精确到城市就算不错了。它的价值在于提供另一个维度的判断依据。比如你看一个IP查出来属于某国某城市的住宅宽带段，另一个IP查出来属于某云厂商的数据中心段，通过这种差异你就能推测攻击流量大概率的组成结构：是僵尸网络打过来的，还是被人租用云主机打过来的，又或者是某个机房被入侵后成了跳板。这和IP查询得到的ASN信息相互印证，比单看一项要靠谱得多。

再说回三步法的设计思路。整个流程的核心哲学是“逐层收敛”。第一步从海量流量里提取攻击IP，本质上是把“全网的流量”收敛成“一小撮可疑源地址”；第二步做IP查询，是把“一小撮IP”映射成“少数几个ASN和地理区域”；第三步做横向关联和确认，是在“少数几个责任方”里找到最有把握的处置对象。每一步的输入输出都很明确，不容易乱，也方便让团队里其他人接手。

这套方法还有一个额外的好处：不依赖任何商业威胁情报平台。虽然现在很多安全设备都带威胁情报功能，但实战里总会有情报覆盖不全的情况，尤其是一些新建的IDC段、刚启用的云供应商网段。用IP查询工具直接查ASN和地理归属，是零成本、随时可用、任何环境都能跑的兜底方案。学会这套基本功，比只会看情报平台要稳得多。

2. 动手前的准备：日志、工具与基础概念

2.1 从哪拿攻击IP：核心思路是“聚合”而不是“单看”

有些朋友是从Armbian板子怎么查公网IP、或者Windows命令行里怎么ping通局域网IP找到这篇文章的，那些属于单机单点的连通性排查，和我这里要讲的DDoS溯源完全不是一个量级。DDoS场景下流量是海量的，一个攻击IP往往会在短时间内产生成千上万条请求记录，所以你不能一条一条去看，核心方法是“聚合统计”：把日志里所有IP的出现次数做一个排序，次数最高、流量最大的那批，就是需要重点关注的攻击源。

数据来源一般有三个。第一个是边界设备的会话日志，比如防火墙的LOG、路由器的NetFlow/sFlow，这类数据能看到五元组和流量大小，最适合做流量型攻击的分析；第二个是业务层的访问日志，比如Nginx、Apache的access log，适合分析CC攻击和应用层攻击；第三个是自己抓包，也就是用tcpdump在出口或服务器网卡上抓一段时间的原始报文，适合在设备和日志都没有覆盖到的时候做临时取证。

举个例子，假设你有一台Nginx服务器正在被刷，最简单的办法是直接对access.log做统计。我在应急的时候常用这几行命令，先看Top IP：

# 按IP出现次数排序，取前20个 awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

如果是抓包场景，可以用tcpdump抓SYN包再统计源IP：

# 抓取80端口TCP SYN包，保存到文件 tcpdump -nn -i eth0 'tcp port 80 and tcp[tcpflags] & tcp-syn != 0' -c 100000 -w /tmp/syn.pcap # 从pcap里读取并统计源IP tcpdump -nn -r /tmp/syn.pcap 2>/dev/null | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

注意tcpdump输出里源地址那一列的格式可能是“1.2.3.4.12345”，也就是IP后面直接跟端口，用点分隔，所以要用cut -d. -f1-4把端口去掉。这个细节不注意的话，统计出来的结果会乱成一团。

2.2 IP查询工具链与ASN的基础知识

拿到一串可疑IP之后，就需要把它翻译成ASN和地理位置。这里是我日常最常用的一组工具，全部免费、无需注册，适合应急时快速上手。

第一个是whois命令，这是最传统的查询方式，胜在随处可用。大多数Linux发行版默认没有装whois客户端，先装一下：

# Debian / Ubuntu apt install whois -y # CentOS / Rocky yum install whois -y

装好之后，直接查询IP的注册信息：

whois 203.0.113.77

第二个是Team Cymru的IP-to-ASN服务，这是一线安全运营里非常常用的免费接口，可以直接返回IP归属的ASN、BGP前缀、注册国家和注册时间。它支持两种查询方式，一种是用whois客户端指向他们的服务器：

whois -h whois.cymru.com " -v 203.0.113.77"

另一种是用DNS TXT记录查询，适合写脚本批量跑：

dig +short 203.0.113.77.origin.asn.cymru.com TXT

返回结果类似这样：

"64500 | 203.0.113.0/24 | US | arin | 2020-01-01 | EXAMPLE-CLOUD"

解读一下字段：第一列是ASN号，第二列是这个IP所在的BGP前缀，第三列是注册国别，第四列是注册机构（arin对应北美，apnic对应亚太，ripencc对应欧洲），第五列是地址段分配时间，最后一列是ASN的名称。就这一条命令，溯源的关键信息瞬间齐了大半。

第三个是IP情报类的Web API，比如ipinfo.io，适合人工快速看一眼，也适合用脚本批量查。它的免费版就支持返回城市、区域、国家、经纬度、ASN和机构名：

curl -s ipinfo.io/203.0.113.77/json

返回的JSON里有一个字段叫org，形如AS64500 Example Cloud，把ASN和机构名直接打包给你，非常人性化。还有city、region、country这些字段，对应地理位置。

第四个是更精细的路由望远镜类平台，比如bgp.he.net、bgpview.io。在这些网站输入ASN号，能看到这个AS名下宣告的全部IPv4/IPv6前缀、上游和下游的Peer信息、在海外的接入点。这类信息对判断“这个AS是谁、规模多大、该找谁交涉”特别有用。

2.3 批量查询与自动化的小脚本

单查一两个IP用上面的命令就够了，但DDoS攻击往往涉及成百上千个IP。这种时候手敲命令会累死人，需要写一个简单的批量脚本。我把整个流程做成一个循环，每行一个IP，循环调用DNS查询接口，输出成表格。

#!/bin/bash # file: asn_lookup.sh # usage: cat ips.txt | ./asn_lookup.sh while read ip; do [ -z "$ip" ] && continue result=$(dig +short "$ip.origin.asn.cymru.com" TXT | tr -d '"') echo -e "$ip\t$result" done

这个脚本配合前面提取Top IP的步骤，可以实现“日志IP → 文件 → 批量ASN归属”的流水线。实测下来，几百个IP的查询几秒钟就完成了。唯一的注意点是DNS查询频率不要太高，尤其是IP多的时候，建议加个sleep 0.2限一下速，避免被解析服务临时限流。

这里也多说一句，有些团队会把ASN查询结果汇到Excel或者内部Wiki里，形成一个简单的“攻击来源ASN台账”。别小看这个台账，连续几次攻击之后你会发现自己所在业务的攻击来源高度集中，比如总是那两三个ASN的代理池在轮换。提前掌握这些信息，下一次再被打时，封禁策略可以提前备好，响应速度能快一大截。

3. 完整实操：用IP查询锁定攻击源ASN与地理位置

3.1 第一步：清洗并提取攻击IP，按流量特征排序

前面讲了工具的用法，这一节我完整走一遍实际案例。假设接到任务：某网站深夜遭遇到SYN Flood攻击，峰值带宽接近6Gbps，防火墙已经快扛不住了。我登录到出口网关，先用iptables的日志看一眼攻击来源的大致情况：

grep "DROP" /var/log/kernel.log | grep -oE "SRC=[0-9.]+" | sort | uniq -c | sort -rn | head -10

输出大概是这样：

532108 SRC=203.0.113.77 418822 SRC=198.51.100.23 390120 SRC=192.0.2.88 ...

这里能看到同一个IP的命中次数动辄几十万次，说明流量非常集中。用tcpdump再做一次现场抓包，确认协议类型和攻击特征：

tcpdump -nn -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 50000 -w /tmp/full_syn.pcap

抓包结果里如果几乎全部是SYN包、没有对应的SYN-ACK，那就基本可以断定是TCP SYN Flood，属于流量型攻击，不像CC攻击那样需要绞尽脑汁分析URI。这种情况下，提取出来的源IP只要不是随机伪造的，都可以作为后续溯源的对象。

这里有一个非常关键的分叉点：SYN Flood攻击里的源IP有可能是伪造的，也可能是真实的。判断方法很简单，看SYN包的来源IP是否分布在大量不同网段，如果来源IP乱七八糟、分布在一堆没有任何规律的地址段里，很可能是“随机源IP伪造”，这种情况下IP查询的溯源价值有限，主要靠流量清洗设备去处理；如果来源IP集中在某几个网段，并且这些网段能查得到合法的ASN归属，那说明攻击者是用了真实可控的机器在打，这种就可以放心做ASN溯源和封禁。

3.2 第二步：查询IP归属，锁定ASN与地理位置

拿上面Top1的203.0.113.77来做演示。先上Team Cymru的接口：

whois -h whois.cymru.com " -v 203.0.113.77"

返回结果：

AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 64500 | 203.0.113.77 | 203.0.113.0/24 | US | arin | 2023-06-01 | CLOUDHOST-AS

从这一行就能确认几个关键信息：这个IP归属于AS64500，BGP前缀是203.0.113.0/24，注册地区是美国、由ARIN管理，名称是CLOUDHOST-AS。这个ASN名称里带着“CLOUDHOST”，看起来是一个云主机服务商的网段，而不是某个家庭宽带用户，这一点信息量很大：攻击者很可能租用了这家云服务商的VPS来发起攻击。

接着用ipinfo.io确认地理位置和机构信息：

curl -s ipinfo.io/203.0.113.77/json

返回的JSON里关键字段是city、region、country和org。假设返回city: Ashburn、region: Virginia、country: US，那么攻击源的地理位置就被锁定到美国弗吉尼亚州阿什本，这是美国东部一个著名的数据中心聚集地。把ASN信息、机构名称、地理位置列在一起，一条完整的溯源链就出来了：

• 源IP：203.0.113.77
• 归属ASN：AS64500
• ASN名称：CLOUDHOST-AS
• 地理位置：美国弗吉尼亚州阿什本
• 所属机构类型：云服务商

然后对Top10的IP逐一执行同样的查询。你会发现一个规律：大部分IP要么集中在AS64500，要么集中在另外两三个ASN。攻击者的资源池再大，也往往是集中在固定的几个服务商里。这一步做完，攻击来源的整体轮廓已经出来了。

3.3 第三步：横向关联攻击面信息，确认处置方向

锁定ASN之后，不要急着封IP，先做横向关联，把信息吃透。我通常会做四件事。

第一件事，查这个ASN的所有前缀。去bgp.he.net搜索AS64500，能看到这个AS名下宣告的所有CIDR段。如果攻击流量来自203.0.113.77，而这个AS名下还有一个203.0.113.128/25段也在同时段内产生了大量攻击流量，那说明攻击者控制了该服务商内不止一台机器，封禁策略就要考虑动整个子网，而不是只封一个IP。

第二件事，用Shodan或Censys做背景信息调查。查一下这个IP的开放端口、历史域名、反向DNS记录，判断它是纯代理、被入侵的Web服务器，还是其他类型的跳板设备。比如反向DNS解析出来是“proxy.xxx.net”，那基本能确定是代理节点；如果是开放了22端口和8080端口的裸机，大概率是攻击者租来临时用的。

第三件事，去PeeringDB查ASN的运维联系人信息。这个平台相当于网络运营方的“黄页”，输入ASN号就能看到运营方的NOC邮箱、电话号码、机房位置。这一步的产出是沟通渠道，后续要向服务商投诉、要求对方关停攻击机器时，这个邮箱和电话就是正式的联络入口。

第四件事，判断IP的“纯净度”。这里的“纯净度”是指这个IP归属的类型：是云服务商的数据中心段，还是家庭宽带段，还是一个大学的教育网段。不同来源的攻击IP对应不同的处置方式。数据中心段通常是恶意租用，可以联系服务商处理；海外僵尸网络的大范围扫描，一般靠情报平台识别后交给上游清洗；如果是教育网段、政企网段这种大规模机构，基本可以判断是被入侵后的跳板，要尽量把样本和时间线整理清楚，发给对应机构的CERT做进一步处置。

做完这些横向关联，最终处置方案也就顺理成章了。对于ASN集中、且确认是同一家云服务商的情况，我的习惯是先在本机做紧急封禁，保住业务再说。如果边界防火墙支持GeoIP过滤，可以直接把对应国家的流量进行限速或封禁；如果只想封特定网段，用防火墙或ipset做段级封禁最直接。

# ipset段级封禁示例 ipset create attack_block hash:net timeout 3600 iptables -I INPUT -m set --match-set attack_block src -j DROP ipset add attack_block 203.0.113.0/24

同时把ASN、攻击IP列表、抓包样本、时间线、流量统计整理成一份处置材料，发送给云服务商的滥用投诉邮箱（abuse邮箱）和PeeringDB上的NOC联系人，要求对方在自身网络内对攻击源进行隔离。

4. 常见问题与排查技巧实录

4.1 高频问题速查表

溯源这个环节看起来简单，真到了现场各种意外情况特别多。我把这几年遇到的高频问题整理成了一张表，按“现象 → 原因 → 处理建议”的方式列出，方便应急时快速对照。

这里面最容易误导人的就是反射放大攻击。DNS放大、NTP放大、SSDP放大这类攻击的特点是攻击者以小流量触发开放服务器，让服务器把大流量“反射”到受害者头上。你看抓包，看到的源IP全是那些开放DNS或NTP服务器的IP，但这些服务器本身是无辜的，真正要管的是触发流量的人。遇到这种情况，还去一封一个地拉黑反射源IP，不仅没意义，还会累死网络设备。正确的做法是把清洗策略调整成“限制对应端口或协议的入向流量”，同时向上游运营商申请黑洞或流量清洗，把攻击流量在骨干网侧就消化掉。

4.2 实战中的避坑要点

第一，日志时间必须对齐。不同设备的日志时区不一定相同，有的设备用UTC时间，有的用本地时间，还有的只记录启动以来的秒数。做溯源时如果你连攻击时间窗口都对不齐，后面的关联分析就容易串台。我在做应急响应时要求所有参与设备的日志统一用UTC记录，输出到日志平台时再统一转换，这个习惯能避免掉一半以上的工期延误。

第二，封禁按“段”不要按“点”。打完DDoS之后，攻击IP往往会在同一个ASN下面换着IP继续打。你只封死203.0.113.77，它下一波可能就换203.0.113.88继续打。所以IP查询得到ASN之后，快的处置动作是直接对这个ASN下的活跃攻击段做临时封禁，再观察是否还有漏网的。当然要留个心眼：对大型运营商的ASN要谨慎，一个ASN可能广播了几千个网段，误封会伤及无辜。我的判断标准是，先用流量统计确认攻击IP是否集中在少数几个前缀段，再针对这些段做封禁。

第三，保留原始证据。所有抓包文件、日志截图、命令执行的输出结果，都要保留原始状态，不要随手改。后续涉及向上游运营商投诉、给服务商提交工单，甚至走法律途径，这些原始证据都拿得出手。应急结束后，把这些材料归档保存一段时间，别图省事直接删。

第四，IPv6别忽略。现在有相当一部分攻击流量已经走IPv6了，用前面team-cymru的查询方式对IPv6同样有效。Linux上dig命令对IPv6的格式稍微有点差异，但whois -h whois.cymru.com " -v 2001:db8::1"的格式完全一样。网关、防火墙、IDC出口的日志采集都要确认v6流量有没有被记录，别等攻击来了才发现v6日志是空的。

第五，不断积累自己的“黑名单账本”。每次溯源获得的ASN、网段、IP列表不要用完就丢，整理成自己的威胁数据沉淀下来。下一次再碰到类似攻击时，你会发现自己能秒判攻击来源。这个账本可以是内部某个知识库，也可以是一张持续更新的Spreadsheet，形式不重要，重要的是持续维护。

5. 最后的一点经验之谈

做DDoS溯源这几年，我最大的体会是：溯源从来不是目的，止损才是。不要沉浸在“揪出幕后黑手”的执念里，实战环境里更多时候你只要锁定了攻击来自哪个ASN、经过哪个机房，就已经有足够底气去做封禁、联系上游、写处置报告了。那套“把IP翻译成ASN和地理位置”的基本功，看起来简单，真正遇到攻击时你会感谢自己平时练过。

再分享一个小技巧吧。我会把整个溯源流程的常用命令封装成一个shell脚本，并带一个简单的帮助菜单。脚本里从上到下依次是：日志IP提取、批量ASN查询、地理信息查询、ipset封禁生成、处置报告模板生成。每次应急只需要在脚本里替换日志路径和关键参数，就能快速跑完整套流程。碰到深夜被攻击电话吵醒的时候，有这套脚本在手，处理速度会快得多，困意也能减轻几分。希望这篇东西能给正在和DDoS纠缠的你一些参考。