จากตอนที่แล้วเราพบว่าการทำ Penetration test นั้นมีความสำคัญกับการที่จะประเมินหาช่องโหว่ที่เกิดขึ้นจากการใช้งานไอซีที ของบริษัทแล้วนั้น ตอนนี้มาทำความเข้าใจมากขึ้นอีกชนิดหนึ่งของการทำ Penetration test นั้นคือการทำ Penetration test ภายในองค์กร หรือจะเรียกว่า white box ก็ได้ ซึ่งการทำงานประเภทนี้ต้องได้รับความร่วมมือกับผู้ดูแลระบบของฝั่งผู้ใช้บริการ ตั้งแต่การให้แผนผังระบบเครือข่าย จำนวน IP Address ตลอดถึงรายละเอียดประเภทอุปกรณ์เครือข่ายที่เกี่ยวข้อง เป็นต้น เริ่มกันถึงตอนที่ 2 ต่อเนื่องเลยแล้วกันครับ
2. การทำ Penetration test ภายในองค์กรเชิงลึก
เป้าหมายในการทำ Penetration test ภายในคือการทดสอบหาช่องโหว่ที่พบจากการใช้งานไอซีทีในองค์กรเพื่อประเมินช่องโหว่และทำการปิดกั้นช่องโหว่ที่ค้นพบขึ้นเพื่อไม่เกิดปัญหาขึ้นในระยะยาว
มีขั้นตอนการทำงานดังนี้
2.1 สำรวจ : สำรวจผังโครงสร้างงานได้ไอซีทีขององค์กร, แผนผังระบบเครือข่าย, ประเภทอุปกรณ์ประกอบด้วย
- Network Device ได้แก่ จำนวนอุปกรณ์ Router , อุปกรณ์ Switch, อุปกรณ์ Firewall, Network Load balacing, Network VPN, Bandwidth management, อุปกรณ์ Network IDS/IPS
ซึ่งต้องบอกตำแหน่ง (Perimeter zone , DMZ zone) และค่า IP Address เป็นต้น
- เครื่องแม่ข่าย (Server) ได้แก่ Web Server, Mail Server , DNS Server ภายใน, Proxy Server, Authentication Server, ERP Server ซึ่งต้องบอกตำแหน่ง (DMZ zone) และค่า IP Address เป็นต้น
- เครื่องลูกข่าย (Client) ได้แก่ ระบบปฏิบัติการที่ใช้งานได้แก่ Window XP , Linux อื่นๆ ต้องบอกตำแหน่ง (VLAN) และค่า IP Address เป็นต้น
2.2 ตรวจสอบ : ตรวจสอบตามมาตราฐาน Security Checklist ดังนี้
ตรวจสอบความมั่นคงปลอดภัยตามมาตราฐานของ อุปกรณ์ Network Devices ได้แก่ Security Checklist Router , Firewall , IDS/IPS เป็นต้น
ตรวจสอบความมั่นคงปลอดภัยตามมมาตราฐานของ เครื่องแม่ข่าย (Server) ได้แก่ Security Checklist Windwos 2000 server , 2003 server , Linux Server เป็นต้น
ตรวจสอบความมั่นคงปลอดภัยตามมาตราฐานของ เครื่องลูกข่าย (Client) ได้แก่ Security Checklist การใช้งานเครื่องคอมพิวเตอร์ในองค์กรตามมาตราฐาน ISO27001 เป็นต้น
ซึ่งในส่วน security checklist นั้นทางผู้ปฏิบัติงานสามารถนำข้อมูลจาก NIST , NSA หรือ Thaicert ในเอกสารตรวจสอบในแต่ละส่วนได้
2.3 วิเคราะห์ : การวิเคราะห์ช่องโหว่ที่พบจากการสำรวจและตรวจสอบ
ในการวิเคราะห์นี้สามารถใช้อุปกรณ์ หรือ เครื่องมือในการประเมินความเสี่ยงเพื่อตรวจหาความผิดปกติและช่องโหว่ที่พบตามอุปกรณ์เครือข่าย (Network Devices) และเครื่องแม่ข่าย (Server) ที่สำคัญได้
การใช้เครื่องมือในการประเมินความเสี่ยง สิ่งที่ควรตรวจสอบให้มากขึ้นได้แก่
* การวิเคราะห์ในระดับเครือข่ายคอมพิวเตอร์ (Network Analysis)
- ปริมาณการใช้งาน Bandwidth ของระบบเครือข่าย ทั้งข้อมูลขาเข้าและขาออก
- ปริมาณ Throughput ของระบบเครือข่ายทั้งขาเข้าและขาออก แยกตาม Application Protocol ที่สำคัญ
ด้วยเนื่องจากจะช่วยตรวจสอบถึงการใช้งานอันไม่พึ่งประสงค์ของ User ในองค์กร ว่ามีการแพร่ระบาดไวรัสคอมพิวเตอร์ , เครื่อง User เป็น Botnet , การส่งข้อมูลขยะ (spam) หรือมีพฤติกรรมที่ผิดต่อนโยบายบริษัทหรือไม่อีกด้วย ซึ่งในส่วนนี้เราจะสามารถนำไปวิเคราะห์เป็นค่าภัยคุกคามในองค์กร ที่ใช้ประกอบกับขั้นตอนสุดท้ายคือการประเมินได้ต่อไป
** การวิเคราะห์ในระดับอุปกรณ์เครือข่ายและเครื่องแม่ข่ายที่สำคัญ
- ทำการใช้เครื่องมือประเมินความเสี่ยงเพื่อตรวจดู Port Services ที่อุปกรณ์เครือข่าย และ เครื่องแม่ข่ายที่สำคัญเปิดอยู่
- วิเคราะห์ช่องโหว่จากการใช้เครื่องมือหลังจากตรวจ Port Services แล้วจะพบว่า Services ที่ทำการใช้งานอยู่บนอุปกรณ์เครือข่ายและเครื่องแม่ข่ายที่สำคัญ นั้นมีการเปิดใช้งานอยู่ นั้นมีความช่องโหว่ที่เป็นภัยรุนแรงหรือไม่ เช่น เปิด Port services 80 TCP เป็น Application Protocol ของ HTTP ซึ่งในนี้ประกอบด้วย Web Server ที่ใช้งานอยู่ที่เป็น IIS , Apache , หรืออื่นๆ ซึ่งหากเป็น Version ที่มีช่องโหว่ หรือมี code exploit ที่สามารถส่ง command หรือ script จากทางไกลและสามารถยึดครองเครื่องนั้นได้ก็จะถือว่าเป็นระดับภัยคุกคามที่รุนแรง เป็นต้น
- วิเคราะห์หา Security Patch ที่อัพเดทล่าสุดเพื่อเสริมสร้างความมั่นคงปลอดภัยให้กับอุปกรณ์เครือข่าย และ แม่ข่ายที่สำคัญ โดยทั้งนี้ควรทำการเตรียมแผนทดสอบถึงผลกระทบก่อนการอัพเดท Security Patch ก่อน
4. ประเมิน : ขั้นตอนนี้จะเป็นการสรุปผลความเสี่ยงที่พบจากขั้นตอนที่ผ่านมา โดยทำเป็นค่าดัชนีชี้วัดความเสี่ยง และผลการปฏิบัติงาน รวมถึงแนวทางในการปิดกั้นส่วนที่เป็นช่องโหว่ (Hardening) และป้องกันในระยะยาว ซึ่งในส่วนนี้จะเน้นไปทางการทำรายงานผล ในรูปแบบเอกสาร
ขยายความค่าดัชนีชี้วัดความเสี่ยงเกิดจาก Risk = Vulnerability x Threat
ค่าความเสี่ยงที่ประเมินได้ ขึ้นอยู่กับนโยบายขององค์กรด้วย หาดูแล้วไม่กระทบกับธุรกิจมากค่าความเสี่ยงนั้นก็จะแปรผันไปกับการประเมินความเสี่ยงของผู้ปฏิบัติงาน (Penetration tester) ซึ่งในแต่ละที่อาจมีค่าการประเมินไม่เหมือนกัน
เช่น ในกรณีที่พบว่า พบช่องโหว่ Web Server ที่ระบบ IIS 6.0 ที่ยังไม่ได้อัพเดท Patch security เมื่อประเมินแล้วว่า Web Server นั้นไม่สามารถเข้าถึงได้จากอินเตอร์เน็ต และเป็นเครื่องเฉพาะในแผนกใดแผนกหนึ่งดังนั้นระดับความสำคัญที่เป็นภัยคุกคามที่รุนแรงก็จะน้อยกว่าเครื่อง Web Server ที่เผยแพร่ข้อมูลสาธารณะ (Public IP) ได้เป็นต้น ซึ่งค่าดัชนีชี้วัดส่วนนี้ขึ้นกับผู้ปฏิบัติงานในการทำ Penetration Test และประสบการณ์ รวมถึงความเขี่ยวชาญของบุคคลนั้นในการประเมิน บางครั้งการให้บริษัทต่างที่กันมาประเมินหาความเสี่ยง ก็อาจมีค่ารายงานผลไม่เท่ากันเสมอไป ขึ้นอยู่กับทีมปฏิบัติงาน ซึ่งหากในทีมมี Certification ด้าน Security แทบไม่มีผลหากผู้ปฏิบัติงานหากขาดประสบการณ์ในส่วนการวิเคราะห์และประเมินค่าความเสี่ยงนี้ได้
สรุปได้ว่าค่า Vulnerability (ช่องโหว่ที่ค้นพบ จาก อุปกรณ์เครือข่ายที่สำคัญ และเครื่องแม่ข่ายที่สำคัญ) จะมีระดับความเสี่ยง สูง กลาง และต่ำ หรืออาจจะมีรายละเอียดมากกว่านั้น
ค่า Threat (ภัยคุกคาม) ขึ้นกับนโยบายองค์กร และการประเมินค่าจะผู้ปฏิบัติงาน นำมารวมค่ากันแล้วจะได้เป็นดัชนีชี้วัดความเสี่ยงได้ ซึ่งการประเมินส่วนนี้ก็เป็นเทคนิคลับของแต่ละบริษัทที่ใช้ในการประเมินและสามารถวัดผลได้จริงในทางปฏิบัติ
มาถึงตรงนี้บอกได้ว่าการประเมินความเสี่ยงนั้นไม่สามารถที่สิ้นสุดการทำงานได้จากการใช้เครื่องมือ (tools) มาแล้วจะสรุปค่าความเสี่ยงที่เกิดขึ้นจากการใช้งานไอซีทีองค์กรได้จำเป็นต้องอาศัยคนวิเคราะห์ถึงระดับภัยคุกคามและผลลัพธ์รายงานที่มีประโยชน์ต่อบริษัทเพื่อใช้ในการปรับปรุงแก้ไขให้ระบบมีความแข็งแรงและมีความปลอดภัยขึ้น
นนทวรรธนะ สาระมาน
Nontawattana Saraman
05/10/52
วันจันทร์, ตุลาคม 5
การทำ Penetration Test แบบมืออาชีพ ตอนที่ 1
หลายคนคงสงสัยว่า Penetration Test กับ Vulnerability Assessment มันแตกต่างกันอย่างไง วันนี้เราสามารถกระจ่างกับ 2 ศัพท์นี้กัน
คำว่า Penetration test คือการทดสอบเพื่อหาช่องทางในการเข้าถึงระบบ (Exploit) ซึ่งการเข้าถึงระบบโดยผ่านช่องโหว่ที่พบอาจเป็น 0day ที่ยังไม่พบการแจ้งเตือนจากผู้ผลิต (Vendor) และการกระทำใดๆที่อาจทำให้ผู้ว่าจ้างได้ทราบถึงความเสี่ยง เสมือนปฎิบัติจริงการเป็นแฮกเกอร์เพื่อเจาะระบบ
ส่วนคำว่า Vulnerability Assessment คือ การประเมินหาความเสี่ยงที่เกิดจากช่องโหว่ที่ค้นพบ ตามช่องโหว่ที่มีความเสี่ยง ซึ่งส่วนใหญ่แล้วเป็นความเสี่ยงที่ปรากฎต่อสาธารณะแล้วตาม CVE (Common Vulnerabilities and Exposures)
ความแตกต่างทั้ง 2 คำนี้ก็คือ Pen-test นั้นคือการทดสอบเจาะระบบแบบแฮกเกอร์ เพื่อประเมินความเสี่ยงของธุรกิจหรือองค์กรนั้น ส่วน VA จะเน้นตรวจหาช่องโหว่ที่เป็นสาธารณะที่มีการเผยแพร่ช่องโหว่นั้นแล้ว เพื่อไม่ให้ถูกโจมตีจากผู้ไม่ประสงค์ดีได้ ทั้งคู่นี้จำเป็นต้องออกรายงานถึงระดับความเสี่ยงให้ผู้ว่าจ้างนั้นได้รู้ถึงภัยอันตรายที่อาจเกิดขึ้น
ดังนั้นหากเราพิจารณาดีๆ แล้วการทำ Penetration test จะเกิดก่อนการทำ Vulnerability Assessment อยู่ยกเว้นในบางกรณีที่ลูกค้าหรือผู้ใช้บริการทราบถึงช่องโหว่แล้วแต่ยังไม่สามารถประเมินค่าช่องโหว่ได้ตรงนี้ก็จะกระโดดไปทำ Vulnerability Assessment ได้ทันที แต่หากไม่สามารถระบุช่องโหว่อะไรได้เลยสิ่งแรกที่เราควรทำคือการทดสอบเจาะระบบเพื่อหาช่องทางในการเข้าถึงระบบเสียก่อน จึงเกิดเป็นการทำ Penetration test
การทำ Penetration test และ Vulnerability Assessment มีหลักการง่ายๆ ที่ทางทีมงาน SRAN ได้รวบรวมและสรุปเป็นขั้นตอนการปฏิบัติงานที่กระชับขึ้นและสามารถใช้ได้ทุกสถานะการณ์โดยสามารถแบ่งเป็นเนื้องานได้ดังนี้
การทำ Penetration test (การทดสอบเจาะระบบในเชิงลึก) ทั้งที่เกิดจากภายนอกระบบและภายในระบบเครือข่ายองค์กร ซึ่งการทำงานประเภทนี้ควรได้รับการอนุญาตจากบริษัท,องค์กรที่ว่าจ้างและมีการทำสัญญาการไม่เผยแพร่ความลับ และให้ดีกว่านั้นคืออาจต้องมีการเตรียมการกับผู้ดูแลระบบบริษัท , องค์กรให้ทราบถึงช่วงเวลาในการปฏิบัติงานที่แน่นอน เพื่อจะได้ระบุได้ว่าการโจมตีเกิดจากการทดสอบเจาะระบบจากทีมงานไม่ใช่นักโจมตีระบบอื่นที่ไม่เกี่ยวข้องในงาน ซึ่งส่วนนี้หากองค์กรมีระบบตรวจจับผู้บุกรุก IDS (Intrusion Detection System) ไม่ว่าเป็นระดับ Network หรือ Host base ก็จะเห็นความผิดปกติที่เกิดจากการทำการประเมินความเสี่ยงได้จาก Log ที่เกิดขึ้นบนอุปกรณ์ ซึ่งสามารถลัดขั้นตอนการทำประเมินความเสี่ยงโดยใช้อุปกรณ์ประเภทที่สามารถวิเคราะห์ Log files ที่เกิดบนระบบเครือข่ายคอมพิวเตอร์ได้ในที่นี้เราแนะนำใช้ NetApprove
1. การทำ Penetration Test จากภายนอกระบบเครือข่ายองค์กร หรืออาจเรียกว่าการทำ Black Box ก็ได้ คือ การใช้เครื่องคอมพิวเตอร์จำลองเป็นนักโจมตีระบบเพื่อหาทางเข้าสู่ระบบเครือข่ายองค์กรที่ให้ทำการประเมินความเสี่ยง โดยมีขั้นตอนดังนี้
1.1 สำรวจ : ตรวจหาเครือข่ายเป้าหมายในการปฏิบัติงาน เช่นบริษัท XYZ ต้องการให้ทำ Penetration test เพื่อดูว่าเครือข่ายองค์กรบริษัทมีช่องทางใดที่เป็นช่องโหว่และมีโอกาสที่ถูกโจมตีจากภายนอกได้
- การค้นหาข้อมูลบริษัท XYZ กับช่องทางการเชื่อมต่ออินเตอร์เน็ต โดยใช้เครื่องสาธารณะ และซอฟต์แวร์ในการค้นหาข้อมูล ซึ่งประกอบด้วย การค้นหาช่องทางสาธารณะได้แก่การ whois ชื่อ Domain name บริษัท XYZ ที่ทำการเปิดข้อมูลในสาธารณะเช่น เว็บไซต์ บริษัท อีเมลล์บริษัท เป็นต้น สิ่งที่ได้ตรงนี้คือเราจะทราบถึง รายชื่อผู้จดทะเบียนชื่อเว็บไซต์รของบริษัท ที่อยู่ เบอร์โทรศัพท์ที่ใช้ในการติดต่อ วันหมดอายุของ domain เว็บไซต์บริษัทนั้นได้ วิธีอาจจะไม่ได้รับข้อมูลทั้งหมดเนื่องจากสมัยนี้ได้มีการปิดข้อมูลชื่อผู้จดทะเบียนเว็บไซต์ และข้อมูลอีเมลล์ในการติดต่อได้
ผลลัพธ์ที่ได้จากการค้นหาข้อมูลสาธารณะนั้น คือ รายชื่ออีเมลล์ของผู้จดทะเบียนเว็บไซต์ ซึ่งปกติหากมีการจดทะเบียนควรตั้งชื่อเป็น pool e-mail ไม่ควรใช้ชื่อใครคนใดคนหนึ่งในองค์กรเป็นคนจดทะเบียนเว็บไซต์ ก็เพื่อว่าหากมีการโยกย้ายงาน หรือคนที่จดทะเบียนนั้นไม่อยู่ในบริษัทแล้วก็จะทำให้การอัพเดทข้อมูลในการจดทะเบียนเว็บไซต์เป็นไปอย่างยากลำบากขึ้น อีกทั้งหากเป็นชื่อ domain name ของเว็บไซต์ที่มีความสำคัญบุคคลที่จดทะเบียนเว็บไซต์ก็อาจจะมีความเสี่ยงที่นักโจมตีระบบจะใช้ช่องทาง e-mail เป็นการปลอมตัวเพื่อเข้าไปเป็นผู้จดทะเบียนเว็บไซต์ได้จากวิธีการเดา password หรือส่ง Trojan ไปที่ e-mail บุคคลนั้นเพื่อได้มาซึ่ง domain name ที่ได้ลงทะเบียนไว้ ถือว่าเป็นการยึด domain nameได้เช่นกัน ในปัจจุบันก็พบกันบ่อยๆว่ามีการยึด domain name เป็นตัวประกันเช่นกัน ในการค้นหาข้อมูลบริษัท XYZ ยังสามารถใช้เครื่องมือในการเรียกใช้บริการ DNS ที่ผู้จดทะเบียนเว็บไซต์นั้นได้เช่น DNS เชื่อมโยงไปยังที่ใด ฝากไว้กับ ISP หรือตั้ง DNS Server เอง ซึ่งส่วนนี้จะสามารถค้นหาช่องโหว่ที่เกี่ยวข้องกับการใช้บริการ DNS Server ได้โดยตรวจสอบหา Zone Transfer เพื่อดูความสัมพันธ์อื่นจากชื่อ domain อื่นที่พบ เช่น www.xyz.com พบว่ามี DNS ที่เกี่ยวข้องคือ mail.xyz.com , ns1.xyz.com , ns2.xyz.com เป็นต้นก็จะทำให้เครื่องเป้าหมายที่เราจะทำการ Penetration test เพิ่มช่องทางการเข้าถึงได้ถึง 3 เครื่องจากในตัวอย่างนี้ที่กล่าวไป
ในการใช้ข้อมูลสาธารณะนั้นยังมีอีกมากมาย เช่นตรวจสอบสถานะ Link ของเว็บไซต์ เพื่อดูความสัมพันธ์ของข้อมูล , ตรวจสอบหา e-mail ของ domain จากเครื่องมือค้นหา (search engine) เพื่อดูพฤติกรรมการใช้ข้อมูลองค์กร ในกรณีก็ค้นหาคำว่า @xzy.com เพื่อว่าจะเข้าถึงระบบจาก e-mail พนักงานในองค์กรได้อีกทาง ซึ่งหากทำ Penetration test ควรจะแจ้งให้บริษัทรับทราบถึงวิธีการดังกล่าวด้วย ไม่เช่นนั้นอาจผิดตามกฏหมายคอมพิวเตอร์ฯได้เช่นกันหากมีการตรวจสอบพบ
- สำรวจช่องทางการเข้าถึงเครือข่ายองค์กร โดยวิธีการนี้ต่อยอดจากการแบบแรก ซึ่งเน้นไปทางการค้นหาเส้นทางการเดินทางของข้อมูล (Route) ของบริษัท Xyz เพื่อออกสู่อินเตอร์เน็ตภายนอก หากพบว่าช่วง IP Address ที่เป็น Public IP ของบริษัทนั้นที่ค่ามาจาก ISP ก็จะทำให้มีช่องทางการเข้าถึงมากขึ้นจากเดิม ซึ่งจะทำให้นักโจมตีระบบสามารถใช้เทคนิคการตรวจสอบได้มากขึ้นเช่นการทำ DDoS/DoS กับช่วง IP ที่บริษัทได้รับมาเป็นต้น
สรุปได้ว่าในขั้นตอน สำรวจ นั้นจะต้องหาข้อมูลเกี่ยวข้องกับบริษัทที่ให้ประเมินความเสี่ยงมากที่สุด เพื่อหาช่องทางในการเข้าถึงระบบได้หลากหลายช่องทางขึ้น
1.2 ตรวจสอบ : เมื่อเราทำการรวบรวมข้อมูลที่ได้มาจากขั้นตอนสำรวจนั้น ก็จะทำการวาดรูปความสัมพันธ์เครือข่ายองค์กรออกมาพร้อมกำหนดจุดที่ทำการตรวจสอบขึ้น การตรวจสอบมักจะใช้ check list ตามมาตราฐาน หรือใช้เครื่องมือในการตรวจสอบ ในกรณีนี้เป็นการทำ Penetration test จากภายนอก สิ่งที่ตรวจสอบได้แก่
- Information leak จากขั้นตอนที่หนึ่ง เช่น รายชื่อผู้จดทะเบียนเว็บไซต์, e-mail, รายชื่อ DNS ที่มีความสัมพันธ์กับบริษัท, ข้อมูลรั่วจากการใช้งานอินเตอร์เน็ตได้แก่ e-mail พนักงานในการโพสข้อมูล, Link ของเว็บไซต์บริษัทที่ทำให้ได้ข้อมูลอื่นๆเป็นต้น
- Web Application checklist ตรวจสอบช่องโหว่ที่พบจากเว็บไซต์ในกรณีคือ www.xyz.com ว่ามีช่องโหว่ในการเข้าถึงระบบผ่าน Web application จากมาตราฐาน OWASP เป็นต้น รายละเอียดการตรวจสอบเบื้องต้นสามารถอ่านได้ที่ http://nontawattalk.blogspot.com/2009/09/layer-7-3.html
- DNS server checklist ตรวจสอบค่า Domain name server ที่แสดงข้อมูลสาธารณะ
- E-mail Server checklist ตรวจสอบค่าการใช้งาน E-mail server ที่แสดงข้อมูลสาธารณะ เช่นกรณีที่ บริษัท XYZ จัดทำ Mail server เองขึ้นการตรวจสอบจะตรวจว่า Mail server ของบริษัทนั้นจะมีโอกาสจดหมายขยะจะเข้าถึงได้หรือไม่เป็นต้น
- Network Topology checklist ตรวจสอบการเชื่อมต่ออินเตอร์เน็ตบริษัท เส้นทางการ route ข้อมูลจำนวน Linkของ ISP ที่บริษัท xyz ใช้บริการ ซึ่งส่วนนี้จะเน้นไปการทดสอบ DDoS/DoS ว่าทางบริษัท xyz มีการควบคุมการโจมตีชนิดนี้ได้หรือไม่ ซึ่งจะสะท้อนให้เห็นถึงความพร้อมโครงสร้างเครือข่าย (Network) ของบริษัทว่าได้มีการจัดเตรียมเทคโนโลยีด้านความมั่นคงปลอดภัยครบถ้วนในส่วน Perimeter network เช่นได้มีการจัดทำ ACL (Access Control List) ค่า Blacklist ในอุปกรณ์ Router หรือ Firewall , มีอุปกรณ์ Firewall ที่ป้องกันทางเครือข่ายในระดับ stateful inspection หรือไม่ เป็นต้น
- ตรวจสอบ Port services จากข้อมูลในขั้นตอนสำรวจ เช่น เราพบ IP Address ของเว็บไซต์บริษัท , e-mail , DNS server, Router ก็ทำการตรวจสอบว่ามี Port services อะไรที่ทำการเปิดไว้เพื่อจะทำการขยายผลต่อในขั้นตอนต่อไป
1.3 วิเคราะห์ : เมื่อทำการตรวจสอบจากการสำรวจและตรวจสอบ ภายนอกเครือข่ายองค์กรแล้วนำข้อมูลเหล่านั้นมาทำการวิเคราะห์เพื่อศึกษาว่าพบช่องโหว่และการเข้าถึงข้อมูล เช่น จากการตรวจสอบ Port services พบว่ามีการเปิด Port ที่มีช่องโหว่และสามารถเข้าถึงระบบจากภายนอกได้ ผ่านการให้บริการ Web server port 80 ช่องโหว่ที่พบคือ มีการใช้ Web server version เก่าและมี tools ในการเข้าถึงระบบ (Exploit) ผ่านช่องโหว่นี้ได้ หรือ ใน Web server เปิด port 1433 เป็นการเปิด port SQL server เป็น Data base บนเครื่อง Web server และมี exploit ที่เข้าถึงระบบได้ เป็นต้น
ในขั้นตอนวิเคราะห์จะลงรายละเอียดถึงการเข้าถึงระบบจากภายนอก เป็นส่วนๆจากขั้นตอนสำรวจและตรวจสอบ เช่น ส่วนของ Web server , ส่วนของ E-mail Server , ส่วนของ DNS server และส่วนของ Router เป็นต้น
1.4 ประเมิน : ในส่วนนี้ผมขอเรียกว่า Vulnerability Assessment เมื่อทำการวิเคราะห์ถึงช่องโหว่ที่พบแล้ว ถึงขั้นตอนสุดท้ายคือการประเมิน ว่าช่องโหว่ที่พบนั้นมีความเสี่ยงและมีผลกระทบต่อธุรกิจองค์กรอย่างไร
ส่วนใหญ่เป็นเอกสารการแนะนำและการปิดช่องโหว่ที่พบ
สูตรการหาค่าความเสี่ยงต่อธุรกิจองค์กร Risk = Vulnerability x Threat หรือบ้างครั้งอาจจะเห็นเป็นสูตร
Risk = Vulnerability x Threat x cost การประเมินความเสี่ยง (Risk Assessment) สามารถมองได้ 2 แบบคือด้านมหาภาคภาพรวมองค์กร ที่ต้องดูถึง 3P คือ
Vulnerability คน กระบวนการ และเทคโนโลยี
Threat จากคน กระบวนการและเทคโนโลยี
และ จุลภาคคือทางด้านเทคนิคอย่างเดียว คือมอง Vulnerability และ Threat เฉพาะทางเทคโนโลยี
และทั้งหมดผมขออธิบายก็เป็นเฉพาะส่วนของเทคนิคอย่างเดียว ยังไม่มองแบบครบ 3P
คือการประเมินหาความเสี่ยงจาก
ค่าความเสี่ยง (Risk)ที่พบ จะเกิดจาก ช่องโหว่ที่พบ (Vulnerability) คูณกับค่าภัยคุกคาม (Threat) ลักษณะภัยคุกคามที่พบก็มีความเสี่ยงสูง กลาง และต่ำ ซึ่งส่วนนี้ขึ้นอยู่รูปแบบผู้ทำเอกสารว่าจะจัดทำค่าการประเมินความเสี่ยงจากอุปกรณ์หรือเครื่องมือในตรวจวิเคราะห์ (Tools) มาสรุปความเสี่ยง สูง กลาง และต่ำ ก็ได้
และจัดทำค่าดัชนีชี้วัดความเสี่ยงที่มีผลกระทบต่อธุรกิจทางด้านเทคนิค ซึ่งเอกสารในผลลัพธ์ของแต่ละบริษัทที่จัดทำอาจจะมีรูปแบบที่แตกต่างกันได้เช่นกัน
ในตอนหน้าเรามาพูดถึงการทำ Penetration test และ Vulnerability Assessment ภายในองค์กรกันต่อไปครับ
เขียนโดย
นนทวรรธนะ สาระมาน
Nontawattana Saraman
4 / 10 /52
คำว่า Penetration test คือการทดสอบเพื่อหาช่องทางในการเข้าถึงระบบ (Exploit) ซึ่งการเข้าถึงระบบโดยผ่านช่องโหว่ที่พบอาจเป็น 0day ที่ยังไม่พบการแจ้งเตือนจากผู้ผลิต (Vendor) และการกระทำใดๆที่อาจทำให้ผู้ว่าจ้างได้ทราบถึงความเสี่ยง เสมือนปฎิบัติจริงการเป็นแฮกเกอร์เพื่อเจาะระบบ
ส่วนคำว่า Vulnerability Assessment คือ การประเมินหาความเสี่ยงที่เกิดจากช่องโหว่ที่ค้นพบ ตามช่องโหว่ที่มีความเสี่ยง ซึ่งส่วนใหญ่แล้วเป็นความเสี่ยงที่ปรากฎต่อสาธารณะแล้วตาม CVE (Common Vulnerabilities and Exposures)
ความแตกต่างทั้ง 2 คำนี้ก็คือ Pen-test นั้นคือการทดสอบเจาะระบบแบบแฮกเกอร์ เพื่อประเมินความเสี่ยงของธุรกิจหรือองค์กรนั้น ส่วน VA จะเน้นตรวจหาช่องโหว่ที่เป็นสาธารณะที่มีการเผยแพร่ช่องโหว่นั้นแล้ว เพื่อไม่ให้ถูกโจมตีจากผู้ไม่ประสงค์ดีได้ ทั้งคู่นี้จำเป็นต้องออกรายงานถึงระดับความเสี่ยงให้ผู้ว่าจ้างนั้นได้รู้ถึงภัยอันตรายที่อาจเกิดขึ้น
ดังนั้นหากเราพิจารณาดีๆ แล้วการทำ Penetration test จะเกิดก่อนการทำ Vulnerability Assessment อยู่ยกเว้นในบางกรณีที่ลูกค้าหรือผู้ใช้บริการทราบถึงช่องโหว่แล้วแต่ยังไม่สามารถประเมินค่าช่องโหว่ได้ตรงนี้ก็จะกระโดดไปทำ Vulnerability Assessment ได้ทันที แต่หากไม่สามารถระบุช่องโหว่อะไรได้เลยสิ่งแรกที่เราควรทำคือการทดสอบเจาะระบบเพื่อหาช่องทางในการเข้าถึงระบบเสียก่อน จึงเกิดเป็นการทำ Penetration test
การทำ Penetration test และ Vulnerability Assessment มีหลักการง่ายๆ ที่ทางทีมงาน SRAN ได้รวบรวมและสรุปเป็นขั้นตอนการปฏิบัติงานที่กระชับขึ้นและสามารถใช้ได้ทุกสถานะการณ์โดยสามารถแบ่งเป็นเนื้องานได้ดังนี้
การทำ Penetration test (การทดสอบเจาะระบบในเชิงลึก) ทั้งที่เกิดจากภายนอกระบบและภายในระบบเครือข่ายองค์กร ซึ่งการทำงานประเภทนี้ควรได้รับการอนุญาตจากบริษัท,องค์กรที่ว่าจ้างและมีการทำสัญญาการไม่เผยแพร่ความลับ และให้ดีกว่านั้นคืออาจต้องมีการเตรียมการกับผู้ดูแลระบบบริษัท , องค์กรให้ทราบถึงช่วงเวลาในการปฏิบัติงานที่แน่นอน เพื่อจะได้ระบุได้ว่าการโจมตีเกิดจากการทดสอบเจาะระบบจากทีมงานไม่ใช่นักโจมตีระบบอื่นที่ไม่เกี่ยวข้องในงาน ซึ่งส่วนนี้หากองค์กรมีระบบตรวจจับผู้บุกรุก IDS (Intrusion Detection System) ไม่ว่าเป็นระดับ Network หรือ Host base ก็จะเห็นความผิดปกติที่เกิดจากการทำการประเมินความเสี่ยงได้จาก Log ที่เกิดขึ้นบนอุปกรณ์ ซึ่งสามารถลัดขั้นตอนการทำประเมินความเสี่ยงโดยใช้อุปกรณ์ประเภทที่สามารถวิเคราะห์ Log files ที่เกิดบนระบบเครือข่ายคอมพิวเตอร์ได้ในที่นี้เราแนะนำใช้ NetApprove
1. การทำ Penetration Test จากภายนอกระบบเครือข่ายองค์กร หรืออาจเรียกว่าการทำ Black Box ก็ได้ คือ การใช้เครื่องคอมพิวเตอร์จำลองเป็นนักโจมตีระบบเพื่อหาทางเข้าสู่ระบบเครือข่ายองค์กรที่ให้ทำการประเมินความเสี่ยง โดยมีขั้นตอนดังนี้
1.1 สำรวจ : ตรวจหาเครือข่ายเป้าหมายในการปฏิบัติงาน เช่นบริษัท XYZ ต้องการให้ทำ Penetration test เพื่อดูว่าเครือข่ายองค์กรบริษัทมีช่องทางใดที่เป็นช่องโหว่และมีโอกาสที่ถูกโจมตีจากภายนอกได้
- การค้นหาข้อมูลบริษัท XYZ กับช่องทางการเชื่อมต่ออินเตอร์เน็ต โดยใช้เครื่องสาธารณะ และซอฟต์แวร์ในการค้นหาข้อมูล ซึ่งประกอบด้วย การค้นหาช่องทางสาธารณะได้แก่การ whois ชื่อ Domain name บริษัท XYZ ที่ทำการเปิดข้อมูลในสาธารณะเช่น เว็บไซต์ บริษัท อีเมลล์บริษัท เป็นต้น สิ่งที่ได้ตรงนี้คือเราจะทราบถึง รายชื่อผู้จดทะเบียนชื่อเว็บไซต์รของบริษัท ที่อยู่ เบอร์โทรศัพท์ที่ใช้ในการติดต่อ วันหมดอายุของ domain เว็บไซต์บริษัทนั้นได้ วิธีอาจจะไม่ได้รับข้อมูลทั้งหมดเนื่องจากสมัยนี้ได้มีการปิดข้อมูลชื่อผู้จดทะเบียนเว็บไซต์ และข้อมูลอีเมลล์ในการติดต่อได้
ผลลัพธ์ที่ได้จากการค้นหาข้อมูลสาธารณะนั้น คือ รายชื่ออีเมลล์ของผู้จดทะเบียนเว็บไซต์ ซึ่งปกติหากมีการจดทะเบียนควรตั้งชื่อเป็น pool e-mail ไม่ควรใช้ชื่อใครคนใดคนหนึ่งในองค์กรเป็นคนจดทะเบียนเว็บไซต์ ก็เพื่อว่าหากมีการโยกย้ายงาน หรือคนที่จดทะเบียนนั้นไม่อยู่ในบริษัทแล้วก็จะทำให้การอัพเดทข้อมูลในการจดทะเบียนเว็บไซต์เป็นไปอย่างยากลำบากขึ้น อีกทั้งหากเป็นชื่อ domain name ของเว็บไซต์ที่มีความสำคัญบุคคลที่จดทะเบียนเว็บไซต์ก็อาจจะมีความเสี่ยงที่นักโจมตีระบบจะใช้ช่องทาง e-mail เป็นการปลอมตัวเพื่อเข้าไปเป็นผู้จดทะเบียนเว็บไซต์ได้จากวิธีการเดา password หรือส่ง Trojan ไปที่ e-mail บุคคลนั้นเพื่อได้มาซึ่ง domain name ที่ได้ลงทะเบียนไว้ ถือว่าเป็นการยึด domain nameได้เช่นกัน ในปัจจุบันก็พบกันบ่อยๆว่ามีการยึด domain name เป็นตัวประกันเช่นกัน ในการค้นหาข้อมูลบริษัท XYZ ยังสามารถใช้เครื่องมือในการเรียกใช้บริการ DNS ที่ผู้จดทะเบียนเว็บไซต์นั้นได้เช่น DNS เชื่อมโยงไปยังที่ใด ฝากไว้กับ ISP หรือตั้ง DNS Server เอง ซึ่งส่วนนี้จะสามารถค้นหาช่องโหว่ที่เกี่ยวข้องกับการใช้บริการ DNS Server ได้โดยตรวจสอบหา Zone Transfer เพื่อดูความสัมพันธ์อื่นจากชื่อ domain อื่นที่พบ เช่น www.xyz.com พบว่ามี DNS ที่เกี่ยวข้องคือ mail.xyz.com , ns1.xyz.com , ns2.xyz.com เป็นต้นก็จะทำให้เครื่องเป้าหมายที่เราจะทำการ Penetration test เพิ่มช่องทางการเข้าถึงได้ถึง 3 เครื่องจากในตัวอย่างนี้ที่กล่าวไป
ในการใช้ข้อมูลสาธารณะนั้นยังมีอีกมากมาย เช่นตรวจสอบสถานะ Link ของเว็บไซต์ เพื่อดูความสัมพันธ์ของข้อมูล , ตรวจสอบหา e-mail ของ domain จากเครื่องมือค้นหา (search engine) เพื่อดูพฤติกรรมการใช้ข้อมูลองค์กร ในกรณีก็ค้นหาคำว่า @xzy.com เพื่อว่าจะเข้าถึงระบบจาก e-mail พนักงานในองค์กรได้อีกทาง ซึ่งหากทำ Penetration test ควรจะแจ้งให้บริษัทรับทราบถึงวิธีการดังกล่าวด้วย ไม่เช่นนั้นอาจผิดตามกฏหมายคอมพิวเตอร์ฯได้เช่นกันหากมีการตรวจสอบพบ
- สำรวจช่องทางการเข้าถึงเครือข่ายองค์กร โดยวิธีการนี้ต่อยอดจากการแบบแรก ซึ่งเน้นไปทางการค้นหาเส้นทางการเดินทางของข้อมูล (Route) ของบริษัท Xyz เพื่อออกสู่อินเตอร์เน็ตภายนอก หากพบว่าช่วง IP Address ที่เป็น Public IP ของบริษัทนั้นที่ค่ามาจาก ISP ก็จะทำให้มีช่องทางการเข้าถึงมากขึ้นจากเดิม ซึ่งจะทำให้นักโจมตีระบบสามารถใช้เทคนิคการตรวจสอบได้มากขึ้นเช่นการทำ DDoS/DoS กับช่วง IP ที่บริษัทได้รับมาเป็นต้น
สรุปได้ว่าในขั้นตอน สำรวจ นั้นจะต้องหาข้อมูลเกี่ยวข้องกับบริษัทที่ให้ประเมินความเสี่ยงมากที่สุด เพื่อหาช่องทางในการเข้าถึงระบบได้หลากหลายช่องทางขึ้น
1.2 ตรวจสอบ : เมื่อเราทำการรวบรวมข้อมูลที่ได้มาจากขั้นตอนสำรวจนั้น ก็จะทำการวาดรูปความสัมพันธ์เครือข่ายองค์กรออกมาพร้อมกำหนดจุดที่ทำการตรวจสอบขึ้น การตรวจสอบมักจะใช้ check list ตามมาตราฐาน หรือใช้เครื่องมือในการตรวจสอบ ในกรณีนี้เป็นการทำ Penetration test จากภายนอก สิ่งที่ตรวจสอบได้แก่
- Information leak จากขั้นตอนที่หนึ่ง เช่น รายชื่อผู้จดทะเบียนเว็บไซต์, e-mail, รายชื่อ DNS ที่มีความสัมพันธ์กับบริษัท, ข้อมูลรั่วจากการใช้งานอินเตอร์เน็ตได้แก่ e-mail พนักงานในการโพสข้อมูล, Link ของเว็บไซต์บริษัทที่ทำให้ได้ข้อมูลอื่นๆเป็นต้น
- Web Application checklist ตรวจสอบช่องโหว่ที่พบจากเว็บไซต์ในกรณีคือ www.xyz.com ว่ามีช่องโหว่ในการเข้าถึงระบบผ่าน Web application จากมาตราฐาน OWASP เป็นต้น รายละเอียดการตรวจสอบเบื้องต้นสามารถอ่านได้ที่ http://nontawattalk.blogspot.com/2009/09/layer-7-3.html
- DNS server checklist ตรวจสอบค่า Domain name server ที่แสดงข้อมูลสาธารณะ
- E-mail Server checklist ตรวจสอบค่าการใช้งาน E-mail server ที่แสดงข้อมูลสาธารณะ เช่นกรณีที่ บริษัท XYZ จัดทำ Mail server เองขึ้นการตรวจสอบจะตรวจว่า Mail server ของบริษัทนั้นจะมีโอกาสจดหมายขยะจะเข้าถึงได้หรือไม่เป็นต้น
- Network Topology checklist ตรวจสอบการเชื่อมต่ออินเตอร์เน็ตบริษัท เส้นทางการ route ข้อมูลจำนวน Linkของ ISP ที่บริษัท xyz ใช้บริการ ซึ่งส่วนนี้จะเน้นไปการทดสอบ DDoS/DoS ว่าทางบริษัท xyz มีการควบคุมการโจมตีชนิดนี้ได้หรือไม่ ซึ่งจะสะท้อนให้เห็นถึงความพร้อมโครงสร้างเครือข่าย (Network) ของบริษัทว่าได้มีการจัดเตรียมเทคโนโลยีด้านความมั่นคงปลอดภัยครบถ้วนในส่วน Perimeter network เช่นได้มีการจัดทำ ACL (Access Control List) ค่า Blacklist ในอุปกรณ์ Router หรือ Firewall , มีอุปกรณ์ Firewall ที่ป้องกันทางเครือข่ายในระดับ stateful inspection หรือไม่ เป็นต้น
- ตรวจสอบ Port services จากข้อมูลในขั้นตอนสำรวจ เช่น เราพบ IP Address ของเว็บไซต์บริษัท , e-mail , DNS server, Router ก็ทำการตรวจสอบว่ามี Port services อะไรที่ทำการเปิดไว้เพื่อจะทำการขยายผลต่อในขั้นตอนต่อไป
1.3 วิเคราะห์ : เมื่อทำการตรวจสอบจากการสำรวจและตรวจสอบ ภายนอกเครือข่ายองค์กรแล้วนำข้อมูลเหล่านั้นมาทำการวิเคราะห์เพื่อศึกษาว่าพบช่องโหว่และการเข้าถึงข้อมูล เช่น จากการตรวจสอบ Port services พบว่ามีการเปิด Port ที่มีช่องโหว่และสามารถเข้าถึงระบบจากภายนอกได้ ผ่านการให้บริการ Web server port 80 ช่องโหว่ที่พบคือ มีการใช้ Web server version เก่าและมี tools ในการเข้าถึงระบบ (Exploit) ผ่านช่องโหว่นี้ได้ หรือ ใน Web server เปิด port 1433 เป็นการเปิด port SQL server เป็น Data base บนเครื่อง Web server และมี exploit ที่เข้าถึงระบบได้ เป็นต้น
ในขั้นตอนวิเคราะห์จะลงรายละเอียดถึงการเข้าถึงระบบจากภายนอก เป็นส่วนๆจากขั้นตอนสำรวจและตรวจสอบ เช่น ส่วนของ Web server , ส่วนของ E-mail Server , ส่วนของ DNS server และส่วนของ Router เป็นต้น
1.4 ประเมิน : ในส่วนนี้ผมขอเรียกว่า Vulnerability Assessment เมื่อทำการวิเคราะห์ถึงช่องโหว่ที่พบแล้ว ถึงขั้นตอนสุดท้ายคือการประเมิน ว่าช่องโหว่ที่พบนั้นมีความเสี่ยงและมีผลกระทบต่อธุรกิจองค์กรอย่างไร
ส่วนใหญ่เป็นเอกสารการแนะนำและการปิดช่องโหว่ที่พบ
สูตรการหาค่าความเสี่ยงต่อธุรกิจองค์กร Risk = Vulnerability x Threat หรือบ้างครั้งอาจจะเห็นเป็นสูตร
Risk = Vulnerability x Threat x cost การประเมินความเสี่ยง (Risk Assessment) สามารถมองได้ 2 แบบคือด้านมหาภาคภาพรวมองค์กร ที่ต้องดูถึง 3P คือ
Vulnerability คน กระบวนการ และเทคโนโลยี
Threat จากคน กระบวนการและเทคโนโลยี
และ จุลภาคคือทางด้านเทคนิคอย่างเดียว คือมอง Vulnerability และ Threat เฉพาะทางเทคโนโลยี
และทั้งหมดผมขออธิบายก็เป็นเฉพาะส่วนของเทคนิคอย่างเดียว ยังไม่มองแบบครบ 3P
คือการประเมินหาความเสี่ยงจาก
ค่าความเสี่ยง (Risk)ที่พบ จะเกิดจาก ช่องโหว่ที่พบ (Vulnerability) คูณกับค่าภัยคุกคาม (Threat) ลักษณะภัยคุกคามที่พบก็มีความเสี่ยงสูง กลาง และต่ำ ซึ่งส่วนนี้ขึ้นอยู่รูปแบบผู้ทำเอกสารว่าจะจัดทำค่าการประเมินความเสี่ยงจากอุปกรณ์หรือเครื่องมือในตรวจวิเคราะห์ (Tools) มาสรุปความเสี่ยง สูง กลาง และต่ำ ก็ได้
และจัดทำค่าดัชนีชี้วัดความเสี่ยงที่มีผลกระทบต่อธุรกิจทางด้านเทคนิค ซึ่งเอกสารในผลลัพธ์ของแต่ละบริษัทที่จัดทำอาจจะมีรูปแบบที่แตกต่างกันได้เช่นกัน
ในตอนหน้าเรามาพูดถึงการทำ Penetration test และ Vulnerability Assessment ภายในองค์กรกันต่อไปครับ
เขียนโดย
นนทวรรธนะ สาระมาน
Nontawattana Saraman
4 / 10 /52
วันศุกร์, ตุลาคม 2
SRAN ใส่ใจความเป็นส่วนตัว
ดูคลิปเองเลยครับไม่มีคำบรรยาย
หลังจากนำอุปกรณ์ SRAN Light ติดตั้งที่เครือข่ายคอมพิวเตอร์ในบริษัทแล้ว เราจะสามารถทำการกำหนดค่าความเป็นส่วนตัวของพนักงานได้ SRAN Light ใส่ใจข้อมูลความเป็นส่วนตัวของคุณ
รายละเอียดเพิ่มเติมดูได้ที่ http://sran.org/q
หลังจากนำอุปกรณ์ SRAN Light ติดตั้งที่เครือข่ายคอมพิวเตอร์ในบริษัทแล้ว เราจะสามารถทำการกำหนดค่าความเป็นส่วนตัวของพนักงานได้ SRAN Light ใส่ใจข้อมูลความเป็นส่วนตัวของคุณ
รายละเอียดเพิ่มเติมดูได้ที่ http://sran.org/q
นนทวรรธนะ สาระมาน
Nontawattana Saraman
Nontawattana Saraman
ปฏิวัติระบบระบุตัวตนทางเครือข่ายคอมพิวเตอร์ SRAN Light ตอนที่ 2
เคยเบื่อบ้างไหม! กับการต้องมานั่ง Login ทุกครั้งเมื่อต้องการใช้งานอินเตอร์เน็ต เหตุเพราะที่ทำงานต้องการเก็บ Log คนเข้าใช้งาน เลยต้องทำระบบระบุตัวตน (Authentication) การ Login เป็นการยืนยันตัวตนแบบชั้นเดียวก็มีโอกาสผู้อื่นมาใช้ username และ password ที่สุดแสนจะเดาง่ายของเราได้ เนื่องจากต้องทำการ Login บ่อยๆ จึงทำให้ตั้ง password ที่สะดวกในการจดจำ
แล้วเคยเบื่อบ้างไหมว่า ลงทุนระบบไปแล้วติดตั้งไม่รู้จักจบจักสิ้นเสียที ติดตั้งมาเป็นเดือนแล้วยังไม่ได้ผลลัพธ์อย่างที่ต้องการ แถมซ้ำ Log ที่ได้มากับค้นหาผู้กระทำผิดได้ยากหรืออาจจะไม่ได้เลยเพราะอ่านไม่รู้เรื่อง หากเคยเบื่อกับอาการดังกล่าว ลองหันมาฟังทางนี้ เรามีทางเลือกใหม่ให้ ทุกอย่างครบและเสร็จสิ้นที่อุปกรณ์เดียวในชื่อ SRAN Light จะทำให้ Log ที่เห็นเป็นเรื่องง่ายในการสืบค้นโดยไม่จำเป็นต้องอาศัยผู้เชี่ยวชาญก็อ่าน Log ของ SRAN แล้วบอกถึงผู้กระทำความผิดทางคอมพิวเตอร์ได้
SRAN Light ถูกออกแบบมาเพื่อให้ผู้ใช้ (User) เกิดความสะดวกสบาย ขึ้นโดยไม่ต้อง Login ทุกครั้งที่จะเชื่อมต่ออินเตอร์เน็ตในเครือข่ายองค์กร เพียงครั้งแรกและครั้งเดียวระบบก็จะเก็บบันทึกความเป็นตัวตนของผู้ใช้งานไว้ ด้วยเทคโนโลยี HBW (Human Behavioral Warning System) ที่ได้ถูกคิดค้นขึ้นจากทีมงาน SRAN จึงทำให้ไม่ต้อง Login แล้ว Login อีก ก็สามารถระบุตัวตนผู้ใช้งานได้อย่างครบถ้วน
รายละเอียด http://sran.org/q
ไฟล์เอกสารแนะนำเทคโนโลยีและการออกแบบการใช้งานสำหรับ SRAN Light http://sran.org/b2
คลิปสาธิตการเฝ้าระวังภัยคุกคามภายในองค์กร (Insider Threat)
อีกก้าวหนึ่งของทีมงาน SRAN ที่พัฒนา SRAN Light เป็นการระบุตัวตนและเฝ้าระวังภัยคุกคามทางเครือข่ายคอมพิวเตอร์ได้อย่างลงตัว
สนใจติดต่อตัวแทนขายที่ท่านรู้จักเพื่อทดลองใช้ดูกัน อีกสิ่งดีๆที่ต้องการเสนอให้กับเครือข่ายองค์กรในประเทศไทยได้รู้ทันภัยคุกคามที่อาจเกิดขึ้นกับตัวของท่านและบริษัทของท่านได้ตลอดเวลา SRAN Light ถือว่าเป็นก้าวหนึ่งที่แสดงถึงการพัฒนาการอย่างไม่หยุดนิิ่งจากทีมวิจัยพัฒนา SRAN
แล้วเคยเบื่อบ้างไหมว่า ลงทุนระบบไปแล้วติดตั้งไม่รู้จักจบจักสิ้นเสียที ติดตั้งมาเป็นเดือนแล้วยังไม่ได้ผลลัพธ์อย่างที่ต้องการ แถมซ้ำ Log ที่ได้มากับค้นหาผู้กระทำผิดได้ยากหรืออาจจะไม่ได้เลยเพราะอ่านไม่รู้เรื่อง หากเคยเบื่อกับอาการดังกล่าว ลองหันมาฟังทางนี้ เรามีทางเลือกใหม่ให้ ทุกอย่างครบและเสร็จสิ้นที่อุปกรณ์เดียวในชื่อ SRAN Light จะทำให้ Log ที่เห็นเป็นเรื่องง่ายในการสืบค้นโดยไม่จำเป็นต้องอาศัยผู้เชี่ยวชาญก็อ่าน Log ของ SRAN แล้วบอกถึงผู้กระทำความผิดทางคอมพิวเตอร์ได้
SRAN Light ถูกออกแบบมาเพื่อให้ผู้ใช้ (User) เกิดความสะดวกสบาย ขึ้นโดยไม่ต้อง Login ทุกครั้งที่จะเชื่อมต่ออินเตอร์เน็ตในเครือข่ายองค์กร เพียงครั้งแรกและครั้งเดียวระบบก็จะเก็บบันทึกความเป็นตัวตนของผู้ใช้งานไว้ ด้วยเทคโนโลยี HBW (Human Behavioral Warning System) ที่ได้ถูกคิดค้นขึ้นจากทีมงาน SRAN จึงทำให้ไม่ต้อง Login แล้ว Login อีก ก็สามารถระบุตัวตนผู้ใช้งานได้อย่างครบถ้วน
รายละเอียด http://sran.org/q
ไฟล์เอกสารแนะนำเทคโนโลยีและการออกแบบการใช้งานสำหรับ SRAN Light http://sran.org/b2
คลิปสาธิตการเฝ้าระวังภัยคุกคามภายในองค์กร (Insider Threat)
อีกก้าวหนึ่งของทีมงาน SRAN ที่พัฒนา SRAN Light เป็นการระบุตัวตนและเฝ้าระวังภัยคุกคามทางเครือข่ายคอมพิวเตอร์ได้อย่างลงตัว
สนใจติดต่อตัวแทนขายที่ท่านรู้จักเพื่อทดลองใช้ดูกัน อีกสิ่งดีๆที่ต้องการเสนอให้กับเครือข่ายองค์กรในประเทศไทยได้รู้ทันภัยคุกคามที่อาจเกิดขึ้นกับตัวของท่านและบริษัทของท่านได้ตลอดเวลา SRAN Light ถือว่าเป็นก้าวหนึ่งที่แสดงถึงการพัฒนาการอย่างไม่หยุดนิิ่งจากทีมวิจัยพัฒนา SRAN
นนทวรรธนะ สาระมาน
Nontawattana Saraman
Nontawattana Saraman
วันพฤหัสบดี, ตุลาคม 1
ปฏิวัติระบบระบุตัวตนทางเครือข่ายคอมพิวเตอร์ SRAN Light ตอนที่ 1
ผมได้ดูพิธีวันชาติของประเทศจีนเมื่อวานนี้จากทางข่าวในทีวี บอกว่าอาวุธ,ถัง และเทคโนโลยีการทหารและด้านความมั่นคงของชาติ เป็นเทคโนโลยีที่จีนเป็นเจ้าของทั้งสิ้น ซึ่งในความเป็นเราๆก็รู้ๆกันอยู่ว่าจีนเก่งในเรื่อง C&D (Copy and Development) แต่นั้นไม่ใช่ปัญหา เนื่องจากผลลัพธ์ที่เราๆท่านๆเห็นอยู่ตรงหน้านั้นคือความยิ่งใหญ่ จนทุกวันเราคงยอมรับกันอย่างแพร่หลายแล้วว่าประเทศจีนคือประเทศมหาอำนาจชาติหนึ่งและเรียกได้ว่าอาจเป็นอันดับหนึ่งของโลกไปแล้วในไม่ช้านี้
ความเหมือนกันของวันชาติสิงคโปร์กับจีนนั้นเหมือนกันคือแสดงให้เห็นถึงความรักต่อประเทศของตน และแสดงศักยภาพให้ต่างประเทศที่ได้รับรู้ข่าวสารอย่างเราได้แต่ชื่นชม
ที่ผมกล่าวเช่นนี้นั้นหมายความได้ว่า ประเทศไทยหากจะต้องการเป็นมหาอำนาจอย่างเขา เราต้องเริ่มที่จะทำเทคโนโลยีเราเองบ้าง ผมคิดว่าประเทศไทยเป็นประเทศที่อุดมสมบูรณ์กว่า 2 ประเทศที่กล่าวมาอยู่มาก โดยเฉพาะภัยทางธรรมชาตินั้นเราน้อยกว่าเห็นๆ ยิ่งมีพายุเข้าในช่วงนี้รู้สึกรักประเทศไทยมากขึ้น คิดดูสิ พายุก่อตัวที่ฟิลิปปิน กว่าจะเคลื่อนเข้าประเทศไทย ต้องผ่านเวียดนาม ลาว กว่าถึงไทย พายุก็อ่อนกำลังลง ทะเลของเราก็สวยแถมยังเสี่ยงภัยน้อยกว่าที่อื่นๆ มองจากแผนที่โลกลงมาเนื้อที่โดดเด่นที่สุดก็คิดว่าเป็นประเทศไทยนี้แหละ อยู่ตรงกลางพอดีเลย
ที่กล่าวมาทั้งหมดไม่ได้เกี่ยวกับหัวข้อเลยแค่อยากให้คนไทยเริ่มต้นที่สร้างชาติกันอย่างหยั่งยืน ซึ่งอีกทางหนึ่งบนความรู้และความถนัดของผมและทีมงานแล้วเราก็คงได้เป็นเพียงส่วนหนึ่ง
และตอนนี้เราได้พัฒนาเทคโนโลยีตัวหนึ่งที่อยากนำเสนอ จริงๆเขียนไว้แล้วที่ http://www.sran.net/
Presentation ในงานเปิดตัว SRAN Light
ประเทศไทยจะก้าวไกลได้ทุกคนในชาติต้องสนับสนุนเทคโนโลยีที่เกิดจากภูมิปัญญาของคนไทยด้วยกัน
อย่าคิดว่าของไทยแล้วห่วยเทคโนโลยีไทยเป็นได้แค่การเกษตร จนมองข้ามเทคโนโลยีที่ถือว่าเป็นตัวชี้วัดคุณภาพของประเทศนั้นได้ไป และมองเพียงว่าเทคโนโลยีที่คนไทยทำนั้นไม่ work! ต้องบอกว่าไม่มีผู้ประกอบการคนไหนที่ต้องการสร้างของไม่ดีให้กับผู้บริโภคหลอก ยิ่งเราอยู่ตรงนี้ถ้าทำไม่ดีคนก็ว่าเราได้ตรงๆ กระทบต่อชื่อเสียงเราตรงๆ ต่างกับเทคโนโลยีข้ามชาติถ้าไม่ work เขาก็เอาตัวอื่นมาขายไม่ได้ยืนอยู่ตรงนี้เหมือนกับเรา รวมกันเถอะครับสนับสนุนเทคโนโลยีที่คนไทยเป็นผู้พัฒนาขึ้นอย่างน้อยทำให้เจตนาผู้ทำได้มีกำลังใจในการทำงานไม่เฉพาะ SRAN แต่ทุกเทคโนโลยีนับแต่นี้ไป
นนทวรรธนะ สาระมาน
Nontawattana Saraman
วันเสาร์, กันยายน 26
การตรวจจับหมายเลขบัตรเครดิตในเครือข่าย
* การจับคู่ลำดับหมายเลขบัตรเครดิต
* การจัดการกับผลบวกลวง (false positive) โดยการใช้ข้อยกเว้น (exceptions)
* ข้อควรพิจารณาอื่น ๆ รวมทั้งการหลบหลีกการตรวจจับ บันทึกเหตุการณ์ (logging) และรูปแบบอื่น ๆ ที่ล่อแหลม
1. การจับคู่หมายเลขบัตรเครดิต
1.1 การจับคู่ลำดับหมายเลขบัตรเครดิต
หมายเลขบัตรเครดิตประกอบด้วยตัวเลข 13 ถึง 16 ตัว นอกจากนี้ในการใช้งานจริงหมายเลขบัตรเครดิตยังมีตัวคั่นอย่างเช่น เครื่องหมายขีดหรือเว้นวรรคในตำแหน่งเฉพาะ regular expression ต่อไปนี้สามารถใช้เพื่อจับหมายเลขบัตรเครดิตได้
\d{4}[\- ]?\d{4}[\- ]?\d{2}[\- ]?\d{2}[\- ]?\d{1,4}
1.2 ขอบเขต
ลำดับตัวเลขยาว ๆ เป็นสิ่งที่เกิดขึ้นเป็นปกติในการจราจรในระบบเครือข่าย regular expression ที่กล่าวมาแล้วข้างต้นจะพบลำดับตัวเลขที่มีความยาวดังกล่าวจำนวนมาก เพื่อหลีกเลี่ยงเหตุการณ์นี้ เราจำเป็นต้องกำหนดตัวคั่น ตัวคั่นจะใช้ได้หรือไม่อาจขึ้นอยู่กับแอพพลิเคชั่นดังกล่าว ถ้าไม่ใช้ตัวคั่นเลยจะทำให้เกิดผลบวกลวงจำนวนมาก แต่ถ้าการใช้ตัวคั่นอาจนำไปสู้ผลลบลวงได้เช่นกัน ตัวอย่างเช่น เราควรอนุญาตให้มี “0″ นำหน้าหรือไม่ ?
ตัวเลือกที่มีเหตุผลสำหรับตัวคั่นคือตัวอักขระใด ๆ ที่ไม่ใช่ตัวเลข regular expression ที่ได้คือ ?
หรือถ้า regular expression ที่ไม่สนับสนุนการค้นหาแบบ look-ahead และ look-behind
(?:^|[^\d])(\d{4}[\- ]?\d{4}[\- ]?\d{2}[\- ]?\d{2}[\- ]?\d{1,4})(?:[^\d]|$)
1.3 การตรวจสอบหมายเลขโดยใช้อัลกอริทึม LUHN checksum
อย่างไรก็ตามลำดับของตัวเลข 13 ถึง 16 ตัวไม่จำเป็นต้องเป็นหมายเลขบัตรเครดิตเสมอไป มีตัวเลขยาว ๆ จำนวนมากในการจราจรในเครือข่ายปกติจำนวนมาก ตัวอย่างเช่น เรามักพบหมายเลขไอดี อย่างเช่นหมายเลขผลิตภัณฑ์ใช้ในเวบจำหน่ายสินค้าออนไลน์ใช้ตัวเลข 13 ถึง16 หลักด้วย โชคดีที่หมายเลขบัตรเครดิตสอดคล้องกับฟังค์ชั่น LUHN checksum ระบบเฝ้าดูเครือข่ายสามารถใช้อัลกอริทึมนี้และตรวจสอบลำดับตัวเลขเพื่อตรวจ สอบว่าเป็นหมายเลขบัตรเครดิตหรือไม่
มาตรการนี้เพียงพอสำหรับการหลีกเลี่ยงผลบวกลวงหรือไม่ ? ฟังค์ชั่น LUHN เป็นฟังค์ชั่นในการ checksum ที่สร้างตัวเลขเพิ่มเติมสำหรับแต่ละหมายเลข ดังนั้นมันจึงจับคู่ 1 ใน 10 หมายเลขที่ต่อเนื่องกัน เนื่องจากในกรณีส่วนใหญ่ หลาย ๆ แอพพลิเคชั่นใช้ตัวเลขที่มีความยาวขนาดนี้เป็นหมายเลขไอดี แอพพลิเคชั่นนั่นก็อาจใช้ตัวเลขต่อเนื่องกันหลายหมายเลข ดังนั้นหนึ่งในสิบของหมายเลขที่ใช้อาจเป็นหมายเลขบัตรเครดิตจริง ดังนั้นการตรวจสอบตัวเลขโดยใช้สูตร LUHN จึงลดจำนวนของผลบวกลวงลงได้ร้อยละ 90 แต่ไม่ได้กำจัดลงไปทั้งหมด
1.4 ตรวจสอบตัวเลขนำหน้า (prefixes)
เพื่อลดจำนวนของผลบวกลวง ระบบเฝ้าดูสามารถตรวจสอบได้ว่าหมายเลขบัตรเครดิตนั้นไม่เพียงแต่ถูกต้องแต่ ยังได้รับการกำหนดไว้แล้วด้วย โดยปกติระบบเฝ้าดูไม่อาจมีรายการของหมายเลขที่กำหนดไว้ได้ทั้งหมด แต่มันสามารถตรวจตัวเลขนำหน้า ว่าตัวเลขกลุ่มใดที่กำหนดให้กับสถาบันทางการเงินแห่งใด ตารางของตัวเลขนำหน้าสามารถค้นหาได้จาก Wikipedia (http://en.wikipedia.org/wiki/Credit_card_number)
ตัวเลขนำหน้าสามารถลดจำนวนของผลบวกลวงและสามารถตรวจสอบได้โดยอาศัย regular expression หมายเลขที่กำหนดไว้มีจำนวนร้อยละ 1 ถึง 17 ของหมายเลขบัตรเครดิตที่ใช้ได้ทั้งหมดโดยขึ้นอยู่กับความยาวของตัวเลข ตัวเลขนำหน้ามีประโยชน์ในการใช้เพื่อกำจัดตัวเลขความยาว 14 และ 15 หลักที่ไม่ค่อยมีการใช้กันมากนักออกไป ทำให้เรามีตัวเลขความยาว 13 ถึง 16 ตัว ยังคงไม่เป็นที่แน่ชัดว่า Visa ยังใช้ตัวเลข 13
หลักอยู่หรือไม่
ในแง่เสีย การใช้ตัวเลขนำหน้าอาจนำไปสู่ผลลบลวงและอาจจะต้องมีการปรับปรุงระบบเฝ้าดู เครือข่าย เช่น ช่วงหมายเลขที่ใช้สำหรับธนาคารในออสเตรเลียที่เวบ Wikipedia ระบุไว้ว่าไม่มีการใช้ แต่เรากลับเจอตัวเลขในช่วงดังกล่าวในการจราจรในระบบเครือข่าย
โดยการใช้สูตร LUHN และการตรวจสอบตัวเลขนำหน้า ทำให้สามารถลดอัตราการเกิดของผลบวกลวงลงได้ประมาณร้อยละ 1 จากข้อมูลทั้งหมดที่ได้จากการใช้หลักการของ pattern matching เท่านั้น
2. การจัดการกับผลบวกลวงโดยใช้กฏข้อยกเว้น
ในระบบที่ใช้อยู่จริง ร้อยละ 1 ยังถือว่าเป็นจำนวนที่สูง โดยเฉพาะอย่างยิ่งลำดับของตัวเลขเป็นสิ่งที่เกิดขึ้นเป็นปกติในการจราจรใน เครือข่าย ถ้ามนุษย์เป็นจำเป็นต้องตรวจสอบการแจ้งเตือนเป็นจำนวนร้อยข้อความต่อวัน ระบบเฝ้าดูก็จะไม่มีประโยชน์ เราสามารถทำให้ระบบตรวจจับมีความแม่นยำขึ้นได้อย่างไร
วิธีที่ทำได้คือการสร้างกฏข้อยกเว้นสำหรับการจราจรที่รู้ว่าจะสร้างผลบวก ลวง กฏข้อยกเว้นสามารถกำหนดได้ทั้งสำหรับลำดับตัวเลขที่ไม่ใช่หมายเลขบัตรเครดิต และการรับส่งข้อมูลหมายเลขบัตรเครดิตที่ตั้งใจ
กฏข้อยกเว้นดังกล่าวมีทั้งข้อดีและข้อเสีย การใช้มากเกินไปหรือกำหนดไว้อย่างกว้าง ๆ เกินไปจะทำให้เกิดช่องโหว่ความปลอดภัย เช่น ลำดับตัวเลข 16 ตัวที่ใช้เพื่อเป็นหมายเลขผลิตภัณฑ์ในเวบไซต์ ข้อยกเว้นที่ใช้กฏเหมือนกับไฟร์วอลที่สนับสนุนเฉพาะที่อยู่ไอพี (IP address) และพอร์ท (port) จะต้องปล่อยให้การจราจรทั้งหมดของเวบไซต์นั้นผ่านไปได้ ในอีกแง่หนึ่งระบบเฝ้าดูแอพพิลเคชั่น เช่น Web Application Firewall (WAF) สามารถกำหนดกฏข้อยกเว้นได้ละเอียดกว่า ในกรณีข้างต้นกฏของ WAF สามารถกำหนดให้ยกเว้นการตรวจจับหมายเลขบัตรเครดิตสำหรับเขตข้อมูลเฉพาะใน หน้าพิเศษที่ใช้สำหรับหมายเลขผลิตภัณฑ์
ตัวอย่างเช่นกฏของ SRAN Security Center โดยผสมผสาน Signature snort + ModSecurity โดยใช้ หมายเลข 955555 ตรวจพบหมายเลขบัตรเครดิตในข้อมูลที่ได้จากแอพพิลเคชั่นหนึ่ง แต่หน้า /support/manual_payment.php มีเพียงแต่เจ้าหน้าที่ของร้านเท่านั้นที่สามารถเข้าถึงได้ จะต้องแสดงหมายเลขบัตรเครดิต ข้อยกเว้นสำหรับ ModSecurity ต่อไปนี้อนุญาตให้หน้านี้ผ่านไปได้
SecRuleRemoveById 955555
เราสามารถกำหนดข้อยกเว้นให้ตรวจสอบต่อไปได้อีกว่ามีเพียงหมายเลขบัตร เครดิตเพียงหมายเลขเดียวที่แสดงในหน้านี้ และแสดงในเพียงบางส่วนของหน้านี้เท่านั้น
นอกจากนี้หมายเลขผลิตภัณฑ์ยังอาจมีคุณลักษณะอื่น ๆ อีกเช่นตัวเลขนำหน้าเฉพาะของมัน หรือข้อความอื่น ๆ ที่ช่วยในการทำให้ข้อยกเว้นแคบลง ตัวอย่างเช่น Google AdSense เวบไซต์ที่มี Google ads จำเป็นต้องเพิ่มโค้ดต่อไปนี้เข้าไปในแต่ละหน้าที่แสดงโฆษณาหลายครั้งที่หมายเลข 16 ตัวในพารามิเตอร์ google_ad_client เป็นหมายเลยบัตรเครดิตจริง regular expression
3. ข้อควรพิจารณาอื่น ๆ
3.1 การหลบหลีกการตรวจจับ
เทคนิคในการหลบหลีกการตรวจจับ (Evasion techniques) เป็นปัญหาร้ายแรงสำหรับระบบตรวจจับการบุกรุกและยิ่งมีปัญหามากขึ้นอีกสำหรับ การตรวจจับหมายเลขบัตรเครดิต แม้แต่ฟังค์ชั่นในการเปลี่ยนรูปแบบตัวเลขที่ง่ายที่สุดก็สามารถหลบหลีกการ ตรวจจับได้ ตัวอย่างเช่น ผู้โจมตีทำการโจมตีแบบ SQL injection เพื่อขโมยข้อมูลหมายเลขบัตรเครดิต เขาสามารถสร้าง SQL statement ที่ทำให้ตัวเลขของหมายเลขบัตรเครดิตแต่ละตัวคูณด้วยสอง มีผลให้ระบบเฝ้าดูไม่สามารถตรวจผลที่ได้ว่าเป็นหมายเลขบัตรเครดิต หลังจากที่ข้อมูลดังกล่าวรั่วไหลออกมาแล้ว ผู้โจมตีสามารถหารตัวเลขด้วยสองเพื่อให้ได้มาซึ่งหมายเลขบัตรเครดิตดังเดิม เพราะง่ายในการหลบหลีกระบบเฝ้าดูเครือข่ายหรือระบบตรวจจับอื่น ๆ จึงไม่เหมาะสมในการตรวจจับการขโมยหมายเลขบัตรเครดิต ดังนั้นการหลีกเลี่ยงการขโมยถึงต้องมุ่งเน้นที่การป้องกันสิ่งที่เข้ามา
แม้แต่ข้อมูลที่รั่วไหลออกไปโดยไม่ตั้งใจก็อาจหลบหลีกการตรวจจับอย่างไม่ ตั้งใจเช่นกัน ตัวอย่างที่ดีคือการเข้ารหัส เพื่อให้มึความปลอดภัยที่ดีขึ้น แอพพลิเคชั่นหลายตัวใช้การเข้ารหัสเมื่อต้องการรับส่งข้อมูลผ่านทางเครือ ข่าย การเข้ารหัสดังกล่าวซ่อนการจราจรจากระบบเฝ้าดู ในขณะที่ระบบ IDS ในระดับ network layer ไม่สามารถถอดรหัส SSL ได้ โซลูชั่นในระดับ web layer สามารถทำได้ คุณสามารถอ่านรายละเอียด
เพิ่มเติมเกี่ยวกับ SSL blind spot ได้จาก http://archives.neohapsis.com/archives/sf/ids/2007-q3/0084.html
อีกปัญหาหนึ่งคือระบบเข้ารหัสที่เพิ่มเข้าไปในโปรโตคอลด้านเครือข่าย เช่น Unicode หรือการบีบอัดการจราจร HTTP และการเข้ารหัสข้อความอีเมลที่เรียกว่า base64 ระบบเฝ้าดูเครือข่ายไม่สามารถตรวจจับการจราจรที่เข้ารหัสได้ แต่ระบบเฝ้าดูที่รู้จักแอพพลิเคชั่นสามารถถอดรหัส ก่อนการตรวจจับและตรวจหาการรั่วไหลของข้อมูลได้
3.2 บันทึกข้อมูล (logging)
การบันทึกข้อมูลเป็นสิ่งสำคัญเช่นเดียวกับการตรวจจับของระบบเฝ้าดูเครือ ข่าย สิ่งนี้มีความสำคัญอย่างมากกับการตรวจจับหมายเลขบัตรเครดิตในหลาย ๆ กรณีอาจสามารถบรรเทาความเสียหายที่เกิดจากการบุกรุกระบบรักษาความปลอดภัยได้ ถ้าองค์การดังกล่าวรู้ว่ามีข้อมูลข่าวสารใดบ้างที่รั่วไหลออกไป ตัวอย่างเช่น มีกฏหมายของสหรัฐ ฯ เช่น California SB-1386 ที่กำหนดให้องค์การต้องบอกให้ผู้ใช้ (client) ที่ได้รับผลกระทบจากการถูกบุกรุกรับทราบ ถ้าองค์การนี้ไม่รู้ว่ามีผู้ใช้คนไหนบ้างที่ได้รับผลกระทบ องค์การดังกล่าวจะต้องบอกให้ทุกคนรู้ ซึ่งจะเพิ่มความเสียหายที่เกิดขึ้นจากการถูกบุกรุกและทำให้เสียชื่อเสียงจาก การเผยแพร่ข่าวของสื่อมวลชนได้
โชคไม่ดีที่การบันทึกข้อมูลการรั่วไหลของหมายเลขบัตรเครดิตทำได้ไม่ง่าย PCI DSS ไม่อนุญาตให้มีการบันทึกหมายเลขบัตรเครดิตแต่ตัวบันทึกเองจะต้องมีข้อมูลที่ มีประโยชน์มากพอ ระบบบันทึกจะต้องมีการบันทึกในสองระดับดังนี้คือ
- บันทึกแจ้งเตือนที่สามารถใช้เพื่อวิเคราะห์ว่าอะไรเกิดขึ้น แต่จะต้องไม่มีหมายเลขบัตรเครดิตยู่ด้วย หรืออาจจะเป็นหมายเลขที่อำพรางไว้
- หมายเลขบัตรเครดิตที่เก็บอยู่ในรูปแบบที่เข้ารหัสไว้
3.3 สมรรถนะการทำงาน (Performance)
การใช้ regular expression เป็นวิธีการที่ไม่มีประสิทธิภาพเป็นอย่างมาก ดังนั้นระบบ IDS ส่วนใหญ่จึงหลีกเลี่ยงการทดสอบ payload ที่มี regular expression จำนวนมาก เพื่อให้บรรลุเป้าหมายนี้ IDS จึงจะต้องพยายามใช้อัลกอริทึมในการตรวจจับแบบคู่ขนานที่มีประสิทธิภาพ เช่น Aho-Corasick (http://en.wikipedia.org/wiki/Aho-Corasick_algorithm) ซึ่งทำงานได้อย่างรวดเร็วมากและใช้การตรวจสอบเพียงครั้งเดียว อย่างไรก็ตามการตรวจจับแบบคู่ขนานสามารถตรวจได้เพียงสายอักขระง่าย ๆ ถ้าพบสายอักขระง่าย ๆ จึงจะมีการทดสอบ regular expression อื่นตามมา เพื่อลดจำนวนของการทดสอบ regular expression อัลกอริทึมในการตรวจจับแบบคู่ขนานจึงต้องค้นหาสายอักขระที่ยาวที่สุดจากทุก ๆ regular expression
3.4 ข้อมูลอื่น ๆ ที่มีความสำคัญ
ไม่ได้มีเพียงแต่หมายเลขบัตรเครดิตเท่านั้นที่เป็นข้อมูลสำคัญที่ต้องให้ ความสนใจ Card Verification Code (CVV) เป็นตัวเลข 3 หรือ 4 หลักที่อยู่ด้านหลังบัตรเครดิตที่ใช้ในการทำธุรกรรมออนไลน์ด้วย CVV มีความล่อแหลมมากกว่าหมายเลขบัตรเครดิต แตในการตรวจจับเนื่องจากมันมีจำนวนสั้น ๆ และไม่มีตัวเลข checksum
วิธีหนึ่งในการตรวจจับหมายเลข CVV คือการค้นหาตัวเลขสามหรือสี่ตัวในเขตข้อมูลในฟอร์มหนึ่ง ที่พบหมายเลขบัตรเครดิต วิธีนี้ยังอาจพบผลบวกลวงได้ แต่ระบบที่มีความระมัดระวังอาจช่วยทำให้ผลข้อมูลบวกลวงน้อยลงได้
4. บทสรุป
การตรวจจับการขโมยข้อมูลบัตรเครดิตโดยการเฝ้าดูการจราจรในเครือข่ายทำได้ ยากมาก แต่การเฝ้าดูดังกล่าวอาจมีประโยชน์ในการใช้เพื่อตรวจจับการรั่วไหลของ หมายเลขบัตรเครดิตโดยไม่ได้ตั้งใจ ในการทำเช่นนี้ระบบเฝ้าดูจะต้องรู้จักกับแอพพลิเคชั่นและโปรโตคอล เพื่อชดเชยกับการเข้ารหัสที่ใช้กับข้อมูล และยังใช้เป็นเครื่องมือในการสร้างกฏ (Rule Base Signature) หรือข้อยกเว้นสำหรับหมายเลขบัตรเครดิตที่ถูกต้องหรือข้อมูลอื่น ๆ ที่อาจถูกตรวจจับอย่างผิดพลาดว่าเป็นหมายเลขบัตรเครดิต
5. อธิบายคำศัพท์
Regular Expression หมายถึง รูปแบบของลำดับ หรือกลุ่มของสัญลักษณ์ที่ใช้แทนลำดับ หรือกลุ่มของอักขระตามที่ต้องการ
checksum เป็นรูปแบบหนึ่งของ redundancy check (ข้อมูลพิเศษที่เพิ่มเข้าไปในข้อความเพื่อจุดประสงค์ในการตรวจจับผิดพลาดและ ทำให้ถูกต้อง) เป็นวิธีง่าย ๆ ในการป้องกันความครบถ้วนของข้อมูลโดยการตรวจจับความผิดพลาดในข้อมูลส่งผ่าน ทางระยะทาง (โทรคมนาคม) หรือเวลา (พื้นที่เก็บข้อมูล) ทำงานโดยการเพิ่มองค์ประกอบพื้นฐานของข้อความ โดยทั่วไปแล้วมักจะเป็นข้อมูลที่ใช้ยืนยันความถูกต้อง และเก็บค่าที่ได้ไว้ ทุกคนสามารถกระทำการอย่างเดียวกับข้อมูลนั้น และเปรียบเทียบผลที่ได้กับ checksum ของแท้และสรุปได้ว่าข้อความนั้นได้ถูกเปลี่ยนแปลงหรือไม่
LUHN algorithm หรือ LUHN formula เป็นสูตรในการ checksum เพื่อตรวจสอบความถูกต้องของหมายเลขไอดีต่าง ๆ เช่น หมายเลขบัตรเครดิตและหมายเลขประกันสังคมของแคนาดา สร้างขึ้นโดย Hans Peter Luhn นักวิทยาศาสตร์ของบริษัทไอบีเอ็ม
นนทวรรธนะ สาระมานNontawattana Saraman
SRAN Dev
ของเก่ามาเล่าใหม่ครับ เป็นบทความที่ดีนำมาเสนออีกครั้ง
อ่านเพิ่มเติม เรื่อง How .NET Regular Expressions Really Work
บทความ มาทำความรู้จักมาตรฐาน PCI DSS กับการรับรองมาตรฐานกับ Global Technology Integrated
วันอังคาร, กันยายน 22
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 3
ต่อจากตอนที่แล้วครับ ผมขอนำเสนอเลยเนื่องจากเนื้อหาในตอนนี้มากกว่าทุกตอน
ในระดับ Application Layer เราควรมองพฤติกรรมเป็นสองฝั่งคือ
* ฝั่งของผู้ให้บริการ เช่น จัดตั้งเป็น Web Server ที่มีชื่อ world wide web (www.) , Mail Server ที่ผ่าน Protocol SMTP และอื่นๆ นั้นสามารถถูกเรียกใช้จากภายนอกได้อยู่เสมอ ซึ่งเป็นข้อมูลสาธารณะ
** ฝั่งของผู้ใช้บริการ คือเราๆท่านๆ ที่ทำการเรียกใช้ เช่น การค้นหาข้อมูล การดูหนัง ฟังเพลง ในฝั่งของผู้ใช้บริการหากพิจารณาให้ดี ก็จะแบ่งได้อีก คือ ผู้ใช้บริการนั้น ใช้อินเตอร์เน็ตติดต่อที่ใด ?
หากเป็นสถานที่เชื่อมต่ออินเตอร์เน็ต ที่อยู่ใน LAN ผู้ใช้บริการจะมี IP Address เป็น Private IP (10.x.x.x, 172.16.x.x. , 192.168.x.x สุดแล้วจะตั้งค่า subnet ให้เป็น class A,Bหรือ C ซึ่งเป็น IP v4 ที่สงวนไว้สำหรับใช้ใน LAN)
หากเป็นสถานที่เชื่อมต่ออินเตอร์เน็ต ที่ติดต่อตรง (ซึ่งน้อยมาก) ผู้ใช้บริการจะมี IP Address เป็น Public IP
ในการสืบสวนสอบสวนหาผู้กระทำความผิด สำหรับผู้ใช้บริการแล้วหากสามารถหา IP Public มักจะหาผู้กระทำผิดได้ไม่ยาก แต่ในทางตรงข้าม IP private ที่เกิดจากผู้ใช้งานในเครือข่าย (Network) องค์กรก็สามารถหาได้เช่นกันหากองค์กรนั้นได้มีการจัดเก็บข้อมูลจราจรตาม พระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ ซึ่งได้บังคับให้ทุกที่ได้มีการจัดเก็บ Log ขึ้นเพื่อประโยชน์ในการสืบหาผู้กระทำความผิดนั้นเอง
ฝั่งของผู้ให้บริการ ผมขอแยกเป็น Application protocol ที่จำเป็นและสำคัญที่ทุกเครือข่ายเปิดใช้จะกล่าวถึงเฉพาะ Application Protocol ที่สำคัญอยู่ 3 ชนิดได้แก่ Web , DNS และ Mail เรามาดูตัวแรกกัน
1. Web (HTTP) ภัยคุกคามที่มากับ Protocol นี้นับว่าเป็นการรับมือการโจมตีชนิดต่างๆได้ยาก เนื่องจากการเปิด Web Server ขึ้นมานั้นประกอบด้วยทางเข้าถึงระบบมีหลากหลายหนทาง ไม่ว่าเป็นช่องโหว่ (Bug) ต่างๆ ที่เกิดขึ้นได้แก่
- ช่องโหว่ที่เกิดขึ้นจาก OS (Operating System) การโจมตีก็มี ทั้งแบบ Remote และ Access โดยตรงกับเครื่องที่ให้บริการ ไม่ว่าเป็นการโจมตีแบบ Remote Exploit ผ่านเครือข่ายเพื่อเข้าถึง OS หรือการ Access โดยตรงเพื่อทำให้เกิด Buffer overflow เป็นต้น
- ช่องโหว่ที่เกิดจาก Web Server เอง เช่น IIS 6 , IIS 7 , Apache อื่นๆ มีทั้งแบบ Remote และ Access โดยตรงกับเครื่องที่ให้บริการ ไม่ว่าเป็นการโจมตีแบบ Remote Exploit และการ Access โดยตรงเพื่อทำให้เกิด Buffer overflow
- ช่องโหว่ที่เกิดจากโปรแกรม ไม่ว่าเป็นการให้บริการของ Web Application ที่ใช้โปรแกรมในการเขียน เช่น Java , CGI , Perl ,PHP อื่นๆ อีกมากมาย ยิ่งถ้าเป็น Web 2.0 แล้วการเปิด Web Application มากขึ้นก็ทำให้การเข้าถึงระบบ มีช่องทางเข้าถึงระบบ ตามช่องโหว่าที่พบ OS , Application ยิ่งถ้าใน Web Application นั้นมี Data Base (SQL Server, Mysql เป็นต้น) ในเครื่องเดียวก็ยิ่งมีความเสี่ยงมากขึ้นเป็นเงาตามตัว
เพียงช่องทางเดียวคือ Port 80 ที่เปิดให้บริการ
สิ่งที่เราควรตรวจสอบ Web Application มีดังนี้
1.1 ตรวจหา Web Application Fingerprint : เพื่อให้รู้ถึงเวอร์ชั่นและชนิดของ web server ที่ใช้เพื่อให้ผู้ทดสอบสามารถรู้ถึงช่องโหว่และการโจมตีที่ถูกต้องในระหว่างการทดสอบได้
1.2 ตรวจสอบ Application Discovery : เพื่อค้นหาว่ามีแอพพลิเคชั่นใดที่ทำงานอยู่ใน web server นี้บ้างเช่นตรวจดู Hyper link ทั้งหมดในเว็บไซต์เพื่อดูความผิดปกติ Link และหากพบว่ายังขาดการตั้งค่าสิทธิการเข้าถึง Link path ที่สำคัญก็ควรปิด เช่น path ที่เกี่ยวข้องกับการ config ต่างๆ
1.3 วิเคราะห์หา Error Code : การทดสอบ web application มักจะพบกับ error code จากแอพพลิเคชั่นหรือ web server เป็นไปได้ที่จะทำให้เกิดมีการแสดง error เหล่านี้โดยการใช้ request เฉพาะ ข้อความแสดงข้อผิดพลาดเหล่านี้มีประโยชน์มากสำหรับผู้ทดสอบเพราะมันจะเปิดเผยข้อมูลที่มีประโยชน์เกี่ยวกับฐานข้อมูล ช่องโหว่ (bug) และองค์ประกอบอื่น ๆ ที่เกี่ยวข้อง
1.4 ทดสอบ file extensions handling : web server มักใช้ file extension เพื่อตัดสินใจเกี่ยวกับเทคโนโลยี ภาษา ปลั๊กอินที่ต้องใช้เพื่อร้องของผ่านทางเวบให้สำเร็จผล การทดสอบ file extension ให้ข้อมูลที่มีประโยชน์สำหรับผู้ทดสอบเกี่ยวกับเทคโนโลยีที่ใช้ใน web application และยังช่วยให้การเลือกรูปแบบในการโจมตีสำหรับเทคโนโลยีต่าง ๆ ทำได้ง่ายขึ้น นอกจากนี้การกำหนดค่าที่ผิดพลาดใน web server ยังอาจเปิดถึงข้อมูลสำคัญเกี่ยวกับการเข้าถึงระบบอีกด้วย
1.5 ทดสอบ SSL-TLS : การกำหนดค่าที่ผิดพลาดใน web server ที่เกี่ยวกับการเข้ารหัสการสื่อสาร อาจทำให้ผู้โจมตีสามารถใช้การเข้ารหัสที่มีความปลอดภัยน้อยกว่าเพื่อเข้าถึงช่องทางการสื่อสารที่เข้ารหัสไว้ได้
1.6 ทดสอบการค้นหา old file : ไฟล์ที่ไม่ใช้งานหรือไฟล์เก่าอาจสามารถใช้เพื่อหาข้อมูลสำคัญเกี่ยวกับโครงสร้างระบบหรือวิธีการเข้าถึงระบบได้
1.7 ทดสอบค่า Default or Guessable User Account : web application ในปัจจุบันนี้มักอาศัยซอฟท์แวร์ยอดนิยม ซึ่งอาจเป็นแบบโอเพ่นซอร์สหรือขายเชิงพาณิชย์ซึ่งติดตั้งใน server และจำเป็นต้องมีการกำหนดค่าหรือปรับแต่งโดยผู้ดูแลระบบ บ่อยครั้งที่ แอพพลิเคชั่นเหล่านี้ไม่ได้กำหนดค่าอย่างถูกต้องและไม่ได้อัพเดทชื่อผู้ใช้และรหัสผ่าน ทำให้ผู้บุกรุกสามารถใช้เพื่อเข้าถึงเครือข่ายภายในและขโมยข้อมูลได้
1.8 ทดสอบการ Brute Force password : เป็นการทดลองเข้าระบบโดยการใช้ชื่อผู้ใช้และรหัสผ่านที่เป็นไปได้ทั้งหมด ในการทดสอบ web application เราจะตรวจสอบชนิดของการพิสูจน์ตัวผู้ใช้และความมีประสิทธิภาพในการโจมตี brute-force แบบต่าง ๆ
1.9 ทดสอบการ Bypassing Authentication Schema : ในขณะที่แอพพลิเคชั่นส่วนใหญ่จำเป็นต้องอาศัยการพิสูจน์ตัวเพื่อการเข้าถึงข้อมูลหรือทำงานบางอย่าง แต่ไม่ได้หมายความวิธีการที่ใช้ในการพิสูจน์ตัวทุกวิธีที่มีใช้การรักษาความปลอดภัยอย่างเพียงพอ ความละเลย ความไม่รู้ หรือไม่ให้ความสำคัญกับภัยคุกคามด้านความปลอดภัยมักมีผลทำให้ระบบที่ใช้ในการพิสูจน์ตัวผู้ใช้ถูกหลบหลีกได้อย่างง่ายดายโดยการหลบหลีกหน้าล็อกอินและเรียกหน้าภายในโดยตรง นอกจากนี้ยังอาจสามารถหลบหลีกมาตรการในการพิสูจน์ผู้ใช้โดยการแก้ไขการร้องขอโดยการหลอกให้แอพพลิเคชั่นคิดว่าได้ผ่านการพิสูจน์ตัวแล้ว โดยการแก้ไขพารามิเตอร์ของ URL หรือแก้ไข form หรือปลอม session
1.10 ทดสอบ Directory Traversal : มี web application หลายตัวที่ใช้และจัดการไฟล์ ถ้าแอพพลิเคชั่นเหล่านี้ใช้วิธีการตรวจสอบอินพุทที่ออกแบบมาไม่ดี ผู้โจมตีสามารถอาศัยประโยชน์เพื่ออ่าน/เขียนไฟล์ที่ไม่ได้ตั้งใจให้สามารถเข้าถึงได้ ในบางสถานการณ์อาจสามารถทำให้สามารถเอ็กซิคิวท์โค้ดที่ต้องการได้
1.11 ทดสอบหา Vulnerable Remember Password and Pwd Reset : มี web application หลายตัวที่ช่วยให้ผู้ใช้สามารถรีเซ็ตรหัสผ่านในกรณีที่ลืมรหัสผ่าน ซึ่งโดยปกติมักจะส่งอีเมลที่บอกรหัสผ่านที่รีเซ็ตใหม่ไปให้ หรือถามคำถามที่ผู้ใช้เคยกำหนดไว้ให้ถูกต้อง ในการทดสอบนี้เราจะตรวจสอบว่าระบบนี้ทำงานได้อย่างถูกต้องและไม่มีช่องโหว่ในการทำงาน
1.12 ทดสอบหาค่าตกค้าง จากการ Logout และ Browser Cache Management : ในขั้นตอนนี้ เราจะตรวจสอบว่าการทำงานของระบบ logout ทำงานได้อย่างถูกต้องหรือไม่ และเป็นไปได้ที่จะใช้ session ใหม่อีกครั้งหลังจาก logout แล้วหรือไม่ เรายังตรวจอีกด้วยว่าแอพพลิเคชั่นดังกล่าวได้ logout ผู้ใช้แบบอัตโนมัติหลังจากผู้ใช้ไม่ทำงานหลังจากช่วงระยะเวลาหนึ่งผ่านไปแล้วหรือไม่ และไม่มีข้อมูลสำคัญที่ยังคงค้างอยู่ใน cache ของบราวเซอร์
1.13 ทดสอบค่า Session Management Schema : ในการหลีกเลี่ยงการพิสูจน์ตัวผู้ใช้สำหรับแต่ละหน้าของเวบไซต์หรือบริการหนึ่ง web application จะใช้กลไกต่าง ๆ ในการเก็บและตรวจสอบชื่อผู้ใช้และรหัสผ่านสำหรับช่วงเวลาหนึ่งที่กำหนดไว้ กลไกเหล่านี้เรียกว่า Session Management ซึ่งช่วยให้แอพพิลเคชั่นเหล่านี้ใช้งานง่าย แต่มันอาจจะถูกใช้ประโยชน์จากผู้ทดสอบเพื่อให้สามารถเข้าถึงแอคเคาท์ของผู้ใช้โดยไม่จำเป็นต้องใส่ชื่อและรหัสผ่านที่ถูกต้องได้
1.14 ทดสอบค่า Cookie and Session Token Manipulation : ตรวจสอบว่า cookie และสิ่งที่ใช้สำหรับแสดง session แบบอื่น ๆ ได้สร้างขึ้นมาอย่างปลอดภัยและไม่สามารถคาดเดาได้ ผู้โจมตีที่สามารถเดาและปลอม cookie ได้จะสามารถเข้าถึง session ของผู้ใช้ที่ถูกต้องได้
1.15 ทดสอบค่า Exposed Session Variables : ถ้าสิ่งที่ใช้แสดง session (cookie, SessionID, Hidden Field) ถูกเปิดเผย ทำให้ผู้โจมตีสามารถปลอมเป็นเหยื่อและเข้าถึงแอพพิลเคชั่นได้ ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องป้องกันจากการดักข้อมูล โดยเฉพาะในการส่งข้อมูลระหว่างไคลเอ็นท์และ application server
1.17 ทดสอบ HTTP Exploit : ขั้นตอนนี้จะอาศัยฟีเจอร์ของ HTTP protocol เพื่อโจมตี ซึ่งอาจอาศัยช่องโหว่ใน web application หรือวิธีการต่าง ๆ ที่ agent ใช้เพื่อตีความข้อความของ HTTP
1.18 ทดสอบ Cross site scripting : เป็นการโจมตีในระดับแอพพิลเคชั่นที่พบได้บ่อยครั้ง Cross Site Scripting ใช้ตัวย่อ XSS เพื่อหลีกเลี่ยงความสับสนกับคำว่า Cascading Style Sheets (CSS) การทดสอบ XSS มักเป็นผลให้มีการแสดงหน้าต่าง JavaScript alert แสดงให้ผู้ใช้เห็น หน้าต่าง alert อาจเป็นสัญญาณที่บ่งชี้ได้ว่าผู้โจมตีสามารถรันโค้ดที่ต้องการได้ อ่านเพิ่มเติมได้ที่ http://www.sran.net/archives/200 และ http://www.sran.net/archives/201
1.19 ทดสอบค่า HTTP Methods and XST : ในขั้นตอนนี้เราจะตรวจสอบว่า web server ไม่ได้กำหนดค่าให้ยอมรับคำสั่ง (method) HTTP ที่มีอันตรายและการโจมตี Cross Site Tracing (XST) ไม่สามารถทำได้
1.20 ทดสอบ SQL Injection : เพื่อทดสอบการโจมตี SQL Injection ประกอบด้วยการป้อนคำสั่ง SQL ผ่านทางข้อมูลอินพุทจากไคลเอ็นท์ไปยังแอพพลิเคชั่น การโจมตี SQL injection ที่สำเร็จสามารถอ่านข้อมูลที่เป็นความลับจากฐานข้อมูล แก้ไขข้อมูลในฐานข้อมูล เอ็กซิคิวท์คำสั่งของผู้ดูแลระบบ หรือในบางกรณีสามารถใช้คำสั่งภายในระบบได้
1.21 ทดสอบ SSI Injection : เพื่อทดสอบ web server หลายตัวที่มีฟีเจอร์ที่ช่วยให้สามารถเพิ่มโค้ดแบบไดนามิคเข้าไปในหน้า html แบบ static ฟีเจอร์นี้เรียกว่า Server-Side Includes (SSI) เป็น extension ที่อาจทำให้ผู้โจมตีสามารถใส่โค้ดเข้าไปในหน้า html หรือเอ็กซิคิวท์โค้ดจากระยะไกลได้
1.22 ทดสอบ IMAP/SMTP Injection : เพื่อตรวจสอบภัยคุกคามนี้มีผลกระทบกับแอพพลิเคชั่นที่สื่อสารกับ mail server (IMAP/SMTP) ส่วนใหญ่แล้วจะเป็น webmail เพื่อทดสอบความเป็นไปได้ในการป้อนคำสั่ง IMAP/SMTP เข้าไปใน mail server เนื่องจากไม่มีการตรวจสอบข้อมูลที่ป้อนเข้าไปอย่างเพียงพอ
1.23 ทดสอบ Code Injection : เพื่อทดสอบว่าสามารถใส่โค้ดเข้าไปในหน้าเวบและทำให้ web server เอ็กซิคิวท์โค้ดดังกล่าวได้หรือไม่
1.24 ทดสอบ Command Injection : เป็นการทดสอบการป้อนคำสั่งของระบบปฏิบัติการผ่านทาง HTTP request ไปยังแอพพลิเคชั่น
1.25 ทดสอบช่องโหว่ Web Application ผ่านช่องทางระบบ Search engine ซึ่งเราสามารถค้นหาลักษณะตัวแปรของการเขียน code web application และหาช่องโหว่ได้ ผมได้เขียนไว้ที่ http://nontawattalk.blogspot.com/2004/12/personal-information-is-not-secured.html
2. ผู้ให้บริการ DNS Server ที่เป็นบริการสาธารณะ (อ่านมุมมองในการเก็บ Log http://nontawattalk.blogspot.com/2009/04/blog-post.html เพื่อสืบหาผู้กระทำความผิด)
ช่องโหว่ที่มีกับ DNS Server ที่เป็นลักษณะ Fast flux ซึ่งเป็นเทคนิคทาง DNS ที่ใช้โดย botnet เพื่อซ่อนไซต์ที่ทำหน้าที่ให้บริการ phishing และมัลแวร์ ที่อยู่เบื้องหลังเครือข่ายของโฮสต์ที่ถูกบุกรุก
ทำตัวเป็น proxy ที่มีการเปลี่ยนแปลงตลอดเวลา ยังหมายถึงเครือข่ายแบบ peer-to-peer รวมกันหลายเครือข่าย ใช้เทคนิคต่าง ๆ ได้แก่ การใช้คำสั่งและการควบคุมแบบกระจาย (distributed) การใช้ load-balancing และการเปลี่ยนเส้นทาง proxy เพื่อทำให้การเครือข่ายมัลแวร์ยากต่อการถูกตรวจพบและการป้องกัน Storm Worm เป็นหนึ่งในมัลแวร์ที่ใช้เทคนิคเหล่านี้ผู้ใช้อินเทอร์เน็ตอาจพบการใช้ fast flux ในการโจมตี phishing ที่มีเชื่อมโยงกับกลุ่มอาชญากร รวมถึงการโจมตี MySpace , facebook อีกด้วย
ลักษณะการโจมตี DNS แบบ Single-flux และ double-flux
fast flux แบบง่าย ๆ เรียกว่า "single-flux" มีโหนดหลาย ๆ โหนดภายในเครือข่ายที่ลงทะเบียนและเลิกลงทะเบียนที่อยู่ของพวกมันโดยใช้ DNS A record สำหรับชื่อ DNS เดียว ใช้ round robin DNS ที่มีค่า TTL (time to live) สั้นมาก ๆ เพื่อสร้างรายชื่อของที่อยู่เป้าหมายที่มีการเปลี่ยนแปลงตลอดเวลาสำหรับชื่อ DNS เดียว รายชื่อนี้อาจยาวเป็นหลายร้อยหรือหลายพันบรรทัด fast flux ที่มีความซับซ้อนมากกว่านี้เรียกว่า "double-flux" มีหลายโหนดภายในเครือข่ายที่ลงทะเบียนและเลิกลงทะเบียนที่อยู่ของพวกมัน
โดยใช้ DNS SOA (start of authority) record ซึ่งจะช่วยเพิ่มเสถียรภาพและความอยู่รอดภายในเครือข่ายมัลแวร์นี้ได้
การทดสอบ DNS Server
ให้มีการตรวจสอบการ query Zone Tranfer ซึ่งเป็นผลทำให้ทราบข้อมูลในส่วนเครื่องแม่ข่าย (Server) ทั้งหมดในองค์กรได้
Zone transfer เป็นวิธีการที่ secondary DNS server ใช้สำหรับอัพเดทข้อมูลจาก primary DNS server, DNS server ของโดเมนหนึ่งจะทำงานใช้วิธีการที่เรียกว่า master-slave ซึ่งตัวที่เป็น slave จะอัพเดทข้อมูล DNS จากตัวที่เป็น master ผู้ดูแลระบบควรกำหนด DNS server ให้ยอมให้มีการทำ zone transfer จาก secondary (slave) DNS server เท่านั้น
3. Mail Server ที่เป็นการให้บริการสาธารณะ Mail Server มักจะมีการใช้ DNS และ Web Application มาเกี่ยวข้องดังนั้นภัยคุกคามที่เกิดกับ Mail Server นั้นต้องพิจารณา DNS และเรื่องของ Web Application มาเกี่ยวข้องด้วยเสมอ เนื่องจาก Mail ในยุคปัจจุบันก็สามารถทำงานผ่าน Web Application มากขึ้น
ภัยคุกคามจาก Mail Server ที่ควรตรวจสอบก็ควรพิจารณาผู้อื่นมาใช้ Mail Server เราเพื่อทำเป็น Spam Server ได้จากการตรวจสอบขั้นต้นคือดูที่ Mail server เปิด Open relay ที่จะอนุญาตให้บุคคลภายในใช้ mail server เพื่อส่งอีเมลไปยังที่อื่นได้หรือไม่ จากคำสั่ง
บทความเกี่ยวข้อง
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 1
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 2
ในระดับ Application Layer เราควรมองพฤติกรรมเป็นสองฝั่งคือ
* ฝั่งของผู้ให้บริการ เช่น จัดตั้งเป็น Web Server ที่มีชื่อ world wide web (www.) , Mail Server ที่ผ่าน Protocol SMTP และอื่นๆ นั้นสามารถถูกเรียกใช้จากภายนอกได้อยู่เสมอ ซึ่งเป็นข้อมูลสาธารณะ
** ฝั่งของผู้ใช้บริการ คือเราๆท่านๆ ที่ทำการเรียกใช้ เช่น การค้นหาข้อมูล การดูหนัง ฟังเพลง ในฝั่งของผู้ใช้บริการหากพิจารณาให้ดี ก็จะแบ่งได้อีก คือ ผู้ใช้บริการนั้น ใช้อินเตอร์เน็ตติดต่อที่ใด ?
หากเป็นสถานที่เชื่อมต่ออินเตอร์เน็ต ที่อยู่ใน LAN ผู้ใช้บริการจะมี IP Address เป็น Private IP (10.x.x.x, 172.16.x.x. , 192.168.x.x สุดแล้วจะตั้งค่า subnet ให้เป็น class A,Bหรือ C ซึ่งเป็น IP v4 ที่สงวนไว้สำหรับใช้ใน LAN)
หากเป็นสถานที่เชื่อมต่ออินเตอร์เน็ต ที่ติดต่อตรง (ซึ่งน้อยมาก) ผู้ใช้บริการจะมี IP Address เป็น Public IP
ในการสืบสวนสอบสวนหาผู้กระทำความผิด สำหรับผู้ใช้บริการแล้วหากสามารถหา IP Public มักจะหาผู้กระทำผิดได้ไม่ยาก แต่ในทางตรงข้าม IP private ที่เกิดจากผู้ใช้งานในเครือข่าย (Network) องค์กรก็สามารถหาได้เช่นกันหากองค์กรนั้นได้มีการจัดเก็บข้อมูลจราจรตาม พระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ ซึ่งได้บังคับให้ทุกที่ได้มีการจัดเก็บ Log ขึ้นเพื่อประโยชน์ในการสืบหาผู้กระทำความผิดนั้นเอง
ฝั่งของผู้ให้บริการ ผมขอแยกเป็น Application protocol ที่จำเป็นและสำคัญที่ทุกเครือข่ายเปิดใช้จะกล่าวถึงเฉพาะ Application Protocol ที่สำคัญอยู่ 3 ชนิดได้แก่ Web , DNS และ Mail เรามาดูตัวแรกกัน
1. Web (HTTP) ภัยคุกคามที่มากับ Protocol นี้นับว่าเป็นการรับมือการโจมตีชนิดต่างๆได้ยาก เนื่องจากการเปิด Web Server ขึ้นมานั้นประกอบด้วยทางเข้าถึงระบบมีหลากหลายหนทาง ไม่ว่าเป็นช่องโหว่ (Bug) ต่างๆ ที่เกิดขึ้นได้แก่
- ช่องโหว่ที่เกิดขึ้นจาก OS (Operating System) การโจมตีก็มี ทั้งแบบ Remote และ Access โดยตรงกับเครื่องที่ให้บริการ ไม่ว่าเป็นการโจมตีแบบ Remote Exploit ผ่านเครือข่ายเพื่อเข้าถึง OS หรือการ Access โดยตรงเพื่อทำให้เกิด Buffer overflow เป็นต้น
- ช่องโหว่ที่เกิดจาก Web Server เอง เช่น IIS 6 , IIS 7 , Apache อื่นๆ มีทั้งแบบ Remote และ Access โดยตรงกับเครื่องที่ให้บริการ ไม่ว่าเป็นการโจมตีแบบ Remote Exploit และการ Access โดยตรงเพื่อทำให้เกิด Buffer overflow
- ช่องโหว่ที่เกิดจากโปรแกรม ไม่ว่าเป็นการให้บริการของ Web Application ที่ใช้โปรแกรมในการเขียน เช่น Java , CGI , Perl ,PHP อื่นๆ อีกมากมาย ยิ่งถ้าเป็น Web 2.0 แล้วการเปิด Web Application มากขึ้นก็ทำให้การเข้าถึงระบบ มีช่องทางเข้าถึงระบบ ตามช่องโหว่าที่พบ OS , Application ยิ่งถ้าใน Web Application นั้นมี Data Base (SQL Server, Mysql เป็นต้น) ในเครื่องเดียวก็ยิ่งมีความเสี่ยงมากขึ้นเป็นเงาตามตัว
เพียงช่องทางเดียวคือ Port 80 ที่เปิดให้บริการ
สิ่งที่เราควรตรวจสอบ Web Application มีดังนี้
1.1 ตรวจหา Web Application Fingerprint : เพื่อให้รู้ถึงเวอร์ชั่นและชนิดของ web server ที่ใช้เพื่อให้ผู้ทดสอบสามารถรู้ถึงช่องโหว่และการโจมตีที่ถูกต้องในระหว่างการทดสอบได้
1.2 ตรวจสอบ Application Discovery : เพื่อค้นหาว่ามีแอพพลิเคชั่นใดที่ทำงานอยู่ใน web server นี้บ้างเช่นตรวจดู Hyper link ทั้งหมดในเว็บไซต์เพื่อดูความผิดปกติ Link และหากพบว่ายังขาดการตั้งค่าสิทธิการเข้าถึง Link path ที่สำคัญก็ควรปิด เช่น path ที่เกี่ยวข้องกับการ config ต่างๆ
1.3 วิเคราะห์หา Error Code : การทดสอบ web application มักจะพบกับ error code จากแอพพลิเคชั่นหรือ web server เป็นไปได้ที่จะทำให้เกิดมีการแสดง error เหล่านี้โดยการใช้ request เฉพาะ ข้อความแสดงข้อผิดพลาดเหล่านี้มีประโยชน์มากสำหรับผู้ทดสอบเพราะมันจะเปิดเผยข้อมูลที่มีประโยชน์เกี่ยวกับฐานข้อมูล ช่องโหว่ (bug) และองค์ประกอบอื่น ๆ ที่เกี่ยวข้อง
1.4 ทดสอบ file extensions handling : web server มักใช้ file extension เพื่อตัดสินใจเกี่ยวกับเทคโนโลยี ภาษา ปลั๊กอินที่ต้องใช้เพื่อร้องของผ่านทางเวบให้สำเร็จผล การทดสอบ file extension ให้ข้อมูลที่มีประโยชน์สำหรับผู้ทดสอบเกี่ยวกับเทคโนโลยีที่ใช้ใน web application และยังช่วยให้การเลือกรูปแบบในการโจมตีสำหรับเทคโนโลยีต่าง ๆ ทำได้ง่ายขึ้น นอกจากนี้การกำหนดค่าที่ผิดพลาดใน web server ยังอาจเปิดถึงข้อมูลสำคัญเกี่ยวกับการเข้าถึงระบบอีกด้วย
1.5 ทดสอบ SSL-TLS : การกำหนดค่าที่ผิดพลาดใน web server ที่เกี่ยวกับการเข้ารหัสการสื่อสาร อาจทำให้ผู้โจมตีสามารถใช้การเข้ารหัสที่มีความปลอดภัยน้อยกว่าเพื่อเข้าถึงช่องทางการสื่อสารที่เข้ารหัสไว้ได้
1.6 ทดสอบการค้นหา old file : ไฟล์ที่ไม่ใช้งานหรือไฟล์เก่าอาจสามารถใช้เพื่อหาข้อมูลสำคัญเกี่ยวกับโครงสร้างระบบหรือวิธีการเข้าถึงระบบได้
1.7 ทดสอบค่า Default or Guessable User Account : web application ในปัจจุบันนี้มักอาศัยซอฟท์แวร์ยอดนิยม ซึ่งอาจเป็นแบบโอเพ่นซอร์สหรือขายเชิงพาณิชย์ซึ่งติดตั้งใน server และจำเป็นต้องมีการกำหนดค่าหรือปรับแต่งโดยผู้ดูแลระบบ บ่อยครั้งที่ แอพพลิเคชั่นเหล่านี้ไม่ได้กำหนดค่าอย่างถูกต้องและไม่ได้อัพเดทชื่อผู้ใช้และรหัสผ่าน ทำให้ผู้บุกรุกสามารถใช้เพื่อเข้าถึงเครือข่ายภายในและขโมยข้อมูลได้
1.8 ทดสอบการ Brute Force password : เป็นการทดลองเข้าระบบโดยการใช้ชื่อผู้ใช้และรหัสผ่านที่เป็นไปได้ทั้งหมด ในการทดสอบ web application เราจะตรวจสอบชนิดของการพิสูจน์ตัวผู้ใช้และความมีประสิทธิภาพในการโจมตี brute-force แบบต่าง ๆ
1.9 ทดสอบการ Bypassing Authentication Schema : ในขณะที่แอพพลิเคชั่นส่วนใหญ่จำเป็นต้องอาศัยการพิสูจน์ตัวเพื่อการเข้าถึงข้อมูลหรือทำงานบางอย่าง แต่ไม่ได้หมายความวิธีการที่ใช้ในการพิสูจน์ตัวทุกวิธีที่มีใช้การรักษาความปลอดภัยอย่างเพียงพอ ความละเลย ความไม่รู้ หรือไม่ให้ความสำคัญกับภัยคุกคามด้านความปลอดภัยมักมีผลทำให้ระบบที่ใช้ในการพิสูจน์ตัวผู้ใช้ถูกหลบหลีกได้อย่างง่ายดายโดยการหลบหลีกหน้าล็อกอินและเรียกหน้าภายในโดยตรง นอกจากนี้ยังอาจสามารถหลบหลีกมาตรการในการพิสูจน์ผู้ใช้โดยการแก้ไขการร้องขอโดยการหลอกให้แอพพลิเคชั่นคิดว่าได้ผ่านการพิสูจน์ตัวแล้ว โดยการแก้ไขพารามิเตอร์ของ URL หรือแก้ไข form หรือปลอม session
1.10 ทดสอบ Directory Traversal : มี web application หลายตัวที่ใช้และจัดการไฟล์ ถ้าแอพพลิเคชั่นเหล่านี้ใช้วิธีการตรวจสอบอินพุทที่ออกแบบมาไม่ดี ผู้โจมตีสามารถอาศัยประโยชน์เพื่ออ่าน/เขียนไฟล์ที่ไม่ได้ตั้งใจให้สามารถเข้าถึงได้ ในบางสถานการณ์อาจสามารถทำให้สามารถเอ็กซิคิวท์โค้ดที่ต้องการได้
1.11 ทดสอบหา Vulnerable Remember Password and Pwd Reset : มี web application หลายตัวที่ช่วยให้ผู้ใช้สามารถรีเซ็ตรหัสผ่านในกรณีที่ลืมรหัสผ่าน ซึ่งโดยปกติมักจะส่งอีเมลที่บอกรหัสผ่านที่รีเซ็ตใหม่ไปให้ หรือถามคำถามที่ผู้ใช้เคยกำหนดไว้ให้ถูกต้อง ในการทดสอบนี้เราจะตรวจสอบว่าระบบนี้ทำงานได้อย่างถูกต้องและไม่มีช่องโหว่ในการทำงาน
1.12 ทดสอบหาค่าตกค้าง จากการ Logout และ Browser Cache Management : ในขั้นตอนนี้ เราจะตรวจสอบว่าการทำงานของระบบ logout ทำงานได้อย่างถูกต้องหรือไม่ และเป็นไปได้ที่จะใช้ session ใหม่อีกครั้งหลังจาก logout แล้วหรือไม่ เรายังตรวจอีกด้วยว่าแอพพลิเคชั่นดังกล่าวได้ logout ผู้ใช้แบบอัตโนมัติหลังจากผู้ใช้ไม่ทำงานหลังจากช่วงระยะเวลาหนึ่งผ่านไปแล้วหรือไม่ และไม่มีข้อมูลสำคัญที่ยังคงค้างอยู่ใน cache ของบราวเซอร์
1.13 ทดสอบค่า Session Management Schema : ในการหลีกเลี่ยงการพิสูจน์ตัวผู้ใช้สำหรับแต่ละหน้าของเวบไซต์หรือบริการหนึ่ง web application จะใช้กลไกต่าง ๆ ในการเก็บและตรวจสอบชื่อผู้ใช้และรหัสผ่านสำหรับช่วงเวลาหนึ่งที่กำหนดไว้ กลไกเหล่านี้เรียกว่า Session Management ซึ่งช่วยให้แอพพิลเคชั่นเหล่านี้ใช้งานง่าย แต่มันอาจจะถูกใช้ประโยชน์จากผู้ทดสอบเพื่อให้สามารถเข้าถึงแอคเคาท์ของผู้ใช้โดยไม่จำเป็นต้องใส่ชื่อและรหัสผ่านที่ถูกต้องได้
1.14 ทดสอบค่า Cookie and Session Token Manipulation : ตรวจสอบว่า cookie และสิ่งที่ใช้สำหรับแสดง session แบบอื่น ๆ ได้สร้างขึ้นมาอย่างปลอดภัยและไม่สามารถคาดเดาได้ ผู้โจมตีที่สามารถเดาและปลอม cookie ได้จะสามารถเข้าถึง session ของผู้ใช้ที่ถูกต้องได้
1.15 ทดสอบค่า Exposed Session Variables : ถ้าสิ่งที่ใช้แสดง session (cookie, SessionID, Hidden Field) ถูกเปิดเผย ทำให้ผู้โจมตีสามารถปลอมเป็นเหยื่อและเข้าถึงแอพพิลเคชั่นได้ ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องป้องกันจากการดักข้อมูล โดยเฉพาะในการส่งข้อมูลระหว่างไคลเอ็นท์และ application server
1.17 ทดสอบ HTTP Exploit : ขั้นตอนนี้จะอาศัยฟีเจอร์ของ HTTP protocol เพื่อโจมตี ซึ่งอาจอาศัยช่องโหว่ใน web application หรือวิธีการต่าง ๆ ที่ agent ใช้เพื่อตีความข้อความของ HTTP
1.18 ทดสอบ Cross site scripting : เป็นการโจมตีในระดับแอพพิลเคชั่นที่พบได้บ่อยครั้ง Cross Site Scripting ใช้ตัวย่อ XSS เพื่อหลีกเลี่ยงความสับสนกับคำว่า Cascading Style Sheets (CSS) การทดสอบ XSS มักเป็นผลให้มีการแสดงหน้าต่าง JavaScript alert แสดงให้ผู้ใช้เห็น หน้าต่าง alert อาจเป็นสัญญาณที่บ่งชี้ได้ว่าผู้โจมตีสามารถรันโค้ดที่ต้องการได้ อ่านเพิ่มเติมได้ที่ http://www.sran.net/archives/200 และ http://www.sran.net/archives/201
1.19 ทดสอบค่า HTTP Methods and XST : ในขั้นตอนนี้เราจะตรวจสอบว่า web server ไม่ได้กำหนดค่าให้ยอมรับคำสั่ง (method) HTTP ที่มีอันตรายและการโจมตี Cross Site Tracing (XST) ไม่สามารถทำได้
1.20 ทดสอบ SQL Injection : เพื่อทดสอบการโจมตี SQL Injection ประกอบด้วยการป้อนคำสั่ง SQL ผ่านทางข้อมูลอินพุทจากไคลเอ็นท์ไปยังแอพพลิเคชั่น การโจมตี SQL injection ที่สำเร็จสามารถอ่านข้อมูลที่เป็นความลับจากฐานข้อมูล แก้ไขข้อมูลในฐานข้อมูล เอ็กซิคิวท์คำสั่งของผู้ดูแลระบบ หรือในบางกรณีสามารถใช้คำสั่งภายในระบบได้
1.21 ทดสอบ SSI Injection : เพื่อทดสอบ web server หลายตัวที่มีฟีเจอร์ที่ช่วยให้สามารถเพิ่มโค้ดแบบไดนามิคเข้าไปในหน้า html แบบ static ฟีเจอร์นี้เรียกว่า Server-Side Includes (SSI) เป็น extension ที่อาจทำให้ผู้โจมตีสามารถใส่โค้ดเข้าไปในหน้า html หรือเอ็กซิคิวท์โค้ดจากระยะไกลได้
1.22 ทดสอบ IMAP/SMTP Injection : เพื่อตรวจสอบภัยคุกคามนี้มีผลกระทบกับแอพพลิเคชั่นที่สื่อสารกับ mail server (IMAP/SMTP) ส่วนใหญ่แล้วจะเป็น webmail เพื่อทดสอบความเป็นไปได้ในการป้อนคำสั่ง IMAP/SMTP เข้าไปใน mail server เนื่องจากไม่มีการตรวจสอบข้อมูลที่ป้อนเข้าไปอย่างเพียงพอ
1.23 ทดสอบ Code Injection : เพื่อทดสอบว่าสามารถใส่โค้ดเข้าไปในหน้าเวบและทำให้ web server เอ็กซิคิวท์โค้ดดังกล่าวได้หรือไม่
1.24 ทดสอบ Command Injection : เป็นการทดสอบการป้อนคำสั่งของระบบปฏิบัติการผ่านทาง HTTP request ไปยังแอพพลิเคชั่น
1.25 ทดสอบช่องโหว่ Web Application ผ่านช่องทางระบบ Search engine ซึ่งเราสามารถค้นหาลักษณะตัวแปรของการเขียน code web application และหาช่องโหว่ได้ ผมได้เขียนไว้ที่ http://nontawattalk.blogspot.com/2004/12/personal-information-is-not-secured.html
2. ผู้ให้บริการ DNS Server ที่เป็นบริการสาธารณะ (อ่านมุมมองในการเก็บ Log http://nontawattalk.blogspot.com/2009/04/blog-post.html เพื่อสืบหาผู้กระทำความผิด)
ช่องโหว่ที่มีกับ DNS Server ที่เป็นลักษณะ Fast flux ซึ่งเป็นเทคนิคทาง DNS ที่ใช้โดย botnet เพื่อซ่อนไซต์ที่ทำหน้าที่ให้บริการ phishing และมัลแวร์ ที่อยู่เบื้องหลังเครือข่ายของโฮสต์ที่ถูกบุกรุก
ทำตัวเป็น proxy ที่มีการเปลี่ยนแปลงตลอดเวลา ยังหมายถึงเครือข่ายแบบ peer-to-peer รวมกันหลายเครือข่าย ใช้เทคนิคต่าง ๆ ได้แก่ การใช้คำสั่งและการควบคุมแบบกระจาย (distributed) การใช้ load-balancing และการเปลี่ยนเส้นทาง proxy เพื่อทำให้การเครือข่ายมัลแวร์ยากต่อการถูกตรวจพบและการป้องกัน Storm Worm เป็นหนึ่งในมัลแวร์ที่ใช้เทคนิคเหล่านี้ผู้ใช้อินเทอร์เน็ตอาจพบการใช้ fast flux ในการโจมตี phishing ที่มีเชื่อมโยงกับกลุ่มอาชญากร รวมถึงการโจมตี MySpace , facebook อีกด้วย
ลักษณะการโจมตี DNS แบบ Single-flux และ double-flux
fast flux แบบง่าย ๆ เรียกว่า "single-flux" มีโหนดหลาย ๆ โหนดภายในเครือข่ายที่ลงทะเบียนและเลิกลงทะเบียนที่อยู่ของพวกมันโดยใช้ DNS A record สำหรับชื่อ DNS เดียว ใช้ round robin DNS ที่มีค่า TTL (time to live) สั้นมาก ๆ เพื่อสร้างรายชื่อของที่อยู่เป้าหมายที่มีการเปลี่ยนแปลงตลอดเวลาสำหรับชื่อ DNS เดียว รายชื่อนี้อาจยาวเป็นหลายร้อยหรือหลายพันบรรทัด fast flux ที่มีความซับซ้อนมากกว่านี้เรียกว่า "double-flux" มีหลายโหนดภายในเครือข่ายที่ลงทะเบียนและเลิกลงทะเบียนที่อยู่ของพวกมัน
โดยใช้ DNS SOA (start of authority) record ซึ่งจะช่วยเพิ่มเสถียรภาพและความอยู่รอดภายในเครือข่ายมัลแวร์นี้ได้
การทดสอบ DNS Server
ให้มีการตรวจสอบการ query Zone Tranfer ซึ่งเป็นผลทำให้ทราบข้อมูลในส่วนเครื่องแม่ข่าย (Server) ทั้งหมดในองค์กรได้
Zone transfer เป็นวิธีการที่ secondary DNS server ใช้สำหรับอัพเดทข้อมูลจาก primary DNS server, DNS server ของโดเมนหนึ่งจะทำงานใช้วิธีการที่เรียกว่า master-slave ซึ่งตัวที่เป็น slave จะอัพเดทข้อมูล DNS จากตัวที่เป็น master ผู้ดูแลระบบควรกำหนด DNS server ให้ยอมให้มีการทำ zone transfer จาก secondary (slave) DNS server เท่านั้น
3. Mail Server ที่เป็นการให้บริการสาธารณะ Mail Server มักจะมีการใช้ DNS และ Web Application มาเกี่ยวข้องดังนั้นภัยคุกคามที่เกิดกับ Mail Server นั้นต้องพิจารณา DNS และเรื่องของ Web Application มาเกี่ยวข้องด้วยเสมอ เนื่องจาก Mail ในยุคปัจจุบันก็สามารถทำงานผ่าน Web Application มากขึ้น
ภัยคุกคามจาก Mail Server ที่ควรตรวจสอบก็ควรพิจารณาผู้อื่นมาใช้ Mail Server เราเพื่อทำเป็น Spam Server ได้จากการตรวจสอบขั้นต้นคือดูที่ Mail server เปิด Open relay ที่จะอนุญาตให้บุคคลภายในใช้ mail server เพื่อส่งอีเมลไปยังที่อื่นได้หรือไม่ จากคำสั่ง
เนื่องจากรายละเอียดในแต่ละ Application Protocol มีอยู่มาก ดังนั้นการที่เราจะทำให้ระบบนี้ปลอดภัยทั้งหมดจำเป็นต้องอาศัยผู้เชี่ยวชาญมาทำการประเมินความเสี่ยง (Vulnerability Assessment) และหาวิธีการปิดกั้นภัยคุกคาม (Hardening) ที่อาจเข้าถึงระบบของเราได้ รวมถึงการออกแบบระบบเครือข่าย (Network Re-design) เพื่อรองรับปริมาณข้อมูลและความปลอดภัย จึงทำให้ปัญหาต่างๆบนระบบไอซีทีขององค์กรเราเหลือน้อยลงและมีสร้างประสิทธิภาพการทำงานให้สูงขึ้นได้ จงจำไว้ว่าความมั่นคงปลอดภัยทางไอทีจะเกิดขึ้นได้ต้องมี 3 ประสานเดินไปพร้อมกัน ไม่ว่าเป็น คน กระบวน และเทคโนโลยี มีกระบวนการนโยบายมาควบคุมคน มีคนมาควบคุมการใช้เทคโนโลยี และมีเทคโนโลยีเพื่อตอบสนองความสะดวกสบายและความปลอดภัยในองค์กรเป็นชั้นๆไป หากขาดสิ่งใดสิ่งหนึ่งย่อมทำให้เกิดช่องโหว่ตามมาไม่ทางใดก็ทางหนึ่ง
ส่วนอีกมุมคือ มุมของผู้ใช้บริการ ส่วนใหญ่ปัญหาต่างๆเกิดจากผู้ใช้บริการ (User) นั่นแหละ ผู้ใช้บริการมี 2 ลักษณะคือ ผู้ใช้บริการที่มีเจตนาในการโจมตีระบบ และ ผู้ใช้บริการที่ไม่มีเจตนา
ผู้ใช้บริการที่เจตนาในการโจมตีระบบ (Hacker) ส่วนใหญ่แก้ไขโดยต้องสร้างจรรยธรรมในการใช้คอมพิวเตอร์ และให้คิดถึงใจเขาใจเรา หรือใช้กฏหมายมาควบคุมคนเหล่านี้
ผู้ใช้บริการที่ไม่มีเจตนาในการโจมตีระบบ มักเป็น zombie ผีดิบ หากมี zombie หลายๆตัวรวมเป็นกองทัพ botnet เนื่องจากเครื่องคอมพิวเตอร์เหล่านั้นติด Malware จากพฤติกรรมการใช้งานไอซีที ก็จะสร้างความเสียหายให้กับเครือข่ายองค์กรมาก มักจะพบสถิติมีจำนวนมากขึ้นเรื่อย เนื่องจากการขาดความตระหนักในการใช้ข้อมูล และทำให้เครื่องผู้ใช้งานเป็นฐานทัพของ Hacker เพื่อใช้เครื่องคอมพิวเตอร์ในการโจมตีระบบต่อไป ไม่รู้จักจบสิ้น วิธีป้องกันเพื่อไม่ให้ผู้ใช้งาน (User) เป็น botnet ต้องอาศัยการจัดอบรมความมั่นคงปลอดภัยในการใช้ข้อมูลสารสนเทศขึ้นอย่างต่อเนื่องเพื่ออัพเดทเทคนิคใหม่ๆ ภัยคุกคามใหม่ๆ และควบคุมพฤติกรรมการใช้งานของผู้ใช้ (User) ให้ได้จากเทคโนโลยี ซึ่งจะทำให้ความเสี่ยงน้อยลง ถึงแม้ปัญหาพวกนี้เป็นปัญหาโลกแตกจนไม่สามารถทำให้ทุกเครื่องคอมพิวเตอร์บนโลกใบนี้ปลอดภัยได้หมดได้ แต่ก็เป็นหน้าที่ของทุกคนที่ทำให้เครื่องปลอดภัย เพราะความมั่นคงปลอดภัยต้องเริ่มจากตัวเองก่อนเสมอ ...
นนทวรรธนะ สาระมาน
Nontawattana Saraman
22/09/52
ทางบริษัท Global Technology Integrated มีผู้เชี่ยวชาญที่ให้คำปรึกษาและจัดการออกแบบระบบเครือข่ายให้มีความปลอดภัย ในบริการที่ชื่อว่า One Security Services และบริการอื่นๆ สามารถอ่านได้ที่
http://www.gbtech.co.th/th/servicesบทความเกี่ยวข้อง
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 1
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 2
สมัครสมาชิก:
บทความ (Atom)
