Dies ist eine kanonische Frage zum Sichern von öffentlichen DNS-Resolvern

Offene DNS-Server scheinen recht ordentlich und praktisch zu sein, da sie IP-Adressen bereitstellen, die wir unabhängig von ihrem Standort unternehmensweit einheitlich verwenden können. Google und OpenDNS bieten diese Funktionalität, aber ich bin nicht sicher, ob diese Unternehmen Zugriff auf unsere DNS-Abfragen haben sollen.

Ich möchte so etwas für unser Unternehmen einrichten, aber ich höre viel darüber, dass dies eine gefährliche Praxis ist (insbesondere in Bezug auf Verstärkungsangriffe ), und ich möchte sicherstellen, dass wir dies richtig machen. Was muss ich beachten, wenn ich eine solche Umgebung aufbaue?

Es gibt ein paar Dinge, die Sie verstehen müssen:

Dies ist ein Netzwerkproblem.

Die meisten Benutzer, die diese Art von Umgebung einrichten möchten, sind Systemadministratoren. Das ist cool, ich bin auch ein Systemadministrator! Ein Teil der Arbeit besteht darin, zu verstehen, wo Ihre Verantwortlichkeiten enden und wo die einer anderen Person beginnt, und glauben Sie mir, dies ist kein Problem, das Systemadministratoren selbst lösen können. Hier ist der Grund:

• UDP ist ein zustandsloses Protokoll. Es erfolgt kein Client-Handshake.
• Abfragen gegen einen DNS-Server sind eine nicht authentifizierte zweistufige Transaktion (Abfrage, Antwort). Es gibt keine Möglichkeit für den Server zu wissen, ob die Quell-IP gefälscht ist, bevor er antwortet.
• Wenn eine Abfrage den Server erreicht hat, ist es bereits zu spät, um ein gefälschtes UDP-Paket zu verhindern. Spoofing kann nur durch eine Methode verhindert werden, die als Eingangsfilterung bekannt ist. Dieses Thema wird in den Dokumenten BCP 38 und BCP 84 behandelt . Diese werden von den Netzwerkgeräten implementiert, die sich vor Ihrem DNS-Server befinden.
• Wir können Ihnen nicht erklären, wie Sie Ihr Rechenzentrum von Anfang bis Ende einrichten oder wie Sie diese Best Practices implementieren. Diese Dinge sind sehr spezifisch für Ihre eigenen Bedürfnisse. Das Q & A-Format funktioniert einfach nicht und diese Seite ist kein Ersatz für die Einstellung von Fachleuten, die professionelle Arbeit leisten sollen.
• Gehen Sie nicht davon aus, dass Ihr milliardenschweres Unternehmen die Ingress-Filterung korrekt implementiert.

Dies ist keine bewährte Methode. Die beste Vorgehensweise ist, dies nicht zu tun.

Es ist sehr einfach, einen DNS-Resolver für das Internet einzurichten. Die Einrichtung eines solchen Systems erfordert weitaus weniger Forschung als das Verständnis der damit verbundenen Risiken. Dies ist einer jener Fälle, in denen gute Absichten versehentlich die Missetaten (und das Leiden) anderer ermöglichen.

• Wenn Ihr DNS-Server auf eine angezeigte Quell-IP-Adresse antwortet, führen Sie einen offenen Resolver aus. Diese werden ständig in verstärkenden Angriffen gegen unschuldige Parteien eingesetzt. Täglich stellen neue Systemadministratoren offene Resolver bereit , sodass es für böswillige Personen lohnenswert ist, ständig nach ihnen zu suchen. Es steht außer Frage, ob Ihr Open Resolver für einen Angriff verwendet wird oder nicht: Ab 2015 ist dies so ziemlich selbstverständlich. Es kann nicht sofort sein, aber es wird sicher passieren.
• Selbst wenn Sie eine ACL mithilfe Ihrer DNS-Software (z. B. BIND) anwenden, beschränkt dies lediglich, auf welche gefälschten DNS-Pakete Ihr Server antwortet. Es ist wichtig zu verstehen, dass Ihre DNS-Infrastruktur nicht nur dazu verwendet werden kann, die Geräte in der ACL anzugreifen, sondern auch alle Netzwerkgeräte zwischen Ihrem DNS-Server und den Geräten, auf die er reagiert. Wenn Sie das Rechenzentrum nicht besitzen, ist dies nicht nur für Sie ein Problem.

Google und OpenDNS tun dies. Warum kann ich das nicht?

Manchmal ist es notwendig, die Begeisterung gegen die Realität abzuwägen. Hier sind einige schwierige Fragen, die Sie sich stellen sollten:

• Wollen Sie das aus einer Laune heraus einrichten oder haben Sie ein paar Millionen Dollar, um es richtig zu machen?

• Haben Sie ein engagiertes Sicherheitsteam? Engagiertes Missbrauchsteam? Haben beide die Zyklen, um mit Missbrauch Ihrer neuen Infrastruktur und Beschwerden von externen Parteien umzugehen?

• Haben Sie ein juristisches Team?

• Wenn all dies gesagt und getan ist, wird sich all diese Anstrengung dann auch nur aus der Ferne bezahlt machen, einen Gewinn für das Unternehmen erzielen oder den Geldwert des Umgangs mit den Unannehmlichkeiten, die Sie in diese Richtung geführt haben, übertreffen?

Abschließend weiß ich, dass dieser Thread Fragen und Antworten für die meisten von Ihnen, die mit ihm verknüpft sind, eine Art Enttäuschung darstellt. Serverfault ist hier, um Antworten zu geben, und die Antwort "Das ist eine schlechte Idee, tu es nicht" wird normalerweise nicht als sehr hilfreich empfunden. Einige Probleme sind weitaus komplizierter als es zunächst scheint, und dies ist eines davon.

Wenn Sie versuchen möchten , dies zu erreichen, können Sie uns dennoch um Hilfe bitten, wenn Sie versuchen, eine solche Lösung zu implementieren. Die Hauptsache ist, dass das Problem an sich zu groß ist, als dass die Antwort in einem praktischen Q & A-Format bereitgestellt werden könnte. Sie müssen bereits viel Zeit in die Erforschung des Themas investiert haben und uns mit spezifischen Logikproblemen ansprechen, auf die Sie während Ihrer Implementierung gestoßen sind. Mit diesen Fragen und Antworten möchten wir Ihnen ein besseres Verständnis für das Gesamtbild vermitteln und Ihnen helfen, zu verstehen, warum wir eine so umfassende Frage nicht beantworten können.

Helfen Sie uns, das Internet sicher zu halten! :)

Unabhängig davon, ob Sie einen offenen DNS-Recursor oder einen autorisierenden DNS-Server ausführen, ist das Problem dasselbe und die meisten möglichen Lösungen sind auch gleich.

Die beste Lösung

DNS-Cookies sind ein vorgeschlagener Standard, der DNS-Servern die Möglichkeit gibt, Clients zum Senden eines Cookies aufzufordern, um nachzuweisen, dass die Client-IP-Adresse nicht gefälscht wurde. Dies kostet eine zusätzliche Hin- und Rückfahrt für die erste Suche. Dies ist der niedrigste Overhead, den eine Lösung bieten kann.

Fallback für ältere Kunden

Da DNS-Cookies noch nicht standardisiert sind, wird es natürlich notwendig sein, ältere Kunden jetzt und in den kommenden Jahren zu unterstützen.

Sie können Limitanforderungen von Clients ohne DNS-Cookie-Unterstützung bewerten. Aber Ratenbeschränkungen erleichtern es einem Angreifer, Ihren DNS-Server zu konfigurieren. Beachten Sie, dass einige DNS-Server eine Ratenbeschränkungsfunktion haben, die nur für autorisierende DNS-Server entwickelt wurde. Da Sie nach einem rekursiven Resolver fragen, sind solche Ratenbegrenzungsimplementierungen möglicherweise nicht auf Sie anwendbar. Das Ratenlimit wird automatisch zum Engpass für Ihren Server, sodass ein Angreifer weniger Datenverkehr senden muss, um legitime Anforderungen zu verwerfen, als dies ohne Ratenlimit der Fall wäre.

Ein Vorteil von Ratenbeschränkungen besteht darin, dass für den Fall, dass ein Angreifer Ihren DNS-Server mit DNS-Anfragen überflutet, mit größerer Wahrscheinlichkeit Kapazität übrig bleibt, die es Ihnen ermöglicht, SSH an den Server zu senden und die Situation zu untersuchen. Darüber hinaus können Ratenbeschränkungen so festgelegt werden, dass hauptsächlich Anforderungen von Client-IPs verworfen werden, die viele Anforderungen senden. Dies kann ausreichen, um Sie vor DoS von Angreifern zu schützen, die keinen Zugriff auf gefälschte Client-IPs haben.

Aus diesen Gründen kann eine Geschwindigkeitsbegrenzung, die etwas unter Ihrer tatsächlichen Kapazität liegt, eine gute Idee sein, auch wenn sie nicht wirklich vor Verstärkung schützt.

TCP verwenden

Sie können einen Client zur Verwendung von TCP zwingen, indem Sie einen Fehlercode senden, der angibt, dass die Antwort für UDP zu groß ist. Dies hat einige Nachteile. Es kostet zwei zusätzliche Hin- und Rückfahrten. Und einige fehlerhafte Clients unterstützen es nicht.

Mit diesem Ansatz können die Kosten für zwei zusätzliche Hin- und Rückflüge auf die erste Anforderung beschränkt werden:

Wenn die Client-IP nicht bestätigt wurde, kann der DNS-Server eine abgeschnittene Antwort senden, um den Client zu zwingen, zu TCP zu wechseln. Die gekürzte Antwort kann so kurz sein wie die Anforderung (oder kürzer, wenn der Client EDNS0 verwendet und die Antwort nicht), wodurch die Verstärkung beseitigt wird.

Jede Client-IP, die einen TCP-Handshake durchführt und eine DNS-Anfrage für die Verbindung sendet, kann vorübergehend auf die Whitelist gesetzt werden. Sobald diese IP-Adresse auf die Whitelist gesetzt wurde, kann sie UDP-Anfragen senden und UDP-Antworten mit bis zu 512 Bytes empfangen (4096 Bytes bei Verwendung von EDNS0). Wenn eine UDP-Antwort eine ICMP-Fehlermeldung auslöst, wird die IP erneut aus der Whitelist entfernt.

Die Methode kann auch mithilfe einer Blacklist umgekehrt werden. Dies bedeutet lediglich, dass Client-IPs standardmäßig über UDP abfragen dürfen. Jede ICMP-Fehlermeldung führt jedoch dazu, dass die IP auf die Blacklist gesetzt wird und eine TCP-Abfrage erforderlich ist, um von der Blacklist gestrichen zu werden.

Eine Bitmap, die alle relevanten IPv4-Adressen abdeckt, könnte in einem Speicher von 444 MB gespeichert werden. IPv6-Adressen müssten auf andere Weise gespeichert werden.

Ich weiß nicht, ob ein DNS-Server diesen Ansatz implementiert hat.

Es wurde auch berichtet, dass einige TCP-Stapel bei Amplifikationsangriffen ausgenutzt werden können. Dies gilt jedoch für jeden TCP-basierten Dienst und nicht nur für DNS. Derartige Sicherheitsanfälligkeiten sollten durch ein Upgrade auf eine Kernelversion verringert werden, bei der der TCP-Stack so repariert wurde, dass als Antwort auf ein SYN-Paket nicht mehr als ein Paket gesendet wird.