การทำ 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

SRAN ใส่ใจความเป็นส่วนตัว

ดูคลิปเองเลยครับไม่มีคำบรรยาย

หลังจากนำอุปกรณ์ SRAN Light ติดตั้งที่เครือข่ายคอมพิวเตอร์ในบริษัทแล้ว เราจะสามารถทำการกำหนดค่าความเป็นส่วนตัวของพนักงานได้ SRAN Light ใส่ใจข้อมูลความเป็นส่วนตัวของคุณ
รายละเอียดเพิ่มเติมดูได้ที่ http://sran.org/q

นนทวรรธนะ สาระมาน
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

นนทวรรธนะ สาระมาน
Nontawattana Saraman

ปฏิวัติระบบระบุตัวตนทางเครือข่ายคอมพิวเตอร์ SRAN Light ตอนที่ 1


ผมได้ดูพิธีวันชาติของประเทศจีนเมื่อวานนี้จากทางข่าวในทีวี บอกว่าอาวุธ,ถัง และเทคโนโลยีการทหารและด้านความมั่นคงของชาติ เป็นเทคโนโลยีที่จีนเป็นเจ้าของทั้งสิ้น ซึ่งในความเป็นเราๆก็รู้ๆกันอยู่ว่าจีนเก่งในเรื่อง C&D (Copy and Development) แต่นั้นไม่ใช่ปัญหา เนื่องจากผลลัพธ์ที่เราๆท่านๆเห็นอยู่ตรงหน้านั้นคือความยิ่งใหญ่ จนทุกวันเราคงยอมรับกันอย่างแพร่หลายแล้วว่าประเทศจีนคือประเทศมหาอำนาจชาติหนึ่งและเรียกได้ว่าอาจเป็นอันดับหนึ่งของโลกไปแล้วในไม่ช้านี้

ความเหมือนกันของวันชาติสิงคโปร์กับจีนนั้นเหมือนกันคือแสดงให้เห็นถึงความรักต่อประเทศของตน และแสดงศักยภาพให้ต่างประเทศที่ได้รับรู้ข่าวสารอย่างเราได้แต่ชื่นชม
ที่ผมกล่าวเช่นนี้นั้นหมายความได้ว่า ประเทศไทยหากจะต้องการเป็นมหาอำนาจอย่างเขา เราต้องเริ่มที่จะทำเทคโนโลยีเราเองบ้าง ผมคิดว่าประเทศไทยเป็นประเทศที่อุดมสมบูรณ์กว่า 2 ประเทศที่กล่าวมาอยู่มาก โดยเฉพาะภัยทางธรรมชาตินั้นเราน้อยกว่าเห็นๆ ยิ่งมีพายุเข้าในช่วงนี้รู้สึกรักประเทศไทยมากขึ้น คิดดูสิ พายุก่อตัวที่ฟิลิปปิน กว่าจะเคลื่อนเข้าประเทศไทย ต้องผ่านเวียดนาม ลาว กว่าถึงไทย พายุก็อ่อนกำลังลง ทะเลของเราก็สวยแถมยังเสี่ยงภัยน้อยกว่าที่อื่นๆ มองจากแผนที่โลกลงมาเนื้อที่โดดเด่นที่สุดก็คิดว่าเป็นประเทศไทยนี้แหละ อยู่ตรงกลางพอดีเลย
ที่กล่าวมาทั้งหมดไม่ได้เกี่ยวกับหัวข้อเลยแค่อยากให้คนไทยเริ่มต้นที่สร้างชาติกันอย่างหยั่งยืน ซึ่งอีกทางหนึ่งบนความรู้และความถนัดของผมและทีมงานแล้วเราก็คงได้เป็นเพียงส่วนหนึ่ง
และตอนนี้เราได้พัฒนาเทคโนโลยีตัวหนึ่งที่อยากนำเสนอ จริงๆเขียนไว้แล้วที่ http://www.sran.net/

Presentation ในงานเปิดตัว SRAN Light

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

นนทวรรธนะ สาระมาน
Nontawattana Saraman

การตรวจจับหมายเลขบัตรเครดิตในเครือข่าย

SRAN IP Securityตามมาตรฐาน Payment Card Industry Data Security Standard (https://www.pcisecuritystandards.org/) ได้กำหนดห้ามไม่ให้มีการรับส่งหมายเลขบัตรเครดิตในรูปแบบที่ไม่ได้เข้ารหัส และไม่ได้อำพรางไว้ โดยปกติแล้วระบบเฝ้าดูเครือข่ายเช่น IDS หรือ IPS เป็นสเมือนระบบบังคับเพื่อให้มั่นใจได้ว่าข้อมูลดังกล่าวจะไม่ถูกส่งผ่าน เครือข่าย แต่จากการตรวจสอบอย่างละเอียดแสดงให้เห็นว่าปฏิบัติตามข้อบังคับอย่างถูก ต้องนั้นทำได้ไม่ง่าย ข้อเขียนนี้จะแสดงถึงแง่มุมต่าง ๆ ในการใช้ระบบเฝ้าดูเครือข่ายเพื่อตรวจจับการรั่วไหลของหมายเลขบัตรเครดิต และเพื่อสร้าง Signature ในการตรวจจับความผิดปกติของข้อมูลบนระบบเครือข่าย ดังต่อไปนี้คือ

* การจับคู่ลำดับหมายเลขบัตรเครดิต
* การจัดการกับผลบวกลวง (false positive) โดยการใช้ข้อยกเว้น (exceptions)
* ข้อควรพิจารณาอื่น ๆ รวมทั้งการหลบหลีกการตรวจจับ บันทึกเหตุการณ์ (logging) และรูปแบบอื่น ๆ ที่ล่อแหลม

“RegexTree:”

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

ภัยคุกคามตาม 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

http://farm4.static.flickr.com/3310/3344883753_ffd3c742e2_m.jpg
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

หนังสือพิมพ์ Telecom Journal โกลบอลเทคโนโลยี อินทิเกรเทด ผู้พัฒนาระบบเฝ้าระวังภัยคุกคามวันที่ 21-27 กันยายน 2552

โกลบอลเทคโนโลยี อินทิเกรเทด ผู็พัฒนาระบบเฝ้าระวังภัยคุกคาม เครือข่ายสารสนเทศภายใต้แบนด์ “SRAN” เปิดตัวอุปกรณ์ใหม่ล่าสุด “SRAN Light” ระบบเฝ้าระวังเครือข่ายสารสนเทศในองค์กรเพิ่มประสิทธิภาพการระบุตัวตนผู้ใช้งานระบบไอทีในองค์กรและบันทึกการใช้งานได้อย่างครบถ้วย โดยรักษาสิทธิส่วนบุคคลตามนโบายขององค์กรได้อย่างลงตัว

นรัตน์ สาระมาน กรรมการผู้จัดการ บริษัทโกลบอลเทคโนโลยี อินทิเกรเทด จำกัด กล่าวว่า จากการสำรวจความต้องการของลูกค้า ประกอบการกับแนวโน้มที่เพิ่มสูงขึ้นของภัยคุกคามและการทุจริตภายในองค์กร บริษัทฯจึงได้พัฒนาผลิตภัณฑ์เพื่อต่อยอด SRAN Security Center จนเกิดเป็น “SRAN Light” ขึ้น โดยยังคงคุณสมบัติด้านการเก็บล็อกไฟล์อยา่งถูกต้องตาม พ.ร.บ.ว่าด้วยการกระทำด้วยความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550 ผสมผสานกับเทคโนโลยีใหม่คือ Human Behavioral Warning (HBW) ที่เชื่อมโยงการเฝ้าระวังภัยคุกคามภายในเครือข่ายองค์กร เข้ากัยงานบริหารทรัพยากรบุคคลและระบบจัดเก็บคลังข้อมูล (Inventory)

SRAN Light สามารถแสดงผลแบบ real time ทั้งในส่วนของการใช้งานเครือข่ายปกติที่องค์กรต้องการเฝ้าระวัง และการใช้งานที่เข้่าข่ายเป็นภัยคุกคามทำให้สามารถป้องกันได้อย่างทันที ทั้งนี้ระบบบริหารจัดการของอุปกรณ์ได้ได้รับการออกแบบไม่ให้ละเอียดสิทธิส่วนบุคคลของคนในองค์กร โดยแต่ละองค์สามารถกำหนดกฎเกณฑ์ หรือโปรโตคอลที่จะตรวจสอบให้สอดคล้องกับนโยบายองค์กร นอกจากนี้ ยังสามารถรายงานสิถิตการใช้งานเครือข่ายสารสนเทศเป็นรายบุคคล รายเเผนก หรือในภาพรวมทั้งองค์กรได้อีกด้วย

อุปกรณ์ดังกล่าวจะช่วยให้ทราบพฤติกรรมการใช้งานระบบไอทีภายในองค์กร ตรวจจับการใช้งานที่ไม่เหมาะสม รวมถึงการทุจริตภายในองค์กร และทำให้สามารถวางแผนการลงทุนพัฒนาระบบไอทีได้อย่างมีประสิทธิภาพมากขึ้น

ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 2

ที่กล่าวไปแล้วในตอนที่แล้วเราพูดถึงภัยคุกคามที่เกิดขึ้นตาม OSI 7 layer ผมทำการเรียงลำดับมาตั้งแต่ Layer 1 – Layer 3 ไปแล้ว ต่อจากนี้เราจะมาทำความเข้าใจภัยคุกคามตาม Layer ที่เหลืออีก

Layer 4 : Transport มี Protocol ที่ใช้ใน Layer นี้คือ TCP และ UDP การเชื่อมต่อสื่อสารเป็นชนิด End-to-end connection
TCP คือต้องการความถูกต้องของการรับส่งข้อมูล ยืนยันจากการติดต่อแบบ 3 way handshake
SYN , ACK , FIN รายละเอียดเพิ่มเติมอ่านได้ที่
Transmission Control Protocol
ประเภท Application Protocol ที่มีการเชื่อมต่อที่ใช้ TCP ได้แก่ Web (HTTP, HTTPS) , การ Remote ทางไกล เช่น Telnet (23) , SSH (22)
Mail เช่น SMTP (25) , POP3 (110) เป็นต้น
Port ทั้งหมดของ TCP มี 65,535 port services
UDP คือการติดต่อที่อาศัยความเร็วในการรับส่งข้อมูลไม่เน้นความถูกต้องของข้อมูล
ประเภท Application protocol ที่ใช้ UDP ได้แก่ syslog (514) , SNMP (161) , IRC (6667-7000)
เป็นต้น Port ทั้งหมดของ UDP มี 65,535 port services
ดังนั้นวิธีการโจมตีผ่าน Layer 4 โดยอาศัย Protocol TCP และ UDP นั้นจึงมีหลากหลายหนทางในการปฏิบัติ

ทางเป็นชนิด TCP ก็อาศัยการติดต่อสื่อสารระหว่างเครื่องให้ขาดความสมบูรณ์ในการเชื่อมต่อ เช่น ส่งค่า SYN อย่างเดียวแทนที่จะครบ SYN –> SYN ACK —> ACK –> FIN เพื่อให้ครบ ESTABLISHED

ภาพการติดต่อที่สมบูรณ์ จาก command line บนเครื่องผู้เขียน netstat -an ลองทำตามได้ครับ

ถ้าติดต่อไม่สมบูรณ์ จากการโจมตีที่เรียกว่า SYN Flood เป็นรูปแบบหนึ่งของการทำ DoS (Denial of Services)

ภาพจาก (tula.bofh.ru/articles/539)

การทำ DDoS/DoS ชนิด SYN flood สามารถมองได้ 2 มุม ได้แก่

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

ในมุมภายในนี้ สามารถ Radom port ในการส่งค่า SYN Flood ได้สะดวกเนื่องจากมีทางเลือกให้ถึง 65,535 port ทีเดียว ดังนั้นจึงเป็นที่ทำให้ผู้ดูแลระบบต้องมีเครื่องมือในการเฝ้าระวังในจุดนี้ด้วย และหากเครื่องคอมพิวเตอร์ (client) มีการใช้ Host Base Firewall , Host Base IPS ก็สามารถป้องกันได้ระดับหนึ่ง ที่บอกว่าได้ระดับหนึ่งเนื่องจาก ซอฟต์แวร์ป้องกันในระดับ Host base ต้องอาศัยการ CPU และ RAM รวมถึงการต่อต้านการโจมตีของระบบปฏิบัติการ (OS) ซึ่งมีรายละเอียดพอสมควรหากให้อธิบายเป็นระดับ Kernel และการปรับแต่งค่า system ภายใน OS อยู่หากเครื่องคอมพิวเตอร์ที่มีคุณสมบัติทางกายภาพไม่เหมาะสมหรือเป็นรุ่นเก่าการประมวลผลช้าถึงแม้จะมีระบบป้องกันที่ดี หากมีการโจมตีจำนวนมากและเป็นชนิด DDoS (Distributed Denial of Service) เข้าร่วมแล้วล่ะก็มีโอกาส CPU สูงและทำให้เครื่องอืดพร้อมใช้งานไม่ได้ตามมา

ส่วนมุมภายนอก คือ ยิงค่า SYN Flood จากเครื่องผู้ไม่หวังดีไปที่เครื่องเป้าหมายที่ห่างไกลออกนอกระบบเครือข่าย ในกรณีต้องมีการทำการ scan port เครื่องปลายทางเสียก่อนถึงจะร่วงรู้ว่ามีการเปิดค่า port services ที่เป็น TCP หรือไม่ ส่วนใหญ่มักจะยิงค่า SYN Flood ผ่าน Application Protocol ที่ทราบว่ามีการใช้งานอยู่เช่น HTTP Protocol (80) ซึ่งเป็นการติดต่อแบบ TCP เช่นกัน ซึ่งเป็นส่วนใหญ่ที่นักโจมตีไม่อยากเสียเวลาในการ scan port ทั้งหมด (65,535 TCP และ 65,535 UDP) เนื่องจากในมุมภายนอกมักมีการกำหนดช่องทางการเข้าถึงจำกัด แต่ที่รู้กันคือต้องเปิด port 80 เป็นอย่างแน่นอน

การยิงในมุมภายนอก นั้นสามารถป้องกันได้โดยใช้อุปกรณ์ Network Firewall ที่เป็นชนิด State ful inspection หรือ Network IPS ก็จะสามารถป้องกันได้

แล้ว UDP ล่ะจะเกิด SYN Flood ได้หรือไม่ ? คำตอบคือไม่ได้ เพราะ UDP ไม่มีการเชื่อมต่อแบบ TCP

ภาพนี้เป็นโครงสร้างของการติดต่อแบบ TCP

แล้วจะมีการโจมตี UDP Flood หรือไม่ ? มีและเป็นที่นิยมในยุคหลังๆมากขึ้น โดยเฉพาะไวรัสคอมพิวเตอร์ชนิด worm ที่มักโจมตีด้วยการอาศัย Protocol TCP และ UDP

หากในระบบเครือข่ายภายในองค์กร มีการระบบเฝ้าระวังภัย และพบว่ามีการติดต่อค่า UDP มากกว่า TCP แล้วนั้นต้องตั้งข้อสงสัยไว้ก่อนว่าอาจจะมีเหตุการณ์ไม่พึ่งเกิดขึ้นได้

ส่วนผู้ดูแลระบบ Core Router ที่จำเป็นต้องเปิดค่า UDP จาก SNMP เพื่อใช้ในการ Monitor ความเสรียฐภาพของอุปกรณ์ ก็ต้องระวังให้มากเนื่องจาก SNMP อาจถูกโจมตีจากผู้ไม่หวังดีได้ ดังนั้นควรตั้งค่า community string สำหรับ SNMP เพื่อไม่ให้นักโจมตีระบบ scan port จากภายนอกและทำการส่งค่า UDP Flood มาสู่อุปกรณ์ Router , Switch เราได้จากโลกภายนอก ซึ่งทั้งนี้ Router / Switch นั้นต้องมี IP Address ที่เป็น IP จริง ถึงจะมีการโจมตีผ่านได้ โดยปกติแล้ว Core Router ก็ต้องมี Interface ที่แสดงค่า IP จริงได้อยู่แล้วหากมีผู้ไม่หวังดีทราบถึง IP ของ Router และทำการ scan port ขึ้นก็อาจทำให้เกิดการโจมตีได้ ขึ้นกับการป้องกันของผู้ดูแลระบบว่ามีความตระหนักในเรื่องนี้มากน้อยแค่ไหน

ส่วนค่า Syslog ล่ะจะทำการส่งค่าออกไปข้างนอกผ่าน Internet ได้หรือไม่ ? คำตอบว่าได้ แต่ควรผ่านอุปกรณ์เฉพาะที่ใช้ในการส่งค่า syslog เช่น SIEM (Security Information Event Management) หรืออุปกรณ์อื่นๆ ที่ใช้ในการส่งโดยเฉพาะ ไม่ควรส่งผ่านอุปกรณ์ Router หรือ Switch โดยตรงเพราะอาจถูก scan port จากทางไกลและอาศัย port services ที่ส่งในเป็นเครื่องมือในการโจมตี DDoS/DoS ได้

ดังนั้นการส่งค่า syslog ที่เป็น UDP ออกสู่ข้างนอกจึงควรมีระบบการส่งให้มีความปลอดภัย และไม่มีผลกระทบกับ Bandwidth ในองค์กรนัก ทั้งนี้ต้องเกิดจากการออกแบบจากผู้เชี่ยวชาญด้านนี้โดยตรง

มาถึงตรงนี้ ก็จะพบว่าภัยคุกคามที่เกิดจาก Transport Layer นั้นมักอาศัยช่องทาง TCP , UDP โดยส่วนใหญ่จะเป็นการโจมตีแบบ DDoS/DoS เชื่อมกับ Application protocol ที่เราๆท่านๆ ได้เปิดใช้ขึ้นเองทั้งมุมภายในและมุมภายนอกนั้นแหละ หากเป็นมุมภายนอกเราปิด Port services ที่ไม่จำเป็นต้องใช้ได้ก็จะปลอดภัยขึ้น ปิดจากอะไรก็ปิดจาก Network Firewall ที่เราควรจะมีไว้ทุกองค์กรนั้นเอง

ส่วนมุมภายใน วิธีที่ง่ายที่สุดคือลงโปรแกรมที่จำเป็นเท่านั้นบนเครื่องคอมพิวเตอร์ หากลงโปรแกรมมาก ก็ทำให้มีการเปิด port services มากเป็นเงาตามตัว ทำให้เพื่อนร่วมงานหรือ Hacker ในองค์กร ที่ร้อนวิชาอาจโจมตีท่านได้เช่นกัน โชคไม่ดีอาจเป็นแหล่งเพาะเชื้อที่ทำให้ไวรัสคอมพิวเตอร์เข้าถึงเครื่องคอมพิวเตอร์ได้ง่ายขึ้นอีก ใครที่ลงโปรแกรมเกมส์ โปรแกรมโหลดหนังผ่าน P2P ก็ควรใตร่ตรองในเรื่องนี้ให้มากขึ้น

ในตอนหน้าผมขอรวบ Layer 5,6 และ 7 เป็นเรื่องเดียวกัน ซึ่งถือได้ว่า Layer หลังนี้เป็นจุดเสี่ยงภัยที่มีการเข้าถึงระบบได้ง่ายและเป็นที่นิยมจากเทคนิคการโจมตีต่างๆในยุคปัจจุบันเป็นอย่างมาก

Nontawattana Saraman

SRAN Development Team ตอนนี้ขอทำการโปรโมทเทคโนโลยีใหม่ที่ทางทีมวิจัยพัฒนา SRAN ได้พัฒนาขึ้นเพื่อช่วยในการเฝ้าระวังภัยคุกคามที่เกิดขึ้นภายในองค์กร ชื่อ SRAN Light รายละเอียด http://sran.org/q ซึ่งเทคโนโลยีตัวนี้ช่วยให้เรารู้ทันภัยคุกคามได้ชนิดที่ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญ

นนทวรรธนะ สาระมาน
Nontawattana Saraman
09/09/09

เนื้อหาบทความที่เกี่ยวข้อง ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 1
รายละเอียด Port Number และความหมาย

ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 1


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

(ภาพ OSI 7 layer Model จาก wikipedia)

ภัยคุกคามที่เกิดจากการสื่อสาร เป็นการรับ-ส่งข้อมูล จากต้นทางไปปลายทางที่ถูกเรียกใช้บริการ หลักการสื่อสารที่เกิดขึ้นบนโลกอินเตอร์เน็ตก็เช่นเดียวกัน เกิดจากการรับ-ส่งข้อมูลผ่าน โมเดลที่เรียกว่า OSI 7 layer (Open Systems Interconnection) นั้นเมื่อเราพิจารณาแต่ละ Layer และวิเคราะห์ถึงภัยคุกคามนั้นเราสามารถแบ่งได้ 8 ส่วนดังนี้

จากภาพจะเห็นว่าได้มีเพิ่มอีก Layer คือ People คนเป็นส่วนสำคัญที่ทำให้เกิดช่องโหว่และความเสี่ยงที่ทำให้เกิดภัยคุกคามจากการใช้งานระบบไอทีได้ และยากแก่การควบคุมและป้องกันเป็นอย่างมาก

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

บางส่วนการบรรยายในงานเปิดตัวบริการ Cyfence จาก CAT Telecom ตุลาคม 2549

จึงเป็นเหตุที่ต้องพิจารณาภัยคุกคามตาม Layer ทั้ง 7 นี้ขึ้น

1. Physical Layer ภัยคุกคามที่เกิดขึ้นมักจะเกิดจากการโจมตีในระดับฮาร์ดแวร์ การเข้าถึงทางกายภาพ ซึ่งมักเกิดจากการออกแบบและไม่พิถีพิถันต่อภัยคุกคามที่เกิดขึ้น

วิธีป้องกันในส่วนนี้ทำได้โดยการออกแบบให้รัดกุมขึ้น มีการระบุตัวตนในการเข้าถึงข้อมูล สถานที่ที่มีความสำคัญและการควบคุมเส้นทางการใช้งานข้อมูลให้ไม่กระจายในจุดที่ควบคุมไม่ได้

2. Data Link Layer ภัยคุกคามที่เกิดขึ้นใน Layer นี้มักจะเป็นการดักข้อมูล หรือ ที่เรียกว่า “การสนิฟ” การดักข้อมูลนั้นมี 2 ส่วน คือ

:: ส่วนที่ 1 การดักข้อมูลที่เรียกว่า Promiscuous หรือการเงี่ยหูฟัง ข้อมูลที่เกิดขึ้นรอบๆตัวผู้ดักฟัง จะเกิดขึ้นในระดับ Ethernet หรือวง LAN

Promiscuous Mode จะทำให้การ์ดแลนในเครื่องที่ดักฟังมีการเปลี่ยนแปลงการรับข้อมูล หรือทางเทคนิคเรียกว่า Finger print ของ การ์ดแลนที่เปิด Promiscuous mode นั้นเปลี่ยนไป สิ่งที่ได้จาการเปิด mode นี้ทำให้เครื่องคอมพิวเตอร์สามารถดักฟังข้อมูลที่เกิดขึ้นรอบๆตัวเครื่องคอมพิวเตอร์ได้ ซึ่งไม่ได้หมายความว่าจะดักข้อมูลได้ทั้งระบบเครือข่าย ขึ้นอยู่กับตำแหน่งการติดตั้ง Promiscuous mode ไปอยู่ในตำแหน่งใด หากเป็น เครื่องคอมพิวเตอร์ภายในองค์กรเครื่องใดเครื่องหนึ่ง ก็จะดักฟังข้อมูลได้ไม่หมด เป็นเพียงการสื่อสารรอบๆข้างที่เกิดขึ้นจากการ์ดแลนที่ดักฟังเท่านั้น และจะเกิดขึ้นได้บนเครือข่ายคอมพิวเตอร์เดียวกัน

วิธีการป้องกัน การสื่อสารในวง LAN หากจำเป็นต้องมีการ Remote Access หรือมีการ Login ระบบ ควรมีการเข้ารหัส (Encryption) Protocol ที่เลือกใช้ เช่น

Remote Access ถ้าใช้ Telnet ให้เปลี่ยนเป็น SSH , ถ้าใช้ HTTP ในการ Login ให้เปลี่ยนเป็น HTTPS ในการ Login แทน ถ้าใช้ POP3 ในการับ Mail ก็ให้ใช้ Secure – POP3 ในการรับ Mail แทนเป็นต้น

เนื่องจาก Protocol ที่สำคัญในชีวิตประจำวัน ที่เราต้องใช้ เช่น Web , Mail และการ Remote ต่างๆจำเป็นต้องคำนึงถึงข้อมูลที่ส่งผ่านนั้นได้เริ่มมีการเข้ารหัสเพื่อป้องกันการดักฟังข้อมูลภายในเครือข่ายเดียวกันหรือไม่

ดังนั้น Promiscuous mode ที่เกิดจากเจตนาที่ต้องการดักฟังนั้น สามารถป้องกันได้ไม่ยาก แต่ที่ยากกว่านั้นเราจะรู้ได้อย่างไรว่ามีเครื่องคอมพิวเตอร์ในเครือข่ายของเราดักฟังอยู่

วิธีตรวจสอบ คือ ควรมีระบบที่เรียกว่า NIDS (Network Intrusion Detection System) เพื่อวิเคราะห์หาFinger print เครื่องคอมพิวเตอร์ที่ทำการดักฟังข้อมูลหรือมีการเปลี่ยนแปลงการ์ดแลนในเครื่องให้เป็น Promiscuous mode ขึ้น

:: ส่วนที่ 2 การดักฟังข้อมูลแบบ MITM (Man In The Middle attack) การข้อมูลชนิดนี้จะไม่สามารถป้องกันได้จากการเข้ารหัสข้อมูลเมื่อมีการ Remote Access บนระบบเครือข่าย เนื่องจากผู้ที่ต้องการดักฟังโดยใช้เทคนิค MIM Attack จะทำตัวเป็นตัวกลางในการเรียกใช้ข้อมูล โดยเฉพาะ ซึ่งทำให้ผู้ที่ถูกดักฟังข้อมูลเข้าใจผิดนึกและทำการส่งข้อมูลไปให้เครื่องที่ดักฟัง

ลักษณะการทำ MIM เริ่มจากการส่งค่า ARPspoof เพื่อปลอมค่า MAC Address ให้ตรงกับ Gateway และส่ง ARP Poisoning ไปที่เครื่องที่ต้องการดักฟัง

วิธีการป้องกัน คือต้องมีระบบตรวจบันทึกการเปลี่ยนแปลงค่า MAC Address ที่เครื่อง Gateway หากมีการเรียกค่า MAC Address ซ้ำกับเครื่อง Gateway ก็มีความเป็นไปได้สูงที่มีเครื่องภายในระบบเครือข่ายที่ทำการดักฟังข้อมูล ควรมีระบบ NIDS (Network Intrusion Detection System) ที่คอยวิเคราะห์พฤติกรรมที่ไม่เหมาะสม เช่นมีการเรียกค่า ARPspoof บนระบบเครือข่าย

ภาพจาก SRAN Light ที่สามารถตรวจหาเครื่องที่มีพฤติกรรมดักฟังข้อมูลได้ รายละเอียดของภาพดูได้ที่

http://twitpic.com/dczv7

โดยพื้นฐาน NIDS จะทำการตรวจจับได้ก็ต่อเมื่อติดตั้งในตำแหน่งที่เหมาะสม จากภาพจะเห็นว่าการทำ ARPspoof จะเกิดขึ้นใน Layer 2 จึงทำให้การตรวจจับไม่สามารถระบุถึง IP Address ได้ หากระบบเครือข่ายมี NIDS แล้วจำเป็นต้องทำเพิ่มเติมคือมีการจัดทำระบบ Inventory หรือ คลังข้อมูลเครื่องคอมพิวเตอร์สำหรับเครือข่ายภายในอีกด้วย ไม่เช่นนั้นก็จะไม่สามารถตรวจหาเครื่องที่ดักจับข้อมูลผ่านเทคนิค MIM attack ได้

3. Network Layer ภัยคุกคามที่เกิดขึ้นใน Layer นี้ส่วนใหญ่จะเป็นการโจมตีระบบที่เรียกว่าการทำ DDoS/DoS (Denial of Service) การโจมตีเครื่องเป้าหมายโดยใช้เทคนิค DDoS/DoS นั้นจะทำได้ผ่าน Protocol ที่เรียกว่า ICMP ซึ่งสามารถทำได้หลายเทคนิคเช่น Ping of Death , Smurf attack

หากโจมตีลำพังเพียงเครื่องเดียวไปที่เครื่องเป้าหมาย เรียกว่า DoS (Denial of Service)

หากโจมตีหลายเครื่องไปที่เครื่องเป้าหมาย เรียกว่า DDoS (Distributed Denial of Service)

วิธีการป้องกัน

เพิ่มค่าที่ Router กำหนดค่า Router(config-if)# no ip directed-broadcast

กำหนดให้ Network Firewall ปิดกั้นการรับค่า ICMP

ถึงอย่างไรการโจมตีชนิด DDoS/DoS ใน Layer 3 หรือ Network Layer เป็นเทคนิคที่ใช้ไม่ได้ผลแล้วในปัจจุบันแต่ก็ยังมีหลายองค์กรที่ยังถูกการโจมตีชนิดนี้อยู่ เนื่องจากการกลายพันธ์ของเทคนิคการโจมตีนี้ไปผนวกกับการแพร่ระบาดของไวรัสคอมพิวเตอร์ (worm) ในหลากหลายชนิดและสายพันธุ์ ทำให้เครือข่ายคอมพิวเตอร์ฝั่งภายนอกองค์กรจึงเต็มไปด้วยข้อมูลขยะที่วิ่งวนเวียนพร้อมที่สร้างความลำคาญใจต่อระบบไม่น้อย

ส่วนใหญ่การพูดถึง DDoS/DoS มักมองในมุมเครือข่ายภายนอกองค์กร และเหตุการณ์มักจะเกิดขึ้นช่วงรอยต่อของจุดเชื่อมเครือข่ายภายในและภายนอกที่มีการติดต่อโลกอินเตอร์เน็ต แต่เมื่อมีการแพร่ระบาดไวรัสคอมพิวเตอร์ (Worm) บางสายพันธ์แล้วการโจมตีดังกล่าวอาจเกิดขึ้นภายในองค์กรก็ได้ เช่น worm ที่ชื่อว่า Nachi ที่เคยทำให้ระบบเครือข่ายในองค์กรใหญ่ในประเทศไทยถึงใช้งานไม่ได้ก็เคยเกิดขึ้นมาแล้ว ดังนั้นเทคโนโลยีที่ใช้ในเครือข่ายคอมพิวเตอร์ในองค์กรควรพิจารณาทั้งสองมุมจะเป็นการดี

อีกทั้งภัยคุกคามที่เกิดขึ้นใน Network Layer (L3) นั้นก็ยังมีการปลอมแปลงค่า IP Address หรือที่เรียกตามศัพท์เทคนิคว่า IP Spoofing ซึ่งเทคนิคนี้จะมีผลกระทบและสร้างความเสียหายได้เมื่อ IP Address ดังกล่าวเกิดขึ้นบนระบบเครือข่ายภายในองค์กรเอง แต่ก็ยังเป็นผลกระทบที่ไม่รุนแรงและสามารถแก้ไขได้หากมีการออกแบบระบบเครือข่ายที่ดี ก็จะป้องกันปัญหาดังกล่าวได้

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

นนทวรรธนะ สาระมาน
Nontawattana Saraman

มารู้จักกับ Payment Card Industry Data Security Standard

มาตรฐาน Payment Card Industry Data Security Standard เป็นมาตรฐานความปลอดภัยสารสนเทศที่แพร่หลายทั่วโลก รวบรวมโดยคณะกรรมการ Payment Card Industry Security Standards Council (PCI SSC) มาตรฐานนี้สร้างขึ้นมาเพื่อช่วยให้องค์กรต่าง ๆ ที่ดำเนินการชำระเงินผ่านบัตร ให้สามารถป้องกันการฉ้อโกงบัตรเครดิตด้วยการควบคุมข้อมูลและช่องโหว่ต่าง ๆ ที่เพิ่มขึ้น ได้มีการนำมาตรฐานดังกล่าวมาใช้กับทุกองค์กรที่เก็บรักษา ดำเนินการ หรือส่งต่อข้อมูลข่าวสารเกี่ยวกับผู้ถือบัตรจากบัตรใด ๆ ก็ตามที่ประทับยี่ห้อของเครื่องหมายการค้าของบัตรเครดิตเจ้าใดเจ้าหนึ่ง

มาตรฐานนี้ดูแลรักษาโดยคณะกรรมการ Payment Card Industry Security Standards Council ซึ่งดูแลทั้งมาตรฐาน PCI DSS และมาตรฐานอื่น ๆ อาทิเช่น Payment Card Industry PIN Entry Device security requirements (PCI PED) และ Payment Application Data Security Standard (PA-DSS)

การตรวจสอบการปฏิบัติตามมาตรฐานอาจทำได้จากทั้งจากภายในหรือภายนอก ขึ้นอยู่กับปริมาณของการทำธุรกรรมของบัตรที่องค์กรนั้นจัดการ ถึงแม้ว่าองค์กรจะมีขนาดใหญ่เพียงใดก็ตาม การประเมินการปฏิบัติตามมาตรฐานจะต้องทำเป็นรายปี องค์กรที่จัดการกับการทำธุรกรรมที่มีปริมาณมากจะต้องมีการประเมินการทำตาม มาตรฐานโดยผู้ประเมินอิสระที่เรียกว่า Qualified Security Assessor (QSA) ส่วนบริษัทที่จัดการกับการทำธุรกรรมที่มีจำนวนน้อยกว่าสามารถเลือกที่จะ ทำการประเมินได้ด้วยตัวเองที่เรียกว่า Self-Assessment Questionnaire (SAQ)

ข้อกำหนด

มาตรฐานนี้ในเวอร์ชั่นปัจจุบัน (1.2) ระบุถึงข้อกำหนด 12 ข้อในการปฏิบัติตามมาตรฐาน แบ่งเป็นหกกลุ่มที่เกี่ยวข้องกัน เรียกว่า “control objectives”

Control Objectives ข้อกำหนด PCI DSS
สร้างและดูแลรักษาเครือข่ายที่ปลอดภัย 1. ติดตั้งและดูแลรักษาค่าที่ตั้งไว้ของไฟร์วอลล์เพื่อป้องกันข้อมูลของผู้ถือบัตร
2. ไม่ใช้ค่าที่ตั้งมาพร้อมกับผลิตภัณฑ์สำหรับรหัสผ่านและการรักษาความปลอดภัยอื่น ๆ ของระบบ
การป้องกันข้อมูลผู้ถือบัตร 3. ป้องกันข้อมูลผู้ถือบัตรที่เก็บรักษาอยู่
4. เข้ารหัสธุรกรรมที่ส่งผ่านเครือข่ายสาธารณะแบบเปิด
ดูแลรักษาโปรแกรมที่จัดการกับช่องโหว่ 5. ใช้และอัพเดทซอฟท์แวร์แอนตี้ไวรัสในทุกระบบที่มักจะได้รับผลกระทบจากมัลแวร์
6. พัฒนาและดูแลรักษาระบบและแอพพลิเคชั่นต่าง ๆ ให้ปลอดภัย
ใช้มาตรการควบคุมการเข้าถึงที่เข้มแข็ง 7. จำกัดการเข้าถึงข้อมูลผู้ถือบัตร สำหรับผู้ที่ได้รับอนุญาตให้สามารถเข้าถึงได้เท่านั้น
8. กำหนดหมายเลขประจำตัวเฉพาะสำหรับผู้ที่สามารถเข้าถึงคอมพิวเตอร์ได้
9. จำกัดการเข้าถึงข้อมูลผู้ถือบัตรทางกายภาพ
เฝ้าดูและทดสอบเครือข่ายต่าง ๆ อย่างสม่ำเสมอ 10. ติดตามและเฝ้าดูการเข้าถึงทรัพยากรทางเครือข่ายและข้อมูลผู้ถือบัตร
11. ทดสอบระบบและขั้นตอนต่าง ๆ ในการรักษาความปลอดภัยอย่างสม่ำเสมอ
ดูแลรักษานโยบายความปลอดภัยสารสนเทศ 12. ดูแลรักษานโยบายที่กล่าวถึงความปลอดภัยสารสนเทศ

มาตรฐาน PCI DSS ที่มีใน SRAN Data Safehouse

ระบบของ Data Safehouse ในส่วนของการประเมินการปฏิบัติตามมาตรฐานของ PCI DSS จะเน้นที่การตรวจสอบปัญหาต่าง ๆ ที่พบใน web server เป็นหลัก

หน้ารายงานในส่วนของ PCI DSS สามารถเปิดดูได้จากเมนู Status > Security scan เมื่อเข้ามาที่หน้า Security scan แล้วให้คลิกที่ลิงค์ PCI DSS Compliance check

จากนั้นจึงเลือกเปิดดูรายงานตามวันที่ที่ต้องการโดยคลิกที่ลิงค์ view report

จะปรากฏหน้าที่บอกรายละเอียดการประเมินผล พร้อมทั้งผลที่บอกว่า web server ของคุณผ่านมาตรฐาน PCI DSS หรือไม่ ซึ่งคุณสามารถอ่านรายละเอียดได้จากรายงานที่บอกถึงรายละเอียดที่อยู่ข้าง ล่าง

ตัวอย่างรายงานที่บอกรายละเอียดว่าเหตุใด server ที่ตรวจสอบถึงไม่ผ่านตามมาตรฐาน PCI DSS