Saturday, September 26

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

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


Tuesday, September 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


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

Thursday, September 17

ภัยคุกคามตาม 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 และความหมาย

Monday, September 7

โกลบอลเทคฯ เตรียมเปิดตัว "SRAN Light"


โกลบอลเทคฯ เตรียมเปิดตัว "SRAN Light" ปฏิวัติระบบเฝ้าระวังภัยคุกคามทางเครือข่ายแบบเดิมอย่างสิ้นเชิง ด้วยการระบุตัวตนการใช้งานไอซีทีในองค์กรวิเคราะห์พฤติกรรมการใช้งานในเชิงลึกโดยตรวจสอบลักษณะการใช้งานไอทีพร้อมประเมินค่าพฤติกรรมว่ามีความเสี่ยงสอดคล้องกับนโยบายขององค์กรที่ต้องการความคล่องตัวที่ไม่ต้องการลงทุนหลายระบบเพื่อได้มาซึ่งผลลัพธ์ที่ต้องการ


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






ที่มานวัฒกรรมนี้เกิดจากทีมพัฒนา SRAN ได้เก็บเกี่ยวประสบการณ์ในงานด้าน IT Security ค้นคว้าวิจัยเพิ่มเติม และสำรวจความต้องการของลูกค้า ผนวกกับแนวโน้มที่เพิ่มสูงขึ้นของภัยคุกคามภายในองค์กร (Insider Threat) ทีมงานจึงได้พัฒนาผลิตภัณฑ์เพื่อต่อยอดจาก SRAN Security Center จนเกิดเป็น "SRAN Light" ขึ้น ซึ่ง SRAN Light นี้ ยังคงคุณสมบัติด้านการเก็บ Log File ตาม พ.ร.บ.คอมพ์ ผนวกเทคโนโลยีใหม่ "HBW" หรือ Human Behavioral Warning เพื่อเชื่อมโยงการเฝ้าระวังภัยคุกคามภายในเครือข่ายองค์กร เข้ากับงานบริหารทรัพยากรบุคคล พร้อมระบบจัดเก็บคลังข้อมูล (Inventory)

เทคโนโลยี HBW ซึ่งเป็นหัวใจของ SRAN Light นี้ ได้นำเทคนิค Intrusion Detection System ในระดับ Network Base มาผนวกเข้ากับการจัดเก็บคลังข้อมูล (Inventory) ให้สามารถตรวจจับรายชื่อพนักงาน ชื่อแผนกของหน่วยงาน ค่า MAC Address นำมาเชื่อมโยงกับ IP Address (ทั้งแบบ Dynamic และ Static IP) ได้ เพื่อประโยชน์ในการเฝ้าระวังพฤติกรรมการใช้งานไอซีทีภายในองค์กร ระบบถูกออกแบบไม่ให้มีการละเมิดสิทธิส่วนบุคคลของพนักงานในองค์กร
เทคโนโลยีทั้งหมดรวมอยู่ในเครื่องเดียว ไม่ต้องติดตั้งอุปกรณ์เพิ่มเติม เพิ่มความสะดวกในการใช้งาน และเป็นประโยชน์สำหรับองค์กรในการเฝ้าระวังภัยคุกคามภายใน "Insider Threat” ที่มีสถิติเพิ่มสูงขึ้นทุกๆปี และการสืบค้นหาประวัติเหตุการณ์เพื่อหาผู้กระทำความผิดได้สะดวกมากขึ้น อีกทั้งยังสามารถเชื่อมกับงานบริหารทรัพยากรบุคคล (HR) ทำให้ทราบพฤติกรรมการใช้งาน IT ภายในองค์กร ว่ามีพฤติกรรมการใช้งานอันไม่เหมาะสมในเวลางานหรือไม่ หรือมีการลักลอบขโมยข้อมูลภายในองค์กรส่งไปยังที่อื่นนอกเวลางานหรือไม่ ช่วยให้รู้เท่าทันปัญหาการฉ้อโกง (Fraud) จากคนภายในองค์กรได้ พร้อมหลักฐานประกอบรูปคดี ทั้งยังสามารถเก็บสถิติการใช้งานรายแผนก รายบุคคล ช่วยให้การพยากรณ์การลงทุนระบบไอซีทีในองค์กรมีประสิทธิภาพมากขึ้น


ลักษณะการตรวจวิเคราะห์ Application Protocol ที่ SRAN Light สามารถเก็บบันทึกได้ แบ่ง 2 ส่วนคือ

ข้อมูลที่เกิดจากการใช้งานปกติ (Normal Traffic) ได้แก่

Web : HTTP, HTTPS


Email : SMTP, POP3, IMAP, Web Mail, Lotus Note, POP3S, SMTPS, IMAPS ซึ่งจะดูเฉพาะ Subject e-mail ในการรับส่ง


Messenger : ICQ, MSN, IRC, AIM, Yahoo, ebuddy, Camfrog ใน Mode Chat สามารถควบคุมได้ว่าจะให้แสดงข้อความการสนทนาได้ ซึ่งเป็นการป้องกันเรื่องความเป็นส่วนตัวพนักงาน


File Transfer : FTP, TFTP ,Files Sharing (Netbios)


P2P : napster, GNUtella, DirectConnect, Bittorrent, eDonkey, MANOLITO, Ares, ed2k, kaaza, soulseek และ VoIP ชนิด P2P เช่น Skype เป็นต้น


Others : Telnet, Remote Desktop, VNC, Radius


ข้อมูลที่เกิดจากการใช้งานที่ไม่ปกติ (Threat Traffic) ได้แก่

- ลักษณะการแพร่กระจายสิ่งผิดปกติ เช่น Virus/worm , Backdoor , Trojan , Malware , Botnet


- ลักษณะการโจมตีในชนิดต่างๆ เช่น DDoS/DoS , Brute force password , buffer overflow


- ลักษณะความผิดปกติจากการรับ-ส่งข้อมูล เช่น Spam การรับ-ส่งข้อมูลขยะ , Phishing การรับ-ส่งข้อมูลที่หลอกลวง, การที่อุปกรณ์เครือข่ายที่ปล่อยสัญญาณผิดปกติ จาก Protocol ICMP , SNMP เป็นต้น


- ลักษณะการปลอมแปลงข้อมูล เช่น การ Spoof ค่า MAC โดยใช้เทคนิค ARP-spoof , Spoof ค่า DNS เป็นต้น