RIPv6 - Überlisten von IP-Adressen basierenden Sperren

RIPv6

Überlisten von IP-Adressen basierenden Sperren

Michael Schneider
von Michael Schneider
Lesezeit: 8 Minuten

In der IT-Sicherheit herrscht ein kontinuierliches Wettrüsten zwischen Angreifern und Verteidigern. Aufgrund neuer Ideen, Konzepte und Technologien werden auf der einen Seite Verteidigungswälle umgangen und auf der anderen Seite Angriffe erkannt und blockiert. Ein Wechsel von Aktion und Reaktion. Aktionen im Angriff und der Verteidigung erfolgen mehrstufig. So versucht ein Verteidiger beispielsweise Angriffe zu erkennen, diese zu blockieren und weitere Angriffsversuche zu verhindern.

Wir treffen diese Ausgangslage wiederholt in Penetration Tests von Web-Applikationen an. Hier kann die Erkennung eines Angriffs dazu führen, dass die IP-Adresse des Angreifers blockiert wird und neue Verbindungen nicht mehr möglich sind. Ich habe mir diesbezüglich Gedanken gemacht, wie wir auf solche Blockaden reagieren und diese erfolgreich umgehen können. In diesem Artikel stelle ich das Tool RIPv6 Random IPv6 (RIPv6) vor, um restriktive Filter- und Blockierungsregeln basierend auf IP-Adressen zu umgehen.

Ausgangslage: Sperre einer IP-Adresse

Beim Penetration Test einer mir unbekannten Web-Applikation versuche ich herauszufinden, wie diese Applikation aufgebaut ist und wo sich mögliche Angriffsvektoren befinden. Ein Vektor ist ein Eintrittspunkt in der Applikation, wie zum Beispiel Login-Seiten für normale Benutzer oder Administratoren. Um eine Administratorenschnittstelle zu finden, probiere ich unter anderem Pfadnamen wie /admin, /adm/ oder /administrator aus.

Das Ausprobieren von Pfadnamen hinterlässt eine identifizierbare Spur in den Logdateien des Webservers. Jemand, der in schneller Abfolge nach möglicherweise vorhanden Verzeichnissen oder Dateien sucht, generiert eine Vielzahl von Fehlermeldungen wie HTTP 404 Not found. Ein Verteidiger kann nun die Logdateien seines Webservers nach solchen Mustern durchsuchen und entsprechende Aktionen durchführen. In der Regel sieht das so aus, dass die IP-Adresse des identifizierten Angreifers für einen bestimmten Zeitpunkt oder permanent gesperrt wird. Eines der bekanntesten Tools in diesem Bereich ist Fail2ban, welches Logdateien scannt und IP-Adressen basierend auf der Erkennung von verdächtigen Mustern sperrt.

Dies bedeutet für einen Tester, in der Rolle eines Angreifers, dass er idealerweise eine Vielzahl von Systemen oder IP-Adressen zur Verfügung haben sollte, um nicht bereits zu Beginn eines Angriffs von der Web Applikation blockiert zu werden. Der Einsatz eines Botnetzes wäre eine mögliche Lösung für das Problem; aus Gründen der Praktikabilität und juristischen Abhängigkeiten beschränke ich mich aber auf ein einzelnes Test-System. Für das einzelne System sollten dementsprechend viele IP-Adressen zur Verfügung stehen. In der Welt von IPv4 ist dies mittlerweile ein Problem, da es im Zeitalter der IPv4-Adressknappheit nicht mehr ohne weiteres möglich ist, grosse Adressblöcke zu erhalten. Gut für jene, die schon seit langer Zeit über einen grossen IPv4-Adressbereich verfügen. Für den Rest bleibt nur das Ausweichen auf IPv6 übrig.

Ziel: Alle X Sekunden eine neue IP-Adresse

Eines der Ziele beim Design des Protokolls IPv6 war die Adressknappheit von IPv4 zu beseitigen. Dabei wurde der Adressbereich von 32 auf 128 Bit vergrössert. Damit existieren viel mehr Subnetze und Adressen. Momentan ist es so, dass jeder Kunde mit einem IPv6-Internetanschluss, mindestens ein /64 Subnetz zugewiesen erhält. Ein /64 Subnetz enthält 18’446’744’073’709’551’616 mögliche Adressen. Mit einer einfachen Nachfrage stellt ein guter Internet Service Provider (ISP) auch ein /48 Subnetz zur Verfügung. Falls der ISP auch im Jahre 2016 noch kein IPv6 anbietet, können IPv6-Tunneling-Dienste genutzt werden. Damit ist die Anforderung für die Vielzahl von IP-Adressen soweit erfüllt.

Ich habe mich dafür entschieden eine statische Konfiguration der IPv6-Adressen vorzunehmen. Dabei werden die IPv6-Adressen zufällig generiert und mit Bordmitteln des Betriebssystems verwaltet. So kann ich den Zeitpunkt selbst festlegen, wann eine neue IP-Adresse erstellt oder nicht mehr weiter verwendet wird. Zudem fällt die Abhängigkeit zu einem Netzwerkdienst (Router Advertisement oder DHCPv6) weg. Beim Rotieren von IP-Adressen muss zudem das Kommunikationsverhalten zwischen Webserver und Client/Scanner beachtet werden. Bei dem Scan einer Webseite werden Verbindungen zum Webserver aufgebaut: Der Client sendet eine Anfrage, die durch den Webserver beantwortet wird. Wenn in der Zwischenzeit die IP-Adresse gewechselt wird, dann kann es sein, dass die Antwort des Webservers nicht mehr zugestellt werden kann.

Die Lösung dazu ist gleichzeitig mehrere IP-Adressen zu verwenden. Dies wird von IPv6 unterstützt und es ist durch das Protokoll gar vorgesehen, dass ein Netzwerkadapter über mehrere (virtuelle) IPv6-Adressen verfügt. Meine Umsetzung basiert auf dem Rollover-Konzept des Pre-Publish-Modell von DNSSEC-Schlüsseln (ZSK). Die erste IPv6-Adresse IP1 wird generiert und aktiv genutzt. Nach dem Zeitfaktor X wird eine zweite IPv6-Adresse IP2 generiert und sogleich aktiv für neue Verbindungen eingesetzt. Die IP1 fällt in eine Art Stand-By-Status, wird für neue Anfragen nicht mehr verwendet, kann aber noch Antworten entgegennehmen. Mit der Generierung der dritten IPv6-Adresse IP3 erreicht die IP1 den Status Rolled und wird auf dem Netzwerkadapter gelöscht. IP2 fällt in den Status Stand-By und wird dann bei der nächsten Generierung einer IPv6-Adresse ebenfalls gelöscht. Dieser Zyklus läuft endlos. Damit erhält das Test-System neue IP-Adressen und es ist sichergestellt, dass Antworten nicht verloren gehen.

RIPv6

Soweit die Theorie. Die praktische Umsetzung des Tools RIPv6 (Random IPv6) basiert auf einem Bash-Skript. Bei Bedarf ist eine Adaption auf Microsoft PowerShell für Windows Test-Systeme denkbar. Die Software befindet sich in meinen GitHub Repository und ist frei verfügbar.

Eine Voraussetzung für RIPv6 ist ein bereits vorhandener Gateway, der das Routing des IPv6-Netzwerks übernimmt. Der eigene Adressbereich und der erwähnte Gateway werden zurzeit im Skript selbst in der Sektion Variables definiert. Ebenso kann in dieser Sektion der Zeitwert für die Rotation der IP-Adressen festgelegt werden. In einer späteren Version können diese Werte auch über Parameter definiert werden.

Die zufällige Generierung einer IP-Adresse im Netzwerkbereich erfolgt durch die Funktion GenerateAddress(). Im Moment werden Adressen für ein /64 Subnetz generiert. Die Unterstützung für /48 Netze ist geplant. Die ursprüngliche Funktion selbst stammt von Vladislav V. Prodan, wobei ich diese für meine Zwecke angepasst und verkürzt habe.

Für das Rollover-Konzept setzte ich eine Endlos-While-Schleife ein. Die generierte IP-Adresse wird mittels des Befehls ip dem Netzwerkadapter zugewiesen, respektive wieder entfernt. Während des ersten Durchlaufs wird zudem die Default-Route konfiguriert. Dieser Schritt wird nur während des ersten Durchlaufs ausgeführt.

Das Skript kann nun gestartet und im Hintergrund ausgeführt werden. Im Moment wird jeder Vorgang (Hinzufügen und Löschen) per echo ausgegeben. Dadurch kann nachvollzogen werden, welche IP-Adressen gerade im Einsatz ist.

[user@host ~]# ./ripv6.sh
[+] add ip1 2001:470:26:12b:45dc:2314:b631:4c4a
[*] set default route
[+] add ip2 2001:470:26:12b:9a65:b818:6c96:4271
[+] add ip3 2001:470:26:12b:c15e:ec07:400a:56a2
[-] del ip1 2001:470:26:12b:45dc:2314:b631:4c4a
[+] add ip1 2001:470:26:12b:5326:a7c6:7122:d269
[-] del ip2 2001:470:26:12b:9a65:b818:6c96:4271
[+] add ip2 2001:470:26:12b:ef45:b13a:5665:7ae4
[-] del ip3 2001:470:26:12b:c15e:ec07:400a:56a2
[+] add ip3 2001:470:26:12b:9bd6:6e3d:f90f:8a36
[-] del ip1 2001:470:26:12b:5326:a7c6:7122:d269

Es ist keine weitere Anpassung am Test-System notwendig. Der Webscanner oder andere Applikationen können wie gewohnt eingesetzt werden. Der einzige Unterschied ist, dass Anfragen nun mit wechselnden IP-Adressen versendet werden. Damit sollte eine IP-basierende Sperre zukünftig kein Hindernis mehr darstellen – vorausgesetzt die Website ist über IPv6 erreichbar. Die aktuelle GitHub Version entspricht einem Proof of Concept und wird in Zukunft einige Verbesserungen erhalten. Unter anderem ist die Konfiguration per Parameter oder die Unterstützung für /48 Subnetze geplant. Für Feedback, Anpassungen und Erweiterungen bin ich dankbar.

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Haben Sie Interesse an einem Penetration Test?

Unsere Spezialisten kontaktieren Sie gern!

×
Ich möchte ein "Red Teaming"

Ich möchte ein "Red Teaming"

Michael Schneider

Area41 2024

Area41 2024 - Ein Rückblick

Michael Schneider

Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

Einführung von CVSS v4.0

Einführung von CVSS v4.0

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv