入門級應急響應小貼士

本篇主要說明一下遇到拒絕服務攻擊、DNS劫持、IOC告警以及APT事件的常規處理方式。

拒絕服務攻擊

拒絕服務攻擊分為兩種，DDOS攻擊和DOS攻擊。

DDOS攻擊也稱為分布式拒絕服務攻擊，英文全稱Distributed denial of service attack，與DOS攻擊存在較大區別。

DOS攻擊可以理解為使用單臺主機利用目標系統應用層或系統層的漏洞，使其無法正常提供服務，而DDOS攻擊一般都是通過駭客控制的大量的肉雞，結合反射放大等攻擊對目標進行大量流量攻擊，使其無法提供服務。

先討論DDOS攻擊，這類攻擊通常在防火牆等網路設備能看到目標短時間內遭受了大量的流量攻擊，最明顯的表現為網站外網無法正常拜訪或拜訪速度非常卡頓，而內網則正常拜訪沒有問題，此時基本可以斷定為目標遭受DDOS攻擊。

這類攻擊沒有特別好的處理方式，僅給出網上常用的處理建議：

1、特征丟棄，根據數據包的特征或拜訪行為進行丟棄，如基於Payload特征、發包行為特征等。

2、限速，對流量／拜訪的速率進行限流。

3、限源，即對源IP或協議進行限制。

還是建議部署安全設備或上雲來防止遭受DDOS攻擊。

DOS攻擊一般都是由於系統或應用漏洞導致，最應用層最常見的有apache的slowloris Attack，也是awvs最容易掃出來的問題，msf中自帶有相幹的掃描腳本。

除此之外，部分DOS攻擊利用系統漏洞使服務器無法正常運行，如經典的MS12020，可以使任意開放了RDP服務並且沒有打對應補丁主機藍屏重啟，從而導致無法正常提供服務。

遭遇此類攻擊時，我們應當對系統開放的服務一一進行排查，如果有相幹的網路設備可以對受影響主機進行流量監控，確認遭受攻擊的端口與服務，再進行後續分析。

DNS劫持

DNS劫持，是指通過攻擊域名解析服務器（DNS）或偽造域名解析服務器（DNS）的方法，把目標網站域名解析到錯誤的IP地址從而實現用戶無法拜訪目標網站的目的或者蓄意或惡意要求用戶拜訪指定IP地址（網站）的目的。

通常來說存在三種情況：

路由器被入侵

DNS服務被入侵

運營商流量劫持

鑒於運營商方面有時溝通無果，本文隻討論前兩種情況。

DNS劫持應該優先排查好主機方面的問題，如DNS配置有無問題，本地hosts文件是否被篡改過，瀏覽器設置是否被改動，前兩種情況可以直接查看，瀏覽器設置問題可以使用360、火絨等殺軟直接進行掃描並修復。

路由器被入侵導致的DNS劫持應該是最常見的場景，由於某些路由器可能映射管理端口到外網，並且有可能存在弱口令和RCE的問題，所以遇到DNS劫持的情況，應當首先更換路由器設備（當前，肯定要換不同的款式），然後查看情況是否解決，如果解決問題，那麼針對原路由的口令以及後門RCE漏洞等進行分析，出具相幹報告。

如果仍未解決問題，那麼考慮DNS服務器是否遭受入侵。

登錄DNS服務器，查看DNS配置是否存在問題，若發現被惡意更改，則確認該事件是由於DNS服務器遭受入侵導致，需要使用殺軟進行病毒查殺掃描，可以參考上篇文章中的主機處理流程。

IOC告警

IOC告警事件大多是由內部安全設備發現，通常都是由於內網主機非法請求了高危的威脅情報地址。

這類事件首先應該對IOC告警進行確認，在微步上查詢對應IoC，如www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

看到以上結果，基本確認內網是存在WannaCry蠕蟲病毒，有NTA的情況下基本能快速定位所有感染主機，處理方案參考上篇文章的勒索病毒處理流程。

如為其他告警但是確認為惡意安全事件的，也可以通過搜尋引擎查詢對應的分析文章，根據病毒行為作出對應的修復和後續的防護措施。

特殊情況下，如果IoC告警大概率確認為惡意，但是也無法找到相幹文章，需要人工進行分析。

windows下通過netstat -ano命令來查看請求對應的IoC的PID，然後使用tasklist /svc|findstr 「PID」來定位到對應進程。

linux下操作思路與以上類似，不多贅述。另外如進程請求變化太快不好定位，推薦個大佬寫的小工具可以試試。

APT事件

此類事件本人接觸的並不多，實際遭遇目前差不多就兩三次的樣子。首先明確一下什麼樣的事件可以被歸類為APT事件，借鏡一下百度百科的說明，APT攻擊的主要特征有針對性強、組織嚴密、持續時間長、高隱蔽性和間接攻擊。詳細可以參考百度百科。

簡單講述一下本人遭遇過的一個事件為例，接到應急通知，某軍工相幹單位，更新了軟體後安全設備一直告警。

到現場查看，殺軟當前更新到最新版本，掃描到的木馬日期在兩年之前，此前一直沒有發現（環境為內網環境，無法連接外網，近期才更新了殺軟病毒庫）（持續性），說明木馬具有一定的免殺性（隱蔽性），考慮到目標系統在內網（間接攻擊）並且為敏感單位（針對性），基本確認為APT事件。

由於時間太久遠，網站沒有日志記錄，通過溝通確認網站使用了某知名OA系統，查看webshell時間與當年該OA系統爆出RCE漏洞時間基本吻合，大致確認是由於該漏洞導致的入侵，由此得出結論，鑒於事件性質，後續工作移交了對應部門進行處理。

總得來說，如果真懷疑遇到了APT，還是建議找專業公司來進行解決。

總結

文章總結了應急過程中常見的情景，以及對應的處理方式，更偏向於剛接觸應急的朋友進行參考，文中若有不對還請指正，希望本文能有所幫助。

*本文作者：3unshine，轉載請註明來自FreeBuf.COM