So – mittlerweile sind wir dann bei 1,3 Terabit pro Sekunde für einen zünftigen DDoS angelangt, wie Akamai in einem Blogeintrag vom vom 1. März schreibt. Anti DDoS Mitbewerber/Marktbegleiter Link11 war etwas schneller und schrieb schon am 27. Februar von einer Neuen DDoS Angriiffstechnik .Hier war es dann ein bischen weniger - "nur" 296Gbit/s.
Machen wir uns nichts vor – einen DDoS von um die 300Gbit/s bekommt kein mittelständischer ISP weg wenn der angegriffene Service weiter laufen soll. Aber hey – neuartiger Angriff, da kann man natürlich nichts machen. Neuartig? Schauen wir doch mal nach.
Ich glaube der gute alte Smurf war der erste DDoS Angriff dieser Art. Da hat man einen Ping auf eine Broadcast Adresse geschickt und alle Hosts in dem Netz
antworteten dann an die (gespoofte) IP-Adresse des Opfers. Das war zu Zeiten als wir noch kein „full spectrum cyber“ (s. hier ) hatten, Bill Clinton im Weißen Haus nette Sachen gemacht und 34Mbit/s eine dicke ISP-Anbindung war.
Der Smurf war eine dumme, oder besser gesagt arglose Konfiguration des IP-Stacks. Das stammte aus Zeiten, als man nicht davon aus ging dass es Player mit bösen Absichten im Netz gibt. So ungefähr aus der gleichen Zeit stammen dann Dinger wie Chargen DDoS und dergleichen. Für den der's nicht kennt - Chargen ist ein Service den man über das Netz ansprechen kann und der dann einfach endlos den ASCII-Zeichensatz ausliefert. In der Praxis sieht das so aus:
$ telnet localhost chargen
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh
"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi
#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk
%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl
&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn
()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno
)*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnop
*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopq
+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx
23456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy
3456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{
56789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|
6789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
89:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|} !
^]
telnet> quit
Connection closed.
Da das auch über UDP geht, kann hier prima einen DDoS mit machen - ein paar Byte zum Chargen-Server - Megabyteweise Daten zum Opfer.
Das alles war im letzten Jahrtausend. Jetzt sollte man meinen, dass nun - 18 Jahr später - ein paar Lektionen gelernt worden wären. Aber leider ist das nicht so, und Memcached ist da kein Einzelfall. Es ist immer noch so, dass 'Anwendung funktioniert irgendwie' das einzige Kriterium zu sein scheint was zählt.
MongoDB in 2017
... "wurden fast 27.000 Datenbanken erfolgreich gekapert. Demnach gingen 22.500 der Attacken auf das
Konto einer Gruppe mit der E-Mail-Adresse cru3lty@safe-mail.net. Den Hackern geht es ums Geld:
Sie scannen nach öffentlich übers Internet erreichbaren MongoDB-Datenbanken, kopieren sie und löschen den Inhalt.
Dann hinterlassen sie eine Lösegeldforderung samt Bitcoin- und zu kontaktierender E-Mail-Adresse."
Natürlich, das betrifft nur die ignoranten Admins, die Ihre Datenbank offen ungesichert ans Netz gehangen haben. Aber trotzdem stellt sich die Frage, was die Leute die die Mongo Releases machen davon abhält, das Thema so zu behandeln wie z.B. MySQL. MySQL (und auch Maria oder Percona z.B.) nehmen nur Anfragen vom eigenen Rechner (Localhost) entgegen, außer der Admin konfiguriert etwas anderes.
Da kann man natürlich anführen, dass dies erstmal nur den Nutzer dieser Datenbank trifft. Das gilt aber nur so lange, wie niemand einen passenden DDoS Vektor findet.
Noch jemand der zeigt, Wie man es nicht machen sollte, sind die Redis Entwickler. Da steht in der Konfigurationsdatei:
# By default, if no "bind" configuration directive is specified, Redis listens
# for connections from all the network interfaces available on the server.
# It is possible to listen to just one or multiple selected interfaces using
# the "bind" configuration directive, followed by one or more IP addresses.
#
# Examples:
#
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1
Also das exakte Gegenteil von einer sicheren Defaultkonfiguration. Und nein, da kann man sich nicht auf den Standpunkt stellen, wir haben doch in unserem Security Dokument geschrieben:
Redis is designed to be accessed by trusted clients inside trusted environments.
This means that usually it is not a good idea to expose the Redis instance directly
to the internet or, in general, to an environment where untrusted clients
can directly access the Redis TCP port or UNIX socket.
Diese Ansicht der Redis Entwickler hält auch dem Abgleich mit dem echten Leben nicht stand. Nein, die Leute lesen das nicht, die installieren den Kram einfach. An der Konfiguration wird dann etwas gemacht, wenn es zu langsam ist oder wenn es nicht läuft. Hinterher kümmert sich kein Mensch mehr darum. Und das gilt genau so für jede andere Software. Ohne eine sichere Defaultkonfiguration kommt dabei genau so etwas heraus.
Warum schreibe ich das gerade? Ach ja, wir haben ja unseren Zimbra Business-Mail Server im Produktportfolio. Und der nutzt auch einen Memcached. Und da schreibt unser Softwarehersteller dann mal:
https://support.zimbra.com/node/448 "There is an increase in .. attacks".
Und da das dann auch noch über die Vertriebsnewsletter distribuiert wird, gibt es dann von unserer GL noch einen "Task" dazu - "Bitte die Exposition unserer Produkte bezüglich Memcached DDoS prüfen, bewerten und ggf. beheben." Klasse. Die gute Nachricht für unsere Kunden ist, dass wir seit gefühlt ewigen Zeiten alle Zimbra Server so ausliefern, dass nur die Services offen am Netz sind, die es sein sollen - also Mail und Web. Die Frage die sich Zimbra hier stellen sollte ist aber eine andere.
Warum um alles in der Welt ist der vorgeschlagene Fix für Single-Server Installationen:
su - zimbra
/opt/zimbra/bin/zmprov ms `zmhostname` zimbraMemcachedBindAddress 127.0.0.1
/opt/zimbra/bin/zmprov ms `zmhostname` zimbraMemcachedClientServerList 127.0.0.1
nicht einfach der Default?
Der einzige Grund, warum der memcached hier auf was anderem als 127.0.0.1 hören sollte ist eine Mulit-Server Installation. Ich denke, ich hänge mich nicht zu weit aus dem Fenster wenn ich behaupte, dass über 90% aller Zimbra Installationen Single-Server Installationen sind. Die Leute die eine Multi-Server Installation machen, werden sowieso mehr Planung machen müssen und mehr Dokumentationen lesen. Die können das ohne Probleme anpassen. Und für alle anderen kann es doch per Default sicher sein, oder?
Wenn ein OpenSource Projekt wie Redis, Mongo oder Memcached das verkackt, ist das dumm. Wenn ein Anwender das verkackt und anschließend seine MongoDB Daten beim Erpresser wiederfindet oder seine Server sich fröhlich an einem DDoS beteiligen ist das zum Heulen, vor allem dann wenn es unbeteiligte Dritte trifft (wie die DDoS Opfer oder die Leute deren Daten in der MongoDB gelagert waren). Dass aber ISVs wie Zimbra ein Produkt für das Geld bezahlt wird so ausliefern ist eigentlich unentschuldbar.
Was ist so schlimm daran, jetzt einen Hotfix zu machen, der für Single-Server Installationen genau dies nachzieht? Warum kann man nach einer Multi-Server Installation nicht einen Infotext generieren, der die benötigte Firewallkonfiguration darlegt, damit das Produkt läuft?
Zum guten Schluß möchte ich noch auf das Thema "neuer Angriff" abgehen. DDoS mit Amplification sind so neu nicht, dass hatten wir ja oben schon mit der Rückblende auf die Internetbronzezeit mit Smurf, Fraggle, Chargen usw. Das BSI schickt uns als ISP seit mehreren Jahren Warnhinweise über Systeme in unserem Netzbereich die unsicher konfiguriert sind. Diese Hinweise dürfte jeder ISP in Deutschland bekommen. Da gab es Warnungen zu offenen DNS-Servern, NTP-Servern, C&C-Server von irgendwelchen Botnets und was weiss ich noch alles. Wir arbeiten das alles brav ab, reden mit den Kunden und meistens ist so etwas in kurzer Zeit erledgt. Ich habe gerade unser Ticketsystem befragt. Die älteste Mail in der vor offenen Memcached Server gewarnt wird die für DDoS benutzt werden ist aus 2015. Das das nicht nur bei uns aufgeschlagen ist, sondern auch bei anderen ISPs sieht man z.B. hier:
http://www.blogler.de/bsi-versendet-abuse-melungen-fuer-offene-memcached-server/
In den Köpfen der Entwickler muss endlich ankommen, dass eine per Default sichere Konfiguration eine Pflicht ist. Gleiches gilt für Softwareanbieter, gerade wenn sie Opensource Projekte nutzen die noch eine per Default unsichere Konfiguration haben.
Webentwickler müssen begreifen, dass ein Projekt nicht nur 'wir machen das mal fertig' ist, sondern dass die langfristige Betreuung gewährleistet sein muss. Wenn dem so wäre, gäbe es heute nicht tausende ungepatchte Typo3, Joomla und was weiß ich noch Versionen am Netz, die dann noch unsicher konfigurierte Komponenten wie Redis und Memcached verwenden und damit Leuten die dafür überhaupt nichts können, den Tag versauen bzw. das Geschäft kaputt machen.
Schlußendlich müssen die Anwender in die Verantwortung genommen werden. Es muß klar sein, dass man dafür zu sorgen hat, dass sein Webserver/Mailserver/Plattform sicher konfiguriert sein muss und die Software dort aktuell gehalten werden muss.