Vielen Dank, dass Sie sich die Zeit genommen haben, dies zu lesen! Wir sind keine Experten für Tor-Netzwerke, aber wir kennen uns aus.
Wenn dir irgendetwas von dem, was hier beschrieben wird, Sinn macht und/oder du einen Verdacht hast, ist jede Art von Feedback sehr willkommen!
1. Was ist hier los?
Unser Dienst lief lange Zeit gut und stabil. Plötzlich traten zunächst leichte, dann schwere Leistungsprobleme auf, und schließlich war unser Dienst gar nicht mehr erreichbar.
Es scheint sich nicht um einen "normalen" DDoS-Angriff zu handeln. Es scheint sich um einen DoS-Angriff zu handeln, aber nicht um etwas Bekanntes, da es sich um einen Angriff auf den Tor-Daemon allein zu handeln scheint. Alle Gegenmaßnahmen, die wir bisher ausprobiert haben, waren nicht erfolgreich. Es ist kein Angriff auf die laufenden Dienste (http, ssh, ftp, mail, etc.) erkennbar, sondern nur auf die Tor-Verbindung selbst.
Trotz intensiver Nachforschungen und Untersuchungen scheint der Vorfall für uns nicht nachvollziehbar zu sein. Dokumentationen über frühere Angriffe auf die versteckten Tor-Dienste sind selten zu finden und passen nicht zu dem, was wir erleben.
Wir weigern uns zu glauben, dass es ein Angriffsszenario gibt, das nicht bekannt ist und dem nicht entgegengewirkt werden kann, da es jeden einzelnen versteckten Tor-Dienst verwundbar machen würde, da die Gegner in der Lage wären, jeden versteckten Tor-Dienst innerhalb von Minuten für eine unbestimmte Zeit offline zu nehmen. Die Auswirkungen auf die Tor-Community wären unermesslich.
Wir hoffen, dass jemand mit dem nötigen Einblick und Fachwissen uns zumindest einen Hinweis geben kann, was genau vor sich geht und uns in die richtige Richtung weist, um eine Lösung zu finden, um diesen Angriff zu beenden oder seine Auswirkungen auf unsere Systeme zu reduzieren und um solche Angriffe in Zukunft zu verhindern. Dies würde dazu beitragen, die versteckten Tor-Dienste auf der ganzen Welt vor zukünftigen Angriffen wie dem aktuellen zu schützen.
2. Wie ist das System aufgebaut?
- Das System läuft auf einem aktuellen und stets aktuellen Linux (amd64) Server
- Der gesamte Datenverkehr wird durch Tor über den Tor-Transport auf Port 9040 geleitet, DNS-Anfragen werden ebenfalls über Tor aufgelöst
- Der Versteckte Dienst von Tor ist v3
- Tor ist Version 0.4.7.8 und läuft mit Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 und Glibc 2.31 als libc
- Tor wurde mit GCC Version 10.2.1 kompiliert. Vanguards 0.3.1 ist ebenfalls installiert.
- Tor läuft als systemd-Dienst
- Vanguards läuft als systemd-Dienst
torrc-Konfiguration:
CookieAuthentifizierung 1
HashedControlPasswort 16:<Hash>
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
Versteckter DienstPort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Was sind die Symptome?
- Weniger als eine Minute nach dem Starten von Tor mit aktiviertem Hidden Service steigt die CPU auf 100%, der Speicher scheint davon nicht betroffen zu sein
- Die genutzte Bandbreite steigt um 100kb/s
- Der Deskriptor des versteckten Dienstes ist unerreichbar
- Das System kann immer noch Clearnet- und Tor-Adressen auflösen
- Das System kann sich immer noch mit ausgehenden Diensten verbinden (z.B. curl zu einer Webseite)
- Das System wird mit eingehenden TCP-Paketen auf dem Loopback-Interface überflutet
- Wenn Tor neu gestartet wird, hört die Flut für ein paar Sekunden auf und beginnt dann wieder.
- Wenn Tor ohne aktivierten Versteckten Dienst gestartet wird, scheint es kein Problem zu geben
- Wenn Tor mit einem zweiten aktivierten versteckten Dienst gestartet wird, bleiben beide Deskriptoren des versteckten Dienstes unerreichbar:
Tor-Browser auf dem primären HS:
Zwiebelseite hat die Verbindung unterbrochen
Die wahrscheinlichste Ursache ist, dass die Onionsite offline ist. Kontaktiere den Administrator der Onionseite.
Details: 0xF2 - Einführung fehlgeschlagen, was bedeutet, dass der Deskriptor gefunden wurde, aber der Dienst nicht mehr mit dem Einführungspunkt verbunden ist. Es ist wahrscheinlich, dass der Dienst seinen Deskriptor geändert hat oder nicht läuft.
oder
Die Verbindung hat eine Zeitüberschreitung
Der Server unter (angegriffener versteckter Dienstdeskriptor).onion braucht zu lange, um zu antworten.
Die Seite könnte vorübergehend nicht verfügbar oder zu stark ausgelastet sein. Versuche es in ein paar Augenblicken noch einmal.
Tor-Browser auf Seconday HS:
Verbindung kann nicht hergestellt werden
Firefox kann keine Verbindung zum Server von (secondary hidden service descriptor).onion herstellen.
Die Seite könnte vorübergehend nicht verfügbar oder zu stark ausgelastet sein. Versuche es in ein paar Augenblicken noch einmal.
- Wenn Tor mit einem zweiten versteckten Dienst gestartet wird, der durch OnionAuthentication geschützt ist, bleibt der primäre Deskriptor des versteckten Dienstes unerreichbar,
der sekundäre (geschützte) Deskriptor des versteckten Dienstes ist erreichbar.
- Wenn Tor nur mit dem zweiten versteckten Dienst gestartet wird (mit oder ohne OnionAuthentication), scheint es kein Problem zu geben
- Wenn Tor mit dem primären versteckten Dienst gestartet wird, der durch OnionAuthentication geschützt ist, ist der Deskriptor des versteckten Dienstes erreichbar
- Wenn er angegriffen wird, erscheinen diese Einträge in der Tor-Logdatei:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (erledigt): Erledigt
Aug 24 19:42:34.000 [notice] Die Geschwindigkeit deiner Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen des Timeouts auf 60000ms nach 18 Timeouts und 388 Aufbauzeiten.
Aug 24 19:42:39.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 240 Erstellungszeiten.
Aug 24 19:42:53.000 [notice] Die Geschwindigkeit der Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 489 Aufbauzeiten.
Aug 24 19:43:11.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 659 Aufbauzeiten.
...
Aug 24 19:46:09.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Aufbau der Verbindung: 122s. Vermutlich Taktsprung. Zweck 14 (Messung der Schaltkreiszeitüberschreitung)
Aug 24 19:46:09.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Schaltungsaufbau: 122s. Vermutlich Zeitsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
Aug 24 19:46:09.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 114 Aufbauzeiten.
Aug 24 19:46:15.000 [notice] Die Geschwindigkeit der Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 125 Aufbauzeiten.
...
Aug 24 19:47:08.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Aufbau der Verbindung: 123s. Vermutlich Taktsprung. Zweck 14 (Zeitüberschreitung der Schaltung messen)
Aug 24 19:47:10.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Schaltungsaufbau: 122s. Vermutlich ein Zeitsprung. Zweck 14 (Messung der Schaltkreiszeitüberschreitung)
Aug 24 19:47:10.000 [notice] Extrem hoher Wert für die Zeitüberschreitung beim Schaltungsaufbau: 123s. Vermutlich ein Zeitsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
Aug 24 19:47:13.000 [notice] Extrem hoher Wert für die Zeitüberschreitung beim Schaltungsaufbau: 123s. Vermutlich Zeitsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
Aug 24 19:47:14.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 495 Aufbauzeiten.
Aug 24 19:47:18.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 124 Aufbauzeiten.
Aug 24 19:47:21.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Aufbau der Verbindung: 122s. Vermutlich Taktsprung. Zweck 14 (Messung der Schaltkreiszeitüberschreitung)
Aug 24 19:47:23.000 [notice] Extrem hoher Wert für die Zeitüberschreitung beim Schaltungsaufbau: 123s. Vermutlich Taktsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
...
Aug 24 19:47:55.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen des Timeouts auf 60000ms nach 18 Timeouts und 1000 Buildtimes.
Aug 24 19:47:59.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 117 Aufbauzeiten.
...
Aug 24 19:52:43.000 [notice] Seltsamer Wert für Schaltungsaufbauzeit: 121581msec. Vermutlich Taktsprung. Zweck 14 (Zeitüberschreitung der Schaltung messen)
Aug 24 19:52:43.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 120000ms nach 18 Zeitüberschreitungen und 57 Aufbauzeiten.
Aug 24 19:52:53.000 [notice] Unterbrechung: Sauberes Beenden.
4. Was wurde versucht, um das Problem zu beheben?
- Wir haben einen komplett neuen Server von Grund auf neu aufgesetzt, auf dem nur das Basis-Betriebssystem sowie tor und vanguards in der Standardkonfiguration laufen, um die Möglichkeit einer Fehlkonfiguration auf unserem betroffenen Server auszuschließen. Sobald tor mit dem angegriffenen Deskriptor gestartet wurde, passierte genau das Gleiche.
- Wir haben versucht, die Last auf unserem Server über OnionBalance in diesem Setup aufzuteilen:
Server1: Führt Onionbalance für den primären Hidden Service Deskriptor aus
Server2/3/4: Führt den versteckten Dienst auf neuen und anderen versteckten Dienst-Deskriptoren aus
- Dadurch wird der ursprüngliche Hidden Service Descriptor nicht wieder zum Leben erweckt
- Die Dienstdeskriptoren auf den Servern 2/3/4 sind erreichbar, wenn sie direkt geöffnet werden, aber nicht über den nun ausgeglichenen primären Deskriptor
- Die CPU auf den Servern 2/3/4 geht auf 100%, solange der Angriff stattfindet, während die CPU auf Server 1 (Balancer) normal bleibt.
- Auch das Hinzufügen von weiteren Backend-Servern zum Balancer hat keinen Unterschied gemacht
- Wir fügten diese Direktiven zum versteckten Dienstblock in torrc hinzu und probierten verschiedene Einstellungen aus:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <getestet mit verschiedenen Werten>
HiddenServiceEnableIntroDoSRatePerSec <getestet mit verschiedenen Werten>
Dies reduzierte die CPU-Last auf den Servern 2/3/4 erheblich, aber der Balanced Service Descriptor bleibt unerreichbar.
- Wir haben versucht, verschiedene Einstellungen in vanguards.conf zu ändern, ohne Erfolg.
- Wir haben versucht, die angreifenden tcp-Pakete zu identifizieren und über iptables zu blockieren, ohne Erfolg.
Unser Fachwissen reicht nicht aus, um aus dem Inhalt der besagten tcp-Pakete, die wie folgt aussehen, Rückschlüsse auf das zu ziehen, was genau passiert:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (falsch -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dies ist mit Tor auf einem einzelnen Server. Wenn es ausgeglichen ist, wird |---------(angegriffener versteckter Dienstdeskriptor)---------| durch die Dienstdeskriptoren der Backends von Server 2/3/4 ersetzt.
Wir können ein größeres tcpdump-Snipplet zur Verfügung stellen, falls nötig.
5. Schlussfolgerungen
Wir denken, dass ein Angreifer die Möglichkeit hat, einen versteckten Dienstdeskriptor (und damit den versteckten Dienst selbst) zu "unterbrechen", indem er den Tor-Daemon mit unzähligen tcp-Paketen überflutet, die ihn auffordern, Schaltkreise aufzubauen. Das verursacht die CPU-Belastung und macht den Hidden Service Descriptor letztendlich unbrauchbar.
Kann dies jemand bestätigen?
Da Direktiven wie die besagten HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec und HiddenServiceEnableIntroDoSRatePerSec dazu gedacht sind, diese Art von Angriffen abzuwehren, so wie es auch die Vorhut tun sollte, können wir uns nicht erklären, warum sie unwirksam bleiben. Vielleicht sind einige sehr spezielle Einstellungen dieser Werte notwendig, um sie wirksam zu machen. Leider sind diese Direktiven (wie auch die Einstellungen in vanguards.config) nur sehr vage beschrieben.
Weiß jemand, wie diese richtig gesetzt werden müssen, um wirksam zu sein?
Zu diesem Zeitpunkt haben wir alle Verweise auf tor und vanguards Konfiguration, die wir online finden konnten, ausgeschöpft.
Auch hier wären wir für jede Hilfe oder Information sehr dankbar! Wir glauben nicht, dass es keine Lösung für dieses Problem gibt.
Wenn dir irgendetwas von dem, was hier beschrieben wird, Sinn macht und/oder du einen Verdacht hast, ist jede Art von Feedback sehr willkommen!
1. Was ist hier los?
Unser Dienst lief lange Zeit gut und stabil. Plötzlich traten zunächst leichte, dann schwere Leistungsprobleme auf, und schließlich war unser Dienst gar nicht mehr erreichbar.
Es scheint sich nicht um einen "normalen" DDoS-Angriff zu handeln. Es scheint sich um einen DoS-Angriff zu handeln, aber nicht um etwas Bekanntes, da es sich um einen Angriff auf den Tor-Daemon allein zu handeln scheint. Alle Gegenmaßnahmen, die wir bisher ausprobiert haben, waren nicht erfolgreich. Es ist kein Angriff auf die laufenden Dienste (http, ssh, ftp, mail, etc.) erkennbar, sondern nur auf die Tor-Verbindung selbst.
Trotz intensiver Nachforschungen und Untersuchungen scheint der Vorfall für uns nicht nachvollziehbar zu sein. Dokumentationen über frühere Angriffe auf die versteckten Tor-Dienste sind selten zu finden und passen nicht zu dem, was wir erleben.
Wir weigern uns zu glauben, dass es ein Angriffsszenario gibt, das nicht bekannt ist und dem nicht entgegengewirkt werden kann, da es jeden einzelnen versteckten Tor-Dienst verwundbar machen würde, da die Gegner in der Lage wären, jeden versteckten Tor-Dienst innerhalb von Minuten für eine unbestimmte Zeit offline zu nehmen. Die Auswirkungen auf die Tor-Community wären unermesslich.
Wir hoffen, dass jemand mit dem nötigen Einblick und Fachwissen uns zumindest einen Hinweis geben kann, was genau vor sich geht und uns in die richtige Richtung weist, um eine Lösung zu finden, um diesen Angriff zu beenden oder seine Auswirkungen auf unsere Systeme zu reduzieren und um solche Angriffe in Zukunft zu verhindern. Dies würde dazu beitragen, die versteckten Tor-Dienste auf der ganzen Welt vor zukünftigen Angriffen wie dem aktuellen zu schützen.
2. Wie ist das System aufgebaut?
- Das System läuft auf einem aktuellen und stets aktuellen Linux (amd64) Server
- Der gesamte Datenverkehr wird durch Tor über den Tor-Transport auf Port 9040 geleitet, DNS-Anfragen werden ebenfalls über Tor aufgelöst
- Der Versteckte Dienst von Tor ist v3
- Tor ist Version 0.4.7.8 und läuft mit Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 und Glibc 2.31 als libc
- Tor wurde mit GCC Version 10.2.1 kompiliert. Vanguards 0.3.1 ist ebenfalls installiert.
- Tor läuft als systemd-Dienst
- Vanguards läuft als systemd-Dienst
torrc-Konfiguration:
CookieAuthentifizierung 1
HashedControlPasswort 16:<Hash>
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
Versteckter DienstPort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Was sind die Symptome?
- Weniger als eine Minute nach dem Starten von Tor mit aktiviertem Hidden Service steigt die CPU auf 100%, der Speicher scheint davon nicht betroffen zu sein
- Die genutzte Bandbreite steigt um 100kb/s
- Der Deskriptor des versteckten Dienstes ist unerreichbar
- Das System kann immer noch Clearnet- und Tor-Adressen auflösen
- Das System kann sich immer noch mit ausgehenden Diensten verbinden (z.B. curl zu einer Webseite)
- Das System wird mit eingehenden TCP-Paketen auf dem Loopback-Interface überflutet
- Wenn Tor neu gestartet wird, hört die Flut für ein paar Sekunden auf und beginnt dann wieder.
- Wenn Tor ohne aktivierten Versteckten Dienst gestartet wird, scheint es kein Problem zu geben
- Wenn Tor mit einem zweiten aktivierten versteckten Dienst gestartet wird, bleiben beide Deskriptoren des versteckten Dienstes unerreichbar:
Tor-Browser auf dem primären HS:
Zwiebelseite hat die Verbindung unterbrochen
Die wahrscheinlichste Ursache ist, dass die Onionsite offline ist. Kontaktiere den Administrator der Onionseite.
Details: 0xF2 - Einführung fehlgeschlagen, was bedeutet, dass der Deskriptor gefunden wurde, aber der Dienst nicht mehr mit dem Einführungspunkt verbunden ist. Es ist wahrscheinlich, dass der Dienst seinen Deskriptor geändert hat oder nicht läuft.
oder
Die Verbindung hat eine Zeitüberschreitung
Der Server unter (angegriffener versteckter Dienstdeskriptor).onion braucht zu lange, um zu antworten.
Die Seite könnte vorübergehend nicht verfügbar oder zu stark ausgelastet sein. Versuche es in ein paar Augenblicken noch einmal.
Tor-Browser auf Seconday HS:
Verbindung kann nicht hergestellt werden
Firefox kann keine Verbindung zum Server von (secondary hidden service descriptor).onion herstellen.
Die Seite könnte vorübergehend nicht verfügbar oder zu stark ausgelastet sein. Versuche es in ein paar Augenblicken noch einmal.
- Wenn Tor mit einem zweiten versteckten Dienst gestartet wird, der durch OnionAuthentication geschützt ist, bleibt der primäre Deskriptor des versteckten Dienstes unerreichbar,
der sekundäre (geschützte) Deskriptor des versteckten Dienstes ist erreichbar.
- Wenn Tor nur mit dem zweiten versteckten Dienst gestartet wird (mit oder ohne OnionAuthentication), scheint es kein Problem zu geben
- Wenn Tor mit dem primären versteckten Dienst gestartet wird, der durch OnionAuthentication geschützt ist, ist der Deskriptor des versteckten Dienstes erreichbar
- Wenn er angegriffen wird, erscheinen diese Einträge in der Tor-Logdatei:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (erledigt): Erledigt
Aug 24 19:42:34.000 [notice] Die Geschwindigkeit deiner Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen des Timeouts auf 60000ms nach 18 Timeouts und 388 Aufbauzeiten.
Aug 24 19:42:39.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 240 Erstellungszeiten.
Aug 24 19:42:53.000 [notice] Die Geschwindigkeit der Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 489 Aufbauzeiten.
Aug 24 19:43:11.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 659 Aufbauzeiten.
...
Aug 24 19:46:09.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Aufbau der Verbindung: 122s. Vermutlich Taktsprung. Zweck 14 (Messung der Schaltkreiszeitüberschreitung)
Aug 24 19:46:09.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Schaltungsaufbau: 122s. Vermutlich Zeitsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
Aug 24 19:46:09.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 114 Aufbauzeiten.
Aug 24 19:46:15.000 [notice] Die Geschwindigkeit der Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 125 Aufbauzeiten.
...
Aug 24 19:47:08.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Aufbau der Verbindung: 123s. Vermutlich Taktsprung. Zweck 14 (Zeitüberschreitung der Schaltung messen)
Aug 24 19:47:10.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Schaltungsaufbau: 122s. Vermutlich ein Zeitsprung. Zweck 14 (Messung der Schaltkreiszeitüberschreitung)
Aug 24 19:47:10.000 [notice] Extrem hoher Wert für die Zeitüberschreitung beim Schaltungsaufbau: 123s. Vermutlich ein Zeitsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
Aug 24 19:47:13.000 [notice] Extrem hoher Wert für die Zeitüberschreitung beim Schaltungsaufbau: 123s. Vermutlich Zeitsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
Aug 24 19:47:14.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 495 Aufbauzeiten.
Aug 24 19:47:18.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 124 Aufbauzeiten.
Aug 24 19:47:21.000 [notice] Extrem großer Wert für die Zeitüberschreitung beim Aufbau der Verbindung: 122s. Vermutlich Taktsprung. Zweck 14 (Messung der Schaltkreiszeitüberschreitung)
Aug 24 19:47:23.000 [notice] Extrem hoher Wert für die Zeitüberschreitung beim Schaltungsaufbau: 123s. Vermutlich Taktsprung. Zweck 14 (Messung der Schaltkreis-Zeitüberschreitung)
...
Aug 24 19:47:55.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen des Timeouts auf 60000ms nach 18 Timeouts und 1000 Buildtimes.
Aug 24 19:47:59.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 60000ms nach 18 Zeitüberschreitungen und 117 Aufbauzeiten.
...
Aug 24 19:52:43.000 [notice] Seltsamer Wert für Schaltungsaufbauzeit: 121581msec. Vermutlich Taktsprung. Zweck 14 (Zeitüberschreitung der Schaltung messen)
Aug 24 19:52:43.000 [notice] Die Geschwindigkeit Ihrer Netzwerkverbindung scheint sich geändert zu haben. Zurücksetzen der Zeitüberschreitung auf 120000ms nach 18 Zeitüberschreitungen und 57 Aufbauzeiten.
Aug 24 19:52:53.000 [notice] Unterbrechung: Sauberes Beenden.
4. Was wurde versucht, um das Problem zu beheben?
- Wir haben einen komplett neuen Server von Grund auf neu aufgesetzt, auf dem nur das Basis-Betriebssystem sowie tor und vanguards in der Standardkonfiguration laufen, um die Möglichkeit einer Fehlkonfiguration auf unserem betroffenen Server auszuschließen. Sobald tor mit dem angegriffenen Deskriptor gestartet wurde, passierte genau das Gleiche.
- Wir haben versucht, die Last auf unserem Server über OnionBalance in diesem Setup aufzuteilen:
Server1: Führt Onionbalance für den primären Hidden Service Deskriptor aus
Server2/3/4: Führt den versteckten Dienst auf neuen und anderen versteckten Dienst-Deskriptoren aus
- Dadurch wird der ursprüngliche Hidden Service Descriptor nicht wieder zum Leben erweckt
- Die Dienstdeskriptoren auf den Servern 2/3/4 sind erreichbar, wenn sie direkt geöffnet werden, aber nicht über den nun ausgeglichenen primären Deskriptor
- Die CPU auf den Servern 2/3/4 geht auf 100%, solange der Angriff stattfindet, während die CPU auf Server 1 (Balancer) normal bleibt.
- Auch das Hinzufügen von weiteren Backend-Servern zum Balancer hat keinen Unterschied gemacht
- Wir fügten diese Direktiven zum versteckten Dienstblock in torrc hinzu und probierten verschiedene Einstellungen aus:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <getestet mit verschiedenen Werten>
HiddenServiceEnableIntroDoSRatePerSec <getestet mit verschiedenen Werten>
Dies reduzierte die CPU-Last auf den Servern 2/3/4 erheblich, aber der Balanced Service Descriptor bleibt unerreichbar.
- Wir haben versucht, verschiedene Einstellungen in vanguards.conf zu ändern, ohne Erfolg.
- Wir haben versucht, die angreifenden tcp-Pakete zu identifizieren und über iptables zu blockieren, ohne Erfolg.
Unser Fachwissen reicht nicht aus, um aus dem Inhalt der besagten tcp-Pakete, die wie folgt aussehen, Rückschlüsse auf das zu ziehen, was genau passiert:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (falsch -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dies ist mit Tor auf einem einzelnen Server. Wenn es ausgeglichen ist, wird |---------(angegriffener versteckter Dienstdeskriptor)---------| durch die Dienstdeskriptoren der Backends von Server 2/3/4 ersetzt.
Wir können ein größeres tcpdump-Snipplet zur Verfügung stellen, falls nötig.
5. Schlussfolgerungen
Wir denken, dass ein Angreifer die Möglichkeit hat, einen versteckten Dienstdeskriptor (und damit den versteckten Dienst selbst) zu "unterbrechen", indem er den Tor-Daemon mit unzähligen tcp-Paketen überflutet, die ihn auffordern, Schaltkreise aufzubauen. Das verursacht die CPU-Belastung und macht den Hidden Service Descriptor letztendlich unbrauchbar.
Kann dies jemand bestätigen?
Da Direktiven wie die besagten HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec und HiddenServiceEnableIntroDoSRatePerSec dazu gedacht sind, diese Art von Angriffen abzuwehren, so wie es auch die Vorhut tun sollte, können wir uns nicht erklären, warum sie unwirksam bleiben. Vielleicht sind einige sehr spezielle Einstellungen dieser Werte notwendig, um sie wirksam zu machen. Leider sind diese Direktiven (wie auch die Einstellungen in vanguards.config) nur sehr vage beschrieben.
Weiß jemand, wie diese richtig gesetzt werden müssen, um wirksam zu sein?
Zu diesem Zeitpunkt haben wir alle Verweise auf tor und vanguards Konfiguration, die wir online finden konnten, ausgeschöpft.
Auch hier wären wir für jede Hilfe oder Information sehr dankbar! Wir glauben nicht, dass es keine Lösung für dieses Problem gibt.
Last edited:
