☰

Bind: Abfrage (Cache) './ANY/IN' abgelehnt – handelt es sich um einen DDoS-Angriff?

tag-icon • tag-icon domain-name-system bind named-conf
Bind: Abfrage (Cache) './ANY/IN' abgelehnt – handelt es sich um einen DDoS-Angriff?

In meinem Syslog erscheinen Meldungen wie

Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied

und ich weiß nicht, ob dies ein DDoS-Angriff oder nur ein seltsames Verhalten von Bind ist.

Also habe ich ein einfaches Fail2Ban-Jail eingerichtet, das IPs blockiert, die mehr als 20 solcher Fehler in 24 Stunden produzieren. Nach dem Wochenende habe ich nachgeschaut und war erstaunt: Mehr als 1000 IPs wurden blockiert. Darunter auch so bekannte wie 1.1.1.1. Das kann also nicht stimmen.

Mein Server ist ein Debian 9, der über Plesk Obsidian verwaltet wird. Ich habe keine spezielle Konfiguration für bind9/named vorgenommen (soweit ich weiß). Es ist der primäre NS-Server für alle meine Domänen.

Die Frage ist also: Was kann ich tun, um meinen Server vor einer solchen Flut von DNS-Anfragen zu schützen, oder sollte ich sie einfach ignorieren?

Antwort1

Das lässt sich schwer mit Sicherheit sagen, aber auf den ersten Blick sieht es so aus, als könnte es sich um einen versuchten Reflection-Angriff handeln (oder um einen Test, ob Ihr Server für einen solchen Angriff verwendet werden kann).

Die Idee hinter einem solchen Angriff besteht darin, Abfragen über UDP mit einer gefälschten Quell-IP-Adresse an einen offenen Resolver-Server zu senden, um Datenverkehr zum Angriffsziel (dem Host, der tatsächlich über die gefälschte Quell-IP verfügt) zu generieren. Dabei wird eine Abfrage verwendet, von der bekannt ist, dass sie eine große Antwort erzeugt, um eine starke Verstärkung der zum Senden der Abfragen benötigten Bandbreite des Angreifers zu erreichen.

Vorausgesetzt, dies ist der Fall, ergeben sich folgende Implikationen:

  • Sie sind nicht das eigentliche Ziel, sondern sollen lediglich Ihre Bandbreite „leihen“. Die Quelladresse ist die Person, die angeblich angegriffen wird (oder die prüft, ob Ihr Server für solche Zwecke verwendet werden könnte).
  • Es hat nicht wirklich funktioniert. Da Sie diese Anfragen ablehnen, sind die Antworten nicht so umfangreich, wie die eigentliche Antwort . ANYwäre. (Vermutlich, weil Rekursion von vornherein nicht zugelassen wird, was gut ist).

Was Ihr Gefühl angeht, dass es legitim erscheint, weil eine der Quell-IP-Adressen lautet 1.1.1.1, würde ich sagen, dass meine instinktive Reaktion genau das Gegenteil ist. Wenn man 1.1.1.1diese Abfrage als Quelladresse sieht, deutet das sofort darauf hin, dass etwas Seltsames vor sich geht:

  • Wir wissen, dass es 1.1.1.1sich um Anycast handelt, weshalb es keine gute Idee ist, Abfragen von dieser Adresse aus zu initiieren. Wenn Sie auf eine Abfrage von antworten, 1.1.1.1wird Ihre Antwort an die nächstgelegene (im BGP-Sinne) 1.1.1.1Instanz weitergeleitet, nicht an die, die die Abfrage generiert hat.
  • Selbst wenn man die Wahl der Quelladresse außer Acht lässt, warum sollte der öffentliche Resolver von Cloudflare jemals eine Abfrage an Ihren Server senden für . ANY? Sie sind nicht die Autorität für .und sie haben auch keinen Grund, Abfragen an Sie weiterzuleiten.

Das heißt, ich denke, Sie haben Recht, dass diese Abfragen wahrscheinlich „nichts Gutes im Schilde führen“.
Ob es nun eine gute Idee ist, den Verkehr von diesen Adressen zu blockieren, weiß ich nicht so genau. Das Problem dabei ist, dass es einfache DoS-Angriffe ermöglicht. Jemand könnte Ihr Blockierungsverhalten dazu nutzen, Ihren Server dazu zu bringen, nicht mehr auf Abfragen von beliebigen Adressen zu reagieren, was missbraucht werden könnte, um legitimen Verkehr zu blockieren.

verwandte Informationen