- 明确目标:定义“秒解”度量(例如:检测到攻击后 30-60 秒内转入清洗或恢复正常流量)。 - 收集信息:服务器公网 IP、ASN、BGP 前缀、运营商联系人(紧急与日常)、API 文档、SLA/清洗阈值与计费方式。 - 文档化:把以上信息放在运维手册里并共享给值班与供应商对接人,设置紧急联系人群(电话+短信+工单)。
- 确认清洗触发点:和供应商约定流量阈值(pps、bps、连接数)以及触发方式(自动/人工)。 - 确认公告流程:了解供应商是否有 BGP 黑洞、转发到清洗中心或路由劫持流程,明确每一步所需时间与回滚条件。 - 要求 API/模板:要求供应商提供标准化 API 或工单模板以便快速发起清洗。
- 多线与Anycast:若可能,部署多出口(多运营商)或 Anycast IP 来分散攻击面。 - BGP 社区与前缀调整:确认供应商支持哪些 BGP community 用于流量导向或降级,测试 announce/withdraw 流程并记录耗时。 - 黑洞与清洗切换:与供应商演练一次“announce 到清洗中心 → 回撤”过程,记录从下发到生效的延时。
- 打开 SYN cookies:sysctl -w net.ipv4.tcp_syncookies=1; - 提高 backlog 与队列:sysctl -w net.core.somaxconn=1024;sysctl -w net.core.netdev_max_backlog=5000;sysctl -w net.ipv4.tcp_max_syn_backlog=2048; - conntrack 调优:sysctl -w net.netfilter.nf_conntrack_max=2000000,并根据 /proc/sys/net/netfilter/nf_conntrack_count 监控使用率。 - 持久化:把上述放入 /etc/sysctl.d/99-custom.conf 并 sysctl --system。
- 基础拒绝策略:拒绝非必要端口,仅放行业务端口 + 管理端口(用白名单)。 - SYN 限速示例(iptables):iptables -A INPUT -p tcp --syn -m limit --limit 200/s --limit-burst 300 -j ACCEPT;其余 SYN 丢弃或标记。 - 基于 conntrack 限制:iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m recent --set;iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 200 -j DROP。 - 自动化下发:将规则脚本化并通过 Ansible/Cobbler 在多机上线。
- 监控指标:pps、bps、连接数、conntrack 使用、CPU、网卡队列、清洗触发次数。 - 告警策略:设置两级告警(阈值预警 + 紧急告警),并将紧急告警联动到供应商工单/API。 - 自动化:编写脚本在达到预警阈值时自动调用供应商清洗 API(含签名与幂等检测)并记录回执。
- 与供应商约定彩排时间,使用合规的流量发生器或供应商提供的测试服务进行演练(勿自行攻击公网上的其他目标)。 - 验证点:确认清洗开始时间、清洗是否影响正常流量、回退后业务是否恢复、日志与索引是否完整。 - 结果输出:写演练报告并固化到 SOP,调整阈值与流程。
问:如果发现流量瞬间飙升但供应商未能在预定时间内完成清洗,我应该怎样快速响应?
答:首先启动本地速率限制与临时黑名单(iptables/nftables),同时立即通过预设的紧急联系方式催促供应商开启清洗。若有多出口,临时 withdraw/announce 操作或切换到备用线路;并保存 pcap/log 供供应商定位。演练中要把这些步骤写入值班手册并训练值班人员。
问:清洗过程中常常会误伤正常用户,有没有具体的防护与验证流程?
答:设置灰度策略:先将清洗规则应用于可疑流量子网段并监控命中率;使用会话指纹(Cookie/Token)或应用层白名单识别正常用户;供应商清洗时要求保留应用层检测(HTTP header/URI 白名单)。演练时统计误杀率并把可接受阈值写入 SLA。
问:签长期合同时,技术与合同层面有哪些必须约定的要点?
答:合同中应约定清洗时延、清洗阈值、误杀赔偿、紧急响应时间、流量计费方式、API/工单响应 SLA。技术层面要求供应商提供 BGP 社区 切换、API 调用示例、日志导出与样本、定期演练与报告。保留退出与升级条款以便业务变化时调整策略。