Defending Your Web Server

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

ผม(ผู้เขียน)ได้เข้าไปที่เว็ปของ Attrition ที่มีสภิติเกี่ยวกับเว็ปไซต์ที่ถูกเปลี่ยนแปลงเนื้อหา สิ่งที่ผมพบคือ เซิร์ฟเวอร์ที่ใช้ NT ถูกเปลี่ยนแปลงเนื้อหาภายในเว็ปเพจเพิ่มขึ้นเรื่อย ๆ เฉลี่ย 60 % เพิ่มขึ้น 64 % ใน เดือนเมษายน คศ.2000 ระบบปฏิบัติการ NT เป็นแชมป์ของการถูกเปลี่ยนแปลงเนื้อหาในเว็ปมากที่สุด ถ้าคุณรวมลีนุกซ์ทุกเจ้าเข้าด้วยกัน มันจะมาเป็นที่สองด้วยอัตราเฉลี่ย 17 % ตามด้วย Solaris 10 % ต่อเดือน อัตราของการถูกเปลี่ยนแปลงเนื้อหาเว็ปของ Solaris ลดลงสวนกับอัตราการเพิ่มขึ้นกับ NT

บางทีอัตราการถูกเปลี่ยนเนื้อหาภายในเว็ปเซิร์ฟเวอร์ที่สูงของ NT อาจเกี่ยวข้องกับการที่เว็ปเซิร์ฟเวอร์ที่ใช้ NT มีมากกว่าแพลตฟอร์มอื่น ๆ แต่จริง ๆ แล้วมันไม่เกี่ยวข้องกัน จากการสำรวจของเว็ปไซต์ Netcraft แสดงให้เห็นว่าซอฟทแวร์เว็ปเซิร์ฟเวอร์ของ Apache มีมากกว่าของไมโครซอฟท์เกือบสามต่อหนึ่ง กล่าวอีกนัย หนึ่ง ถึงแม้ว่าเว็ปเซิร์ฟเวอร์ที่ใช้ NT จะไม่ได้เป็นที่นิยมใช้มากที่สุดก็ตาม แต่กลับถูกเปลี่ยนเนื้อหามากกว่า เว็ปเซิร์ฟเวอร์แพลตฟอร์มอื่นทั้งหมด

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

ยูนิกซ์ vs. NT

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

ถ้า NT มีศักยภาพในการรักษาความปลอดภัยดีกว่ายูนิกซ์หรือลีนุกซ์ แล้วทำไมจึงถูกบุกรุกบ่อยมาก ? ปัญหาที่ส่วนใหญ่ไม่ได้อยู่ที่ตัว NT เอง แต่อยู่ที่ IIS (Internet Information Server) IIS พยายามที่จะทำ สิ่งต่าง ๆ มากกว่าที่ Apache ทำ สิ่งนี้เองที่ทำให้เกิดปัญหา

ปีที่แล้วการโจมตีโดยอาศัย buffer overflow สำหรับ IIS ถูกค้นพบและโปรแกรม exploit ถูกเผยแพร่ โดย eEye (http://www.eEye.com) ทีมรักษาความปลอดภัยที่อยู่ทางใต้ของแคลิฟอร์เนีย ช่องโหว่นี้ ยอมให้ผู้โจมตีสามารถอัปโหลดและรันโค้ดได้ตามใจชอบ นอกจากการโจมตีนี้อาศัย buffer overflow ของ IIS( แน่ละคุณจำเป็นต้องอัปเกรดเซิร์ฟเวอร์ของคุณถ้าคุณไม่ได้อัปเดทเมื่อปีที่ แล้ว) มันยังอาศัยคุณลักษณะ พิเศษของอื่นของ Win32 API ทำให้ไม่ยากที่จะทำสิ่งง่าย ๆ เช่นการอัปโหลดโค้ด(ใช้ fuction call เพียงคำสั่งเดียว)

เว็ปเซิร์ฟเวอร์ของ Apache ไม่ได้รับผลกระทบจาก buffer overflow มาหลายปีแล้ว NCSA 1.3 ซึ่งเป็น ต้นแบบของ Apache เคยมีปัญหาเรื่อง buffer overflow ถูกใช้ในการบุกรุกระบบของ GE Plactic ในปีคศ. 1994 ภายในปีที่แล้วมีเพียงซอฟท์แวร์แก้ไขสำหรับแก้ไขบั๊กที่ได้รับการเตือนจาก CERT ว่าข้อความที่แสดงข้อผิดพลาดที่ส่งกลับไปโดยเว็ปเซิรฟเวอร์สามารถรวมเอาสคริปท์ไว้ด้วยถ้าผู้โจมตี สร้างเว็ปเพจที่ใช้เพื่อเข้าถึงเว็ปเซิร์ฟเวอร์ (CERT Advisory CA-2000-02) ไมโครซอฟท์ได้ออก ซอฟท์แวร์เพื่อแก้ไขข้อผิดพลาดของ ISS นี้แล้ว

นอกจากเรื่อง buffer overflow แล้ว Rain Forest Puppy (RFP) ได้เผยแพร่ Perl script ที่สามารถ ใช้เพื่อรันคำสั่งใน IIS server ที่มีสคริปท์ตัวอย่างหลายสคริปท์ (advisory ที่สองในปีคศ.1999) ประจวบกับที่ Attrition รายงานการถูกเปลี่ยนเนื้อหาภายในเว็ปที่เกิดขึ้นทั้งวันหลังจากนั้น โดยสถิติเกิดขึ้นในวันอาทิตย์ส่วนใหญ่ คุณอาจพิจารณาที่จะเขียนสคริปท์ซึ่งเก็บรวบรวมโฮมเพจของคุณไว้ เปรียบเทียบกับสิ่งที่ควรเป็นแล้วให้มันส่งมาทางอีเมลล์หรือเพจเจอร์มาให้คุณถ้ามันถูกเปลี่ยนแปลงไป

ซอฟท์แวร์ของ Apache จะมีสคริปท์ตัวอย่างมาให้ด้วย ในเวอร์ชันเก่า ๆ สคริปท์เหล่านี้จะอยู่ในไดเร็กทอรี cgi-bin ซึ่งเป็นไดเร็กทอรีที่กำหนดไว้ตั้งแต่เริ่มต้น ถ้าคุณปล่อยให้สคริปท์เหล่านี้อยู่ในเซิร์ฟเวอร์ต่อไป พวกมันอาจมีช่องช่องโหว่ให้ละเมิดความปลอดภัยได้ เวอร์ชันใหม่ ๆ ของ Apache ย้ายสคริปท์เหล่านี้ ไปไว้ที่ ไดเร็กทอรี sample ที่ไม่สามารถเข้าถึงได้โดยค่าเริ่มต้น

ไม่ว่าคุณจะใช้ IIS หรือซอฟท์แวร์อื่น คุณจำเป็นต้องลบสคริปท์ตัวอย่างเหล่านี้ทั้งหมด คุณอาจต้องการ เก็บสคริปท์เหล่านี้ไว้เพื่อการอ้างอิง เพียงแต่ไม่เก็บพวกมันไว้ที่ไดเร็กทอรีของสคริปท์ใน NT หรือ cgi-bin ในยูนิกซ์ ไดเร็กทอรีทั้งสองนี้อยู่ที่ไดเร็กทอรีรากของเซิร์ฟเวอร์ จำไว้ว่าทั้ง IIS และ Apache อาจมีสคริปท์ อื่นอีกและคุณต้องทำเช่นเดียวกัน และอย่าลืมว่ามีไดเร็กทอรีย่อยด้วย (เช่น cgi-bin/photoads หรือ Scripts\Tools)

ข้อควรระวังเกี่ยวกับสคริปท์

ถ้า คุณมีสคริปท์ในเว็ปเซิร์ฟเวอร์ คุณต้องตรวจหาช่องโหว่ที่แฝงอยู่อย่างละเอียด ข้อผิดพลาดที่พบบ่อย ในสคริปท์(หรือโปรแกรม) สำหรับการทำงานในเว็ปเซิร์ฟเวอร์คือการไม่กลั่นกรองแก้ไขสิ่งที่ป้อนเข้าไป (trusting client input) exploit สำหรับยูนิกซ์ที่เป็นที่รู้จักกันดีคือการใส่เครื่องหมายจบคำสั่ง (command terminator) ลงไปในสิ่งที่ป้อนเข้าไปด้วย เช่นตามท้ายชื่อหรือที่อยู่อีเมลล์ ถ้าสคริปท์ไว้ใจในสิ่งที่ป้อนเข้าไป โดยไม่ได้กลั่นกรองแก้ไข มันอาจส่งผ่านสิ่งที่ป้อนเข้าไปและสิ่งที่อยู่หลังเครื่องหมายจบคำสั่งให้ เป็นคำสั่งใน ยูนิกซ์ (เครื่องหมาย เซมิโคลอน บรรทัดใหม่ และอักขระอีกหลายตัวสามารถรันได้โดย shell)

Visual Basic ของไมโครซอฟท์มี shell fucntion ที่สามารถใช้ cmd.exe เพื่อรันโปรแกรมใน NT เซิร์ฟเวอร์ได้ด้วย ประเด็นนี้จึงไม่ได้มีปัญหาเฉพาะกับยูนิกซ์ นอกจากนี้ Perl ที่ใช้ทั้งยูนิกซ์และ NT ก็สามารถจัดการกับสิ่งที่ป้อนเข้าไปโดยไม่ได้คาดหมายด้วย

CERT (Computer Emergecy Response Team) เผยแพร่ Perl สคริปท์ตัวอย่างหลายปีมาแล้ว ออกแบบมาเพื่อกรองอักขระที่ไม่ได้รับการคาดหมายว่าเป็นสิ่งที่ป้อนเข้ามาออกไป ผู้เขียนสคริปท์สร้าง กลุ่มของอักขระที่คาดหมายว่าจะเป็นสิ่งที่ป้อนเข้ามา และใช้คำสั่งแทนที่สิ่งที่ไม่ได้อยู่ในกลุ่มของอักขระนี้ โดยด้วยอักขระขีดเส้นใต้ (underscore character)

ประเด็นเฉพาะสำหรับ NT คือการจัดการกับรหัสผ่าน การรักษาความปลอดภัยของ NT ตั้งใจให้ชื่อผู้ใช้และ รหัสผ่านรวมอยู่ในสคริปท์ที่จะติดต่อกับฐานข้อมูล Access หรือ SQL ไดเร็กทอรีของสคริปท์ไม่ควร ปรากฏอยู่ในไดเร็กทอรีของเอกสารเว็ป (webroot หรือ htdocs) ตัวสคริปท์เองก็ต้องได้รับการป้องกัน IIS มีระบบป้องกัน (NTFS ACLs) ควรกำหนดค่าให้รันได้อย่างเดียวเท่านั้น (execuition only)

NT และ IIS มีปัญหากับการป้องกันไม่ให้อ่านสคริปท์(read access) มีวิธีหลีกเลี่ยง 6 วิธีในการอ่านสคริปท์ โดยไม่รันสคริปท์ ซึ่งมีมาหลายปี ซึ่งจะได้รับการแก้ไขโดยไมโครซอฟท์ในไม่ช้า วิธีห้าอย่างนี้รวมถึงการ เพิ่มอักขระบางตัวต่อท้าย pathname ของสคริปท์ แล้วจึงใช้สคริปท์ตัวอย่างเพื่อการอ่านไฟล์ที่อยู่ในเซิร์ฟเวอร์

การอนุญาตและความเป็นเจ้าของ (Permissions and Ownership)

ถึงแม้ว่าซอฟท์แวร์เว็ปเซิร์ฟเวอร์พยายามที่จะควบคุมการเข้าถึง แต่เป็นการดีกว่าที่ใช้ข้อดีจากความเป็นเจ้าของ และการอนุญาตหรือการควบคุมการเข้าถึงของระบบปฏิบัติการเอง ไม่ว่าคุณจะใช้ NT หรือยูนิกซ์ก็ตาม เอกสารและสคริปท์ไม่ควรเป็นเจ้าของโดย user account ที่รันเว็ปเซิร์ฟเวอร์ ในระบบของ NT account นี้ มีชื่อเป็น IUSR__xxx โดย xxx เป็นชื่อของระบบ ระบบยูนิกซ์และลีนุกซ์ส่วนใหญ่ใช้ชื่อ nobody ถึงแม้ว่าบางแห่งจะ มีชื่อ account พิเศษ (ชื่อเริ่มต้น www) สำหรับรันเว็ปเซิร์ฟเวอร์

ถ้ามีช่องโหว่ในซอฟท์แวร์เว็ปเซิร์ฟเวอร์ หรือในสคริปท์ที่รันโดยเว็ปเซิร์ฟเวอร์ ถ้าเอกสารและสคริปท์ไม่เป็น เจ้าของโดย web user account และไม่สามารถเขียนโดย web user account พวกเขาก็ไม่สามารถแก้ไข เปลี่ยนแปลงได้ จึงควรเปลี่ยนความเป็นเจ้าของและการอนุญาตเสีย (ACLs ใน NT) เพื่อป้องกันไม่ไห้มีการ เปลี่ยนแปลงเนื้อหาภายในเว็ป โดยเฉพาะในระบบของ NT

ไดเร็กทอรีที่อยู่ภายใต้ไดเร็กทอรีของเว็ปต้องได้รับการปกป้องด้วย ทั้ง NT และยูนิกซ์ยอมให้มีการลบไฟล์ ได้ถ้าไดเร็กทอรีกำหนดให้ลบได้ ในยูนิกซ์จำเป็นต้องมี write และ execution permission ใน NT มีการ กำหนด delete permissionเฉพาะสำหรับลบไดเร็กทอรีใน NTFS ด้วย สิ่งที่มักจะไม่ค่อยรู้เกี่ยวกับ NTFS คือ delete permission ของไดเร็กทอรีนั้นยอมให้ลบไดเร็กทอรีย่อยและไฟล์ด้วย

Bastion

เว็ปเซิร์ฟเวอร์จะมีความปลอดภัยมากถ้ากำหนดค่าให้มันเป็น bastion host ที่มีชื่ออย่างนั้นเพราะมันได้รับการ ป้องกัน เอาซอฟท์แวร์ออกไปและเซอร์วิสของเน็ตเวิร์คถูกปิดลง ใน NT คุณสามารถ unbind NetBIOS จาก network interface ปิดเซอร์วิสทั้งหมดยกเว้น EventLog, NTLM Secrutiy Support Provider, Protected Storage (ถ้าคุณมี) และRemote Procedure Call (RPC) เซอร์วิสนี้ จำเป็นสำหรับการรัน IIS (และการล๊อกอินเข้ามาเพื่อการดูแลระบบ) ใช้ IP filtering ใน advanced menu ของ Network control panel เพื่ออนุญาตให้มีการเข้าถึงพอร์ต 80/TCP เท่านั้น เนื่องจากRPC เซอร์วิส จะทำให้มีพอร์ตที่มีปัญหาสำหรับระบบของ NT พอร์ตเหล่านี้คือ 135, 137, 138 และ 139

ถ้าคุณใช้ยูนิกซ์หรือลีนุกซ์ ให้ปิดทุกเซอร์วิสที่อยู่ใน /etc/inetd.conf และเอาลิงค์ที่อ้างไปยัง startup script ในไดเร็กทอรี /etc/rc.d ที่สตาร์ทเน็ตเวิร์คเซอร์วิสออกไป แล้วจึงรีบูตระบบ ใช้คำสั่ง netstat -a เพื่อดู รายการของเซอร์วิสที่รอการติดต่ออยู่( flag LISTENING อยู่ที่คอลัมน์ทางขวา) ในยูนิกซ์ควรมีเฉพาะ httpd เท่านั้น(พอร์ต 80) เท่านั้นที่รอการติดต่อ และอาจมี local domain socket ด้วยถ้าคุณใช้ X (ใช้ text console ปลอดภัยกว่า) ใน NT เซอร์วิสที่เหลือควรมีเฉพาะ RPC และ IIS จำไว้ว่าการรัน RPC เซอร์วิสและ IIS ทำให้บางพอร์ตที่อยู่ระหว่าง 1025 ถึง 1035 เปิดขึ้นมาได้

ควรมีเพียงแต่ผู้บริหารระบบเท่านั้นที่มี account ใน bastion host, เนื้อหาของเว็ปใส่อย่างปลอดภัยจาก เว็ปเซิร์ฟเวอร์ที่พัฒนาอยู่ไปสู่ bastion host โดยการใส่ไฟล์ลงไปสื่อแบ๊คอัปเช่น zip หรือ writeable CD แล้วจึงใส่ลงไปจาก console ในโลกของ NT เครื่องมือที่มีประโยชน์ เช่น FrontPage มีประโยชน์กับนักล้วง ข้อมูลเช่นเดียวกัน

แน่นอน bastion host จะได้รับการป้องกันโดยไฟร์วอล คุณจำเป็นต้องกำหนดค่าทั้ง bastion host และ ไฟร์วอล ไฟร์วอลควรป้องกันเน็ตเวิร์คภายในจากเว็ปเซิร์ฟเวอร์ด้วย ในกรณีที่เว็ปเซิร์ฟเวอร์ถูกบุกรุก ไฟร์วอลที่จำหน่ายโดยส่วนใหญ่สนับสนุน network interface ทั้งสามแบบ เว็ปเซิร์ฟเวอร์ควรอยู่ใน DMZ (Demilitarize Zone) interface

ผู้ ขายระบบปฏิบัติการพยายามทำอย่างมากในการทำให้ระบบใช้ง่าย เจ้าของเว็ปเซอร์ฟเวอร์สามารถเซ็ต ให้เว็ปเซิร์ฟเวอร์ให้ทำงานในอินเตอร์ได้อย่างง่ายดาย เพียงจัดการเรื่องการรักษาความปลอดภัยให้แน่นหนา ที่สุดเท่านั้น เพราะระบบปฏิบัติการมีระบบรักษาความปลอดภัยที่ได้รับการทดสอบแล้ว ไม่ได้หมายความว่า จะปลอดภัยถ้าคุณใส่ application ที่ไม่ปลอดภัยลงไป การรับรองความปลอดภัยระดับ C2 ของ NT ใช้ได้เมื่อ NT ไม่ได้ต่อกับเน็ตเวิร์คเท่านั้น อย่ามัวนิ่งเฉยอยู่ จัดการทำให้เว็ปเซิร์ฟเวอร์ของคุณปลอดภัยเสีย

แหล่งข้อมูล

Survey of Web server types: http://www.netcraft.com/survey/ (top three, Apache 62%, Microsoft, 21%, iPlanet 7%) 14,322,950 Web servers

http://www.attrition.org/mirror/attrition/os.html

Steve Sutton's NT security Guide: http://www.trustedsystems.com/tss_nsa_guide.htm

Microsoft IIS 4.0 Security Checklist: http://www.micorosoft.com/security/products/iis/CheckList.asp

Stefan Norberg's excellent paper and tools for creating an NT bastion host (separate paper for HP/UX): http://people.hp.se/stnor/

AUSCert NT security suggestions: http://www.auscert.org.au/Information/Auscert_info/Papers/ win_configuration_guidelines.html, (US mirror, http://www.securityfocus.com/library/2335)

The World Wide Web Security FAQ by Lincoln D. Stein gro.lhsc|nietsl#gro.lhsc|nietsl http://www.w3.org/Security/Faq/

Rain Forest Puppy's Web site, with several IIS exploits: http://www.wiretrip.net/rfp/

เขียนโดย Pom infosec.sran.org 08/2544

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License