被 DDoS攻击 之后，很多站长的第一个念头是「能不能报警」。本文用 10 个问答讲清被 DDoS 攻击要留哪些证据、怎么固定才有效、报案的现实预期、向机房与安全厂商申诉要什么材料、日志该留存多久，以及止血与留证的先后顺序。
Q：被DDoS攻击了，报警到底有没有用？
要分场景看，别抱不切实际的期待：
- 有实际作用的部分：一是拿到接报案回执，向机房、云厂商、支付与第三方服务商说明情况时有正式凭据；二是攻击源在境内、且有明确经济损失时，可以立案追责。
- 基本无解的部分：攻击源大量在境外、经过多层跳板与代理时，溯源与追责的现实难度极高。
- 最常见的结果：拿到的是受理记录，而不是破案结果。所以报案是维权手段之一，不能当成唯一的救命稻草。
结论是：先做好防护和止血，再谈报案与追责，顺序反过来只会耽误业务恢复。
Q：报案之前，必须先把哪三件事说清楚？
- 攻击事实：开始时间、持续时间、峰值带宽与峰值 pps、攻击源 IP 数量、攻击类型。
- 业务损失：不可访问的时长、影响用户数、订单或交易损失、是否被机房停机或产生额外计费。
- 攻击源特征：境内还是境外、集中在哪些 IP 段、是否带有勒索留言或联系方式。
这三件事说不清，任何渠道都推进不下去。建议提前做一份空白模板，出事时直接填空。
Q：必须保留的证据有哪些？
- 流量曲线原始数据：带宽与 pps 的时间序列，最好从云监控或 WAF 后台导出 CSV，而不是只截图。
- WAF 与防火墙拦截日志：原始文件，包含被拦截次数与被穿透次数。
- Web 服务器日志：
access.log与error.log原始文件。 - 数据包抓取文件：这是最关键的一份，原始报文可以交给第三方复现分析。
- 沟通与处置记录：机房或云厂商的通知邮件、工单编号、通知时间。
- 勒索型攻击的留言内容：攻击者的联系方式、勒索金额、留下的钱包地址。
Q：一份有效的数据包要怎么抓？
# 全量抓取，按 5 分钟切片，避免单个文件过大
sudo tcpdump -i eth0 -s 0 -w /data/ddos-%Y%m%d-%H%M.pcap 'tcp or udp' -G 300
# 只抓 SYN 包，体积极小，最适合证明 SYN Flood
sudo tcpdump -i eth0 -s 0 -w /data/syn.pcap 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'
# 按攻击目标端口过滤
sudo tcpdump -i eth0 -s 0 -w /data/port80.pcap 'tcp port 80'- -s 0 表示抓完整报文，截断过的包在事后分析时信息不全。
- -G 300 按时间切片，单文件过大既难传输也难分析。
- 抓包本身消耗磁盘与 CPU，不要长时间在已经被打满的机器上硬抓，优先在入口节点或镜像口抓。
Q：怎么证明这份证据没被改过？
证据的可信度取决于三件事：完整性、连续性和时间准确性。落地方法是立刻做哈希并归档到站外：
D=$(date +%Y%m%d_%H%M)
mkdir -p /root/evidence/$D && cd /root/evidence/$D
cp /data/*.pcap /var/log/nginx/access.log /var/log/nginx/error.log ./
sha256sum *.pcap *.log > SHA256SUMS
sha256sum SHA256SUMS > SHA256SUMS.txt
tar czf ../evidence-$D.tar.gz ./
# 再上传对象存储或拷到离线介质，本地副本随时可能被删掉- 时间必须可信：确认服务器校时正常（
chronyc tracking），日志时间统一到同一时区。 - 采样必须连续：中途停止采集会让时间线出现断点，说明力大打折扣。
- 哈希要随证据一起保存，后续任何人拿到文件都能自行校验。
Q：止血和留证冲突时，先做哪个？
顺序是先止血、再留证，但止血过程中不要销毁证据。上高防、切 CDN、请机房封端口都属于止血，这些动作本身不影响留证，真正危险的是下面这些操作：
- 直接删除或清空日志文件，等于把唯一的访问记录抹掉。
- 没抓包就重启服务器，内存里的连接表与未落盘日志会一起消失。
- 顺手执行日志或归档清理，把攻击时段的数据一起删掉。
稳妥做法是：止血前先做一次日志切分和一次数据包抓取，然后再动带宽和防护策略。
Q：除了报警，还有哪些更实用的维权路径？
- 向机房或云厂商申诉：附上攻击情况描述与已采取的自救措施，核心诉求是避免被停机、避免攻击流量计入账单。
- 向 CDN 或 WAF 服务商索取攻击报告：这份报告带时间轴与统计数据，比自己截的图有说服力得多。
- 民事路径：如果能证明攻击者与你有明确商业竞争关系、且造成了可量化损失，可以走律师函与诉讼。
- 平台举报：勒索留言里的联系方式与账号，可以向对应平台举报。
Q：向服务商要攻击报告，必须包含哪些字段？
- 攻击起止时间，精确到分钟。
- 峰值带宽、峰值 pps、攻击总流量。
- 攻击类型判定，例如 SYN Flood、UDP 反射、CC、混合攻击。
- TOP 20 攻击源 IP 及其 ASN 与归属地。
- 拦截次数与被穿透次数，是否出现过漏过。
- 是否触发清洗阈值或黑洞路由，以及触发的时间点。
关键原则：要原始数据和导出文件，不要只有截图，截图无法被核查。
Q：日志到底要留多久？
法规层面有底线，运维层面还要有自己的策略：
- 合规底线：网络安全法要求网络日志留存不少于六个月，所以别把日志保留期设成七天。
- 运维建议：近 30 天在线保留便于查询，更早的压缩归档到站外，总保留期 6 到 12 个月。
# logrotate：按天滚动、保留 180 天、压缩归档
/var/log/nginx/*.log {
daily
rotate 180
compress
delaycompress
missingok
notifempty
sharedscripts
postrotate
[ -f /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
endscript
}Q：还有什么补充建议？
- 提前准备好模板：一份攻击情况说明文档，出事时填空即可，紧张状态下人是想不起要写什么的。
- 立刻记时间线：首次发现时间、止血动作时间、恢复时间，事后回忆一定有偏差。
- 别指望报警解决问题：防护、申诉、留证三条路同时走，才是现实解法。
- 把源站藏好：证据能帮你维权，但藏源站加 CDN 兜底才能真正降低被打的概率。
- 定期演练一次：真的被打时再去翻文档，通常已经来不及。
一句话总结：被 DDoS 之后先止血、再留证、然后走申诉与报案；证据的关键是原始数据、连续采样、可信时间与哈希校验，日志至少留六个月，向服务商要报告要原始字段而不是截图。