经验测评

Nginx防御cc攻击之硬抗解决Proxy类型的cc攻击

Proxy代理类型的CC攻击方式描述:短时间大量攻击源,来源遍布于世界各个角落,常见于很多国外的低成本在线拒绝攻击服务提供网站,很多商业级别的老站也是用的这种方式,例如一些提供穿透CDN的拒绝攻击服务提供网站。
这篇文章其实很早就想写了,但是站长懒起来真的是太可怕了,所以到现在才发文。
写这个文章主要是四月份的时候,不知道是恶意还是某些人无聊,有段时间每天去我的代购站进行CC攻击,导致站点无法正常运行,时不时量还特别大,斗智斗勇了很久,不管是利用cloudflare的js验证还是配合检查脚本自动ban,升级服务器到很高的配置,尝试多台服务器均衡负载都没有什么很大的用处,在我快要放弃的时候,灵机一动,于是有了这篇文章。
如您的站点是高资源的动态站点(例如不能优化的PHP程序、没有做静态处理)wordpress、whmcs之类的,资金不宽裕购买不了高配置服务器等,人比较懒特别不愿意折腾一些新东西的用户,特别适合,毕竟其他程序靠着全站静态,或者别的方式就能很好的处理了。
那么,就开始文章吧。

甜点

首先来一个小小的甜点 Github的项目"blocklist-ipset"
项目地址:https://github.com/firehol/blocklist-ipsets
这个项目很棒,基本上每天都会更新了很多干坏事的IP,和CC相关的就是项目里的proxy相关的文件,如果您的站点使用了cloudflare的cdn,提取出来处理一下IP文件,然后利用下方的代码提交到cloudflare,直接Ban掉,能解决掉部分代理类型cc攻击来源。
脚本如下,保存为banip.sh执行即可

for line in $ip
do
echo $line >> /temp/blackip.txt
echo $line
done
# 这里还可以执行CF的API来提交数据到CF防火墙
# 填Cloudflare Email邮箱
CFEMAIL="你的cloudflare账号"
# 填Cloudflare API key
CFAPIKEY="你的APIKEY"
# 填Cloudflare Zones ID 域名对应的ID
ZONESID="你域名的ZonesID"
# /home/wwwlogs/black.txt存放恶意攻击的IP列表
# IP一行一个。
IPADDR=$(</temp/blackip.txt)
# 循环提交 blackip.txt 到 Cloudflare 防火墙黑名单
# 模式(mode)有 block(屏蔽), challenge(验证码), whitelist(白名单), js_challenge(js人机验证,俗称:5秒盾)
for IPADDR in ${IPADDR[@]}; do
echo $IPADDR
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONESID/firewall/access_rules/rules" \
-H "X-Auth-Email: $CFEMAIL" \
-H "X-Auth-Key: $CFAPIKEY" \
-H "Content-Type: application/json" \
--data '{"mode":"block","configuration":{"target":"ip","value":"'$IPADDR'"},"notes":"CC"}'
done

正文

那么就开始这篇文章的正文吧,首先站长在被这种攻击方式搞得焦头烂额的时候,灵机一动,想到了Nginx日志,看看攻击源的IP头,立马就去调整Nginx的日志格式,让它能显示出不同的头信息,日志格式配置如下。

log_format newlog '$remote_addr -$remote_user[$time_local]"$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$proxy_add_x_forwarded_for"';

主要就是在原有的基础上增加$http_x_forwarded_for、$proxy_add_x_forwarded_for,这两个的详细介绍可以参见搜索引擎
然后呢,攻击来的时候我们就可以看到如下的日志

nginx防御cc

nginx防御cc

由图可见,这种穿透cloudflare js5秒盾的攻击方式$remote_addr的值和后面新增的两个参数的值都不同,所以根据日志文件所显示的日志,我们就可以很方便的识别出来这种攻击了,然后利用nginx来硬抗它(返回444),代码如下(是的你没有看错,就是这短短的代码,解决了大大的问题)

A-适合服务器是直连解析,没有经过cdn保护,没有反代的情况下

if ($proxy_add_x_forwarded_for != $remote_addr){
return 444;
}

B-适合站点是经过CDN保护或者反代的情况下

if ($http_x_forwarded_for != $remote_addr){
return 444;
}

2020-05-21更新:站点经过CDN保护或者反代的情况下,需要让Nginx获取到访客真实IP,具体方法可以参照搜索引擎
添加好后,我们重启Nginx再次观察日志,会发现这种代理类型cc攻击类型,已经完全被阻挡了,我们的站点也就高枕无忧了,在本站站长的测试下,发现1核1G的配置也可以利用它来阻挡大部分市面上成本较低的一些恶意攻击,效果非常非常的棒。

那么也许有人会说了,很多高成本的攻击类型(大量真实服务器进行短时间超高并发访问)你这个不就没用处了吗,对于那种情况,因为IP来源少,可以很方便的利用一些比较原始的手段进行处理,比如定时检测日志,提取超过访问次数的IP进行防火墙Drop或者cdn屏蔽等等拉。毕竟高成本的攻击不是人人都承受得起的拉。好了该篇文章到此结束,强烈推荐被这种攻击类型的cc折磨的朋友可以试一试!

    For Share tools , Still working

关于作者

Yunlab-云喇叭-优选好物

4 条评论

  • 阿里云CDN,此方法无效
    日志:
    47.244.73.51 --[20/May/2020:16:54:47 +0800]"GET / HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36" "xxx.xxx.xxx.xxx" "xxx.xxx.xxx.xxx, 47.244.73.51"
    xxx是我的ip,正常的用户请求也被挡了。

    • 仔细阅读我的说明哦
      代码分为两种 一种是域名解析到真实服务器 前端没有任何cdn或者反代之类的
      一种是前端有cdn 或者有反代之类的
      前端有cdn的需要让后端的服务求获取真实IP

      我已经在很多个站实装了 不会阻挡真实访客 不会对爬虫有影响

留下评论