ตัวแก้ไข DNS และการกรองพอร์ตคำขอ

ระหว่างการโจมตีด้วยการขยาย DNS บนเซิร์ฟเวอร์ DNS ฉันสังเกตเห็นว่าคำขอ DNS บางรายการมี IP/พอร์ต 2 พอร์ตที่คล้ายกัน 104.49.96.196:80. ฉันเข้าใจว่านี่เป็น IP ปลอม แต่ควรพิจารณากรองพอร์ตของคำขอ DNS หรือไม่ ฉันเชื่อว่าเราไม่ควรคาดหวังพอร์ต > 1023 มันเป็นสมมติฐานที่ปลอดภัยหรือไม่? ในกรณีนั้น ฉันเชื่อว่านี่เป็นเรื่องง่ายที่จะตรวจพบและไม่ตอบกลับการโจมตีแบบขยาย DNS (หากแพ็กเก็ตเข้าถึงเซิร์ฟเวอร์ DNS และไม่ถูกทิ้งโดย WAF)

ไคลเอนต์ DNS ควรมีพอร์ตต้นทางที่ > 1023

หากเป็น <1024 ควรเป็นพอร์ตต้นทาง 53 หากมาจากเซิร์ฟเวอร์ DNS อื่น - แต่นั่นไม่น่าเป็นไปได้

ยืนยันด้วย พอร์ต tcpdump 53

โดยดูว่า RFC6056 และ การทำให้เข้าใจง่ายด้วยตัวอย่างบางส่วน เราอาจกล่าวต่อไปว่าสแต็ก IP ที่ใช้งานได้ดีไม่ควรมี (มี) พอร์ตต้นทางที่ต่ำกว่า 49152 (พอร์ตชั่วคราวแรก) อย่างไรก็ตาม ส่วนที่ 3.2 ขัดแย้งกับสิ่งนี้ ตัวอย่างก็เช่นกัน

แต่จนกว่าจะมีใครให้การอ้างอิงถึง RFC ที่นิยาม RFC6056 ใหม่ได้ จึงปลอดภัยที่จะบอกว่า sport <= 1023 ไม่ถูกต้อง

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

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

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

ดูที่ https://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/ สำหรับคำแนะนำเกี่ยวกับเรื่องนี้และที่ https://www.isc.org/docs/DNS-RRL-LISA14.pdf สำหรับการนำเสนอทางเทคนิคเพิ่มเติม