Günstiges Internet und leicht-zugängliche Cloud-Technologien haben einen Nachteil: Botnets. Bisher erstellten Cyberkriminelle solche Botnets auf der Grundlage lokaler Server, doch mit der Entwicklung von Cloud-Technologien und IoT ist die Anzahl der Geräte, virtueller Maschinen und der physischen Server — alle potenzielle Elemente von Botnetzen — exponentiell gestiegen. Experten glauben, dass die Entwicklung von Serverlosen Technologien die Entwicklung von Botnets weiter erleichtern wird. So können wir dem entgegenwirken.
Welche Technologien werden von Botnet-Besitzern verwendet?
Zunächst ein bisschen Theorie. Welche Geräte und Technologien können für Angriffe eingesetzt werden? Hier sind ein paar grundlegende Möglichkeiten:
- Physische Server sind für einen Angreifer die lästigste und teuerste Option. Wenn Angreifer jedoch auf physische Server abzielen, reicht es aus, die Infrastruktur zu befallen und dazu zu zwingen, zufällige Ziele im Botnet-Netz anzugreifen, um sie auf verschiedenen Stack-Ebenen zu blockieren.
- Virtuelle Maschinen sind die Lieblingswaffe der Botnet-Besitzer. Cloud-Plattformen werden ständig weiterentwickelt, um virtuelle Maschinen schneller zu erstellen und den Kunden zur Verfügung zu stellen. Das spielt auch den Angreifern in die Hände: Sie haben schnell Zugriff auf einen umfangreichen Bestand preiswerter Ressourcen.
- IoT-Geräte sind ein häufiges Opfer von Botnet-Erstellern. Diese Geräte-Netzwerke, die mit dem Internet of Things verbunden sind (in der Regel Router), können mit Malware infiziert und für Angriffe genutzt werden.
Eine weitere Technologie, die potenziell von Cyberkriminellen genutzt werden kann, ist das Serverless Computing. Mit der Entwicklung von Cloud-Diensten wie Function as a Service (FaaS) wird davon ausgegangen, dass der Botnet-Besitzer überhaupt keine Infrastruktur mehr benötigt, da er in der Lage ist, zustandsfreie Einheiten zu verwenden, die den Code nach einem bestimmten Zeitplan ausführen und dann wieder herunterfahren. In diesem Fall wird bei jedem Auslöser eine neue Instanz der gleichen Funktion erstellt. Zum Glück sind bislang keine Fälle bekannt, in denen Serverless Computing für Botnets eingesetzt wurde, abgesehen von gezielten Experimenten.
Die Herausforderungen für Cloud-Anbieter
Während die bösartige Anwendung von Serverless-Technologien noch eine Theorie ist, sollten wir die traditionelle Infrastruktur — physisch oder virtuell — betrachten. In den allermeisten Fällen befallen die Angreifer solche Infrastrukturen über Massenschwachstellen. Das funktioniert so: Wenn eine Schwachstelle in Routern einer bestimmten Marke oder eines bestimmten Modells entdeckt wird, scannen die Angreifer die Netzwerke und installieren Malware auf vielen Routern, um dann so Angriffe zu starten. Das gilt auch für physische Server und virtuelle Maschinen.
Cyberkriminelle starten einen Bot auf jedem Knoten einer befallenen Infrastruktur. Das kleine Skript führt automatisch die angegebene Funktion aus — einen DDoS-Angriff. Die Anzahl solcher Angriffe steigt von Jahr zu Jahr, das Volumen des eingehenden Traffics nimmt zu, dadurch wird die Belastung des Sicherheitsbereichs immer größer.
Wie sollten sich Cloud-Anbieter angesichts der neuen Bedingungen verhalten? Selbstverständlich könnte man auch einfach die Kapazität der Filterzentren kontinuierlich erhöhen, damit diese das steigende Datenaufkommen bewältigen können. Allerdings führt das zu neuen Schwierigkeiten: Zum einen ist es teuer, zum anderen müssen diese Anlagen regelmäßig gewartet, die Geräte ausgetauscht werden und vieles mehr. Aus diesem Grund versuchen verschiedene Cloud- und Hosting-Anbieter, die bereit sind, bösartigen Traffic zu blockieren und die legitimen Anfragen zu behalten, die Datenlast so weit wie möglich umzuverteilen. Ein CDN ist für so eine Lastverteilung ideal. So funktioniert es.
Wie der Schutz von Gcore funktioniert
Unser Bereinigungszentrum besteht aus drei Ebenen:
- DDOS-Schutz — diese Ebene umfasst Lösungen zum Schutz vor volumetrischen L3/L4-Angriffen.
- Bot-Schutz — diese Ebene umfasst eine Reihe von Algorithmen zur Bereinigung des Traffics, der bereits in den Perimeter eingedrungen ist.
- WAF — eine Firewall zum Schutz von Webanwendungen vor Hackerangriffen und dem Zugriff auf vertrauliche Daten.
Dieses mehrschichtige Sicherheitssystem ermöglicht es uns, alle Anfragen zu analysieren. Wenn das System feststellt, dass es viele Anfragen für eine URL von einer IP Adresse gibt, wird die Sitzung gekennzeichnet und blockiert. Das System reagiert automatisch auf eine übermäßige Anzahl von Anfragen, da es die Durchschnittsbelastung der Ressourcen verfolgt und selbständig die normalen und abnormalen Werte bestimmt. Somit wird legitimer Traffic akzeptiert, aber volumetrische Angriffe wie UDP/ICMP Flood, Amplification, SYN ACK und RST SYN Flood bereits auf der ersten Schutzebene blockiert. Noch interessanter wird die Situation bei einem weiteren Angriffsvektor — HTTP Flood.
Wie HTTP Flood-Schutz funktioniert
Die zweite Ebene des Bereinigungszentrums — der Bot-Schutz — ist für den Schutz vor HTTP Flood zuständig. Bei dieser Art von Angriffen müssen wir vorsichtiger sein, um verdächtige IP-Adressen nicht ohne zusätzliche Prüfung zu blockieren, denn hinter diesen, hinter NAT, befinden sich sowohl Benutzer, deren Computer infiziert sind, als auch seriöse Besucher.
Um das zu verhindern, setzen wir eine mehrstufige Analyse ein:
- Verhaltensanalyse. Überprüfung der Anzahl und Häufigkeit der Anfragen.
- JS Challenge/Captcha. Noch bevor wir entscheiden, dass wir es mit einem Bot zu tun haben, senden wir eine Anfrage zur Verifizierung mittels JS Challenge/Captcha.
Bei der ersten Methode, der JS Challenge, wird ein jаvascript-Code mit einer bestimmten Aufgabe an den Client gesendet. Wenn ein echter Benutzer, anders als ein typischer Bot, einen Browser mit jаvascript-Unterstützung verwendet, besteht er den Test, ohne es überhaupt zu merken, denn er muss keine Ampeln oder Fahrräder markieren.
Die zweite Methode, JS Captcha, ist zwar weniger intelligent, dafür aber umso zuverlässiger. Nach Absolvierung der Herausforderung wird der Client vorübergehend in die Liste der geprüften IPs aufgenommen. Während des Tests erhalten wir Informationen, die für den Bot-Schutz nützlich sind und die wir in Zukunft verwenden können (z.B. die Browserversion).
- Analyse der HTTP Header. Vergleich von Headern und JS Challenge-Ergebnissen.
- TLS Sitzungsanalyse mit JA3-Hash. JA3-Hash ist eine effiziente Methode zum Analysieren einer Sitzung. Jeder Hash umfasst mehrere Werte, die es ermöglichen, den Benutzer zu bestimmen. Da er mit einer speziellen Hash-Funktion erstellt wird, die auf den im TLS Hello-Paket enthaltenen Informationen aufbaut, kann jede Browserversion und jeder Benutzer identifiziert werden, indem der empfangene Hash mit dem Hash in der Datenbank des Filterzentrums verglichen wird.
Wenn die Filterzentrale einen Hash in TLS Hello entdeckt, der nicht in der Datenbank vorhanden oder offensichtlich unberechtigt ist, z.B. wenn ein JA3-Hash von curl mit der Angabe „Internet Explorer“ im Benutzer-Agenten empfangen wird, blockiert die Zentrale diese Anfrage oder leitet eine Prüfung ein.
Diese Tests zeigen deutlich, wie der Bot-Schutz auf hohem Niveau funktioniert. Aber was passiert im Inneren, auf einer niedrigeren Ebene?
Wie eBPF Angriffe auf L3-L4 blockiert
Bei schweren Angriffen wird die Integration mit eBPF aktiviert, die Angriffe auf L3-L4 blockiert. So verringern wir auch das Risiko einer Überlastung des Bereinigungszentrums.
Die Kombination der Analysetechnologien auf niedriger Ebene zusammen mit algorithmischen Methoden auf höchster Ebene verringert die Wahrscheinlichkeit, dass legitimer Traffic blockiert wird, selbst wenn sowohl bösartiger als auch legitimer Traffic von derselben IP-Adresse stammt. Die Anzahl unserer der falsch-positiven Ergebnisse beträgt weniger als 0,01%.
Warum haben wir uns für eBPF entschieden? Da es sich um einen in den Kernel eingebauten Monolithen handelt — im Vergleich zu dem vorher verwendeten (dpdk) lassen sich einige Probleme einfacher lösen, in manchen Fällen können Probleme jetzt vollständig beseitigt werden. Im Gegensatz zu dpdk kann eBPF zum Beispiel auf einer Netzwerkschnittstelle zusammen mit einer anderen Rolle verwendet werden. Aus diesem Grund planen wir, eBPF in Zukunft aktiver auf CDN Knoten einzusetzen, die mit leistungsstarken Intel® Xeon® Scalable-Prozessoren der 3. Generation arbeiten. Gcore verwaltet ein großes Content-Delivery-Netzwerk — die Gesamtkapazität beträgt ungefähr 100 TB Traffic pro Sekunde, aber gleichzeitig wird der Duplex-Kanal für 85% des ausgehenden Traffics genutzt (Kunden, die Inhalte empfangen), der eingehende Kanal nicht ausgelastet ist. Dank der Integration von CDN und eBPF planen wir, diese Kapazitäten mit der Trafficsbereinigung zu verbinden, um so nah wie möglich am Kunden zu sein.
Aktivieren Sie den Schutz vor Bots und anderen Arten von Angriffen
Gcore-Nutzer sind umfassend geschützt: sowohl vor allgemeinen Angriffen wie volumetrischen DDoS-Angriffen, als auch vor maskierten oder mit legitimem Traffic vermischten Angriffen. Das alles, zusammen mit der Möglichkeit, WAF zu integrieren, ermöglicht es unseren Kunden, Angriffsfolgen auf die Netzwerk-, Transport- und Anwendungsebenen des Stacks abzumildern.
