คู่มือฉบับสมบูรณ์สำหรับการติดตั้งใช้งาน Netfilter และ Suricata บน Linux

อินฟอร์เมเทค ดิจิตอล » Recursos » คู่มือฉบับสมบูรณ์สำหรับการติดตั้งใช้งาน Netfilter และ Suricata บน Linux

หากคุณทำงานกับเครือข่ายบน GNU/Linux ( ระบบปฏิบัติการ Linux ที่ดีที่สุดสำหรับความปลอดภัยและความเป็นส่วนตัว ) และสนใจที่จะก้าวข้ามขีดจำกัดของไฟร์วอลล์แบบคงที่ทั่วไป คุณอาจสงสัยว่าจะรวม Netfilter, NFQUEUE และ Suricata เข้าด้วยกันเพื่อสร้าง IDS/IPS ที่ยืดหยุ่นอย่างแท้จริงได้ อย่างไร โดยไม่ต้องเสียเงินจำนวนมากไปกับฮาร์ดแวร์ที่เป็นกรรมสิทธิ์ นั่นคือสิ่งที่เราจะสำรวจในบทความนี้ โดยผสมผสานองค์ประกอบระดับต่ำ (เคอร์เนล, คิว, C) กับเครื่องมือระดับสูง (Suricata, กฎ, MySQL, Memcached, pfSense)

แนวคิดพื้นฐานนั้นทรงพลังมาก: ใช้ประโยชน์จากข้อเท็จจริงที่ว่าเคอร์เนล (ดูวิธีการเพิ่มประสิทธิภาพเคอร์เนล Linux ) สามารถจัดคิวแพ็กเก็ตไปยังพื้นที่ผู้ใช้และปล่อยให้โปรแกรมที่กำหนดเองตัดสินใจว่าจะทำอย่างไรกับแพ็กเก็ตเหล่านั้น ซึ่งสามารถนำไปใช้ในการกรองทราฟฟิก (ไฟร์วอลล์ขั้นสูง, IPS) การกำหนดเส้นทางแบบไดนามิก หรือการบูรณาการตรรกะทางธุรกิจ (ฐานข้อมูล แคช การตรวจจับการโจมตีเว็บแอปพลิเคชัน VoIP เป็นต้น) และหากเราเพิ่ม Suricata เป็นเอ็นจิ้น IDS/IPS แบบหลายกระบวนการ เราก็จะได้ชุดค่าผสมที่แข็งแกร่งมากสำหรับสภาพแวดล้อมต่างๆ ตั้งแต่ห้องปฏิบัติการไปจนถึงศูนย์ข้อมูลที่มีปริมาณการใช้งานสูง

NFQUEUE และ Netfilter: ยกระดับไฟร์วอลล์ไปสู่พื้นที่ผู้ใช้

ในระบบ GNU/Linux ทั่วไป กฎของ Netfilter/iptables (หรือ nftables) มักถูกใช้เป็นนโยบายแบบคงที่ซึ่งจัดเก็บไว้ในพื้นที่เคอร์เนลทั้งหมดส่วนหน้าและอุปกรณ์ (รวมถึงโซลูชันจำนวนมากที่ใช้ Netfilter หรือ Packet Filter ของ BSD) จะจัดเก็บการกำหนดค่าไว้ในไฟล์ข้อความ XML หรือ SQLite และเมื่อมีการเปลี่ยนแปลงใดๆ เกิดขึ้น ระบบจะสร้างและโหลดกฎใหม่ วิธีนี้มีความยืดหยุ่น แต่ตรรกะยังคงเป็นเหมือนภาพรวมของไฟร์วอลล์ที่มีการปรับแต่งแบบไดนามิกเล็กน้อย (เช่น ขีดจำกัดการเชื่อมต่อต่อวินาที, conntrack, การจับคู่ประเทศ, เลเยอร์ 7 หากมี ฯลฯ)

สิ่งที่ NFQUEUE นำเสนอคือการเปลี่ยนแปลงครั้งสำคัญ: แทนที่เคอร์เนลจะเป็นผู้ตัดสินใจขั้นสุดท้ายเสมอ เราสามารถมอบหมายการตัดสินใจนั้นให้กับกระบวนการของผู้ใช้ได้เคอร์เนลจะจัดคิวแพ็กเก็ตไว้ในคิวที่มีหมายเลข และแอปพลิเคชันที่ใช้ไลบรารี libnetfilter_queue จะดึงแพ็กเก็ตนั้นมาวิเคราะห์ และส่งผลลัพธ์กลับมา: ยอมรับ ทิ้ง หรือแม้กระทั่งทำเครื่องหมายสำหรับการกำหนดเส้นทางตามนโยบาย มันเหมือนกับการมี "ผู้พิพากษา" ที่เขียนโปรแกรมได้ด้วยภาษา C, Python หรือ Perl อยู่บนไฟร์วอลล์

ข้อดีของเรื่องนี้คือ โปรแกรมของเราสามารถทำอะไรก็ได้ตามที่เราต้องการ ไม่ว่าจะเป็นการสอบถามข้อมูลจาก /dev/urandom, ฐานข้อมูล, เว็บเซอร์วิส, แคชแบบกระจาย หรืออัลกอริทึมที่ซับซ้อนก่อนที่จะตอบกลับไปยังเคอร์เนล ในแง่ของสถาปัตยกรรม ไฟร์วอลล์จะไม่ใช่แค่ชุดกฎคงที่ธรรมดาอีกต่อไป แต่จะกลายเป็นไปป์ไลน์ที่ Netfilter, คิว และแอปพลิเคชันของผู้ใช้ทำงานร่วมกันได้อย่างลงตัวเหมือนชิ้นส่วนของจิ๊กซอว์

NFQUEUE ประกอบด้วยสองส่วน: เป้าหมาย NFQUEUE ใน iptablesซึ่งส่งแพ็กเก็ตไปยังคิวเฉพาะ และไลบรารีผู้ใช้ libnetfilter_queueซึ่งอนุญาตให้คุณอ่านแพ็กเก็ตเหล่านั้นและออกคำตัดสิน มันไม่ใช่โปรแกรมดักจับแพ็กเก็ตแบบง่ายๆ เหมือน tcpdump: ที่นี่เราสามารถตัดสินเส้นทางที่แพ็กเก็ตเดินทางได้โดยตรง

การตั้งค่า iptables ขั้นพื้นฐานด้วย NFQUEUE

จากมุมมองของ iptables การใช้ NFQUEUE นั้นค่อนข้างตรงไปตรงมา: คุณเพิ่มกฎลงในเชนที่คุณสนใจเพื่อส่งแพ็กเก็ตที่ตรงตามเกณฑ์บางอย่าง (IP ต้นทาง/ปลายทาง พอร์ต สถานะ โมดูลเพิ่มเติม เช่น GeoIP หรือเลเยอร์ 7 หากมี ฯลฯ) ไปยังคิว

ตัวอย่างเช่น หากเราต้องการส่ง ping ทั้งหมดที่เข้ามายังโฮสต์ไปยัง NFQUEUE:

iptables -I INPUT -p icmp -j NFQUEUE

คำสั่งนี้จะส่งแพ็กเก็ต ICMP ที่เข้ามาไปยังคิว 0 (เว้นแต่จะระบุไว้เป็นอย่างอื่น) เราสามารถระบุคิวอื่นได้ด้วยคำสั่งเช่น`--queue-num 3`เมื่อแสดงรายการกฎด้วยตัวนับ (`iptables -L -n -v -x`) เราจะเห็นตัวนับเพิ่มขึ้น ซึ่งบ่งชี้ว่ามีแพ็กเก็ตถูกจัดคิวรายละเอียดที่สำคัญ: หากมีแพ็กเก็ตอยู่ในคิวและไม่มีกระบวนการของผู้ใช้ดึงและประมวลผลแพ็กเก็ตเหล่านั้น พฤติกรรมเริ่มต้นคือการปฏิเสธแพ็กเก็ตเหล่านั้น ดังนั้นความล้มเหลวของแอปพลิเคชันจึงส่งผลให้การรับส่งข้อมูลถูกบล็อกตามที่ออกแบบไว้

การเขียนโปรแกรมโดยใช้ libnetfilter_queue: ตัวอย่าง "hello world" ในภาษา C

ในการเข้าร่วมคิวจากพื้นที่ผู้ใช้ จะใช้ไลบรารี libnetfilter_queue (ซึ่งอาศัย libnfnetlink อีกที) บนระบบปฏิบัติการอย่าง Debian เพียงแค่ติดตั้งแพ็กเกจสำหรับการพัฒนา:

apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc

โครงสร้างพื้นฐานของโปรแกรมขั้นต่ำที่รับแพ็กเก็ตอยู่เสมอนั้นประกอบด้วยขั้นตอนที่ชัดเจนไม่กี่ขั้นตอน ได้แก่เปิดไลบรารี ยกเลิกการผูกแฮนด์เลอร์ที่มีอยู่ ผูกกับโปรโตคอล AF_INET สร้างคิวด้วยฟังก์ชันเรียกกลับ กำหนดโหมดการคัดลอก และเข้าสู่ลูปรับ ฟังก์ชันเรียกกลับจะถูกเรียกใช้สำหรับแต่ละแพ็กเก็ตในคิว โดยจะดึง ID ออกมาและส่งคืนค่าผลลัพธ์

ในทางปฏิบัติ ขั้นตอนการทำงานจะเป็นดังนี้: `nfq_open` เพื่อรับแฮนเดิล, `nfq_unbind_pf` เพื่อล้างแฮนเดิล, `nfq_bind_pf` เพื่อเชื่อมโยงกับ AF_INET, `nfq_create_queue` เพื่อลงทะเบียนฟังก์ชันเรียกกลับในคิว 0, `nfq_set_mode` เพื่อระบุว่าเราต้องการเมตาเดตาหรือแพ็กเก็ตทั้งหมด, วนลูปด้วย `recv()` กับตัวอธิบาย และ `nfq_handle_packet` เพื่อประมวลผลแต่ละแพ็กเก็ตเมื่อสิ้นสุดการทำงาน คิวจะถูกทำลายด้วย `nfq_destroy_queue` และแฮนเดิลจะถูกปิดด้วย `nfq_close`

ตัวอย่าง "hello world" แบบนี้ช่วยให้สามารถวัดผลกระทบของ NFQUEUE ได้อย่างชัดเจน หากเราคอมไพล์ตัวอย่างด้วยสิ่งต่อไปนี้:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

และหากเราจัดคิวทราฟฟิกจาก iperf (ตัวอย่างเช่น พอร์ต TCP 5001 ใน INPUT และ OUTPUT) เราจะเห็นว่าโค้ดที่รับแพ็กเก็ตโดยตรงนั้นแทบไม่มีผลต่อประสิทธิภาพบนเครือข่ายกิกะบิตเลย อย่างไรก็ตาม มีรายละเอียดสำคัญอย่างหนึ่งคือ การพิมพ์ข้อมูลในฟังก์ชันเรียกกลับ (printf, fflush เป็นต้น) จะทำให้ปริมาณงานลดลงอย่างมาก ดังที่เห็นได้จากการเปรียบเทียบ iperf ที่มีและไม่มีการดีบักหน้าจอ

ตัวเลือก NFQUEUE ขั้นสูง: บายพาส, บาลานซ์ และแฟล็กอิน

NFQUEUE มีตัวเลือก iptables ที่น่าสนใจหลายอย่างซึ่งปรับเปลี่ยนพฤติกรรมเริ่มต้นของคิว และควรทราบก่อนนำไปใช้งานในสภาพแวดล้อมการผลิตหรือสภาพแวดล้อมที่มีประสิทธิภาพสูง เนื่องจากตัวเลือกเหล่านี้ส่งผลต่อ วิธีการจัดการ ความล้มเหลวของแอปพลิเคชันของผู้ใช้หรือการเติมคิว

คำ สั่ง `--queue-bypass`ช่วยให้คุณมั่นใจได้ว่า หากไม่มีกระบวนการใดกำลังรอรับแพ็กเก็ตอยู่ แพ็กเก็ตจะไม่ถูกทิ้ง แต่จะถูกส่งต่อไปยังฮอปถัดไปในเชน iptables แทน ซึ่งอาจมีประโยชน์หากคุณต้องการให้ระบบ "เปิดค้างไว้" เมื่อบริการของผู้ใช้ไม่พร้อมใช้งาน แม้ว่าในมุมมองด้านความปลอดภัยแล้ว มันก็เป็นดาบสองคมอยู่ดี

ตัวเลือก`--queue-balance`ช่วยให้คุณกระจายแพ็กเก็ตไปยังคิวต่างๆ ได้หลายคิว (เช่น จาก 0 ถึง 3) จากนั้นจึงมีกระบวนการหรือเธรดอิสระหลายตัวที่รับแพ็กเก็ตจากแต่ละคิวโค้ดของ Netfilter จะรับประกันว่าแพ็กเก็ตจากโฟลว์เดียวกันจะไปอยู่ในคิวเดียวกันเสมอ ซึ่งช่วยลดความซับซ้อนในการรักษาความสอดคล้องในตรรกะการตัดสินใจได้อย่างมาก

นอกจากนี้ยังมี โหมด`--fail-open`ซึ่งควบคุมสิ่งที่เกิดขึ้นเมื่อคิวเต็มเนื่องจากกระบวนการของผู้ใช้ทำงานช้าเกินไป การเปิดใช้งานโหมดนี้จะทำให้เคอร์เนลยอมรับแพ็กเก็ตโดยตรงแทนที่จะทิ้งไป ซึ่งจะช่วยป้องกันการหยุดชะงักของการรับส่งข้อมูลจำนวนมาก อย่างไรก็ตาม นี่อาจเป็นปัญหาด้านความปลอดภัยได้เช่นกัน เพราะหากเราต้องการตัดสินใจเป็นรายกรณี การสูญเสียแพ็กเก็ตการตัดสินใจหมายถึงการไม่บรรลุเป้าหมายนั้น

เพื่อตรวจสอบว่าเกิดอะไรขึ้นกับคิวต่างๆ Netfilter จะแสดงข้อมูลในระบบไฟล์เสมือน/proc/net/netfilter/nfnetlink_queueซึ่งสามารถเรียกดูได้ง่ายจากสคริปต์หรือเครื่องมือตรวจสอบต่างๆ

การบูรณาการตรรกะทางธุรกิจ: การทดสอบด้วย Memcached และ MySQL

เมื่อกระบวนการ "hello world" อยู่ภายใต้การควบคุมแล้ว ขั้นตอนต่อไปที่เหมาะสมคือการเพิ่มฟังก์ชันเรียกกลับ (callback) ด้วยการเรียกใช้ระบบภายนอกการทดลองทั่วไปเกี่ยวข้องกับการตัดสินใจว่าจะยอมรับหรือปฏิเสธแพ็กเก็ตโดยพิจารณาจากว่าที่อยู่ IP ต้นทางปรากฏอยู่ในระบบแบ็กเอนด์ใด ๆ หรือไม่ เช่น ฐานข้อมูล MySQL หรือแคช Memcached

ในกรณีของ Memcached นั้น จะมีการติดตั้ง daemon (apt-get install memcached) และโหลดคีย์ เช่นauthorizedที่มีที่อยู่ IP ที่เราสนใจลงไป เราสามารถทำได้ด้วยคำสั่ง echo และ netcat ง่ายๆ จากนั้นตรวจสอบด้วยคำสั่ง get ว่าค่าถูกจัดเก็บอย่างถูกต้องหรือไม่ จากนั้น โปรแกรม NFQUEUE นอกจากจะได้รับ packet ID แล้ว ยังรับแพ็กเก็ตทั้งหมดโดยใช้NFQNL_COPY_PACKETดึงส่วนหัว IP (struct iphdr) และแปลงที่อยู่ต้นทางเป็นสตริงด้วย inet_ntop

เพื่อหลีกเลี่ยงการเสียเวลาในการเปิดการเชื่อมต่อกับแต่ละแพ็กเก็ตการเชื่อมต่อกับ Memcached จะถูกเริ่มต้นเพียงครั้งเดียวในเมธอดหลัก (memcached_create, memcached_server_list_append, memcached_server_push) และตัวจัดการจะถูกเก็บไว้ในตัวแปรส่วนกลาง ในฟังก์ชันเรียกกลับ จะมีการเรียก memcached_get พร้อมกับคีย์ที่ต้องการ ที่อยู่ IP ต้นทางจะถูกเปรียบเทียบกับค่าที่ได้รับ และหากตรงกัน จะส่งคืนค่า NF_ACCEPT มิฉะนั้นจะส่งคืนค่า NF_DROP หากไม่มีคีย์หรือมีข้อผิดพลาด แพ็กเก็ตจะถูกทิ้งตามนโยบายที่ระมัดระวัง

เมื่อใช้ iperf กลยุทธ์นี้จะลดปริมาณการรับส่งข้อมูลลงเหลือประมาณ140 เมกะบิตต่อวินาทีบนเครือข่ายกิกะบิตและพบว่าคิวเริ่มมีการสูญหาย (สังเกตได้จากสัญลักษณ์ภายในโค้ดเอง) กล่าวอีกนัยหนึ่ง การเรียกใช้บริการแคชต่อแพ็กเก็ตแต่ละครั้งนั้นมีค่าใช้จ่ายสูงมาก แม้ว่าจะยังคงใช้งานได้สำหรับปริมาณการรับส่งข้อมูลระดับปานกลางหากมีการปรับให้เหมาะสม

สำหรับ MySQL วิธีการจะคล้ายกันแต่ซับซ้อนกว่า: ติดตั้งไลบรารีเซิร์ฟเวอร์และไคลเอ็นต์ สร้างฐานข้อมูล (เช่น nfqueue) พร้อมตารางง่ายๆ ชื่อ authorized(ip varchar(50)) และแทรกที่อยู่ IP ที่อนุญาตเข้าไป ในโปรแกรม`mysql_init` และ `mysql_real_connect` จะถูกเรียกใช้ เมื่อเริ่มต้น และในฟังก์ชันเรียกกลับ จะมีการสร้างคำสั่ง SQL เช่น `select * from authorized where ip like 'xxxx'` หากคำสั่ง SQL ทำงานสำเร็จและพบแถว ระบบจะยอมรับแพ็กเกจนั้น มิฉะนั้นจะถูกทิ้ง

เมื่อเปิดใช้งานการแคชคำสั่ง SQL ของ MySQL ผลการทดสอบได้ความเร็วประมาณ188 เมกะบิตต่อวินาทีซึ่งลดลงเหลือ103 เมกะบิตต่อวินาทีเมื่อปิดใช้งานการแคชคำสั่ง SQL ตัวเลขเหล่านี้แม้จะห่างไกลจากระดับกิกะบิต แต่ก็แสดงให้เห็นว่า แม้แต่ในวิธีการที่เรียบง่ายที่สุด (แบบเธรดเดียว โดยไม่มีการปรับแต่ง)ก็สามารถจัดการปริมาณการรับส่งข้อมูลที่น่าพอใจได้โดยใช้การตัดสินใจที่ขับเคลื่อนด้วยฐานข้อมูลหรือการแคช

ประสิทธิภาพ การทำงานแบบมัลติเธรด และการใช้งาน CPU

การทดสอบด้วย iperf, Memcached และ MySQL แสดงให้เห็นอย่างชัดเจนว่าขีดจำกัดประสิทธิภาพไม่ได้ถูกกำหนดโดย NFQUEUE เองมากนัก แต่ถูกกำหนดโดยตรรกะที่เราเพิ่มเข้าไปในพื้นที่ผู้ใช้และวิธีการที่เรานำไปใช้ โปรแกรมที่ส่งค่าคืนเพียง NF_ACCEPT สามารถทำความเร็วได้เกือบ 1 กิกะบิตต่อวินาทีโดยไม่มีปัญหาใดๆ แต่ทันทีที่เราเพิ่มการเรียกใช้ I/O หรือเครือข่ายเข้าไป ความเร็วในการทำงานก็จะลดลง และ CPU ของเครื่อง NFQUEUE, daemon Memcached หรือ MySQL ก็จะถูกใช้งานจนถึงขีดจำกัด

จากมุมมองด้านสถาปัตยกรรม สิ่งนี้มีนัยสำคัญสองประการ ประการแรก ยืนยันว่าการมอบหมายการตัดสินใจเกี่ยวกับไฟร์วอลล์ให้กับแอปพลิเคชันของผู้ใช้สำหรับปริมาณการรับส่งข้อมูลจำนวนมากนั้นเป็นไปได้อย่างสมบูรณ์แบบ โดยคำนึงถึงต้นทุนที่แท้จริงของการเรียกใช้งานแต่ละครั้ง ประการที่สอง แสดงให้เห็นว่าเพื่อให้เข้าใกล้ขีดความสามารถสูงสุดของแพลตฟอร์ม ต้องพิจารณา การใช้ มัลติเธรดดิ้งหรือมัลติโปรเซสซิ่ง NFQUEUE อนุญาตให้กระจายการรับส่งข้อมูลไปยังคิวหลายคิว เราสามารถเปิดแอปพลิเคชันของเราหลายชุด โดยแต่ละชุดรับฟังคิวที่แตกต่างกัน และใช้ประโยชน์จากหลายคอร์โดยไม่ต้องยุ่งยากกับการใช้ pthreads หรือ fork จำนวนมาก

อีกหนึ่งวิธีปรับปรุงที่เห็นได้ชัดคือการจำกัดปริมาณการรับส่งข้อมูลที่จะผ่าน NFQUEUEในการทดสอบนั้น กระแสข้อมูล iperf ทั้งหมดถูกจัดคิวไว้ แต่ในสถานการณ์จริง เราสามารถจัดคิวเฉพาะแพ็กเก็ตที่มีสถานะ NEW เท่านั้น อนุญาตให้แพ็กเก็ต ESTABLISHED/RELATED ผ่านไปได้ และสงวนตรรกะที่ใช้ทรัพยากรมากไว้สำหรับการล็อกอินหรือรูปแบบที่น่าสงสัย

ท้ายที่สุดแล้ว การใช้งาน CPU และการออกแบบเธรดเป็นสิ่งสำคัญ: หากกระบวนการของผู้ใช้ล้มเหลว คิวจะเต็ม และเราต้องหันไปใช้วิธีการต่างๆ เช่น fail-open หรือ accept drops ซึ่งจะทำให้สูญเสียการควบคุมอย่างละเอียดบางส่วนที่วิธีการนี้มุ่งหวัง

การกำหนดเส้นทางแบบไดนามิกพร้อมตราสินค้า Netfilter

NFQUEUE ไม่ได้จำกัดอยู่แค่การ "ยอมรับ" หรือ "โยนทิ้ง" เท่านั้น แต่ยังสามารถใช้เพื่อกำหนดแฟล็ก Netfilter (fwmark) ให้กับแพ็กเก็ต และผสานรวมกับ ip rule และ iproute2เพื่อสร้างรูปแบบการกำหนดเส้นทางทางการเมืองแบบ VRF ที่มีความยืดหยุ่นสูงและมีน้ำหนักเบาได้อีกด้วย

โดยคร่าวๆ ขั้นตอนจะเป็นดังนี้: กำหนดตารางการกำหนดเส้นทางหลายตารางใน/etc/iproute2/rt_tablesเช่น ตารางแบบช้าและแบบเร็ว; กำหนดเส้นทางเริ่มต้นที่แตกต่างกันให้กับแต่ละตาราง (ตารางหนึ่งผ่านสายไฟเบอร์ และอีกตารางหนึ่งผ่านลิงก์ที่มีข้อจำกัดมากกว่า); ใช้กฎ ip เพื่อระบุว่าแพ็กเก็ตที่มี fwmark 1 ไปที่ตารางแบบเร็ว แพ็กเก็ตที่มี fwmark 2 ไปที่ตารางแบบช้า เป็นต้น; และสุดท้ายใช้ NFQUEUE เพื่อทำเครื่องหมายแพ็กเก็ตอย่างเหมาะสมก่อนที่จะส่งผลลัพธ์กลับมา

ในการกำหนดค่าคำตัดสินจากฟังก์ชันเรียกกลับ จะใช้`nfq_set_verdict2`ซึ่งคล้ายกับ `nfq_set_verdict` แต่ช่วยให้คุณสามารถกำหนดค่าคำตัดสินที่ `ip rule` จะเห็นได้ เมื่อรวมทั้งหมดนี้ คุณสามารถสร้างเราเตอร์ IP ที่ตัดสินใจว่าจะกำหนดเส้นทางไปยังที่ใดโดยอิงจากเกณฑ์ต่างๆ ได้ ตั้งแต่สิ่งที่ดูไร้สาระ เช่น ขนาดแพ็กเก็ตคู่/คี่ ไปจนถึงข้อมูลภายนอก เช่น อัลกอริทึมการคาดการณ์ปริมาณการรับส่งข้อมูล เหตุการณ์บนโซเชียลมีเดีย หรือสัญญาณจากระบบตรวจสอบ

ผลลัพธ์ที่ได้คือระบบที่เคอร์เนลยังคงส่งต่อแพ็กเก็ตในอัตราปกติ แต่เส้นทางที่แน่นอนของแต่ละโฟลว์นั้นถูกมอบหมายให้ซอฟต์แวร์ภายนอกซึ่งสามารถเปลี่ยนแปลงได้แบบเรียลไทม์โดยไม่ต้องแก้ไขกฎคงที่

NFQUEUE และ Suricata: ระบบป้องกันการบุกรุกระดับสูงใน GNU/Linux

ทั้งหมดที่กล่าวมาข้างต้นสามารถเขียนโปรแกรมด้วยมือได้ในภาษา C แต่เมื่อพูดถึงการตรวจจับการบุกรุกและการตรวจสอบแพ็กเก็ตเชิงลึก ตัวเลือกที่เหมาะสมมักจะเป็นการใช้เครื่องมือ IDS/IPS ที่มีประสิทธิภาพสูงนั่นคือจุดที่ Suricata เข้ามามีบทบาท ซึ่งถูกสร้างขึ้นมาเพื่อเป็นทางเลือกแบบมัลติโปรเซสแทน Snort โดยมีคุณสมบัติ IPS ตั้งแต่เริ่มต้น และเน้นหนักไปที่การใช้ประโยชน์จากคอร์ CPU จำนวนมากที่มีอยู่ในปัจจุบัน

Suricata ถูกเขียนขึ้นใหม่ทั้งหมดและเผยแพร่ภายใต้ใบอนุญาต GPLv2โดยมูลนิธิ Open Information Security Foundation (OISF) ดูแลทั้งเอนจินและระบบนิเวศของกฎและเอกสารประกอบที่ค่อนข้างครอบคลุม แตกต่างจาก Snort 2.x ซึ่งสืบทอดมาจากแกนหลักแบบเธรดเดียวและได้รับการปรับปรุงเพิ่มเติม Suricata ได้รับการออกแบบให้แบ่งภาระงานออกเป็นหลายเธรด ได้แก่ การจับภาพ การถอดรหัส การตรวจจับ และการส่งออก โดยใช้กลยุทธ์การแบ่งภาระงานที่แตกต่างกัน

ในระดับการทำงาน Suricata ให้การสนับสนุนIPv6 โดยตรง การตรวจสอบเลเยอร์ 7 (HTTP ขั้นสูงมากผ่านไลบรารี HTP) การจดจำโปรโตคอลที่ไม่ขึ้นกับพอร์ตการสร้างโฟลว์ขึ้นใหม่ และระบบตัวแปรเซสชัน (flowbits) ที่ทรงพลังมากเพื่อเชื่อมโยงขั้นตอนต่างๆ ของการโจมตีที่แพร่กระจายไปทั่วการเชื่อมต่อ TCP หลายรายการ

จุดเด่นเพิ่มเติมคือความเข้ากันได้กับกฎของ Snortและความสามารถในการใช้ชุดลายเซ็นทั้ง Sourcefire VRT และ Emerging Threats (เวอร์ชันฟรี ET Open และเวอร์ชันเชิงพาณิชย์ ET Pro) นอกจากนี้ยังส่งออกเหตุการณ์ในรูปแบบที่มีประโยชน์มาก (fast.log, JSON ใน eve.json) สำหรับการบูรณาการกับ SIEM, ELK, Splunk และระบบอื่นๆ

Suricata ในฐานะ IPS บน Linux: โหมดการจับภาพและ NFQUEUE

บนระบบ GNU/Linux นั้น Suricata สามารถทำงานได้ในโหมดต่างๆ ขึ้นอยู่กับวิธีการดักจับทราฟฟิก: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … แต่ละโหมดมีข้อดีและข้อกำหนดที่แตกต่างกัน ในระดับ IPS โดยเฉพาะ โหมดที่สำคัญที่สุดสองโหมดคือ NFQUEUE และ AF_PACKET

ใน โหมด NFQ (NFQUEUE)กระบวนการทำงานจะคล้ายกับที่อธิบายไว้ก่อนหน้านี้ คือ ชุดกฎ iptables จะส่งแพ็กเก็ตไปยังคิว จากนั้น Suricata ซึ่งทำงานในพื้นที่ผู้ใช้ จะอ่านจากคิวนั้น ตรวจสอบเนื้อหาตามกฎ และส่งผลลัพธ์กลับไปยังเคอร์เนล ได้แก่ NF_ACCEPT, NF_DROP หรือ NF_REPEAT โดยสามารถใช้ผลลัพธ์ที่สามเพื่อส่งแพ็กเก็ตกลับเข้าไปในตาราง iptables เดิมหลังจากเพิ่มเครื่องหมายหรือแก้ไขเพิ่มเติม

โหมดนี้มีความยืดหยุ่นสูงและง่ายต่อการใช้งานในโครงสร้างพื้นฐานที่มีอยู่เนื่องจากต้องแก้ไขกฎเฉพาะจุดเท่านั้น (เช่น FORWARD, INPUT, OUTPUT) และปล่อยให้ส่วนอื่นๆ เป็นไปตามเดิม ต้นทุนคือค่าใช้จ่ายเพิ่มเติมในการส่งแพ็กเก็ตขึ้นและลงผ่าน NFQUEUE ซึ่งส่งผลกระทบดังที่กล่าวไว้ข้างต้นหากปริมาณสูงมากหรือกฎใช้ทรัพยากรมาก

ใน โหมด AF_PACKETนั้น Suricata จะทำงานใกล้กับอินเทอร์เฟซเครือข่ายมากขึ้น โดยคัดลอกแพ็กเก็ตผ่านซ็อกเก็ต AF_PACKET วิธีนี้เร็วกว่ามากโดยไม่ต้องคัดลอกแพ็กเก็ตซ้ำแต่ต้องใช้ระบบที่ทำงานเป็นเกตเวย์ที่มีสองอินเทอร์เฟซ และต้องทำการบล็อกทราฟฟิกในระดับการส่งต่อระหว่าง NIC: แพ็กเก็ตที่จะถูกบล็อกจะไม่ถูกส่งผ่านจากอินเทอร์เฟซขาเข้าไปยังอินเทอร์เฟซขาออก

Suricata สามารถใช้งานร่วมกับ Netfilter ได้ทั้งสองโหมด แต่NFQUEUE เหมาะอย่างยิ่งในสถานการณ์ที่เราต้องการใช้ตรรกะของ iptables ทั้งหมด (นโยบาย ช่วง และกฎก่อนหน้า) ซ้ำ และส่งเฉพาะทราฟฟิกที่เราสนใจตรวจสอบอย่างละเอียดไปยัง Suricata เท่านั้น

การติดตั้ง Suricata ขั้นพื้นฐานจากซอร์สโค้ด

สำหรับผู้ที่ต้องการคอมไพล์ Suricata แทนการใช้แพ็กเกจ กระบวนการบนระบบปฏิบัติการแบบ Debian/Ubuntu นั้นเกี่ยวข้องกับการติดตั้งส่วนประกอบที่จำเป็นสำหรับการคอมไพล์ก่อน (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev เป็นต้น) ดาวน์โหลดไฟล์ tarball จากเว็บไซต์ทางการ และ เรียกใช้คำสั่ง . /configure, make, make install ตามขั้นตอนปกติ

ในระหว่างขั้นตอนการกำหนดค่า สคริปต์จะระบุว่าฟีเจอร์สนับสนุนใดบ้างที่เปิดใช้งานอยู่ เช่น AF_PACKET ใช่/ไม่ใช่, PF_RING, NFQUEUE ใช่/ไม่ใช่, NFLOG, IPFW, การสนับสนุน libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP เป็นต้น สิ่งสำคัญคือต้องตรวจสอบให้แน่ใจว่าNFQUEUE เปิดใช้งานอยู่ หากเราต้องการทำงานในโหมดนั้นและต้องแน่ใจว่าได้ค้นหาไลบรารีการจับภาพที่เราสนใจแล้ว

หลังจากติดตั้งไบนารีแล้ว คุณสามารถเรียกใช้คำสั่ง`make install-conf`เพื่อปรับใช้การกำหนดค่าเริ่มต้นไปยัง `/etc/suricata` และ`make install-rules`เพื่อดาวน์โหลดและวางชุดกฎภัยคุกคามที่เกิดขึ้นใหม่ไว้ใน `/etc/suricata/rules` จากนั้นสามารถอัปเดตชุดกฎเหล่านี้ได้โดยใช้เครื่องมือต่างๆ เช่น `suricata-update`

บนระบบ Red Hat/CentOS ตรรกะจะคล้ายกัน โดยใช้ yum หรือ dnf สำหรับการติดตั้ง dependency (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel เป็นต้น) แล้วจึงคอมไพล์ด้วยขั้นตอนเดียวกัน เพื่อประสิทธิภาพที่ดีขึ้น แนะนำให้ปิดใช้งาน LRO/GRO ในอินเทอร์เฟซการจับภาพโดยใช้ ethtool ด้วย เนื่องจากฟังก์ชัน offload เหล่านี้อาจส่งผลต่อการมองเห็นแพ็กเกจในระดับ IDS

การตั้งค่า Suricata: YAML, ตัวแปร และการทำงานแบบมัลติเธรด

การตั้งค่าหลักของ Suricata อยู่ใน ไฟล์ /etc/suricata/suricata.yamlเป็นไฟล์ YAML ที่อ่านง่ายและมีคำอธิบายประกอบอย่างละเอียด ซึ่งกำหนดทุกอย่างตั้งแต่เส้นทางของไฟล์บันทึกและชุดกฎ ไปจนถึงนโยบายของระบบปฏิบัติการเป้าหมายและพารามิเตอร์การทำงานแบบมัลติเธรด

หนึ่งในฟิลด์พื้นฐานคือ`default-log-dir`ซึ่งระบุตำแหน่งที่จะจัดเก็บไฟล์บันทึก (โดยค่าเริ่มต้นคือ `/var/log/suricata`) ภายใต้ส่วน `vars` จะมีตัวแปรต่างๆ เช่น `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` และ `SSH_PORTS` ซึ่งทำหน้าที่เป็นตัวย่อในกฎต่างๆ โดยปกติแล้ว `HOME_NET` จะถูกกำหนดค่าด้วยช่วงเครือข่ายท้องถิ่นที่เราต้องการปกป้อง ในขณะที่ `EXTERNAL_NET` โดยทั่วไปจะถูกกำหนดเป็น `!HOME_NET`

ส่วนสำคัญอีกส่วนหนึ่งคือhost-os-policyซึ่งจะบอก Suricata ว่าระบบปฏิบัติการใดควรใช้งานช่วง IP ใดบ้าง これにより Suricata สามารถปรับวิธีการประกอบ TCP หรือตีความพฤติกรรมของสแต็กเครือข่ายบางอย่างได้ทำให้ยากต่อการหลีกเลี่ยงโปรโตคอลโดยอาศัยความแตกต่างระหว่างสแต็ก (Windows กับ Linux เป็นต้น) สามารถกำหนดช่วง IP เฉพาะให้กับหมวดหมู่ต่างๆ เช่น Windows, Linux, BSD, Vista, Windows 2003 เป็นต้นได้

ในส่วนของการทำงานแบบมัลติเธรดนั้น ส่วนนี้ช่วยให้คุณสามารถปรับแต่งความสัมพันธ์ของ CPU และจำนวนเธรดการตรวจจับได้ โดยปกติแล้ว `set-cpu-affinity` จะถูกปิดใช้งาน ซึ่งจะทำให้ตัวจัดตารางเวลาของระบบกระจายเธรดไปยังคอร์ต่างๆ พารามิเตอร์ `detect-thread-ratio`ระบุจำนวนเธรดการตรวจจับที่จะสร้างขึ้นต่อคอร์ที่มีอยู่ โดยหากตั้งค่า `detect-thread-ratio: 1.5` บนเครื่องที่มี 8 คอร์ Suricata จะสร้างเธรดการตรวจจับ 12 เธรด รวมถึงเธรดการจับภาพและการจัดการด้วย

โมเดลทั้งหมดนี้จะสะท้อนให้เห็นในผลลัพธ์เมื่อเดมอนเริ่มทำงาน: จะเห็นเธรดการจับภาพ (เช่น pcap) และเธรดตรวจจับหลายเธรด นอกเหนือจากตัวจัดการโฟลว์และตัวจัดการสถิติสถาปัตยกรรมแบบหลายกระบวนการนี้เองที่ทำให้ Suricata สามารถปรับขนาดได้ดีกว่าเอนจิ้นแบบเธรดเดียวเมื่อเผชิญกับลิงก์ 10/40 Gbit/s

กฎและการอัปเดตลายเซ็นใน Suricata

Suricata ใช้ชุดกฎในการตรวจจับรูปแบบการโจมตี พฤติกรรมที่ผิดปกติ และการใช้โปรโตคอลในทางที่ผิด นอกเหนือจากการยอมรับกฎในรูปแบบ Snortแล้ว ระบบนิเวศที่พบได้บ่อยที่สุดคือ Emerging Threats: ET Open (ฟรี) และ ET Pro (เชิงพาณิชย์) ซึ่งมีกฎที่มุ่งเน้นไปที่ภัยคุกคามในปัจจุบัน

ระบบปฏิบัติการ Linux รุ่นใหม่ๆ หลายตัวมี เครื่องมือ `suricata-update`ซึ่งช่วยให้การจัดการกฎง่ายขึ้น โดยจะอัปเดตแหล่งข้อมูล เปิดใช้งานหรือปิดใช้งานผู้ให้บริการเฉพาะ และดาวน์โหลดชุดลายเซ็นเวอร์ชันล่าสุด ขั้นตอนการทำงานทั่วไปคือ ติดตั้ง `suricata-update` (เช่น ผ่าน pip) เรียกใช้ `suricata-update` ครั้งแรกเพื่อดาวน์โหลด ET Open แสดงรายการแหล่งข้อมูลด้วย `suricata-update list-sources` เปิดใช้งานแหล่งข้อมูลเพิ่มเติม เช่น `ptresearch/attackdetection`, `oisf/trafficid` หรือ `sslbl/ssl-fp-blacklist` และเรียกใช้ `suricata-update` อีกครั้งเพื่อสร้างไฟล์กฎใหม่

ไฟล์ suricata.yaml จะถูกปรับแต่งให้ชี้ไปยังเส้นทางของกฎที่ถูกต้อง จากนั้น Suricata จะเริ่มสร้างเหตุการณ์แจ้งเตือนซึ่งจะถูกบันทึกไว้ในfast.log (ข้อความที่อ่านง่าย) และ eve.json (JSON ที่มีโครงสร้างพร้อมข้อมูลที่สมบูรณ์มาก)รูปแบบหลังนี้มีประโยชน์อย่างยิ่งสำหรับการป้อนข้อมูลไปยังแดชบอร์ด ระบบการเชื่อมโยง หรือสคริปต์ที่กำหนดเอง

นอกเหนือจากลายเซ็นแล้ว Suricata ยังรวมเอาตัวถอดรหัสและตัวแยกวิเคราะห์สำหรับโปรโตคอลหลายตัวไว้ด้วย ทำให้ไม่ขึ้นอยู่กับพอร์ตมากนัก กล่าวคือ สามารถระบุทราฟฟิก HTTP ได้แม้ว่าจะผ่านพอร์ตที่ไม่เป็นมาตรฐาน ตรวจจับ SSH, TLS, DNS ฯลฯ ผ่านพอร์ตและระดับการห่อหุ้มที่แตกต่างกัน (รวมถึงอุโมงค์ IPv4/IPv6 แบบผสม)

การใช้งานจริง: ตั้งแต่การตรวจจับช่องโหว่ของเว็บไซต์ไปจนถึงการบล็อกอัตโนมัติ

หนึ่งในกรณีการใช้งานที่ต้องการมากที่สุดในสภาพแวดล้อมการโฮสติ้งหรือศูนย์ข้อมูลคือการตรวจจับความพยายามในการโจมตีช่องโหว่ในเว็บแอปพลิ เคชัน (เช่น WordPress และปลั๊กอินต่างๆ) แบบเรียลไทม์ และตอบสนองโดยอัตโนมัติ ซึ่งโดยปกติแล้วจะทำได้โดยการบล็อกหรือขึ้นบัญชีดำ IP ต้นทางในไฟร์วอลล์

Suricata ซึ่งขับเคลื่อนด้วยกฎที่ได้รับการปรับปรุงใหม่ สามารถจดจำรูปแบบการโจมตีเฉพาะเจาะจงต่อ URL พารามิเตอร์ เพย์โหลด HTTPและแม้แต่ลำดับคำขอที่ตรงกับช่องโหว่ที่รู้จัก ระบบ IDS สามารถทำงานในโหมดพาสซีฟ โดยรับทราฟฟิกผ่านการจำลองจากพอร์ตสวิตช์ (SPAN) แต่เพื่อให้สามารถทำงานเป็นระบบ IPS และบล็อกการโจมตีได้ จำเป็นต้องผสานรวมเข้ากับระนาบการส่งต่อข้อมูล

มีแนวทางทั่วไปสองวิธี: การตั้งค่า IDS เป็นบริดจ์ออนไลน์ เพื่อให้ทราฟฟิกผ่านเครื่องโดยตรง (โดยใช้ iptables, AF_PACKET หรือ PF ขึ้นอยู่กับแพลตฟอร์ม) หรือปล่อยให้โครงสร้างเครือข่ายเป็นเช่นเดิม แต่รวมการทำมิเรอร์เข้ากับการดำเนินการบนไฟร์วอลล์ส่วนกลางผ่าน API สคริปต์ หรือ NFQUEUEแนวทางแรกช่วยลดความหน่วงระหว่างการตรวจจับและการบล็อก แต่ต้องแลกมาด้วยการเพิ่มองค์ประกอบอีกตัว "ตรงกลาง" ของเครือข่าย ในขณะที่แนวทางที่สองให้ความยืดหยุ่นและความทนทานมากกว่า แต่ทำให้การจัดการซับซ้อนขึ้น

เป็นไปได้อย่างยิ่งที่ระบบตรวจจับการบุกรุก (IDS) จะตรวจจับความพยายามในการโจมตีปลั๊กอิน WordPress ที่มีช่องโหว่ และจากนั้นเพิ่มที่อยู่ IP ของผู้โจมตีลงในบัญชีดำของ iptables ไม่ว่าจะโดยตรงหรือผ่านส่วนประกอบที่เกี่ยวข้อง สามารถทำได้ผ่านเอาต์พุต JSON ของ Suricata และสคริปต์ที่เรียกใช้ iptables/nftablesหรือโดยการมอบหมายตรรกะบางส่วนให้กับ NFQUEUE ซึ่งตัวเอนจินเองหรือกระบวนการที่เกี่ยวข้องจะทำการตัดสินใจแบบเรียลไทม์โดยไม่ต้องรอให้รายการภายนอกได้รับการอัปเดต

วิธีนี้ช่วยให้คุณมุ่งเน้นไปที่ภัยคุกคามที่สำคัญจริงๆ (เช่น การโจมตีช่องโหว่ การพยายามยกระดับสิทธิ์ การสแกนที่รุนแรงมาก) โดยไม่สนใจหรือบันทึกเฉพาะข้อมูลที่ไม่สำคัญ เช่น การสแกนพอร์ตพื้นฐาน ซึ่งในหลายๆ บริบทนั้นไม่น่ากังวลแต่อย่างใด

Suricata บน Pfsense: ไฟร์วอลล์โอเพนซอร์สพร้อมระบบตรวจจับการบุกรุกและป้องกันการบุกรุก (IDS/IPS) ในตัว

ไม่ใช่ทุกคนที่จะสามารถหรือต้องการซื้อไฟร์วอลล์ระดับไฮเอนด์ที่เป็นกรรมสิทธิ์อย่าง Palo Alto ได้ ในหลายๆ สภาพแวดล้อม การเลือกใช้โซลูชันโอเพนซอร์สอย่าง pfSense และ Suricata นั้นดูน่าสนใจกว่า เพราะครอบคลุมทั้งความต้องการไฟร์วอลล์ขั้นสูง (multi-WAN, VLAN, VPN, NAT ฯลฯ) และระบบตรวจจับการบุกรุก/การบุกรุก (IDS/IPS)

Pfsense ซึ่งใช้ FreeBSD และ Packet Filter เป็นพื้นฐาน ทำงานได้ดีเป็นพิเศษกับสภาพแวดล้อมเสมือน (Proxmox, KVM เป็นต้น) ยกเว้นว่าแนะนำให้ใช้การ์ด E1000 แทน Virtioในเครื่อง KVM หากต้องการหลีกเลี่ยงปัญหาด้านประสิทธิภาพและการหยุดทำงานภายใต้ภาระงานหนัก เว้นแต่คุณจะปฏิบัติตามคำแนะนำของ Netgate (ปิดใช้งานการคำนวณ checksum ด้วยฮาร์ดแวร์ใน System > Advanced > Networking แล้วรีสตาร์ท โดยทราบว่าวิธีนี้อาจไม่เพียงพอเมื่อมีภาระงานสูงมาก)

ข้อกำหนดฮาร์ดแวร์ขั้นต่ำสำหรับห้องปฏิบัติการที่ใช้ Suricata บน Pfsense นั้นอาจไม่สูงมากนัก (ซีพียู 1 ตัว ความเร็ว 500 MHz, แรม 1 GB, ดิสก์ 4 GB) แต่สำหรับการใช้งานจริงจัง แนะนำให้ ใช้ซีพียูอย่างน้อย 2 ตัว, แรม 4 GB และพื้นที่จัดเก็บข้อมูล 16 GB ขึ้น ไป พร้อม ทั้งควรมีอินเทอร์เฟซเครือข่ายหลายตัว (หนึ่งตัวสำหรับ WAN, อีกหนึ่งตัวสำหรับ LAN และเพิ่มหากต้องการ WAN หลายตัวหรือ VLAN ที่ซับซ้อน)

การติดตั้ง pfSense นั้นรวดเร็วมาก: คุณบูตจากไฟล์ ISO ยอมรับข้อตกลงใบอนุญาต เลือกติดตั้ง เลือกภาษาและรูปแบบแป้นพิมพ์ ปล่อยให้การแบ่งพาร์ติชั่นเป็นแบบอัตโนมัติ (Auto UFS หากคุณจะใช้ดิสก์ทั้งหมด) และในไม่กี่นาที ระบบก็พร้อมสำหรับการบูตครั้งแรก คอนโซลมีเมนูสำหรับกำหนดอินเทอร์เฟซ รีสตาร์ท เรียกใช้เชลล์ ฯลฯ

ในห้องปฏิบัติการ เช่น ใน VirtualBox เป็นเรื่องปกติที่จะปิดใช้งานไฟร์วอลล์ของ Pfsense ชั่วคราวจากคอนโซลด้วยคำสั่ง pfctl -dเพื่อเข้าถึงเว็บอินเทอร์เฟซผ่าน WAN (ชื่อผู้ใช้ admin รหัสผ่าน pfsense) และดำเนินการตามวิซาร์ดเริ่มต้นให้เสร็จสมบูรณ์ ได้แก่ ข้อมูลทั่วไป เซิร์ฟเวอร์ NTP การกำหนดค่า WAN (DHCP มักจะเพียงพอในห้องปฏิบัติการ) LAN การเปลี่ยนรหัสผ่านผู้ดูแลระบบ และการใช้งานการกำหนดค่า

เมื่อการเข้าถึงเสถียรแล้ว คุณสามารถสร้างกฎในไฟร์วอลล์ WAN เพื่ออนุญาต HTTPS จากแหล่งใดก็ได้ไปยังที่อยู่ IP ของ pfsense โดยเพิ่มตัวคั่นที่สื่อความหมายเพื่อจัดระเบียบกฎให้เป็นระเบียบ (ตัวอย่างเช่น "การเข้าถึงไฟร์วอลล์") นอกจากนี้ ขอแนะนำให้ปิดใช้งานตัวเลือกในการบล็อกเครือข่ายส่วนตัวบน WANหากคุณอยู่ในสภาพแวดล้อมการทดสอบที่มีที่อยู่ RFC1918 เพื่อหลีกเลี่ยงการใช้คำสั่ง `pfctl -d` อย่างต่อเนื่อง

การติดตั้ง Suricata บน pfSense และภาพรวม

เมื่อติดตั้ง pfSense เสร็จเรียบร้อยแล้ว การติดตั้ง Suricata ก็ง่ายมาก เพียงแค่ไปที่System > Package Manager > Available Packagesค้นหา Suricata แล้วติดตั้งแพ็กเกจ กระบวนการนี้จะดาวน์โหลดไฟล์หลายไฟล์และอาจใช้เวลานานพอสมควร ขึ้นอยู่กับฮาร์ดแวร์ของคุณ แต่มีคำแนะนำอย่างละเอียดผ่านทางเว็บอินเทอร์เฟซ

เมื่อติดตั้งเสร็จแล้ว รายการ Suricata จะปรากฏในแท็บ Services ซึ่งคุณสามารถกำหนดค่าอินสแตนซ์ตามอินเทอร์เฟซ (WAN, LAN, VLAN ฯลฯ) เลือกชุดกฎที่จะใช้ เปิดใช้งานโหมด IDS หรือ IPSและปรับพารามิเตอร์ด้านประสิทธิภาพและการบันทึกข้อมูลได้ ตัวเลือกมีมากมาย (มากพอที่จะเขียนบทความทั้งบทความเกี่ยวกับการกำหนดค่า) แต่ข้อดีคือ งานหลายอย่างที่ใน Linux ต้องแก้ไขไฟล์ YAML ด้วยตนเองนั้น สามารถจัดการได้ด้วยแบบฟอร์มและช่องทำเครื่องหมาย

หมายเหตุสำคัญ: แม้ว่าการเปิดระบบบริหารจัดการ pfSense สู่ภายนอกโดยตรงอาจดูน่าสนใจในสภาพแวดล้อมห้องปฏิบัติการ แต่ในสภาพแวดล้อมการใช้งานจริง จำเป็นอย่างยิ่งที่จะต้องจำกัดการเข้าถึงเฉพาะที่อยู่ IP แบบคงที่ ใช้ VPN สำหรับการจัดการระยะไกล และหลีกเลี่ยงการเปิดเผยเว็บคอนโซลโดยเด็ดขาด pfSense มีความยืดหยุ่นสูง แต่ก็ต้องได้รับการดูแลเสมือนเป็นองค์ประกอบที่สำคัญอย่างยิ่งด้วย

เมื่อเปิดใช้งาน Suricata บน pfSense คุณจะได้สภาพแวดล้อมที่ทราฟฟิกไหลผ่าน pfSense เพื่อทำหน้าที่เป็นไฟร์วอลล์และ NAT จากนั้นSuricata จะตรวจสอบตามกฎของมันและสามารถบล็อกได้ในโหมด IPSการผสมผสานนี้ ซึ่งจัดการได้จากเว็บอินเทอร์เฟซเดียว ช่วยลดความซับซ้อนในการติดตั้งระบบป้องกัน DPI ในเครือข่ายขนาดเล็กและขนาดกลางได้อย่างมาก

ในการใช้งานหลายๆ ครั้ง ระบบนี้จะเสริมด้วยการเชื่อมต่อ Pfsense/Suricata เข้ากับ SIEM หรือแพลตฟอร์มบันทึกข้อมูลส่วนกลาง โดยใช้ประโยชน์จากรูปแบบเอาต์พุตที่มีโครงสร้างเพื่อเชื่อมโยงเหตุการณ์และตรวจจับแคมเปญที่กว้างขึ้น

การตรวจสอบเหตุการณ์และตัวอย่างบันทึกใน Suricata

เมื่อ Suricata ทำงานแล้ว เหตุการณ์ต่างๆ จะถูกบันทึกไว้ในพาธที่กำหนดโดย default-log-dir ซึ่งโดยปกติคือ/var/log/suricataไฟล์ fast.log ใช้รูปแบบข้อความกระชับที่มีการประทับเวลา รหัสกฎ การจัดประเภท และลำดับความสำคัญ เหมาะสำหรับการตรวจสอบอย่างรวดเร็วจากเทอร์มินัล (tail -f)

ตัวอย่างเช่น เมื่อพบการรับส่งข้อมูลที่มีค่าตรวจสอบความถูกต้องของ TCP ไม่ถูกต้อง เราอาจเห็นบรรทัดต่างๆ ดังนี้: การประทับเวลาพร้อมวันที่และเวลา ตามด้วยตัวระบุของกฎ (เช่น 1:2200074:1) ข้อความ "SURICATA TCPv4 invalid checksum" การจัดประเภท ลำดับความสำคัญ และคู่ IP/พอร์ตต้นทาง-ปลายทางการแจ้งเตือนประเภทนี้ช่วยให้สามารถระบุปัญหาความสมบูรณ์ของแพ็กเก็ตหรือความพยายามในการหลีกเลี่ยงได้อย่างรวดเร็ว

ไฟล์ eve.json ประกอบด้วยเหตุการณ์ต่างๆ ในรูปแบบ JSON โดยมีฟิลด์ต่างๆ เช่น เวลา, ประเภทเหตุการณ์, IP ต้นทาง, IP ปลายทาง, พอร์ตต้นทาง, พอร์ตปลายทาง, โปรโตคอล และไฟล์ย่อยการแจ้งเตือนที่มีการดำเนินการ, GID, รหัสลายเซ็น, Rev, ลายเซ็น, หมวดหมู่ และความรุนแรง รูปแบบนี้สามารถนำเข้าได้อย่างง่ายดายด้วย Logstash, Fluentd, Filebeat หรือตัวแทนบันทึกอื่นๆทำให้สามารถวิเคราะห์ข้อมูลได้ละเอียดกว่าการใช้ข้อความธรรมดาเพียงอย่างเดียว

เมื่อใช้งาน Suricata บนเซิร์ฟเวอร์แบบมัลติคอร์ (เช่น 8 คอร์) การบีบอัดเธรดจะเห็นได้ชัดเจนในเครื่องมือต่างๆ เช่น htop ในโหมดเธรด โดยจะแสดงเธรดการจับภาพหนึ่งเธรดขึ้นไป (pcap, AF_PACKET หรือ NFQ) และเธรดการตรวจจับจำนวนมากที่กระจายอยู่ทั่วคอร์การปรับอัตราส่วนเธรดการตรวจจับและความสัมพันธ์ของ CPU สามารถส่งผลกระทบอย่างมากต่อปริมาณงานและความหน่วงเมื่อปริมาณการรับส่งข้อมูลใกล้ถึงขีดจำกัดของแพลตฟอร์ม

ก่อนที่จะนำไปใช้งานจริง ควรใช้เวลาปรับแต่งชุดกฎที่เปิดใช้งาน อย่างละเอียด เพื่อหลีกเลี่ยงการแจ้งเตือนผิดพลาดจำนวนมากที่อาจปิดกั้นการรับส่งข้อมูลที่ถูกต้อง หรือทำให้บันทึกข้อมูลรกเกินไป Suricata-update อนุญาตให้คุณปิดใช้งานหมวดหมู่ทั้งหมดหรือกฎแต่ละข้อ เพื่อหาจุดสมดุลที่เหมาะสมระหว่างความละเอียดอ่อนและการใช้งาน

แอปพลิเคชันพิเศษ: VoIP, การวิเคราะห์เสียง และ NFQUEUE สำหรับงานสร้างสรรค์

นอกเหนือจากการใช้งานแบบดั้งเดิม (การปกป้องบริการเว็บ การตรวจจับมัลแวร์ การวิเคราะห์ DDoS) แล้ว การทำงานร่วมกันของ Netfilter และ NFQUEUE ยังช่วยให้สามารถสร้างสรรค์โซลูชันที่น่าสนใจในด้านต่างๆ เช่น VoIP ได้อีกด้วย ตัวอย่างเช่น สามารถตั้งค่าตัวกรองป้องกัน SPIT (สแปมผ่านโทรศัพท์ IP) หรือระบบเซ็นเซอร์คำหยาบในสตรีม RTP ได้

แนวคิดคือ: ระบุทราฟฟิก RTP โดยใช้พอร์ตหรือการจดจำโปรโตคอล แล้วส่งไปยัง NFQUEUE; จากแอปพลิเคชันของผู้ใช้สร้างสตรีม RTP ขึ้นใหม่โดยใช้ไลบรารีเช่น librtpแยกเสียงในรูปแบบ WAV แล้วส่งไปยังเอนจิ้นการจดจำคำหลัก (wordspotting) เช่น ไลบรารีการสังเคราะห์หรือการจดจำที่ให้บริการโดยบุคคลที่สาม

จากคำที่ตรวจพบ กระบวนการ NFQUEUE สามารถตัดสินใจอนุญาต บล็อก หรือแม้กระทั่งเปลี่ยนแปลงการเล่นโดยการแทรกเสียงบี๊บเข้าไปในสตรีมได้ แม้ว่าการเปลี่ยนแปลงดังกล่าวจะต้องการการควบคุม RTCP ลำดับแพ็กเก็ต และจังหวะเวลาที่แม่นยำมาก ซึ่งเกือบจะเป็นวิธีการโจมตีแบบคนกลาง (man-in-the-middle) มันไม่ใช่เรื่องง่าย แต่ในทางทฤษฎีแล้วสามารถทำได้โดยสมบูรณ์โดยใช้ระบบคิวและระบบตัดสินแบบเดียวกัน

จริงอยู่ที่บางส่วนของกระบวนการนี้สามารถทำได้โดยใช้โปรแกรมดักจับข้อมูล (sniffer) ที่ส่งข้อมูลไปยังโปรเซสเซอร์ภายนอก แล้วดำเนินการกับสัญญาณ SIP หรือผ่านทาง SBC (เช่น Asterisk, Kamailio เป็นต้น) แต่ความแตกต่างของการใช้ NFQUEUE คือการดำเนินการกับโฟลว์ RTP สามารถทำได้ทันทีและโดยตรงโดยไม่ต้องประสานงานกับส่วนประกอบหลายส่วน หรือรอให้เลเยอร์การส่งสัญญาณเสร็จสิ้นการโทร

สถานการณ์เหล่านี้แสดงให้เห็นอย่างชัดเจนถึงศักยภาพของการผสมผสานระหว่าง GNU/Linux + Netfilter + Suricata + ไลบรารีของบุคคลที่สาม: มันไม่ใช่แค่การบล็อกพอร์ตและที่อยู่ IP เท่านั้น แต่ยังเกี่ยวกับการจัดการการตัดสินใจด้านการจราจรที่ซับซ้อนแบบเรียลไทม์โดยใช้ระบบนิเวศซอฟต์แวร์ฟรี 100%

เมื่อพิจารณาภาพรวมทั้งหมด ตั้งแต่โปรแกรม C ขนาดเล็กที่รับแพ็กเก็ตอยู่เสมอ ไปจนถึงการใช้งาน Suricata แบบมัลติโปรเซสที่ผสานรวมกับ NFQUEUE, Pfsense, ฐานข้อมูล และแคช จะเห็นได้ถึงความยืดหยุ่นที่เทคโนโลยีชุดนี้มอบให้ในการสร้างทุกสิ่ง ตั้งแต่ไฟร์วอลล์แบบไดนามิกอย่างง่าย ไปจนถึงสถาปัตยกรรม IDS/IPS ระดับศูนย์ข้อมูล พร้อมความสามารถในการตรวจสอบเชิงลึกอย่างแท้จริง และการตอบสนองอัตโนมัติต่อการโจมตีที่ซับซ้อนมากขึ้นเรื่อยๆ