简单应对验证码接口恶意攻击

 这几天不断的有人攻击公司的验证码接口, 就是随机生成了一系列的手机号然后调用注册页面的验证码的接口. 对待这种攻击自然最严谨的是适时弹出验证码, 可临时我们没有这么快的速度去做这套验证码的方案(前面写了"适时"二字自然不能对所有人都弹出验证码, 本来用户转注册的转化率就低, 再加个验证码那就更难看了). 

今天又是周末, 只能简单处理一下.

我们的接口拉扯类似于

/api/smsCaptcha/send.json

注意到攻击者是用固定的几个IP来发起请求的, 此时最简单有效又不影响用户的方法自然是屏蔽攻击者的ip. 一个简单的指令就能让攻击者暴露无遗. 

tail -100000 /data/logs/nginx_access.log|grep smsC|awk "{print $1}'|sort |uniq -c|sort -n

好的, 把这些IP加到nginx的验证码接口location内. 

这边因为是事后记录, 所以这些IP不一定能与上面的列表对应. 

此时这些ip调用验证码接口已经变成了403. 

过了一会儿, 再去看一下, 果然攻击者换了IP又来了, 并且调低了调用频率. 

tail -100000 /data/logs/nginx_access.log|grep smsC|grep -v 403|awk "{print $1}'|sort |uniq -c|sort -n

加个403是把前面已经屏蔽掉的请求过滤掉. 好再把新的IP加到屏蔽列表. 再来怎么办? 乘这会儿攻击都还没有反应过来, 我们来写个shell脚本. 脚本的原来也很简单. 检查nginx访问日志的最后10W条请求, 如果有IP不停的调用验证码接口, 就自动加入到nginx的屏蔽列表内.

为此我们得单独搞个deny.conf, 然后在nginx.conf中去include它. 

先上shell. 

#!/bin/sh
# auto-deny.sh

nginx=/usr/bin/nginx
deny_file=/usr/local/nginx/conf/deny.conf
bad_ips=`tail -100000 /data/logs/nginx_access.log|grep smsC|grep -v 403|awk "{print $1}'|sort |uniq -c|sort -n|awk '{if ($1 > 8) print $2}'`

for ip in $bad_ips; do
	echo "deny ${ip};" >> $deny_file
done

sort $deny_file|uniq > /tmp/deny.conf
rm -f $deny_file
mv /tmp/deny.conf $deny_file

$nginx -t > /dev/null 2>&1
if [ $? -eq "0" ];then
	$nginx -s reload
fi

我们再加个定时任务, 5分钟跑一次. 

*/5 * 26 8 *  /data/shell/auto-deny.sh

OK任务完成, 可以先去午休一下了.