ฉันจะตั้งค่าตัวแก้ไขแบบเปิด "ปลอดภัย" ได้อย่างไร


25

นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับการรักษาความปลอดภัยตัวแก้ไข DNS สาธารณะ

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

ฉันต้องการที่จะตั้งค่าบางอย่างเช่นนี้สำหรับการใช้งานโดย บริษัท ของเรา แต่ผมได้ยินมากเกี่ยวกับเรื่องนี้เป็นวิธีที่อันตราย (โดยเฉพาะอย่างยิ่งในเรื่องที่เกี่ยวกับการโจมตีขยาย ) และฉันต้องการที่จะทำให้แน่ใจว่าเราทำตอนนี้ สิ่งที่ฉันต้องจำไว้เมื่อสร้างสภาพแวดล้อมประเภทนี้?


5
downvote ทำให้ฉันหัวเราะคิกคัก
Andrew B

คำตอบ:


34

มีบางสิ่งที่คุณต้องเข้าใจในเรื่องนี้:


นี่เป็นปัญหาด้านวิศวกรรมเครือข่าย

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

  • UDP เป็นโปรโตคอลไร้สัญชาติ ไม่มีการจับมือลูกค้า
  • การค้นหากับเซิร์ฟเวอร์ DNS เป็นธุรกรรมสองขั้นตอนที่ไม่ผ่านการตรวจสอบสิทธิ์ (แบบสอบถามตอบกลับ) ไม่มีทางที่เซิร์ฟเวอร์จะทราบได้ว่ามีการปลอมแปลง IP ต้นทางก่อนที่จะตอบกลับหรือไม่
  • เมื่อถึงเวลาที่แบบสอบถามไปถึงเซิร์ฟเวอร์แล้วมันก็สายเกินไปแล้วที่จะป้องกันแพ็กเก็ต UDP ที่ถูกปลอมแปลง ปลอมแปลงเท่านั้นที่สามารถป้องกันได้โดยการปฏิบัติที่เรียกว่าการกรองการเข้าหัวข้อที่ถูกปกคลุมด้วยเอกสารBCP-38และBCP 84 สิ่งเหล่านี้ถูกนำไปใช้โดยอุปกรณ์เครือข่ายที่อยู่ด้านหน้าเซิร์ฟเวอร์ DNS ของคุณ
  • เราไม่สามารถให้คำแนะนำเกี่ยวกับวิธีตั้งค่าดาต้าเซ็นเตอร์ของคุณได้ตั้งแต่ต้นจนจบหรือวิธีการปฏิบัติที่ดีที่สุดเหล่านี้ สิ่งเหล่านี้มีความเฉพาะเจาะจงกับความต้องการของคุณ รูปแบบถาม & ตอบไม่ได้ผลสำหรับเรื่องนี้และเว็บไซต์นี้ไม่ได้มีไว้เพื่อทดแทนการจ้างคนทำงานมืออาชีพมาทำงาน
  • อย่าสันนิษฐานว่า บริษัท ที่มีมูลค่าเกินพันล้านดอลลาร์ของคุณเกินไปที่จะดำเนินการกรองอย่างถูกต้อง

นี่ไม่ใช่วิธีปฏิบัติที่ดีที่สุด แนวทางปฏิบัติที่ดีที่สุดไม่ใช่การทำเช่นนี้

ง่ายมากในการตั้งค่าอินเทอร์เน็ตที่ใช้ตัวแก้ไข DNS ใช้เวลาวิจัยน้อยกว่าในการตั้งค่ามากกว่าเข้าใจความเสี่ยงที่เกี่ยวข้องในการทำเช่นนั้น นี่เป็นหนึ่งในกรณีที่ความตั้งใจดีเปิดใช้งานการกระทำผิด (และความทุกข์) ของผู้อื่นโดยไม่ตั้งใจ

  • หากเซิร์ฟเวอร์ DNS ของคุณจะตอบกลับไปยังที่อยู่ IP ต้นทางใด ๆ ที่คุณเห็นคุณกำลังเรียกใช้ตัวแก้ไขที่เปิดอยู่ สิ่งเหล่านี้ถูกยกระดับอย่างต่อเนื่องในการโจมตีแบบขยายต่อฝ่ายผู้บริสุทธิ์ ผู้ดูแลระบบใหม่กำลังยืนอยู่ที่ตัวแก้ไขแบบเปิดทุกวันทำให้ผู้ที่ประสงค์ร้ายสามารถสแกนหาพวกเขาได้อย่างต่อเนื่อง ไม่มีคำถามจริง ๆ ว่าตัวแก้ไขแบบเปิดของคุณจะถูกนำไปใช้ในการโจมตีหรือไม่: ในปี 2558 เป็นเรื่องที่ได้รับมา มันอาจจะไม่ทันที แต่มันจะเกิดขึ้นอย่างแน่นอน
  • แม้ว่าคุณจะใช้ ACL โดยใช้ซอฟต์แวร์ DNS ของคุณ (เช่น BIND) สิ่งนี้จะ จำกัด ว่าแพ็คเก็ต DNS ปลอมแปลงที่เซิร์ฟเวอร์ของคุณจะตอบกลับ สิ่งสำคัญคือต้องเข้าใจว่าโครงสร้างพื้นฐาน DNS ของคุณสามารถใช้งานไม่เพียง แต่จะโจมตีอุปกรณ์ใน ACL แต่อุปกรณ์เครือข่ายใด ๆ ระหว่างเซิร์ฟเวอร์ DNS ของคุณและอุปกรณ์ที่จะตอบสนอง หากคุณไม่ได้เป็นเจ้าของศูนย์ข้อมูลนั่นเป็นปัญหาสำหรับคุณ

Google และ OpenDNS ทำเช่นนี้ทำไมฉันทำไม่ได้

บางครั้งจำเป็นต้องชั่งน้ำหนักความกระตือรือร้นต่อความเป็นจริง นี่คือคำถามที่ยากที่จะถามตัวเอง:

  • นี่คือสิ่งที่คุณต้องการตั้งค่าด้วยความตั้งใจหรือเป็นสิ่งที่คุณมีไม่กี่ล้านดอลลาร์เพื่อลงทุนในการทำมันใช่ไหม?

  • คุณมีทีมรักษาความปลอดภัยโดยเฉพาะหรือไม่? ทีมการละเมิดโดยเฉพาะหรือไม่ พวกเขาทั้งสองมีรอบการจัดการกับโครงสร้างพื้นฐานใหม่ของคุณและการร้องเรียนที่คุณจะได้รับจากบุคคลภายนอกหรือไม่

  • คุณมีทีมกฎหมายหรือไม่?

  • เมื่อสิ่งเหล่านี้ถูกพูดและทำเสร็จแล้วความพยายามทั้งหมดนี้แม้จะเริ่มต้นจากระยะไกลจ่ายผลกำไรให้กับ บริษัท หรือเกินกว่าค่าเงินในการจัดการกับความไม่สะดวกที่ทำให้คุณไปในทิศทางนี้?


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

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

ช่วยเรารักษาความปลอดภัยของอินเทอร์เน็ต! :)


5
ในฐานะที่เป็นส่วนเติมเต็มให้คนสามารถตรวจสอบพวกเขาไม่ได้มีการถ่ายทอด DNS ที่เปิดในช่วงสาธารณะของพวกเขาผ่านทางโครงการ openresolver ทุกคนควรระลึกไว้เสมอว่าอินเทอร์เน็ตนั้นมีรีเลย์แบบเปิดประมาณ20 ล้านตัวที่รับคิวรีแบบเรียกซ้ำ ตัวอย่างของผลที่ตามมา: CloudFlare ประสบการโจมตี DNS 300 Gb / s โดยใช้ 0.1% ของเหล่านี้
Xavier Lucas

คุณไม่สามารถปิดใช้งาน UDP และบังคับให้คิวรีทั้งหมดใช้ TCP แทนได้หรือไม่
小太郎

@ 小太郎อ้างถึงคำถามนี้ ไลบรารีตัวแก้ไขจะใช้ค่าเริ่มต้นเป็นโหมด UDP และในหลายกรณีลองใหม่กับ TCP หากการตอบกลับถูกตัดทอน มันจะใช้งานได้หากแอปพลิเคชันข้ามระบบปฏิบัติการและทำการค้นหาของตัวเอง แต่โดยปกติแล้วจะเอาชนะจุดประสงค์ของสิ่งที่ผู้คนพยายามทำให้สำเร็จด้วยการตั้งค่านี้
Andrew B

0

ไม่ว่าคุณจะเรียกใช้ตัวเรียกคืน DNS แบบเปิดหรือเซิร์ฟเวอร์ DNS ที่มีสิทธิ์ปัญหาก็เหมือนกันและวิธีแก้ปัญหาที่เป็นไปได้ส่วนใหญ่ก็เหมือนกัน

ทางออกที่ดีที่สุด

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

ทางเลือกสำหรับลูกค้าเก่า

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

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

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

ด้วยเหตุผลเหล่านี้อัตรา จำกัด เล็กน้อยภายใต้ความจุจริงของคุณอาจเป็นความคิดที่ดีแม้ว่าจะไม่ได้ป้องกันการขยายสัญญาณ

ใช้ TCP

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

ค่าใช้จ่ายของ Roundtrips เพิ่มเติมสองอันสามารถ จำกัด ได้เฉพาะการร้องขอครั้งแรกโดยใช้วิธีนี้:

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

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

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

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

ฉันไม่ทราบว่าเซิร์ฟเวอร์ DNS ใด ๆ ใช้วิธีนี้หรือไม่

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


เพื่อความเป็นธรรมคำตอบของฉันจะเน้นไปที่เทคโนโลยีกล่องที่อยู่ในมือของเราตอนนี้ คนส่วนใหญ่ที่ถามคำถามนี้ใน Serverfault ไม่ต้องการพัฒนาซอฟต์แวร์เนมเซิร์ฟเวอร์ของตนเองหรือเขียนซอฟต์แวร์แก้ไขสำหรับซอฟต์แวร์ชื่อเซิร์ฟเวอร์ที่มีอยู่ Alnitak ได้แจ้งให้เราทราบว่าวิธีการขึ้นบัญชีขาวของ TCP + ที่คุณแนะนำดูเหมือนจะได้รับการจดสิทธิบัตรแม้ว่าเขาจะไม่ได้อ้างถึงสิทธิบัตรที่แน่นอนก็ตาม
Andrew B

นอกจากนี้คุณยังสามารถสร้างการโจมตี DoS ที่คุณกล่าวถึงในการใช้ซอฟต์แวร์เซิร์ฟเวอร์ DNS ใด ๆ ในปัจจุบันที่ใช้งาน RRL หรือรู้กรณีที่คนอื่นประสบความสำเร็จหรือไม่ ฉันค่อนข้างแน่ใจว่าสิ่งนี้จะเกิดขึ้นกับรายชื่ออีเมลที่ฉันสมัคร
Andrew B

@AndrewB ฉันยังไม่ได้ทดสอบเพราะฉันไม่ต้องการทำให้เกิดน้ำท่วมในเซิร์ฟเวอร์ของคนอื่น และบางคนที่กล่าวถึงการ จำกัด อัตราการมีทัศนคติที่ทำให้ฉันคิดว่าพวกเขาจะไม่ไว้วางใจผลลัพธ์ถ้าฉันทำบนเซิร์ฟเวอร์ของตัวเอง แต่เมื่อคุณขอให้ฉันลองทำฉันจะต้องตั้งค่าเซิร์ฟเวอร์ DNS แยกต่างหากเพื่อทำการทดสอบ การใช้เวอร์ชัน Bind เริ่มต้นบน Ubuntu LTS 14.04 นั้นเหมือนกับการตั้งค่าที่สมเหตุสมผลหรือไม่? การตั้งค่าที่แน่นอนบนเซิร์ฟเวอร์ที่มีสิทธิ์คุณจะพิจารณาว่าเหมาะสมสำหรับการทดสอบดังกล่าวหรือไม่
kasperd

ฉันไม่ใช่คนที่ดีที่สุดในการขอตั้งค่าขออภัยเรายังไม่ได้เริ่มการทดสอบในห้องปฏิบัติการ ฉันจะยังคงสนับสนุนให้คุณลองและสร้างสถานการณ์ที่เสนอ: ไม่ว่าทัศนคติของฝ่ายที่คุณสนทนาด้วยมีหลายฝ่ายในหลายฐานการติดตั้งซอฟต์แวร์ที่จะให้ความสนใจในการหาประโยชน์ในทางปฏิบัติ ฉันยังแนะนำให้คุณตรวจสอบ UDP ที่ได้รับการล้นคิวโดยใช้ SNMP กราฟที่จะช่วยแสดงให้เห็นว่าคุณสามารถลดความสามารถของซอฟต์แวร์ในการรับแพ็คเก็ตได้หรือไม่
Andrew B

@ AndrewB ฉันเพิ่งตระหนักถึงความคลาดเคลื่อนเล็กน้อยที่นี่ คำถามนี้เกี่ยวกับตัวแก้ไขแบบเรียกซ้ำ แต่การ จำกัด อัตราไม่ได้ออกแบบมาสำหรับตัวแก้ไขแบบเรียกซ้ำ Deliberately open recursive DNS servers are outside the scope of this document.สำหรับตอนนี้ฉันได้เพิ่มคำเตือนเกี่ยวกับเรื่องนั้น ฉันควรทดสอบว่าเป็นไปได้หรือไม่ที่จะเปิดใช้งานการ จำกัด อัตราของ Bind ที่กำหนดค่าเป็นโปรแกรมแก้ไขแบบเรียกซ้ำและถ้ามันทำงานได้อย่างถูกต้อง
kasperd
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.