行之有效的屏蔽恶意 URL 请求的方法分享

说起恶意 URL 请求（Malicious URL request）可能很多老站长们应该都知道，URL 恶意请求对于网站来说是很正常的一种“黑客行为”，大家都知道搜索引擎有“蜘蛛爬虫”（bot），那么反之黑客也有自己的“漏洞蜘蛛爬虫”。简单点说就是一个可以在网络上运行并且不断的“遍历”发现的网站上的程序漏洞并记录反馈给指定的服务器什么的，需要的时候就可以针对网站漏洞进行攻击或者什么的（攻击只是一个统称，把被攻击网站做“肉鸡”用来攻击别人，盗取网站重要资料，木马植入等等算是一种攻击行为）。

『26 号被攻击的记录和分析』一文的攻击其实就是一次大规模的恶意 URL 请求造成的，如果你还是不明白或者无法理解恶意 URL 请求的话，那么下面的日志记录的请求只要你关注过自己站点的日志文件一定不会陌生：

119.188.116.15 - - [09/Jan/2019:12:23:19 +0800] "POST //sqzr.asp HTTP/1.1" 403 2155 "http://www.imydl.tech//sqzr.asp" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

119.188.116.17 - - [09/Jan/2019:12:23:19 +0800] "POST //css.asp HTTP/1.1" 403 2155 "http://www.imydl.tech//css.asp" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

119.188.116.17 - - [09/Jan/2019:12:23:19 +0800] "POST //?q={${eval%28$_POST[c]%29}} HTTP/1.1" 555 0 "http://www.imydl.tech//?q={${eval%28$_POST[c]%29}}" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

119.188.116.16 - - [09/Jan/2019:12:23:20 +0800] "POST //?q={${eval%28$_POST[c]%29}} HTTP/1.1" 555 0 "http://www.imydl.tech//?q={${eval%28$_POST[c]%29}}" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

150.138.216.82 - - [09/Jan/2019:12:23:20 +0800] "POST //?q={${eval%28$_POST[c]%29}} HTTP/1.1" 555 0 "http://www.imydl.tech//?q={${eval%28$_POST[c]%29}}" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

119.188.116.15 - - [09/Jan/2019:12:23:20 +0800] "POST //plus/result.php HTTP/1.1" 403 2155 "http://www.imydl.tech//plus/result.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

119.188.116.16 - - [09/Jan/2019:12:23:20 +0800] "POST //data/cache/asd.php HTTP/1.1" 403 2155 "http://www.imydl.tech//data/cache/asd.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

150.138.216.78 - - [09/Jan/2019:12:23:20 +0800] "POST //plus/result.php HTTP/1.1" 403 2155 "http://www.imydl.tech//plus/result.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)"

上面的就是 Nginx 日志里发现的恶意 URL 请求节录，这是明月自用的主机上 Web 服务器拦截屏蔽掉的恶意 URL 请求，当然这仅仅是个代表而已，形式有很多种，在『26 号被攻击的记录和分析』一文里明月曾经做过汇总分析，这些恶意请求可以说是无时无刻的存在着，估计很多站长们都见怪不怪了，但是有句话说的好，“不怕贼偷就怕贼惦记着”如果一直都无视这些恶意请求的话早晚会有一天造成恶劣的后果，比如 SQL 注入攻击、文件包含漏洞攻击、敏感文件探测、SQL 盲注攻击探测、远程代码执行漏洞攻击等等这些恶意请求一旦找到了漏洞就可以获取到需要的权限来实施盗取、植入、破坏了，毕竟谁也没有办法保证“漏洞”可以做到百分百能及时发现并修复的，正所谓“道高一尺，魔高一丈”最早发现漏洞的往往都不是官方，所以限制或者禁止这类随机似的恶意请求也是一种有效的安全防御策略。

目前明月采取的方式是 CDN+WAF+WEB 服务器三个层面同时拦截和屏蔽，运行这半个多月以来感觉还是非常不错的，细说起来这样的防御实施起来很简单：

首先选择一个 CDN 服务，最好是自带 WAF 的 CDN 服务，目前免费的 CDN 里比较推荐上海云盾和又拍云（加入又拍云联盟可以免费用一年）以及 360 网站卫士，除了又拍云需要手动开启 WAF 防护外，其他两个都是默认开启 WAF 的，并且都不需要我们自己设置 WAF 规则，这是最简单的措施了，几乎不用花费我们什么的，都是免费的。一些常见的恶意请求都会被 CDN 的 WAF 拦截并返回一个无效的 HTTP 状态码。当然这个 CDN 的 WAF 并不是万能的，想绕过这类 WAF 其实也很简单，所以我们还得在服务器上有自己的 WAF。

其次服务器端的 WAF 意义就在于可以自定义拦截屏蔽规则通过监控服务器日志文件再进行一次过滤屏蔽拦截，在『LNMP 1.5 测试版体验之 ngx_lua_waf 初体验！』一文里明月专门介绍过 LNMP 环境下借助 Nginx 的 LUA 模块自建 WAF 的方法，有兴趣的站长可以参考一下，一般默认的规则基本就够用了，如果你的正则表达式功力深厚可以自己再添加一些适合自己的规则就更好了。

最后，在有了 CDN 的 WAF 和服务器的 WAF 后，还是会有漏网之鱼的，理论上这时候基本已经非常的干净了，但是“道高一尺，魔高一丈”原则下是没有“绝对”的，所以还可以借助 Web 服务器来屏蔽恶意请求的，在『Nginx 防止 SQL 注入、XSS 攻击的实践配置方法』一文里，明月收集整理的 Nginx 站点配置文件里的根据不同请求设定条件判断返回对应的 HTTP 状态码就算是最后一次的屏蔽和拦截了，仔细研究一下话可以举一反三根据自己站点的实际情况调整更加适合自己，明月比较喜欢的是“拦截 17ce.com 站点测速节点的请求”，别人测试你的站点速度回瞬间让你的站点负载飙升，所以直接拦截掉类似的请求显得很高大上。其实这个方法最主要就是对所有“GET”类请求进行判断后返回不同的 HTTP 状态码，对于那些爬虫、机器人发出的请求效果还是非常明显的，明月建议大家能用还是用上最好。代码很长，建议大家采用见这些代码放到一个单独的.conf 文件里在站点配置文件里 include 的方式引用即可。

经过上面所述三个层面的撸了又撸，基本上可以屏蔽掉 80%以上的恶意请求了，为什么说是 80%而不是 100%呢，因为还是那句话“道高一尺，魔高一丈”，以后只需要经常的分析日志文件做出恶意请求的规则再设定对应的拦截屏蔽策略启用即可。减小了这些恶意请求后，自己服务器的安全系数自然也就上升了不少，就算是有漏洞风险也减小了很多！

·END·