短信发送接口被恶意访问的网络攻击事件(二)肉搏战-阻止恶意请求

<h1>前言</h1>

承接前文《短信发送接口被恶意访问的网络攻击事件(一)紧张的遭遇战险胜》，在解决了短信发送的问题后，长长地舒了口气，也就各忙各的事情去了，本以为应该是个完美的收场，哪知道只是泥泞道路的前一段，收场是收不了了，还是要去应付接下来的烂摊子，因为攻击者并没有停止攻击，虽然恶意请求已经可以被识别并且不会被业务服务器处理，也不会去触发短信发送接口，但是请求依然会源源不断的到达服务器，而且丝毫没有停止的意思。

像前文中说的，那种感觉就像葛大爷被麻匪给劫了，既然被贼给盯上了，你觉得是那么轻而易举的就能够挣脱的了么？

geyou

<h1>问题分析</h1>

公司用的是阿里云的云服务器ECS，在ECS控制台中查看入网流量：

入网统计曲线

虽然在程序中加入逻辑判断可以阻止非法请求对短信接口的触发，但是却无法阻止攻击者持续的向ECS发送请求，通过上图ECS的入网流量可以看到，在流量上升之后，并没有降下来的意思，得，这狗皮膏药真的一时没法撕下来了，虽然说这些个攻击者无聊，但还是得跟他们杠上了，心累。

所以刚刚开心了没多久，又陷入了困顿之中，刚刚踩完一个坑，爬上来没多久，发现眼前又是一个坑，坑坑复坑坑，开发的坑是何其多，运维也一样，都是一家人。

bug

鲁迅说过：

你尽管说，说得有用算我输，坑还是得踩，谁让你做开发的。

luxun

我们都知道流量攻击，攻击者用大流量来压垮网络设备和服务器，或者有意制造大量无法完成的不完全请求来快速耗尽服务器资源，现在看来这次的短信接口攻击称不上流量攻击，因为数量级不在一个概念上，虽然也存在大量的非法请求，但是并不足以瘫痪设备，当然，这些话都是写在事件结束之后的，与事件发生时的想法可能有些出入，因为当时并不确定攻击者的请求是否会持续增加、是否会打满服务器的带宽，是否会影响正常请求，是否会使服务器瘫痪.....

看着持续不减的入网流量，思考了半天，最终是打算加入防火墙，通过封掉这些恶意请求的IP，让ECS直接拒绝请求，在请求的第一步就把它弄死，将入口堵住应该可以一定程度的阻止攻击者继续攻击，也使得流量降低不会影响到处理正常请求所用到的系统资源。

前文提到的只是针对具体的系统模块，在应用层降低攻击的危害，因为一开始认为这次攻击只会影响短信接口，但是如果是流量攻击的话，则是影响整个服务器层面，会影响所有在这台服务器上的基础设施，这个就比较麻烦了，想法只有一个：阻止入网请求。

<h1>应急方案--iptables防火墙</h1>

一开始想到的是用iptables来作为这次的防火墙工具，花了些时间，写了一个分析日志的shell脚本，把攻击者的IP定位出来，然后把这些IP放到iptables的策略中给封掉，以下为iptables策略设置的脚本，运行脚本的前提是你的linux服务器中安装了iptables工具。

#!/bin/sh

#iptables设置
#author:13

iptables -P INPUT ACCEPT
iptables -F
iptables -X
iptables -Z
iptables -A INPUT -i lo -j ACCEPT

iptables -I INPUT -s 111.147.220.88 -j DROP
iptables -I INPUT -s 101.68.56.76 -j DROP
iptables -I INPUT -s 106.6.90.58 -j DROP
iptables -I INPUT -s 111.147.212.230 -j DROP
......
（这里省略了大部分的IP，因为太多了）

iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

#保存设置
service iptables save
#重启iptables服务
systemctl restart iptables.service

虽然选择了这个方式，但是也知道这种方式比较笨拙和被动，而且不能完全的做到自动化，以后有时间会试着用nginx+lua+redis写一个拦截器，作为限制恶意IP访问的小工具，近期也会找一下其他的解决方案。

由此，最新阻止攻击的方式已经变成了下图中的模式：

iptables防火墙

根据日志文件来分析请求，一旦被识别为恶意IP的话，之后的所有请求都会被iptables防火墙拦截，请求不会被处理，半天时间限制了500多个IP的访问，但是依然会有新的IP加入到攻击之中，散列IP攻击真的很烦，限制了短信发送后，已经不会进一步造成损失，而今天又做了IP访问限制，更进一步确保了攻击造成的影响降低，同时也降低了流量陡增给系统带来的危害。

这次攻击并没有造成进一步的影响，应该也算是送了一口气，从数量级上来看，倒不是特别大的攻击，就是这两天的日志文件比较大，因为在没有限制IP访问时，这几百个IP搭配无数的手机号码，发送的请求数量是挺惊人的。而至于这次的攻击者到底是什么人，出于什么目的，完全不得而知，人民币损失也是有的，但是还好发现和解决的及时，并没有造成太大的影响，肯定不至于丢了工作，哈哈哈哈。

<h1>防火墙效果</h1>

流量攻击由第一天的每分钟1000次左右的恶意请求(统计对象仅包含非法请求，正常请求不包含在内)，通过采用封锁IP的方法来进行防御之后，目前为每分钟10-20次左右的恶意请求，虽然已经拦截掉大部分的攻击，但是依然不断会有新的伪装IP加入到攻击当中，暂时也想不到其他办法来应对，因为IP是一直在变的，虽然在半天内已经封锁掉了500多条IP，不过依然还是会有新的IP带着新的请求进来，但是好消息是，现在的流量已经不像刚开始那样，像是开了闸口的洪水一样喷涌而来了，目前已经是锐减成涓涓细流了，他奶奶的。

ip
整个过程你来我往的，看似热闹，其实就是菜鸡互啄，攻击者通过工具发送恶意请求，恶意请求进来并被记录到日志文件中，被脚本检测到之后加入到iptables策略中封锁IP，然后攻击者又会利用新的IP做攻击，检测到之后再次封锁，周而复始。说难度嘛，倒是没什么技术难度，至于麻烦嘛，是有一些小麻烦，再说损失，通过参数验证后，应该不会请求短信服务商再造成损失了，关键是被恶心到了，毕竟这个事情没法彻底的解决掉，除非停掉这一个服务，这是不可能的，也只能等下次更新了，中间这段时间只能被恶心了。

<h1>防火墙的方案</h1>

虽然当时是选择使用iptables来作为主要的防火墙工具，但是现在想想，也有其他方法的，事后诸葛亮一下，总结了以下四种方式，希望大家补充：

• iptables
• hosts.deny
• 阿里云的ECS安全策略
• WAF(这个是前一篇文章中一位朋友留言提到的方案)

<h1>结语</h1>

也想过在APP重新发版时，重新设计一套url，将原来的url废弃掉，或者关闭一些服务器以杜绝这些攻击，但是，这些都是冲动和极端的想法和做法，即使APP重新发版，也不可能立即关闭后端服务器，关闭后端服务意味着完全抛弃对上一个版本的支持，但是正确做法不可能对没有更新版本的用户不管不问，即使他们不更新也要保证原来的整体功能可用。不能因为一个服务的错误，让用户去承受错误，不能让用户来为我们埋单，停掉服务器的做法不可行，没有到那个地步，因此只能是自己去解决和维护。

每次发生这种意料之外的事件，都会提醒自己做好安全保障工作，不可掉以轻心，不要给心怀恶意之人有可乘之机，这次损失一块钱RMB，下次可能是一千块，一万块，金钱的损失可以衡量，如果是给系统带来影响或者给团队招来不必要的麻烦就真的百口莫辩了。

目前来看，虽然是解决了一部分问题，用请求验证阻止发送短信，用iptables阻止恶意IP的访问，但是并没有根本解除掉攻击，不排除攻击者会进一步攻击的可能性，因此只能被动的防守，同时也做好web和服务器的安全防护。

首发于我的个人博客，地址在这里

security