利用圖形處理器與階層式平行技術加速網路入侵偵測系統

全文

(1)國立臺灣師範大學電機工程學系碩士論文指導教授：林政宏博士利用圖形處理器與階層式平行技術加速網路入侵偵測系統 A Novel Hierarchical Parallelism for Accelerating NIDS Using GPUs. 研究生：謝政宏. 中. 華民. 國一. ○. 撰. 七年. 七月.

(2) 利用圖形處理器與階層式平行技術加速網路入侵偵測系統. 學生：謝政宏. 指導教授：林政宏博士. 國立臺灣師範大學電機工程學系碩士班. 摘要目前網路入侵偵測系統大多採用多重樣式字串比對的方式，是否含有網路攻擊與異常的封包，透過比對數以千計的攻擊特徵來偵測封包內容。隨著大數據時代的來臨，網路速度與攻擊活動的增加，多重樣式字串比對面臨效能與吞吐量的不足，導致許多封包沒有處理且遺失。為了改善網路入侵偵測系統的效能與吞吐量，本論文提出階層式平行架構，利用多張圖形處理器(Multi-GPU)與三種不同層面的平行技術加速網路入侵偵測系統。階層式平行架構由三層不同的平行技術所組成，從上至下來看，第一層實現資料平行(Data Parallelism)於多張圖形處理器；第二層將管線化排程(Pipeline Schedule)實現於個別圖形處理器中，屬於任務平行(Task Parallelism)；第三層則是採用資料平行的技術，優化 Aho-Corasick 演算法。本論文實驗結果顯示，採用四張圖形處理器 Nvidia Titan X 實現於階層式平行架構，總系統吞吐量可高達 70 Gbps，與傳統使用於 Snort 中的 Aho-Corasick 演算法相比，可高達四十倍的改善倍率。當圖形處理器的數量增加，總系統的吞吐量也會隨之增加。除此之 ii.

(3) 外，本論文採用完美雜湊(Perfect Hashing)的方法，壓縮傳統 Aho-Corasick 的狀態機，減少在 Snort 中 99.2%多重樣式字串比對的記憶體使用量，最後本論文將提出的階層式平行架構實現於開源網路入侵偵測系統 Snort。關鍵字：網路入侵偵測系統、圖形處理器、多重樣式字串比對、Aho-Corasick 演算法. iii.

(4) A Hovel Hierarchical Parallelism for Accelerating NIDS Using GPUs. Student：Cheng-Hung Hsieh. Advisors：Dr. Cheng-Hung Lin. Department of Electrical Engineering National Taiwan Normal University ABSTRACT. Multi-string matching has been widely used in NIDS to detect network attacks and malicious network packets by matching packet contents with thousands of attack patterns. Due to the rapid increase of growing network attacks and network speeds, multistring matching faces the challenges for limited performance and insufficient throughput . In order to improve the performance and throughput of multi-string matching, this thesis presents a novel hierarchical parallelism that can accelerate multi-string matching on multiple GPUs. The hierarchical parallelism consists of three layers of parallelism. From top to bottom, the first layer is the data parallelism on multiple GPUs; The second layer is the task parallelism on a single GPU; The last layer is the data parallelism of the Aho-Corasick algorithm. Experimental results show that the hierarchical parallelism on a machine featured with four Nvidia Titan X GPUs can achieve 70 Gbps of throughput which is 40 times faster than the Aho-Corasick algorithm used in Snort. As the number of GPUs increase, the throughput of the hierarchical parallelism will also increase. In iv.

(5) addition, the proposed approach adopts the perfect hashing to construct state machines that can achieve memory reduction on Snort up to 99.2%. Finally, the proposed hierarchical parallelism is implemented in the open source network intrusion detection system using Snort.. Keywords: Network intrusion detection systems, graphics processing units, multiple string matching, Aho-Corasick algorithm.. v.

(6) 謝. 誌. 本論文得以完成，首先要感謝我的指導教授林政宏老師。故事發展從大二下開始，因緣際會下進入了林政宏老師的實驗室，高效能平行計算實驗室。起初，完全不知道進來這個實驗室的目的，唯一知道的是老師的名字與我的名字相同，或許這就是一種緣份吧，而我因此莽莽撞撞地踏入了這裡。政宏老師雖然表面上是一個教授，但是政宏老師身兼數職，他不僅是一個能夠教導你人生道理的傳道士，也可以是一個能夠照顧你的家人，時時刻刻叮嚀著你，無論變胖變瘦都會關心著你，更是一個教學幽默風趣的教授，還是一個能夠像朋友打屁聊天的教授，是目前我所遇到最好的老師，可以說是我的啟蒙老師，我很感謝這個緣份。每一次的開會中，老師不僅僅在研究上能夠給你幫助、指引你研究的方向，也會分享老師的求學經歷與經驗，告訴我們學生應該有的本份，以及要如何秉持著好的態度去學習，與其他老師不同的是，總是站在學生的角度為學生思考，並不會因為老師是教授而有所不同。在求學過程中，老師就像家人支持著你，不會強迫你做你不喜歡的事情，反而給予你更多的是機會。政宏老師就像是船長一樣，而我們實驗室就像是一艘船，船長掌握著整艘船的方向，當有大浪來臨時，能夠順利引導整艘船避開險境，而當船員們(我們)害怕、恐懼時，不僅有很好的心態堅強面對，也能適時的鼓舞每一位船員。在此由衷地感謝林政宏老師，能夠給予我這個機會，讓我能夠在這求學的五年當中，獲得如此受用的收穫，感謝再感謝。實驗室的學長，暐辰學長，在大學期間，我與你的相處並沒有特別多，反而是你主動找我聊天、問我專題的近況，讓我在實驗室感受到一絲溫暖。碩士期. vi.

(7) 間，才發現暐辰學長是一個非常有想法的學長，當我有任何疑難雜症時，詢問你，總是會得到出乎意料的答案。能夠與你在實驗室一起奮鬥和聊天，一起去安徽參訪玩樂，是我的榮幸。很感謝你在這段期間對實驗室的無私奉獻。實驗室的好夥伴，林永鑫，指考數甲接近滿分的同學，能夠與你一起做專題與研究，我覺得是無比的榮幸與驕傲。大三大四的健身好夥伴，每天早上八點準時到健身房報到，你因此瘦了許多，但現在後悔莫及了吧。碩士期間，我們一起參與了許多產學計畫，共同完成了艱難的任務，感謝求學過程中有你的陪伴，身為朋友的我，在此希望往後你能夠不要那麼懶惰。另外還要感謝實驗室的學弟妹們，亦信、振豪、易穎、李穎、鐘暘，希望你們也能早日順利畢業，我相信未來你們一定能在政宏老師的帶領下，能夠有很好的成績與前途。另外要感謝本系蔣欣翰教授、元智大學陳勇志教授撥冗擔任口試委員，給予我指導與建議，使得此論文能更加完善，同時也給予我許多啟發與收穫。最後我要感謝的是我的家人，在求學的過程中，讓我在經濟上無後顧之憂，能夠專心在我的學業上，給予我支持與協助。. 在此時此刻的心情，充滿著感恩，感謝身邊每一個幫助過我的人，不管是實驗室的同學或學弟妹們、或是一起重訓加油打氣的朋友們、支持我的家人們，或許我沒辦法記下所有每次讓我感動的時刻，但這一切都被點滴記錄在心頭，成為我繼續努力的動力與方向。. 謝政宏 July 24, 2018. vii.

(8) 目. 錄. 中文摘要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ii. 英文摘要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iv. 誌謝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vi. 目錄 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii 圖目錄. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 表目錄. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii. 第一章緒論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 研究背景與動機 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 1.3 1.4 1.5. 研究目的 . . 研究方法概述研究貢獻 . . 論文架構 . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 2 2 4 4. 第二章文獻探討 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 入侵偵測系統 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6 6. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. . . . .. . . . . . . .. 7 10 10 15 17 18 20. 2.4.3 PixelSnort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Gnort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21 21. 第三章研究方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 多重字串比對演算法的優化 . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Data Parallel Aho-Corasick Algorithm . . . . . . . . . . . . . .. 25 25 25. viii. . . . . . . .. . . . .. 1 1. . . . .. 2.2 Snort 網路入侵偵測系統 . 2.3 樣式字串比對 . . . . . . . 2.3.1 單一樣式字串比對 2.3.2 多重樣式字串比對 2.4 Snort 相關研究文獻與討論 2.4.1 Supra-linear Packet 2.4.2 MultiSnort . . . . .. . . . .. x. . . . . . . ..

(9) 3.2 Snort 處理流程與程式架構 . . . . . . . . . . . 3.2.1 Snort 處理流程 . . . . . . . . . . . . . 3.2.2 Snort 程式架構 . . . . . . . . . . . . . 3.3 階層式平行架構 . . . . . . . . . . . . . . . . 3.3.1 緩衝區機制 . . . . . . . . . . . . . . . 3.3.2 第一層 – 資料平行於多個圖形處理器 . 3.3.3 第二層 – 任務平行於個別圖形處理器 .. . . . . . . .. 27 27 28 30 30 32 32. 3.3.4 第三層 – 資料平行於 Aho-Corasick . . . . . . . . . . . . . . . 3.3.5 後處理程序 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33 39. 第四章實驗結果 . . . . . . . 4.1 實驗環境與測試數據 4.1.1 實驗環境 . . . 4.1.2 測試數據 . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 41 41 41 42. 4.2 演算法效能分析 . . . . . . . . . . . . . . . 4.2.1 單執行緒 CPU 與單圖形處理器 GPU 4.3 系統整體效能評估 . . . . . . . . . . . . . . 4.3.1 多圖形處理器 Multi-GPU . . . . . . 4.3.2 多圖形處理器(Multi-GPU)樣本採計 . 4.4 相關論文之實驗數據分析 . . . . . . . . . . 4.5 實驗結論 . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 45 45 49 49 51 57 57. 第五章結論與未來展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 未來展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59 59 59. 參考文獻 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61. 自傳 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 64. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. ix. . . . .. . . . .. . . . .. . . . .. . . . ..

(10) 圖. 目. 錄. 圖 1-1. 階層式平行架構 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 圖 2-1. Snort 規則結構 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 圖 2-2. Snort 規則表頭結構 . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 圖 2-3. Snort 規則範例 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 圖 2-4. Snort 工作流程圖 . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 圖 2-5. KMP 演算法範例 . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 圖 2-6. Boyer-Moore 演算法壞字元範例 . . . . . . . . . . . . . . . . . .. 12. 圖 2-7. Boyer-Moore 演算法好後綴範例 . . . . . . . . . . . . . . . . . .. 14. 圖 2-8. Boyer-Moore 演算法範例 . . . . . . . . . . . . . . . . . . . . . .. 15. 圖 2-9. Aho-Corasick 狀態機，特徵字串為「he」、「she」、「his」、「hers」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 圖 2-10 Snort 工作流程圖 . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 圖 2-11 Supra-linear packet processing 結構 . . . . . . . . . . . . . . . . .. 19. 圖 2-12 MultiSnort 結構 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 圖 2-13 Gnort 架構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 圖 2-14 Packet per multiprocessor 架構 . . . . . . . . . . . . . . . . . . . .. 23. 圖 2-15 Packet per stream processor 架構 . . . . . . . . . . . . . . . . . .. 23. 圖 3-1. 邊界偵測問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 圖 3-2. Snort 處理流程 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 圖 3-3. Snort 程式架構 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 圖 3-4. Multiple Pattern Search Engine Interface . . . . . . . . . . . . . . .. 29. x.

(11) 圖 3-5. 異質運算架構 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31. 圖 3-6. 階層式平行架構 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 圖 3-7. CUDA streaming schedule . . . . . . . . . . . . . . . . . . . . . .. 33. 圖 3-8. Parallel Failureless Aho-Corasick 演算法 . . . . . . . . . . . . . .. 34. 圖 3-9. Failureless Aho-Corasick 狀態機，由特徵字串「he」，「she」，「his」，「her」所建構 . . . . . . . . . . . . . . . . . . . . . .. 35. 圖 3-10 PFAC 範例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 圖 3-11 Perfect hashing table 範例 . . . . . . . . . . . . . . . . . . . . . .. 38. 圖 3-12 查詢雜湊表步驟 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 圖 3-13 後處理程序 Linked list . . . . . . . . . . . . . . . . . . . . . . . .. 40. 圖 3-14 後處理程序 Self-balanced binary searching tree . . . . . . . . . .. 40. 圖 4-1. Blacklist rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 圖 4-2. CVE rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 圖 4-3. 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 Blacklist rules，AC、PFAC 演算法的吞吐量表現 . . . . . . . . .. 圖 4-4. 48. 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 CVE rules，AC、PFAC 演算法的吞吐量表現 . . . . . . . . . . .. 48. 圖 4-5. V1 輸入封包吞吐量為 2.4 Gbps . . . . . . . . . . . . . . . . . . .. 51. 圖 4-6. V2 輸入封包吞吐量為 3.1 Gbps . . . . . . . . . . . . . . . . . . .. 52. 圖 4-7. V3 輸入封包吞吐量為 4.3 Gbps . . . . . . . . . . . . . . . . . . .. 53. 圖 4-8. V4 輸入封包吞吐量為 5.8 Gbps . . . . . . . . . . . . . . . . . . .. 53. 圖 4-9. V5 輸入封包吞吐量為 6.35 Gbps . . . . . . . . . . . . . . . . . .. 54. 圖 4-10 V6 輸入封包吞吐量為 6.4 Gbps . . . . . . . . . . . . . . . . . . .. 54. 圖 4-11 V7 輸入封包吞吐量為 8.4 Gbps . . . . . . . . . . . . . . . . . . .. 55. xi.

(12) 圖 4-12 V8 輸入封包吞吐量為 9.8 Gbps . . . . . . . . . . . . . . . . . . .. 55. 圖 4-13 V9 輸入封包吞吐量為 16 Gbps . . . . . . . . . . . . . . . . . . .. 56. 圖 4-14 V10 輸入封包吞吐量為 20 Gbps . . . . . . . . . . . . . . . . . .. 56. xii.

(13) 表. 目. 錄. 表 2.1. KMP 部分比對表(Partial Match Table) . . . . . . . . . . . . . . .. 11. 表 4.2. 中央處理器規格 CPU specification . . . . . . . . . . . . . . . . .. 42. 表 4.3. 圖形處理器規格 GPU specification . . . . . . . . . . . . . . . . .. 42. 表 4.4. 輸入封包檔 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 表 4.5. 規則樣式字串 . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 表 4.6. 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 Blacklist rules，AC、PFAC 吞吐量表 . . . . . . . . . . . . . . .. 表 4.7. 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 CVE rules，AC、PFAC 吞吐量表 . . . . . . . . . . . . . . . . .. 表 4.8. 表 4.10. 47. 多圖形處理器 Multi-GPU 基於規則樣式字串為 Blacklist rules，PFAC 演算法吞吐量表 . . . . . . . . . . . . . . . . . . . .. 表 4.9. 46. 50. 多圖形處理器 Multi-GPU 基於規則樣式字串為 CVE rules，PFAC 演算法吞吐量表 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50. Comparison with other methods . . . . . . . . . . . . . . . . . . .. 57. xiii.

(14) 第一章緒論. 1.1. 研究背景與動機. 隨著現今網路的普及，網路安全日益重要，網路入侵偵測系統(Network Intrusion Detection System, NIDS)，被使用於分析網路封包、流量，以及警示惡意的攻擊行為。如今大數據的時代，網路攻擊的種類和數量成指數級成長，偵測系統中的擁有病毒與攻擊特徵的規則集逐漸龐大，導致偵測系統的負擔日益沉重。同時硬體資源的改善，也增加網路與應用程式的網路頻寬，使得 NIDS 必須提升系統的整體效能，才能達到目前的網路需求。 Snort [1] 是一個強大且輕量級的開源網路入侵偵測系統，具有很好的擴充性與可移植性，它具有即時網路流量分析與日誌化網路封包的能力。能夠處理包括 UDP、TCP 和 ICMP 等各種協定(Protocol)的分析，並針對封包的標頭(header)與內容(content)進行搜索與比對，找出可能藏有的攻擊特徵。它能夠檢測各種不同的攻擊活動，對攻擊活動進行即時警報，例如：秘密埠掃描、緩衝區溢出、CGI 攻擊、SMB 探測、探測操作系統指紋特徵的企圖等等。Snort 自 2002 年釋出之後，偵測引擎主要採用 Aho-Corasick [2] 的多重樣式(Multi-pattern)字串比對演算法。透過我們的分析，固定字串比對佔 Snort 整體系統效能的 41.68%，根據 OSEC [3] (Open Security Evaluation Criteria)的數據報告顯示，Snort 的效能約. 1.

(15) 為 750Mbps 的網路吞吐量，換句話說，由於攻擊特徵的增加與網路速度的需求，現今 Snort 面臨巨大的挑戰。因此有需多硬體與軟體的方法被提出，包括 FPGA [4][5]、CPU [6]、GPUs [7][19]，用來改善 Snort 的效能表現。過去我們在利用圖形處理器 GPU 加速字串比對的研究上已經有初步的成果，提出 Parallel Failureless Aho-Corasick，PFAC 演算法[8][9]，利用圖形處理器 GPU 加速傳統 Aho-Corasick 演算法。此外對於降低多重樣式字串比對的記憶體需求，也提出透過完美雜湊(Perfect hashing)[10]，壓縮 Aho-Corasick 狀態機，大幅降低記憶體的使用率，獲得大幅的效能提升。在本文當中，我們將延伸過去的研究成果於優化開源網路入侵偵測系統 Snort 的整體系統效能與減少字串比對的記憶體需求，並提出階層式平行架構、緩衝區機制、後處理程序，以提升 Snort 的效能。. 1.2. 研究目的. 由於大數據的時代來臨，攻擊活動與病毒入侵數量日益增生，數量龐大的規則集使得 Snort 偵測系統無法達到目前網路吞吐量的需求。傳統的硬體與軟體的改進，仍然無法使 Snort 的整體系統達到改善，因此我們將結合過去利用圖形處理器加速字串比對的演算法，以及利用階層式平行的架構，加速 Snort 的整體系統效能與減少字串比對演算法狀態機的記憶體需求，此外提出緩衝區機制、後處理程序，解決傳統在圖形處理器上運算會產生的問題。. 1.3. 研究方法概述. 本論文提出的階層式平行架構分為三個不同層面的平行技術，包含資料. 2.

(16) 平行(Data parallelism)於緩衝區機制、任務平行(Task parallelism)於多圖形處理器，與利用圖形處理器之資料平行於 Aho-Corasick 演算法稱作 Parallel Failureless Aho-Corasick 演算法。. 圖 1-1 階層式平行架構. 第一部分為資料平行於緩衝區機制(圖 1-1 左)，將通過網路的封包先行放置緩衝區等待，當緩衝區達到飽和時或超過停留時間，將緩衝區資料分別指派給四張圖形處理器運行，每個圖形處利器分別處理不同部分的輸入封包；也就是說在單一時間內將封包指派給不同圖形處理器運行，達到資料平行。第二部分為任務平行於圖形處理器(圖 1-1 中)，我們透過 CUDA Streaming 的方式，將圖形處理器進行排程。由於 CUDA Streaming 的優點在於可以隱藏 GPU computation 與 memory IO 的時間，因此達到資源管線化排程(Pipeline Scheduling)，使得圖形處理器資源最大化使用。第三部分為資源平行於 Aho-Corasick 演算法，稱作 Parallel Failureless AhoCorasick (圖 1-1 中間核心演算法 PFAC)，是運用於圖形處理器的一個高效能多重 3.

(17) 字串比對演算法，是將大量的 Input 字元指派給每個執行緒進行走訪狀態機，因圖形處理器擁有數以千計的執行緒，因此極適用於圖形顯示器中運算，是一個實現多重樣式字串比對、資料平行的方法。. 1.4. 研究貢獻. 我們提出一個階層式平行架構包含三個階層的平行化技術，加速開源網路入侵偵測系 Snort。實驗結果顯示透過四張圖形處理器 GPU，階層式平行架構可達到平均 70 Gbps 的網路吞吐量，相當於傳統 Snort 中所使用 Aho-Corasick 演算法的 40 倍效能提升。當圖形處理器數量增加，整體系統吞吐量也會隨之增加。. 1.5. 論文架構. 本論文將分為五個章節逐一介紹：緒論、文獻探討、研究方法、實驗結果以及結論與未來展望，以下條列各章節內文摘要。第一章緒論：講述現今網路入侵偵測系統 NIDS 的相關背景、研究目的以及研究方法概述，說明此研究的貢獻與論文架構。第二章文獻探討：針對開源網路入侵偵測系統 Snort、字串比對、研究方法相關之文獻探討說明。第三章研究方法：說明三個層面的階層式平行化技術，以及所提出的緩衝區機制與後處理程序。第四章實驗結果：說明實驗環境與實驗流程，以及實驗結果分析。第五章結論與未來展望：最後對此研究提出的方法與實驗結果做總結，並說明. 4.

(18) 未來可以改善的方向。. 5.

(19) 第二章文獻探討. 網路入侵偵測系統在過去已有不少研究被提出。本章節於 2.1 介紹入侵偵測系統，2.2 簡述 Snort 網路入侵偵測系統，2.3 樣式字串比對的應用與背景，2.4 分別整列過去 Snort 相關研究文獻與討論。. 2.1. 入侵偵測系統. 入侵偵測是一個計算機網路技術，在偵測不同類型的攻擊中扮演非常重要的角色，檢測通過計算機系統的一個偵測程序，入侵檢測系統主要提供三種的安全檢測方法，分別為監控、偵測、回應。入侵檢測主要識別計算機內部與外部的攻擊，普遍來說，IDS 可視為軟體與硬體結合的一個系統。入侵檢測的工作就像是大樓的安全警衛一樣，管理內部與外部人員的出進入情形。主要入侵偵測系統的好處如下:. 1. 檢測攻擊活動與各種對安全造成疑慮的行為 2. 確認會危害與感染系統的病毒 3. 觀察和分析計算機或網路系統活動 4. 評估重要系統的完整性和資訊文件. 理想的 IDS 應具備以下功能: 6.

(20) 1. 即時性 - 規定時間內檢測到異常行為 2. 高檢測率 - 保證找出大部分的異常行為 3. 低誤報率 - 允許少數虛假警報的數量 4. 特別性 - 一旦發現攻擊現象，便提供詳細訊息與回應 5. 可擴展性 - 可應用於各種小型或大型網路. 2.2. Snort 網路入侵偵測系統. Snort 是一個非常受歡迎的開源網路入侵偵測系統[1]，它可以同時在系統上進行通訊分析與資料流分析。在 Snort 中，使用者可任意撰寫需要的規則，並在系統中擁有很好的閱讀性以及擴充性。圖 2-1 為 Snort 規則的基本架構，包含兩個部分，第一部分為規則表頭(Rule header)，第二部分為規則選項(Rule options)。. 圖 2-1 Snort 規則結構. 圖 2-2 Snort 規則表頭結構. 7.

(21) 圖 2-3 Snort 規則範例. 圖 2-2 顯示在規則表頭中所有的欄位，圖 2-3 說明 Snort 中的規則範例，由圖 2-3 可以看出這個 Snort 規則會產生警告(Alert)的動作(Action)，協定(Protocal)是一個 TCP 的協定，擁有來源地址 172.16.123.12，是從任意來源端埠口至任意目的端埠口，目的端埠口為 54(DNS)，此外規則也帶有內容，顯示 "DNS request attempt" 以及規則識別碼 sid:1000010[6]。. 8.

(22) System initialization. Parse command line arguments. Parse rules. Capture packet. Gernerate rules linked list. Parse packet. N Match rules ? Y Response and alarm. 圖 2-4 Snort 工作流程圖. 如圖 2-4 在系統工作之前，Snort 進行初始化且解析命令行參數並進行設置，根據上述使用者定義的規則生成規則鏈表，同時調用相關初始化預處理模組、輸出模組。Snort 透過階層式的解析封包，解析完的封包透過一個指標儲存結構，指標包含源/目的端的結構指標、封包內容指標、封包長度、TCP/IP 等解碼內容等。Snort 將比對解析內容與特定規則鏈表是否發生入侵行為，系統將根據規則鏈表處理適當的處理方式，最後透過輸出模組進行紀錄或警報。. 9.

(23) 樣式字串比對. 2.3. 字串比對是在任何網路入侵偵測系統中，最為關鍵且影響系統效能的操作。字串比對可以簡單分為兩種類別，一為單一樣式字串比對，二為多重樣式字串比對。. 2.3.1. 單一樣式字串比對. 在單一樣式字串比對中，每個樣式字串都在給定的字串中進行搜尋，這表示當我們擁有 K 個樣式需要被搜尋，單一樣式字串比對必須重複執行 K 次。Knuth-Morris-Pratt [11]與 Boyer-Moore [12] 是最被廣泛使用的單一樣式字串比對演算法。 Knuth-Morris-Pratt(KMP) 演算法的核心，是透過部分比對表(Partial Match Table)所建構，部分比對表如表 2.1，是以樣式字串「abababca」所構成，如表所示，如果待比對的樣式字串有 8 個字元，部分比對表就有 8 個數值。先解釋字串的前綴與後綴，如果字串 A 和 B，存在 A = BS，其中 S 為任意非空的字串，我們就稱作 B 為 A 的前綴，舉例來說，「Jason」的前綴包括「J」、「Ja」、「Jas」、「Jaso」，我們將所有前綴的組合，稱作前綴集合。反之我們也可以定義 A = SB，也就是說稱作 B 是 A 的後綴，例如「Hsieh」的後綴包括「sieh」、「ieh」、「eh」、「h」，將後綴的組成稱為後綴集合。因此部分比對表的數值為字串前綴集合與後綴集合交集的最長元素長度。例如，對於，針對「abab」的前綴為「a」、「ab」、「aba」，後綴為「bab」、「ab」、「b」，而前綴與後綴的交集為「ab」，因此最長的元素就是字串 10.

(24) 表 2.1 KMP 部分比對表(Partial Match Table) char. a. b. a. b. a. b. c. a. index. 0. 1. 2. 3. 4. 5. 6. 7. value. 0. 0. 1. 2. 3. 4. 0. 1. 「ab」，長度為 2，對於樣式字串「abab」的部分比對表中對應的數值為 2。再舉一個例子，假設樣式字串為「ababa」，前綴為「a」、「ab」、「aba」、「abab」，後綴為「abab」、「aba」、「ab」、「a」，其中交集為「aba」，長度為 3。了解部分比對表的運作模式之後，就可以透過部分比對表來加速字串比對的尋找。如圖 2-5，我們的輸入字串為「ababababca」，樣式字串為「abababca」，在搜尋輸入字串的過程中，發現 j 位置發生字元不匹配成功，由於前面樣式字元部分比對表的性質，也就是說輸入字串的指標 i-j 到 i 的這一段位置與 0 到 j 是完全相同的，因此樣式字串 0 到 j-1，以這個例子為例就是「ababab」，其中最長元素為「abab」，長度為 4。因此我們可以將這一段字元省略，也就是直接移動 j 指標至樣式字串的部分比對表[j-1]，就可省略灰色部份的比對。. 圖 2-5 KMP 演算法範例 11.

(25) Robert S. Boyer 與 J Strother Moore 在 1977 年共同發表《A Fast String Search Algorithm》，文章當中介紹一種新的快速字串比對演算法，成為目前最廣泛使用的單一樣式字串比對演算法 Boyer-Moore。在傳統算法當中，對於輸入字串與樣式字串並未進行預處理的動作。而 KMP 演算法是針對樣式字串進行預處理的動作，建立部分比對表，預先計算樣式字串個位置最長相同前後綴的表。Boyer-Moore 演算法也是透過樣式字串進行預處理。Boyer-Moore 演算法針對樣式字串進行預處理時，採用兩種策略稱為:. 1. 壞字元 (Bad Character Heuristic)，當輸入字串的某個字元與樣式字串的某個字元發生不匹配時，我們稱輸入字串的不匹配字元為壞字元。 2. 好後綴 (Good Suffix Heuristic)，當輸入字串的某個字元與樣式字串的某個字元發生布不匹配時，我們稱輸入字串中已經匹配的字元為好後綴。. 根據這兩個策略建立 Bad Character Shift 與 Good Suffix Shift 的轉移表，當進行字串比對時，如果發生輸入字串與樣式字串不匹配時，將比較兩個策略所建立的轉移表，選擇兩種表對應數值最大的那一個進行跳躍。以下為 J Strother Moore 提供的演算法範例。. 圖 2-6 Boyer-Moore 演算法壞字元範例 12.

(26) 以輸入字串為“HERE IS A SIMPLE EXAMPLE”，樣式字串為“EXAMPLE”為例子，如圖 2-6，將輸入字串與樣式字串的頭部對齊，並從尾部開始進行匹配。如圖 2-6 1 ，發現尾部字元不匹配，則前面的字元也不需要在進行比較，我們發現“S”與“E”不匹配，我們稱“S”為輸入字串中的壞字元(Bad Character)。如圖 2-6 2 ，由於“S”在樣式字串中未出現，因此我們可以直接跳到“S”的後面繼續進行比較，之後發現“P”與“E”不匹配，“P”是壞字元，但是“P”有在樣式字串中出現，因此我們將樣式字串後移兩個位置，使得“P”對齊。因此我們可以歸納出壞字元策略的規則為「樣式後移位數 = 壞字元在樣式中不匹配的位置 – 壞字元在樣式字串中最後一次出現的位置」。因此以圖 2-6 2 ，“P”是壞字元為例，它不匹配位置為“E”的位置為 6，在樣式字串最後一次出現的位置為 4，因此位移數為 6-4 = 2，因此將樣式字串後移兩位，使得 P 可以對齊如圖 2-6 3 。我們繼續上述的過程，仍然從尾部開始進行比較，如圖 2-7 1 ，發現“E”與“E”匹配成功，繼續從尾部比較，發現“L”與“L”匹配如圖 2-7 2 ，繼續從尾部比較，發現“P”與“P”匹配如圖 2-7 3 ，繼續從尾部比較，發現“M”與“M”匹配如圖 2-7 4 ，繼續從尾部比較，發現“I”與“A”不匹配如圖 2-7 5 ，則“I”為壞字元，但由於前面已經匹配的字串為“MPLE”、“PLE”、“LE”、“E”，我們將這四個字串稱為好後綴。好後綴規則為「樣式後移位數 = 好後綴在樣式字串中的當前位置 – 好後綴在樣式字串中最右出現且前傳字元不同位置」，因此“MPLE”未出現，最右出現位置為 -1，“PLE”未出現，最右出現位置為 -1，“LE”未出現，最右出現位置為 -1，“E”出現在樣式字串的頭部，因此最右出現位置為 0，因此利用當前位置扣掉最右出現位置為 6-0 = 6，因此好後綴後移位數為 6，而根據壞字元規則發現，樣式字串後移位數為 2–(-1) = 3，根據 Boyer-Moore 演算法，我們會選擇壞字元規則與好後綴規則中，最大的值作為樣式字串滑動的位置，因此我們將樣式字串後移 6 位。. 13.

(27) 圖 2-7 Boyer-Moore 演算法好後綴範例. 因此將樣式字串後移 6 位如圖 2-8 1 ，繼續從尾部比較，發現“P”與“E”不匹配如圖 2-8 2 ，“P”是壞字元，則樣式後移位數為 6 – 4 = 2，因此將樣式字串後移 2 位，繼續從尾部比較，直到發現全部完成匹配如圖 2-8 3 。因此從上述範例顯示，Boyer-Moore 透過計算壞字元的轉移表與好後綴的轉移表，選擇其最大值作為轉移的位移量。在計算過程當中，只與樣式字串有關，與輸入字串無關。. 14.

(28) 圖 2-8 Boyer-Moore 演算法範例. 2.3.2. 多重樣式字串比對. 多重樣式字串比對是將樣式字串進行預處理的動作，會先建立樣式字串的有確定性狀態機，而這個狀態機會在比對階段進行掃描。狀態機可以被表示為一個樹的結構(Trie)、一個表或是兩者結合，輸入字串的每個字元都只會搜尋一次。在時間複雜度與效能上，多重樣式字串比對通常比單一樣式字串比對有優勢。多重樣式字串比對包括 Aho-Corarsick 演算法 [2]、Wu-Manber [13]、Commentz-Walter [14]。大部分的網路入侵偵測系統都採用狀態機與正規表示法 [1][22][23] 進行字串比對。C.Coit [21] 等人利用 Boyer-Moore 演算法的 skipping feature 結合 Aho-Corasick 的樹狀態結構，改進 Snort 的效能 Snort 自從 2.6 版本開始，只用 Aho-Corasick 多重字串樣式比對演算法進行偵測引擎模組的檢測。Snort 偵測引擎提供多種儲存樣式狀態機的設定，包括非確定性有限狀態機 Nondeterministic finite automaton(NFA)、確定性有限狀態機 Deterministic finite automaton(DFA)，以及保存在記憶體空間的格式，例如 full、sparse、banded、trie，等等有關的格式。. 15.

(29) Aho-Corasick 演算法的核心是將多個樣式字串構建成擁有 valid transition 的樹結構，接下來對每一個字元狀態構建其 failure transition，最後構建每個字元狀態的匹配值，會給予每個 final state 一個特定值代表其比對的特徵字串。Aho-Corasick 是一個多重樣式字串匹配演算法，主要是將數個特徵字串編譯成一個確定性有限狀態機 (Deterministic Finite Automata, DFA)，利用有限狀態機將字元比對轉化為狀態的轉移。這個演算法有兩個優點，一個是時間複雜度 O(n)，n 為輸入字串的長度，時間複雜度與特徵字串的數量和字串長度無關，另一個是搜尋輸入字串時不需要回溯。以圖 2-9 為例，為四個字串「he」、「she」、「his」、「hers」的 Aho-Corasick 確定性有限狀態機，狀態機按照 valid transition (以實線標註)的狀態轉移路徑進行轉移，當所有 valid transition 的狀態轉移路徑條件不能滿足時，再接著 failure transition(以虛線標註)的狀態轉移路徑進行狀態轉移。如：狀態 0 時，當輸入「h」，則轉移到狀態 1 ；輸入「e」，則轉移到狀態 2 ；否則轉換到狀態 0 。當狀態轉移到 2 ， 5 ， 7 ， 9 等狀態時，則分別代表比對比對到「he」，「she」、「his」，與「hers」等四個特徵字串。. 圖 2-9 Aho-Corasick 狀態機，特徵字串為「he」、「she」、「his」、「hers」. 16.

(30) 我們用一個例子來說明利用 Aho-Corasick 狀態機的比對方法。考慮一個輸入字串"shers"，這個執行緒從狀態 0 出發，首先提取輸入字元「s」，狀態機從狀態 0 轉移到狀態 3 ，接下來提取輸入字元「h」，狀態機從狀態 3 移轉到狀態 4 ，接下來取得輸入字元「e」，而抵達狀態 5 ，由於狀態 5 是特徵字串「she」的終點狀態，代表特徵字串「she」被匹配。接下來提取輸入字元「r」，因為沒有滿足 valid transition，因此執行緒藉由 failure transition 轉移到狀態 2 ，然後再取得一次字元「r」到狀態 8 ，最後取得「s」字元，抵達狀態 9 ，由於狀態 2 、狀態 5 與狀態 9 是特徵字串「he」、「she」、「hers」的終點狀態，代表特徵字串「he」、「she」、「hers」被匹配。. 2.4. Snort 相關研究文獻與討論. 圖 2-10 Snort 工作流程圖. 17.

(31) Snort 是目前最流行的開源網路入侵偵測系統，目前是由 Cisco Inc. 維護，最新穩定版本為 2.9.11，圖 2-10 描述了Snort 2.9.x 的工作流程，首先 Snort 會透過 libpcap 或其他函式庫進行數據採集，擷取網路或網路介面卡的封包(Data sniffer)，並透過解碼封包模組(Decode)，將擷取的封包進行解碼並匯入 Snort 的數據結構，在檢測封包之前，預處理模組(Preprocess)會先將封包進行修改或分析。而偵測引擎模組(Detect) 是將編譯完成的規則集與封包的內容進行多重樣式字串匹配(Pattern matching)。假如偵測過程中發現攻擊或特徵時，Snort 將警訊回傳給使用者(Alarm system)，並記錄其日誌方便後續檢測(Log system)。 Snort 2.x 使用單執行緒處理(Single-thread processing)，在多核心處理的過程中，只使用一個 CPU 核心進行運算，無法充分利用多核心優勢與計算能力。為了建構一個平行的系統架構，我們必須尋找在串列處理過程中的瓶頸。Derek L. Schuff 過去曾經研究 Snort 開源網路入侵偵測系統中的每一個模組的執行時間，發現偵測模組佔總系統執行時間的 51.90%，預處理模組平均佔總系統執行時間的 18.02% [15]，因此這項工作在於建立平行方法，以解決預處理模組與偵測模組的效能瓶頸。. 2.4.1. Supra-linear Packet. Supra-linear Packet Processing [16] 是基於 Snort 2.6 版本，在 2006 年由 Intel 開發完成，圖 2-11 說明他的系統架構。Supra-linear 將封包擷取模組結合封包分類雜湊模組(Packet classification hash) 作為一個指派封包的分配者，並且由一個執行緒負責。將其他處理模組獨立出來，並由多個執行緒負責處理。每個執行緒從解碼模組(Decoder)到輸出模組(Output)的處理流程中都是使用相同的程式碼，彼此獨立且不相互溝通。 18.

(32) 圖 2-11 Supra-linear packet processing 結構. Supra-linear 是一個簡單容易實現的方法，但執行緒處理過程中，無法共享記憶體空間，必須複製多份相同的資料給執行緒運算。但是在多執行緒的架構下，有些數據是可以共享的，像是 Aho-Corasick 編譯後的規則集，一個執行緒會編譯規則集大小約 1.5 GBytes，在大多數的平台上，無法為多執行緒分配如此龐大的記憶體空間。. 19.

(33) 2.4.2. MultiSnort. MultiSnort [15] 也是基於 Snort 2.6 版本，由 Derek L. Schuff, Purdue University 所提出的多執行緒 Snort 的架構，相較於 Supra-linear packet processing 結構，MultiSnort 只能平行化分配 Snort 的數個模組，並提出共享記憶體空間的方法，如圖 2-12 所示。. 圖 2-12 MultiSnort 結構. MultiSnort 設計一個負載平衡器(Load balancer)，使用分佈式任務佇列(Distributed task queues)來分派封包的流量，分派流量後，每個執行緒分別完成解碼模組與預處理模組和檢測動作，最後警示統一由輸出模組進行輸出。MultiSnort. 20.

(34) 從 Snort 2.6 版本的原始碼進行修改，但是由於每個模組元件(Data acquisition、Decoder)都與其他元件相互關聯，插入新的模組與元件並不容易。基於實驗環境下，MultiSnort 採用從記憶體讀取封包的方式，並非直接從網路介面中讀取封包，因此並未實現於真實網路當中。. 2.4.3. PixelSnort. 隨著大數據時代的來臨，越來越多研究人員使用圖形處理單元(GPU)加速他們的應用程序，例如嘗試使用圖形處理器運算包括密碼學 [17]、資料探勘 [18]、入侵檢測 [19]。Jacob and Brodley 是第一個嘗試使用圖形處理器優化網路入侵偵測系統的樣式匹配引擎，稱做 PixelSnort [19]。PixelSnort 利用圖形處理器加速簡化版本的 KMP 演算法，屬於單一樣式匹配演算法，實驗結果顯示效能只有微小的改善。. 2.4.4. Gnort. Gnort [7] 是由 Vasiliadis、Antonatos 在 2008 年所提出，是一個利用圖形處理器加速 Snort 開源網路入侵偵測系統，是目前與本篇論文最為相關的文獻。. 21.

(35) 圖 2-13 Gnort 架構. 如圖 2-13 所示，Gnort 系統架構分為三大部份，第一部分是將封包傳送至圖形處理器 GPU，第二部分是在圖形處理器中運行字串比對演算法，第三部份是將處理的結果傳回至 CPU。首先考慮如何將網路傳輸中的封包，傳送至 GPU 的記憶體空間，傳統方式是將封包依序單獨地傳送至 GPU 進行計算，由於 GPU 傳輸相關的花費成本，批次傳送封包不是有效率的做法，因此大量批次地傳送封包至 GPU 是比較有效率的方法 [20]。由於封包在封包分類模組會被分成不同的 Port Group，根據每個封包的來源與目的地不同，分成不同的 Group，批次處理機制就是將不同的 Group 分配至不同的緩衝區中，當緩衝區達到飽和時，再將緩衝區所有封包傳至 GPU 進行計算。當封包被傳送至 GPU 時，下一步驟就是在 GPU 上運行樣式匹配，Gnort 採用 Aho-Corasick 多重樣式字串匹配演算法，Gnort 實現兩種平行方法於不同的 Aho-Coarsick 層面，第一種方法是將封包切分成許多部份，每個執行緒平行地搜尋不同的部份，第二種方法為將整個封包平行地指派給每個執行緒處理。. 22.

(36) 圖 2-14 Packet per multiprocessor 架構. 圖 2-15 Packet per stream processor 架構. 23.

(37) Assigning a single packet to each multiprocessor，如圖 2-14，在此方法中，每個封包由特定的執行緒模塊(Thread block)處理。在執行緒模塊中，通常以一個 Warp 的大小為單位，因此執行緒模塊搜尋封包內容大小為固定大小。每個執行緒負責封包的不同部分，因此封包被分成 32 個不同的區塊(Chunks)，每個執行緒並行處理這些區塊。為了有效率地正確處理封包的不同區塊，每個執行緒會掃描超過自己區塊後的 X 字串長度，其中 X 為狀態表中最大樣式的長度。為了減少重複計算的運算成本，每個封包也會同時被複製到共享暫存器(Shared Memory)當中，所有執行緒並行地複製不同的區塊，因此不會增加額外的計算成本。這個方法的缺點是會重複計算封包的某些區塊，這種傳統平行化方法會遇到重複計算的問題，我們將在第三章會做詳細說明。 Assigning a single packet to each stream processor，如圖 2-15，在此方法中，每個封包由不同執行緒處理，所建立的模塊(Thread block)數量等於 GPU 所具有的處理器數量。每個執行緒區塊處理 X/N 個封包，其中 X 是傳送至 GPU 的批次處理封包數量，N 為圖形處理器的數量，但是每個區塊最大的執行緒數目為 512 個，因此如果每個執行緒區塊越多，則會擁有更多執行緒。這種方法的缺點是每個執行緒的工作量不會相同，因為封包大小有所不同。造成一個 Warp 的執行緒必須等待，直到所有執行緒完成被分配的封包。. 24.

(38) 第三章研究方法. 本章節將說明本論文提出的階層式平行架構的設計與研究方法。本章節各小節分別說明：3.1 介紹如何優化多重字串比對演算法；3.2 詳述 Snort 處理流程與程式架構，3.3 說明本論文提出的階層式平行架構，以及針對本論文在此架構所提出的緩衝區機制與後程序處理進行說明。. 多重字串比對演算法的優化. 3.1. Snort 網路入侵偵測系統在偵測網路封包時，由於病毒與攻擊事件逐漸擴增，因此自 Snort 2.6 版後，皆採用多重字串比對演算法 Aho-Corasick。偵測引擎會將使用者定義的規則，或是現有的資料庫規則如 CVE(Common Vulnerabilities and Exposures)，進行封包檢測。當規則集數量越來越多時，Aho-Corascik 字串比對演算法的負荷也越來越大，逐漸影響 Snort 的整體效能。. 3.1.1. Data Parallel Aho-Corasick Algorithm. 傳統上是採用資料平行的方式優化 Aho-Corasick Alogrithm，稱作 Data Parallel Aho-Corasick(DFAC)，我們將輸入串流(input stream)，切分成好幾個區塊(Segments)，而每個區塊由各別獨立的執行緒去走訪 AC 狀態機，以圖 3-1 為例，我們將輸入串流切分成四個區塊，一個執行緒負責一個區塊，且每個執行續都是走訪同一個 AC 狀態機。這種傳統的資料平行方法有一個重大的缺失，就是 25.

(39) 當要搜尋的特徵字串出現在相鄰區塊的邊界，則這個方法將無法匹配到此特徵字串，我們將這個問題稱作「邊界偵測問題」。舉例來說，如圖 3-1 有個特徵字串「she」在區塊三與區塊四中間發生邊界偵測問題，因此執行緒三與執行緒四無法匹配到「she」這個特徵字串。. 圖 3-1 邊界偵測問題. 為了解決邊界偵測的問題，每個執行緒必須越過自己的區塊搜尋。而搜尋額外的長度為最長特徵字串減一。越過邊界搜尋會造成每個執行緒的額外負擔，我們稱作為「重複計算」(Overlapping computing)問題，舉例來說，如圖 3-1，執行緒三越過三個字元長度找到特徵字串「she」，重複計算的複雜度可由以下表示，每個 DFAC 的執行緒時間複雜度為 O(n/s+m)，m 為最長特徵字串的長度，n 為總長度，s 為切分成幾個區塊，因此記憶體存取的時間複雜度為 O((n/s+m)*s) = O(n + ms)。AC 演算法記憶體存取的時間複雜度為 O(n)，與 AC 演算法相比較，DFAC 需要花更多時間在記憶體的存取。而大量的記憶體存取會造成目前 GPU 效能上的瓶頸。. 26.

(40) Snort 處理流程與程式架構. 3.2. 在此章節首先會先簡介 Snort 的架構，以便後續分析其處理流程與程式架構說明。. 3.2.1. Snort 處理流程 Selected Output Mode (Log files, console, sockets...etc) . Output Plugins Detection Plugins Detection Engine Reads/Applies References Preprocessor Rule files. Decoder. Packet Capture Module (Based on Libpcap/WinPcap) . Network Traffic. 圖 3-2 Snort 處理流程. 如圖 3-2 所示，由五個主要模組所組成，分別為. 27.

(41) 1. 解碼模組(Decoder) - 將捕獲的封包匯入 Snort 的資料結構中，並解碼鏈結層的協定，以及解碼 IP/TCP/UDP 的相關埠口資訊 2. 前處理模組(Preprocess) - 會根據不同的鏈結協定識別可通過的封包 3. 規則文件(Rule files) - 使用者可自行定義規則集的文件，也可以使用公開的規則集文件，例如 CVE rules 4. 檢測模組(Detection engine) - 從規則文件中定義的規則，並將規則與封包進行字串比對。。 5. 輸出模組(Output Plug-ins) - 將感染的封包進行警報，撰寫日誌，納入資料庫。. 3.2.2. Snort 程式架構. SnortMain. SnortInit. PacketLoop. Snort Initialization include preprocessing, detection engine, alert module. Process a packet in loop. fpCreatePortGroups. Preprocess. mpseSearch. Create port group object for all port tables. Decode and preprocess the packet. An abstracted interface to the Multi Pattern Matching routines. mpse Interface. fpEvalPacket. mpseNew, mpseAddPatterns . Evaluate the network packet. TCP. 圖 3-3 Snort 程式架構 28. UDP. ICMP. IP.

(42) Snort 的程式架構如圖 3-3，首先 SnortInit 會先將使用者的命令列參數進行設置，並初始化 Snort 所使用的模組，包括前處理模組(Preprocessing)、偵測模組(Detection engine)、以及輸出警示模組(Alert module)。使用者設定的規則文件會透過 fpCreatePortGroups 設置不同的規則埠口群組，建立埠口表，以便後續快速搜尋規則鏈表，並透過 MPSE(Multiple Pattern Search Engine) Interface 建立 Aho-Corasick 初始化參數，並將規則樣式字串加入於 Aho-Corascik 狀態機。從網路介面中擷取的封包，會送進 PacketLoop 進行處理，會將封包進行前處理動作(Preprocess)，解碼並匯入 Snort 的資料結構中。解碼完成的封包會透過 fpEvalPacket 將封包依不同通訊協定包括 TCP、UDP、ICMP、IP，進行掃描，而 mpseSearch 則為一個多重字串比對流程的抽象介面。. 圖 3-4 Multiple Pattern Search Engine Interface. MPSE(Multiple Pattern Search Engine) interface 多重字串比對流程的抽象介面，如圖 3-4 所示，將依序解釋其功能。. • mpseNew 會將所使用的演算法如 Aho-Corasick 多重樣式字串比對演算法的參數初始化，如字母大小為 256、所使用的狀態機為 DFA ...等 • mpseAddPattern 會將先前已分析完的規則，加入至 Aho-Corasick 物件中 • mpsePrePatterns 將規則樣式字串建立成鏈結串列，並透過鏈結串列建立 Aho-Corasick 所使用的 Failure list，與匹配成功的 Match list. 29.

(43) • mpseSearch 為 Aho-Corasick 演算法核心，透過上述設置的參數，進行 content 與 pattern 的字串比對 • mpseFree 則將所使用的物件、鏈結串列、表...等進行釋放. 了解其 MPSE(Multiple Pattern Search Engine) interface 多重字串比對流程的抽象介面後，我們可以增加其 Parallel Failureless Aho-Corasick algorithm 至抽象介面。. 3.3. 階層式平行架構. 由於傳統 Snort 屬於單執行緒處理，即使原本 Snort 內部已經提供許多 Aho-Corasick 演算法狀態機的優化配置，例如 NFA 狀態機的優化有 Full, Sparse, Sparsebands, Banded、DFA 狀態機優化有 Full matrix, Sparse, Sparsebands, Banded，但是仍然無法適應目前的網路速度與吞吐量。因此本論文提出將偵測模組從單執行緒的 CPU 處理，轉移至圖形處理器的多執行緒執行，並提出階層式的平行架構，加速 Snort 開源網路入侵偵測系統。. 3.3.1 緩衝區機制由於傳統 Snort 在處理封包時，皆透過 PacketLoop 外部的 PacketCallback 函式呼叫，屬於單一處理個別封包，換句話說，Snort 在偵測網路線路中的封包時，一次只會檢查一個封包。這樣的作法在目前多核心平台上，是非常沒有效率且無法充分利用其電腦資源。首先會先解釋為何需要緩衝區機制。. 30.

(44) 圖 3-5 異質運算架構. 首先如圖 3-5 所示，當今典型的異質運算是由兩個 CPU 或是多個 CPU 組成更多核心的 CPU 所構成的節點。目前圖形處理器(GPU)並不是一個獨立的平台，而是 CPU 的協同處理器。因此圖形處理器必須透過 PCI-Express 的匯流排與 CPU 進行資料上的溝通。因此 CPU 會被稱作主機(Host)，GPU 會被稱作設備(Device)。當我們要處理一個封包時，我們必須拷貝封包在 DRAM 中的內容，並透過 PCIE Bus 傳送至 GPU 的 DRAM，之後將封包在 GPU 中進行處理。由於 GPU 適合在單一時間內處理大量的資料，因此這個單一傳送封包至 GPU 處理的策略，是浪費頻寬且消耗資源。因此本篇論文提出批次處理的機制，將封包先行放置緩衝區，並批此處理緩衝區內的封包。為了達到批次處理的機制，我們提出階層式平行架構，利用資料與任務的平行，並利用多張圖形處理器優化 Snort。階層式平行架構如圖 3-6。. 31.

(45) 圖 3-6 階層式平行架構. 3.3.2. 第一層 – 資料平行於多個圖形處理器. 資料平行(Data parallelism)又稱為數據平行，是一種多個處理器的平行計算方式，將資料指派到不同的平行計算節點中。資料平行是將大筆資料劃分為若干個相同的子資料區塊。我們透過 OpenMP(Open Multi-Processing) 共享記憶體的方式，讓多個執行緒分配給不同的緩衝區當中。我們透過資料平行的方法實現在階層式平行架構中的第一層，我們設計緩衝區機制，將擷取自網路的封包暫時存放於緩衝區中，並且記錄該封包在緩衝區的位置，以便後續後處理程序應用。當緩衝區達到它的停留時間或者緩衝區飽和時，會將緩衝區劃分為若干個 input data，這邊以 4 個為例，分別同時指派給四張圖形處理器 GPU 運行；換句話說，也就是在單一時間內將封包指派達到資料平行。. 3.3.3 第二層 – 任務平行於個別圖形處理器任務平行(Task parallelism)又稱作功能平行或是控制平行，是平行運算程式. 32.

(46) 設計的一種，是指同一筆資料有多個任務需要進行(對任務進行分解)，舉例來說，不同處理器針對同一資料集，分別計算出不同的答案。我們透過任務平行的方法實現在階層式平行架構中的第二層，首要任務是透過緩衝區機制紀錄其封包的順序、封包位置，緩衝區達到它的停留時間或者緩衝區飽和時，會將緩衝區內的封包，批次傳入圖形處理器 GPUs 中進行下次任務的處理。. 圖 3-7 CUDA streaming schedule. 如圖 3-7 所示，典型圖形處理器 GPU 由三個任務所構成，第一為將資料從 CPU 搬移至 GPU 稱作 H2D (Host to device)，第二為 GPU 核心函式(Kernel function)，第三則是將運算結果從 GPU 搬移至 CPU，CUDA 提供串流技術的排程(Streaming schedule)，可以將資料批次性地傳送至 Kernel 進行演算法運算，因此我們透過 Streaming schedule 的排程技術，將封包批次性地傳送至圖形處理器(GPU)進行任務排程，增加系統效能表現，達到管線化處理(Pipeline processing)。. 3.3.4. 第三層 – 資料平行於 Aho-Corasick. 傳統 Aho-Corasick 演算法是透過一個執行緒，從輸入字串的開始走訪到結束，為了能夠加速字串比對的效能與速度，我們提出適合圖形處理器的演算 33.

(47) 法，一個利用 Data Parallelism 平行化的演算法 Parallel Failure-less Aho-Corasick (PFAC) Algorithm. 如圖 3-8，PFAC 演算法透過輸入字串，每個字元的位置賦予一個獨立的執行緒(Thread)，每個執行緒負責走訪一個狀態機。假設輸入字串長度為 n，則需要 n 個執行緒，每個執行緒同時執行字串匹配的任務。. 圖 3-8 Parallel Failureless Aho-Corasick 演算法. 由於每個執行需只需要走訪它所負責的字元起點使否有比對到特徵字串，因此每個執行緒只要按照 valid transition 的狀態轉移路徑進行轉移，當目前狀態沒有滿足路徑轉移條件時，這個執行緒就直接結束，不必在走訪 failure transition，這樣大幅減少了走訪路徑，簡化原本 Aho-Corasick 的狀態機，增加比對效能與速度。如圖 3-9 是沒有 failure transition 的 Aho-Corasick 狀態機，是由「he」，「she」，「his」，「her」所建構。與傳統 Aho-Corasick 狀態機的差別就是所有 failure transitions 與初始狀態 0 的 self-transition 都被刪除。. 34.

(48) 圖 3-9. Failureless Aho-Corasick 狀態機，由特徵字串「he」，「she」，「his」，. 「her」所建構. 以一個例子解釋 PFAC 演算法的比對過程。輸入字串為「shers」，如圖 3-10，執行緒 n 負責輸入字元「s」來走訪 Failureless-AC 狀態機。當取得輸入字元「s」、「h」與「e」之後，執行緒 n 到達 final state 為「she」的輸出字串，代表「she」特徵字串比對成功，接下來取得字元「r」，但是沒有 valid transition，因此執行緒 n，結束目前階段的任務。相同地，執行緒 n+1 負責輸日字元「h」，當執行緒 n+1 取得「h」、「e」、「r」、「s」之後，執行緒 n+1 到達 final state 為「hers」的輸出字串，代表「hers」特徵字串比對成功。相較於傳統 Aho-Corasick 演算法不同的地方，Aho-Corasick 利用單一執行緒搜尋到兩個特徵字串，PFAC 演算法是透過兩個平行的執行緒分別搜尋到兩個特徵字串。. 35.

(49) 圖 3-10 PFAC 範例. PFAC 是一個資料平行的演算法，將特徵字串的每個字元交給一個執行緒負責走訪狀態機，因此 PFAC 非常適合執行在圖形處理器，因為圖形處理器擁有數以千計的核心數，能夠在同一時間啟動龐大的執行緒，但絕大部分的執行緒會有很高的機率在開始後結束，原因是因為每個執行緒只負責目前的字元是否有比對到規則字串建構的狀態機，因此 PFAC 執行緒的生命週期會遠小於傳統 Aho-Corasick 演算法的執行緒。如圖 3-10，除了 n 與 n+1 的執行緒會在狀態，因為沒有滿足狀態機的 valid transitions，這個執行緒就會直接結束。由上述 Data Parallel Aho-Corasick 與 Parallel Failureless Aho-Corasick 的說明，我們可以統整以下優點與缺點. • Data Parallel Aho-Corasick algorithm – 每個執行緒會有掃描長度的限制 – 每個執行緒會有邊緣偵測的問題 • Parallel Failureless Aho-Corasick algorithm – 解決邊緣偵測問題 36.

(50) – 每個執行緒掃描長度為可變長度 – 大部分執行緒皆很早終止 – 解決重複計算問題. 隨著規則特徵字串的增加，會導致 PFAC 的狀態轉移表逐漸增大，而 PFAC 的狀態轉移表是一個稀疏的二維矩陣，因此我們針對 PFAC 狀態轉移表的記憶體需求，提出利用完美雜湊(Perfect hashing) 演算法來壓縮狀態轉移表。相較於傳統的雜湊，完美雜湊可以保證不會發生碰撞，且相較於之前的架構，完美雜湊有效地減少 99.5%的記憶體使用。以圖 3-11 為例子，假設狀態轉移表儲存的轉移狀態為「2、4、10、11、13、14、20、21、22、25、27」如圖 3-11，可以發現是一個寬度為 8 的二維的稀疏矩陣，我們透過完美雜湊來壓縮此稀疏矩陣。完美雜湊是透過 C.-C. Yao 提出的演算法改寫成狀態壓縮表。. 37.

(51) 圖 3-11 Perfect hashing table 範例. 如圖 3-11，第一步根據每個 Row 內的 Key (轉移狀態)的數目，賦予其優先順序，並依照順序對每個 Row 移動。移動順序為先向左靠齊第一個 Column，並向右移動直到每個 Key 對應到的 Column 是可使用(空)的，並紀錄它所移動的距離 -2 在 Row Table 中。接下來重複此動作，依序移動第 1、3、4 個 Row，並紀錄移動距離。最後壓縮成一維的 Hash key Table。而只要透過簡單的四個步驟就能查詢雜湊表，如圖 3-12，第一步為將計算 Key 原始在二維矩陣中的 Row 與 Column，第二步透過 Row Table 查詢 Key 在這個 Row 的位移量，第三步計算 Key 在一維陣列中的位置，最後我們會比對 Key 與 Hash key Table 中的狀態元素，假設是相同的 Key，則為 Valid key，反之則不是真正的 Key。而我們透過 Key 就可以確認是否為 Valid transition。舉例來說，給予一個輸入 Key 13，它的. 38.

(52) Row 等於 13 / 8 = 1，Column 等於 13 mod 8 = 5，因此它的 Hash value 為 RT[1] + 5 = -2 + 5 = 3。由於 HK[3] = 13，因此我們得知 13 是一個有效的 Key。相反如果給予一個非法的 key 18，它的 Row 等於 18/8 = 2，Column 等於 18 mod 8 = 2，因此它的 Hash value 為 RT[2] + 2 = 1 + 2 = 3。由於 HK[3] = 13，不等於 18，因此可以得知 19 不是合法的 Key。. 圖 3-12 查詢雜湊表步驟. 3.3.5. 後處理程序. 有別於 Snort 傳統的處理過程，Snort 透過偵測模組中的 Aho-Corasick 多重樣式字串比對演算法，各別處理單一的封包，再透過 Output 輸出模組，輸出此封包在哪個位子被匹配成功，藉此警訊使用者。我們提出的階層式平行架構，設計緩衝區機制，將擷取自網路的封包暫時存放於緩衝區中，並且記錄該封包在緩衝區的位置。當圖形處理器 GPU 處理完成後，會回傳比對結果，因此要如何快速地搜尋是哪一個封包被匹配到成為首要目標。最簡單的方法，就是在緩衝區機制時，利用鏈結串列(Linked list)建立每個封包的節點如圖 3-13 所示，Packet Data 會記錄封包的起始位置、封包長度、封包識別碼，而 Pointer 則是指向另一個封包。當圖形處理器計算完匹配位置時，會回傳在緩衝區的匹配位置為何，我. 39.

(53) 們可以透過鏈結串列查詢匹配位置為哪個封包，以便後續銜接輸出模組，警示給使用者。. head. Pointer. Packet data. Packet data. Packet data. Packet data. Pointer. Pointer. Pointer. Null. 圖 3-13 後處理程序 Linked list. 由於當封包數量增加時，鏈結串列的搜尋時間複雜度為 O(n)，n 為建立的封包節點，因此本論文提出後處理程序，在緩衝區機制時，建立二元平衡搜尋樹來建構封包在緩衝區的起始位置與封包識別碼，以利後續後處理程序快速搜尋出比對結果。由圖 3-14 所示，透過二元平衡搜尋樹搜尋，搜尋時間複雜度為 O(logn)，n 為所建構的樹節點。降低傳統利用鏈結串列搜尋的時間，增加搜尋速度。. 50. Packet start_pos. Packet start_pos. Packet start_pos. Packet start_pos. 72. 17. Packet start_pos. 12. Packet start_pos. 23. 圖 3-14 後處理程序 Self-balanced binary searching tree. 40. 54.

(54) 第四章實驗結果. 本章節將說明本論文嘗試之所有實驗，對於階層式平行架構中依序介紹，分別述於：4.1 實驗環境與測試數據，4.2 演算法效能分析，4.3 系統整體效能評估，4.4 相關論文之實驗數據分析，並於 4.5 實驗結論，進行實驗結果討論. 實驗環境與測試數據. 4.1. 4.1.1. 實驗環境. 實驗環境包含兩個 CPU 主機端(Host)與四個 GPU 設備端(Device)，單一主機端為 Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz 的中央處理器，詳細規格如表 4.2，單一設備端端為 Nvidia TITAN X (PASCAL) GPU，含有 3,840 個 CUDA Cores 與 12GB DDR5X DDRAM ，詳細規格如表 4.3。實驗伺服器作業系統為 Xubuntu 16.04 LTS。採用 OpenMP[25]、CUDA[20] 撰寫、加速階層式平行架構。編譯器為 GCC-5.4.0 以及 CUDA-8.0’s NVCC。. 41.

(55) 表 4.2 中央處理器規格 CPU specification Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz Product. Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz. Number of Cores. 16. Number of Threads. 32. Processor Base Frequency. 2.10 GHz. Max Turbo Frequency. 3.00 GHz. Cache. 40 MB SmartCache. Bus Speed. 9.6 GT/s QPI. Number of QPI Links. 2. TDP. 120 W. 表 4.3 圖形處理器規格 GPU specification GeForce GTX TITAN X (Pascal). 4.1.2. Device name. GeForce GTX TITAN X (Pascal). CUDA Cores. 3840. Boost Clock(MHz). 1582. Memory Speed. 11.4Gbps. Standard Memory Config. 12GB GDDR5X. Memory Interface Width. 384-bit. Memory Bandwidth(GB/sec). 547.7 GB/s. 測試數據. （一）輸入封包檔. 此實驗方法目標以測量 Aho-Corasick 演算法與 Parallel Failure Aho-Corasick 演算法，以及系統效能評估，我們透過封包產生器(Packet generator)，產生不同 42.

(56) 吞吐量(Throughput)的輸入封包，作為測試數據之一，檢測兩種演算法是否能應付不同吞吐量的輸入封包，測試 Snort 在此輸入封包下的效能評估。輸入封包檔大小皆為 208 MegaBytes，吞吐量分別為 2.40 Gbps、3.10 Gbps、4.30 Gbps、5.80 Gbps、6.35 Gbps、6.40 Gbps、8.40 Gbps、9.80 Gbps、16.0 Gbps、20.0 Gbps，以吞吐量大小、封包數量作為區分如表 4.4。以 V1 版本編號為例，輸入封包吞吐量為 2.4 Gbps，輸入封包總數量為 220978。表 4.4 輸入封包檔輸入封包檔大小. 版本編號. 輸入封包總數量. 輸入封包吞吐量. V1. 220978. 2.40 Gbps. V2. 285044. 3.10 Gbps. V3. 217913. 4.30 Gbps. V4. 240717. 5.80 Gbps. V5. 222444. 6.35 Gbps. V6. 222431. 6.40 Gbps. V7. 218164. 8.40 Gbps. V8. 217510. 9.80 Gbps. V9. 217135. 16.0 Gbps. V10. 214913. 20.0 Gbps. 208MB. （二）規則樣式字串. 此實驗方法目標以測量 Aho-Corasick 演算法與 Parallel Failureless AhoCorasick 演算法，以及系統效能評估。因此以 Snort 內部提供的規則集作為要比對的規則樣式字串。規則樣式字串如表 4.5。以 Blacklist rules 為例，規則檔大小為 30 KB，規則字元數量為 29949，規則樣式字串數量為 1000 個。以 CVE rules 為例，規則檔大小為 6.7 KB，規則字元數量為 6782，規則樣式字串數量為 273，詳細規則樣式描述內文如圖 4-1 為 Blacklist rules 樣式描述內文，圖 4-2 為 43.

(57) CVE rules 樣式描述內文。表 4.5 規則樣式字串規則檔名稱. 規則檔大小. 規則字元數量規則字串數量. Blacklist rules. 30K. 29949. 1000. CVE rules. 6.7K. 6782. 273. 圖 4-1 Blacklist rules. 44.

(58) 圖 4-2 CVE rules. 演算法效能分析. 4.2. 4.2.1. 單執行緒 CPU 與單圖形處理器 GPU. 如圖 3-7，我們可以了解典型圖形處理器 GPU 由三個部分所組成，分別是 H2D(Host to Device)、D2H(Device to Host)、Kernel，H2D 為將資料從主機端搬移至設備端所花的執行時間，D2H 為將比對結果傳回主機端所花的執行時間，Kernel 為核心字串比對演算法執行時間，我們將 H2D、D2H 稱作匯流排傳輸時間(PCIE)，因此我們可以由兩個層面討論，分別為核心(Kernel)字串比對演算法的吞吐量，以及包括匯流排傳輸時間的系統總吞吐量，如表 4.6 為規則樣式. 45.

(59) 字串 Blacklist rules 在傳統 Snort 架構中所測量的數據，橫軸為輸入封包大小、版本編號、輸入封包總數量、輸入封包吞吐量、單核心 CPU 所測量的 AC 演算法吞吐量、單圖形處理器 GPU 所測量的 PFAC 演算法系統吞吐量、單圖形處理器 GPU 所測量的 PFAC 演算法核心吞吐量。以 V1 版本編號為例，輸入封包大小為 208 MB，封包數量為 220978，輸入封包吞吐量為 2.4 Gbps，單核心 AC 演算法吞吐量為 1.5018 Gbps，單圖形處理器 PFAC 系統吞吐量為 23.4239、單圖形處理器 PFAC 核心演算法吞吐量為 520.5679 Gbps。當輸入封包吞吐量為 V1 版本編號 2.41 Gbps 時，傳統在 Snort 所使用的單核心 AC 演算法，無法將輸入封包的內容即時地處理完成，有可能造成封包遺漏等問題，而單圖形處理器 PFAC 演算法，不管是系統吞吐量，或者是核心吞吐量，都高於輸入封包的吞吐量，代表能夠即時地處理為 2.4 Gbps 的輸入封包。表 4.6 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 Blacklist rules，AC、PFAC 吞吐量表輸入封包大小. 輸入封包. 輸入封包. AC 演算法. PFAC 演算法. PFAC 演算法. 總數量. 吞吐量. 吞吐量. 系統吞吐量. 核心吞吐量. V1. 220978. 2.40 Gbps. 1.5018 Gbps. 23.4239 Gbps. 520.5679 Gbps. V2. 285044. 3.10 Gbps. 1.5544 Gbps. 24.5559 Gbps. 525.7862 Gbps. V3. 217913. 4.30 Gbps. 1.5143 Gbps. 24.5143 Gbps. 518.5445 Gbps. V4. 240717. 5.80 Gbps. 1.7090 Gbps. 24.4779 Gbps. 522.3417 Gbps. V5. 222444. 6.35 Gbps. 1.5288 Gbps. 24.3952 Gbps. 526.0016 Gbps. V6. 222431. 6.40 Gbps. 1.6967 Gbps. 25.0538 Gbps. 526.8844 Gbps. V7. 218164. 8.40 Gbps. 1.6910 Gbps. 25.3837 Gbps. 522.8190 Gbps. V8. 217510. 9.80 Gbps. 1.7190 Gbps. 25.0054 Gbps. 522.0870 Gbps. V9. 217135. 16.0 Gbps. 1.7699 Gbps. 23.4637 Gbps. 524.1651 Gbps. V10. 214913. 20.0 Gbps. 1.7187 Gbps. 24.6771 Gbps. 524.4938 Gbps. 版本編號. 208MB. 如表 4.7 為規則樣式字串 CVE rules 在傳統 Snort 架構中所測量的數據，橫軸. 46.

(60) 為輸入封包大小、版本編號、輸入封包總數量、輸入封包吞吐量、單核心 CPU 所測量的 AC 演算法吞吐量、單圖形處理器 GPU 所測量的 PFAC 演算法系統吞吐量、單圖形處理器 GPU 所測量的 PFAC 演算法核心吞吐量。以 V10 版本編號為例，輸入封包大小為 208 MB，輸入封包總數量為 214913，輸入封包吞吐量為 20.0 Gbps，單核心 AC 演算法吞吐量為 1.7270 Gbps，單圖形處理器 PFAC 演算法系統吞吐量為 23.7601 Gbps，單圖形處理器 PFAC 演算法核心吞吐量為 487.9394 Gbps。當輸入封包吞吐量為 V10 版本編號 20.0 Gbps 時，傳統在 Snort 所使用的單核心 AC 演算法，無法將輸入封包的內容即時地處理完成，有可能造成封包遺漏等問題，而單圖形處理器 PFAC 演算法，不管是系統吞吐量，或者是核心吞吐量，都高於輸入封包的吞吐量，代表能夠即時地處理為 20.0 Gbps 的輸入封包。表 4.7 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 CVE rules，AC、PFAC 吞吐量表輸入封包大小. 輸入封包. 輸入封包. AC 演算法. PFAC 演算法. PFAC 演算法. 總數量. 吞吐量. 吞吐量. 系統吞吐量. 核心吞吐量. V1. 220978. 2.40 Gbps. 1.8259 Gbps. 24.4341 Gbps. 483.9699 Gbps. V2. 285044. 3.10 Gbps. 1.8046 Gbps. 23.7115 Gbps. 484.4827 Gbps. V3. 217913. 4.30 Gbps. 1.7408 Gbps. 23.8685 Gbps. 488.3868 Gbps. V4. 240717. 5.80 Gbps. 1.7940 Gbps. 22.9522 Gbps. 493.6281 Gbps. V5. 222444. 6.35 Gbps. 1.7498 Gbps. 23.7262 Gbps. 489.5466 Gbps. V6. 222431. 6.40 Gbps. 1.8710 Gbps. 24.1666 Gbps. 488.5466 Gbps. V7. 218164. 8.40 Gbps. 1.7344 Gbps. 23.6462 Gbps. 492.4519 Gbps. V8. 217510. 9.80 Gbps. 1.7786 Gbps. 24.5871 Gbps. 492.7339 Gbps. V9. 217135. 16.0 Gbps. 1.8049 Gbps. 23.6448 Gbps. 489.1335 Gbps. V10. 214913. 20.0 Gbps. 1.7270 Gbps. 23.7601 Gbps. 487.9394 Gbps. 版本編號. 208MB. 如圖 4-3、圖 4-4，紅色為單圖形處理器 GPU 所測量的 PFAC 演算法系統的吞吐量，藍色為傳統 Snort 所使用單核心 CPU 所測量的 AC 演算法吞吐量。在 47.

(61) 各個不同吞吐量的輸入封包檔下對 Blacklist rules、CVE rules 兩種不同的規則樣式字串進行分析，實驗結果顯示，相較於單核心 AC 的演算法吞吐量，單圖形處理器 PFAC 演算法的系統吞吐量是非常高的，也就是說單圖形處理器 PFAC 演算法能夠處理的資料量優於傳統 Snort 所使用的 AC 演算法。參考點為 10 Gbps。. 吞吐量(Throughput) Gbps. AC. PFAC. 25 20 15 10 5 0 V1 V2 V3 V4 V5 V6 V7 V8 V9V10 版本編號. 圖 4-3. 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 Blacklist. rules，AC、PFAC 演算法的吞吐量表現. 吞吐量(Throughput) Gbps. AC. PFAC. 25 20 15 10 5 0 V1 V2 V3 V4 V5 V6 V7 V8 V9V10 版本編號. 圖 4-4. 單執行緒 CPU 與單圖形處理器 GPU 基於規則樣式字串為 CVE. rules，AC、PFAC 演算法的吞吐量表現 48.

(62) 系統整體效能評估. 4.3. 4.3.1. 多圖形處理器 Multi-GPU. 多圖形處理架構(Multi-GPU)，基於本篇論文測驗平台為四張圖形處理器，測量在多圖形處理器架構下的系統與核心的效能表現，如表 4.8、表 4.9 分別為規則樣式字串 Blacklist rules 及 CVE rules 的多圖形處理器架構測量數據，橫軸為輸入封包大小、版本編號、輸入封包總數量、輸入封包吞吐量(Batch throughput)、多圖形處理器 PFAC 演算法系統吞吐量、多圖形處理器 PFAC 演算法核心吞吐量。以表 4.8 V5 版本編號為例，輸入封包大小為 208 MB，輸入封包總數量為 222444，輸入封包吞吐量為 6.35 Gbps，多圖形處理器架構下 PFAC 演算法系統吞吐量為 69.2091 Gbps，PFAC 演算法核心吞吐量為 2091.1623 Gbps。由此可看出 PFAC 演算法無論是系統吞吐量亦或是核心吞吐量，都遠遠超過輸入封包吞吐量。. 49.

(63) 表 4.8 多圖形處理器 Multi-GPU 基於規則樣式字串為 Blacklist rules，PFAC 演算法吞吐量表. 輸入封包大小. 輸入封包. 輸入封包. PFAC 演算法. PFAC 演算法. 總數量. 吞吐量. 系統吞吐量. 核心吞吐量. V1. 220978. 2.40 Gbps. 71.6123 Gbps. 2076.2736 Gbps. V2. 285044. 3.10 Gbps. 68.9363 Gbps. 2094.9030 Gbps. V3. 217913. 4.30 Gbps. 69.5965 Gbps. 2062.3737 Gbps. V4. 240717. 5.80 Gbps. 68.7778 Gbps. 2082.3055 Gbps. V5. 222444. 6.35 Gbps. 69.3629 Gbps. 2091.1623 Gbps. V6. 222431. 6.40 Gbps. 70.5571 Gbps. 2097.8553 Gbps. V7. 218164. 8.40 Gbps. 70.2090 Gbps. 2092.6386 Gbps. V8. 217510. 9.80 Gbps. 71.5086 Gbps. 2086.9446 Gbps. V9. 217135. 16.0 Gbps. 70.1447 Gbps. 2087.6491 Gbps. V10. 214913. 20.0 Gbps. 72.2501 Gbps. 2085.4505 Gbps. 版本編號. 208MB. 表 4.9 多圖形處理器 Multi-GPU 基於規則樣式字串為 CVE rules，PFAC 演算法吞吐量表. 輸入封包大小. 輸入封包. 輸入封包. PFAC 演算法. PFAC 演算法. 總數量. 吞吐量. 系統吞吐量. 核心吞吐量. V1. 220978. 2.40 Gbps. 71.1838 Gbps. 1937.3548 Gbps. V2. 285044. 3.10 Gbps. 71.6958 Gbps. 1970.7792 Gbps. V3. 217913. 4.30 Gbps. 68.7932 Gbps. 1949.8805 Gbps. V4. 240717. 5.80 Gbps. 68.7539 Gbps. 1970.7631 Gbps. V5. 222444. 6.35 Gbps. 71.0838 Gbps. 1954.9846 Gbps. V6. 222431. 6.40 Gbps. 65.1584 Gbps. 1904.4605 Gbps. V7. 218164. 8.40 Gbps. 69.3669 Gbps. 1966.3034 Gbps. V8. 217510. 9.80 Gbps. 71.6244 Gbps. 1972.7590 Gbps. V9. 217135. 16.0 Gbps. 67.6798 Gbps. 1922.8753 Gbps. V10. 214913. 20.0 Gbps. 72.2678 Gbps. 1947.4334 Gbps. 版本編號. 208MB. 50.

(64) 4.3.2. 多圖形處理器(Multi-GPU)樣樣本採計. 為了凸顯多圖形處理器(Multi-GPU)的效能，我們將各個版本編號 V1 至 V10 取樣 100 次的 PFAC 系統吞吐量(Throughput)，做為參考依據，分別針對 2.4 Gbps 至 20 Gbps 的輸入封包吞吐量，進行個別 100 次的樣本採計。以樣本採計的資量顯示，在多圖形處理器的架構下，PFAC 演算法平均系統的吞吐量都高於輸入封包的吞吐量。基於多圖形處理器架構如圖 4-5 版本編號為 V1 輸入封包吞吐量為 2.4 Gbps 顯示，PFAC 演算法核心平均吞吐量為 71.6 Gbps。如圖 4-6 版本編號為 V2 輸入封包吞吐量為 3.1 Gbps 顯示，PFAC 演算法核心平均吞吐量為 68.9 Gbps。. 吞吐量(Throughput) Gbps. 100 80 71.6 60 40 20 2.4 0. 10. 20. 30. 40. 50 Sample. 60. 70. 圖 4-5 V1 輸入封包吞吐量為 2.4 Gbps. 51. 80. 90. 100.