☰

DNS DDOS Angriff - möchte Protokoll verstehen

tag-icon • tag-icon domain-name-system logging bind
DNS DDOS Angriff - möchte Protokoll verstehen

Im Rahmen eines (weitgehend wirkungslosen) DOOS-Angriffs sehe ich derzeit Protokollmeldungen der Form:

<DATE> client <EXTERNAL-IP>#3074 (<NAME>): query: <SAME-NAME> IN RRSIG + (<ONE-OF-MY-IPs>)

Meine Lektüre des DNS-Protokolls lässt darauf schließen, dass es sich um eine Abfrage von < EXTERNAL-IP > handelt, deren Ergebnis an < ONE-OF-MY-IPs > gesendet werden soll. Ist das richtig?

Wir verwenden ein älteres BIND, das bald aktualisiert wird, aber ich wollte verstehen, was diese Abfrage eigentlich bewirkt (es werden viele gesendet).

Bearbeiten: Außerdem wäre es schön zu wissen, wie sie es strukturieren können, um das Ergebnis an eine andere IP zu senden.

Antwort1

Das Protokollformat für BIND-Abfragen

Haben Sie Alan Cleggs (ISC) verfolgt?Folien zum Thema BIND-Protokollierung? Auf Seite 16 heißt esfalsch:

Die Adresse, an die die Antwort gesendet wird (in Klammern)

Im BIND 9 Administrator Reference Manual steht, dass es sich dabei um die Adresse handelt, an die dasAbfragegesendet wurde, d.h. eineIP-Adresse Ihres DNS-Servers. Die Struktur des Handbuchs ist weder besonders einfach zu lesen noch zu referenzieren, daher hier der vollständige Pfad zur entsprechenden Dokumentation:

  • Aus dem Referenzhandbuch Version 9.14.11,
    • Kapitel 5. BIND 9 Konfigurationsreferenz,
      • Grammatik der Konfigurationsdatei,

Die klarere Formatierung und Hervorhebung stammt von mir:

  1. Der Abfrageprotokolleintrag meldet zunächst eine Clientobjektkennung im @0x<hexadecimal-number>Format.
  2. Als nächstes meldet es die IP-Adresse und Portnummer des Clients und
  3. der Abfragename, die Klasse und der Typ.
  4. Als nächstes berichtet es
  • ob das Flag „Rekursion erwünscht“ gesetzt wurde ( +falls gesetzt, -falls nicht gesetzt),
  • ob die Abfrage signiert war ( S),
  • ob EDNS im Einsatz war und die EDNS-Versionsnummer ( E(#)),
  • ob TCP verwendet wurde ( T),
  • ob DO (DNSSEC Ok) gesetzt wurde ( D),
  • ob CD (Checking Disabled) eingestellt wurde ( C),
  • ob ein gültiger DNS-Server-COOKIE empfangen wurde ( V), und
  • ob eine DNS COOKIE-Option ohne gültiges Server COOKIE vorhanden war ( K).
  1. Anschließend wird die Zieladresse gemeldet, an die die Anfrage gesendet wurde.
  2. Abschließend wird, falls in der Clientabfrage eine CLIENT-SUBNET-Option vorhanden war, diese in eckige Klammern in das Format aufgenommen [ECS address/source/scope].

Also rein:

info: client @0xf00 203.0.113.88#3074 (example.com): query: example.com IN RRSIG + (192.0.2.1)
  • 203.0.113.88#3074ist die IP-Adresse und der Port des Clients
  • example.comist der Abfragename, INdie Klasse und RRSIGder Typ (RFC 4034, 3)
  • +teilt dem Client mit, dass er nach Rekursion gefragt hat
  • 192.0.2.1ist eine IP-Adresse Ihres DNS-Servers, an den die Abfrage gesendet wurde

DNS-Amplification-Angriffe und wie man sie abwehrt

In diesem Protokolleintrag gibt es keine Anzeichen für einen DDoS-Angriffan sich, und die Antwort wird an den Client zurückgesendet 203.0.113.88#3074. Wenn die Client-IP-Adresse gefälscht wurde, dannVerstärkungsangriffliegt darin, dass die Antwort auf eine RRSIGAbfrage viel umfangreicher ist als die ursprüngliche Abfrage.

...der Angreifer veranlasst, dass UDP-DNS-Abfragen an die reflektierenden Resolver gesendet werden, wobei die Quell-IP-Adressen der Abfragen auf die Adresse des Ziels (Opfers) gesetzt werden. Die reflektierenden Server verarbeiten die rekursive Abfrage und senden die Antwort an die IP-Adresse, von der die Abfragen ihrer Meinung nach stammen. Aufgrund des gefälschten Ursprungs werden die Antworten tatsächlich an das Ziel gesendet. - -

Die nicht angeforderten DNS-Antworten werden verworfen, falls/wenn sie den Zielcomputer erreichen. Bis dahin haben sie jedoch bereits Netzwerkressourcen und einen kleinen Teil der CPU-Zeit auf dem Zielcomputer verbraucht.

So können Sie dies je nach Ihrer Situation abmildern:

Kein offener rekursiver Namensdienst

Die autoritativen Nameserver dürfen keinen rekursiven Nameservice anbieten. Diese Anforderung wird geprüft, indem eine Anfrage außerhalb der Zuständigkeit der Autorität mit gesetztem „RD“-Bit gesendet wird.

Handelt es sich hierbei um einerekursivNameserver, beschränken Sie den Zugriff nur auf Ihre eigenen Netzwerke, die diesen Dienst nutzen dürfen. Dies kann entweder mit allow-queryoder erfolgen allow-recursion.

allow-recursion

Gibt an, welche Hosts rekursive Abfragen über diesen Server durchführen dürfen. Wenn allow-recursionnicht gesetzt ist, allow-query-cachewird verwendet, wenn gesetzt, andernfalls allow-querywird verwendet, wenn gesetzt, andernfalls wird die Standardeinstellung ( localnets; localhost;) verwendet.

Damit RRL sich dagegen wehren kann, bearbeiten Sie die globale Option named.confund fügen Sie die folgende Klausel hinzu:rate-limit

options {
         … 
          rate-limit {
              responses-per-second 10;
          };
      };

Dies wird ausführlicher in der offiziellen Dokumentation unteroptionsAnweisungsdefinition und -verwendung:Begrenzung der AntwortrateDort finden Sie

- why and how to use `slip` to truncate responses (done by default with value `2`)
- use `qps-scale` to tighten defenses during attacks.

verwandte Informationen