IDS กับ IPS ต่างกันอย่างไร เมื่อวางแบบ Passive และ Inline

IDS (Intrusion Detection System) ตรวจทราฟฟิกแล้วแจ้งเตือน ส่วน IPS (Intrusion Prevention System) ทำทุกอย่างที่ IDS ทำได้ และพยายามหยุดการโจมตีได้ด้วย ความต่างที่เห็นได้ชัดที่สุดอยู่ที่ตำแหน่งที่ติดตั้ง IDS มักวางแบบ passive ได้แค่สำเนาของทราฟฟิก ส่วน IPS วางแบบ inline ให้ทราฟฟิกวิ่งผ่านตัวมัน จึง drop แพ็กเก็ตได้

บทความนี้เขียนแบบถาม-ตอบ อิงเอกสารหลักคือ NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS) ฉบับเดือนกุมภาพันธ์ พ.ศ. 2550 ซึ่งยังเป็นฉบับ final ที่ใช้อยู่ เพราะ draft Revision 1 ปี พ.ศ. 2555 ไม่ได้ออกเป็นฉบับ final และถูกยกเลิกไปแล้ว ส่วนตัวอย่างคำสั่งมาจากเอกสารของ Suricata และ Snort ครับ

IDS   passive: gets a copy                                      
                                                                
┌───────┐                                             ┌────────┐
│client │[bad]─────────[sw] ──────────────────────────│ server │
└───────┘                ┆ SPAN                       └────────┘
                   ┌────────────┐                               
                   │ IDS sensor●│                               
                   └────────────┘                               
                                                                
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
IPS   inline: traffic goes through it                           
                                                                
┌───────┐                 ┌──────────┐                ┌────────┐
│client │─────────────────│    IPS  ●│────────────────│ server │
└───────┘                 └──────────┘                └────────┘
                                                                
                                                                
IDS sees a copy, so it can only alert. IPS is in the path.      

IDS กับ IPS ต่างกันตรงไหน

IPS คือ IDS ที่หยุดการโจมตีได้ NIST นิยาม IDS ว่าเป็น software ที่ทำ intrusion detection แบบอัตโนมัติ และนิยาม IPS ว่าเป็น software ที่มีความสามารถทั้งหมดของ IDS และพยายามหยุด incident ที่อาจเกิดขึ้นได้ด้วย (หัวข้อ 2) เอกสารยังบอกว่าผู้ดูแลมักปิดฟีเจอร์ prevention ใน IPS ให้ทำงานเป็น IDS ได้ NIST จึงเรียกรวมทั้งสองแบบว่า IDPS

ที่มาของตาราง: NIST SP 800-94 หัวข้อ 4.2 และ 4.3.4

IDS ได้ทราฟฟิกมาจากไหน ถ้าไม่ได้อยู่บนเส้นทาง

ได้สำเนามาครับ NIST นิยาม passive sensor ว่าตรวจสำเนาของทราฟฟิกจริง โดยไม่มีทราฟฟิกวิ่งผ่านตัว sensor เลย และวิธีรับสำเนามีสามแบบ:

• SPAN port พอร์ตบน switch ที่เห็นทราฟฟิกที่วิ่งผ่าน switch ข้อเสียคือถ้าตั้งค่า switch ผิดจะเห็นไม่ครบ และเมื่อ switch โหลดสูง SPAN port อาจเห็นทราฟฟิกไม่ครบหรือถูกปิดชั่วคราว
• Network tap ต่อเข้ากับสายโดยตรง เช่น สาย fiber ได้สำเนาครบ แต่การติดตั้งมักต้องมี downtime
• IDS load balancer รวมสำเนาจากหลายจุดแล้วแจกให้ sensor หลายตัว ข้อควรระวังคือถ้าแบ่งทราฟฟิกให้ sensor คนละตัว ขั้นตอนของการโจมตีเดียวกันอาจไปอยู่คนละ sensor และไม่มีตัวไหนจับได้

firewall รุ่นใหม่ก็ทำงานแบบนี้ได้ ใน PAN-OS ถ้าตั้ง interface เป็น Tap mode แล้วต่อกับ SPAN port ตัว firewall จะเห็นแอปและภัยคุกคามในเครือข่าย แต่เพราะทราฟฟิกไม่ได้วิ่งผ่าน firewall จึงทำอะไรกับทราฟฟิกไม่ได้ เช่น บล็อก เอกสารจึงให้ตั้ง action ของ Security Profile เป็น alert

IPS หยุดการโจมตีได้อย่างไร

IPS วางแบบ inline คือทราฟฟิกที่มันตรวจต้องวิ่งผ่านตัวมัน และมักวางที่รอยต่อระหว่างเครือข่าย ตำแหน่งเดียวกับ firewall เมื่อเจอแพ็กเก็ตที่ตรง rule ก็ไม่ส่งต่อ NIST ระบุความสามารถที่ทำได้เฉพาะแบบ inline ไว้สามอย่าง คือ drop หรือ reject ทราฟฟิก, จำกัด bandwidth ของ protocol ที่ถูกใช้ผิดทาง และแก้เนื้อหาอันตรายในแพ็กเก็ต ส่วน passive sensor ทำได้แค่ส่ง TCP reset ไปให้ปลายทั้งสองฝั่ง ซึ่ง NIST บอกว่าหลายครั้ง reset ไปถึงไม่ทัน และใช้กับ UDP หรือ ICMP ไม่ได้

ข้อแนะนำของ NIST สั้นมาก ถ้าจะใช้ prevention ให้วาง inline ถ้าไม่ใช้ให้วาง passive

ตัวอย่างใน Suricata

Suricata ทำ IPS บน Linux ได้หลายแบบ แบบหนึ่งคือให้ netfilter ส่งแพ็กเก็ตเข้าคิว NFQUEUE แล้ว Suricata ตัดสินว่าจะปล่อยหรือ drop (Suricata 7.0: IPS/inline for Linux):

sudo iptables -I FORWARD -j NFQUEUE
sudo suricata -c /etc/suricata/suricata.yaml -q 0

อีกแบบคือ AF_PACKET ที่ใช้ interface สองขา และ copy-mode: ips จะทำตาม keyword drop ส่วน copy-mode: tap ไม่ drop อะไรเลย

rule ที่ใช้ตัดสินมี action นำหน้า เช่น alert, pass, drop และ reject โดย drop คือ drop แพ็กเก็ตและสร้าง alert ตัวอย่าง rule ที่เขียนตาม format ในเอกสาร:

drop http $EXTERNAL_NET any -> $HOME_NET any (msg:"URI contains /etc/passwd"; flow:established,to_server; http.uri; content:"/etc/passwd"; sid:1000001; rev:1;)

rule นี้ถ้า Suricata รันแบบ IDS จะได้แค่ alert ใน log ของ Suricata ฟิลด์ action ของ alert จะเป็น "allowed" เว้นแต่ rule ใช้ action drop และ Suricata อยู่ใน IPS mode จึงจะเป็น "blocked" เวลาอ่าน log ให้ดูฟิลด์นี้ก่อนสรุปว่าบล็อกแล้วหรือยัง

ตัวอย่างใน Snort 3

Snort 3 เลือกโหมดจาก command line ครับ อ่าน pcap ด้วย -r หรือฟังบน interface ด้วย -i จะเป็น passive โดยค่าเริ่มต้น และถ้า DAQ รองรับ ใส่ -Q เพื่อรันแบบ inline:

snort -Q --daq afpacket -i "eth0:eth1"

IDS และ IPS ใช้วิธีตรวจจับแบบไหนบ้าง

NIST แบ่งไว้สามวิธี และผลิตภัณฑ์ส่วนใหญ่ใช้หลายวิธีร่วมกัน (SP 800-94 หัวข้อ 2.3)

Signature-based

เทียบสิ่งที่เห็นกับ pattern ของภัยที่รู้จัก เช่น การ telnet ด้วย username root หรืออีเมลที่แนบไฟล์ชื่อ freepics.exe วิธีนี้ได้ผลดีกับภัยที่รู้จักแล้ว แต่แทบไม่ได้ผลกับภัยใหม่ หรือการโจมตีที่หลบด้วยเทคนิค evasion ตัวอย่างในเอกสารคือ แค่เปลี่ยนชื่อไฟล์เป็น freepics2.exe signature ที่หา freepics.exe ก็ไม่ match แล้ว

Anomaly-based

สร้าง profile ของพฤติกรรมปกติ แล้วแจ้งเมื่อเบี่ยงไปมาก เช่น สัดส่วน bandwidth ของ web หรือจำนวนครั้งที่ login ไม่สำเร็จ ข้อดีคือจับภัยที่ไม่เคยเห็นมาก่อนได้ ข้อเสียคือ false positive เยอะ ตัวอย่างใน NIST คืองาน maintenance ที่โอนไฟล์ใหญ่เดือนละครั้ง ถ้าไม่เกิดในช่วงที่สร้าง profile พอถึงวันนั้นก็จะถูกมองว่าผิดปกติและเกิด alert

Stateful protocol analysis

ตรวจตาม state ของ protocol เช่น session FTP ที่ยังไม่ login ควรใช้ได้แค่ไม่กี่คำสั่ง ถ้าใช้คำสั่งของคนที่ login แล้วถือว่าน่าสงสัย และตรวจความยาวของ argument ด้วย เช่น username ที่ปกติยาวไม่เกิน 20 ตัวอักษร ถ้ามา 1000 ตัวถือว่าน่าสงสัย ข้อเสียหลักคือใช้ทรัพยากรมาก NIST บอกไว้ใน footnote ด้วยว่า vendor บางเจ้าเรียกวิธีนี้ว่า deep packet inspection

ทำไม IPS ถึงเสี่ยงกว่า IDS เวลาตรวจจับผิด

เพราะ false positive ของ IDS คือ alert ที่ต้องเสียเวลาตรวจ แต่ false positive ของ IPS คือทราฟฟิกจริงที่ถูกบล็อกครับ

NIST นิยาม false positive ว่าคือการระบุกิจกรรมปกติว่าเป็นอันตราย และ false negative คือการพลาดกิจกรรมอันตราย เอกสารบอกว่าทำให้ทั้งสองแบบเป็นศูนย์ไม่ได้ และส่วนใหญ่ลดแบบหนึ่งก็จะเพิ่มอีกแบบ นอกจากนี้ deployment ใหม่มักมี false positive จำนวนมากจนกว่าจะ tune เสร็จ

ผมจึงชอบลำดับนี้ครับ เปิด rule ใหม่เป็น alert ก่อน ดู log สักระยะว่า match อะไรบ้าง แล้วค่อยเปลี่ยนเป็น drop เฉพาะ rule ที่ไม่ไปโดนทราฟฟิกปกติ

ถ้า IPS ล่มหรือรับโหลดไม่ไหว ทราฟฟิกจะผ่านหรือถูกบล็อก

แล้วแต่การตั้งค่าครับ ถ้าตั้งเป็น fail-open ทราฟฟิกผ่านไปโดยไม่ถูกตรวจ ถ้าเป็น fail-closed ทราฟฟิกถูกบล็อก ต้องเลือกว่าอยากเสียอะไรเมื่อมีปัญหา ระหว่างการตรวจกับการใช้งานได้

NIST อธิบายว่า inline sensor ที่ drop แพ็กเก็ตเพราะโหลดสูงทำให้การใช้งาน network สะดุด และแนะนำให้เลือก sensor ที่รู้ตัวว่าโหลดสูง แล้วเลือกได้ว่าจะปล่อยทราฟฟิกบางประเภทผ่านโดยไม่วิเคราะห์เต็มที่ หรือ drop ทราฟฟิกที่สำคัญน้อย

ค่าเริ่มต้นของแต่ละตัวต่างกัน:

• Suricata 7.0 มี exception policy สำหรับกรณีอย่าง memcap เต็ม ค่า auto ใน IPS mode ทำให้พฤติกรรมเริ่มต้นของ exception policy ส่วนใหญ่เป็น fail close คือ drop flow หรือแพ็กเก็ต ส่วนใน IDS mode ค่า auto คือไม่ใช้ exception policy
• Suricata กับ NFQUEUE ถ้าไม่มีโปรแกรมรอรับคิว แพ็กเก็ตที่ส่งเข้าคิวจะถูก drop ทั้งหมด ถ้าใส่ option bypass กฎจะทำตัวเป็น ACCEPT แทน เอกสารเตือนว่าวิธีนี้กัน link ล่มตอน Suricata ไม่ทำงานได้ แต่ก็ไม่มีการบล็อกในช่วงนั้นด้วย
• FortiGate (FortiOS 7.2) config ips global มี set fail-open ที่ ค่าเริ่มต้นเป็น disable คือบล็อกทราฟฟิกเมื่อ IPS buffer เต็ม

config ips global
    set fail-open enable
end

การเลือกว่าจะ fail-open หรือ fail-closed ควรตกลงกับเจ้าของระบบและเขียนไว้ใน design ไม่ควรปล่อยเป็นค่าเริ่มต้นโดยไม่มีใครรู้

ควรเริ่มจาก IDS หรือ IPS

ถ้ายังไม่รู้ว่าทราฟฟิกปกติของเครือข่ายหน้าตาเป็นอย่างไร ผมแนะนำให้เริ่มแบบ IDS หรือ IPS ที่ตั้ง rule เป็น alert ก่อนครับ เมื่อ tune จน alert ส่วนใหญ่มีความหมายแล้ว ค่อยเปิด drop ทีละกลุ่ม เช็กลิสต์ก่อนเปิดโหมดบล็อก:

1. sensor อยู่ในตำแหน่งที่ทราฟฟิกต้องผ่านจริง ไม่ใช่ SPAN port
2. รู้ว่า fail-open หรือ fail-closed และเจ้าของระบบยอมรับแล้ว
3. rule ที่จะ drop เคยรันเป็น alert มาก่อน และเห็นว่า match อะไรบ้าง
4. sensor รับโหลดช่วง peak ได้ โดยดูจากโปรโตคอลจริงในเครือข่าย ไม่ใช่ตัวเลขบน datasheet อย่างเดียว เพราะ NIST บอกว่าความสามารถจริงขึ้นกับ protocol ที่ใช้ อายุ connection และจำนวน connection พร้อมกัน
5. ทีมรู้วิธีอ่าน log ว่าแพ็กเก็ตไหนถูกบล็อกจริง เช่น ฟิลด์ action ของ Suricata

แหล่งอ้างอิง

• NIST SP 800-94: Guide to Intrusion Detection and Prevention Systems (IDPS), CSRC page
• NIST SP 800-94 (PDF, February 2007)
• Suricata 7.0.0: Setting up IPS/inline for Linux
• Suricata 7.0.0: Rules format
• Suricata 7.0.0: Exception policies
• Suricata 7.0.0: EVE JSON format
• Snort 3: Reading traffic
• FortiOS 7.2.0 CLI reference: config ips global
• PAN-OS: Tap interfaces