CC防御服务攻击事件的完整记录留存，核心价值不在于“存了多少日志”，而在于能否从原始流量和防护动作中还原攻击路径、判断防御有效性，并为后续策略调优提供可追溯依据。很多运维团队在攻击结束后只保留了一份“攻击发生了”的结论，却丢失了时间线、样本和处置节点，导致下一次同类攻击依然被动。真正有意义的记录留存，需要同时覆盖攻击特征、防御触发、误封情况、源IP行为、请求内容以及最终效果评估六个维度。

攻击事件记录的第一步是确定时间基准。所有日志必须使用统一的NTP同步时间戳，精度至少到毫秒。如果服务器时间与CDN或高防节点时间不一致，后续做关联分析时会出现严重错位。建议在攻击开始前就强制所有节点启用同一时区，并在日志中同时记录UTC时间和本地时间。攻击期间每一分钟都可能产生数十万条请求，时间戳混乱会让整个留存记录失去分析价值。

流量层的记录应包含源IP、目标域名、目标URL、请求方法、User-Agent、Referer、请求体大小、响应状态码、响应耗时以及是否命中CC防护规则。仅记录被拦截的请求远远不够，放行的请求同样重要。很多CC攻击会混合正常请求和恶意请求，如果只留存拦截日志，就无法判断是否存在漏防。完整记录应区分“拦截”“挑战通过”“直接放行”三类结果，并保留挑战验证的通过率。

针对CC攻击最核心的特征是请求频率和路径分布。留存记录中需要单独生成每个源IP的请求速率曲线，建议按秒、分钟、五分钟三个粒度聚合。攻击源可能在短时间内爆发，也可能以低频慢速方式持续消耗资源。低频CC攻击往往每IP每分钟只发几个请求，但控制成千上万个IP同时发起，单看某一时刻并不突出，只有长时间聚合才能发现异常。因此留存数据至少要覆盖攻击前24小时到攻击结束后48小时，便于对比基线。

源IP的威胁情报关联也是留存的重要组成部分。记录中应包含IP归属地、AS号、是否属于IDC机房、是否出现在公开威胁情报库中、历史攻击记录等。很多CC攻击源来自云主机或代理节点，这些IP的AS信息往往高度集中。留存时可以按AS号聚合统计，快速识别攻击基础设施。对于家庭宽带IP发起的攻击，需要额外记录其是否通过HTTP代理或浏览器指纹异常来判断是否为肉鸡。

请求内容的留存不能只存URL，必须包含完整的请求头和请求体样本。CC攻击中大量请求可能针对搜索接口、登录接口、动态页面或数据库查询接口。留存请求体样本有助于判断攻击是否针对特定业务逻辑，例如恶意构造的搜索关键词导致后端高负载。建议对攻击期间的请求体做哈希去重，保留Top 100的样本内容，并记录每种样本的出现次数和占比。这样既能控制存储成本，又能还原攻击载荷特征。

防御动作的记录需要精确到规则级别。每次触发CC防护时，应记录触发的是哪条规则、规则阈值是多少、命中的具体条件是什么。例如“单IP 60秒内请求超过200次触发JS挑战”或“单IP对同一URL请求超过50次触发验证码”。留存这些信息可以评估规则是否过于宽松或过于严格。如果攻击期间大量正常用户被误封，说明规则阈值需要调整；如果攻击流量穿透，说明阈值设置过高或规则匹配维度不足。

误封率的记录往往被忽略，但它直接关系到业务可用性。留存记录中应包含被拦截IP的后续行为，例如是否完成了JS挑战或验证码，完成后的访问是否恢复正常。如果大量真实用户无法通过挑战，说明挑战机制本身存在问题。可以单独统计挑战通过率、验证码通过率、被拦截后用户重试次数等指标。对于误封严重的时段，需要回溯对应规则并标记为待优化。

攻击事件的时间线记录要像作战日志一样完整。从监控告警触发开始，到人工介入、策略调整、攻击流量变化、攻击停止、后续观察，每个节点都要有时间戳和操作内容。例如“14:32 监控发现目标域名QPS从800突增至15000”“14:35 开启CC防护紧急模式”“14:40 攻击流量下降至3000 QPS”“15:10 误封率上升，调整阈值”“16:00 攻击停止”。这些记录能帮助团队复盘响应效率，也能在向上级汇报时提供清晰依据。

留存攻击样本时，建议使用pcap包和HTTP日志双轨制。pcap包能保留完整的网络层和传输层信息，适合分析TCP连接行为、TLS指纹、包大小分布等特征。HTTP日志则更适合业务层分析。pcap包可以按攻击峰值时段截取，不必全程抓取，否则存储压力过大。一般建议在攻击确认后立即启动抓包，持续抓取至少30分钟，覆盖攻击最猛烈的阶段。抓包文件按时间切片保存，每个文件不超过1GB，便于后续分析。

对于使用CDN或高防服务的场景，留存记录需要与服务商的数据打通。很多服务商只提供简化的攻击报表，不开放原始日志。建议在合同中明确要求提供攻击期间的完整访问日志导出能力，包括被拦截和放行的请求。如果服务商无法提供原始日志，至少要求提供按分钟聚合的流量统计、拦截统计和Top源IP列表。否则一旦攻击结束，本地只能看到回源流量，无法完整还原攻击全貌。

日志存储的格式和索引方式直接影响留存记录的可用性。建议使用JSON格式存储，每条日志包含统一字段名，避免不同系统字段不一致。对于大规模攻击，单日日志可能达到数百GB，需要提前规划存储周期。攻击事件日志建议保留至少90天，核心样本和pcap包保留30天。存储时按域名和日期分目录，建立索引文件记录每个文件的起止时间和日志条数，方便快速检索。

留存记录中还需要包含攻击对业务影响的量化数据。例如攻击期间网站响应时间从平均200ms上升到5000ms，订单转化率下降多少，用户投诉量增加多少，服务器CPU和内存使用率变化等。这些数据能直观说明攻击造成的实际损失，也是评估防御投入产出比的重要依据。很多团队只记录技术指标，忽略了业务指标，导致事后无法向管理层说明防御服务的价值。

攻击结束后的复盘报告是留存记录的最终产出物。报告应包含攻击概述、时间线、攻击特征分析、防御效果评估、误封情况、业务影响、存在的问题和改进建议。报告不是简单的日志堆砌，而是从留存数据中提炼出结论。例如“本次攻击主要利用HTTP Flood针对搜索接口，峰值QPS达到3.2万，防御系统成功拦截92%的恶意请求，但误封率偏高达到8%，主要原因是JS挑战对移动端兼容性不足”。

在实际留存操作中，可以编写自动化脚本定时采集和归档关键数据。以下是一个简单的日志归档脚本示例，用于按小时切割并压缩攻击日志：

#!/bin/bash
# CC攻击日志按小时归档脚本
LOG_DIR="/var/log/nginx"
ARCHIVE_DIR="/data/cc_archive"
DOMAIN="example.com"
DATE=$(date +%Y%m%d)
HOUR=$(date +%H)

mkdir -p ${ARCHIVE_DIR}/${DATE}

# 复制当前小时日志并压缩
if [ -f ${LOG_DIR}/${DOMAIN}.access.log ]; then
    cp ${LOG_DIR}/${DOMAIN}.access.log ${ARCHIVE_DIR}/${DATE}/${DOMAIN}_${HOUR}.log
    gzip ${ARCHIVE_DIR}/${DATE}/${DOMAIN}_${HOUR}.log
    # 清空当前日志（需根据实际日志轮转策略调整）
    > ${LOG_DIR}/${DOMAIN}.access.log
fi

# 记录归档文件信息到索引
echo "${DATE} ${HOUR} ${DOMAIN}_${HOUR}.log.gz" >> ${ARCHIVE_DIR}/index.txt

这个脚本可以根据实际环境调整日志路径和归档策略。关键是要保证归档动作在攻击期间也能稳定执行，不能因为日志量过大导致脚本阻塞或磁盘写满。建议在攻击前就测试归档脚本的性能，确保单小时日志量达到10GB以上时仍能在几分钟内完成压缩归档。

对于留存数据的查询分析，建议使用命令行工具快速聚合关键指标。例如统计攻击期间每个源IP的请求数，可以用以下命令处理归档日志：

# 统计每个源IP的请求总数（从解压后的日志中提取）
zcat ${ARCHIVE_DIR}/20250115/*.log.gz | \
    awk '{print $1}' | sort | uniq -c | sort -rn | head -50

如果需要统计特定URL的请求频率，可以调整awk字段提取逻辑。这些基础命令在攻击事件分析中非常实用，能够快速定位Top攻击源和热点路径。留存记录的价值就在于能够随时用这些命令重新分析历史数据，而不是只能看服务商提供的固定报表。

CC防御服务攻击事件的完整记录留存，本质上是一套从采集、存储、分析到复盘的工作流。它要求运维团队在攻击发生前就建立好日志规范，在攻击期间持续采集多维数据，在攻击结束后系统化整理和归档。只有做到这些，留存记录才能真正成为下一次防御的决策依据，而不是躺在硬盘里的死数据。对于任何面向公网提供服务的业务，这套留存机制都应该作为安全运营的基础能力来建设。