สาธารณะหันหน้าไปทางเซิร์ฟเวอร์ DNS ซ้ำ - กฎ iptables


16

เราใช้เซิร์ฟเวอร์ DNS แบบเรียกซ้ำแบบสาธารณะบนเครื่อง Linux เราถูกใช้สำหรับการโจมตีการขยาย DNS มีiptablesกฎที่แนะนำที่จะช่วยลดการโจมตีเหล่านี้หรือไม่?

วิธีแก้ปัญหาที่ชัดเจนคือเพียง จำกัด แพ็คเก็ต DNS ขาออกไปยังระดับการรับส่งข้อมูลที่แน่นอน แต่ฉันหวังว่าจะพบสิ่งที่ฉลาดกว่านี้อีกเล็กน้อยเพื่อที่การโจมตีจะบล็อกการรับส่งข้อมูลไปยังที่อยู่ IP ของเหยื่อ

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


2
คนที่แนะนำให้คุณไม่เรียกใช้เนมเซิร์ฟเวอร์สาธารณะแบบเรียกซ้ำที่ถูกต้อง คุณช่วยอธิบายได้ไหมว่าทำไมมันถึงจำเป็น
Alnitak

1
@Alnitak: สิ่งที่ไม่ง่ายต่อการเปลี่ยนแปลงจะแตกถ้าเราไม่ทำเช่นนั้นเนื่องจากการตัดสินใจที่ทำมานานกว่าทศวรรษที่ผ่านมา
David Schwartz

ใช่ฉันเห็นว่าในคำถามเดิม คุณช่วยอธิบายได้ไหมว่าทำไมการกำหนดค่านั้นจึงจำเป็น
Alnitak

2
@Alnitak: เพราะสิ่งที่ไม่ง่ายที่จะเปลี่ยนจะขึ้นอยู่กับมัน เหล่านี้คืออุปกรณ์ที่มีเฟิร์มแวร์และติดตั้งอยู่ทั่วโลกมีสิ่งอำนวยความสะดวกที่ปลอดภัยมากมายที่เราไม่สามารถเข้าถึงได้
David Schwartz

ระบบฝังตัวของคุณรองรับการจำแนกชื่อ TCP แทน UDP หรือไม่ ถ้าเป็นเช่นนั้นมันจะง่ายแค่ไหนในการปิดการใช้งาน UDP สำหรับการแก้ปัญหา?
Mike Pennington

คำตอบ:


9

"ไม่ใช่ปัญหาของฉัน" ที่ไม่ใช่ความผิดของคุณจริง ๆ และควร / สามารถแก้ไขได้ 100% โดยดำเนินการตามความเหมาะสมโดยไม่คำนึงว่า "ยาก" หรือ "ยาก" เป็นอย่างไรและนั่นเป็นการยกเลิก เซิร์ฟเวอร์

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

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

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

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

สิ่งนี้ทำตลอดเวลา: ฉันมีลูกค้าหลายรายที่ จำกัด การเข้าถึงเอกซ์ทราเน็ตหรือผู้ฟัง HL7 สำหรับพันธมิตรทางการแพทย์ด้วยวิธีนี้ มันไม่ยากเลยเพื่อให้พวกเขากรอกแบบฟอร์มและจัดหา IP และ / หรือ netblock ฉันควรคาดหวังปริมาณการใช้ข้อมูลจาก: หากพวกเขาต้องการเข้าถึงเอกซ์ทราเน็ตพวกเขาต้องให้ IP หรือซับเน็ตให้ฉัน และนี่เป็นเป้าหมายที่เคลื่อนย้ายได้ยากดังนั้นจึงไม่เหมือนกับที่คุณจะได้รับการร้องขอการเปลี่ยนแปลง IP หลายร้อยครั้งทุกวัน: เครือข่ายโรงพยาบาลในมหาวิทยาลัยขนาดใหญ่ที่เป็นเจ้าของ netblocks ของตัวเองด้วยเครือข่ายย่อยหลายร้อยเครือข่าย หยิบที่อยู่ IP หรือเครือข่ายย่อยฉันควรคาดหวัง; อีกครั้งผู้ใช้แล็ปท็อปเหล่านี้ไม่ได้เดินทางไปรอบ ๆ มหาวิทยาลัยตลอดเวลาดังนั้นทำไมฉันจึงคาดว่าจะเห็นแหล่งข้อมูลแพ็กเก็ต UDP จากที่อยู่ IP ที่เปลี่ยนแปลงตลอดเวลา เห็นได้ชัดว่าฉันทำให้ฉันเป็นสมมติฐานที่นี่ แต่ฉันจะเดิมพันมันไม่มากเท่าที่คุณคิดสำหรับอุปกรณ์ <100s ใช่มันจะเป็น ACL ที่ยาวและใช่

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

การรันนานtcpdumpควรทำงานการกรอง UDP 53 ที่เข้ามาและการบันทึกอย่างละเอียดในแอปพลิเคชันเซิร์ฟเวอร์ DNS ฉันต้องการเริ่มรวบรวมแหล่งข้อมูลที่อยู่ IP / netblocks / geoIP (ลูกค้าของคุณทั้งหมดในสหรัฐฯหรือไม่ปิดกั้นทุกอย่าง) เพราะอย่างที่คุณบอกว่าคุณไม่ได้เพิ่มอุปกรณ์ใหม่คุณเพียงแค่มอบมรดก บริการการติดตั้งที่มีอยู่

วิธีนี้จะช่วยให้คุณเข้าใจว่ามีการร้องขอประเภทระเบียนใดและโดเมนใดที่ใครและบ่อยครั้งเพียงใด : เพื่อให้การขยาย DNS ทำงานได้ตามที่ต้องการผู้โจมตีจะต้องสามารถขอประเภทระเบียนขนาดใหญ่ (1) ทำงานโดเมน (2)

  1. "ประเภทระเบียนขนาดใหญ่": อุปกรณ์ของคุณจำเป็นต้องใช้ระเบียน TXT หรือ SOA เพื่อให้สามารถแก้ไขได้โดยเซิร์ฟเวอร์ DNS แบบเรียกซ้ำหรือไม่? คุณอาจระบุประเภทระเบียนที่ถูกต้องบนเซิร์ฟเวอร์ DNS ของคุณ ฉันเชื่อว่าเป็นไปได้ด้วย BIND และ Windows DNS แต่คุณต้องขุดบ้าง หากตอบสนองเซิร์ฟเวอร์ DNS ของคุณกับSERVFAILใด ๆ TXT หรือ SOA ระเบียนและน้อยว่าการตอบสนองเป็นคำสั่งของขนาด (หรือสอง) มีขนาดเล็กกว่าอัตราที่ตั้งใจ เห็นได้ชัดว่าคุณยังคง "เป็นส่วนหนึ่งของปัญหา" เพราะเหยื่อที่ปลอมแปลงจะยังคงได้รับการSERVFAILตอบสนองจากเซิร์ฟเวอร์ของคุณ แต่อย่างน้อยคุณก็ไม่ได้ทุบพวกเขาและบางทีเซิร์ฟเวอร์ DNS ของคุณได้รับ "เพิกถอน" จากรายการที่เก็บเกี่ยว บอทใช้ตลอดเวลาเพราะไม่ใช่ "การประสานงาน"

  2. "โดเมนที่ใช้งานได้": คุณอาจสามารถยกเว้นโดเมนที่ถูกต้องเท่านั้น ฉันทำสิ่งนี้ในการตั้งค่าศูนย์ข้อมูลที่แข็งขึ้นซึ่งเซิร์ฟเวอร์ต้องการเพียงแค่ Windows Update, Symantec และอื่น ๆ เพื่อให้สามารถใช้งานได้ อย่างไรก็ตามคุณเพียงแค่บรรเทาความเสียหายที่เกิดขึ้น ณ จุดนี้เหยื่อจะยังคงถูกโจมตีNXDOMAINหรือSERVFAILตอบสนองจากเซิร์ฟเวอร์ของคุณเพราะเซิร์ฟเวอร์ของคุณจะยังตอบสนองต่อ IP ต้นทางที่ปลอมแปลง อีกครั้งสคริปต์ Bot อาจอัปเดตรายการเซิร์ฟเวอร์ที่เปิดโดยอัตโนมัติตามผลลัพธ์ดังนั้นจึงอาจลบเซิร์ฟเวอร์ของคุณได้

ฉันจะใช้การ จำกัด อัตรารูปแบบตามที่คนอื่นแนะนำในระดับแอปพลิเคชัน (เช่นขนาดข้อความคำขอต่อข้อ จำกัด ไคลเอนต์) หรือระดับไฟร์วอลล์ (ดูคำตอบอื่น ๆ ) แต่อีกครั้งคุณจะ ต้องทำการวิเคราะห์เพื่อให้แน่ใจว่าคุณไม่ได้ฆ่าทราฟฟิกที่ถูกกฎหมาย

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

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


1
ไม่สามารถแก้ไขได้ เราไม่ได้ทำงานสร้างฮาร์ดแวร์อีกต่อไปสำหรับบางแพลตฟอร์ม สำหรับ netblock ที่พวกเขาคาดหวังการรับส่งข้อมูลพวกเขามักไม่รู้ ฉันไม่แน่ใจว่าคุณจะชื่นชมความผิดปกติของสภาพแวดล้อมที่อุปกรณ์เหล่านี้บางตัวอยู่ในเครือข่ายส่วนตัวที่พวกเขามีรูปแบบ DNS ของตัวเองและอาจไม่มีใครอยู่รอบ ๆ อีกต่อไปที่รู้วิธีการตั้งค่าระบบ ขึ้น เราแค่ต้องทำให้มันทำงานจนกว่าสัญญาจะสิ้นสุด
David Schwartz

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

1
ฉันกำลังคิดแนวทางลูกผสม IP ที่ได้รับอนุญาตที่เราสามารถระบุได้ (อาจอยู่ภายใต้ขีด จำกัด สูง) เรื่อง IP อื่น ๆ ถึงขีด จำกัด ที่ค่อนข้างต่ำ ตรวจสอบเป็นระยะเพื่อดูว่า IP ใด ๆ ที่จำเป็นต้องได้รับการยกเว้นหรือลบออกจากรายการที่อนุญาตหรือไม่
David Schwartz

@DavidSchwartz คุณอาจไม่ต้องการขีด จำกัด สูง อีกครั้งการมีการรับส่งข้อมูลพื้นฐานจะช่วยได้อย่างมาก
gravyface

6

ขึ้นอยู่กับประเภทของการ จำกัด อัตราที่คุณต้องการ

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

iptables การ จำกัด อัตราการลดลง:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

การใช้ hashlimitมากกว่าlimitจะให้อัตรา จำกัด คุณต่อ IP ปลายทาง คือแพ็คเก็ตห้าถึง 8.8.8.8 ที่ขีด จำกัด จะป้องกันแพ็คเก็ตที่ถูกส่งไปยัง 8.8.4.4 ในขณะที่hashlimitถ้า 8.8.8.8 สูงสุดคุณยังสามารถไปถึง 8.8.4.4 ซึ่งฟังดูเหมือนสิ่งที่คุณต้องการ

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

ฉันไม่ได้ใช้tcมากนัก แต่นี่เป็นตัวอย่างของการ จำกัด อัตรา ICMPซึ่งคุณสามารถปรับใช้กับ DNS ได้อย่างง่ายดาย


1
บทความของฉันในภาษาฝรั่งเศสเกี่ยวกับการตั้งค่านี้ (ใช้สำหรับตัวแก้ไขการเปิดจริง): bortzmeyer.org/rate-limiting-dns-open-resolver.html
bortzmeyer

4

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

ก่อนอื่นให้ดูที่บันทึกการรักษาความปลอดภัยและค้นหาที่อยู่ IP ที่ได้รับการปลอมแปลง

จากนั้นรัน tcpdump โดยใช้ IP ต้นทาง (10.11.12.13) ดังนี้:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

คุณจะได้รับสิ่งนี้:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, offset 0, แฟล็ก [none], proto: UDP (17), ความยาว: 45) 10.11.12.13.51169> 01.02.03.04.domain: 4215+ ANY ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... ด้วย
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

ตอนนี้ส่วนที่สนุก! เปิด rfc1035 ที่http://tools.ietf.org/html/rfc1035และไปที่หัวข้อ 4.1.1

ได้เวลาแปลผลลัพธ์ของ tcpdump แล้วค้นหารูปแบบที่เราสามารถใช้เพื่อสร้างตัวกรองระดับแพ็กเก็ต

ID ของส่วนหัวเริ่มต้นที่ 0x1C ดังนั้นเราจึงมีแฟล็กที่ 0x1E, QDCOUNT ที่ 0x20, ANCOUNT ที่ 0x22, NSCOUNT ที่ 0x24 และ ARCOUNT ที่ 0x26

นั่นเหลือคำถามจริงที่ 0x28 ซึ่งในกรณีนี้คือ null (ROOT) สำหรับ NAME, 0xFF สำหรับ QTYPE = ANY และ 0x01 สำหรับ QCLASS = IN

เพื่อให้เรื่องสั้นสั้นฉันพบว่าการเพิ่มกฎ iptables ต่อไปนี้บล็อกมากกว่า 95% ของการค้นหาที่หลอกลวงซึ่งกำลังร้องขอบันทึกใด ๆ ที่อยู่ในรูท:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

ไมล์สะสมของคุณอาจแตกต่างกันไป ... หวังว่านี่จะช่วยได้


3

การใช้tcและการจัดคิวงานใน linux สำหรับพอร์ตขาออก 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

จะตั้งค่าคุณด้วยการdiscจำกัด เพียง 10mbit สำหรับแพคเก็ตใด ๆ ที่มีเครื่องหมายไฟร์วอลล์ '1' เครื่องหมายไฟร์วอลล์เป็นไฟร์วอลล์ภายในเท่านั้นและไม่ได้แก้ไขแพ็กเก็ต เพียงแค่การจัดการแพ็คเก็ตโดยการจัดคิว นี่คือวิธีที่คุณใช้iptablesในการทำเครื่องหมายไฟร์วอลล์:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

ปรับเปลี่ยนตามที่คุณต้องการยกเว้นเครือข่ายย่อยและ / หรือปลายทางที่เชื่อถือได้ -o eth0ขีด จำกัด ของการสร้างที่จะแพ็คเก็ตขาออกเท่านั้น หวังว่านี่จะช่วยได้


DNS ใช้ UDP และ TCP ...
Patrick Mevzek

1

ฉันพยายามเขียนรายชื่อลูกค้าทั้งหมดที่พึ่งพาตัวแก้ไขแบบเรียกซ้ำภายนอกของคุณ เริ่มด้วยการติดตามแพ็คเก็ตหนึ่งวันหรือมากกว่านั้นในกล่อง DNS จากนั้นให้เริ่มสร้างกฎ iptables เพื่ออนุญาตการรับส่งข้อมูลที่คุณรับรู้และอนุญาต ในที่สุดค่าเริ่มต้นจะลดทราฟฟิกเป็น 53 / tcp และ 53 / udp หากสิ่งนั้นผิดพลาดให้ปรับกฎของคุณ


1

ทั้งนี้ขึ้นอยู่กับ 'ตำแหน่ง' ของเครือข่ายที่คุณอยู่ใน [มีฟีด bgp หลายรายการหรืออยู่ที่ 'สิ้นสุด' ของอินเทอร์เน็ต - ในฐานะเครือข่ายต้นขั้ว] คุณสามารถลองบางอย่างเช่นuRPFเพื่อป้องกันการปลอมแปลงแหล่งที่อยู่

แหล่งข้อมูลอื่น ๆ


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

@DavidSchwartz ฉันได้ตัดสินใจที่จะยกเลิกการลบคำตอบของฉัน ฉันเข้าใจว่ามันไม่ได้มีประโยชน์มากในกรณีของคุณ แต่อาจมีประโยชน์สำหรับผู้อื่น กรณีที่น่าสนใจ btw - ฉันอยากรู้เกี่ยวกับคำตอบอื่น ๆ ที่จะมา
pQd

1

อุปกรณ์เหล่านี้ยังอยู่ภายใต้สัญญาการสนับสนุนหรือไม่ ถ้าเป็นเช่นนั้นติดต่อกับลูกค้าของคุณ บอกให้พวกเขารู้ว่าอินเทอร์เน็ตมีการพัฒนาเล็กน้อยในทศวรรษที่ผ่านมาและเพื่อที่จะให้การแก้ปัญหาชื่อสำหรับอุปกรณ์เหล่านี้คุณจะต้องรู้ SRC IP เพื่อคาดหวังการสืบค้น กำหนดวันที่ ~ 6 เดือนในอนาคตในเวลาที่คุณจะไม่สามารถให้บริการลูกค้าที่ไม่รู้จักและติดอยู่กับมัน นี่เป็นเรื่องธรรมดาในอุตสาหกรรม หากอุปกรณ์เหล่านี้ไม่อยู่ภายใต้สัญญาการสนับสนุนอีกต่อไป ... ดูเหมือนจะเป็นการตัดสินใจทางธุรกิจ บริษัท ของคุณตั้งใจจะใช้ทรัพยากรไปกับผลิตภัณฑ์โบราณที่ไม่สร้างรายได้อีกต่อไปนานแค่ไหน?

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

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


1
อ่านคำตอบอื่น ๆ คุณบอกว่าคุณไม่สามารถพัฒนาแพทช์ได้เพราะคุณไม่มีฮาร์ดแวร์ที่จะทำการทดสอบอีกต่อไป ในกรณีนี้สัญญาการสนับสนุนปัจจุบันของคุณมีความถูกต้องหรือไม่ คุณจะทำอย่างไรถ้าหนึ่งในอุปกรณ์ 'ที่รองรับ' เหล่านี้ประสบกับความล้มเหลวของฮาร์ดแวร์ ทำสิ่งเดียวกันที่นี่
Jason Preston

เราไม่สนับสนุนฮาร์ดแวร์ เราไม่ได้รับอนุญาตแม้แต่จะสัมผัสฮาร์ดแวร์ หากฮาร์ดแวร์ล้มเหลวก็จะถูกทำลายและเปลี่ยน เราสนับสนุนโครงสร้างพื้นฐานระยะไกลและต้องทำตามสัญญาจนถึงปี 2558 (ไม่ใช่ว่าเราไม่มีฮาร์ดแวร์ที่จะทำการทดสอบนั่นคือเราไม่สามารถทำการทดสอบได้การเปลี่ยนแปลงใด ๆ จำเป็นต้องได้รับการอนุมัติ ไม่สามารถทำได้อีกต่อไปเนื่องจากมาตรฐานการอนุมัติหมดอายุแล้วยินดีต้อนรับสู่การจัดการกับรัฐบาล)
David Schwartz

1

จาก nanog บางแห่งสิ่งนี้:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

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


-1

นี่เป็นวิธีแก้ปัญหาที่ฉันใช้สองสามครั้งเพื่อป้องกันการโจมตี DDOS มันไม่ได้สมบูรณ์แบบ แต่ช่วยฉันออก โซลูชันประกอบด้วยสคริปต์ที่ถูกเรียกแต่ละนาที N (เช่น 1,2,3 ฯลฯ นาที) โดย cron และบล็อก IP ที่สร้างจำนวนการเชื่อมต่อที่ใหญ่กว่าจากนั้นกำหนดในสคริปต์:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp

3
ฉันไม่คิดว่ามันจะทำงาน: DNS เป็นคำขอ / ตอบกลับผ่าน UDP และไม่ปล่อยให้การเชื่อมต่อที่เปิดอยู่
bortzmeyer
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.