วิเคราะห์ประเด็น True แบบงู ๆ ปลา ๆ

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

* ประเด็น DNS spoofing (DNS cache poisoning) *
=== ทำความเข้าใจ DNS ===
ถ้าพูดถึง DNS ที่ผู้ใช้เข้าใจ ว่าต้องชี้ไปที่ไอพี โน่นนั่นนี่ แล้วแต่จะเลือกตามสะดวก เพื่อให้สามารถเข้าใช้งานอินเทอร์เน็ตได้ นั่นเป็นครึ่งทางของ DNS ซึ่งเรียกอย่างเป็นทางการว่า Caching DNS แต่ละเจ้า ISP ก็จะต้องมีไว้อย่างน้อย 1 ระบบ (1 เครื่อง, 1 rack, หรือ 1 ชั้น ก็แล้วแต่ scale) ส่วนอีกครึ่งทางคือ Authoritative DNS หรือ DNS ที่มีการเก็บข้อมูลว่าปลายทางที่เราจะไป ด้วยชื่อ blablabla.com อยู่แห่งหนตำบลใด

เนื่องจาก DNS ทำงานกันแบบกิ่งก้านใบ (Hierachy) ดังนั้น DNS query ที่เราร้องขอไป อาจจะผ่านไปหลายชั้นของ DNS server ได้
เช่น กรณีที่ข้อมูลปลายทางยังไม่ถูก cache และ query ไปยัง www.kku.ac.th

dns query => caching dns => root dns => top level domain (.th) => kku dns [reply 202.12.97.4]

หลังจากนั้น caching dns จะจำค่า www.kku.ac.th [202.12.97.4] ไว้ แล้วแต่กำหนดระยะเวลา ก่อนจะร้องขอใหม่อีกครั้ง เมื่อ cache หมดอายุ

dns query => caching dns [reply 202.12.97.4]

จากเส้นทางในกรณีไม่มี cache จะเห็นว่า การร้องขอ ผ่านเส้นทางที่เชื่อถือได้ เนื่องจากปัจจุบัน ระบบ DNS มีการเปิดใช้งาน DNSSec (http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) เพื่อป้องกันการส่งข้อมูลแปลกปลอมเข้ามาในสารบบ จะมีประเด็นบ้างก็ตรง leaf domain ซึ่งอาจจะยังไม่ได้เปิดใช้งาน DNSSec ซึ่งส่วนนี้ ก็ยังเป็นช่องให้เกิดการโจมตี DNS ได้อยู่

=== ตามรอย DNS ===
การตามรอย DNS ว่าไปไหนมาไหน ก็เป็นเรื่องที่ทำได้ปกติอยู่แล้ว ซึ่งก็มีประเด็นกันว่า tool ไหนใช้ได้ ไม่ได้ ตอนนี้อย่าหลงประเด็นนะครับ ว่า เรากำลังกล่าวหา DNS server อย่างอื่นอย่าพึ่งดึงเข้ามายุ่ง

+ จะใช้ traceroute ก็ไม่ผิด เพราะสุดสายปลายทาง มันจะแสดง ip ที่เราวิ่งไปหา โดนปลอมหรือไม่ปลอมก็เช็คได้ครับ

+ แต่ traceroute ไม่ได้บอกว่า DNS ตัวไหนที่เป็นคนตอบเรามา ถ้าคิดว่า DNS นั่นแหละคือ ผู้ต้องสงสัย ก็ต้องลอง trace dns ดู

$ dig +trace www.kku.ac.th

หรือจะใช้ dnstracer แสดงผลดูง่ายกว่า

$ sudo apt-get install dnstracer
$ dnstracer -4 -s [dns server] www.kku.ac.th
Tracing to www.kku.ac.th[a] via [dns server], maximum of 3 retries
127.0.0.1 (127.0.0.1) Got answer 
 |\___ kknt.kku.ac.th [kku.ac.th] (202.12.97.21) Got authoritative answer 
 |\___ kku1.kku.ac.th [kku.ac.th] (2001:03c8:c108:0000:0000:0000:0000:0001) Not queried
 |\___ kku1.kku.ac.th [kku.ac.th] (202.12.97.1) Got authoritative answer 
  \___ ns2.kku.ac.th [kku.ac.th] (202.28.117.198) * ^C

หรือไล่ย้อนกลับจาก top level domain

$ dnstracer -4 -s . www.kku.ac.th
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ th.cctld.authdns.ripe.net [th] (2001:067c:00e0:0000:0000:0000:0000:0116) Not queried
 |\___ th.cctld.authdns.ripe.net [th] (193.0.9.116) 
 |     |\___ kku1.kku.ac.th [kku.ac.th] (2001:03c8:c108:0000:0000:0000:0000:0002) Not queried
 |     |\___ kku1.kku.ac.th [kku.ac.th] (202.12.97.1) Got authoritative answer 
 |     |\___ ns.thnic.net [kku.ac.th] (202.28.0.1) 
 |     |\___ ns2.kku.ac.th [kku.ac.th] (202.12.97.44) * ^C

+ สุดท้ายถ้าเป็น DNS spoofing จริง ... เปลี่ยน Caching DNS ที่ไม่ได้อยู่ในกิ่งที่มีปัญหา อาการต้องหาย นอกจากที่ gateway จะมีการบังคับ ทุก DNS query เข้า Caching DNS ตัวเดิม (DNS interception)

=== สรุป ===
ประเด็น DNS spoofing ถ้าจะเช็คต้องทำตอนที่เกิดอาการ เพราะหากเวลาผ่านไป cache ก็คงหมดอายุ หรือหาก spoofing ถูกทำที่ต้นสาย หลังจากต้นสายที่เกิด spoofing มีการแก้ไขแล้ว ค่าก็จะกลับมาปกติ เหมือนไม่มีอะไรเกิดขึ้น ส่วนมันจะเป็นสาเหตุหลัก หรือไม่ใช่สาเหตุเลย ผมก็ไม่สามารถสรุปได้

ยังมีอีกประเด็นหนึ่ง ที่ไม่พูดถึงไม่ได้ คือ Transparent Proxy/Cache ซึ่งกรณีนี้ ก็เกี่ยวกับ cache poisoning ได้เหมือนกัน เอาไว้ต่ออีกบทวิเคราะห์หนึ่งละกันครับ