เป็นที่ทราบกันดีอยู่แล้วว่า?ไฟร์วอลล์มีหน้าที่หลักในการกรอง?(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?ที่ควรปิดกั้นที่ไฟร์วอลล์?โดยไม่ให้ใช้ทั้งจากภายในและภายนอกเครือข่าย
| Port(s) (Transport) | Server | Port(s) (Transport) | Server | | 1 (TCP & UDP) | tcpmux | 1981 (TCP) | Shockrave | | 7 (TCP & UDP) | echo | 1999 (TCP) | BackDoor | | 9 (TCP & UDP) | discard | 2001 (TCP) | Trojan Cow | | 11 (TCP & UDP) | systat | 2023 (TCP) | Ripper | | 13 (TCP & UDP) | daytime | 2049 (TCP & UDP) | nfs | | 15 (TCP & UDP) | netstat | 2115 (TCP) | Bugs | | 17 (TCP & UDP) | qotd | 2140 (TCP) | Deep Throat | | 19 (TCP & UDP) | chargen | 2222 (TCP) | Subseven21 | | 37 (TCP & UDP) | time | 2301 (TCP & UDP) | compaqdiag | | 43 (TCP & UDP) | whois | 2565 (TCP) | Striker | | 67 (TCP & UDP) | bootps | 2583 (TCP) | WinCrash | | 68 (TCP & UDP) | bootpc | 2701 (TCP & UDP) | sms-rcinfo | | 69 (UDP) | tftp | 2702 (TCP & UDP) | sms-remctrl | | 93 (TCP) | supdup | 2703 (TCP & UDP) | sms-chat | | 111 (TCP & UDP) | sunrpc | 2704 (TCP & UDP) | sms-xfer | | 135 (TCP & UDP) | loc-srv | 2801 (TCP) | Phineas P. | | 137 (TCP & UDP) | netbios-ns | 4045 (TCP) | lockd | | 138 (TCP & UDP) | netbios-dgm | 5800 - 5899 (TCP) | winvnc web server | | 139 (TCP & UDP) | netbios-ssn | 5900 - 5999 (TCP) | winvnc | | 177 (TCP & UDP) | xdmcp | 6000 - 6063 (TCP) | X11 Window System | | 445 (TCP & UDP) | microsoft-ds | 6665 - 6669 (TCP) | irc | | 512 (TCP) | rexec | 6711 - 6712 (TCP) | Subseven | | 513 (TCP) | rlogin | 6776 (TCP) | Subseven | | 513 (UDP) | who | 7000 (TCP) | Subseven21 | | 514 (TCP) | rsh, rcp, rdist, rdump, rrestore | 12345 - 12346 (TCP) | NetBus | | 515 (TCP) | lpr | 16660 (TCP) | Stacheldraht | | 517 (UCP) | talk | 27444 (UCP) | Trinoo | | 518 (UCP) | ntalk | 27666 (TCP) | Trinoo | | 540 (TCP) | uucp | 31335 (UCP) | Trinoo | | 1024 (TCP) | NetSpy | 31337 -31338 (TCP & UDP) | Back Orifice | | 1045 (TCP) | Rasmin | 32700 - 32900 (TCP & UDP) | RPC services | | 1090 (TCP) | Xtreme | 32720 (TCP) | Trinity V3 | | 1170 (TCP) | Psyber S.S | 39168 (TCP) | Trinity V3 | | 1234 (TCP) | Ultors Trojan | 65000 (TCP) | Stacheldraht | | 1243 (TCP) | Backdoor-G | ? | ? | | 1245 (TCP) | VooDoo Doll | ? | ? | | 1349 (UCP) | Back Orifice DLL | ? | ? | | 1492 (TCP) | FTP99CMP | ? | ? | | 1600 (TCP) | Shivka-Burka | ? | ? | | 1761 - 1764 (TCP & UDP) | sms-helpdesk | ? | ? | | 1807 (TCP) | SpySender |
? ตารางที่?2?แสดง?TCP/UDP?service?ที่ควรปิดกั้นไม่ให้เข้ามาจากภายนอก
| Port(s) (Transport) | Server | | 79 (TCP) | finger | | 161 (TCP & UDP) | snmp | | 162 (TCP & UDP) | snmp trap | | 514 (UDP) | syslog | | 550 (TCP & UDP) | new who |
? ตารางที่ 3 แสดง TCP/UDP service ที่อาจเปิดให้บริการใน DMZ (ในทางปฏิบัติให้เปิดเฉพาะ service ที่มีการให้บริการจริงเท่านั้น)? | Port(s) (Transport) | Server | | 20 (TCP) | ftpdata | | 21 (TCP) | ftp | | 22 (TCP) | ssh | | 23 (TCP) | telnet | | 25 (TCP) | smtp | | 53 (TCP & UDP) | domain | | 80 (TCP) | http | | 110 (TCP) | pop3 | | 119 (TCP) | nntp | | 123 (TCP) | ntp | | 143 (TCP) | imap | | 179 (TCP) | bgp | | 389 (TCP & UDP) | ldap | | 443 (TCP) | ssl | | 1080 (TCP) | socks | | 3128 (TCP) | squid | | 8000 (TCP) | http (alternate) | | 8080 (TCP) | http-alt | | 8888 (TCP) | http (alternate) |
ตารางที่?4?แสดง?ICMP?message?ที่ควรอนุญาตให้ออกไปจากเครือข่ายภายในได้
| Message Type | | Number | Name | | 4 | source quench | | 8 | echo request (ping) | | 12 | parameter problem |
ตารางที่?5?แสดง?ICMP?message?ที่ควรอนุญาตให้เข้ามายังเครือข่ายภายในได้
| Message Type | | Number | Name | | 0 | echo reply | | 3 | destination unreachable | | 4 | source quench | | 11 | time exceeded | | 12 | parameter problem |
คำแนะนำอื่นๆ?สำหรับการสร้าง?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)
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
,?"?The?60?Minute?Network?Security?Guide"?,?version?1.0
URL:?http://nsa2.www.conxion.com/support/guides/sd-7.pdf?(October?16,?2001)
ที่มา?คุณภูวดล?ด่านระหาญ
|
