DDoS 对您的服务器和主机商，到底做了什么

互联网上几乎每一个主机商的页面都承诺提供 DDoS 防护，却几乎没有一个会说清楚，自己说的究竟是两种攻击中的哪一种。这个区别绝非纸上谈兵：其中一种是算术问题，在几百公里之外、由您永远不会打交道的人一锤定音，而且确实包含在价格之内。另一种则无法被任何不读取您流量内容的人过滤，没有哪个服务商能诚实地把它卖给您而不说明这一点。以下是数据包身上究竟发生了什么，您的主机商接下来最可能做什么，以及无论向谁购买都始终是您自己的问题的那部分。

两种攻击，一个名字，几乎没有共同点

拒绝服务攻击的目标只有一个——耗尽某种资源，直到别人一点都不剩——而整件事其实都取决于哪一种资源。这个选择决定了谁有能力制止它、在哪里制止、代价几何。这不是一条连续的光谱。这是两大类，由不同的当事人用不同的设备来阻止，而一个只用一个数字来回答问题的服务商，其实只回答了其中一类，对另一类只字未提。

第一类攻击的是管道本身。UDP 泛洪、SYN 数据包泛洪、来自互联网上某些配置不当的服务器的反射流量。它们根本不关心您在跑什么，不知道您托管的是论坛还是 git 镜像，永远到不了您的应用层，多数情况下甚至根本到不了您的机器——它们会在您上方的某处塞满链路，或者耗尽某台路由器里的一张表。正因为它对内容毫不在意，不看您流量内容的人也能识别并丢弃它。这就是它能在上游解决的原因，也是这一半会被免费包含进套餐的原因。

第二类攻击的是您的应用本身。每一个请求单独看都无懈可击：TLS 握手正确，HTTP 合法，URL 也真实存在。您的服务器很乐意接收它们。真正倒下的，是搜索框背后的数据库，或者登录表单背后的密码哈希运算——而且倒下时的请求速率，在您的网络流量图上几乎不会留下痕迹。没有特征可以匹配，因为单独看每一个请求都毫无问题。能把这股洪流和风平浪静的一天区分开的，只有意图，而意图从来不是数据包头里的一个字段。

六种攻击形态、各自耗尽什么，以及谁有能力阻止它

到达的是什么	能否在上游过滤	是否要您自己解决	耗尽的是什么，实际在哪里被拦下
反射型 UDP 泛洪	是	否	链路容量。这类流量是批量、伪造、对您跑什么毫不在意的，所以看不到流量内容的人也能把它丢弃——但前提是，那份容量得坐落在它想要填满的链路的上游。一旦那条链路已经塞满，无论在服务商的边缘做什么，还是在您自己的机器上做什么，都于事无补。
SYN 泛洪	是	部分	耗尽的是连接状态表，不是带宽。半开连接发起成本很低，但记住它们的代价很高。在网络边缘就能被过滤，而且很大程度上在您自己的内核里就已经被化解了：Linux 多年来都默认启用 SYN cookie，大多数人从来都不必知道这件事。
小数据包泛洪	是	否	耗尽的是转发平面。路由器和网卡的处理能力是按每秒数据包数来衡量的，而由微小数据包组成的泛洪，瞄准的正是这个数字，而不是带宽数字。在上游的硬件层面就会被拦下。这是那种能在流量图看起来风平浪静时，就把防火墙拖垮的攻击。
慢速请求头与慢速请求体攻击	否	是	耗尽的是工作线程槽位。几百个连接，建立之后每次只喂一个字节，就能把一台每连接使用一个线程的服务器，一直占用到线程耗尽为止。靠反向代理里的超时设置和按地址限制连接数就能解决；事件驱动型的前端几乎是无意间就能扛住它。
HTTP 请求泛洪	否	是	耗尽的是您的 CPU 和数据库。目标是开销昂贵的端点——搜索、登录、购物车，任何涉及写入的操作——每秒几千个请求就足够了。只能在您的应用内部拦下，或者在您特意允许其解密流量的代理内部拦下。不存在第三个地方。
爬取与撞库	否	是	耗尽的是一切，只是很慢。这根本算不上一次针对可用性的攻击，但它出现的样子和攻击一模一样，大约一半的情况下也会被当成攻击上报。靠您自己按端点、按账号设置的限速来解决。针对错误诊断买来的缓解措施，是最昂贵的那一种。

上面三行是您主机商的职责，下面三行是您自己的职责，而且无论花多少钱，都无法把哪一行从这一半挪到另一半去。当一个服务商说「DDoS 已防护」时，诚实的理解是：上面三行已经覆盖到了。这值得拥有。但这不是全部，而几乎所有真实发生的中断，都出在这道缝隙里。

替攻击者收尾的缓解措施

接下来是没有哪张产品页面会写出来的部分。当一股洪流抵达某个网络时，服务商有两个选择：可以选择过滤——把攻击流量从您真正的流量里分离出来，让您保持在线，这需要付出容量、设备和某个人的关注力作为代价；也可以向其上游承运商宣告您的地址，并附上一个意味着丢弃所有发往这里的流量的标记。这就是黑洞，也叫空路由，而它之所以成为行业默认做法，原因和您毫无关系。

这套机制是标准化的，而且完全公开。IETF 于 2016 年 10 月发布的 RFC 7999，定义了一个名为 BLACKHOLE、广为人知的 BGP 团体属性，在 IANA 登记为 0xFFFF029A——文档本身还不动声色地指出，其低位两个字节换算成十进制正是 666。它的语义只有一句话：该团体属性的存在，是「建议将所有发往此前缀的流量丢弃」的一种指示。它可以作为远程触发式黑洞配置的触发器，这项技术早在 2009 年的 RFC 5635 中就已描述。任何一个称职的网络，都能从一台路由器上，在几秒钟内、零成本地做到这一点。

读懂它做了什么：洪流不再抵达，服务商的链路恢复正常，同一网络上的其他每一位客户都恢复如常。而您则从互联网上消失了——不是变慢，不是降级，而是彻底消失，如同机器被拔掉了电源一样彻底，而且只要服务商不撤回那条宣告，就会一直持续下去。攻击者的目标，就是让您的服务无法访问；这项缓解措施替他们做到了这一点，而且没有让他们多花一分钱，事后它还会被描述成一次「缓解」——因为从网络的角度看，这恰恰就是它的本质。

有两个信号，而且在您花一分钱之前都能读到。第一个信号在可接受使用政策里，而不是在营销页面上。找那条关于「指向」您服务的流量的条款，留意由我们自行决定、可能暂停或可能实行空路由这类字眼。真正代表该服务商实际 DDoS 政策、并具有约束力的，是那一段文字，而不是首页上的盾牌图标。

第二个信号，是防护是否作为一个独立档位来销售。额外收月费的「受保护 IP」，本身就在明确宣告：普通地址是不受保护的，而一个网络对待负载下的未受保护地址，只有一种做法。真正意义上的上游过滤，无论是保护一个客户还是所有客户，成本都一样，这正是为什么按地址收费是一项定价决策，而不是工程决策。我们自己在这个问题上的立场是：过滤默认在每个端口上开启，不需要做任何操作来启用，而且比起把您空路由掉，我们更愿意先给您打个电话——这个承诺之所以有意义，正是因为它可以被证伪，也因为同一个页面上公开了它所依赖的容量数字。

上游的算术，以及数据包为何比比特更重要

流量型攻击并不高明，也不需要一个僵尸网络。它们需要的，是那些用小问题换回大答案的服务器，而互联网上到处都是这种服务器。CISA 公布过一张表，列出了按协议测得的放大倍数：DNS 是所问内容的 28 到 54 倍，NTP 是 556.9 倍，SSDP 是 30.8 倍，CharGEN 是 358.8 倍，CLDAP 是 56 到 70 倍。暴露在外的 memcached 实例，应答倍数在 10,000 到 51,000 之间。因为 UDP 不会验证问题是谁发的，答案就会发往攻击者写在上面的任意地址——也就是您的地址。

把这个乘法算一遍，那些营销说辞就都站不住脚了。一台接在普通千兆上联上的机器，只要瞄准足够多暴露在外的 memcached 服务器，就能把太比特级的流量砸向一个目标。攻击者不需要租用任何东西，也不需要攻陷任何东西。这正是为什么唯一有意义的容量数字，是位于服务商传输链路上游的那个数字，而不是他们边缘上的那个数字。如果一个主机商的传输带宽是 20 Gbps，自家机柜里的清洗设备也是 20 Gbps，那么 21 Gbps 的洪流就会堵塞传输链路，让链路后面的所有人一起遭殃——过滤本身是真实存在的，配置也正确，只是刚好站在了瓶颈错误的一侧。过滤必须发生在还有余量的地方，这意味着必须是运营商在做这件事，也就意味着您的主机商必须提前和一些您永远不会见面的人谈妥了这件事。

第二处算术，是连老手都会栽跟头的地方。网络设备的规格是按每秒数据包数来衡量的，不是按比特。1,500 字节大小的数据包凑够 1 吉比特，大约是每秒 81,000 个包，这不算什么。同样 1 吉比特，换成 64 字节的数据包，就变成每秒大约 150 万个包——带宽完全相同，处理量却是 18 倍。针对这个数字设计的洪流，会打垮防火墙、虚拟交换机或小型路由器，而与此同时，您盯着的那张流量图，只会显示一个不起眼的小凸起，看不出任何异常的理由。「我们有十吉比特」因此并不能回答任何真正值得问的问题。

这也是为什么常开式过滤和按需式过滤，是两款用同一个名字销售的不同产品。按需式的意思是：先检测，再通过一家清洗服务商重新宣告您的前缀，然后把干净的流量用隧道传回来——现实中，从检测到第一个干净数据包抵达，通常要数十秒到几分钟不等，而很多攻击的持续时间比这还短。一项在它本该起效的事件结束之后才可靠抵达的缓解措施，其实是一份订阅服务，而不是一道防线，而这个区别，在两家服务商的功能列表上都同样看不出来。

过滤不是免费的，它的代价是延迟。在链路上游、以硬件方式在线检测的流量，在正常状态下的代价远低于一毫秒——我们自己公开了这个数字，连同测量所用的路由一并公开。绕道另一个国家的清洗中心、再用隧道传回来的流量，无论有没有人在攻击您，都要一直承受那趟绕行本身的代价。两种设计都合理，只是通常只有一种会被公开出来。

第七层，以及让人替您过滤它的代价

以上所有内容都止步于传输层，您的主机商在未经您许可的情况下能为您做的一切，也止步于此。一次 HTTP 请求泛洪，发生在您的 TLS 会话内部。上游没有任何人能看到 URL、方法、请求头或正文——这正是加密存在的意义，而且它确实有效。您的主机商若要过滤它，就必须先解密它，而一个能够解密您流量的服务商所拥有的能力，不是任何司法管辖区的论证、磁盘加密方案或隐私政策能够扛得住的。

所以诚实的选项只有两个，没有第三个。要么您自己在应用内部处理应用层洪流，要么在前面放一个代理，由您主动把证书和私钥交给它，由它读取每一个请求之后再转发出去。这就是这笔交易，一句话说完；任何不做到这两件事之一，却承诺提供第七层防护的供应商，其实只是在用更好听的话描述第三层过滤。

如果您选择用代理，那么这整套安排就都建立在一个假设之上：攻击者无法直接触达您的服务器。您的源地址一旦泄露，所有请求都会绕开代理，而您花钱买来的防护也就成了摆设。源地址会通过好几个渠道泄露：您上代理之前用过的那个名字留下的 DNS 历史记录、从同一台机器发出的邮件、记录着您申请过证书的每一个名字的证书透明度日志、那个没人记得要接入代理的子域名，以及能在几个小时内把您的证书和互联网上每一个地址逐一比对的全网扫描器。一个没有防火墙、不能拒绝除代理自身地址段之外一切流量的代理，只是在没有去掉任何东西的情况下，又加上了一层——同一份指南里还讲了，这一层还会代您转发出去哪些别的东西。

第七层里不那么光鲜的那一半，更便宜，而且不需要任何供应商。给匿名访客返回一个缓存好的响应，几乎不花您一分钱，所以积极地做缓存，能把大多数泛洪都变成一件无关紧要的小事。限速应该设在开销高昂的端点上，而不是整个网站上，因为首页从来都不是目标。任何慢到值得被攻击的东西，通常也都值得被优化。而一个静态的兜底页面——放在另一个地址上，清楚地说明服务正在遭受攻击、以及该什么时候再来试——在事件发生期间，对您的用户来说，比任何数量的、默默失效的基础设施都更有价值。

事发之前该决定的事，按价值排序

这些事没有一件能在攻击发生时临时安排，但也没有一件不能在一个下午之内安排妥当。顺序比全不全更重要：前两项不花一分钱，却比其余加在一起更能左右结果。

1. 买之前先读滥用条款（10 分钟）。找到关于指向您服务的流量的那一段，看清楚服务商为自己保留了什么权利。如果它写着，可以自行决定实行空路由，且没有义务通知您，那么无论产品页面怎么写，这才是真正的产品——而您现在免费知道了这一点。
2. 弄清楚过滤是标配还是一个独立档位（5 分钟）。如果是加购项，默认做法就是黑洞；问清楚攻击进行期间，普通套餐上的地址会怎样，以及升级能多快生效。「等攻击发生时再说」不是一个答案，因为 BGP 不会按您的时间表收敛。
3. 把必须保持在线的部分，和可以承受宕机的部分分开（一个下午）。把静态站点和状态页放在一个地址上，应用放在另一个地址上。当应用遭受请求泛洪时，您的用户依然能访问到一些真实的内容，而不是一个超时页面，而您也保留了一条能告诉他们发生了什么的渠道。
4. 在所有匿名流量前面都放上缓存（一个下午）。这是您能用上的、单项价值最高的应用层防御手段，每个月不花一分钱，还能让您的服务在没人攻击它的日子里更快——而这几乎是每一天，只有一天例外。
5. 按端点限速，而不是按站点限速（一小时）。登录、搜索、注册、密码重置，任何写入数据库或发送邮件的操作。一个对繁忙首页来说够宽松的全局限速，对一个登录表单来说宽松得离谱。
6. 弄清楚升级上报的路径，并且真的用一次（20 分钟）。搞清楚凌晨三点能联系到谁，通过什么渠道，对方又如何确认您的身份。一个以下一个工作日为目标的工单队列，算不上一条升级上报路径；在事故进行中才发现这一点，正是一个糟糕的一小时变成糟糕一周的原因。

这六件事里，两件是决策，四件是配置，而那两项决策，比另外四项加起来还更重要。如果您对自己足够诚实，不妨再加上第七件：提前定好一个界限——到了这个界限，您宁愿被黑洞一个小时，也不要继续硬扛。有些攻击，凭您的预算根本打不赢，而提前选定那个放弃的时刻，正是「决策」和「恐慌」之间的区别。

给所有兜售「DDoS 防护」的人的六个问题

这六个问题，任何真正自己运营网络的人，都能在钱还没有易手之前，用书面方式回答。愿不愿意回答这件事本身，就已经说明了大半问题。

• 过滤是在您的传输链路上游，还是在您自己的边缘？任何等于或低于传输数字的容量，保护的都是服务商的设备，而不是客户的可达性。这两个数字必须一起给出，才有意义。
• 在什么情况下，您会把一个客户空路由掉，会不会事先打电话？这是清单上唯一一个您猜不出答案的问题，也是决定您糟糕的一天会是什么样子的那个问题。
• 是标配，还是一个独立档位？如果是分档的，问清楚在那之前，没有升级的地址靠什么保护。答案只有一个，就是上一个问题。
• 是常开式，还是触发式——到第一个干净数据包送达要多久？任何以分钟为单位来衡量的防护，只对持续型攻击活动有效，而这类攻击只占少数。
• 既然您读不了我的 TLS，那第七层您打算怎么办？正确的答案，大致是「我们什么都做不了，但可以介绍能做到的人，还可以告诉您怎么把源站锁紧，让这件事真正有意义」。任何回避这个约束条件的答案，都值得读两遍。
• 你们上一次处理的攻击是什么样子的？规模、持续时间、攻击手法，以及你们做了什么。一个承载真实流量的网络会有故事可讲；一个从未遭受过攻击的网络，也就谈不上有什么处理流程。

这些答案筛选服务商的速度，比任何功能对比表都快，因为六个问题里有五个问的是运营，而不是设备，而设备是唯一能在销售页面发布当天就买到的部分。我们自己的答案，写在网络页面上，连同容量数字，以及我们刻意不对您的流量做的那些事；而第七层这个答案所依赖的约束条件，和让这个网站其余论述都能自洽的，是同一个约束：我们没法过滤自己承诺过不会去读的东西。

最后值得一说的，是一道减法题。拒绝服务攻击只是众多对手中的一个，而对大多数小型平台来说，它甚至都不是最先找上门的那一个——那份按可能性排序的清单把自动化扫描、版权投诉和支付纠纷都排在了它前面，而且排得没错。去买过滤服务吧，因为它随端口附赠，不花您一分钱。把下午的时间花在缓存、限速和兜底页面上，因为那些才是您自己的责任。也别让定价页面上的一个盾牌图标说服您相信，那个活在您自己应用内部的半个问题，已经有别人替您处理好了。它没有，以后也不会有。

由负责运维该平台的工程师撰写，并已于 1 个月前 复核。如果这里有错误或内容已过时，请通过客户面板告知我们——目前约有一半的内容更新正是这样来的。