--- title: 研究問題(舊2) tags: 倉庫 --- > From: https://bit.ly/385RcQ1 ### A.數據平面應用程序。用於TDOS防禦 SDN為通過可編程控制和數據層面進行聯網提供了新的示範。此級別的可編程性提供了SIP安全研究人員以前無法使用的一組新功能。考慮到電話是對時間敏感的應用程序,因此在處理實時數據包時有必要使延遲最小化。考慮到這一要求,我們建議直接在數據層面中實現TDoS檢測和緩解功能。當數據層面是可編程的時,現在可以在SIP協議層對每個單個數據包執行深度數據包檢查。此功能對於驗證特定SIP會話是否偏離正常SIP狀態機協議是必需的。在本質上,我們建議在數據平面中實現傳統網絡設備的功能,並使其在每個交換機端口上都可用。以前的建議與本文之間的對比說明如下:圖1。 > ![](https://i.imgur.com/MbKEOds.gif) 圖1中的每個矩形分別描繪了通常實施TDoS檢測和緩解的位置,即作為與SIP代理服務器安裝在同一主機上的應用程序,作為SIP代理服務器的擴展模塊以及作為專用網絡設備。相反,該提議在數據層面上實現了TDoS防禦,如圖1所示(底部矩形)。通過這種方法,可以在P4交換機的每個端口上使用SIP TDoS防禦。 ### B. SIP狀態機檢測算法 SIP協議使用狀態機來創建和終止SIP會話。一個有效且適當的SIP會話將包含一對INVITE-and-BYE數據包,而對於電話DoS攻擊,它將具有大量的INVITE數據包。根據RFC 3665或Best Current Practice 75 ,成功的會話建立如圖2所示,其中呼叫者通過發送INVITE數據包啟動會話,而被呼叫者通過發送BYE數據包結束會話。 > ![](https://i.imgur.com/6E3Q3EK.gif) 如圖3中的偽代碼所示,攻擊檢測算法指出,對於每個交換機端口,它都不能超過為該端口預先設置的活動會話限制。當端口已收到INVITE數據包且尚未從同一端口發送BYE數據包時,則認為SIP會話處於活動狀態。換句話說,該算法可以對未完成的INVITE數據包施加限制。當達到此限制時,後續的INVITE數據包將被自動丟棄,並且無法創建SIP會話。 > ![](https://i.imgur.com/7bgykqH.gif) 在TDoS攻擊期間,攻擊者將繼續發送INVITE數據包,而無需遵循協議規範RFC 3261 [13]中指定的交互。這樣,將會有很多INVITE數據包,這種情況被解釋為正在進行的INVITE泛洪攻擊。在這種情況下,這些INVITE數據包會在數據平面自動丟棄。 跟踪SIP狀態機非常有效,因為即使對源IP地址進行了欺騙和隨機分配,它仍然可以工作。與基於簽名/規則的檢測方法相比,當源IP地址是隨機的時,很難建立有效的檢測規則。使用基於異常的方法,低速和慢速攻擊不會觸發警報,因為它沒有表現出不同的流量模式(例如,流量突然爆發),因此對於基於異常的算法而言,它顯示為正常流量。與基於異常的方法相比,無論創建這些惡意SIP會話的速度有多慢,狀態機檢測方法仍然有效。 ### C.每個端口的自定義邀請限制 在交換機上,每個端口都有自己的INVITE限制,具體取決於將哪個設備連接到該端口以及該設備所帶來的潛在威脅(表I)。例如,對於不具有SIP通信的IoT設備,可以將限制設置為零。這對於防止被殭屍網絡感染和招募來使用SIP作為命令和控制(C2)通道的IoT設備很有用[11]。如果端口被授權進行SIP會話,則可以根據要求將此端口的限制設置為一個或兩個。如果此端口連接到上游SIP提供程序,則其未清INVITE限制可以具有更大的值。 > ![](https://i.imgur.com/KHvQzfJ.gif) 當端口1收到INVITE數據包時,端口1上的INVITE寄存器的值將增加1,如圖4步驟(1)所示。端口1接收到的後續INVITE數據包將被自動丟棄,因為端口1(連接到IP電話)的未完成INVITE限制已預設為1(表I)。非SIP數據包被正常處理,即被路由到目的地。當BYE數據包即將從端口1發送出去時,端口1上BYE寄存器的值將增加1,如圖4步驟(2)所示。此時,兩個寄存器(INVITE和BYE)的值均為1,表示已完成SIP會話。這些寄存器被重置為0,如圖4所示 在完整會話結束時執行步驟(3)。