Bei DNS-Amplification-Angriffen auf einen DNS-Server habe ich beobachtet, dass einige DNS-Anfragen für ein IP/Port-Paar ungefähr so aussehen 104.49.96.196:80. Ich verstehe, dass dies eine gefälschte IP ist, aber ist es in Ordnung, den Port der DNS-Anfrage zu filtern? Ich glaube, wir sollten keinen Port > 1023 erwarten. Ist das eine sichere Annahme? In diesem Fall glaube ich, dass dies ein leicht zu erkennender Vorteil ist und man nicht auf den DNS-Amplification-Angriff reagieren kann (wenn das Paket den DNS-Server erreicht und nicht von der WAF gelöscht wird).
Antwort1
Nein, das ist keine sichere Annahme. Versuchen Sie nicht, nach Ports zu filtern, das wird keine nützlichen Ergebnisse bringen. Wie ein Client mit seinen lokalen Ports umgeht, ist seine eigene Sache, und daher können Sie als Server damit rechnen, dass Sie von allen Ports Datenverkehr erhalten. Die Unix-Aufteilung bei 1024 ist ein archaisches Erbe der Vergangenheit, das heute im Grunde nichts mehr bedeutet.
Wenn Sie die DNS-Verstärkung bekämpfen möchten, ist RRL oder grundsätzlich die Ratenbegrenzung neben „Standardmaßnahmen“ (z. B. Sicherstellen, dass Sie wirklich den gesamten Datenverkehr bewältigen müssen, der ankommt, d. h. dass Sie nicht völlig offen sind) heutzutage eine der am häufigsten verwendeten Methoden.
Ansehenhttps://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/für eine Einführung in das Thema undhttps://www.isc.org/docs/DNS-RRL-LISA14.pdffür eine technischere Präsentation.
Antwort2
DNS-Clients sollten einen Quellport > 1023 haben.
Wenn es < 1024 ist, sollte es nur dann Quellport 53 sein, wenn es von einem anderen DNS-Server kommt – aber das ist unwahrscheinlich.
Verifizieren mittcpdump port 53
Durch einen Blick aufRFC6056UndVereinfachung mit einigen BeispielenWir könnten noch weiter gehen und sagen, dass kein gut funktionierender IP-Stack einen Quellport kleiner als 49152 (erster temporärer Port) haben sollte (hatte). Dem widerspricht jedoch Abschnitt 3.2 und die Beispiele ebenfalls.
Aber bis jemand auf ein RFC verweisen kann, das RFC6056 neu definiert, kann man mit Sicherheit sagen, dass „Sport <= 1023“ nicht gültig ist.
Wenn aus irgendeinem Grund eine Anfrage fehlschlägt, sollte der Client es erneut versuchen und hoffentlich eine erfolgreiche Anfrage erhalten. (Selbst wenn dies fehlschlagen würde, würde ich diese Implementierungen ignorieren.)