บริการ Google Public DNS ประกาศเพิ่มมาตรการป้องกัน DNS Cache Poisoning ที่คนร้ายสร้าง DNS Reply โดยปลอมไอพีเป็น authoritive server มาตอบไอพีแทนเซิร์ฟเวอร์จริง หากสามารถยิง reply เข้าไปถึงกูเกิลก่อนที่ข้อความจากเซิร์ฟเวอร์จริงไปถึง ก็จะกลายเป็นว่าผู้ใช้จำนวนมากถูกส่งไปยังเซิร์ฟเวอร์ปลอมเป็นระยะเวลาหนึ่ง
ที่จริง IETF พยายามแก้ปัญหานี้แล้ว ด้วยมาตรฐาน DNS Cookies ( RFC 7883 ) ที่เพิ่มค่า cookie ให้เซิร์ฟเวอร์ตอบค่าเดียวกันเท่านั้น ทำให้คนร้ายไม่สามารถเดาค่านี้ได้ แต่ในโลกความเป็นจริงเซิร์ฟเวอร์จำนวนมากไม่ได้รองรับฟีเจอร์นี้ โดยรวมมีคิวรีที่ได้รับการปกป้องจากกระบวนการนี้แค่ 10%
เมื่อปี 2022 กูเกิลจึงทดลองมาตรการที่มีการเสนอกันมาตั้งแต่ปี 2008 คือการสุ่มตัวเล็กใหญ่ในชื่อโดเมน ซึ่งโดยทั่วไปแล้วเซิร์ฟเวอร์ authoritive จะตอบกลับชื่อเดิมที่คิวรีเข้า ในกรณีที่คนร้ายพยายามปลอม DNS reply ก็จะไม่สามารถเดาได้ว่ากูเกิลสุ่มตัวเล็กใหญ่ไว้รูปแบบใด เนื่องจากเซิร์ฟเวอร์ส่วนใหญ่มีพฤติกรรมตรงกันทำให้ป้องกันได้เป็นวงกว้าง และตอนนี้กูเกิลก็เปิดฟีเจอร์นี้เป็นค่าเริ่มต้น ทำให้การคิวรีมากกว่า 90% ได้รับมาตรการปกป้องเพิ่มเติม ลดความเสี่ยงถูกโจมตี cache poisoning ลงแล้ว
มาตรการนี้เซิร์ฟเวอร์ authoritive ไม่ต้องทำอะไรเพิ่ม แต่กูเกิลก็แนะนำให้พยายามเปิดใช้ฟีเจอร์ความปลอดภัยใหม่ๆ
ที่มา - Google Security Blog
ภาพกระบวนการคิวรี DNS จาก Cloudflare
ยังงงๆ
hisoft Mon, 08/04/2024 - 03:04
ยังงงๆ อยู่ว่าช่วยป้องกันได้ยังไง 🥲
ปกติ bad actors จะใช้วิธีการ
McKay Mon, 08/04/2024 - 07:56
In reply to ยังงงๆ by hisoft
ปกติ bad actors จะใช้วิธีการ flood dns reply โดยใช้ queryid ที่คาดเดาไว้จาก queryid ตัวก่อนๆที่ prime และ sniff ไว้ครับ
ซึ่งหมายความว่า flood dns reply มักจะเป็น domain record ค่าเดียวเสมอ เพื่อพยายามให้ recursive nameserver ได้รับค่าและนำค่านั้นไปใช้ก่อนค่าที่มาจาก authoritative nameserver ของจริง
ดังนั้นถ้า recursive nameserver ร้องขอ BlOgNoNe.CoM
recursive nameserver ask BlOgNoNe.CoM with queryid 1011 >> bad actor authoritative nameserver flood reply blognone.com with queryid 1011 = mismatch
recursive nameserver ask BlOgNoNe.CoM with queryid 1011 >> authoritative nameserver reply BlOgNoNe.CoM with queryid 1011 = match ครับ
โอ้ ขอบคุณครับ
hisoft Mon, 08/04/2024 - 10:36
In reply to ปกติ bad actors จะใช้วิธีการ by McKay
โอ้ ขอบคุณครับ อธิบายได้เห็นภาพเลย
ไม่เข้าใจเช่นกัน
deaknaew Mon, 08/04/2024 - 05:13
ไม่เข้าใจเช่นกัน
เข้าใจว่าถ้าปลอม dns resolver
tg-thaigamer Mon, 08/04/2024 - 07:22
เข้าใจว่าถ้าปลอม dns resolver ถ้าสุ่มพิมพ์เล็กพิมพ์ใหญ่ มันต้อง return ที่ถูกต้องกลับมาตามที่สุ่ม
แต่เข้าใจว่าถ้า MIM จะปลอมกลับด้วยพิมพ์เล็กใหญ่ domain ที่เจนมาไม่ถูก ทำให้มาเช็คได้ว่าใครทำ server ปลอมอยู่ เข้าใจถูกไหมนะ
งงๆ
Hoo Mon, 08/04/2024 - 09:05
งงๆ
ถ้าคนร้ายแก้ให้ relay ปลอม ตอบตัวใหญ่เล็ก ตามที่ถูก query ถามมา
ก็หลอกได้แล้วรึเปล่า???
Blognone.com นี่ 11 ตัวอักษร
lew Mon, 08/04/2024 - 10:27
In reply to งงๆ by Hoo
Blognone.com นี่ 11 ตัวอักษร ไม่รวมจุด ความเป็นไปได้ 2^11 ประมาณ 2048 แบบ ถ้าชื่อโดเมนยิ่งยาวรูปแบบยิ่งมาก
เมื่อนำไปร่วมกับมาตรการอื่นๆ ก่อนหน้านี้ เช่น randomized port ที่คนร้ายต้องเดาว่า Google เลือกคิวรีโดเมนใดจากพอร์ตต้นทางพอร์ตไหนอีกประมาณ 30,000 รูปแบบ จะได้ความเป็นไปได้ประมาณ 60 ล้านรูปแบบในกรณขีของ Blognone มัน "เยอะพอ"ที่คนร้ายจะไม่สามารถเดาจนครบ ภายใต้ช่วงเวลาที่ Goolge ยิงคิวรีอออกมาจริงๆ และรอผลลัพธ์อยู่
ผมเข้าใจว่าทำไม่ได้ครับ
mix5003 Mon, 08/04/2024 - 13:24
In reply to งงๆ by Hoo
ผมเข้าใจว่าทำไม่ได้ครับ (ถ้าเข้าใจผิดขออภัย)เพราะมันไม่ได้ยิงไปถามคนร้าย คนร้ายเลยไม่รู้ว่าคนถาม ถามด้วยตัวใหญ่เล็กรูปแบบใด
ที่ผ่านมาคนร้ายน่าจะใช้วิธียิงคำตอบ ไปหาคนถามโดยไม่สนว่าคนถามถามว่าอะไรครับ
เช่นคนถามอาจจะถามว่า www.blognone.com ip อะไร แต่คนร้ายยิงไปว่า www.google.com ip นี้นะ
แล้วก็รอฟลุค ว่าเมื่อไหรคนถาม จะถามว่า www.google.com ip อะไร
อ๋อ ขอบคุณครับ
Hoo Tue, 09/04/2024 - 07:32
In reply to ผมเข้าใจว่าทำไม่ได้ครับ by mix5003
อ๋อ ขอบคุณครับ ค่อยเข้าใจหน่อย
เห็นคำว่า relay เลยนึกว่า เครื่องคนร้ายจะทำได้ระดับ man in middle ซึ่ง ตัวใหญ่-เล็ก มันไม่น่าจะช่วยอะไร เพราะดักคำถามได้
แต่แบบนี้ก็น่าจะไม่ช่วยกับพวก
itpcc Mon, 08/04/2024 - 12:54
แต่แบบนี้ก็น่าจะไม่ช่วยกับพวก Unicode-based domain ล่ะมั้ง
ถึงอย่างนั้นก็น่าจะช่วยกับเว็บส่วนใหญ่พอได้อยู่
แสดงว่าถ้า Client ไม่ได้ใช้
big50000 Mon, 08/04/2024 - 13:56
แสดงว่าถ้า Client ไม่ได้ใช้ Case-sensitive Authoritive ก็อาจจะป้องกันไม่ได้
เวลา compare มันต้อง case
rattananen Mon, 08/04/2024 - 15:57
In reply to แสดงว่าถ้า Client ไม่ได้ใช้ by big50000
เวลา compare มันต้อง case sensitive ตาม spec น่ะครับhttps://datatracker.ietf.org/doc/html/rfc1034#section-3.1 ย่อหน้าที่ 5
++
big50000 Tue, 09/04/2024 - 05:12
In reply to เวลา compare มันต้อง case by rattananen
++
อย่างน้อยเบราว์เซอร์ก็หายห่วง