ThaiCERT: Thai Computer Emergency Response Team ศูนย์ประสานงานการรักษาความปลอดภัยคอมพิวเตอร์ ประเทศไทย

การสร้าง rule สำหรับไฟร์วอลล์
เรียบเรียงโดย : ภูวดล ด่านระหาญ
เผยแพร่เมื่อ : 4 ธันวาคม 2544

เป็นที่ทราบกันดีอยู่แล้วว่า ไฟร์วอลล์มีหน้าที่หลักในการกรอง (filter) ข้อมูลเฉพาะส่วนที่ได้รับอนุญาตเท่านั้น ดังนั้นการเขียนกฏหรือ rule สำหรับไฟร์วอลล์จึงเป็นเรื่องที่สำคัญอย่างยิ่ง การสร้าง rule ของไฟร์วอลล์ที่ผิดพลาดจะทำให้ไฟร์วอลล์ (ทั้งราคาแพงและใช้งานฟรี) ทั้งหลายไม่สามารถช่วยป้องกันเครือข่ายให้รอดพ้นจากการถูกบุกรุกหรือโจมตีได้อย่างแน่นอน แต่ก่อนอื่น ผู้ดูแลไฟร์วอลล์จะต้องมั่นใจว่าเครื่องไฟร์วอลล์นั้นมีความปลอดภัยในระดับโฮสต์อยู่แล้ว (host based security) เพราะถึงแม้ว่า rule ที่สร้างขึ้นจะสามารถป้องกันเครื่องอื่นๆ ภายในเครือข่ายได้ แต่ถ้าเครื่องไฟร์วอลล์เองไม่สามารถทนต่อการบุกรุกได้ก็เป็นจุดที่อันตรายไม่ยิ่งหย่อนไปกว่า rule ที่ผิดพลาดแต่อย่างใด

Firewall Host Based Security
เป็นคำแนะนำเบื้องต้นสำหรับเครื่องที่ทำหน้าที่เป็นไฟร์วอลล์รวมไปถึง router ด้วย

• ปิด TCP/UDP service ที่ไม่ได้ใช้งาน เช่น bootps, finger ยิ่งเปิด service น้อยก็ยิ่งลดโอกาสในการโจมตีของผู้บุกรุก และยังเป็นการลดการใช้งาน CPU และหน่วยความจำของระบบอีกด้วย
• ในกรณีที่จำเป็นต้องเปิด service บนเครื่องไฟร์วอลล์ จะต้องจำกัดการเข้าถึงให้ใช้งานได้เฉพาะผู้ดูแลระบบเท่านั้น
• ปิด service ที่ไม่จำเป็นอื่นๆ บนเครื่องไฟร์วอลล์ เช่น การทำ remote configuration
• ยกเลิก interface ที่ไม่ได้ใช้งานในเครื่องไฟร์วอลล์(หรือ router )
• ในกรณีที่ใช้ฮาร์ดแวร์ไฟร์วอลล์หรือ router จะต้องป้องกันการเข้าถึง port ที่ใช้ในการควบคุม เช่น console port
• แก้ไขค่า default password โดยให้มีความยาวอย่างต่ำ 8 ตัวอักษร, ไม่เป็นคำที่อยู่ในดิกชันนารี, ต้องไม่ขึ้นต้นด้วยตัวเลข, และมีตัวเลขรวมทั้งตัวอักษรพิเศษรวมอยู่ด้วย (เช่น ,./<>;':"[]{}\|~!@#$%^&*()_+-= ) และควรใช้รหัสผ่านที่แตกต่างกันในแต่ละเครื่อง ทั้งนี้ควรเปลี่ยนรหัสผ่านทุกๆ 90 วัน

Building Firewall Rulebase
หลักการง่ายๆ (ที่ไม่ง่าย)ในการสร้าง rule ของไฟร์วอลล์ที่ดีคือ ความง่าย (simplicity) ซึ่งความง่ายในที่นี้หมายถึงการสร้าง rule ที่สั้นๆ อ่านง่าย ได้ใจความ ไฟร์วอลล์ที่ดีไม่ควรมี rule มากกว่า 30 rule เพราะถ้ามากกว่านี้จะทำให้เกิดความสับสนได้ง่าย และอาจจะทำให้เกิดความผิดพลาดโดยไม่รู้ตัวขึ้น นอกจากนี้ยังมีข้อดีในส่วนที่ทำให้เครื่องทำงานน้อยลงอีกด้วย

การสร้าง rule ของไฟร์วอลล์ถือได้ว่าเป็นการนำ security policy ขององค์กรมาบังคับใช้งานในทางเทคนิค โดยใช้ไฟร์วอลล์เป็นเครื่องมือให้เกิดผลตามที่ต้องการ นอกจากนี้ยังมี rule บางส่วนที่ถือได้ว่า ผู้ดูแลระบบควรเพิ่มเข้าไปใน rule ของไฟร์วอลล์ เช่น การป้องกัน ip spoofing, ป้องกันการโจมตีแบบ land attack ซึ่งรายละเอียดจะได้กล่าวถึงอีกครั้งในส่วนของ TCP/IP Filter

Rule Order
การเรียงลำดับของ rule ก็มีความสำคัญเช่นเดียวกัน เพราะไฟร์วอลล์โดยส่วนใหญ่ทำงานแบบ sequence คือ ตรวจสอบ packet กับ rule ตามลำดับ rule ที่สร้างไว้

คำแนะนำในการวางลำดับของ rule คือ ให้วาง rule ที่เป็น rule ทั่วไปไว้ด้านล่าง และให้นำ rule ที่มีความเฉพาะเจาะจงมาไว้ด้านบน เพื่อป้องกันไม่ให้ packet match กับ rule ที่เป็น rule ทั่วไปก่อน ยกตัวอย่างเช่น ให้นำ rule ที่ทำหน้าที่ block ไอพีแอดเดรสไปไว้ด้านบนเพื่อให้มั่นใจว่า ถ้ามี packet ที่มีไอพีแอดเดรสตรงตามที่ระบุไว้ packet นั้นจะถูก drop ทิ้งไปก่อนที่จะ match กับ rule อื่น

TCP/IP Filter
ผู้ดูแลไฟร์วอลล์สามารถกำหนด default policy ได้ 2 รูปแบบคือ

• default ACCEPT : ผู้ดูแลไฟร์วอลล์จะต้องสร้าง rule เพื่อกำหนดว่าจะปิด service และโฮสต์ใดบ้าง โดย service และโฮสต์อื่นๆ ที่ไม่ถูกกำหนดไว้ จะมีค่าเป็นเปิด
• default DROP : ผู้ดูแลไฟร์วอลล์จะต้องสร้าง rule เพื่อกำหนดว่าจะเปิด service และโฮสต์ใดบ้าง โดย service และโฮสต์อื่นๆ ที่ไม่ถูกกำหนดไว้ จะมีค่าเป็นปิด

อย่างไรก็ตาม ไม่ว่าจะกำหนด default policy ในรูปแบบใด ผู้ดูแลไฟร์วอลล์ก็ควรทราบ TCP/IP service ที่เป็นจุดอ่อนต่างๆ ในระบบ ดังนี้

ตารางที่ 1 แสดง TCP/UDP service ที่ควรปิดกั้นที่ไฟร์วอลล์ โดยไม่ให้ใช้ทั้งจากภายในและภายนอกเครือข่าย

ตารางที่ 2 แสดง TCP/UDP service ที่ควรปิดกั้นไม่ให้เข้ามาจากภายนอก

ตารางที่ 3 แสดง TCP/UDP service ที่อาจเปิดให้บริการใน DMZ (ในทางปฏิบัติให้เปิดเฉพาะ service ที่มีการให้บริการจริงเท่านั้น)

ตารางที่ 4 แสดง ICMP message ที่ควรอนุญาตให้ออกไปจากเครือข่ายภายในได้

ตารางที่ 5 แสดง ICMP message ที่ควรอนุญาตให้เข้ามายังเครือข่ายภายในได้

คำแนะนำอื่นๆ สำหรับการสร้าง rule ของไฟร์วอลล์

• ควรมีการบันทึกข้อมูลลงล็อกสำหรับ rule ที่ใช้ block การเข้าถึง ซึ่งข้อมูลนี้จะเป็นประโยชน์ในการตรวจสอบการบุกรุก รายละเอียดของล็อกจะพบใน Logging and Debugging
  
  
• ป้องกันการปลอมไอพี (IP spoof) สำหรับข้อมูลขาเข้ามาจากอินเทอร์เน็ต โดยป้องกันไม่ให้ packet ที่มีไอพีดังต่อไปนี้เข้ามายังเครือข่ายภายใน
  • 127.0.0.0 - 127.255.255.255 : local host address
  • 10.0.0.0 - 10.255.255.255 : reserved address
  • 172.16.0.0 - 172.31.255.255 : reserved address
  • 192.168.0.0 - 192.168.255.255 : reserved address
  • 224.0.0.0 - 239.255.255.255 : multicast address
    
    
• ป้องกันเครื่องไฟร์วอลล์จากการโจมตีแบบ Land attack ซึ่งการโจมตีแบบนี้จะใช้วิธีส่ง packet ที่มี source ip address ตรงกันกับ destination ip address รวมทั้งค่า source port และ destination port ที่ตรงกัน ซึ่งก่อให้เกิดการโจมตีแบบ Denial of Service ได้ ซึ่งป้องกันได้โดย block ไม่ให้ข้อมูลขาเข้าที่มี source ip address ตรงกันกับไอพีของเครือข่ายภายในเข้ามาในระบบ
  
  
• ป้องกันการโจมตีแบบ SYN flood ที่เครื่องไฟร์วอลล์ ซึ่งผู้บุกรุกจะส่ง SYN packet จำนวนมากมายังเครื่องปลายทาง ทำให้คิวของการรับ connection ใน service ดังกล่าวเต็ม ทำให้ไม่สามารถให้บริการแก่เครื่องอื่นๆ ได้
  
  
• เครื่องไฟร์วอลล์และเครื่องอื่นๆ ภายในเครือข่ายควรได้รับป้องกันจาก ICMP message บางชนิด เช่น ป้องกันการรับ ICMP Echo request ซึ่งสามารถส่งมาเพื่อรวบรวมข้อมูลสำหรับการโจมตีครั้งต่อไป หรือการส่ง ICMP Echo request packet ที่มีขนาดใหญ่ (Ping flood) ซึ่งถือว่าเป็นรูปแบบหนึ่งในการโจมตี นอกจากนี้ redirect packet ที่ส่งมาจากภายนอกยังสามารถเปลี่ยน routing table ใน host ได้อีกด้วย ซึ่งเป็นเรื่องที่อันตรายอย่างยิ่ง
  
  สำหรับข้อมูลขาออกนั้น ควรอนุญาตให้ข้อมูล ICMP ดังต่อไปนี้เท่านั้นที่สามารถออกไปได้
  • Echo request
  • Parameter Problem
  • Source Quench
  
  สำหรับข้อมูลขาเข้านั้น ควรอนุญาตให้ข้อมูล ICMP ดังต่อไปนี้เท่านั้นที่สามารถเข้ามาภายในได้
  • Echo Reply
  • Destination Unreachable
  • Source Quench
  • Time Exceeded
  • Parameter Problem
    
    
• ป้องกันไฟร์วอลล์และเครื่องอื่นๆ ภายในเครือข่ายจาก traceroute เพราะ traceroute เป็นโปรแกรมที่ช่วยให้ทราบถึงไอพีแอดเดรสของ router ที่รับส่งต่อ packet ไปทีละ hop จนกระทั่งถึงปลายทางที่ต้องการ โดยใช้คุณสมบัติของ IP Time To Live (TTL) ในการทำงาน โดยมันจะกำหนดค่า TTL counter ที่ทำให้ router ที่ packet ผ่านไปนั้นต้องสร้าง ICMP message กลับมาเสมอ สำหรับคำสั่ง tracert ใน Windows นั้น จะใช้ ping (ICMP Echo) เป็นตัวส่ง packet ออกไป ในขณะที่ traceroute ใน Unix นั้น จะใช้ UDP datagram เป็นตัวส่งข้อมูลออกไป datagram ที่ถูกส่งออกไปนั้นจะถูกส่งไปยัง port 33434 โดยดีฟอลต์ และ ค่าหมายเลข port นี้จะถูกเพิ่มขึ้นเมื่อได้รับ packet ที่ตอบกลับมาอย่างถูกต้อง โดยปกติแล้ว traceroute มักจะส่ง datagram ออกไปจำนวน 3 datagram เพื่อป้องกันการสูญหายระหว่างทาง
  
  ถึงแม้ว่าจะมีการป้องกันการใช้งาน traceroute จากทั้ง Unix และ Windows แล้วก็ตาม ผู้บุกรุกก็ยังสามารถใช้วิธีอื่นในการ trace เข้ามายังเครือข่ายภายใน เช่น การใช้โปรแกรม Firewalk ดังนั้นหากต้องการหยุดยั้งการใช้ traceroute รวมทั้ง Firewalk แล้ว จะต้องใช้วิธี drop TTL Exceeded in Transit packet ที่ขาออกไปสู่อินเทอร์เน็ต
  
  
• จำกัดการเข้าถึงเครื่องไฟร์วอลล์ โดยให้ใช้งานใน service ที่จำเป็นเท่านั้น(สำหรับผู้ดูแลระบบเท่านั้น) และให้บันทึกข้อมูลล็อกสำหรับทั้ง connection ที่สำเร็จและไม่สำเร็จ
  
  
• ถ้าหากมี SNMP server รันอยู่บนเครื่องไฟร์วอลล์ จะต้องจำกัดการใช้งานให้ใช้เฉพาะผู้ดูแลระบบเท่านั้น และให้บันทึกข้อมูลล็อกสำหรับทั้ง connection ที่สำเร็จและไม่สำเร็จ

Logging and Debugging
การเก็บข้อมูลล็อกของเครื่องไฟร์วอลล์เป็นเรื่องที่จำเป็นอย่างยิ่ง โดยเฉพาะในกรณีที่เครื่องโดน compromise ไปแล้ว จะถือว่าเป็นหลักฐานที่แสดงให้เห็นถึงรูปแบบการโจมตีได้ มีคำแนะนำสำหรับการบันทึกข้อมูลล็อกดังนี้

• ให้ส่งข้อมูลล็อกที่มีความสำคัญไปยัง console ของเครื่องไฟร์วอลล์
• ส่งข้อมูลล็อกไปยังเครื่องที่ทำหน้าที่เก็บล็อกโดยเฉพาะ ซึ่งเครื่องนี้ได้รับการควบคุมการเข้าถึงอย่างเคร่งครัด และไม่ได้เปิดให้บริการอื่นใดยกเว้น syslog
• ตั้งเวลาเครื่องไฟร์วอลล์และเครื่องอื่นๆ ในเครือข่ายให้ใช้เวลาที่ตรงกันทั้งหมด โดยใช้ NTP (network time protocol) เพื่อรับข้อมูลเวลาจาก clock server เดียวกัน
• ป้องกันการโจมตีแบบ log flooding ซึ่งจะทำให้ฮาร์ดดิสก์เต็มอย่างรวดเร็ว
• ไม่ควรส่งข้อมูลล็อกออกไปยังเครื่องพิมพ์โดยตรง เพราะอาจจะเสี่ยงต่อการสูญเสียข้อมูลในกรณีที่เครื่องพิมพ์มีปัญหา

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

เอกสารอ้างอิง

• Lance Spitzner, "Building Your Firewall Rulebase "
  URL: http://www.enteract.com/~lspitz/rules.html (January 26, 2000)
• SNAC.Guides@nsa.gov, " The 60 Minute Network Security Guide" , version 1.0
  URL: http://nsa2.www.conxion.com/support/guides/sd-7.pdf (October 16, 2001)