上次发帖求教服务器流量异常处理，看了日志之后发现一坨扫描器留下的痕迹。
发现了WVS的扫描记录，小小的日志文件都被撑成几G大了…（服务器框架定义404页面，导致不存在的页面请求特别多）
WVS确实是好东西，用来爬爬目录啥的最开心了，但是用来扫别人是挺开心的，自己被扫就不一样了…
所以就分析了一下其发包原理，想想怎么让它无法工作…
环境：
网上随便找了一个PHP的cms下载安装，开了WVS的本地代理，burpsutie抓包分析…
分析过程：
通过分析包的格式，前期的探测脚本http头带着的关键参数如下：
GET /acunetix-wvs-test-for-some-inexistent-file HTTP/1.1
Accept: acunetix/wvs
Expect: <script>alert(12345)</script>
Cookie: acunetixCookie=AAAAAAAA…N个A…AAAAAAAA
GET /ClientAccessPolicy.xml HTTP/1.1 类似这样的查找robots.txt 各种 xml常见文件
GET /favicon.ico HTTP/1.1特别有意思的就是这个favicon.ico文件，在日志文件中发现这个文件被访问了N+1多次…
POST https://localhost:8443/enterprise/control/agent.php HTTP/1.1
ACUNETIX /9149447 HTTP/1.1
HTTP_AUTH_LOGIN: ‘
HTTP_AUTH_PASSWD: acunetix
Client-IP: SomeCustomInjectedHeader:injected_by_wvs
Referer: ‘;print(md5(acunetix_wvs_security_test));$a=’
Accept: acunetix/wvs
Acunetix-Aspect: enabled
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect-Queries: filelist;aspectalerts
突然看到WVS也会检测FCK，不过就是目录检测不全…
GET /fckeditor HTTP/1.1
前期扫描一些比较奇葩的漏洞都会带以下参数
Accept: acunetix/wvs
后期的XSS和SQL扫描大概看了下特征的字符就是以下字符
Acunetix-Aspect:
Acunetix-Aspect-Password:
Acunetix-Aspect-Queries:
这三个字段
那就把来路带有关键字的都过滤掉…让你扫去！（这时候就是宁可错杀三千，不能放过一个！）
思路：
检测HTTP头中的
参数：值
任意包含acunetix中就禁止访问，顺便再返回一个500服务器错误。
禁止的方法想了好几种，网上有关这个的就看到当初oldjun和heige的两个思路。不过貌似都不太适合，有兴趣的同学可以自己看看。
因为分析发现扫描过程中一些SQL注入脚本或者其他脚本是不包含以上提到的关键字。
因此想到利用session或者cookie来判断是否恶意请求，判断成立就500，是不是简单粗暴！
看看代码（相当简陋）
if(isset($_COOKIE["PHPinfoTest"]))
{
header('HTTP/1.1 500 Internal Server Error');
exit();
}else{
foreach ($_SERVER as $key => $value) {
If(strpos(strtolower($key),"acunetix")!==false||strpos(strtolower($value),"acunetix")!==false){
header('HTTP/1.1 500 Internal Server Error');
setcookie("PHPinfoTest","IZIEMILOULOAIXNAUHIXLOAIX",time()+60);
exit();
}
}
}
放在全局变量的文件里
看看效果：
使用脚本以后：
这里也只是粗浅的提供一种方法，如有说的不对的，请指正。
转自：http://zone.wooyun.org/content/7942
ps:上面的防护其实是简单的通过请求头来识别awvs的扫描，虽然能起到一点效果，但是也很好绕过（使用burp替换请求头中的相应关键字即可）。要使所有的扫描软件都能去掉其关键特征，绕过服务端的检测，可以参考《自制分布式漏洞扫描》
转载请注明：jinglingshu的博客 » 服务器流量异常追踪–抵抗AWVS扫描