Das Online-Portal für Software-Entwicklungsprojekte Github war am 28. Februar heftigsten DDoS-Angriffen ausgesetzt. Es war der stärkste DDoS-Angriff der Internet-Geschichte. Nie zuvor wurde ein derart massiver Angriff registriert. Dennoch überstand Github die Attacke, nach einigen Stunden war alles vorbei.
Für die Einen ist es ein Versionskontrolldienst, für die Anderen das geilste Sourcecode-Lager der Welt. Github war letzte Woche Mittwoch Woche heftigsten DDoS-Angriffen ausgesetzt. Seit Jahren nutzen Kriminelle DDoS-Angriffe, um Unternehmen gezielt zu schädigen oder zu erpressen. Ihre immense Schlagkraft macht sie zu einer unkalkulierbaren, ernst zu nehmenden Gefahr.
Ein DDoS-Angriff ist eine spezielle Art der Cyber-Kriminalität. Der Distributed-Denial-of-Service (DDoS) ist ein verteilter Denial-of-Service (DoS), der wiederum eine Dienstblockade darstellt. Diese liegt vor, wenn ein angefragter Dienst nicht mehr bzw. nur noch stark eingeschränkt verfügbar ist. Auslöser ist in den meisten Fällen eine Überlastung der IT-Infrastruktur. Angreifer nutzen diese Art der Cyber-Kriminalität, um von ungeschützten Unternehmen Lösegelder zu erpressen.
Während des Angriffes wurden innerhalb weniger Minuten um die 1,3 Terabit Daten pro Sekunde in Richtung Github-Server geschleudert. Doch der Angriff auf Github war anders gelagert als zum Beispiel der große Mirai-Botnet-Schlag von 2016, der mithilfe unzähliger IoT-Geräte etwa die Hälfte der Datenmenge auf die Server eines Sicherheitsdienstes warf. Es handelte sich diesmal nicht um den Angriff eines Zombie-Bot-Netzwerks, das tausende übernommene Einheiten in den Krieg führt.
Stattdessen war es ein Response-Angriff, bei dem unzählige kleinster Anfragen mit verfälschter Absender-IP (in unserem Falle die von Github-Servern) an tausende Server bestimmter Datendienstanbieter, wie Memcached, gesendet wurden. Die Antworten der angefragten Server sind viel datenintensiver als die Mikroanfragen der eigentlichen Täter und legen so das angestrebte Angriffsziel lahm.
Es ist also möglich von einer kleinen Einheit, zum Beispiel einem kleinen PC oder einem mobilen Raspberry Pi mit Tor-Anbindung, über ein beliebiges WLan unzählige kleinste Anfragen an Memcached-Server zu senden, die dann zur Beantwortung ungleich größere Datenmengen auf die Reise schicken und zwar an das eigentliche Ziel, in unserem Falle Github.
Laut dem botfrei blog machen sich die Kriminellen die Tatsache zunutze, dass bei vielen Memcashed-Servern der UDP-Port 11211 für externe Verbindungen verfügbar ist und sie diesen somit von außen kontrollieren können. Jetzt werden mithilfe der übernommenen Memcashed-Server sowohl das Netzwerk als auch die Server belastet. Sowohl im Ziel, als auch auf den Weg dorthin, kann nur noch ein Bruchteil des Datenverkehrs abgewickelt werden.
So kommen eigentlich legitime Anfragen nicht mehr durch oder können nur noch eingeschränkt (also mit extremer Verzögerung) bearbeitet werden. Die Memcashed-Server fungieren also als eine Art Verstärker.
Github selbst spricht von einer Verstärkung von 1 zu 51.000. Das bedeutet, dass für jedes Angriffs-Byte in Richtung Memcached gleich 51 Kilobyte von Memcached auf Github geflogen sind. Die Turmuhr der Saints Peter and Paul Kirche schlug exakt 8.21 Uhr, als der Angriff begann. Unmittelbar nach Angriffsbeginn hörte Github auf, im Internet zu existieren. Es dauerte fünf bis zehn Minuten, dann schaltete Github den Sicherheitsanbieter Akamai ein, der auf solche Angriffe spezialisiert ist. Mit Glockenschlag 17.30 Uhr war Github wieder vollständig verfügbar.
Die Betreiber des Software-Portals gaben an, künftig noch mehr auf derartige Angriffs-Szenarien eingehen zu wollen, um die eigene Infrastruktur besser zu schützen. Offenbar will man auch auf den Einsatz einer künstlichen Intelligenz (KI) setzen, denn der neue Schutz gegen derartige Angriffe soll auch unabhängiger von menschlichen Eingriffen werden. Der Sicherheits-Anbieter Akamai geht davon aus, dass es nur eine Frage der Zeit ist, bis es zu noch stärkeren Memcached-Angriffen kommt. Wer für solch kriminelle Handlungen nicht bestraft werden will, lässt besser die Finger davon.
Quelle; tarnkappe
Für die Einen ist es ein Versionskontrolldienst, für die Anderen das geilste Sourcecode-Lager der Welt. Github war letzte Woche Mittwoch Woche heftigsten DDoS-Angriffen ausgesetzt. Seit Jahren nutzen Kriminelle DDoS-Angriffe, um Unternehmen gezielt zu schädigen oder zu erpressen. Ihre immense Schlagkraft macht sie zu einer unkalkulierbaren, ernst zu nehmenden Gefahr.
Ein DDoS-Angriff ist eine spezielle Art der Cyber-Kriminalität. Der Distributed-Denial-of-Service (DDoS) ist ein verteilter Denial-of-Service (DoS), der wiederum eine Dienstblockade darstellt. Diese liegt vor, wenn ein angefragter Dienst nicht mehr bzw. nur noch stark eingeschränkt verfügbar ist. Auslöser ist in den meisten Fällen eine Überlastung der IT-Infrastruktur. Angreifer nutzen diese Art der Cyber-Kriminalität, um von ungeschützten Unternehmen Lösegelder zu erpressen.
Während des Angriffes wurden innerhalb weniger Minuten um die 1,3 Terabit Daten pro Sekunde in Richtung Github-Server geschleudert. Doch der Angriff auf Github war anders gelagert als zum Beispiel der große Mirai-Botnet-Schlag von 2016, der mithilfe unzähliger IoT-Geräte etwa die Hälfte der Datenmenge auf die Server eines Sicherheitsdienstes warf. Es handelte sich diesmal nicht um den Angriff eines Zombie-Bot-Netzwerks, das tausende übernommene Einheiten in den Krieg führt.
Stattdessen war es ein Response-Angriff, bei dem unzählige kleinster Anfragen mit verfälschter Absender-IP (in unserem Falle die von Github-Servern) an tausende Server bestimmter Datendienstanbieter, wie Memcached, gesendet wurden. Die Antworten der angefragten Server sind viel datenintensiver als die Mikroanfragen der eigentlichen Täter und legen so das angestrebte Angriffsziel lahm.
Es ist also möglich von einer kleinen Einheit, zum Beispiel einem kleinen PC oder einem mobilen Raspberry Pi mit Tor-Anbindung, über ein beliebiges WLan unzählige kleinste Anfragen an Memcached-Server zu senden, die dann zur Beantwortung ungleich größere Datenmengen auf die Reise schicken und zwar an das eigentliche Ziel, in unserem Falle Github.
Laut dem botfrei blog machen sich die Kriminellen die Tatsache zunutze, dass bei vielen Memcashed-Servern der UDP-Port 11211 für externe Verbindungen verfügbar ist und sie diesen somit von außen kontrollieren können. Jetzt werden mithilfe der übernommenen Memcashed-Server sowohl das Netzwerk als auch die Server belastet. Sowohl im Ziel, als auch auf den Weg dorthin, kann nur noch ein Bruchteil des Datenverkehrs abgewickelt werden.
So kommen eigentlich legitime Anfragen nicht mehr durch oder können nur noch eingeschränkt (also mit extremer Verzögerung) bearbeitet werden. Die Memcashed-Server fungieren also als eine Art Verstärker.
Github selbst spricht von einer Verstärkung von 1 zu 51.000. Das bedeutet, dass für jedes Angriffs-Byte in Richtung Memcached gleich 51 Kilobyte von Memcached auf Github geflogen sind. Die Turmuhr der Saints Peter and Paul Kirche schlug exakt 8.21 Uhr, als der Angriff begann. Unmittelbar nach Angriffsbeginn hörte Github auf, im Internet zu existieren. Es dauerte fünf bis zehn Minuten, dann schaltete Github den Sicherheitsanbieter Akamai ein, der auf solche Angriffe spezialisiert ist. Mit Glockenschlag 17.30 Uhr war Github wieder vollständig verfügbar.
Die Betreiber des Software-Portals gaben an, künftig noch mehr auf derartige Angriffs-Szenarien eingehen zu wollen, um die eigene Infrastruktur besser zu schützen. Offenbar will man auch auf den Einsatz einer künstlichen Intelligenz (KI) setzen, denn der neue Schutz gegen derartige Angriffe soll auch unabhängiger von menschlichen Eingriffen werden. Der Sicherheits-Anbieter Akamai geht davon aus, dass es nur eine Frage der Zeit ist, bis es zu noch stärkeren Memcached-Angriffen kommt. Wer für solch kriminelle Handlungen nicht bestraft werden will, lässt besser die Finger davon.
Quelle; tarnkappe
