利用tcpdump抓包分析CGI被刷案例一则

利用tcpdump抓包分析CGI被刷案例一则
 

今天又遇见有业务CGI被刷的情况，随手整理分享一下，希望对大家有用。空间的base小域名流量一直增长，但业务方面没有发布变更，其他SET也没...

id="cproIframe_u944267" width="250" height="250" src="http://pos.baidu.com/acom?adn=3&at=231&aurl=&cad=1&ccd=24&cec=UTF-8&cfv=15&ch=0&col=zh-CN&conOP=0&cpa=1&dai=2&dis=0&ltr=http%3A%2F%2Fwww.5iops.com%2Fhtml%2Fproblem%2F&ltu=http%3A%2F%2Fwww.5iops.com%2Fhtml%2F2014%2Fproblem_0505%2F288.html&lunum=6&n=qudao123_cpr&pcs=1345x659&pis=10000x10000&ps=591x213&psr=1366x768&pss=1345x873&qn=a84d8363819452f8&rad=&rs=61820&rsi0=250&rsi1=250&rsi5=2&rss0=%23FFFFFF&rss1=%23FFFFFF&rss2=%230000FF&rss3=%23444444&rss4=%23008000&rss5=&rss6=%23e10900&rss7=&scale=&skin=&td_id=944267&tn=text_default_250_250&tpr=1419348844803&ts=1&xuanting=0&dtm=BAIDU_DUP2_SETJSONADSLOT&dc=2&di=u944267" align="center,center" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" allowtransparency="true">

今天又遇见有业务CGI被刷的情况，随手整理分享一下，希望对大家有用。

 

空间的base小域名流量一直增长，但业务方面没有发布变更，其他SET也没有类似的趋势，根据以往的经验，怀疑有CGI被额刷了。

 

上机器，使用root用户开始抓包分析。

 

第一招，分析来源IP是否有聚集。

tcpdump -itunl0 -c30000 tcp dst port 80 | grep IP | awk '{print $3}' | awk -F. -v OFS=. '{print $1,$2,$3,$4}' | sort | uniq -c | sort -r | head -20

因为前端接入使用的是TGW，所以请求包抓tunl0就够了。

从第一招的结果来看，基本可以确认是被刷了，而且浙江电信不应该访问这个域名。

 

第二招，分析CGI请求是否有聚集。

一般有GET和POST两种请求，大家可以根据情况选用，也可以修改一下grep的正则表达式两种都抓。

tcpdump -itunl0 -s1500 -A -n -c30000 dst port 80 | grep -Eo "POST .*" | awk -F"?" '{print $1}' | sort | uniq -c | sort –r

tcpdump -itunl0 -s1500 -A -n -c30000 dst port 80 | grep -Eo "GET .*" | awk -F"?" '{print $1}' | sort | uniq -c | sort -r

从第二招的结果来看，也基本可以确认被刷的CGI了。

 

第三招，确认该IP是否真的在刷。

确认的逻辑比较简单，就是分析该IP的所有请求包，是否只针对一个CGI，一个正常用户是不可能在短时间内只访问一个CGI的。

tcpdump -itunl0 -s1500 -A -n -c3000 dst port 80 and host 60.190.219.211 | grep -Eo "POST .*" | awk -F"?" '{print $1}' | sort | uniq -c | sort -r

从第三招的结果可以肯定该IP是恶意在刷这个CGI，联系业务、安全中心的同时帮忙确认后实施打击策略即可。

 

一般恶意刷CGI的背后都是有利益在驱动的，如果以上三招还不够用，咱们还有其他几招，有空再分享出来。