可以说是我试图进入安全口的天才第一步了, 能走多远鬼知道呢
背景
去年年前接到的一个外包项目, 是一个 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 分钟, 半小时攻击停止五分钟等各种憨批操作...... 下图这些稀奇古怪的字符串有无大佬知道是什么, 还请评论区教教我.
后来我配上一小时内连续访问 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 一 瞬 缓 存
愿大家在防御的路上武运方昌!
来源: https://www.cnblogs.com/jackablack/p/13272855.html