网站防御再升级 fail2ban 对接 cloudflare 智能拦截恶意攻击
花了整整一天时间，我还是太蠢了，好在功夫不负有心人。
我们可以防御常见的404攻击和503攻击，更稳健，发现暴力攻击直接拉黑IP。关小黑屋1小时。让脚本黑客小子有来无回！
404攻击是常见的套路也是部分php应用的软肋，404原本是为了标记找不到文件用的错误状态码，但是攻击者会故意触发404，发送大量随机无效的请求，再加上wpWordPress网站是php驱动的，这些请求nginx发现找不到文件直接重写到php入口文件，nginx也很无奈只能当甩手掌柜，这是大部分php应用运行机制，所以请求都会来到PHP再到达数据库找数据资源，请求量异常大对数据库mysql造成巨大压力，再牛逼的独立服务器都不一定能抗，更何况我的2+4小鸡，目的是榨干你服务器性能。让你网站宕机无法访问。所以硬抗就只有死路一条。我找了很多方法都解决不了这个问题。只能回归封禁IP这条路了。
503是拒绝访问，大多在nginx层面配置请求频率限制后出现的，目的是防止单一IP高频请求，设立的封堵机制。他的封堵目的是为后端php，mysql减轻压力用的。但也很局限，因为只是瞬间阻止而已。再次请求还会受理。这种大量请求也会影响正常用户访问网站，触发503服务器暂时不可用。所以上fail2ban也会借助503状态码封禁恶意IP。
以前对fail2ban的运用一直有缺陷，无法拦截docker应用的访问请求。也知道docker网络是独立的。无意间发现有前辈已经搞定了，所以我直接用上了。
不过我比他更进阶了，已经对接cf的防御。因为开了CDN后用户的源IP被cf代理了，所以我们封禁该IP无效，只能让cf出面封禁访问IP。来达到网站恶意请求完美封禁。
接下来将分为两部分一部分是源站自主防御，另一部分开CDN后的防御。
版权声明：
作者：KEJILION
链接：https://blog.kejilion.pro/fail2ban-cloudflare/
来源：科技lion官方博客【国内版】
文章版权归作者所有，未经允许请勿转载。
EzXxY
求大佬快速更新，很需要这些知识！
James
很有意思的讨论，不过有一些东西作者没说清楚，
“404”攻击是什么？其实就是生成随机的URL Path。比如
“`text
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7
https://www.jamesflare.com/en/mvQ3oX3NJRCfy8LBdWdL
https://www.jamesflare.com/en/AK3VdReDX4AKmAYanV9j
https://www.jamesflare.com/en/2Msmu2zDGwA4Fd4hDroF
https://www.jamesflare.com/en/crq8KXvMaFphdYhGNaFA
“`
这么做是为了击穿缓存，让请求到达WordPres实例。
那么，你可能要问了，那不就返回404了吗，有什么问题呢？首先我们要明白返回一个404也是需要开销的，这个开销在不同应用下不一样。如果是一个Ngnix服务的静态网站，那么当Nginx在本地找不到请求的文件时就会返回404，这个开销很低。
但在WordPress里，这个开销不是很低，这要从它的逻辑说起。WordPress的页面需要让`index.php`来处理，我们在配置的时候想必写过类似的Rewrite Rule吧
“`nginx
# enforce NO www
if ($host ~* ^www\.(.*))
{
set $host_without_www $1;
rewrite ^/(.*)$ $scheme://$host_without_www/$1 permanent;
}
# unless the request is for a valid file, send to bootstrap
if (!-e $request_filename)
{
rewrite ^(.+)$ /index.php?q=$1 last;
}
“`
道理就是把请求交给`index.php`处理，
“`text
# 浏览器请求的
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7
https://www.jamesflare.com/en/XXbwQMzBFL27zizGAeh7.jpg
# WordPress看到的
https://www.jamesflare.com/index.php/en/XXbwQMzBFL27zizGAeh7
https://www.jamesflare.com/index.php?q=XXbwQMzBFL27zizGAeh7.jpg
“`
这下压力来到WordPress这一边，它首先匹配一遍数据库里有没有这篇文章，没有之后返回404，然后开始像织毛衣一样编织404页面的HTML内容，要是你的404页面还比较时髦，用到的资源比较多，那开销更大了。约等于直接访问了一次动态的文章（但开销应该还是比真文章小）。
还有就是一般人可能会高估他们VPS的性能，绝大多数的VPS性能很差，可能3-4个洋垃圾核心不如你笔记本的半个核心，没缓存的话可能几十rqs网页就爆了。
我猜测KEIJILION针对这个`index.php`特性的解决方法是通过扫描Nginx日志中产生404等异常码的IP，并且通过API加入CloudFlare中的黑名单，一小时后释放。日志差不多长这个样子
“`text
47.29.201.179 – – [28/Feb/2019:13:17:10 +0000] “GET /?p=1 HTTP/2.0” 200 5316 “https://domain1.com/?p=1” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36” “2.75”
“`
这样就极大程度缓解了这个漏洞（其实我觉得叫特性更合适）。
更多的内容我写了一篇文章 [针对 WordPress 特性的 DDoS 攻击原理与探讨](https://www.jamesflare.com/zh-cn/cc-attack-on-index-php/)