網路型入侵偵測系統(以下以網路型 IDS 簡稱)
主機型入侵偵測系統(以下以主機型 IDS 簡稱)
應用程式型入侵偵測系統(以下以應用程式型 IDS 簡稱)
*前言:
在一個網路防禦網裡，IDS 並不能保證你所在網域的安全性，通常 IDS 需要與防火牆、安全人員所制定的安全策略、網路弱點稽查、權限稽核做結合，才能對整個網域做完整的保護措施。
*正題:
一個 IDS 的主要功能有三點，第一是監視目前狀況，第二是偵測的動作，第三是反制方法，而以下所會談到的，主要是第二點的部份，關於監視的方法與原理，請有興趣的讀者自行查閱 sniff/sniffer/sniffing/broadcast 等關鍵字。而要達到這三種功能，我們可以從異常狀況的發生、攻擊事件的確認、可疑事件的綜合分析等方法去達成。
大部份的入侵偵測系統都是以特徵模式(signatures)來辨別是否為蓄意的入侵或有攻擊的意圖，在網路封包的分析上，也開始走向網路規格協定的比對。以採集資料的方式來區分的話，可以將入侵偵測系統分為以監控網路封包為主的網路型IDS、以監控系統紀錄檔來做判斷的主機型 IDS 、以監控應用程式接收值做判斷的應用程式型 IDS。
應用程式型 IDS 主要是因應網路攻擊事件中，光是針對應用程式而使用的攻擊就佔絕大部份，而應用程式輸入值更是攻擊事件的關鍵要點，因此現在出現了針對應用程式接收值做確認的 IDS 。
網路型 IDS:
(A). 運作方式:
在網路的必經節點上過濾所有封包，並即時將這些封包加以分析比對，比如分析封包 header 的資料時，可以偵測到如 source route、out of band、fragmented packet(teardrop) land(same ip, port)
等攻擊，在分析封包內容時，可以偵測到如木馬程式的特定指令、如含有 shellcode 的攻擊程式、含有特定 cgi/php/asp 程式漏洞的特殊指令，這些都可以用最簡單的字串比對等方法來做為攻擊特徵 (signature) 的比對，例如 shellcode 部份可以用累計超過五十個 NOP 指令比對；比對 /etc/passwd 字串以表示有人試圖擷取、修改密碼檔。
在做分析比對的模組上，有以下四種的攻擊特徵比對模式：
(1). 特殊的字串、位元組及特徵值的比對、是否符合網路協定規格
(2). 事件發生的頻率，是否超過所設的門檻值
(3). 可疑事件的關聯性
(4). 統計結果上的異常例外數值 (異於往常的行為模式 *chjong*)
而在比對出符合的攻擊模式後，反應模組會有通知、警告以及做出反制行動等功能，通常會是通知管理者、切斷可疑連線或紀錄可疑連線以做為攻擊證據搜集、研究用。
(B). 網路型 IDS 相對於主機型 IDS 的優(缺)點:
(1). 集中注意於一網路節點:
網路型 IDS 因為只需設置在一網路必經節點上，而不像主機型 IDS 必須設置於網路上的每一台主機，在管理和成本考量上都是較理想的。
(相對的，若只設網路型 IDS 也會因為只靠唯一一層防護而需要冒較高的風險，而且網路型 IDS 如果沒有與應用程式結合運用的話，一遇到加密的點對點連線就沒輒了)
(2). 攻擊者較難除去進行攻擊後留下的封包證據:
因為網路型 IDS 所採取的是即時收集封包，攻擊者要抹滅曾經進行的攻擊證據更加困難。而這些收集到的封包證據也有助於辨認攻擊者。而在主機型 IDS 上，通常他們所用的紀錄檔或是稽核檔案，都可能會被攻擊者入侵後修改，而造成主機型 IDS 失效，甚至誤導之後的稽核檢查動作。
(3). 即時反應，減緩攻擊者造成的傷害:
因為網路型 IDS 所採取的是即時收集封包，可以在分析比對後即時通知、反應，避免給與攻擊者過多時間進行更進一步的攻擊行動。比如當一個惡意的 tcp 連線被偵測到時，網路型 IDS 可以隨即送出一個 tcp reset 封包以截斷這個連線，在一個惡意 udp icmp 連線中，隨即送出 icmp port/destination unreachable 封包以截斷這個連線。主機型 IDS 因為是採定時檢查的方式，容易在反應之前就遭受到阻絕攻擊而導致主機當機、或無法繼續運作、即時反應。
(ref: spoofing!)
(4). 較大的彈性空間:
網路型 IDS 可以選擇和主機型 IDS 一樣放在防火牆內部；但是也可以選擇放在防火牆外部，這點也是主機型 IDS 無法做到的，而此時無論成功通過防火牆或被防火牆擋下的攻擊事件，都會被網路型 IDS 偵測、紀錄下來，以獲得更多關於攻擊者的資訊。
除此之外，網路型 IDS 也不需要像主機型 IDS 要考慮到主機平台是否支援此 IDS 的因素。
(5). 匿蹤、隱形的能力:
相對於主機型 IDS，網路型的 IDS 可以不設定網路介面的位址 (IP address)，也就是達到隱形於網路，同時又能截取所有網路封包的資訊。而主機型 IDS 可能就是攻擊者的攻擊目標之一，攻擊者可能針對主機型 IDS 重要的檔案進行移除或更改。
主機型 IDS:
(A). 運作方式:
檢查主機所收集到的系統紀錄檔資料，以找出可疑的攻擊資料。在收集到新的紀錄資料時，IDS 比對可疑的攻擊模式，若有符合攻擊模式特徵(比對模式同網路型IDS 四點)，則通知管理人員並做出適當反制措施。
現行的主機型 IDS 除了稽核系統紀錄檔以外，也會定時 (ref: time trap, event trap)對重要的系統設定檔、執行檔進行計算稽核值 (checksum hash, md5, digital signature) 的比對，以確定重要的檔案未受惡意的更改。
而 IDS 的反應速度也就決定於所訂定的檢查頻率、或 event trap 產生(e.g open or modify a file) 的反應時間。當發現攻擊行為時，可以有結束使用者連線，停止使用者權限等反制動作。
現行的主機型 IDS 也有在特定的 port 上進行網路封包檢查，算是結合主機型與網路型 IDS 功能的一種方式，而網路型與主機型相互結合也是 IDS 發展的趨勢之一。
(B). 主機型 IDS 相對於網路型 IDS 的優(缺)點:
(1). 對於攻擊事件的影響有較詳盡的紀錄:
因為主機型 IDS 是將攻擊者所造成的系統改變紀錄下來，因此可以得知更多關於攻擊者對特定主機入侵事件造成的影響，及更準確的紀錄攻擊行動的成敗。這部份的紀錄也可以和網路型 IDS 所能即時測知的預警紀錄互相對照比較。
主機型 IDS 通常有個別使用者的上線紀錄，重要檔案的增刪修改紀錄，使用者權限改變的紀錄，使用者連線到哪裡的紀錄，系統對外開啟的 port 紀錄、由哪一個程式開啟哪些檔案、port number 等紀錄，這些都是網路型 IDS 很難做到的。
(2). console 安全防護:
這是主機型 IDS 可以防護的範圍，而網路型 IDS就無法做到這點防護。
(3). 點對點連線的防護:
目前有許多的點對點連線因為採取加密處理，而無法在網路型 IDS 上做到完全的檢查，除非利用網路架構來解決(ref: reverse proxy)，此時就可以在主機型 IDS 上，對連線傳輸的資料做稽核檢察。
(4). 不需另外新增主機硬體:
主機型 IDS 只需要在主機上另外安裝新的軟體，而不像網路型 IDS 需要另外新增主機硬體設備。
應用程式型 IDS:
(A). 變形 shellcode:
主要是針對輸入值的辨認來偵測攻擊行動的發生，可能的話可以直接攔截此輸入值，不讓應用程式執行到惡意的攻擊碼。但在實作偵測上有相當多的問題，因為目前的攻擊程式碼有很多變型的輸入值，從底層的組合語言 shellcode 等的變型，到字元不同編碼的變型，到字串可替代的各種變型都要考慮到，而這些變型如果在網路型 IDS 做檢查的話，勢必會造成處理速度太慢而無法搜集、檢查每個封包。關於字串的比對可能的發展方向是 fuzzy match，可以參考著名的 agrep 實作方法。
在變型的 shellcode 方面，我們可以把偵測連續的 NOP 指令改成是累計數，而不一定用連續的 NOP 作比對，並且對於可能的替代 NOP 用的組合語言指令做一份替換用的指令集列表做比對。針對加裝加密引擎的 shellcode 指令，我們可以加一個解密的模組比對，假如比對出解密的引擎出現，我們就可以假設有變型 shellcode 出現。
(ref:
http://www.cansecwest.com/spp_fnord.c ,
http://www.ngsec.com/ )
(B). Protocol flow and multi-pattern search
應用 protocol analysis 的觀念:
將 client/server 的傳輸分別識為 client->server 的 client flow，以及 server->client 的 server flow。
如此分別我們在已知的傳輸協定中就可以直接將 client flow 拿來做 client request 相關檢查；將 server flow 的資料拿來做 server response 相關檢查，如此一來(分別對 client/server flow 而言)，我們可以將比對的規則範圍縮小，也可以在更確切的 protocol
segment 中做規則比對的動作。
multi-pattern 的比對概念在於將某一類的比對規則應用於適合的資料上，因此首先，我們必需先將比對規則做相關類別的分類。比如依據 source/destination port、rule content 等參數為比對規則分類，在每一個分類集合中，也包括了這個分類所適用的封包種類(同時對規則封包做分類)。比如說 protocol flow 就是封包分類標準所用的參數之一。(應用於 snort 2.0 的 multi-rule search 上) snort multi-rule search:
(1). protocol field: (uricontent)
(2). generic content: (byte position in payload)
(3). packet anomaly: (icmp packets > 800bytes)
(ref:
http://www.snort.org/docs/Snort_20_v4.pdf )
*閃躲(攻擊) IDS 的方法:
以下討論的各種攻擊方法，主要是針對網路型 IDS 。
目前有一種攻擊程式會在連線當中釋放出誘敵的假封包(decoy with FIN or RST in TCP , of incorrect sequence number.)造成部份會保留連線狀態資料的網路型 IDS 錯認為該連線已經結束，逕而開始真正的攻擊動作。當然，對於直接截取所有封包而未做連線動態資料的網路型 IDS 就較不受影響。
第二種在實用上的攻擊程式則是在連線成功後，先送出大量的假封包(mass packets with wrong sequence numbers)藉此把某些網路型 IDS 的封包資料緩衝區塞滿，接著再進行實際的攻擊動作。當然，對於未設定封包資料緩衝區大小上限的網路型 IDS 這招就無效了，但是無大小上限的實作方式可能就比較需要更聰明的做法來達成，否則遇到傳輸量大的連線必定會變成阻絕攻擊的受害者。但若是以遭到阻絕式攻擊與入侵攻擊兩者的權衡輕重來看，是仍有很多討論空間的 :)
第三種在實用上的攻擊程式是利用封包分段的方式，躲過不檢查分段封包的網路型 IDS，或者是不會將分段封包重組的網路型 IDS 也無法查覺躲在分段封包(包括 IP 層與 TCP 層)中的攻擊程式碼。
(tcp is aware of mtu value, fragmentation example: first 8 bytes tcp header packet, the following packets are all sized to be 32 bytes data)。
另一種分段方法是重疊分段的傳送攻擊碼，比如第一次傳"OVV"，第二次傳"ERFLOW"，結果是送出 "OVERFLOW"的程式碼。
對於會經過不允許封包分段的網路節點，或者對方是會將過小封包丟棄的路由器或防火牆，此種攻擊法則會失效。(ref: tcp overlap)
第四種在實用上的攻擊程式是在連線之後，送出許多符合目前連線的 SYN 封包，就作業系統本身並不理會這種封包，但是對於會記錄連線狀態的網路型 IDS 而言，則會誤以為是新的連線產生，而與新的封包序號做同步的動作(sequence number sync)，在連線 timeout 之前攻擊方再送出一個新序號的 RST 封包，如此就可以讓此 IDS 以為連線已斷，但是事實上真正的行動才正要上演...:P
第五種攻擊是在真正的連線之前，先在攻擊主機上 bind 固定一個 port，再藉同一個 port 做接下來的動作: 送出誘敵的 SYN 封包，而這個封包的 checksum value 我們故意亂填，只要這個 IDS 沒有檢查 checksum 值就會以為已經有連線產生(sync with first SYN)，而之後真正的連線封包，反而在 IDS 內被認為是無效的垃圾封包。
第六種是混合型，一開始的情形與第一種攻擊類似，但是接下送出錯誤 checksum 的 FIN/RST 封包讓未檢查 checksum 的 IDS 以為該連線已斷，接下來就開始實際的攻擊動作。
第七種也是以上的混合型，先對目的地送出大量錯誤checksum 的封包，使 IDS 誤判，以躲過 IDS 的偵測。
第八種是藉由計算實際上到目標主機的 TTL 值，再以此值減一(通常就是 IDS 所在位置)送出
FIN/RST/Data 封包藉以讓 IDS 以為該連線已無效，再進行真正的連線。這個方法也可以跟封包分段做結合，也就是利用不會到達目的地的封包(較小的 TTL值、無效的封包)，藉此使 IDS 無法比對出真正的攻擊碼。
綜觀以上這些攻擊方法，主要是針對網路協定底層的可能問題如 checksum、sequence number sync、TTL、fragment 等等的封包 header 資料一一進行試驗破解，另外還有許多在網路協定應用程式層面的攻擊尚未介紹，以下我們再來看看另類攻擊包裝的可能方法。
第一種，類似 fragment 封包分段的作法，就是將攻擊的程式分成多段來執行，可以把第一次連線、第二次連線先放上片段的攻擊程式碼，再等到第三次攻擊
才進行真正的執行動作。目前實作的方法是掌握該網路協定的 time out 時限，在同一個 session time out 之前依序送出片段的程式碼，就可以達到躲過 IDS 的目的。值得注意的是，不管是 tcp 或 udp 分段的封包，除了這整串封包的第一個分段封包有 tcp 或 udp header 以外，接下來的分段封包都只含有 ip header 和 tcp 或 udp 的資料。因此，只要第一個分段封包不被發現，就可以達到目的了。
第二種，也是類似封包分段的作法，但是我們可以用不同來源的連線組成真正要執行的程式碼，等到程式碼都上傳完畢再執行。
第三種，利用不同的編碼方式代表同義的字元，比如用二進位或十六進位的方式來代替一般的字元，用 ISO 8859-1 的 &=34 或 " 來代表 " ，比如說十六進位的:
GET %65%74%63/%70%61%73%73%77%64
或者是
GET %65%74%63/%70a%73%73%77d
來代表 GET /etc/passwd
再考慮 UNICODE UTF8 編碼的變種方式( 如%c0%af的 escape sequence、%c0%ae%c0%ae 的 `..' 路徑漫遊)，這些不同編碼在網頁處理的漏洞攻擊上，常常扮演著重要的角色。
第四種，用變數名稱代表重要的資料、檔案，用 shell script 的名稱來代表要執行的惡意程式，用不同的程式代表同樣的功能，比如 `echo *' 代表 `ls'；字串的處理如 /etc/passwd 可以改成如 /etc//\//passwd，/etc/rc.d/.././\passwd。
第五種，使用加密資料來傳輸，到達目的地之後再將資料解密(ref: VPN, SSL, ipsec)。
第六種，先嘗試把 IDS 所在的主機平台設定為第一攻擊目標，在網路型 IDS 運作前就將該主機平台以阻絕式攻擊癱瘓。或者在 IDS 動作前就先取得權限。
第七種，先以大家較熟的"經典"級(較舊的:)的攻擊從假的來源位址發動，以大量的攻擊封包讓 IDS 的 audit record 佔滿該 IDS 的稽核資料庫；或者是讓 IDS 忙碌於較高頻率的雜訊，再趁亂同時發動攻擊，讓 IDS 措手不及。
第八種，變型的 shellcode，在變型的 shellcode 出現之前，IDS 所使用來辨識 shellcode 的方法就是抓取 NOP(0x90 on IA32) 指令，或者是抓取有執行 /bin/sh 或者是 bind port shell 的動作，但是現在變型的 shellcode 可以把一連串的 NOP 指令轉換成 inc %eax, inc %ebx, pop %eax, nop, dec %eax, dec %ebx ...等等的同義 NOP,(0x90) 指令，而在執行shellcode、bind shell 的部份則用了 xor 等指令來做簡單的加密引擎(從病毒寫法模仿而來)，使得 IDS 無法辨認。與 NOP 指令同義的相關指令集(包括x86以外的平台)可到以下的網址取得:
http://www.cansecwest.com/noplist-v1-1.txt(ref: spoof, stick, snot, frageroute, whisker)
*IDS 未來的發展方向:
(1). 網路型和主機型 IDS 兩者的整合，需考慮到 IDS 本身的穩定性，針對阻絕式服務的應變方式，要能有容錯能力，在發生系統錯誤時能夠自動重新啟動、或者是保有備份系統的運作。(ref: fault tolerance)
(2). 整合的事件紀錄資料庫，整合的事件報告，考慮保留連線狀態可能遺漏的攻擊事件紀錄，加強對封包重組檢查的完備性。(ref: data mining)
(3). 整合的事件處理與事件回應，和防火牆整合的應變程序，和決策支援系統的整合，讓管理者能夠依據個別網路環境實況，得到動態的決策建議。
(ref: decision support system, expert system)
(4). 必需對假警報事件做更完整的檢查，並且需考慮到連線狀態的真假判定，以及所監控的網路協定正確的溝通方法，藉由觀察伺服器回應的封包，要有判斷攻擊事件成功與否的判定能力。不可以為了提高效率就忽略封包完整性的檢查，如此就失去 IDS 存在的意義了。
(5). 針對比對的規則，時間與封包數量方面考慮動態的依照事件發生頻率、異常封包、異常流量修改比對的順序、為各種已知攻擊危險性設定加權值，提高比對的效率。
調整同一來源(主機、網域)攻擊的比重值，增加偵測未知攻擊型態的能力。同時也必須注意到所需蒐集資料量的最佳化處理，以免浪費過多處理用的資料空間。
(ref: packet frequency, Digital Signal Process)
(6). 針對各個協定的網路封包格式，進行強制性的封包 header 資料修正動作，直接避免不符合協定的封包。
朝向以 Intrusion Response 為起點, 以 Intrusion Prevention 為目標的發展方向。強制改變封包的動作所造成的影響，也是另一個研究主題。
(ref: preemption, 2003 iraqi war )
(ref: state-full, detect scan, redirect[reply] to spoof feature in ipfilter, protocol analysis, BlackICE, protocol compliance, uricontent in snort, Boyre-Moore, Aho-Corasick, Algorithms on strings, string matching, similarity between of firewall and ids, ipfilter + bridge = stealth, no ip address and route table, reassemble preprocessor in snort :)
*參考資料: 網路上的某十九篇討論 ids 的論文、文章 :)
(1). Pilymorphic Shellcodes vs. Application IDSs
by Next Generation Security Technologies
(2). IDS Evasion Techniques and Tactics
by Kevin Timm
(3). Insertion, Evasion, and Denial of Service:
Eluding Network Intrusion Detection
by Thomas H. Ptacek tqbf at securenetworks.com
Timothy N. Newsham newsham at securenetworks.com
Secure Networks, Inc. January 1998
(4). An Intrusion Detection Model Combining Abnormal
Detection and Misuse Detection Using Self-Organization Mapping.
by
李昭毅 jolo17 at seed.net.tw
蔡敦仁 drtt at mail.pccu.edu.tw
戴文彬 tai at faulty.pccu.edu.tw
(5). Increasing Performance in High Speed NIDS
A look at Snort's Internals
by Neil Desai ndesai01 at tampabay.rr.com
(6). A look at whisker's anti-IDS tactics
by Rain Forest Puppy
rfp at wiretrip.net
http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html(obsolete)
http://www.cirt.net/code/nikto.shtml
