一、为什么要聊这个？
前几天，用户运营的一个奇迹MU公益服网站遭了 DDoS 攻击 —— 这个网站依托奇迹 mu 服务器运行，攻击直接影响了服务器的正常服务。我们实在想不通，做公益的服务器为啥会被攻击？
平时大家很少聊这种攻击，但既然遇上了，我们觉得把奇迹 mu 服务器的经历和学到的东西分享出来，总比让攻击白白浪费时间好。而且我们发现，很多奇迹 mu 服务器都被攻击过，但很少有人分享应对经验 —— 结果就是每台奇迹 mu 服务器都得自己摸爬滚打，像独自对抗整个互联网的攻击；可攻击者呢？攻完这台攻那台，自己没任何损失，所以才敢这么肆无忌惮。
我们想试着改变这种情况，所以有了这篇分享。
二、攻击来了，奇迹 mu 服务器是怎么应对的？
攻击刚开始时，网站打不开，但我们还能进奇迹 mu 服务器的管理后台。进去后查了下服务器的网络连接，发现有超多异常连接在运行 —— 正常情况下，我们这台奇迹 mu 服务器的访问量没这么大。
这种情况其实好解决，因为这些攻击的 IP 都是真实的，只是占了奇迹 mu 服务器的连接资源。我们用了个简单办法：把那些连接数太多的 IP 封了，还设置成每分钟自动查一次、自动封。很快就封了一大批 IP，统计后发现大多来自韩国。另外，我们还调大了奇迹 mu 服务器能承受的连接数、优化了服务器上的 Nginx 配置，服务器很快就恢复正常了。
可第二天中午，问题又出现了：奇迹 mu 服务器的网络特别慢，ping 一下能丢 70% 的包，服务器上几乎没有正常连接。我们在服务器上抓包一看，攻击变了 —— 这次是大量垃圾数据包（UDP 和 ICMP 类型）占满了服务器带宽。这种问题得在网络层面解决（比如禁止这些类型的数据包），但我们没有自己的物理服务器，奇迹 mu 服务器的网络控制权也不在手上，得靠工信部 CERT 协助，临时协调不过来，依托这台服务器的网站只能暂时停摆。
好在后来有很多热心朋友帮忙，给了我们更好的网络和新的奇迹 mu 服务器资源，这才缓解了问题。
三、DDoS 攻击常见类型，奇迹 mu 服务器该怎么防？
先简单说下：DDoS 攻击就是 “分布式拒绝服务”，核心就是用各种办法占满奇迹 mu 服务器的资源，让正常用户用不了服务器上的服务。
咱们先想下，你打开奇迹 mu 服务器上的网站，正常流程是这样的：输入网址→浏览器查地址（DNS）→和奇迹 mu 服务器连上线→发请求→服务器处理（调用数据库、文件等）→返回结果。这个流程里，每个环节都可能被攻击：
比如你想打开服务器上的 A 网站，却被恶意导向了 B 网站（客户端劫持）；
攻击查地址的环节（DNS 劫持），让大家找不到奇迹 mu 服务器；
发大量垃圾数据包占满服务器带宽，或者占满服务器的连接数，让正常请求进不来；
利用奇迹 mu 服务器的弱点攻击（比如有些服务器用的 Apache 系统，处理请求效率比 Nginx 低）；
攻击服务器上的应用功能（比如频繁调用耗资源的接口，也就是常说的 CC 攻击）。
其实奇迹 mu 服务器的防御没那么复杂，关键是 “找对环节”—— 别用服务器的弱点扛攻击。比如网络层面的问题，别在服务器的应用上解决；应用层面的问题，别靠路由器处理。一套靠谱的防御，奇迹 mu 服务器大概要覆盖这几点：
保护好 “查地址” 的环节（DNS），可以用专业的第三方服务（比如 DNSPod）；
给奇迹 mu 服务器配足够的带宽，并且只允许正常的数据包进来（比如只开网站需要的 80 端口，其他都关了）；
用多台奇迹 mu 服务器组成集群抗压力，还可以用防火墙筛选正常请求 —— 把畸形的、太频繁的异常请求拦在服务器外面。
另外，攻击也不是无懈可击的 —— 攻击者的技术、资源也有漏洞。如果每台奇迹 mu 服务器的运营者都愿意分享被攻击的经验（比如攻击 IP 来自哪、用了什么工具），大家一起提升防御能力，攻击者自然会收敛。
四、我们找到了攻击奇迹 mu 服务器的源头
最让我们困惑的是：攻击我们的奇迹 mu 服务器没任何好处，为啥还要做？后来想通了 —— 攻击者没损失（不用担法律风险，也不耗自己资源），但我们的服务器损失大，这太不公平了。
不过这次我们没认栽，试着找攻击奇迹 mu 服务器的源头。首先发现，攻击用的 IP 都是真实的，而且大多来自韩国。这些被用来攻击的设备（比如路由器、VPN 设备），攻击完奇迹 mu 服务器后，肯定还会和攻击者保持联系 —— 通常是通过一个 DNS 域名。
我们先找了那些开放 80 端口的攻击 IP，发现很多设备用的是 “admin/admin” 这种简单密码，很容易就进去了。进去后，我们把这些设备的 DNS 指向改成了自己的 DNS 服务器，这样就能记录它们的请求。
之后通过分析请求日志，找到了一个可疑域名：workgroup001.snow****.net。这个域名有几个特点：存在时间短（1 年前注册）、搜索引擎查不到、每隔半小时就会被频繁请求（符合控制攻击设备的特征），而且指向的服务器藏在新加坡，还带有 Windows 后门。
后来这个域名直接指向了无效地址（127.0.0.1），我们更确定这就是攻击者控制攻击的域名。现在我们已经拿到了攻击奇迹 mu 服务器的设备列表和控制端信息，会交给中韩相关部门处理 —— 这次攻击者也有损失了（丢了一个控制网络和域名），终于公平了。
五、最后想对奇迹 mu 服务器运营者说的
没有完美的防御，也没有完美的攻击。奇迹 mu 服务器面对 DDoS，不用害怕，关键是找到攻击者的漏洞。如果大家都愿意分享奇迹 mu 服务器被攻击的经验、一起抓漏洞，攻击者在动手前就会掂量：会不会被抓？有没有损失？这样 DDoS 攻击自然会越来越少。
