Improvement of TCP Packet Reassembly in Libnids Advisor : Shyh-In Hwang Presenter : Chun-Hui Hwang E-mail: sky97.tw@gmail.com 2009.07.01
Outline Motivation Goals Libnids Introduction System architecture Approaches Implementation Experiment Result Conclusion Future work 大綱: 動機、目的、Libnids介紹、系統架構、研究方法、還有研究實作和實驗成果,最後會做ㄧ下結論跟未來發展
Motivation Network security monitor is important API libraries are convenient Libnids is often used by network monitor systems Libnids drawback : when packet lose, it can’t reassemble following packets It consumes a lot of memory to store packets 網路應用服務的發達,網路資訊的危害也越來越多,因此網路安全的監控和防範變得很重要 API 函式庫可讓網路安全管理人員方便的開發網路監控管理系統 網路監控管理系統就常用到libnids這套API函式庫 缺點,Libnids遇到封包有遺失、漏掉,無法解須後面來的封包,消耗大量的記憶體來儲存封包
Goals To modify libnids - add a packet dispatch mechanism Let libnids can analyze and reassemble packets which already received Memory can be released normally Packet header informations delivered to AP layer 以下是研究目的: 修改Libnids,加入packet dispatch機制 讓libnids可先解析和重組後面已先到的封包 記憶體可正常釋放,不會消耗大量記憶體來儲存封包 以封包型態往上層傳送,利用封包型態來得到更多資訊
Libnids Introduction(1/2) Library Network Intrusion Detection System Emulates the IP stack of Linux 2.0.x Libnids capability: IP defragmentation TCP stream reassembly TCP port scan detection Libnids是Network Intrusion Detect System library的簡寫,也就是網路入侵偵測系統函式庫 仿造Linux2.0版後的IP stack部分所設計出來,而且提供許多網路入侵偵測系統的通用函式 Libnids主要功能在IP分段重組、TCP資料串流重組和TCP通訊埠號的掃描 5
Libnids Introduction(2/2) Libnids applications: Network Protocol Analysis Sniffer Network Intrusion Detection System Other SNMP traffic analyze (May,2007) data reassembly Combine with dsniff (Nov.2006 & 2007) check connection state and session data Network tracing system (April,2009) IP defragmentation, TCP stream reassembly 應用在網路通訊協定的分析,因可分析各種不一樣應用層協定的TCP封包,可分析整個TCP連線過程 網路監控系統所運用,主要是擷取網路上的封包,來檢測封包的內容取得網路資訊 入侵偵測系統的一部份,例如:封包擷取、通訊協定的分析等 SNMP流量分析-資料的重組,結合dsniff-檢驗連線狀態和封包資訊,TCP資料串流重組、IP分段重組功能-網路追蹤系統。
System architecture 在系統架構中能有一台主機可對整個區域網路做監控,在這台主機上具有一監控程式,利用這監控程式呼叫libnids擷取網路封包,並且在進行封包解析重組還原的動作,進而了解整個libnids的運作。
Libnids process Libnids的流程圖,libnids初始化 -> 擷取封包(off/on line) -> 判斷其封包的完整性 -> 封包重組 -> 資料還原 -> 往上層傳送進行資料分析 進行封包重組,先執行IP封包重組的動作,接著才進行TCP封包重組
Approaches 為了改善libnids在進行TCP資料串流重組時所產生的問題 監控程式來呼叫libnids,libnids會開始擷取封包,讀取offline的封包,接著封包將會進行解析重組,加入packet dispatch機制,利用packet type將資訊往上層傳送,完成改善libnids。
Packet dispatch & Packet header informations Packet dispatch mechanism A FIN or RESET packet has been received Packet sequence number falls outside of the current sliding window Users define timeout period for packets Packet header informations An additional option Packet dispatch機制根據以下三個項目來進行判斷: (1)遺失的封包其序號(sequence number)是否已經在正確的sliding window之外 (2)當旗標欄位(flag)附有FIN或是RESET的封包已收到 (3)使用者定義Libnids等待封包的時間 在完成封包的解析與重組的動作後,在利用一個選擇機制讓資訊可利用payload或者是以封包型態往上層傳送
Implementation Use a sniffer program read offline packets Packet proceed to IP defragmentation Packet proceed to TCP stream reassembly Check packet header length、IP address Check packet header flag TCP packet or not Check time stamp Check TCP connection Check data length add packet flag-FIN greater than 0 Packets go into TCP queue 實作的部分,利用Sniffer監控程式讀取以錄製好的offline封包,並且呼叫libnids來重組還原和解析這些封包 先進行IP分段重組的動作,接著在進一步進行TCP資料串流重組 在TCP資料串流重組時,檢查封包標頭長度、IP位址、旗標、是否為TCP封包、封包的時間戳、以及TCP目前連線狀態等 最主要判斷資料長度若大於0,則將封包送進TCP queue的function之中 11
Implementation
Implementation 可發現client端與server端的封包分別各是獨立運作解析重組與還原而互不相影響, 其中一端遇到有封包未被擷取成功或是遺失的情況並不會影響另外一端libnids解析重組封包的動作 但是其中一端遇到封包未被擷取成功或是遺失時,則無法繼續解析重組還原後續已到的封包並且會消耗大量的記憶體來儲存已到的封包
Packet dispatch mechanism A FIN or RESET packet has been received packet dispatch機制的第一個條件就是當libnids收到封包帶有FIN或RESET flag時,我們就將前面已到的封包晚上層傳送
Packet dispatch mechanism Packet sequence number falls outside of the current sliding window ACK 利用sliding window的概念,在libnids解析封包的過程中,我們可知道若當封包已落在正確的sliding window外面,即表示此封包已被接收到 所以當我們知道遺失的封包不會再被傳送過來,則可將後續已先到封包往前解析重組
Packet dispatch mechanism Users define timeout period for packets May be retransmitted after 60s + User defined waiting time 使用者定義libnids等待封包的時間,在等待時間超過使用者所定義的時間後,則可將被記憶體儲存的封包皆往前傳送進行解析重組並且還原資訊傳送至上層。
Packet header informations Use option choice Payload Packet header informations payload source/destination IP source/destination port data length all packets byte data offset 利用選擇機制讓資訊可利用payload或者是以封包型態往上層傳送 封包payload以外的資訊,如:封包的來源端和目的地端的IP位址及通訊埠號、每一個TCP連線的所有封包的總位元數、每個帶有資訊的封包長度和起始位元數
Experiment Analyze 在libnids解析重組封包的過程中,因為packet dispatch機制的運作,在遇到有一個封包遺失時,後續已到的封包可繼續往前解析重組,同時Sniffer主機利用callback函式將封包資訊儲存的log檔中也會告知有遺失的封包以及遺失封包的長度和起始位元。
Experiment Analyze 若當TCP連線中遺失兩個以上的封包時,libnids也可因為packet dispatch機制的運作,順利的將被儲存在記憶體的封包往前進行解析重組。
Experiment Analyze 當TCP連線中若出現連續兩個封包遺失時,在儲存封包資訊的log檔中僅能知道有一段封包遺失
Experiment Analyze Application Layer 在實際的網路中,會有多個TCP連線同時運行,因此,我們讓libnids解析多個TCP連線的.pcap檔案。 在實驗結果中,可知道libnids在解析重組多個TCP連線時,若遇到其中有一個TCP連線遺失封包,其他TCP連線的封包在解析重組的動作中是不會受到影響
Packet with information Experiment Result Packet lost Packet with information Result of analysis Original libnids Improved libnids Success Analysis 1 6 3 50% 100% 2 13 8 62% 20 17 85% 4 21 15 71% 5 60 54 90% 我們依序實驗幾種不同TCP連線的.pcap檔案,主要以封包遺失和封包晚到的情況為主,以下是封包遺失以及封包晚到的實驗結果, 從解析率看到原始的libnids解析率都比改善後的libnids解析率低,在原始的libnids會因為封包遺失造成後面已到的封包被queue起來,所以也會因為遺失封包的早晚造成解析率不同,但是在我們改善後,其他已到的封包都可以正常被解析。
Experiment Result
Experiment Analyze 在被動式網路監控的情形下,擷取封包的過程中可能會發生封包晚到的情況,若超過兩個以上的封包在記憶體等待被解析重組,而且在等待的那個封包也已經在正確的sliding window外,晚到的封包此時才到達,這種情況libnids就無法繼續解析重組。
Packet with information Experiment Result Packet late Packet with information Result of analysis Original libnids Improved libnids Success Analysis 1 14 8 57% 13 93% 2 23 15 68% 22 96% 3 61 54 89% 60 98% 4 25 92% 24 5 86 77 90% 84 接下來為封包晚到的情況,在封包晚到時,原始版本的libnids也會因為等不到晚到的封包而利用記憶體將所有後續已先到的封包儲存起來,造成解析重組封包不完整;利用改善後的libnids版本,其解析率可高達95%左右,由於我們會將晚到的封包丟棄,避免造成應用層的混亂,因此解析率無法到達100%
Experiment Result
Conclusion Libnids packet dispatch mechanism Libnids can reassemble suspended packets Do not consume a lot of memory Packet header informations delivered to AP layer 最後結論部分,我的研究指出 Libnids擁有packet dispatch機制,無須長時間等待封包。 而且讓Libnids可重組還原更多封包促使上層可解析出更多資訊。 同時不須儲存已先到來的封包,造成大量消耗記憶體。 最後Libnids在完成TCP資料串流重組後,將其資訊在以封包型態繼續往上層傳送,利用封包各種資訊達到有效的網路管理。
Thank you