Ich betreibe einen autoritativen Bind-DNS-Server. Ich folge allen empfohlenen Vorgehensweisen und mein Server ist ausschließlich autorativ (nicht rekursiv) mit aktivierter Ratenbegrenzung.
BIND antwortet auf Anfragen für nicht autoritative Zonen mit dem Code REFUSE. Die Ratenbegrenzung tut ihren Zweck und verhindert, dass mein Server an groß angelegten UDP-Amplification-Angriffen teilnimmt. Ich würde jedoch lieber alle Antworten für Zonen eliminieren, für die ich nicht autoritative bin.
Gibt es hierfür eine Konfigurationsmöglichkeit?
Antwort1
Während es in Ordnung wäre, in dem genauen Szenario, das Sie in Ihrer Frage beschreiben (gefälschte Abfrage bei einem potenziellen Amplification-Angriff, alternativ Prüfung, ob Ihr Server für einen solchen Angriff verwendet werden kann), nicht zu antworten, da kein Resolver tatsächlich auf Ihre Antwort wartet, besteht das Problem darin, dass das Nichtbeantworten von Abfragen echte Probleme verursachen kann und Ihre vorgeschlagene Lösung umfassender ist als das genaue Szenario, das Sie zuerst beschrieben haben (denken Sie daran, dass eine Zone, die Sie tatsächlich nicht haben, an Ihren Nameserver delegiert werden könnte, ob versehentlich oder absichtlich).
Das Nichtbeantworten von Anfragen wird für autoritative Nameserver im Allgemeinen nicht als gute Vorgehensweise angesehen. Gründe hierfür sind:
- Resolver-Server verfolgen die Reaktionsfähigkeit/Zuverlässigkeit der autoritativen Server, mit denen sie arbeiten, um ihre eigene Reaktionsfähigkeit zu verbessern. Dies geschieht Server für Server, nicht Abfrage für Abfrage. Das heißt, Sie können die aktuell wahrgenommene Zuverlässigkeit Ihres Nameservers beeinträchtigen, wenn Sie am Ende nicht auf (möglicherweise fehlgeleitete) Anfragen aus legitimen Quellen antworten. Es ist möglicherweise möglich, Resolver dazu zu bringen, zu glauben, Ihr Nameserver sei völlig ausgefallen (vorübergehend, aber möglicherweise immer wieder).
- Wenn das Nichtbeantworten auch „gute“ Abfragen beeinträchtigen kann (beispielsweise aufgrund einer hohen Abfragerate?), kann dies zu weiteren Problemen führen, die auf den ersten Blick möglicherweise nicht offensichtlich sind, wie z. B. einem erhöhten Risiko erfolgreicher Cache-Poisoning-Angriffe für alle von Ihnen bedienten nicht signierten Zonen (insbesondere, wenn ein Angreifer Ihre Abfrage einigermaßen zuverlässig löschen kann).
Stattdessen möchten Sie im Allgemeinen die Größe der Antworten begrenzen, um nicht tatsächlich die von Angreifern gewünschte Verstärkung bereitzustellen (was Sie anscheinend bereits tun):
- Abfragen, die keiner Zone entsprechen (wie in Ihrem Beispiel), sollten eine leere
REFUSEDAntwort erhalten (damals war es üblich, eine vollständige Verweisantwort für die Wurzel zu senden). - Wenn Sie eine Ratenbegrenzung implementieren, möchten Sie wahrscheinlich leere, gekürzte (
TCgesetzte) Antworten senden, anstatt nicht zu antworten. Wenn ein tatsächlich legitimer Resolver-Server eine Ratenbegrenzung erfährt, erhält er eine Antwort und die Markierung als gekürzt veranlasst ihn lediglich dazu, seine Abfrage über TCP erneut zu senden. - Der
ANYAbfragetyp hat von vornherein nur einen begrenzten tatsächlichen Nutzen und wird manchmal noch weiter eingeschränkt, um die Generierung großer Antworten zu vermeiden. (Wieminimal-anyin BIND) - (Und natürlich ist Rekursion im gesamten Internet absolut nicht zulässig)
Was das Nicht-Reagieren mit BIND betrifft, so ist die Funktion, die das Nicht-Reagieren ermöglicht, die Antwortratenbegrenzung (RRL), die einen slipKonfigurationsparameter hat, um das Verhältnis von Abschneiden zu Löschen zu steuern, wenn jemand die Ratenbegrenzung erreicht hat. Beachten Sie jedoch, dass das Löschen hauptsächlich für einen Resolver-Server und nicht für einen autoritativen Server relevant ist (wie in der vorherigen Erklärung). Dies wird auch inRRL-Abschnitt des BIND-Handbuchs:
(Hinweis: Verworfene Antworten von einem autoritativen Server können es Dritten erschweren, erfolgreich eine Antwort an einen rekursiven Resolver zu fälschen. Der beste Schutz gegen gefälschte Antworten besteht darin, dass autoritative Betreiber ihre Zonen mit DNSSEC signieren und Resolver-Betreiber die Antworten validieren. Wenn dies keine Option ist, können Betreiber, denen die Integrität der Antworten wichtiger ist als die Minderung von Überflutungen, den Slip auf 1 setzen, wodurch alle ratenbegrenzten Antworten abgeschnitten und nicht verworfen werden. Dies verringert die Wirksamkeit der Ratenbegrenzung gegen Reflektionsangriffe.)
Wenn Sie sich in einer Notlage befinden, in der ein anderer Kompromiss tatsächlich Sinn macht, können Sie den slipoben erwähnten Knopf trotzdem in Betracht ziehen oder ein Werkzeug mit einem anderen Satz von Ratenbegrenzungsknöpfen, wie z. B.dnsdist.
Wenn es sich dabei jedoch nur um den normalen Hintergrundgeräuschpegel handelt, verursachen Sie durch Ihre Bemühungen, das Problem zu beheben, wahrscheinlich neue Probleme, ohne viel zu erreichen.