Secure Web Server
ผู้เขียน: ไพชยนต์ วิมุกตะนันทน์
ทุกวันนี้การที่ Web server สักเครื่องหนึ่งที่ให้บริการบน Internet จะถูกโจมตีจากผู้ไม่ประสงค์ดีถือเป็นเรื่องปกติธรรมดา จากข้อมูลของ zone-h.org พบว่า เฉพาะการโจมตีประเภท Defacement ที่มีการรายงานมาที่ zone-h.org ในปี 2011 และ 2010 มีถึงเกือบ 1.5 ล้านครั้งในแต่ละปี โดยเพิ่มขึ้นจากปีก่อนหน้า (2009 ลงไป) เกือบ 3 เท่าอาจจะดูไม่มากนักเมื่อเทียบกับจำนวน Web site ทั้งหมดที่มีมากกว่า 500 ล้านแห่งในปี 2011 แต่ต้องอย่าลืมว่า zone-h รายงานเฉพาะการโจมตีประเภท Defacement ที่มีการแจ้งมาโดยตรงเท่านั้น การโจมตีแบบอื่น (ที่อาจร้ายแรงกว่า) หรือการโจมตีที่ไม่ต้องการให้เป็นที่รับรู้ของสาธารณะชน หรือไม่ได้มีการแจ้งมาโดยตรง ก็จะไม่ได้รวมอยู่ใน 1.5 ล้านครั้งนี้ แต่ไม่ว่าจะมากหรือน้อย ผู้ที่อยู่ในแวดวงด้านความมั่นคงปลอดภัย หรือผู้ที่มีหน้าที่ดูแลเครื่องแม่ข่ายทั้งหลาย ก็คงทราบดีกว่า ปัจจุบันการโจมตีเว็บไซต์นั้น พบได้เกือบตลอดเวลา เพียงแค่ดูจาก Log file ของเครื่องแม่ข่ายเว็บ ก็อาจจะพบร่องรอยความพยายามในการโจมตีได้อย่างไม่ยากนัก ทั้งนี้ด้วยความรวดเร็วของการเผยแพร่ข้อมูลเกี่ยวกับช่องโหว่ใหม่ๆ และความสามารถของ Google ในการหาเครื่องแม่ข่ายเว็บที่เป็นเป้าหมายที่มีช่องโหว่นั้น เช่น บริการ "Google Dork" หรือ "Google Hacking Database: GHDB" ทำให้ผู้ดูแลระบบต้องพบกับความยุ่งยากในการ คอยติดตามข่าวสารเรื่องช่องโหว่และหาทางป้องกันเครื่องแม่ข่ายเว็บที่ตนดูแลอยู่มานักต่อนักแล้ว
ส่วนมาก จุดอ่อนของเครื่องแม่ข่ายเว็บ นั้นไม่ได้อยู่ที่ระบบปฏิบัติของเครื่องแม่ข่ายหรือซอฟต์แวร์สำหรับให้บริการเว็บ (Web Server) แต่อยู่ที่เว็บแอพพลิเคชั่น (Web Aplication) เป็นหลัก หากเว็บไซต์ใดมีข้อมูลเฉพาะ Static Web page หรือ Flat pageโดยไม่มีไฟล์สคริปต์ PHP, ASP หรือ Dynamic content ใดๆ อยู่เลยก็อาจจะเรียกได้ว่ามีความเสี่ยงน้อยมากที่จะถูกเจาระบบหรือโจมตีได้สำเร็จ ซึ่งการพัฒนาเว็บไซต์ที่ใช้งานเฉพาะ Static web page หรือ Flat page แทบจะเป็นไปไม่ได้เลยในยุคที่เว็บไซต์เปรียบเสมือนช่องทางหลักในการทำธุรกิจ หรือแม้แต่การเผยแพร่ข้อมูลโดยทั่วไปก็ยังมีการนำ Web application ประเภท CMS เข้ามาใช้เพื่อความสะดวกในการจัดรูปแบบเนื้อหาและให้ความสะดวกแก่ผู้ใช้บริการ ยิ่งหาก Web application เหล่านี้ซับซ้อนเท่าไหร่ ก็ยิ่งมีโอกาสที่จะพบช่องโหว่มากขึ้นเท่านั้น และเมื่อ Web application มีช่องโหว่ ก็เท่ากับระบบต่างๆที่ทำงานร่วมกับเว็บไซต์มีช่องโหว่ด้วย ซึ่งอาจจะทำให้เกิดจุดอ่อนกับระบบปฏิบัติการหรือแม้แต่เกิดจุดอ่อนกับเครื่องแม่ข่ายเครื่องอื่นๆ ที่อยู่บนเครือข่ายเดียวกันได้
คงไม่มีวิธีการใดที่สามารถป้องกันการโจมตีเว็บไซต์ได้อย่างสมบรูณ์ ผู้เชี่ยวชาญมักจะแนะนำให้เลือกใช้ Web application ที่เชื่อถือได้ และมีการ Update สม่ำเสมอ โดยเฉพาะในด้านความมั่นคงปลอดภัย แต่อย่าลืมว่าการ Update เหล่านี้ มักจะเกิดขึ้นหลังจากที่ผู้พัฒนาได้พบจุดอ่อนที่เกิดจากการโจมตีได้สำเร็จอยู่เสมอ หรือถึงแม้จะยังไม่มีการพบช่องโหว่ใน Web application ที่ใช้งานอยู่ก็ตาม ผู้ดูแลระบบก็ควรทราบว่า แม้แต่การ Configuration บางรูปแบบเพื่อตอบสนองความต้องการของ User ก็อาจทำให้เกิดช่องโหว่ขึ้นมาได้เช่นเดียวกัน
ดังนั้นเพื่อรักษาความมั่นคงปลอดภัยของเว็บไซต์ ทางทีมไทยเซิรต์ได้รวบรวมและนำเสนอแนวปฏิบัติในการดูแลเครื่องบริการเว็บ โดยอาศัยหลักการ Security in-depth กับพิจารณาถึงองค์ประกอบแวดล้อมในเครื่องบริการเว็บทั้งหมด โดยไม่เจาะจงลงไปในตัว Web application เพียงอย่างเดียว เพื่อลดโอกาสหรือลดความรุนแรงที่จะเกิดขึ้นเมื่อถูกโจมตี
คงไม่มีวิธีการใดที่สามารถป้องกันการโจมตีเว็บไซต์ได้อย่างสมบรูณ์ ผู้เชี่ยวชาญมักจะแนะนำให้เลือกใช้ Web application ที่เชื่อถือได้ และมีการ Update สม่ำเสมอ โดยเฉพาะในด้านความมั่นคงปลอดภัย แต่อย่าลืมว่าการ Update เหล่านี้ มักจะเกิดขึ้นหลังจากที่ผู้พัฒนาได้พบจุดอ่อนที่เกิดจากการโจมตีได้สำเร็จอยู่เสมอ หรือถึงแม้จะยังไม่มีการพบช่องโหว่ใน Web application ที่ใช้งานอยู่ก็ตาม ผู้ดูแลระบบก็ควรทราบว่า แม้แต่การ Configuration บางรูปแบบเพื่อตอบสนองความต้องการของ User ก็อาจทำให้เกิดช่องโหว่ขึ้นมาได้เช่นเดียวกัน
ดังนั้นเพื่อรักษาความมั่นคงปลอดภัยของเว็บไซต์ ทางทีมไทยเซิรต์ได้รวบรวมและนำเสนอแนวปฏิบัติในการดูแลเครื่องบริการเว็บ โดยอาศัยหลักการ Security in-depth กับพิจารณาถึงองค์ประกอบแวดล้อมในเครื่องบริการเว็บทั้งหมด โดยไม่เจาะจงลงไปในตัว Web application เพียงอย่างเดียว เพื่อลดโอกาสหรือลดความรุนแรงที่จะเกิดขึ้นเมื่อถูกโจมตี
1. ระมัดระวังเรื่อง Web server Process privilege ส่วนมาก Web application จะทำงานภายใต้สิทธิ์ (User ID) ของโปรเซส Web server ให้ลองจินตนาการว่า หาก Web application จะทำอันตรายระบบของเรา ด้วยสิทธิ์ที่เทียบเท่า Web server จะเกิดผลอย่างไรบ้าง ส่วนมากระบบปฏิบัติการรุ่นใหม่ๆ จะไม่ค่อยให้ Web server ทำงานในสิทธิผู้ดูแลระบบ (root หรือ Administrator) แล้ว แต่อาจจะต้องตรวจสอบดูให้แน่ใจอีกครั้งเป็นรายกรณีไป
2. จำกัดสิทธิ์ในการเขียนไฟล์ของ Web Application Web Application อาจจำเป็นต้องเขียนไฟล์ลงใน File system บ้าง เช่นในกรณีที่มีการ Upload ข้อมูล หรือเขียน Temp แต่ Web application ไม่จำเป็นต้องเขียนข้อมูลลงในทุกๆ Directory ดังนั้นควรจำกัดสิทธิ์ของ Web application ให้เขียนข้อมูลได้ในที่ๆ จำเป็นต้องเขียนเท่านั้น
3. แยกโซนอันตราย พื้นที่หรือ Directory ที่ Web Application ใช้เป็นพื้นที่สำหรับใช้งานชั่วคราว เช่นพื้นที่ Upload ข้อมูลจาก User ให้ถือว่าเป็นพื้นที่อันตราย เนื่องจากเราไม่สามารถรับประกันได้ว่าข้อมูลที่ User ใส่เข้ามาจะเป็น Malicious code หรือไม่ ดังนั้นการป้องกันไม่ให้ Execute หรือ Run ข้อมูลที่อยู่ในพื้นที่อันตรายนี้จึงเป็นสิ่งที่ต้องพิจารณาดำเนินการ
4. พิจาณาใช้งาน Chroot หรือ Jail (FreeBSD) ถ้าเป็นไปได้ ควร Chroot หรือ Jail Web serverเพื่อป้องกันไม่ให้ Web application สามารถเข้าถึงไฟล์อื่นๆบนระบบปฏิบัติการได้โดยอิสระ การใช้ MAC (Mandatory Access Control) หรือ RBAC (Role-Based Access Control) เช่น SELinux, AppArmor , Tomoyo หรือ Grsecurity ก็เป็นอีกทางเลือกที่ผู้ดูแลระบบน่าจะพิจารณาเลือกใช้ได้
5. ควบคุมการใช้งาน Script คล้ายกับข้อ 3 แต่เป็นข้อกำหนดในเชิง Web programming คือการกำหนดให้ Script หรือ Web application code สามารถ Run หรือ Execute ใน Directory ที่กำหนดไว้เท่านั้น เพื่อลดความเสี่ยงที่จะโดนโจมตีในโซนพื้นที่อันตรายเช่น พื้นที่สำหรับเก็บรูปภาพ ที่มีโอกาสถูกอัพโหลดไฟล์ Malicious code จากผู้ไม่ประสงค์ดี ประกอบกับการใช้ช่องโหว่ในการเข้าโจมตีแบบ Remote File Inclusion ที่สั่งให้ Run ไฟล์บน Directory ต่างๆได้ โดยใช้หลักการ Include file
6. จับตาดู Error message 404/403 response อาจเป็นเรื่องปกติที่พบได้ทั่วไปใน Log ของ Web server แต่ถ้าพบในจำนวนมาก ในระยะเวลาสั้นๆ อาจแสดงถึงความพยายาม Scan หรือ Probe จากผู้ไม่ประสงค์ดี แต่ในปัจจุบันที่มีการใช้ Botnet กันอย่างกว้างขวาง Request เหล่านี้ อาจจะไม่ได้มาจาก IP เดียวกันก็ได้ จึงจำเป็นต้องระมัดระวังในการพิจารณาเป็นพิเศษ
7. ควบคุม Web server ในการเรียกข้อมูลภายนอก Web server ไม่ควรมีความจำเป็นต้องเรียกข้อมูลจาก Internet โดยตรง หากมีความจำเป็นต้องดึงข้อมูลมา Update ควรให้ทำผ่าน Proxy และมีการควบคุม URL ปลายทางอย่างเคร่งครัด และควรมีการ Monitor การเรียกข้อมูลที่นอกเหนือจากที่กำหนดด้วย เพราะอาจแสดงให้เห็นว่าผู้ไม่ประสงค์ดี สามารถควบคุม Web server เอาไว้ได้แล้ว
8. Privilege ของ Database user ก็สำคัญ Web application แต่ละตัว ควรใช้ User บน Database ที่แตกต่างกัน เพื่อความสะดวกในการ Audit และแยกสิทธิ์การเขียน/อ่าน ข้อมูลด้วย ถ้า Web application ตัวใดไม่ต้อง Update ข้อมุลใน Database อย่าให้ User ของ Web appliaction นั้นมีสิทธิ์เขียนข้อมูลเด็ดขาด และควรจำกัดสิทธิ์การในระดับ Table ด้วยถ้าเป็นไปได้ วิธีการนี้จะช่วยลดความรุนแรงของการโจมตีประเภท SQLi (SQL Injection) ได้
9. พิจารณา Data type ของ Web application parameter การพัฒนา Web application ที่ดี ควรจำกัดและตรวจสอบชนิดของข้อมูลที่รับส่งกับ User ทุกครั้ง เช่นถ้าข้อมูลที่จะรับเข้ามาเป็น ID ของบทความ ก็ไม่ควรยอมให้มีข้อมูลอื่นนอกจาก Digit เข้ามาใน Parameter นั้น หรือถ้าเป็น Alphanumeric ก็ไม่ควรให้มีสัญลักษณ์เข้ามาปะปน เป็นต้น
10. จับตาดูการเปลี่ยนแปลง เครื่องมือสำหรับตรวจสอบการเปลี่ยนแปลงของไฟล์อย่าง Tripwire หรือ AIDE เป็นเครื่องมือที่ดีที่จะใช้บอกว่ามีสิ่งไม่ชอบมาพากลขึ้นใน Web server เพราะบางครั้ง ผู้ไม่ประสงค์ดีจะทิ้งโปรแกรมประเภท Backdoor ไว้เพื่อให้สะดวกในการควบคุม Web server หรืออาจเป็นการติดตั้งโปรแกรมประเภท Trojan หรือ Bot ก็ได้ แต่ควรใช้อย่างระมัดระวัง เพราะการเปลี่ยนแปลงของไฟล์ในระบบบางอย่าง อาจไม่ได้หมายถึงสิ่งผิดปกติก็ได้ เช่น Log หรือ Temp ที่มีการเปลี่ยนแปลงอยู่เป็นปกติอยู่แล้ว
11. ถือว่าข้อมูลจาก Client เป็น Untrusted Script อะไรก็ตามที่ทำงานในฝั่ง Client เช่น Javascript หรือแม้แต่ Flash หรือ Java ทั้งหลายเหล่านี้อาจจะถูก Compromise ได้ไม่ยาก เพราะฉะนั้น Web application ที่ดีไม่ควรใช้วิธีการตรวจสอบการส่งข้อมูลโดยวิธีการเหล่านี้เป็นอันขาด เช่น การใช้ Javascript ตรวจสอบข้อมูลที่ User ป้อนเข้ามา เพราะผู้ไม่ประสงค์ดีสามารถ Bypass การตรวจสอบนี้ได้อย่างง่ายดายจากโปรแกรมทั่วไป เช่น NoScript หรือแม้แต่สิ่งที่รับมาจาก Client เช่นค่าจากตัวแปรต่างๆ ก็ควรสงสัยไว้ก่อนว่ามีโอกาสเป็นข้อมูลไม่พึงประสงค์ได้
12. ควรเลือกใช้เครื่องมือที่ชำนาญ การเลือกใช้เครื่องมือต่างๆ เช่น Web server, Web application platform หรือ CMS ควรเลือกที่ความคุ้นเคยมากกว่าความสวยงามหรือทันสมัย เพราะเวลามีปัญหาจะสามารถเข้าตรวจสอบและแก้ไขได้ง่าย และอย่าลืมว่าเครื่องมือที่ดีกว่าหรือใหม่กว่า ไม่ได้แปลว่าจะไม่มีโอกาสเกิดปัญหาเลย หรือในอีกมุมหนึ่งการใช้งานเครื่องมือที่พัฒนาขึ้นใหม่อาจเหมือนเป็นหนูทดลองสำหรับการทดสอบผลิตภัณฑ์ก็เป็นได้ ซึ่งจะก่อให้เกิดปัญหาด้านความมั่นคงปลอดภัยตามมา
13. พยายามทำตามมาตรฐาน การเข้ารหัสแบบคิดค้นเอง การจัดการ Session แบบไม่มีมาตรฐาน หรือแม้แต่การพัฒนา Web application ในรูปแบบแปลกๆ มักจะเกิดปัญหาได้ง่ายกว่าแบบเดิมที่นิยมใช้กัน หลายคนเชื่ออย่างผิดๆ ว่าการใช้สิ่งที่คนทั่วไปใช้กัน หรือการใช้ Opensource/Open Standard ที่เปิดโอกาสให้คนเห็น Source code หรือ Algorithm อย่างเปิดเผยนั้นไม่มีความมั่นคงปลอดภัย แต่ก็ต้องอย่าลืมว่า โปรแกรมเข้ารหัสที่ยอมรับกันว่าปลอดภัยที่สุดในขณะนี้ก็เป็น Open standard อยู่ เช่น OpenSSL
14. ไม่ควรแสดง Error message ให้ User เห็น ข้อผิดพลาดของ Web application (Error message) ที่แสดงให้คนอื่นเห็นโดยไม่ตั้งใจ ถือเป็นเรื่องที่รับไม่ได้และน่าอับอายสำหรับคนพัฒนา Web application เพราะแสดงให้ถึงความไม่เป็น Professional ซ้ำร้ายยังกลายเป็นผู้สนับสนุนข้อมูลในการเข้าโจมตีเว็บไซต์จากข้อมูลที่แสดงออกไปอีกด้วย เช่น ข้อผิดพลาดแสดงที่อยู่ของไฟล์ในระบบ หรือชื่อของ Database เป็นต้น เพราะฉะนั้น Web application ที่ดี ต้องไม่แสดง Error message ออกมาให้เห็นเมื่อเกิดความผิดพลาด ซึ่งการจัดการ Exception ที่ดีในถือเป็นอีกวิธีหนึ่งที่จะลดปัญหาข้อนี้
15. จับตาการ Re-attempt โดยปกติ คนที่ลืม Password ย่อมไม่อดทนใส่ Password ที่ผิดเป็นสิบๆ ครั้งต่อเนื่อง เช่นเดียวกับคงไม่มีใครส่งค่า Parameter ตัวเดียวไปเรื่อยๆ อย่างต่อเนื่องเช่นกัน การ Re-attempt ในลักษณะนี้ อาจเกิดจากเครื่องมือพิเศษที่ใช้หาช่องโหว่ของระบบ (Brute Force) หรือเครื่องมือเดา Password มากกว่า
16. Web application ตัวอื่นก็สำคัญ Web application ที่เขียนขึ้นอย่างดี มีความมั่นคงปลอดภัยสูง แต่เมื่อไปอยู่ร่วมกับ Web application ที่มีช่องโหว่ บน Web server ตัวเดียวกัน ย่อมมีความเสี่ยงที่เกิดขึ้นเทียบเท่ากัน เว้นแต่ Web server จะมีการแยก Privilege ระหว่าง Web application แต่ละตัวได้ เช่น การใช้ suEXEC
ขอบคุณแหล่งข้อมูลจาก : https://www.thaicert.or.th/papers/technical/2012/pa2012te001.html#one