How to hardening your UNIX/Linux OS by A.Phakkhaphong Kritawat CCNA, MCSE Windows 2000 with XP , MCSA Windows 2000 ,MCDBA SQL Server 2000 , OCA 9i ACIS Professional Team E-mail:phakkhaphong จาก e-week ฉบับที่แล้วเราได้พูดกันเกี่ยวกับช่องโหว่ (Vulnerability) ที่พบบ่อยในระบบปฏิบัติการวินโดว์ไปบางส่วนแล้ว ในครั้งนี้ ผมขอสลับไปพูดเกี่ยวกับช่องโหว่ที่พบบ่อยในระบบปฏิบัติการซึ่งเป็นที่นิยมไม่แพ้กัน นั่นก็คือ ระบบปฏิบัติการยูนิกซ์ (UNIX)      สำหรับระบบปฏิบัติการยูนิกซ์กลับไม่ค่อยพบปัญหาที่เกี่ยวข้องกับเรื่องของสิทธิการใช้งานข้อมูล เช่น การตรวจสอบสิทธิการเข้าถึง (Authentication), การอนุญาตให้ใช้ (Authorization) สักเท่าไหร่ อาจเป็นเพราะได้มีการออกแบบในเรื่องดังกล่าวตั้งแต่เริ่มมีการใช้ยูนิกซ์เป็นครั้งแรกกว่า 20 ปีมาแล้วก็ว่าได้      แต่ปัญหาที่พบมักเกิดจากการที่โปรโตคอลในชั้น Application บางตัวที่ไม่รองรับการเข้ารหัส ทำให้สามารถดักจับข้อมูลระหว่างที่มีการรับส่งข้อมูลได้ (Eavesdropping/Interception Attack)      ช่องโหว่ที่มักพบบ่อยในระบบปฏิบัติการยูนิกซ์ที่ผมจะนำเสนอในครั้งนี้ จะเป็นช่องโหว่ที่จัดว่าอยู่ในลำดับต้น ๆ ที่ทางสถาบัน SANS และหน่วยงาน FBI ของสหรัฐฯ ได้จัดลำดับเอาไว้ ซึ่งผมขอนำเสนอเพียงบางส่วนดังนี้ 1. ช่องโหว่ที่เกิดกับกระบวนการ RPC (Remote Procedure Call)      ยูนิกซ์ใช้ RPC ในการติดต่อระหว่างกันของ Application ในลักษณะ Client/Server ซึ่งโปรเซสดังกล่าวมักถูกโจมตีโดยวิธี DDOS (Distributed Denial of Service) ในระหว่างปี พ.ศ. 2542-2543 วิธีการแก้ไข หากไม่ต้องมีการติดต่อระหว่าง Application ต่างๆ ผ่านทางเน็ตเวิร์ก ให้ปิดการใช้งานทุกๆ RPC ที่ไม่ใช้ทิ้งไป หากยังคงต้องใช้งาน Service เหล่านั้น ต้องติดตามหา Patch เวอร์ชั่นล่าสุดมาอัปเดทอย่างสม่ำเสมอ ทำการปิดกั้นการเรียกใช้งานพอร์ต 111 จากภายนอกโดยกำหนดกฎดังกล่าวไว้ที่ Firewall ตัวนอกสุด ทำการปิดกั้นการเรียกใช้งานพอร์ตซึ่งเป็น Loopback ของ RPC (พอร์ต 32770-32789) ปิดการทำงานของ Executable Stack ด้วยการเปิดคุณสมบัติ Non-Executable Stack เพื่อป้องกันการแอบซ้อน Code ในการทำให้เกิด Buffer overflow 2. ช่องโหว่ที่เกิดกับ Apache Web Server      แม้ว่าจะมีผู้คนมากมายพยายามเปรียบเทียบ Apache กับ IIS ของไมโครซอฟท์ ซึ่งโดยส่วนใหญ่ลงความเห็นว่า Apache นั้นดีกว่า IIS ในแง่ของระบบรักษาความปลอดภัย แต่ก็ไม่ได้หมายความว่าจะไม่มีช่องโหว่ให้โจมตีได้เลย การที่แฮกเกอร์ในปัจจุบันพยายามที่จะเจาะระบบผ่านพอร์ต 80 แต่เพียงอย่างเดียวอย่างแข็งขัน ก็ทำให้พบเจอช่องโหว่ได้ ซึ่งช่องโหว่เหล่านั้นก็ไม่ได้แตกต่างไปจากที่พบใน IIS เลย ช่องโหว่เหล่านั้นเกิดมาจากการที่เราไม่ค่อยระมัดระวังในการกำหนด Permission ให้กับไฟล์ CGI อีกทั้ง CGI ที่เขียนมาไม่ดีหรือถูกผสมรวมกับ Malicious Code ก็เป็นอีกปัญหาหนึ่งที่อาจนำพาให้เกิดการโจมตีในลักษณะต่าง ๆ วิธีการอย่างง่ายๆ ที่จะแนะนำว่า Apache ที่คุณใช้งานอยู่มีช่องโหว่หรือไม่ ก็ให้ตรวจสอบเวอร์ชันล่าสุดของ Apache จาก http://httpd.apache.org/ และหากพบว่าเวอร์ชันที่คุณมีเก่ากว่าเวอร์ชันปัจจุบัน นั่นก็แปลได้ว่ามีการตรวจพบช่องโหว่ใหม่ๆ เพิ่มขึ้นอีกแล้ว วิธีการแก้ไข ติดตั้ง Apache เวอร์ชันล่าสุดเสมอที่มีการเปลี่ยนแปลง โดยสามารถดาวน์โหลดได้จาก http://www.apache.org/dist/httpd/patches/ ทำการเปลี่ยนค่า HTTP Response Token (บางครั้งอาจเรียกว่า Banner ได้) เพื่อป้องกันการค้นหาชนิดและเวอร์ชันของโปรแกรมที่รันอยู่จากผู้บุกรุกได้ รายละเอียดดูได้จาก http://www.cert.org/advisories/CA-2002-27.html เลือกคอมไพล์โมดูลของ Apache เฉพาะที่ต้องการใช้งานเท่านั้น มีผลเช่นเดียวกันกับการเปิด Service เฉพาะที่จำเป็นต้องใช้งานเท่านั้น ประโยชน์เพื่อลดโหลดที่ไม่จำเป็นออกจากเซิร์ฟเวอร์และลดช่องโหว่ที่อาจจะเกิดขึ้นจาก Service ต่างๆ เลือกรัน Apache ในสภาพแวดล้อมของฟังก์ชัน chroot() ดูรายละเอียดเพิ่มเติมได้จาก http://www.w3.org/Security/Faq/wwwsf3.html#SVR-Q5 ไม่ใช้ root privileges ในการรัน Service ของ Apache ควรสร้าง User ขึ้นมาใหม่เป็นการเฉพาะสำหรับการรัน Service ของ Apache และกำหนด privileges ที่เหมาะสมในการเข้าถึงทรัพยากรต่าง ๆ อย่างเหมาะสม ให้ลบ Web Page และ CGI ตัวอย่างทิ้งไปเพราะถูกเขียนขึ้นมาอย่างไม่รัดกุมและพบปัญหาการบุกรุกบ่อยครั้ง 3. ช่องโหว่ที่ตรวจพบใน SSH (Secure Shell)      แม้ว่า SSH จะถูกระบุว่ามาช่วยแก้ปัญหาการใช้งาน Application Protocol ที่ไม่มีการเข้ารหัสข้อมูลอย่าง FTP,Telnet และ R-Command ก็ตามที แต่ไม่นานมานี้ก็ได้มีการประกาศข่าวอย่างคึกโครมว่าในขั้นตอนการถอดรหัสของ SSH กลับเกิดช่องโหว่ให้เจาะระบบได้เสียเอง ทำให้ระบบที่คิดว่าได้รับการแก้ไขโดยการนำ SSH ไปใช้เสี่ยงต่ออันตรายที่อาจจะเกิดขึ้นอีกครั้ง วิธีการแก้ไข ให้ทำการตรวจสอบเวอร์ชัน โดยการพิมพ์คำสั่ง ssh -v หากเวอร์ชัน 1 ให้ดาวน์โหลดเวอร์ชันใหม่จาก http://www.openssh.org/ หรือ http://www.ssh.com/ มาติดตั้ง      ในฉบับนี้ผมขอนำเสนอช่องโหว่ที่สำคัญ ๆ ใน Unix/Linux เพียง 3 จุดก่อน ฉบับหน้าผมจะนำช่องโหว่ต่อ ๆ ไปมาพูดเพิ่มเติมอีก อย่าลืมทำการ Hardening ตั้งแต่วันนี้นะครับ เพื่อเพิ่มความปลอดภัยให้กับระบบ UNIX/Linux ของคุณ Update Information : 23 ธันวาคม 2545

การติดตั้ง Snort และ ACID (Open Source Intrusion Detection System) อย่างง่ายและถูกวิธี Update: April 2, 2003 How to hardening your UNIX/Linux OS Update: Dec 23, 2002 How to hardening your MS Windows OS Update: Dec 6, 2002