遇到 CC 攻击时，多数站长第一反应是「能不能查到是谁」。本文用 9 个问答讲清 CC 攻击溯源的真实能力边界、需要提前固定的日志证据、从 ASN 与 UA 指纹读出攻击工具画像的方法、代理池与秒拨 IP 的区分依据，以及哪些反制动作会踩到法律红线。
Q：CC 攻击真的能查到源头吗？
先把三件事拆开，不要混为一谈：
- 查到源 IP：几乎一定查得到，但 CC 的源 IP 基本是代理池、秒拨 IP 或被感染的设备，本身不等于攻击者。
- 查到攻击资源：多数情况可以，能判断对方用的是固定 IP 段、代理池，还是秒拨 IP 加无头浏览器。
- 查到自然人：极难。通常需要域名、支付、账号等现实线索，并须由执法机关依法调取，服务商和站长都没有这个权限。
所以实战里 溯源目标应定在「查清攻击资源与工具画像」，据此调整防护与成本策略，而不是期待一键定位到人。凡是宣称能一键溯源到真人的工具，都要保留怀疑。
Q：溯源前必须先固定哪些证据？
取证的前提是日志本身站得住脚，三个条件缺一不可：
- 字段完整：默认日志缺少溯源需要的耗时与代理头信息。
- 时间可信：服务器时间未同步，就永远无法和 CDN、WAF 侧日志对齐。
- 未被篡改：日志要异地或远端留存，攻击期间别在同一台机器上边打边改配置。
# 1) 补齐日志字段（nginx.conf 的 http 段）
log_format forensic '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" "$http_user_agent" '
'rt=$request_time urt=$upstream_response_time '
'xff="$http_x_forwarded_for" host="$host"';
# 2) 确认时间已同步
timedatectl status | grep -E 'System clock|NTP'
chronyc tracking 2>/dev/null | head -3
# 3) 日志至少保留 90 天并压缩归档
/var/log/nginx/access.log {
daily
rotate 90
compress
dateext
}关键点：字段要在攻击发生前就补齐。出事后再改配置，之前那段时间的日志永远是残缺的，补不回来。
Q：怎么从日志里看出攻击来源属于哪一类？
不要一个个看 IP，要按维度做聚合。最有信息量的四个维度是 ASN、C 段、UA、请求间隔：
# Top 30 源 IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30
# 把 IP 映射到 ASN 与归属，看来源是否集中在少数运营商
awk '{print $1}' /var/log/nginx/access.log | sort -u \
| head -200 | while read ip; do echo "$ip $(whois -h whois.cymru.com " -v $ip" | tail -1)"; done
# Top UA（判断工具画像）
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20读法很直接：IP 高度集中在 IDC 段，是代理性攻击；分散在住宅与移动网段，多为被感染设备或秒拨 IP。UA 只有两三种且高度集中，说明是同一套脚本；UA 版本跨度极大，说明对方在轮换工具或做了伪造。
Q：代理池和秒拨 IP 怎么区分？
只看两个数就够：独立 IP 数量和单 IP 平均请求数。
- 代理池：IP 数量多，但每个 IP 请求数少且 ASN 高度分散，还常带异常代理头（多个
Via、X-Forwarded-For链路过长）。 - 秒拨 IP：同一 C 段短时间大量 IP 轮换，每个 IP 只活跃几分钟，归属是境内运营商但反向解析落在 IDC 段。
- 固定 IP 段：IP 少、每 IP 请求数极高、持续数小时不换，最容易被 ipset 直接封掉。
# 统计「IP 数 / 请求数 / 每 IP 平均请求数」
awk '{c[$1]++; n++} END {print "unique_ips="length(c), "requests="n, "avg="n/length(c)}' \
/var/log/nginx/access.log这个比值就是攻击成本结构的指纹。平均值低于 5，说明对方在大量轮换 IP，单靠封 IP 收益很低，应转向行为层拦截；平均值高于 500，说明资源很便宜，直接封段即可。
Q：UA 和请求指纹能提供什么线索？
指纹给出的是工具画像，不是人的身份，但对防护非常有用：
- UA 与真实浏览器特征不匹配：UA 写着最新版 Chrome，但 TLS 指纹（JA3）是 Go 或 Python 客户端。
- 头信息残缺：缺少
Accept-Language，Accept-Encoding只有一种，从不携带 Cookie。 - 版本陈旧且集中：整批请求都用同一个老版本 UA，是脚本框架的默认值。
把这些特征写成规则，就能从「封 IP」升级到「拦工具」。例如 Nginx 里按 UA 与缺失头做初筛，再把 UA 落到独立日志持续观察，比一次性黑名单更稳。要注意 UA 可被任意伪造，它只能作为加权信号，不能作为唯一判据。
Q：能不能主动反制攻击者？
不能，而且这条线很清楚。主动回击、反向扫描对方主机、挂马或植入、发起对等流量攻击，都可能构成违法，还会把你自己从受害方变成违法方，同时暴露源站。合法且有效的动作只有这些：
# 带超时的自动封禁，到期自动解封，避免长期误伤
ipset create ccbl hash:ip timeout 3600
iptables -I INPUT -m set --match-set ccbl src -j DROP
# 命中可疑特征时加入黑名单
ipset add ccbl 203.0.113.10 1800- 止损类：限速、加并发上限、下发行人机验证、切清洗。
- 取证类：日志封存、哈希校验、时间线整理、证据包输出。
- 上报类：向云服务商提交攻击 IP 清单，向网警或 CNCERT 报案并提供证据包。收到敲诈勒索信息时，务必保留原始记录并直接报案。
核心原则：把取证结果用于提升攻击成本，而不是用于报复。
Q：什么情况下才值得花时间做完整溯源？
溯源是事后成本，不是应急手段。先判断性价比，满足两条以上再投入：
- 攻击持续超过 3 天，不是一次性脉冲。
- 有明确商业指向：同行竞争窗口期、伴随敲诈信息、关键业务发布节点。
- 损失可量化：能给出订单损失、退款、带宽超量的具体金额。
- 需要配合报案或平台申诉，必须有成体系的证据材料。
不满足上述条件时，正确顺序是先止损（限速、封禁、清洗），再谈溯源。攻击进行中花时间做分析，本身就是被牵着走的次优选择。
Q：一套完整的取证流程该怎么做？
五步走，每一步都留有产物，避免做完发现取证不可用：
- 第一步 固化环境：确认时区与 NTP 同步状态，记录服务器当前时间。
- 第二步 完整提取：把轮转过的
.gz一并取出，覆盖攻击全时段，不要只取当天。 - 第三步 归一化统计：按 IP、ASN、UA、目标路径、分钟级时间桶分别聚合，形成时间线。
- 第四步 三方交叉：源站日志、WAF 日志、CDN 日志对齐同一时间窗，确认拦截前后的真实到达量。
- 第五步 封存输出：生成证据包并做哈希，保证事后不可否认。
# 打包并生成校验值，便于后续比对与提交
tar czf cc-attack-evidence-$(date +%Y%m%d).tar.gz /var/log/nginx/access.log*
sha256sum cc-attack-evidence-*.tar.gz > cc-attack-evidence.sha256
# 统计攻击峰值时段，供报案材料引用
awk '{print substr($4,14,5)}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10递交材料时，时间线加原始日志加校验值这三样比任何分析结论都更有说服力。
Q：还有什么补充建议？
- 溯源的前置是防护。先把默认限速、UA 初筛、并发上限做好，攻击频率下降后取证难度也同步下降。
- 日志是资产，保留 90 天以上并异地存放。等出事那天才开始找日志，基本什么都找不到。
- 别在线上做取证实验，尤其不要为了复现而放开限速或关闭 WAF，那是给攻击者送礼。
- 不要过度承诺。向老板或客户汇报时，说清能查到资源画像、难查到自然人，比事后解释要轻松得多。
一句话总结：CC 攻击溯源的真实价值，是搞清对手在用哪一档成本的资源，然后把防护做到让那一档资源失效。