入侵取證 [ web日誌分析初步 ]
0x01 前言
既然是取證, 不妨就從一個稍微全域性點的角度來理解,最先應該搞清楚的, 可能就是, 到底哪些地方會留下入侵者的痕跡 , 這次單單就以最基礎的web服務 [ 暫不涉及指令碼引擎,資料庫及系統方面的東西 ] 基本取證流程為例, 其實很簡單,入侵者一般喜歡從哪裡下手,就必然會在那裡留下痕跡, 可能在此之前我們還需要搞清楚客戶端的http資料到底都是從什麼地方過來的, 有GET 的 URL 中傳來的資料 , POST 中傳來的資料,從http頭中獲取的各類客戶端資料 [ 如,cookie,user-agent,Referer,X-Forwarded-For ], 像這些很基礎的東西,早該在最開始部署服務的時候就想到,不然,等到真出事的那一天,自己真正能掌握的資料就著實比較少了
0x02 環境簡介
暫以 nginx 為例,一個最基本的日誌格式大概是下面這個樣子,當然,這種格式可能會造成你的日誌檔案特別大 [ 存的東西多嘛 ], 但實際部署時還是需要你根據自己的實際的業務來,這裡也僅僅只是做個參考
先在指定的 server 標籤中定義好cookie變數
server{
...
set $dm_cookie "";
if ($http_cookie ~* "(.+)(?:;|$)") {
set $dm_cookie $1;
}
...
}
這時再回到 nginx 主配置檔案中, 引用剛剛設定的cookie變數, 這樣, 頭裡面的那幾個欄位資料就都可以被記錄了
http {
...
log_format main '$remote_addr - $remote_user [$time_local] '
' "$request" $request_body $status $body_bytes_sent '
' "$http_referer" "$http_user_agent" "$http_x_forwarded_for" "$dm_cookie" ';
...
}
按照從左到右的順序,每個欄位的的作用分別是
-->遠端ip是多少
-->客戶端是誰,什麼時間訪問的
-->請求了伺服器的哪個檔案,如果是post請求post的引數值是什麼
-->伺服器響應的狀態碼又是多少
-->返回給客戶端的頁面資料實際大小是多少
-->當前請求是從哪個頁面過來的
-->客戶端機器資訊是啥
-->抓取客戶端真實ip
-->抓取cookie中的引數值
以上配置完成後, 重啟nginx, 然後嘗試針對性的訪問, 看看我們剛設定的那幾個點的資料能不能被正常記錄
# /usr/local/nginx/sbin/nginx -t
# /usr/local/nginx/sbin/nginx -s reload
0x03 web分析取證第一步,從最敏感的 異常狀態碼 開始
404 其實,正常使用者在網站頁面上點選訪問,碰到404的概率並不多,如果你發現短時間出現大批量的404,很有可能都是由於入侵者在嘗試掃描各種敏感目錄檔案所致
像這種過於敏感的操作,現如今的waf一般都會進行攔截,短時間某個ip訪問量劇增,再典型不過的攻擊特徵....
403 通常目標都會把一些不想讓使用者訪問到的敏感路徑,比如,網站後臺,各類資料庫的web入口,其他中介軟體的web入口,等等...
401 出現這個狀態碼,很有可能是使用者正在嘗試登入有http基礎認證的頁面時,賬號密碼錯誤的響應狀態
500 典型的伺服器端錯誤,通常是由於後端指令碼或者資料庫報錯所致,比如,入侵者在嘗試一些web漏洞時就很有可能會觸發這樣的錯誤,sql注入,程式碼執行...
503 ....
快速提取各種敏感狀態碼,當然啦,這裡只是給大家簡單做個參考,實際中如果日誌特別大,就儘量不要同時 tee了,可能會把系統卡死
# grep "[[:space:]]500[[:space:]]" /usr/local/nginx/logs/access_bwapp.log | tee -a nginx_500_log.txt
# grep "[[:space:]]404[[:space:]]" /usr/local/nginx/logs/access_bwapp.log
0x04 匹配各種常見 web攻擊特徵
匹配特徵的根本目的,其實就是想知道, 入侵者到底是不是通過web進來的,如果是,是通過什麼樣的漏洞進來的 ,這裡所有的演示純粹只是為了簡單說明問題,告訴大家實際做事的基本思路,等你自己真正用的時候,正則肯定會比我下面的這些要複雜的多的多,說實話,這裡也沒用啥正則…
捕捉各類典型的敏感目錄檔案掃描特徵,敏感檔案主要是針對各類 web入口, svn, 網站備份檔案, 資料庫備份檔案, 敏感配置檔案, 各類探針檔案, 以及其它的各類敏感密碼檔案洩露 , 很多入侵者其實根本就不需要什麼漏洞, 直接從這裡面獲取目標的真實賬號密碼,後面的事情很有可能就直接行雲流水了…
# grep "[[:space:]]404[[:space:]]" /usr/local/nginx/logs/access_bwapp.log | awk '{cnt[$1]++;}END{for(i in cnt){printf("%st%sn", cnt[i], i);}}' | sort -n
快速捕捉各類典型web漏掃工具特徵,當然,這些特徵也都是很容被擦除的,不過好在一般人都不會這麼幹, 比如,最常用的幾款漏掃
awvs,appscan,netsparker,burpsuite,webcuriser,vega,owasp zap,nikto,w3af,nessus,openvas…
# egrep -i --color=auto "AppScan|acunetix|Netsparker|WebCruiser|owasp|ZAP|vega|Nikto|nikto|w3af" /usr/local/nginx/logs/access_bwapp.log
快速捕捉各類典型sql注入特徵, 如
union,select,and,insert,information_schema,or,xor,like,order by,null,sleep…
# egrep -i --color=auto "union(.*)select|select(.*)from" /usr/local/nginx/logs/access_bwapp.log
快速捕捉各類典型的程式碼或者命令執行特徵 eval,assert,system,passthru…
# egrep -i --color=auto "system(.*)|eval(.*)" /usr/local/nginx/logs/access_bwapp.log
抓取 後臺異常的登入行為 ,可直接提取管理頁面的200響應所對應的ip [ 這裡可不僅限於常規網站後臺,其它的各類資料庫web管理入口等都可以這樣幹..] , 先大致定位其ip,確定是不是我們自己的ip,如果不是,可能就要留心了…尷尬,貌似又掉圖了,尼瑪
# egrep -i --color=auto "portal.php" /usr/local/nginx/logs/access_bwapp.log | grep "[[:space:]]200[[:space:]]" | awk -F " " {'print $1'} | sort | uniq -c
從請求記錄中捕捉各類典型的 webshell檔案命名特徵 , 比如, 最常見的 spy列,b374k,r57,c99,c100,Kacak,Zehir4,Webadmin,Webadmin,Spybypass,loveshell,hacker,hacked,shell,g.*,maer… tennc有個專門蒐集webshell的倉庫, 可以去那裡, 把所有的 webshell 特徵都提取一遍, 放到自己的正則中
# egrep -i --color=auto "r57|c99|c100|b374k|aspxspy|phpspy|aspxspy|wso" /
從請求記錄中捕捉各類敏感的 程式碼命令執行,檔案操作類引數特徵 ,比如, php?cmd= , php?filemanager= , php?upload=……..webshell中的引數一般也都會這麼傳
# egrep -i --color=auto "php?cmd=|php?code=|php?exec=" /usr/local/nginx/logs/access_bwapp.log
從get或者post中提取各類典型的 包含,檔案讀取,任意檔案下載,email,xpath,ldap注入…等漏洞引數特徵 ,一般這樣的url中通常都會帶有路徑分隔符,如,./ ../../ …..
# egrep -i --color=auto "php?file=|php?page=|php?include=|./|php?../" /usr/local/nginx/logs/access_bwapp.log
從get或者post中提取典型的 xss漏洞引數特徵 ,既然是xss,直接想辦法過濾 js程式碼 就好了
# egrep -i --color=auto "<script>(.*)</script>|alert(.*)" /usr/local/nginx/logs/access_bwapp.log
快速鎖定 請求相對比較頻繁的那些ip , 找到ip對應的記錄看看它們都到底在幹啥, 然後再針對性的提取分析
# awk '{print $1}' /usr/local/nginx/logs/access_bwapp.log | sort -n |uniq -c | sort -rn | head -n 100
蒐集各類典型的 webshell管理工具 發起的各類敏感 http資料特徵,具體針對性的正則,可能需要你自己,抓包好好看下里面的各種請求引數,如,菜刀,Altman,weevely…比較簡單,就懶得抓了,大家如果有興趣,可以自行嘗試,實在有問題,也可以直接找我交流
利用系統現有工具,手工先簡單查殺下網站目錄下的各種 webshell特徵 , egrep,find,sed,awk,sort,findstr…一句話快速定位網站目錄中的簡易webshell,當然,這個能達到的效果非常有限,不過,如果你想快速的找到一些比較爛的webshell還是可以的
# find /usr/local/nginx/html/ -type f | xargs egrep "eval|system"
針對各類開源程式或者框架0day,可以想辦法直接捕捉相應的 exp引數特徵 ,具體的exp得具體對待了,大家可以把曾經曝過的所有0day,花點兒時間好好蒐集一下,然後再針對性的提取一下exp核心引數特徵, 然後再整合到自己的正則裡就好了, 比如,wp,joomla,drupal,phpbb,discuz,strus2,tp…..這裡就不再演示了,如果你直接用的就是開源程式 [ 肯定不是用的很爛的那種,假如是wp,drupal這種級別的 ], 這一條往往就直接能幫你鎖定入侵者,因為像這種程式一般都是直接拿曾經的一些0day打的,當然啦,除了其它的各種洩露之外,如果你都拿到了後臺管理員的賬號密碼了,還需要什麼exp呢
最後,再上各種專業 webshell 查殺工具仔細掃描網站目錄,比如,各種魚,各種狗,以及各種雲 dog….
0x05 在實際分析web日誌過程中的經常會出現的一些窘境
也許你看我這個貌似挺簡單的,但實際生產環境下就並非如此了,你要考慮到的東西也許會比較的多
不過萬變不離其宗,基本思路有了,剩下的只是實踐,針對性改進,和經驗的問題
經驗老道的入侵者,可能對日誌處理的也比較到位,很難捕捉到什麼有用的東西
比如,最典型的,替換偽造,以此混淆試聽,直接把某個時間段內的日誌整個幹掉,甚至,直接干擾破壞系統正常的日誌記錄服務,這無疑也會給取證帶來不小的困難
入侵者一般都會掛vpn或者利用tor來頻繁切換ip節點,很難溯源到入侵者的真實ip,大部分要依靠拿到的現有的一些入侵者資訊再配合社工一起利用
基於各類形式編碼後的請求很容易被現有的正則遺漏掉
各類免殺webshell,單純的依靠靜態查殺特徵很難被捕捉到
比如,各種利用包含,回撥,編碼,陣列迴圈進行字元拼接...所構造的webshell,waf就很難捕捉到
對於那種直接插到正常程式碼中或者直接駐留在記憶體中的webshell,查殺可能就更困難了
雖然有的殺軟可以幫我們幹這事兒[比如,nod32],但那個畢竟也很有限
單個日誌檔案太大,普通的文字編輯器編輯起來可能有點兒費勁,不過這個也不算什麼問題,畢竟10G下的vi雖然有些吃力,但湊活用……
關於實時網站目錄入侵監控方案,現在也有一些,不過,跟自己的想法多多少少還是有些出入
這裡所說的實時網站入侵監控,依然會從http這一層走,目前自己也還正在不斷積累學習中,待後期沉澱成乾貨後,再仔細分享給大家....
可能有人會問,這種東西為什麼不寫指令碼呢,嘿嘿……指令碼是很方便,但並不是什麼都可以用指令碼幹,畢竟有目的的取證並非流水線,很多時候還是需要人為分析
我們的最終目的可能還是像更精準的溯源到入侵者,並非為了寫工具而寫工具
當然,如果這種東西能再配合著大資料一起無疑是非常好的,不過,這可能需要一個很成熟的平臺,需要有一定的資料積攢才行
今天就只提了最簡單的web服務,關於其它服務和系統層取證,後續還會有一個完整的系列來說...待續ing,嘿嘿...