Packet Flow ใน PAN-OS ทีละขั้น ทำไม Security Policy ถูกตรวจซ้ำ

เวลาที่กฎ "ควรจะ match" แต่ traffic log กลับบอกอีกอย่าง วิธีที่เร็วที่สุดคือรู้ว่าไฟร์วอลล์ PAN-OS ตัดสินใจตามลำดับใดครับ Palo Alto Networks อธิบายลำดับนี้ไว้ในบทความฐานความรู้ Packet Flow Sequence in PAN-OS บทความนี้คือบันทึกของผมจากเอกสารดังกล่าว แบ่งเป็นหกขั้น แล้วต่อด้วยความหมายของลำดับนี้เวลาแก้ปัญหาครับ

1. ขาเข้า (Ingress)

ไฟร์วอลล์อ่านแพ็กเก็ตในชั้นที่ 2, 3 และ 4 และทิ้งแพ็กเก็ตที่ผิดรูปแบบ ในชั้นที่ 2 จะระบุ logical interface ขาเข้าจากพอร์ต แท็ก 802.1Q และ MAC address ปลายทาง ถ้าไม่ตรงกับ interface ใดเลย แพ็กเก็ตจะถูกทิ้งและตัวนับจะเพิ่มขึ้น ในชั้นที่ 3 จะตรวจ IP header หาปัญหา เช่น header ถูกตัดสั้น checksum ผิด หรือรูปแบบอย่าง "Land attack" และ "Ping of death" ส่วนในชั้นที่ 4 จะตรวจ header ของ TCP และ UDP หาการถูกตัดสั้น checksum ผิด พอร์ตเป็นศูนย์ และชุด flag ที่ไม่ถูกต้อง

ในขั้นนี้ยังมีอีกสองเรื่อง ทราฟฟิกที่มาทาง tunnel แบบ IPsec หรือ SSL-VPN จะถูกถอด tunnel แล้วใช้ tunnel interface เป็น interface ขาเข้าใหม่ ก่อนถูกอ่านซ้ำอีกรอบ ส่วน IP fragment จะถูกประกอบกลับแล้วส่งกลับไปให้ตัวอ่านแพ็กเก็ต ถ้า fragment ซ้อนทับกันหรือมีข้อผิดพลาดในการแบ่ง fragment แพ็กเก็ตจะถูกทิ้ง

2. ค้นหาและสร้าง session (slowpath)

ไฟร์วอลล์ค้นหา flow ในตาราง session ด้วยคีย์ 6 ค่า ได้แก่ IP ต้นทาง IP ปลายทาง พอร์ตต้นทาง พอร์ตปลายทาง โปรโตคอล และ security zone (ได้จาก interface ขาเข้า) สำหรับทราฟฟิกที่ไม่มีพอร์ตจะใช้ฟิลด์อื่นแทน เช่น ICMP ใช้ identifier และ sequence number ถ้ายังไม่มี session แพ็กเก็ตจะเข้าสู่ slowpath ซึ่งเป็นที่ที่การตัดสินใจที่ใช้ทรัพยากรมากเกิดขึ้นเพียงครั้งเดียวครับ

• zone protection ซึ่งเลือกตาม zone ขาเข้า
• สถานะ TCP แพ็กเก็ต TCP แรกที่ไม่ใช่ SYN จะถูกทิ้งโดยค่าเริ่มต้น และ SYN flood จะถูกจัดการด้วย SYN cookies หรือ Random Early Drop (RED ซึ่งเป็นค่าเริ่มต้น)
• การส่งต่อ interface และ zone ขาออกขึ้นกับโหมดของ interface ในโหมด layer 3 จะใช้ตาราง forwarding เป็นตัวกำหนด ส่วนในโหมด tap แพ็กเก็ตจะถูกทิ้ง
• NAT policy ซึ่งใช้เฉพาะโหมด layer 3 และ virtual wire ถ้าเป็น destination NAT จะมีการค้นหาเส้นทางรอบที่สอง และถ้าจัดสรร source NAT ไม่สำเร็จ แพ็กเก็ตจะถูกทิ้ง
• User-ID เพื่อจับคู่ IP ต้นทางกับผู้ใช้และกลุ่ม
• DoS protection policy ซึ่งบทความระบุว่าถูกค้นหาก่อน security policy ตั้งแต่ PAN-OS 7.0.2 และ 6.1.7
• security policy โดยที่ application ยังเป็น "any" ถ้า match กฎที่ deny หรือไม่ match กฎใดเลย แพ็กเก็ตจะถูกทิ้ง

ถ้าทราฟฟิกได้รับอนุญาต ไฟร์วอลล์จะดึง session จาก free pool (ขั้นนี้ล้มเหลวได้เมื่อถึงขีดจำกัด) แล้ว session จะเปลี่ยนสถานะจาก INIT เป็น OPENING และเป็น ACTIVE เมื่อ flow ทั้งสองทิศทางถูกเพิ่มลงในตารางค้นหาแล้วครับ

คำว่า "ไม่ match กฎใดเลย" แทบไม่เคยว่างเปล่าจริง ๆ เพราะท้าย rulebase มีกฎที่กำหนดไว้ล่วงหน้าสองข้อ ซึ่งอนุญาตทราฟฟิกภายใน zone เดียวกันทั้งหมดและปฏิเสธทราฟฟิกข้าม zone ทั้งหมด และกฎจะถูกเทียบตามลำดับ โดยใช้กฎแรกที่ match

3. Fastpath

แพ็กเก็ตถัดไปของ session เดียวกันไม่ต้องผ่าน slowpath อีก แพ็กเก็ตของ session ที่อยู่ในสถานะ discard เช่น หลังเปลี่ยน policy เป็น deny หรือหลังตรวจพบภัยคุกคาม จะถูกทิ้ง สำหรับ session ที่ active ไฟร์วอลล์จะต่ออายุ timeout เริ่มตัวจับเวลา half-close หรือ time-wait เมื่อเห็น TCP FIN หรือ RST แปลงที่อยู่ตาม NAT และประกอบ TCP ส่วนแพ็กเก็ตที่มีข้อมูลจะถูกส่งต่อไประบุแอปพลิเคชันและตรวจเนื้อหา

4. App-ID

App-ID ตรวจหากฎ application override ก่อน ถ้า match แอปพลิเคชันจะถูกกำหนดทันทีและ session นั้นจะข้ามการตรวจเนื้อหา หน้า Application Override Policy ระบุว่ากฎแบบนี้ข้ามการประมวลผลชั้นที่ 7 และการตรวจภัยคุกคาม ถ้าไม่ match App-ID จะระบุแอปพลิเคชันจาก signature และถ้า signature ยังสรุปไม่ได้ ก็จะใช้ decoder และ heuristic แทน

เมื่อรู้แอปพลิเคชันแล้ว security policy จะถูกตรวจอีกครั้ง คราวนี้ด้วยแอปพลิเคชันจริงครับ ถ้าเปิด log ตอนเริ่ม session ไว้ ไฟร์วอลล์จะเขียน traffic log ทุกครั้งที่ App-ID เปลี่ยนระหว่าง session ทราฟฟิกที่ได้รับอนุญาตจะได้ QoS class ในขั้นนี้ด้วย และสำหรับ SSL กับ SSH จะมีการค้นหา decryption policy

5. ตรวจเนื้อหา (Content inspection)

ตัวถอดรหัสโปรโตคอลตรวจ flow และมองหาแอปพลิเคชันที่ทำ tunnel ถ้าแอปพลิเคชันเปลี่ยน เช่น พบแอปพลิเคชันหนึ่งทำงานอยู่ภายในอีกแอปหนึ่ง security policy จะถูกตรวจอีกรอบ จากนั้น security profile (antivirus, vulnerability protection, URL filtering และอื่น ๆ) จะถูกใช้ตามกฎที่ match และถ้าตรวจพบสิ่งที่ตั้ง action เป็น block ทราฟฟิกจะถูกทิ้ง ถ้าใช้ SSL forward proxy หรือ SSH decryption แพ็กเก็ตจะถูกเข้ารหัสกลับก่อนไปต่อ

6. ส่งต่อและขาออก (Egress)

ไฟร์วอลล์ทำ QoS shaping แบ่ง fragment ถ้า MTU ขาออกต้องการและแพ็กเก็ตอนุญาตให้แบ่งได้ เข้ารหัสด้วย IPsec หรือ SSL-VPN ถ้า interface ขาออกเป็น tunnel แล้วส่งแพ็กเก็ตออกทาง interface จริง

ทำไมลำดับนี้จึงสำคัญ

• NAT policy ถูกประเมินก่อน security policy แต่ security policy จะ match ด้วยที่อยู่ ก่อน NAT และ zone หลัง NAT (NAT Policy Overview) ส่วนการแปลงที่อยู่จริงเกิดตอนขาออก การเขียนกฎด้วยที่อยู่ที่แปลงแล้ว หรือด้วย zone ก่อน NAT จึงเป็นสาเหตุที่พบบ่อยที่กฎไม่ match
• การตรวจ security policy ครั้งแรกใช้แอปพลิเคชัน "any" กฎที่อนุญาตเฉพาะ ssl จึงยังปล่อยให้ TCP handshake ผ่านได้ และ session จะถูกตัดสินอีกครั้งเมื่อ App-ID รู้ว่าเป็นแอปพลิเคชันอะไร
• ใน session เดียว policy อาจถูกตรวจได้ถึงสามครั้ง คือ ตอนสร้าง session หลัง App-ID และเมื่อแอปพลิเคชันเปลี่ยนระหว่างตรวจเนื้อหา
• application override คือการแลกเปลี่ยน เราเลือกแอปพลิเคชันเอง แต่ session นั้นจะไม่ได้รับการตรวจชั้นที่ 7 และการป้องกันภัยคุกคาม
• การ "allow" ใน rulebase ยังขึ้นกับขั้นก่อนหน้า แพ็กเก็ตที่ถูกทิ้งโดย zone protection การตรวจ TCP SYN หรือ DoS protection จะไปไม่ถึง security policy เลย จึงไม่ปรากฏเป็นการ deny ของ policy

จับคู่ขั้นตอนกับเครื่องมือ

การรู้ว่าขั้นไหนเป็นผู้ตัดสินใจ ช่วยบอกได้ว่าควรเริ่มดู log ตัวนับ หรือ capture ตัวไหนก่อนครับ เครื่องมือในตัวหลายอย่างเข้ากับแต่ละขั้นได้ดี

• คำถามเรื่อง policy: คำสั่ง test security-policy-match ตรวจว่ากฎใดจะ match กับค่าที่เราใส่ ส่วนการทดสอบ Security Policy Match ในหน้าเว็บจะถามหา zone From และ To ด้วย และแสดงกฎที่อาจ match ทั้งหมดจนถึงกฎ allow แรกได้ ให้ใส่ที่อยู่ก่อน NAT และ zone หลัง NAT ซึ่งเป็นมุมมองเดียวกับที่ rulebase ใช้
• การทิ้งแพ็กเก็ตก่อนถึง policy: global counter ที่กรองเฉพาะต้นทางและปลายทางหนึ่งคู่ จะแสดงว่า dataplane ทำอะไรกับแพ็กเก็ตบ้าง บทความฐานความรู้ How to check global counters for a specific source and destination IP address ใช้คำสั่ง show counter global filter packet-filter yes delta yes และเพิ่ม severity drop เพื่อดูเฉพาะการทิ้ง
• แพ็กเก็ตหายไปตรงไหน: custom packet capture มีสี่ stage คือ receive (แพ็กเก็ตเข้าถึง dataplane) firewall (match session หรือสร้าง session ได้) transmit (แพ็กเก็ตออกจาก dataplane) และ drop (การประมวลผลเจอข้อผิดพลาดและทิ้งแพ็กเก็ต) แพ็กเก็ตที่เห็นใน receive แต่ไม่เคยเห็นใน firewall แปลว่าหยุดก่อนจะมี session ซึ่งชี้กลับไปที่ขั้นที่ 1 หรือ slowpath

เมื่ออ่านตามลำดับนี้ packet flow จะไม่ใช่แผนภาพที่ต้องท่องจำอีกต่อไป แต่กลายเป็น checklist คือหาให้เจอว่าเป็นขั้นไหน แล้วอ่านหลักฐานที่ขั้นนั้นทิ้งไว้ครับ