值班人员遇到业务遭受攻击，标准处置五步法：确认告警、止损隔离、证据留存、根除恢复、复盘加固，每一步都有明确操作窗口和执行标准。这篇文章直接拆解每一步的动作和决策逻辑，不讲空话，只说你手边就能用的操作。
攻击发生后的第一个十分钟：黄金处置窗口
业务被打,最怕的不是攻击本身，是值班人员懵在原地，攻击流量不会等你开完会再决定怎么走，前十分钟的动作直接决定业务中断时长和损失范围。
第一步：确认告警，别把误报当攻击
国内一家大型云厂商的安全运营中心曾做过统计,值班团队接到的告警中，误报和重复告警占比在多数月份超过七成，所以收到告警，先别急着拔网线，按顺序做三件事：
- 打开监控大屏,确认业务可用性指标（响应时间、错误率、活跃会话数）是否真实下滑
- 登录服务器执行
top或uptime命令，看负载均值是否异常飙高 - 对比同一时间段的CDN日志和源站日志,判断是否是区域性网络波动引起的连锁告警
确认业务确实异常后,立即进入第二步。
第二步：初步判断攻击类型
DDoS流量型攻击的典型特征是入口带宽被打满，服务器CPU可能不高但网络入方向流量异常。CC/应用层攻击的特征是服务器CPU和连接数双高，netstat -ant | wc -l 命令显示的连接数远超日常基准线。
这个判断不需要多精确,只需要知道方向，方向对了，后续处置动作才有的放矢。
第三步：立即上报并同步信息
值班人员最忌讳的是一边处理一边独自扛着。标准动作是在判定攻击后的三分钟内，将以下信息同步给组长和应急响应群：
- 攻击开始的大致时间点
- 受影响的业务域名和IP列表
- 当前流量峰值和服务器负载
- 已执行的初步排查动作
同步信息用的模板应该是事先准备好的,平时就固化在值班手册里，紧急时刻直接往里面填数字，不要现场组织语言。
网站被攻击了怎么办？止损动作要分清主次
如果你在值班时问“网站被攻击了怎么办”，核心逻辑只有一条：先保业务可用，再谈追溯攻击者，优先级排序如下：
高优先级：切断攻击路径
- 启用云厂商的DDoS高防IP，把流量牵引到清洗节点，国内主流云厂商的控制台都有“一键切换高防”的按钮，日常值班必须熟悉操作路径，别等出事了再翻文档
-
配置WAF紧急规则，对攻击特征明显的IP段做临时封禁，封禁粒度建议先粗后细，攻击峰值期用
/16段封禁快速止血，业务恢复后逐步收紧到单个IP - 修改DNS解析TTL，从默认值调低到60秒，为后续的流量切换做准备
中优先级：控制系统资源
- 针对CC攻击,在Nginx层配置
limit_req模块，限制单IP的请求速率 - 针对连接数耗尽,调整系统内核参数
net.ipv4.tcp_max_syn_backlog，并开启SYN Cookie功能 - 数据库连接池调低上限,防止应用层雪崩拖垮数据库
低优先级：排查与溯源
止损完成、业务恢复后，才开始做日志分析和攻击路径还原，顺序反了，业务大概率二次受损。
这个处置顺序是行业共识,所有安全公司的应急手册基本都遵循“先恢复、再溯源”的原则。
服务器被DDoS了怎么处理？分场景执行
服务器被DDoS了怎么处理，核心取决于攻击打在哪一层，这里拆成两个最常见的场景：
带宽型攻击（L3/L4层）
这类攻击最容易识别,监控面板上能看到入方向流量超过带宽上限的数值，处置路径如下：
- 登录云厂商控制台,确认高防IP的防护峰值是否够用。不够则提交工单临时调升，价格按量计费，这个钱不能省
- 联系上游运营商做黑洞路由或流量清洗,这个动作需要云厂商配合，值班人员负责发起工单并跟进进度
- 如果业务对IPv6有开放,记得同时检查IPv6的流量情况，很多攻击者会绕过IPv4的防护直接打IPv6地址
连接耗尽型攻击
这类攻击的“脏流量”不算大，但并发连接数是正常值的几十倍，导致服务器无法接受合法用户的TCP握手请求。
关键操作：
- 执行
ss -s查看当前TCP状态统计，确认大量连接卡在SYN_RECV或TIME_WAIT状态 - 在边界防火墙上设置连接数限制,基于源IP做阈值管控
- 如果源IP分布极为分散（肉鸡网络），直接启用云平台的一键流量封禁功能，配合CDN做源站IP隐藏
取证与溯源：用日志留住攻击证据
止损之后的取证环节,是很多值班团队最容易忽视、也最没有章法的一步，记住一个原则：做任何操作之前，先想这个操作会不会改变现场。
必须保存的证据类型
- 系统登录日志：Linux执行
last -f /var/log/wtmp，Windows查看安全事件ID 4624/4625 - 应用访问日志
：Nginx的
access.log、Apache的虚拟主机日志，直接完整拷贝一份到独立存储 - 网络连接快照：
netstat -ant的输出结果，建议保存多个时间点的快照，形成变化趋势 - 进程快照：
ps auxf的输出，重点记录PID、父进程PID和对应的可执行文件路径
溯源分析的实操思路
不给攻击者留退路，也不用在日志海里捞针，执行 grep 命令时先锁定时间窗口，再锁定可疑IP段，最后筛出高频URL路径。
比如用一行命令提取攻击高峰期Top访问IP：
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20
这行命令输出的前几个IP,大概率就是攻击源。
恢复与验证：从手动恢复到业务全通
止损和取证完成后,恢复业务也不是简单地把防护撤掉就行。标准的恢复流程分三步走：
第一步：最小化恢复
只恢复核心交易链路,非核心功能保持关闭，比如电商业务先恢复商品浏览和下单，论坛、评论、搜索这些次要模块维持降级状态。
第二步：观察期验证
设置30分钟到2小时不等的观察期，期间持续监控四个指标：带宽使用率、应用响应时间、错误率、活跃会话数，如果四个指标稳定在正常区间，再逐步放宽限制。
第三步：全量开放
防护策略从拦截模式切换为观察模式,流量恢复正常后24小时内保持告警阈值敏感度调高。
这里要提一个常见误区：有些团队恢复业务后太高兴，忘记了备份被攻击前后的系统状态和日志文件，后续如果涉及法律追责或保险理赔，这一步丢失的资料很难补回来，建议平时就在应急预案中设计好取证环节，攻击期间反而不要临时想“要存哪些东西”。
建立长效防御：别等下一次攻击来检验你的运气
攻击处置完毕不代表工作结束,每次攻击都是一次花钱买来的演练机会，不沉淀成防护能力就是白被打。
值班层面的日常准备清单
- 在监控系统中提前配置好DDoS高防的告警阈值,避免流量冲到上限才触发通知
- 定期演练日志转存操作,确保日志量暴涨时不会写满磁盘导致额外故障
- 建立与云厂商安全团队的紧急联系通道,主动询问或试用其DDoS防护产品的应急响应流程，各云厂商的DDoS高防产品都提供7×24小时电话服务，把号码贴在值班工位上
预算与投入的决策参考
- 如果你关心
Web应用防火墙多少钱
的问题，主流云厂商提供了多个档位：基础版按年订阅约在数千元级别，适合小型业务；旗舰版附带AI语义分析和自定义规则引擎，年费在万元级别以上 - 两种方案的取舍很简单：业务体量不大就选基础版+高防IP的组合，体量大或对安全合规有硬性要求，直接上旗舰版，选购时可以关注简米云、酷番云官网的安全产品页面，或者对比使用百度智能云的安全服务
复盘报告怎么写
复盘报告不追求厚,追求结论能落地，统一用这个四段结构：
| 模块 | |
|---|---|
| 时间线 | 从告警到业务恢复的完整时间表，精确到分钟 |
| 根因分析 | 攻击手法、利用的漏洞或配置缺陷、暴露出的监控盲区 |
| 改进措施 | 每条措施需标注责任人和完成时限 |
| 演练计划 | 下次攻防演练的时间、范围和预期目标 |
常见问题解答
Q1：业务被攻击时，值班人员可以直接联系攻击者要求停止吗？
不建议直接接触攻击者,这类沟通不会产生实际效果，反而暴露你的恐慌程度和团队应对能力，有诉求需要通过法律途径或第三方机构处理，值班人员的职责是技术止损，不参与外部沟通。
Q2：攻击结束后，防御策略需要永久保留吗？
攻击结束后的24到72小时内,防护规则先保留观察，确认无后续动作后再逐步放宽，如果攻击带有明显的定向性，建议将相关封禁规则保留到业务版本迭代后自然失效。
Q3：小团队没有专职安全人员，日常怎么提升应急能力？
选一名运维骨干作为安全接口人,定期参与云厂商的免费安全培训及社区活动，获取最新的攻击趋势和技术手段，建议每季度在测试环境模拟一次DDoS和CC攻击处置演练，控制成本的同时让团队熟能生巧，明确分工非常关键，许多演练失败并非技术不过关，而是临场时几个人的职责互相重叠又互相推诿。在值班制度中提前固定好“指挥、操作、协同”三类角色，平时就养成各司其职的协作习惯，真正遇袭时效率会远超临时组织。
业务被攻击不是“会不会”的问题，是“什么时候”的问题，值班人员的价值不在于阻止所有攻击，而在于攻击发生时能按照标准流程把损失控制到最小，熟记处置五步法，把每一步固化为肌肉记忆，当攻击真正来临时，你会发现自己比想象中更从容。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635361.html
