日前，筆者求教服務器流量異常處理，看了日志之后發(fā)現(xiàn)一坨掃描器留下的痕跡。發(fā)現(xiàn)了WVS的掃描記錄，小小的日志文件都被撐成幾G大了(服務器框架定義404頁面，導致不存在的頁面請求特別多)...

WVS確實是好東西，用來爬爬目錄啥的最開心了，但是用來掃別人是挺開心的，自己被掃就不一樣了...

所以就分析了一下其發(fā)包原理，想想怎么讓它無法工作...

環(huán)境：

網(wǎng)上隨便找了一個PHP的cms下載安裝，開了WVS的本地代理，burpsutie抓包分析...

分析過程：

通過分析包的格式，前期的探測腳本http頭帶著的關(guān)鍵參數(shù)如下：

GET /acunetix-wvs-test-for-some-inexistent-file HTTP/1.1
Accept: acunetix/wvs
Expect:
Cookie: acunetixCookie=AAAAAAAA...N個A...AAAAAAAA
GET /ClientAccessPolicy.xml HTTP/1.1 類似這樣的查找robots.txt 各種 xml常見文件
GET /favicon.ico HTTP/1.1特別有意思的就是這個favicon.ico文件，在日志文件中發(fā)現(xiàn)這個文件被訪問了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

前期掃描一些比較奇葩的漏洞都會帶以下參數(shù)

Accept: acunetix/wvs

后期的XSS和SQL掃描大概看了下特征的字符就是以下字符

Acunetix-Aspect:

Acunetix-Aspect-Password:

Acunetix-Aspect-Queries:

這三個字段

那就把來路帶有關(guān)鍵字的都過濾掉...讓你掃去!(這時候就是寧可錯殺三千，不能放過一個!)

思路：

檢測HTTP頭中的

參數(shù)：值

任意包含acunetix中就禁止訪問，順便再返回一個500服務器錯誤。

禁止的方法想了好幾種，網(wǎng)上有關(guān)這個的就看到當初oldjun和heige的兩個思路。不過貌似都不太適合，有興趣的同學可以自己看看。

因為分析發(fā)現(xiàn)掃描過程中一些SQL注入腳本或者其他腳本是不包含以上提到的關(guān)鍵字。

因此想到利用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