鑒別流量攻擊與防御姿勢構建
參加過實網攻防演習的安全從業者都知道，每年防守方都會購買或者租借眾多安全設備，同時在安全設備的幫助下發現攻擊并阻斷攻擊。
安全設備會抓取客戶全流量進行檢測，以免遺漏攻擊，并著重部署于靶標系統的出入站流量。
而用戶流量是龐大的，這時候，設備的數據清洗能力就尤為重要。強大的規則庫是辨別攻擊的基礎，但仍會不可避免地存在誤報。
本文著重講解如何識別這些流量攻擊，以及如何進行規則上的防御構建，從而減少工作量并縮減誤報。
1 常規攻擊
設備抓取的攻擊一般是什么樣子呢？
一、sql注入。設備一般都會對數據庫操作語句，如insert、select、update、delete、and、xor等關鍵字進行攔截，并且針對攻擊常見編碼，都會進行解碼來識別攻擊。如下圖所示的雙重url編碼，包括base64等，都逃不過設備監控：
二、xss攻擊。同樣基于關鍵字script、img、alert、prompt標簽符號，<>; ‘ “ () \ / 等進行攔截，不過以個人接觸過的設備來說，誤報也很大，具體情況各位戰友可自行體驗：
三、弱口令。這個問題可謂是一大毒瘤，基本無法徹底根除。特別是大公司，資產越多越是讓防守方頭疼。明文傳輸、驗證碼復用等情況也比較多：
四、HTTP請求中有可疑powershell命令：
五、Web命令執行：
六、Thinkphp：
七、橫向端口掃描：
八、挖礦：
九、內網請求惡意域名：
十、Shiro反序列化：
十一、java反序列化：
2 串聯攻擊
發現攻擊后，第一時間需要進行應急處置。為了協助應急溯源人員快速定位問題，需要根據設備捕捉到攻擊者的發起時間、ip地址、攻擊類型等因素做基礎判斷，找到攻擊者的切入點是什么。
這時候串聯攻擊的能力很重要，對設備使用度也很重要。那我們應該如何串聯呢？
我暫時將攻擊鏈劃分為三部分：外對內、內對內、內對外。
首先，找到攻擊者入侵時間點，確認使用ip是否為真實地址，還是掛代理攻擊，以及在該時間段做了哪些攻擊行為。
我們來看一個具體案例。
首先根據告警，檢索事件發生時間段，在早上6點47分發現大量sql注入告警：
查看報文特征,解碼后內容如下：
id=-9575%'UNION ALL SELECT 29,29,29,29,29,29,29,29,29,29#
根據告警強度發現，昨晚異常告警凸起在6.20左右。在排查時，建議將告警低危級別根據告警類型快速過一遍，設備存在誤報可能，需要人為去判別是否存在低危放過的情況。
此時，通過告警得知的入侵目標是“www.xxxx.com.cn”，這時直接去驗證一遍最有效。
驗證后發現站點不存在sql注入，但是不能百分百確認沒問題。此時將告警中的ip、域名相關時間段全部提取出來，搜索IP，發現在之前就已經嘗試其他攻擊，但是頻率不高。所以沒有引起注意：
搜索該域名在該段時間是否遭受過其他類型攻擊、如弱口令嘗試等等。在我們確認后，發現此處攻擊沒有成功入侵，地址也是直接封禁了。
此時肯定有同學疑惑，為什么之前攻擊沒被發現，難道告警沒凸起就發現不了嗎？
解釋一下，不是發現不了，造成這種現象原因有很多，人員疏忽、設備誤報，但是最重要的是，當時設備沒有部署上去，查之前的日志當然沒有了。
而且有趣的是，我們在設備在近兩天的時間內，發現了內網主機發起的探測存活掃描。
此時，我們將重心轉移到了內網的排查，發現了對內網整個C段發起的探測：
并且關聯到了來自內網對外部網絡發起的異常回連，捕捉到了回連域名：
經過對回連地址的解析后，發現反連的域名解析ip竟然是外網發起攻擊的IP。
排查時，這臺服務機屬于邊界服務器，暫時沒有開始大規模投放攻擊，猜測攻擊中應該是怕動靜太大，可能是需要等待一個合適的時機。這里開始了支撐溯源的工作：
在開源情報查詢后找到了最近被標記的域名，直接備案查詢：
竟然是以個人名義注冊的。還發現了另一個域名：
訪問第二個域名得知，其旗下存在公眾號，以及支付寶和微信支付碼、郵箱等信息：
之后通過同賬戶名找到網易云賬戶，得知其為浙江杭州人，90后：
生日為7月3日：
這是又對第二個域名進行了歷史查詢解析，驚喜地發現，在16年首次注冊使用的是qq郵箱：
但是qq是不完整的，此時我天真的以為，只有前兩位不知道，枚舉下來也就99個，不多。
但是結果確實沒搜到，有點煩躁——眼看著已經找到人了。
冷靜后想了想，qq肯定是存在的，也有可能是注銷了，只能碰運氣。隨后開始了加位數的枚舉。加到3位，4位，終于找到了這個大哥的qq，沒白費功夫：
雖然空間進不去，但是得知其本人曾在云南大學就讀：
利用各大廠商找回密碼功能，基本確認手機號為182xxxxx104，枚舉結果就不放了：
最后打包信息提交給了客戶。
此次溯源，成功通過設備發現了異常凸起告警，根據告警特征判斷未攻擊成功。
為了以防萬一，根據相關時間段排查內網告警時，在內網發現了異常的回連告警，回連地址解析后發現了相同的ip，并且找到了其他注冊域名。
通過信息收集，發現了qq、微信、電話、姓名等等相關信息。
這次案例是通過一次完整的告警信息成功的捕捉到了攻擊者，從外部到內部、內部到外部的攻擊動作，抓到了攻擊者。
這里不得不說一下低危放過的告警，案例中沒有直接發現回連可能是因為規則沒有更新，或者特征被擦除掉了，因為告警信息并不明顯，所以排查時間被拉長。
3 規則構建
說完了案例，那我們該如何幫助用戶去完善那些不完整的地方呢？
此處將防御重點放置于基于流量規則的精細化，基于攻擊來源、協議、特征、時間、頻率、中間件、端口、服務等等，此處總結了一點規則構建的方法論，可能不夠全面，歡迎補充：
相信同學們認真看完腦圖后，對規則的構建起碼有了一個輪廓。此處同樣舉例一個基于360自身設備構建的相關場景規則。
有同學可能會問，為什么構建這條規則，規則有什么作用。
解釋一下，下面的案例目的是提升告警命中率，在低危告警中找到真實的攻擊。最好出來告警，就可以確認在外部系統中，這個功能點是不是真的有漏洞，并且還是企業內部日常管理應用中不注重的點，是真切需要企業去排查的問題。如果規則準確率達到90%，那這就是一條不可忽視的規則。
首先我們要評估場景。
場景名稱：多臺外部主機對同一個網站發起攻擊；
條件：1.外網主機；2.多個攻擊源；3.同一目標；4.數據源日志。
接下來制定規則。
1.判斷內外網條件：
內網：源地址belong內網IP
外網：not源地址belong 內網ip
2.添加多個攻擊源，如：源地址>3；
3.指定目的地址：目的地址=1；
4.找到數據源數據：數據源="xxx"；告警級別="低危"。
再查驗字段：
找到我們規則中所需要字段，如網段信息、數據源、告警級別等等：
數據源="360_AISA" and 原始級別="low" and 狀態="1"：
然后布置規則。
再確認所需字段后，布置測試上線：
最后進行實用測試：
在規則上，我們總要不斷調優，擦除特征這種方式是最直接有效的。
發現一類攻擊在user-agent中帶有公司標識，是某類業務發起的正常操作，直接將ua頭通過匹配方式not掉。
設備也是提供了通過跑一些歷史數據或者實時數據測試誤報率，經過幾輪調優來提升規則準確率，還是比較友好。
這里提示一下，各位同學在查找攻擊來源時，要注意XFF是否存在。
4 總結
此處演示僅提供思路，方便各位同學可以在海量數據調優的過程中，更快更精準地找到攻擊并通過自己的攻擊串聯思路找到攻擊者，謹以此文，獻給曾經熬夜堅守在安全設備前的安服戰友們。
參加過實網攻防演習的安全從業者都知道，每年防守方都會購買或者租借眾多安全設備，同時在安全設備的幫助下發現攻擊并阻斷攻擊。
安全設備會抓取客戶全流量進行檢測，以免遺漏攻擊，并著重部署于靶標系統的出入站流量。
而用戶流量是龐大的，這時候，設備的數據清洗能力就尤為重要。強大的規則庫是辨別攻擊的基礎，但仍會不可避免地存在誤報。
本文著重講解如何識別這些流量攻擊，以及如何進行規則上的防御構建，從而減少工作量并縮減誤報。
1 常規攻擊
設備抓取的攻擊一般是什么樣子呢？
一、sql注入。設備一般都會對數據庫操作語句，如insert、select、update、delete、and、xor等關鍵字進行攔截，并且針對攻擊常見編碼，都會進行解碼來識別攻擊。如下圖所示的雙重url編碼，包括base64等，都逃不過設備監控：
二、xss攻擊。同樣基于關鍵字script、img、alert、prompt標簽符號，<>; ‘ “ () \ / 等進行攔截，不過以個人接觸過的設備來說，誤報也很大，具體情況各位戰友可自行體驗：
三、弱口令。這個問題可謂是一大毒瘤，基本無法徹底根除。特別是大公司，資產越多越是讓防守方頭疼。明文傳輸、驗證碼復用等情況也比較多：
四、HTTP請求中有可疑powershell命令：
五、Web命令執行：
六、Thinkphp：
七、橫向端口掃描：
八、挖礦：
九、內網請求惡意域名：
十、Shiro反序列化：
十一、java反序列化：
2 串聯攻擊
發現攻擊后，第一時間需要進行應急處置。為了協助應急溯源人員快速定位問題，需要根據設備捕捉到攻擊者的發起時間、ip地址、攻擊類型等因素做基礎判斷，找到攻擊者的切入點是什么。
這時候串聯攻擊的能力很重要，對設備使用度也很重要。那我們應該如何串聯呢？
我暫時將攻擊鏈劃分為三部分：外對內、內對內、內對外。
首先，找到攻擊者入侵時間點，確認使用ip是否為真實地址，還是掛代理攻擊，以及在該時間段做了哪些攻擊行為。
我們來看一個具體案例。
首先根據告警，檢索事件發生時間段，在早上6點47分發現大量sql注入告警：
查看報文特征,解碼后內容如下：
id=-9575%'UNION ALL SELECT 29,29,29,29,29,29,29,29,29,29#
根據告警強度發現，昨晚異常告警凸起在6.20左右。在排查時，建議將告警低危級別根據告警類型快速過一遍，設備存在誤報可能，需要人為去判別是否存在低危放過的情況。
此時，通過告警得知的入侵目標是“www.xxxx.com.cn”，這時直接去驗證一遍最有效。
驗證后發現站點不存在sql注入，但是不能百分百確認沒問題。此時將告警中的ip、域名相關時間段全部提取出來，搜索IP，發現在之前就已經嘗試其他攻擊，但是頻率不高。所以沒有引起注意：
搜索該域名在該段時間是否遭受過其他類型攻擊、如弱口令嘗試等等。在我們確認后，發現此處攻擊沒有成功入侵，地址也是直接封禁了。
此時肯定有同學疑惑，為什么之前攻擊沒被發現，難道告警沒凸起就發現不了嗎？
解釋一下，不是發現不了，造成這種現象原因有很多，人員疏忽、設備誤報，但是最重要的是，當時設備沒有部署上去，查之前的日志當然沒有了。
而且有趣的是，我們在設備在近兩天的時間內，發現了內網主機發起的探測存活掃描。
此時，我們將重心轉移到了內網的排查，發現了對內網整個C段發起的探測：
并且關聯到了來自內網對外部網絡發起的異常回連，捕捉到了回連域名：
經過對回連地址的解析后，發現反連的域名解析ip竟然是外網發起攻擊的IP。
排查時，這臺服務機屬于邊界服務器，暫時沒有開始大規模投放攻擊，猜測攻擊中應該是怕動靜太大，可能是需要等待一個合適的時機。這里開始了支撐溯源的工作：
在開源情報查詢后找到了最近被標記的域名，直接備案查詢：
竟然是以個人名義注冊的。還發現了另一個域名：
訪問第二個域名得知，其旗下存在公眾號，以及支付寶和微信支付碼、郵箱等信息：
之后通過同賬戶名找到網易云賬戶，得知其為浙江杭州人，90后：
生日為7月3日：
這是又對第二個域名進行了歷史查詢解析，驚喜地發現，在16年首次注冊使用的是qq郵箱：
但是qq是不完整的，此時我天真的以為，只有前兩位不知道，枚舉下來也就99個，不多。
但是結果確實沒搜到，有點煩躁——眼看著已經找到人了。
冷靜后想了想，qq肯定是存在的，也有可能是注銷了，只能碰運氣。隨后開始了加位數的枚舉。加到3位，4位，終于找到了這個大哥的qq，沒白費功夫：
雖然空間進不去，但是得知其本人曾在云南大學就讀：
利用各大廠商找回密碼功能，基本確認手機號為182xxxxx104，枚舉結果就不放了：
最后打包信息提交給了客戶。
此次溯源，成功通過設備發現了異常凸起告警，根據告警特征判斷未攻擊成功。
為了以防萬一，根據相關時間段排查內網告警時，在內網發現了異常的回連告警，回連地址解析后發現了相同的ip，并且找到了其他注冊域名。
通過信息收集，發現了qq、微信、電話、姓名等等相關信息。
這次案例是通過一次完整的告警信息成功的捕捉到了攻擊者，從外部到內部、內部到外部的攻擊動作，抓到了攻擊者。
這里不得不說一下低危放過的告警，案例中沒有直接發現回連可能是因為規則沒有更新，或者特征被擦除掉了，因為告警信息并不明顯，所以排查時間被拉長。
3 規則構建
說完了案例，那我們該如何幫助用戶去完善那些不完整的地方呢？
此處將防御重點放置于基于流量規則的精細化，基于攻擊來源、協議、特征、時間、頻率、中間件、端口、服務等等，此處總結了一點規則構建的方法論，可能不夠全面，歡迎補充：
相信同學們認真看完腦圖后，對規則的構建起碼有了一個輪廓。此處同樣舉例一個基于360自身設備構建的相關場景規則。
有同學可能會問，為什么構建這條規則，規則有什么作用。
解釋一下，下面的案例目的是提升告警命中率，在低危告警中找到真實的攻擊。最好出來告警，就可以確認在外部系統中，這個功能點是不是真的有漏洞，并且還是企業內部日常管理應用中不注重的點，是真切需要企業去排查的問題。如果規則準確率達到90%，那這就是一條不可忽視的規則。
首先我們要評估場景。
場景名稱：多臺外部主機對同一個網站發起攻擊；
條件：1.外網主機；2.多個攻擊源；3.同一目標；4.數據源日志。
接下來制定規則。
1.判斷內外網條件：
內網：源地址belong內網IP
外網：not源地址belong 內網ip
2.添加多個攻擊源，如：源地址>3；
3.指定目的地址：目的地址=1；
4.找到數據源數據：數據源="xxx"；告警級別="低危"。
再查驗字段：
找到我們規則中所需要字段，如網段信息、數據源、告警級別等等：
數據源="360_AISA" and 原始級別="low" and 狀態="1"：
然后布置規則。
再確認所需字段后，布置測試上線：
最后進行實用測試：
在規則上，我們總要不斷調優，擦除特征這種方式是最直接有效的。
發現一類攻擊在user-agent中帶有公司標識，是某類業務發起的正常操作，直接將ua頭通過匹配方式not掉。
設備也是提供了通過跑一些歷史數據或者實時數據測試誤報率，經過幾輪調優來提升規則準確率，還是比較友好。
這里提示一下，各位同學在查找攻擊來源時，要注意XFF是否存在。
4 總結
此處演示僅提供思路，方便各位同學可以在海量數據調優的過程中，更快更精準地找到攻擊并通過自己的攻擊串聯思路找到攻擊者，謹以此文，獻給曾經熬夜堅守在安全設備前的安服戰友們。
