ช่องโหว่ด้านความปลอดภัยประเภทใดที่ให้ DNSSEC เปิดเผย

ฉันวางแผนที่จะลงนามโซน DNS ของฉันกับ DNSSEC โซนของฉันผู้รับจดทะเบียนและเซิร์ฟเวอร์ DNS ของฉัน (BIND9) สนับสนุน DNSSEC ทั้งหมด ผู้เดียวที่ไม่สนับสนุน DNSSEC คือผู้ให้บริการ nameserver สำรองของฉัน (คือbuddyns.com )

บนเว็บไซต์ของพวกเขาพวกเขาระบุเรื่องนี้เกี่ยวกับ DNSSEC:

BuddyNS ไม่รองรับ DNSSEC เพราะจะทำให้เกิดช่องโหว่บางอย่างที่ไม่เหมาะสมกับบริการ DNS ระดับสูง

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

ช่องโหว่เหล่านั้นคืออะไร?

DNSSEC มีความเสี่ยง แต่ไม่เกี่ยวข้องโดยตรงกับการสะท้อนหรือการขยาย การขยายขนาดข้อความ EDNS0 เป็นปลาเฮอริ่งแดงในกรณีนี้ ให้ฉันอธิบาย

การแลกเปลี่ยนแพ็คเก็ตใด ๆ ที่ไม่ได้ขึ้นอยู่กับการพิสูจน์ตัวตนก่อนหน้านี้จะถูกโจมตีโดยผู้โจมตี DDoS ที่สามารถใช้การแลกเปลี่ยนแพ็คเก็ตที่ไม่ได้รับการรับรองเป็นตัวสะท้อนและอาจเป็นเครื่องขยายเสียง ตัวอย่างเช่น ICMP (โปรโตคอลหลัง "ping") สามารถถูกใช้งานในลักษณะนี้ เช่นเดียวกับแพ็คเก็ต TCP SYN ซึ่งสามารถรับแพ็คเก็ต SYN-ACK ได้มากถึง 40 ชุดแม้ว่า SYN จะถูกปลอมแปลงมาจากเหยื่อบางรายที่ไม่ต้องการแพ็คเก็ต SYN-ACK เหล่านั้น และแน่นอนว่าบริการ UDP ทั้งหมดมีความเสี่ยงต่อการโจมตีนี้รวมถึง NTP, SSDP, uPNP และตามที่ระบุไว้โดยการตอบสนองอื่น ๆ ที่นี่รวมถึง DNS

การตรวจจับการบุกรุกส่วนใหญ่การป้องกันการบุกรุกและเครื่องใช้โหลดบาลานเซอร์เป็นปัญหาคอขวดไม่สามารถติดตามปริมาณการใช้ "อัตราสาย" ได้ นอกจากนี้เราเตอร์จำนวนมากไม่สามารถทำงานที่อัตราสายและสวิตช์บางตัว คอขวดเหล่านี้โดยเป็นสิ่งที่เล็กที่สุด "ในเส้นทาง" และเล็กกว่าลิงก์ตัวเองเป็นเป้าหมายที่แท้จริงของการโจมตีแบบ DDoS บนพื้นฐานของความแออัด หากคุณสามารถทำให้ไฟร์วอลล์ของใครบางคนไม่ว่างอยู่กับทราฟฟิกของการโจมตีทราฟฟิกที่ดีจะไม่ผ่านแม้ว่าการเชื่อมโยงจะไม่เต็มก็ตาม และสิ่งที่ทำให้ไฟร์วอลล์ช้าลงนั้นไม่ใช่จำนวนบิตทั้งหมดต่อวินาที (ซึ่งสามารถเพิ่มได้โดยใช้ข้อความที่มีขนาดใหญ่ขึ้นและ EDNS0 และ DNSSEC จะทำ) แต่จะเป็นจำนวนแพ็กเก็ตทั้งหมดต่อวินาที

มีตำนานเมืองจำนวนมากเกี่ยวกับวิธีที่ DNSSEC ทำให้ DDoS แย่ลงเนื่องจากขนาดข้อความที่ใหญ่กว่าของ DNSSEC และในขณะที่สิ่งนี้เข้าใจได้ง่ายและ "ฟังดูดี" มันเป็นเรื่องเท็จ แต่ถ้ามีความจริงต่อตำนานนี้คำตอบที่แท้จริงจะยังคงอยู่ที่อื่น - [เพราะ DNSSEC ใช้ EDNS0 เสมอ แต่ EDNS0 สามารถใช้โดยไม่มี DNSSEC] และการตอบกลับที่ไม่ใช่ DNSSEC ทั่วไปนั้นมีขนาดใหญ่เท่ากับ DNSSEC การตอบสนองจะเป็น พิจารณาระเบียน TXT ที่ใช้เพื่อแสดงนโยบาย SPF หรือคีย์ DKIM หรือเพียงแค่ชุดที่อยู่หรือระเบียน MX ขนาดใหญ่ ในระยะสั้นการโจมตีไม่ต้องใช้ DNSSEC และการมุ่งเน้นไปที่ DNSSEC เพราะความเสี่ยง DDoS นั้นเป็นพลังงานที่ผิดพลาด

DNSSEC มีความเสี่ยง! มันใช้งานยากและใช้งานได้ยากขึ้น บ่อยครั้งที่มันต้องการกระบวนการทำงานใหม่สำหรับการเปลี่ยนแปลงข้อมูลโซนการจัดการนายทะเบียนการติดตั้งอินสแตนซ์ของเซิร์ฟเวอร์ใหม่ ทั้งหมดนี้จะต้องมีการทดสอบและจัดทำเอกสารและเมื่อใดก็ตามที่มีบางสิ่งบางอย่างที่เกี่ยวข้องกับ DNS จะต้องมีการตรวจสอบเทคโนโลยี DNSSEC เพื่อหาสาเหตุที่เป็นไปได้ และผลลัพธ์สุดท้ายถ้าคุณทำทุกอย่างถูกต้องนั่นคือในฐานะผู้ลงนามในโซนเนื้อหาและระบบออนไลน์ของคุณจะเปราะบางต่อลูกค้าของคุณ ในฐานะผู้ให้บริการเซิร์ฟเวอร์ระดับสุดยอดผลลัพธ์จะเป็นที่ว่าเนื้อหาและระบบของคนอื่นจะมีความเปราะบางสำหรับคุณมากขึ้น ความเสี่ยงเหล่านี้มักเห็นว่ามีประโยชน์มากกว่าประโยชน์เนื่องจากข้อดีเพียงอย่างเดียวคือการปกป้องข้อมูล DNS จากการดัดแปลงหรือทดแทนในเที่ยวบิน การโจมตีนั้นหายากมากจนไม่คุ้มค่ากับความพยายามทั้งหมดนี้ เราทุกคนหวังว่า DNSSEC จะแพร่หลายไปทุกวันเพราะแอปพลิเคชันใหม่ที่จะเปิดใช้งาน แต่ความจริงก็คือวันนี้ DNSSEC มีค่าใช้จ่ายไม่มีประโยชน์และมีความเสี่ยงสูง

ดังนั้นหากคุณไม่ต้องการใช้ DNSSEC นั่นเป็นสิทธิพิเศษของคุณ แต่อย่าให้ใครสับสนกับคุณว่าปัญหาของ DNSSEC คือบทบาทของแอมพลิฟายเออร์ DDoS DNSSEC ไม่มีบทบาทที่จำเป็นในฐานะแอมพลิฟายเออร์ DDoS มีวิธีอื่นที่ถูกกว่าในการใช้ DNS เป็นแอมพลิฟายเออร์ DDoS หากคุณไม่ต้องการใช้ DNSSEC ให้เป็นเพราะคุณยังไม่เมา Kool Aid และคุณต้องการเป็นผู้เสนอญัตติสุดท้าย (ในภายหลัง) ไม่ใช่ผู้เสนอญัตติแรก (ตอนนี้)

เซิร์ฟเวอร์เนื้อหา DNS บางครั้งเรียกว่า "เซิร์ฟเวอร์ผู้ให้บริการ" จะต้องป้องกันไม่ให้ถูกละเมิดเนื่องจาก DNS สะท้อนแอมพลิฟายเออร์เนื่องจาก DNS ใช้ UDP และเนื่องจาก UDP นั้นถูกใช้งานโดยแพ็คเก็ตที่มาปลอมแปลง วิธีการรักษาความปลอดภัยเซิร์ฟเวอร์เนื้อหา DNS ของคุณจากการละเมิดประเภทนี้ไม่ได้เป็นการปิดกั้น UDP หรือบังคับใช้ TCP (โดยใช้เคล็ดลับ TC = 1) หรือเพื่อบล็อกแบบสอบถามใด ๆ หรือเลือกที่จะไม่ใช้ DNSSEC ไม่มีสิ่งใดที่จะช่วยคุณได้ คุณต้องมีการ จำกัด อัตราการตอบกลับ DNS(DNS RRL) ซึ่งเป็นเทคโนโลยีที่ไม่ต้องเสียค่าใช้จ่ายซึ่งปัจจุบันมีอยู่ในเซิร์ฟเวอร์ชื่อโอเพนซอร์สหลายแห่งเช่น BIND, Knot, และ NSD คุณไม่สามารถแก้ไขปัญหาการสะท้อน DNS กับไฟร์วอลล์ของคุณได้เนื่องจากมีเพียงมิดเดิลแวร์ที่รับรู้เนื้อหาเช่นเซิร์ฟเวอร์ DNS เท่านั้น (ที่เพิ่ม RRL) รู้ดีพอเกี่ยวกับคำขอเพื่อให้สามารถเดาได้อย่างถูกต้องว่าอะไรคือการโจมตี ฉันต้องการเน้นอีกครั้ง: DNS RRL ให้บริการฟรีและเซิร์ฟเวอร์ผู้ให้บริการทุกรายควรเรียกใช้

ในการปิดฉันต้องการเปิดเผยอคติของฉัน ฉันเขียนส่วนใหญ่ของ BIND8 ฉันคิดค้น EDNS0 และฉันร่วมคิดค้น DNS RRL ฉันทำงานเกี่ยวกับ DNS มาตั้งแต่ปี 1988 ในฐานะ 20 อย่างและตอนนี้ฉันไม่พอใจ 50 อย่างซึ่งมีความอดทนน้อยลงสำหรับวิธีแก้ปัญหาแบบครึ่งอบเพื่อแก้ไขปัญหาที่เข้าใจผิด โปรดยอมรับคำขอโทษของฉันถ้าข้อความนี้ฟังดูเหมือนว่า "เฮ้คุณเด็ก ๆ ออกไปสนามหญ้าของฉัน!"

ฉันรู้ว่ามีสองช่องโหว่ที่เฉพาะเจาะจง มีการสะท้อน / การขยายที่กล่าวถึงโดยHåkan และมีความเป็นไปได้ของการแจงนับโซน

การสะท้อน / การขยาย

Reflection หมายถึงการโจมตีที่คำขอที่มี IP ต้นทางปลอมแปลงถูกส่งไปยังเซิร์ฟเวอร์ DNS โฮสต์ที่ถูกปลอมแปลงเป็นเหยื่อหลักของการโจมตี เซิร์ฟเวอร์ DNS จะส่งการตอบกลับไปยังโฮสต์ที่ไม่เคยถามมาโดยไม่รู้ตัว

Amplification หมายถึงการโจมตีแบบไตร่ตรองใด ๆ ซึ่งการตอบสนองแบบไตร่ตรองนั้นประกอบด้วยจำนวนไบต์มากกว่าหรือมากกว่าแพ็คเก็ตมากกว่าคำขอเดิม ก่อนการขยาย DNSSEC + EDNS0 ด้วยวิธีนี้จะอนุญาตให้ส่งได้สูงสุด 512 ไบต์เท่านั้น ด้วย DNSSEC + EDNS0 เป็นไปได้ที่ 4096 ไบต์จะถูกส่งซึ่งโดยทั่วไปจะมีขนาด 3-4 แพ็กเก็ต

มีการบรรเทาที่เป็นไปได้สำหรับการโจมตีเหล่านี้ แต่ฉันไม่ทราบว่าเซิร์ฟเวอร์ DNS ใดที่ใช้งานพวกเขา

เมื่อไคลเอนต์ IP ไม่ได้รับการยืนยันเซิร์ฟเวอร์ DNS สามารถส่งการตอบสนองที่ถูกตัดทอนเพื่อบังคับให้ไคลเอนต์สลับไปยัง TCP การตอบสนองที่ถูกตัดทอนอาจสั้นตามคำขอ (หรือสั้นกว่านี้หากไคลเอ็นต์ใช้ EDNS0 และการตอบสนองไม่ได้) ซึ่งกำจัดการขยาย

IP ไคลเอ็นต์ใด ๆ ที่จับมือ TCP เสร็จสมบูรณ์และส่งคำขอ DNS ในการเชื่อมต่อสามารถได้รับอนุญาตพิเศษ เมื่อรายการที่อนุญาตนั้น IP ได้รับการส่งการสอบถาม UDP และรับการตอบกลับ UDP สูงถึง 512 ไบต์ (4096 ไบต์หากใช้ EDNS0) หากการตอบสนอง UDP ทำให้เกิดข้อความแสดงข้อผิดพลาด ICMP IP จะถูกลบออกจากรายการที่อนุญาตอีกครั้ง

วิธีนี้ยังสามารถย้อนกลับได้โดยใช้บัญชีดำซึ่งหมายความว่า IP ของไคลเอ็นต์ได้รับอนุญาตให้ทำการสืบค้นผ่าน UDP โดยค่าเริ่มต้น แต่ข้อความแสดงข้อผิดพลาด ICMP ใด ๆ ทำให้ IP ถูกขึ้นบัญชีดำต้องใช้แบบสอบถาม TCP เพื่อลบบัญชีดำ

บิตแมปที่ครอบคลุมที่อยู่ IPv4 ที่เกี่ยวข้องทั้งหมดสามารถเก็บไว้ในหน่วยความจำ 444MB ที่อยู่ IPv6 นั้นจะต้องจัดเก็บด้วยวิธีอื่น

การแจงนับโซน

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

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

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

สิ่งที่คำนึงถึงไม่ใช่ DNSSEC เฉพาะเจาะจง แต่เกี่ยวกับส่วนขยาย EDNS0 ซึ่ง DNSSEC อาศัยอยู่

EDNS0 ช่วยให้โหลด UDP ที่มีขนาดใหญ่ขึ้นและเพย์โหลด UDP ที่มีขนาดใหญ่ขึ้นจะช่วยให้การโจมตีการสะท้อน / การขยายสัญญาณแย่ลง

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

จากนี้ฉันคิดว่าเปอร์เซ็นต์ของตัวตรวจสอบความถูกต้องน่าจะมีรูปร่างดีกว่าเปอร์เซ็นต์ของโซนที่เซ็นชื่ออย่างมีนัยสำคัญ