Sicherheitstacho der Telekom

Die Telekom betreibt ein kleines Netz mit 97 Knoten aus Honeypots, um nicht angeforderte Pakete und somit netzweite Scans auf Verwundbarkeiten zu entdecken.

Das Ganze gibt es auch mit ansprechender Visualisierung. Interessanterweise ist Deutschland Nummer 3 der angreifenden (nicht angegriffenen) Länder. Das deckt sich mit unserer Erfahrung, dass es schwer ist bestimmte Botnetze einfach IP-mäßig auszubremsen, da wir im deutschen Netz offenbar genügend infizierte Rechner haben, die zu den Angriffen beitragen.

Zur kurzweiligen Unterhaltung auf jeden Fall nicht schlecht.

-> www.sicherheitstacho.eu

Veröffentlicht unter Allgemein | Verschlagwortet mit , | Kommentare deaktiviert für Sicherheitstacho der Telekom

Neue Botnetz-Studie

Die Szene der Botnetz-Betreiber wird immer professioneller und durchkommerzialisiert. So gibt es bereits seit 2012 Online-Shops, die den Zugriff auf infizierte Maschinen je nach Standort zu unterschiedlichen Preisen anbieten. Dancho Danchev hat das in seinem Blogpost zusammengestellt.

-> http://blog.webroot.com/2013/02/28/how-much-does-it-cost-to-buy-10000-u-s-based-malware-infected-hosts/

Veröffentlicht unter Allgemein | Verschlagwortet mit , , | Kommentare deaktiviert für Neue Botnetz-Studie

Schutz des DNS bei DDoS-Angriffen

DNS

In der Welt des DDoS-Schutzes spielt DNS eine essentielle Rolle. Ohne DNS ist keine Website erreichbar, die nicht direkt über die Eingabe einer IP adressierbar wäre. Selbst die wenigsten Administratoren kennen die Adressen ihrer Maschinen auswendig. Ohne DNS also keine Website, kein Verkauf, kein Umsatz.

Wie sichere ich meinen DNS ab?

Erstens, einen eigenen DNS-Server zu betreiben ist unter dem Gesichtspunkt der minimalen Angriffsfläche nicht zu empfehlen. Wie auch schon in einem vorherigen Posting erwähnt, ist die Verteidigung immer nur so stark wie das schwächste Glied der Defensivkette. In der Praxis haben wir es konkret erlebt, dass ein Kunde den HTTP-Layer mit myracloud erfolgreich abgesichert hatte; die Angreifer legten aber binnen weniger Minuten dann die gesamte DNS-Infrastruktur des Hosters lahm. Dabei schützt selbst die Wahl eines renommierten Hosters nicht; bei dem Hoster standen bis zum nächsten Morgen die Telefone nicht still, weil viele große Kunden betroffen waren. Ein einfacher BIND-Server schafft ein paar tausend Anfragen die Sekunde; wieviele Anfragen kann ein begabter Angreifer produzieren? Leicht ein paar Millionen — und zwar jede Sekunde. So ist die Konnektivität der Seite deutlich eingeschränkt bis alle DNS-Caches die neuen myracloud-Nameserver kennen, was beim DeNIC aufgrund der Default-Time-To-Live von einem Tag entsprechend lange dauern kann.

Daraus ergibt sich eine klare und eindeutige Empfehlung zugunsten von Diensten, die hochperformante DNS-Server anbieten. Per Anycast kann DNS außerdem geographisch verteilt werden, so dass der Erstkontakt mit einer Website beschleunigt wird.

Zweitens, DNS-Server und dabei sowohl authoritative wie auch offene Resolver (=alle im Internet sichtbaren) werden nicht selten zu Angriffen auf dritte Parteien genutzt. Durch das Fälschen der Absenderadresse kann ein Angreifer jederzeit so tun als würde das UDP-Paket nicht von ihm selbst, sondern von einer nahezu beliebigen IP-Adresse kommen. Je nach Art der Abfrage kann der Angreifer so einen Lawineneffekt starten, der die meisten Systeme im Internet in der Lage ist zu überrollen. Verstärkt wird das noch durch den Selbst-DoS-Effekt; System A schickt mit gefälschter Absender-Adresse Z ein Paket an B. B antwortet mit größerem Paket an Z. Z kann damit nichts anfangen und schickt das große Paket mit Fehlermeldung an B zurück. So wird zusätzliche Bandbreite bei B verbraucht. Nicht selten meldet sich der Betreiber von Z und beschwert sich bei B über einen „Angriff“, was entsprechend auch zu juristischen Folgen führen kann.

Hier ist unsere Empfehlung: Betreiben Sie keinen Open-Resolver. Wenn Sie einen Open-Resolver betreiben, dann bauen Sie Rate-Limiting ein. Letzteres gilt auch für Server, die nicht rekursiv auflösen, sondern nur Daten einzelner Zonen ausliefern (sogenannte authoritative NS). Wenn nur eine der Zonen einen größeren Datensatz beinhaltet (z.B. viele MX und einen SPF TXT) kann Ihr Server ansonsten direkt als Datenschleuder missbraucht werden. Dabei hilft die Implementierung von Rate Limiting sowie das Aussperren der missbrauchten Abfragetypen, soweit dadurch keine negative Beeinflussung der legitimen Dienste geschieht. Beim Rate Limiting ist darauf zu achten, dass durch gefälschte Absenderadressen kein Speicherlimit erreicht wird.

Unterm Strich gilt aber auch hier: Der mit der größeren Bandbreite gewinnt.

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , | Kommentare deaktiviert für Schutz des DNS bei DDoS-Angriffen

Linux-System-Check

Die Default-Konfiguration nahezu aller Linux-Distributionen ist eher suboptimal für Angriffs-Szenarien vorbereitet. Insbesondere einfache SYN-Floods lösen bestimmte Prozesse im Linux-Kernel aus, die unerwünscht, aber durch überschaubare Konfiguration in den Griff zu bekommen sind.

Es sollte bei allen Maschinen, die aus dem Internet erreichbar sind, folgendes sichergestellt sein:

  • Route-Cache deaktivieren (net.ipv4.rt_cache_rebuild_count=-1)
  • SYN-Cookies aktivieren (net.ipv4.tcp_syncookies=1)
  • RP-Filter aktivieren (net.ipv4.conf.default.rp_filter=1, net.ipv4.conf.all.rp_filter=1)
  • Selbst-DoSen deaktivieren (Output von ICMP-Typ 3 droppen, sowie TCP-SYNs und UDP an nicht offene Ports)
  • Netfilter conntrack deaktivieren oder mit NOTRACK sicherstellen, dass der conntrack-Table nicht überfüllt wird
  • keine extensiven iptables-Regeln verwenden, bei hohen Paketraten führt dies schnell zur Überlastung der CPU, so dass Pakete verloren gehen

Wer diese Tipps befolgt, steigert die Überlebenschancen seiner Systeme schon erheblich. Auf Anwendungsebene insbesondere bei prozess-basierten Webservern wie Apache gibt es einige weitere Angriffsflächen, die wir in den nächsten Artikeln ansprechen werden.

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , , | Kommentare deaktiviert für Linux-System-Check

DDoS-Abwehr: Bandbreite

Bandbreite

Wichtigster Bestandteil bei der Abwehr von Angriffen ist Bandbreite. Wenn ein Angreifer 100 Millionen Datenpakete pro Sekunde senden kann, so nutzt Ihnen das ausgeklügelste System nicht, wenn es nur 10 oder gar 1 Millionen Pakete pro Sekunde (Mpps) verarbeiten kann. Viele Server sind nur mit 100Mbps-Leitungen an das Internet angebunden. Diese können ca. 0,15 Mpps verarbeiten, haben also selbst gegen kleine Angriffe keine Chance. Große Server sind mit 1Gbps-Leitungen am Netz, schaffen aber auch nur ca. 1,5 Mpps im besten Fall. Meistens sind diese Systeme auch noch so konfiguriert, dass sie selbst aktiv zum DoS beitragen. Einmal laufen häufig interne Tabellen über (SYN-Cookies aktivieren), der Linux Route-Cache overflowed (abschalten), es werden ICMP-Typ 3 Meldungen oder TCP-Resets an gefälschte Absenderadressen geschickt, wodurch die so adressierten Maschinen dann zusätzlichen Traffic an die angegriffene Maschine erzeugen. Und das sind nur Themen auf Layer 3 und 4, die bei SYN-Floods und ähnlichen Angriffen auftauchen.

Verteilung auf viele Systeme

Richtig und wichtig ist die Verteilung von Angriffs-Traffic über viele Systeme, um so den möglichen Impact zu reduzieren. Dies kann über Anycast und/oder GeoIP-basierten DNS erfolgen. Darauf zu achten ist, dass auch das schwächste Glied in der Kette dem stärksten Ansturm gewachsen sein muss, sonst ist die Verfügbarkeit des Dienstes gefährdet. Hier ist insbesondere auf die Rolle von DNS hinzuweisen, ohne dass das „Internet“ nicht funktioniert. Die Verwendung von unterdimensionierten Systemen ist dabei höchstgefährlich. Am Besten verwendet man einen Dienstleister, der Anycast DNS beherrscht und dessen Systeme auch Angriffe im über 100Gbit/s-Bereich verkraften.

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , | Kommentare deaktiviert für DDoS-Abwehr: Bandbreite