企业官网建设流程全解析

短信炸弹攻击这个漏洞，我印象太深了。早几年做电商平台风控的时候，赶上大促前夜，竞对直接拿脚本对着我们注册接口刷短信，一夜之间短信通道费烧掉十几万，用户投诉电话被打爆，应用商店评分直接掉到1.8。那会儿还没有成熟的防护方案，全靠运维手工封IP，累得半死还封不干净。

后来专门花了几周时间，系统性地把这类攻击的路径、手法和防护措施整理了一遍，又在多个项目里反复验证，才形成一套相对完整的方案。这篇就把这套东西拆开揉碎了讲清楚，从攻击原理到接口层防护，从业务规则到风控监控，再到事后溯源，一条链路完整走一遍。不管你是刚接手安全工作的新人，还是在为短信通道成本发愁的架构师，这篇的内容都能直接用上。

1. 短信炸弹攻击的攻击链与识别

想防住一个攻击，先得搞清楚它是怎么打进来的。短信炸弹攻击说白了就是攻击者利用业务系统里“发送短信验证码”这类功能，通过批量、高频的请求，对特定手机号或者大量手机号发起短信轰炸。受害者的手机在短时间内会收到几十上百条验证码短信，正常短信被淹没，严重的甚至会导致手机卡顿、短信功能瘫痪。

从攻击者的视角拆一下这条链路，基本是四步：收集目标手机号、构造请求参数、批量发送请求、绕过防护持续轰炸。

1.1 攻击原理与常见类型

短信炸弹攻击在技术实现上并不复杂，核心就是“调用业务接口”和“绕过频率限制”。攻击者会先分析目标应用的注册、登录、找回密码等业务流程，找到那些不需要登录态就能触发短信的接口，然后用脚本或者现成的攻击工具，循环调用这些接口。

常见的攻击类型可以分成两类：

第一类是定向轰炸，攻击者盯着一个特定的手机号，比如某位主播、某个企业高管，或者某个在社交平台上公开过手机号的人，对这个号码发起大量短信请求。这种攻击的骚扰性质更强，目的可能是报复、恶搞，也可能是为了掩盖同时进行的其他攻击行为。

第二类是批量轰炸，攻击者手里有一批手机号，可能是通过撞库、拖库、或者从黑产渠道买来的，然后对这批号码进行地毯式轰炸。这种攻击的经济目的一般更强，可能是为了拖垮竞争对手的短信通道，也可能是为了制造大规模用户投诉，搞垮目标平台的声誉。

这里有一个关键点很容易被忽视：攻击者不一定只盯着“发送验证码”这一个接口。很多业务系统里，绑定手机、修改手机、解绑手机、活动邀请、好友分享这些功能里都藏着短信发送逻辑，而开发人员在写这些接口的时候，往往不会像对待注册登录那样重视防护。攻击者扫一圈下来，可能发现五六个能发短信的接口，轮着用，单个接口的频率都不高，但加起来总量惊人。

1.2 攻击者常用的绕过手法

光知道原理还不够，你得知道攻击者是怎么绕过基础防护的，不然你做的拦截规则就是一层窗户纸。

最常见的绕过手法是替换请求参数。很多接口虽然做了手机号频率限制，但判断条件写得太死板，比如只判断了手机号维度，没判断IP维度。攻击者用代理池换IP，每个IP只发一两条请求，频率限制就形同虚设。

第二种手法是直接改接口。有些应用的客户端里虽然做了防重复点击、倒计时之类的控制，但这只是前端控制，攻击者用抓包工具拿到接口地址后，直接用Postman或者脚本构造请求，客户端的限制完全绕过去了。

第三种手法更隐蔽，叫“借刀杀人”。攻击者拿到一批正常用户的会话凭证，然后用这些合法凭证去调用短信接口。这种情况下，接口层面看每个请求都是正常用户发起的，频率也合理，传统的WAF和限流规则根本拦不住。

明白这些手法之后，你会发现短信炸弹防护绝对不是加一个“同一手机号60秒只能发一次”就完事的，它需要一套多层配合的体系。

2. 接口层防护：把入口收紧

接口层是整个防护体系的第一道门，也是攻击者最先试探的地方。大部分短信炸弹攻击都集中在接口层，因为这里最容易突破，所以这一层的防护做得扎实不扎实，直接决定了后面几层要不要承受压力。

2.1 单手机号请求频率限制的落地细节

“同一手机号N秒内只能发送一次”这条规则，看着简单，落地的时候坑不少。

第一个坑是限流的维度。如果只按手机号限流，攻击者换号码就绕过了；如果只按IP限流，攻击者换代理IP也绕过了。所以限流必须组合维度，至少要做到“手机号+IP”的组合限流，核心手机号维度上限制要严格，IP维度上要做辅助限制，双管齐下。

第二个坑是限流的粒度。我见过一个项目，限流周期设的是24小时，当天发送超过5次就拒绝。这个方案在理论上没问题，但实际操作中，攻击者会在23:59刷一波，过了零点接着刷，等于24小时窗口被切成了两段。正确的做法是用滑动窗口，Redis里用ZSET存时间戳，每次请求检查窗口内的计数，这样才不会有跨窗口绕过的漏洞。

第三个坑是限流的存储。早期我见过用数据库计数来实现限流的，每次请求都update一条记录，流量一起来数据库直接扛不住。这里正确的姿势是用Redis的INCR或者Lua脚本做原子计数，既保证性能又保证一致性。参考实现大概是这样的：

import redis import time r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True) def check_sms_limit(phone, ip, window_seconds=60, max_count=1): # 手机号维度的滑动窗口限流 phone_key = f"sms:phone:{phone}" # IP维度的辅助限流 ip_key = f"sms:ip:{ip}" # 使用Lua脚本保证原子性 lua_script = """ local key = KEYS[1] local window = tonumber(ARGV[1]) local max = tonumber(ARGV[2]) local now = tonumber(ARGV[3]) redis.call('ZREMRANGEBYSCORE', key, 0, now - window) local count = redis.call('ZCARD', key) if count >= max then return 0 end redis.call('ZADD', key, now, now .. ':' .. math.random(1000000)) redis.call('EXPIRE', key, window) return 1 """ # 手机号维度：60秒内最多1条 phone_allowed = r.eval(lua_script, 1, phone_key, window_seconds, max_count, time.time()) # IP维度：60秒内最多5条（宽松一些，因为一个IP后面可能有多个用户） ip_allowed = r.eval(lua_script, 1, ip_key, window_seconds, max_count * 5, time.time()) return phone_allowed == 1 and ip_allowed == 1

这段代码的意思是：手机号60秒内最多发1条，IP在60秒内最多发5条。两个条件都满足才放行。用ZSET做滑动窗口的好处是，窗口是真正“滑动”的，不存在整点重置的漏洞。

2.2 IP维度的限流与封禁策略

IP维度的限流做起来比手机号维度更讲究，因为IP是共享资源，一个公司出口可能几百号人共用同一个公网IP，你把这个IP封了，正常用户也跟着遭殃。

所以IP维度的策略要有层级：第一层是宽松限制，比如单个IP每分钟最多触发20次短信请求，超过就触发验证码，而不是直接拒绝；第二层是严格限制，单个IP每小时超过50次，直接封禁；第三层是黑名单，如果这个IP在24小时内触发了多次封禁，拉入黑名单，拦截所有短信接口请求。

这里还需要区分两种IP：数据中心IP和住宅IP。数据中心IP来自云厂商、机房，这些IP几乎没有正常用户会用来收发短信验证码，一旦出现请求，风险评分就要提高；住宅IP是普通宽带用户的IP，攻击者如果用住宅代理，单个IP的请求量通常不高，这时候光靠IP限流就不够了，要配合后面的业务侧防护。

代理IP的识别有个土办法，就是维护一份已知的IDC IP段列表，每次请求来的时候查一下来源IP是不是在列表里。网上有开源的IP归属库可以查，也可以直接买商业的IP情报服务，后者更省心，准确率也更高。

2.3 前置校验逻辑的陷阱

很多团队做接口防护的时候，只关注请求来了之后的校验，却忽略了请求本身应该有的前置条件。

举个例子，发送验证码之前，正常业务流程里通常有一些前置校验：注册接口会先检查手机号是否已注册，找回密码接口会先检查手机号是否存在，修改手机接口会先验证旧手机的验证码。攻击者可能根本不care这些前置条件，但如果你的代码里没有做这些校验，攻击者就可以把“发送验证码”这个动作本身当作攻击工具来用。

有一个真实的案例：一个跨境电商平台的“绑定新手机”接口，逻辑是先校验旧手机收到的验证码，校验通过才能绑新手机并发送新验证码。但开发人员写代码的时候，把校验逻辑放在了一个独立的接口里，前端调用“发送新手机验证码”接口的时候，后端没有再次检查旧手机是否已通过校验。结果攻击者直接跳过校验接口，调用发送接口来刷短信。

所以前置校验这块，不要相信前端的调用顺序，后端每个接口都要自校验，该检查登录态就查登录态，该检查上一步结果就查上一步结果。涉及短信发送的接口，全部要走统一的安全校验逻辑，别让每个接口各管各的。

3. 业务侧防护：别让规则被绕过

接口层的限流解决了“量大”的问题，但解决不了“伪装正常”的问题。攻击者用住宅代理、用小号批量注册、用合法会话发起请求的时候，接口层的规则很难识别出来。这时候需要把防护的层级往上拉，从业务规则层面去做判断。

3.1 图形验证码与滑块验证的取舍

很多短信接口的防护方案里，图形验证码几乎是标配。但你有没有想过，图形验证码本身是可以被绕过的？

现在的打码平台，接个API，几秒钟就把简单的图形验证码识别了，成本低到可以忽略。所以图形验证码只能作为基座，不能作为唯一防线。我的建议是分级校验：同一个手机号第一次请求发短信，只要基础限流过了就放行，不打扰用户；第二次请求的时候，弹图形验证码；第三次请求，上滑块或者点选验证码；超过阈值，直接拒绝请求并提示“操作过于频繁，请稍后再试”。

这样做的逻辑很简单：正常用户几乎不会在短时间内频繁请求短信验证码，一旦出现这个行为，就有理由怀疑是脚本或者攻击工具在操作。对于正常用户，第一次请求不验证码的体验是最好的，这也是为什么分级校验的设计在业务上能站得住脚。

滑块验证的体验比图形验证码好一些，但它本身也存在绕过风险。市面上有一些模拟轨迹的工具，可以伪造滑块的拖拽轨迹。所以滑块验证的校验不能只靠前端传一个结果，后端要校验轨迹数据、时间间隔、坐标点分布这些特征，识别出机器模拟的行为。简单说，拖动时间不能太短，轨迹不能是绝对直线，停顿点不能完全没有。

3.2 登录态与设备指纹的引入

如果业务场景允许，短信发送接口最好要求登录态。登录之后，用户身份是明确的，每个账号每天的短信发送量是有限的，即使某个账号被攻击者控制，他能造成的破坏也是可控的。

但很多场景下，注册、找回密码这些流程本身是在未登录状态下进行的，这时候就要用设备指纹来辅助判断。

设备指纹说白了就是通过浏览器的Canvas指纹、WebGL信息、字体列表、时区、语言、屏幕分辨率等信息，给用户的设备生成一个唯一标识。攻击者用脚本刷短信的时候，如果不处理这些特征，设备指纹就是高度集中的，一个指纹对应海量的请求。即使他每次换IP、换手机号，设备指纹不会变，就能识破。

设备指纹的实现可以自己搭，也可以接第三方的SDK。自己搭的话，前端采集信息，后端按规则生成哈希，注意采集的信息要有足够的熵，不然不同设备的指纹会撞车。接第三方的话，识别准确率更高，人脸识别级别的反欺诈能力都有，但成本也更高，适合业务量大的平台。

3.3 通道侧策略

短信炸弹攻击对受害平台来说，最直接的损失是短信通道费用被刷爆。所以通道侧的策略也不能省。

我把通道侧的策略分成两类：一类是配额类，一类是熔断类。

配额类策略的核心是给短信通道设置预算。比如一个业务线每天预算是10万条，当天的实际发送量到了8万条，就触发预警；到了9.5万条，自动暂停非核心业务的短信发送，只保障注册、登录、支付验证码这些关键业务；到了10万条，全部停止发送，需要人工介入处理。配额的实现比较简单，就是给每个业务线配一个计数器，发送前检查计数。

熔断类策略是应对突发流量的。正常情况下，短信发送量的曲线是平滑的，高峰期和低谷期差距不会超过一个量级。如果某一分钟内的发送量突然飙升到平时的几十倍，那不是好事，大概率是攻击开始了。这时候要做的是熔断：在一段时间内暂停短信接口的发送能力，让运维和安全人员有时间去分析情况。熔断实现要有一个总开关，开关一拉，所有短信发送请求都返回“系统繁忙，请稍后再试”，而不是直接失败，避免影响用户体验。

通道侧的策略听着简单，但落地的时候经常踩坑。最大的坑是分布式部署下的计数不准确。如果业务系统是多实例部署，每台机器上的短信发送量是独立的，如果没有一个集中的计数器，配额和熔断的阈值就形同虚设。解决方案是把计数器放在Redis里，所有实例都往同一个Redis上写数据，这样计数才是全局的。

4. 风控与监控：实时发现和阻断

接口层和业务层的防护，更多是规则层面的拦截。对于绕过这些规则的漏网之鱼，还需要一套实时的风控和监控系统去兜底。这部分的价值不在于“拦截”，而在于“发现”和“响应”。

4.1 风控规则引擎的搭建

风控规则引擎说白了，就是把“什么样的情况是可疑的、什么样的行为要阻断”这些判断逻辑，从代码里抽出来，做成可配置的规则，让风控运营人员不用改代码就能调整策略。

规则引擎的核心是特征计算。每条短信发送请求进来，引擎会实时计算出一组特征，比如这个手机号在过去5分钟内的请求次数、这个IP在过去1小时内的请求次数、这个设备指纹关联了多少个手机号、这个手机号是否在历史黑名单里……然后把特征输入规则，输出处置结果。

处置结果一般分四档：放行、验证码、限流、拦截。放行就是直接发短信；验证码是要求用户过验证码才继续；限流是延长下一次发送的等待时间；拦截是不允许发送。

规则引擎的规则设计，我分享几条实际项目里验证过有效的：

第一，同一手机号30分钟内触发5次以上短信请求，进入验证码模式；触发10次以上，直接拦截。

第二，同一设备指纹在10分钟内关联了3个以上不同手机号，所有关联手机号的短信请求都进入验证码模式。

第三，同一IP在5分钟内调用了2个以上不同的短信发送接口，判定为扫描行为，全部短信请求拦截。

第四，注册接口的短信请求占比过高，比如某时间段内注册短信占所有短信的比例超过80%，触发告警。

规则引擎还有一个优势，就是可以做A/B测试。新规则上线之前，先跑一段时间影子模式，只记录命中情况不实际拦截，确认误杀率低之后再切换成正式模式。这个习惯我强烈建议养成，我见过不止一次规则太激进导致大面积用户收不到验证码的事故。

4.2 监控告警与实时大屏

监控这块，我的经验是不要贪多，盯着几个核心指标就够用了。

第一个指标是短信发送成功率。正常情况下的成功率应该在95%以上，如果某一分钟内成功率骤降，大概率是通道出问题了。当然也可能是被攻击了，大量异常请求打到通道，导致通道拒绝服务。

第二个指标是短信发送量的环比变化。和昨天同一时间段的发送量对比，如果突然涨了5倍以上，一定有异常。这个指标的监控逻辑要注意用环比而不是绝对值，因为不同业务时间段的基础值差异很大，绝对值设阈值很容易误报。

第三个指标是视频验证码请求量。如果这个数字突然飙升，先别急着去查通道，大概率是注册和登录接口在被恶意调用。

第四个指标是业务侧的转化漏斗。比如注册页面，从请求验证码到完成注册的转化率，正常情况下是60%以上，如果这个转化率突然掉到20%，说明短信根本发不出去，或者验证码已经被刷爆了。

监控告警的渠道，邮件、短信、企业微信、钉钉这些都可以接，但真要出问题的时候，最有效的还是电话告警。短信和IM的通知容易被忽略，电话铃声一响，值班的人就知道出大事了。

监控大屏这个东西，平时没什么用，但真出了问题，是大家开会复盘的时候的重要参考。大屏上不用放太多花哨的图表，把发送量趋势、成功率、告警事件列表、当前被拦截的IP和手机号这几个信息放上去就够了。

4.3 黑产情报的引入

这一小节单独拿出来说，是因为很多中小团队压根没想到做这一层。

短信炸弹攻击的很多手机号、IP、设备指纹，其实在黑产圈子里是共享的，而且已经有人把这些情报整理成了库。如果能在自己的风控规则里引入这些黑产情报，拦截率会有明显提升。

黑产情报的来源有几个：一是商业的情报服务商，每年交点钱，他们提供API接口，实时查询IP、手机号、设备指纹的风险评分；二是行业内的黑名单共享，比如电商联盟、金融风控联盟内部交换的黑名单；三是自己的历史数据积累，被攻击过的、确认是恶意的IP和手机号，拉进自建黑名单里。

引入黑产情报之后，规则的优先级要设计好：命中黑名单的请求，直接拦截，不需要走其他规则判断了。这不是怕误杀，因为黑名单本身就是高置信度的威胁指标，误杀的概率极低。

5. 常见问题与排查技巧实录

防护方案上线之后，真正的考验才开始。下面这些问题，都是我在实际项目里踩过的坑，有些是设计阶段没想到的，有些是线上运行之后才暴露的。整理出来，希望能帮大家少走弯路。

5.1 验证码被绕过的问题

有一次上线了新的验证码策略，自信满满地觉得防护已经固若金汤，结果第二天就被打脸。攻击者不仅绕过验证码，还顺势刷了一波短信。

排查了一圈，发现问题是这样的：验证码接口和短信发送接口是分开的，前端先请求验证码接口，拿到验证码之后再调用短信接口。而我们的风控只对短信发送接口做了校验，没有校验验证码接口的调用次数。攻击者绕过了验证码接口，直接调短信发送接口，风控发现短信接口的请求里没有携带验证码凭证，但代码里对这个凭证的校验不够严格，默认是“可选”而不是“必选”，于是直接放行了。

这个问题的教训是：验证码的校验必须是强校验，短信发送接口必须检查“本次请求是否通过验证码验证”这个状态，而且这个状态必须是后端维护的，不能只依赖前端传一个标志位。

5.2 短信通道被刷爆的问题

还有一次，攻击者不直接刷短信接口，而是利用业务逻辑漏洞来刷。那个业务逻辑是邀请好友获取优惠券，每邀请一个好友，系统会自动给被邀请人的手机号发一条短信通知。攻击者注册了一堆小号，然后用这些小号去邀请同一个目标手机号，每次邀请都会触发一条短信。

这个问题的本质是：业务逻辑里隐藏着很多间接的短信触发点，这些触发点不在一个统一的“短信网关”管理之下，导致防护规则覆盖不到。排查这个问题耗费了很大精力，因为要翻遍所有调用短信发送的代码，找到所有可能被滥用的路径。

解决思路是：把所有短信发送的调用收敛到一个统一的SDK或者网关服务里，所有短信发送都必须走这个网关，网关层做统一的校验、配额、熔断。任何绕过网关直接对接通道的行为，直接被视为违规，不管是不是业务需求。这个思路执行下去之后，以后再出现类似的间接触发点，至少网关层可以兜住。

5.3 多区域部署下的限流失效问题

还有一个多区域部署时的经典问题。我们的业务部署在好几个城市，每个区域一套集群，最初限流数据是放在本地Redis里的，结果攻击者把请求摊到各个区域，每个区域看到的请求量都不高，全部放行了。

后来把限流数据的存储收敛到了公共的Redis集群，但公共Redis的延迟又上来了，短信接口的响应时间从原来的20毫秒涨到了60毫秒，业务方抱怨得不行。

最终的解决方案是：本地Redis和公共Redis结合，本地Redis做第一层粗限流，公共Redis做第二层精确限流。本地Redis的阈值设得宽松一些，比如手机号60秒内3次，这个判断很快，毫秒级；公共Redis设严格阈值，比如手机号60秒内1次。正常情况下，第一层就够了，只有请求打到两个不同区域的时候，公共Redis才会发挥作用。这个方案既保证了响应速度，又保证了全局限流的有效性。

5.4 排查工具与技巧

排查短信炸弹攻击的时候，有几个好用的工具和技巧，分享给大家。

抓包工具首推Wireshark和Charles。Wireshark适合排查网络层的问题，比如某个IP到短信网关的流量异常；Charles适合排查应用层的问题，比如某个接口的请求参数是怎么构造的。抓包的时候注意要过滤，不然数据量大海捞针。

日志分析是排查的主力。短信发送的日志里，要记录的信息包括：请求时间、手机号、IP、设备指纹、接口名、发送状态、风控规则命中情况。平时这些日志可能只是运维的负担，但攻击发生的时候，它们是最可靠的证据。我的习惯是日志里直接把风控命中的规则ID打出来，排查的时候一条请求一条请求地看，能直观地还原攻击路径。

还有一个排查思路很多人没想到：去自己的应用商店看评价。用户收到短信炸弹轰炸之后，一般会先去应用商店打差评，这是最及时的用户反馈渠道。通过差评的内容和时间，可以快速反推出攻击发生的时间段和覆盖面。

5.5 误杀与投诉的处理

防护做严了，误杀的问题就来了。有一次我们把限流阈值调得过于激进，结果一个正常用户连续触发了几次短信验证码，直接被拦截了，气急败坏地打电话投诉。

误杀对业务的影响是实打实的，所以在设计防护策略的时候，要给“人”留一个出路：用户如果被误杀了，要有申诉和人工处理的通道。比如提示“操作过于频繁，如需帮助请联系客服”，用户联系客服之后，客服可以通过后台查看这个用户的请求记录，判断是不是误杀，然后人工放行。

风控运营人员的心态也要调整，不要觉得“杀得越多越安全”。真正安全的目标是“该拦的拦住，不该拦的不误伤”。在风控领域有一个词叫“召回率”和“准确率”的平衡，召回率是指所有攻击中有多少被拦住，准确率是指所有被拦的有多少是真正的攻击。这两个指标互相矛盾，规则严厉，召回率高但准确率低；规则宽松，准确率高但召回率低。每个团队要根据自己的业务容忍度，找到合适的平衡点，然后在线上不断调优。

6. 纵深防御体系：从单点防护到综合治理

短信炸弹攻击的防护做到最后，你会发现它不是某一个环节能单独解决的，需要整个系统层面的配合。单点防护做得再好，总有绕过去的可能，只有把多层防御串联起来，才能把风险降到最低。

6.1 分层防御体系的设计

我设计短信炸弹防护体系的时候，习惯把防御分成四层：边界层、接入层、业务层、数据层。

边界层是云WAF和防火墙，这个层面的作用是把明显的恶意流量挡在门外，比如已知攻击IP的请求、高频访问的请求，这些根本不用到后端，直接在边界层就丢弃了。接入层是API网关和负载均衡，做基础限流、黑白名单，用透明的方式把不合规的请求识别出来。业务层是接口的代码逻辑，做手机号维度限流、验证码策略、风控判断。数据层是日志和监控，把攻击行为的特征沉淀下来，持续优化规则。

这四层之间的关系是层层递进的，每一层都过滤掉一批攻击，漏网的到下一层继续被拦截。这样即使某一层被绕过，后面还有别的层兜底，不会出现单点失效的灾难。

分层防御还有一个好处，是每一层的实现技术可以独立升级。比如边界层的WAF规则可以随时调整，不会影响业务代码；业务层的风控逻辑变更，也不用等网关层发布。这种模块化的思路，在应对新出现的攻击手法时，响应速度会快很多。

6.2 业务架构层面的主动防御

除了被动拦截，还可以在做业务架构设计的时候，就把“被攻击的可能性”考虑进去。

一个我强烈推荐的做法是：把短信发送能力做成独立的服务，而不是散落在各个业务代码里。这个独立服务对外提供发送短信的接口，内部实现所有的安全校验逻辑——限流、验证码校验、风控规则、配额管控。各个业务线要发短信，统一调用这个服务。这样做的好处是，安全能力的建设和维护只需要关注一个系统，不用每改一个业务模块就去检查安全规则。

当然，这个方案对老项目来说改动量不小，但如果你的项目正在做微服务拆分，或者正在规划中台建设，建议把短信服务作为其中的一个独立服务来设计。前期的投入看起来不划算，但上线之后不管是安全性还是稳定性，都会省掉你大量的维护精力。

6.3 运营机制：告警到处置的闭环

最后补一块，就是运营机制。

好的技术方案只是第一步，如果没有一套顺畅的运营机制，再好的方案也会在线上跑偏。我见过一些团队，风控系统的告警邮件发出来了，但因为没人看，攻击持续了几个小时才被发现。

我的建议是把告警处置做成一个闭环，至少包括：告警通知、初步研判、应急处置、复盘改进四个环节。

告警通知要分级，严重的告警直接电话通知值班人，不能只发邮件；普通的告警发到工作群，工作时间范围内处理就行。初步研判要在5分钟内完成，判断这个告警是真的攻击还是误报。如果是误报，调整规则后关闭告警；如果是真攻击，启动应急响应。应急处置的动作包括：拉黑攻击IP、封禁被滥用的手机号、临时开启更强验证码、暂停非核心短信业务等。整个处置过程要记录在案，事后的复盘会上，要确认这次攻击暴露了哪些防护漏洞，然后针对性改进。

运营机制这块没有标准答案，不同团队的人员配置和业务特点不一样，但只要“发现-响应-处置-改进”这个循环能转起来，短信炸弹攻击就不会对业务造成致命的伤害。

写在最后的几点经验

把整套方案做完之后，说几点我个人想强调的体会。

第一，短信炸弹攻击的防护不是一次性工程。攻击手法在持续演变，防护方案也要持续迭代。不要觉得方案写完就万事大吉了，定期复盘历史攻击事件、关注业界攻防动态，是安全从业者的日常功课。

第二，防护和体验的平衡是永恒的课题。不管做成什么样，总会有用户体验被牺牲的角落。做风控和防攻击方案，本质上是在“给用户添麻烦”和“被攻击者利用”之间找平衡点。多看数据，多听用户反馈，这个平衡点会越找越准。

第三，代码之外，流程和数据同样重要。再强的防护规则，如果告警发出去没人看，等于没有。再多的防护手段，如果事后不留数据不做复盘，下一次攻击来了还是照样手忙脚乱。

我希望这篇内容能帮你把短信炸弹攻击这件事想透。按着这套思路去搭防护体系，哪怕只用里面的几个要点，应该也能让你的系统比大多数同类系统硬实不少。实际操作中如果遇到什么问题，欢迎在评论区留言交流，我尽量回复。