记一次针对静态页面的DDOS基本防护
可以说是我试图进入安全口的天才第一步了,能走多远鬼知道呢
背景
去年年前接到的一个外包项目,是一个base在日本的中国人留学机构做的静态页面。出于锻炼自己的目的,选择为他们按次结薪做长期服务维护。20年618当天给我越洋电话打过来说大量潜在客户试图访问机构官网报错无法访问服务器,让我去帮他们看看怎么回事。
回到电脑前登陆阿里云,发现带宽和CPU被占满了,如下图所示:
第一反应就是:坏了,拒绝服务攻击,搞不好还是分布式的……然后登陆后台尝试看日志,发现还真是拒绝服务攻击:
还行,不是分布式的,不过也够吃满了服务器的1核1G1MBps小水管了……对方还挺无聊,发post没把body整的整齐划一,内容缤纷多彩
处理过程
第一阶段:请求洪泛
iptable bans:
由于发现对方没有使用分布式的攻击手段,我考虑停止对攻击流量的来源IP地址进行HTTP响应,经过查询学习,我选择使用iptables命令完成这一操作:iptables -I INPUT -s <ip addr.> -j DROP
通过此命令,当传入网关的ip地址为定义的ip时,网关会直接丢弃请求,不做任何处理。然而很快我就发现自己太年轻了。对方显然不是抱着笔记本在攻击我,他们不仅更换了ip, 还欢乐骂我的话……
我当时很幼稚的不死心,又用iptables ban了对面五个IP,然后对方换了IP继续打我,我真的毫无办法……
第二阶段 分布式请求洪泛
ddos deflate:
由于对方会动态更换IP地址,单纯手动封禁IP只能做到“见招拆招”,假设对方用的手动更换IP还好,拼手速即可,一旦人家用的是IP池自动调用,人是肯定干不过机器的。一开始打算造轮子,结合
iptables -I INPUT -s <addr> -j DROP
弄个脚本自动封IP,后来觉得雇主给不了让我满意的钱而且我太懒,于是转而上网寻找轮子——找到了ddos deflate
这款软件完全实现我的想法:轮询拿指定时间范围内的网络访问记录,把设定时间长度内连续请求数量大于指定值的IP自动关进小黑屋一段时间。但是他不是万能的,对于雇主的小水管,一秒一次的请求居然也能造成服务延迟,对方不断试探我配置的参数,先后有过一秒一次,五分钟30次然后停止攻击5分钟、半小时攻击停止五分钟等各种憨批操作……下图这些稀奇古怪的字符串是写成16进制的机器码,又名shellcode,只要攻击者通过overflow等方式将这些代码覆写在内存,就有可能执行这些机器码的功能,一般来讲会获取服务器的控制权限、安装后门、下载恶意程序等。
后来我配上一小时内连续访问50次就ban的自杀式配置了以后,服务器太平了10天左右。我自以为高枕无忧,没想到……
第三阶段 SYN 半开链接攻击
强安全策略 + CDN掩盖源站地址
这次雇主又给我打电话,说裂开了,访问时断时续的。我上去看发现对方每三十秒给我发一次脏话。奇了怪了,这怎么会让服务崩溃呢?用netstat命令查看发现有些IP地址连接数很高却没有被 ddos deflate屏蔽掉,于是查看这些IP的链接情况(图是我后来截的):
可以看到,有些IP一直处于 SYN_RECD 状态(这里没有是因为攻击已经被屏蔽了,命令是对的哈),意即为已经向其发送了SYN信号等待第三次握手,却没有收到ACK。每当一个IP地址端口向我们的服务器发送TCP链接请求,都会有一个线程被唤起对其提供服务,如果攻击者drop我们发回的SYN,默认的该线程会等待15分钟并重试3次,也就是说对方每个端口发动攻击一次就会浪费一个线程45分钟。当量足够大,线程池爆掉的时候,你的服务器就再也无法为正常用户提供服务了。
这一攻击致命在于你不能判断一个TCP半开链接是真的网不好还是有恶意,所以超时太短会导致影响正常用户体验,太长则会被对方攻击流量洪泛。网传的哪些加大窗口队列长度、缩短超时时间等方法实际上并不能解决本质问题。
那么我们怎么解决这个问题呢?
答案是使用分布式内容分发网络(CDN)。由于CDNIP不固定且遍布全球,某个IP如果被短时间高流量爆破,还有其他的IP为用户提供服务,不会导致系统完全停止响应。而大多CDN提供了更好用的防火墙设置,也能方便我们自定义安全策略。本次处置我采用了CloudFlare CDN(免费版)+ 阿里云强安全策略解决了这一问题。
第一步:部署CloudFlare
登陆注册以后,前往你的域名服务商,将DNS重定向至Cloudflare提供的地址:
随后,等待24h使修改生效。
第二步:应用强安全策略
在阿里云上使用网络安全组策略,设置一个优先级为2的禁止任何流量流入或流出服务器的组策略和一个优先级为1的允许Cloudflare IP地址通过防火墙的组策略:
这时你的服务应该已经恢复正常了,因为攻击者就算知道源站IP,也没有办法用垃圾流量塞满你的服务器了。但是这还不够太平,因为他们有可能洪泛掉免费CDN那点可怜的带宽,怎么办呢:
第三步:使用Cloudflare防火墙策略
在Cloudflare上,根据雇主特点(访问集中于东亚洲几个国家和几个VPS常见地址)部署自定义的防火墙策略,如图:
成效是显著的,域外发动的攻击基本全部被屏蔽,一个月以来,我们的服务再也没有中断过,而对方的攻击流量全部被Cloudflare 一 瞬 缓 存
愿大家在防御的路上武运方昌!