短信炸弹攻击这个漏洞我印象太深了。早几年做电商平台风控的时候赶上大促前夜竞对直接拿脚本对着我们注册接口刷短信一夜之间短信通道费烧掉十几万用户投诉电话被打爆应用商店评分直接掉到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(host127.0.0.1, port6379, decode_responsesTrue) def check_sms_limit(phone, ip, window_seconds60, max_count1): # 手机号维度的滑动窗口限流 phone_key fsms:phone:{phone} # IP维度的辅助限流 ip_key fsms: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、封禁被滥用的手机号、临时开启更强验证码、暂停非核心短信业务等。整个处置过程要记录在案事后的复盘会上要确认这次攻击暴露了哪些防护漏洞然后针对性改进。运营机制这块没有标准答案不同团队的人员配置和业务特点不一样但只要“发现-响应-处置-改进”这个循环能转起来短信炸弹攻击就不会对业务造成致命的伤害。写在最后的几点经验把整套方案做完之后说几点我个人想强调的体会。第一短信炸弹攻击的防护不是一次性工程。攻击手法在持续演变防护方案也要持续迭代。不要觉得方案写完就万事大吉了定期复盘历史攻击事件、关注业界攻防动态是安全从业者的日常功课。第二防护和体验的平衡是永恒的课题。不管做成什么样总会有用户体验被牺牲的角落。做风控和防攻击方案本质上是在“给用户添麻烦”和“被攻击者利用”之间找平衡点。多看数据多听用户反馈这个平衡点会越找越准。第三代码之外流程和数据同样重要。再强的防护规则如果告警发出去没人看等于没有。再多的防护手段如果事后不留数据不做复盘下一次攻击来了还是照样手忙脚乱。我希望这篇内容能帮你把短信炸弹攻击这件事想透。按着这套思路去搭防护体系哪怕只用里面的几个要点应该也能让你的系统比大多数同类系统硬实不少。实际操作中如果遇到什么问题欢迎在评论区留言交流我尽量回复。