一个多月前，我的个人网站遭受 ddos 攻击，下线了50多个小时。这篇文章就来谈谈，如何应对这种攻击。
需要说明的是，我对 ddos 并不精通，从没想过自己会成为攻击目标。攻击发生以后，很多素昧平生的朋友提供了各种帮助和建议，让我学到了很多东西。这里记录的就是对我最有帮助的一些解决方案。
一、ddos 是什么？
首先，我来解释一下，ddos 是什么。
举例来说，我开了一家餐厅，正常情况下，最多可以容纳30个人同时进餐。你直接走进餐厅，找一张桌子坐下点餐，马上就可以吃到东西。
很不幸，我得罪了一个流氓。他派出300个人同时涌进餐厅。这些人看上去跟正常的顾客一样，每个都说”赶快上餐”。但是，餐厅的容量只有30个人，根本不可能同时满足这么多的点餐需求，加上他们把门口都堵死了，里三层外三层，正常用餐的客人根本进不来，实际上就把餐厅瘫痪了。
这就是 ddos 攻击，它在短时间内发起大量请求，耗尽服务器的资源，无法响应正常的访问，造成网站实质下线。
ddos 里面的 dos 是 denial of service（停止服务）的缩写，表示这种攻击的目的，就是使得服务中断。最前面的那个 d 是 distributed （分布式），表示攻击不是来自一个地方，而是来自四面八方，因此更难防。你关了前门，他从后门进来；你关了后门，他从窗口跳起来。
二、ddos 的种类
ddos 不是一种攻击，而是一大类攻击的总称。它有几十种类型，新的攻击方法还在不断发明出来。网站运行的各个环节，都可以是攻击目标。只要把一个环节攻破，使得整个流程跑不起来，就达到了瘫痪服务的目的。
其中，比较常见的一种攻击是 cc 攻击。它就是简单粗暴地送来大量正常的请求，超出服务器的最大承受量，导致宕机。我遭遇的就是 cc 攻击，最多的时候全世界大概20多个 ip 地址轮流发出请求，每个地址的请求量在每秒200次~300次。我看访问日志的时候，就觉得那些请求像洪水一样涌来，一眨眼就是一大堆，几分钟的时间，日志文件的体积就大了100mb。说实话，这只能算小攻击，但是我的个人网站没有任何防护，服务器还是跟其他人共享的，这种流量一来立刻就下线了。
本文以下的内容都是针对 cc 攻击。
三、备份网站
防范 ddos 的第一步，就是你要有一个备份网站，或者最低限度有一个临时主页。生产服务器万一下线了，可以立刻切换到备份网站，不至于毫无办法。
备份网站不一定是全功能的，如果能做到全静态浏览，就能满足需求。最低限度应该可以显示公告，告诉用户，网站出了问题，正在全力抢修。我的个人网站下线的时候，我就做了一个临时主页，很简单的几行 html 代码。
这种临时主页建议放到 github pages 或者 netlify，它们的带宽大，可以应对攻击，而且都支持绑定域名，还能从源码自动构建。
四、http 请求的拦截
如果恶意请求有特征，对付起来很简单：直接拦截它就行了。
http 请求的特征一般有两种：ip 地址和 user agent 字段。比如，恶意请求都是从某个 ip 段发出的，那么把这个 ip 段封掉就行了。或者，它们的 user agent 字段有特征（包含某个特定的词语），那就把带有这个词语的请求拦截。
拦截可以在三个层次做。
（1）专用硬件
web 服务器的前面可以架设硬件防火墙，专门过滤请求。这种效果最好，但是价格也最贵。
（2）本机防火墙
操作系统都带有软件防火墙，linux 服务器一般使用 iptables。比如，拦截 ip 地址1.2.3.4的请求，可以执行下面的命令。
$ iptables -a input -s 1.2.3.4 -j drop
iptables 比较复杂，我也不太会用。它对服务器性能有一定影响，也防不住大型攻击。
（3）web 服务器
web 服务器也可以过滤请求。拦截 ip 地址1.2.3.4，nginx 的写法如下。
location / {
deny 1.2.3.4;
}
apache 的写法是在.htaccess文件里面，加上下面一段。
<requireall> require all granted require not ip 1.2.3.4 </requireall>
如果想要更精确的控制（比如自动识别并拦截那些频繁请求的 ip 地址），就要用到 waf。这里就不详细介绍了，nginx 这方面的设置可以参考
- https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/
- https://www.nginx.com/blog/rate-limiting-nginx/
web 服务器的拦截非常消耗性能，尤其是 apache。稍微大一点的攻击，这种方法就没用了。
五、带宽扩容
上一节的 http 拦截有一个前提，就是请求必须有特征。但是，真正的 ddos 攻击是没有特征的，它的请求看上去跟正常请求一样，而且来自不同的 ip 地址，所以没法拦截。这就是为什么 ddos 特别难防的原因。
当然，这样的 ddos 攻击的成本不低，普通的网站不会有这种待遇。不过，真要遇到了该怎么办呢，有没有根本性的防范方法呢？
答案很简单，就是设法把这些请求都消化掉。30个人的餐厅来了300人，那就想办法把餐厅扩大（比如临时再租一个门面，并请一些厨师），让300个人都能坐下，那么就不影响正常的用户了。对于网站来说，就是在短时间内急剧扩容，提供几倍或几十倍的带宽，顶住大流量的请求。这就是为什么云服务商可以提供防护产品，因为他们有大量冗余带宽，可以用来消化 ddos 攻击。
一个朋友传授了一个方法，给我留下深刻印象。某云服务商承诺，每个主机保 5g 流量以下的攻击，他们就一口气买了5个。网站架设在其中一个主机上面，但是不暴露给用户，其他主机都是镜像，用来面对用户，dns 会把访问量均匀分配到这四台镜像服务器。一旦出现攻击，这种架构就可以防住 20g 的流量，如果有更大的攻击，那就买更多的临时主机，不断扩容镜像。
六、cdn
cdn 指的是网站的静态内容分发到多个服务器，用户就近访问，提高速度。因此，cdn 也是带宽扩容的一种方法，可以用来防御 ddos 攻击。
网站内容存放在源服务器，cdn 上面是内容的缓存。用户只允许访问 cdn，如果内容不在 cdn 上，cdn 再向源服务器发出请求。这样的话，只要 cdn 够大，就可以抵御很大的攻击。不过，这种方法有一个前提，网站的大部分内容必须可以静态缓存。对于动态内容为主的网站（比如论坛），就要想别的办法，尽量减少用户对动态数据的请求。
上一节提到的镜像服务器，本质就是自己搭建一个微型 cdn。各大云服务商提供的高防 ip，背后也是这样做的：网站域名指向高防 ip，它提供一个缓冲层，清洗流量，并对源服务器的内容进行缓存。
这里有一个关键点，一旦上了 cdn，千万不要泄露源服务器的 ip 地址，否则攻击者可以绕过 cdn 直接攻击源服务器，前面的努力都白费。
