kb

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste Überarbeitung Beide Seiten der Revision
kb [2012/11/15 14:16]
flacco [DDOS / Amplifier Attacke auf bind]
kb [2012/11/15 14:49]
flacco [Gegenmaßnahmen]
Zeile 208: Zeile 208:
 Noch ein schönes Thema für die Knowledgebase,​ diesmal im Hinblick auf das Thema Rootserver. Noch ein schönes Thema für die Knowledgebase,​ diesmal im Hinblick auf das Thema Rootserver.
  
-Beginnend etwa am 25. Oktober 2012 geriet einer meiner produktiv genutzten Rootserver unter Beschuss. Aufgefallen ist mir das Ganze nur, weil invis-Server meiner Kunden immer schlechter via Internet erreichbar waren. Zunächst ließ mich mein Monitoring-System vermuten, dass es Probleme mit den DSL-Anbindungen bei den Kunden gibt. Es stellte sich aber heraus, dass der DNS-Server der für meine Kunden dynamisches DNS betreibt attackiert wurde und dadurch seinen Dienst nicht mehr zuverlässig erledigen konnte. 
  
 +==== Die Attacke ====
 +Beginnend etwa am 25. Oktober 2012 geriet einer meiner produktiv genutzten Rootserver unter Beschuss. Aufgefallen ist mir das Ganze nur, weil invis-Server meiner Kunden immer schlechter via Internet erreichbar waren. Zunächst ließ mich mein Monitoring-System vermuten, dass es Probleme mit den DSL-Anbindungen bei den Kunden gibt. Es stellte sich aber heraus, dass der DNS-Server der für meine Kunden dynamisches DNS (DDNS -- ist im Root-Server Buch beschrieben) betreibt, attackiert wurde und dadurch seinen Dienst nicht mehr zuverlässig erledigen konnte.
  
 +Im Logfile tauchten massiv immer wieder die gleichen Anfragen auf:
 +
 +<​code>​
 +Nov 15 15:11:02 rs2 named[2637]:​ client 77.xxx.xxx.xxx#​64253 (.): query: . IN ANY +E (178.xx.xx.xx)
 +</​code>​
 +
 +Derartige Anfragen sind unschön. Sie nutzen aus, dass der DNS Server, so er ein offener Resolver ist, auch Anfragen beantwortet,​ die außerhalb seines eigenen Datenbestandes liegen. Im Beispiel werden schlicht alle (ANY) Informationnen zur Rootzone (**.**) erfragt.
 +
 +Eine solche Anfrage erzeugt Antworten die weit größer (bis zum Faktor 60, laut einigen Dokumentationen) sind als die früher üblichen 512 Byte. In den Traffic-Logs des Servers spiegelte sich das deutlich nieder. Während in Zeiten vor dem Angriff auf dem Server eingehend ca. 1 bis 2 GB und ausgehend 2 bis 3 GB pro Tag anfielen, stieg der ausgehende Traffic im Verlauf der Attacke bis auf ca. 25 GB pro Tag an. Der Nameserver (im Einsatz ist bind) stieß an die Grenzen seiner Möglichkeiten und beantwortete reguläre Anfragen nicht mehr zuverlässig.
 +
 +Die Diskrepanz zwischen eingehender und bis zum Faktor 60 höherer ausgehender Datenmenge gibt dieser Form des Angriffs ihren Namen DDOS/​Amplifier (Verstärker).
 +
 +Da eine Anfrage im Rechenzentrum ergeben hat, dass von weiteren Attacken auf andere Server nichts bekannt ist und die Attacke auf meinen Server von immer anderen Hosts ausging, liegt der Schluss nahe, dass es sich um einen gesteuerte, zielgerichteten Angriff handelt (Distributed Denial Of Service Attack / DDOS).
 +
 +Leider sind weder die Gründe dafür noch die Angreifer ohne Weiteres ermittelbar.
 +==== Gegenmaßnahmen ====
 +
 +Für die Abwehr eines solchen Angriffes ergeben sich genau zwei Ansatzpunkte:​
 +
 +  * Der Dienst selbst
 +  * Die Firewall
 +
 +Über die Firewall lassen sich Limits für Anfragen pro Zeit auf bestimmte Ports einrichten. Eine solche Maßnahme ist zwar wirksam um die Gesamtbelastung des Servers zu senken, sie bestraft allerdings auch diejenigen, die einen Dienst regulär nutzen.
 +
 +Reduziert man also die Anfragen auf Port 53/UDP auf 200 pro Sekunde, lässt die Firewall eben nur noch eben diese 200 Anfragen auf den DNS-Server zu, ungeachtet dessen, ob eine Anfrage gut oder böse ist. Schöpft der Angreifer das Limit bereits aus, sind Störungen des regulären Betriebs die Folge. Prinzipiell,​ hat der Angreifer auch auf diese Weise sein Ziel schon erreicht. Der einzig messbare Erfolg dieser Strategie ist die Reduktion des Traffics.
 +
 +Besser ist also die Abwehr am Dienst selbst.
 ===== Postfix, Amavis & Dovecot ===== ===== Postfix, Amavis & Dovecot =====
  
  • kb.txt
  • Zuletzt geändert: 2020/10/20 10:47
  • von flacco