- Hetzner leitete eine Abuse-Meldung weiter, wonach von
195.201.9.37ein SSH-Portscan ausgegangen sei; auf dem Server fanden sich jedoch keine Hinweise auf bösartige Prozesse, Dateiänderungen oder ungewöhnlichen Traffic - Der mit
tcpdumpbeobachtete tatsächliche Ablauf war nicht, dass der Server Verbindungen zu externen22/tcp-Ports aufbaute, sondern ähnelte eher Backscatter: mehrere Internet-Hosts sendeten TCP RST an den Server zurück - Die zentrale Ursache ist, dass über Netzwerke ohne BCP38-Filterung Pakete mit beliebiger Quell-IP verschickt werden können; bei TCP, QUIC und TLS, die eine Antwort über den Rückweg benötigen, kann der Angreifer die Antworten nicht selbst sehen
- Dasselbe Muster zeigte sich auch auf zwei weiteren Tor-Relays des Autors; auf der
tor-relays-Mailingliste und in einem Issue des Tor Project wurden seit einigen Tagen ähnliche Phänomene gemeldet, wobei einige Nodes zeitweise offline gingen - Ein Angreifer kann die IP des Opfers als Quelle fälschen, Verbindungsversuche an mehrere SSH-Ziele senden und damit automatische Abuse-Meldungen, Blocklisten-Einträge und Maßnahmen von Hosting-Anbietern auslösen
Hetzner-Abuse-Meldung und Serverprüfung
- Hetzner schickte eine AbuseInfo-Mail zur IP
195.201.9.37- Der Meldende war
abuse@watchdogcyberdefense.com - Die Logs enthielten mehrere
DENIED-Einträge zu22/tcpauf verschiedenen Zielen im Bereich202.91.16x.x
- Der Meldende war
- Oberflächlich sah es so aus, als habe der Server begonnen, SSH-Verbindungen ins Internet aufzubauen; normalerweise wäre das ein Fall, in dem man eine Malware-Infektion vermuten würde
- Nach ein bis zwei Stunden Prüfung wirkte der Serverzustand jedoch weitgehend normal
- Keine auffälligen Prozesse
- Keine Änderungen am Dateisystem
- Kein ungewöhnlicher Netzwerkverkehr aus Sicht des Hypervisors
- Auf dem Server liefen mehrere verteilte und föderierte Dienste
- Syncthing-Relay
- Mastodon-Instanz
- Tor-Relay
- Matrix-Homeserver
- Das Tor-Relay verbindet sich zwar mit einigen
22/tcp-Relays, passte aber nicht zu dem meldenden Netzwerk; auch in den Logs von Matrix und Mastodon sowie in der Mastodon-Sidekiq-Queue fanden sich keine Spuren von Anfragen an zufällige IPs oder Ports
Der tatsächliche Paketfluss laut tcpdump
- Zunächst wurde versucht, mit einem Filter auf
dst port 22ausgehenden Traffic vom Server zu externen22/tcp-Ports zu prüfen - Nachdem der Filter auf
not src host 195.201.9.37geändert wurde, waren TCP-RST-Pakete von22/tcpmehrerer externer IPs an temporäre Ports des Servers zu sehen - Tatsächlich hatte nicht der Server Verbindungen zu
22/tcpbeliebiger Hosts gesendet; vielmehr schickten beliebige Internet-Hosts Reset-Pakete an den Server - Dieses Muster passt zu Backscatter, bei dem Antwortpakete wegen gefälschter Quell-IP an die gefälschte IP zurückgehen
Quell-IP-Spoofing und die Lücke bei BCP38
- Im Internet muss die Ziel-IP korrekt sein, aber es ist möglich, Pakete mit gefälschter Quell-IP an mehrere Ziele zu senden
- BCP38 ist die aktuelle Best Practice, nach der Peer-Netzwerke nur erwartete IP-Adressen als Quellen verwenden dürfen
- Diese Filterung muss früh im Paketpfad greifen, um wirksam zu sein
- Auf Ebene großer Transit-Provider ist sinnvolle Filterung schwierig, weil Peers von diesem Provider erwarten, Traffic ins gesamte Internet weiterzuleiten
- Schon ein einziger Transit-Provider ohne BCP38-Umsetzung reicht aus, um Pakete mit beliebigen Quell-IPs zu verschicken
- APNIC veröffentlichte 2023 einen Artikel darüber, warum Source Address Validation weiterhin ein Problem ist
- TCP, QUIC und TLS-Familien benötigen bidirektionale Kommunikation; bei gefälschter Quell-IP kann der Angreifer die Antwort daher nicht sehen
- Für das Auswerten gewöhnlicher Portscan-Ergebnisse ist das ungeeignet
- Bekannte Missbrauchsformen wie Reflection-DDoS existieren jedoch
Warum dieses Spoofing Schaden verursacht
- Der plausibelste Ablauf ist, dass jemand die IP des Autors als Quelle verwendet und Verbindungsversuche an
22/tcpmehrerer Internet-Hosts sendet - Wenn das Ziel ein gewöhnliches Suchen nach offenen Ports wäre, wäre es unlogisch, weil der Spoofer die Antworten nicht sehen kann
- Früher gab es eine Technik namens Idle Scanning, die jedoch auf wenig ausgelastete Server und vorhersagbare Counter im Netzwerk-Stack angewiesen war und seit Jahrzehnten praktisch nicht mehr brauchbar ist
- Das Traffic-Volumen ist zu niedrig und die Dauer zu lang, sodass auch ein falsch eingetragener Quell-IP-Wert in einer Scanner-Konfiguration wenig überzeugend wirkt
- Der tatsächliche Schaden entsteht durch automatisierte Abuse-Meldungen
- Die gespooften Verbindungsversuche erreichen Netzwerke mit Honeypots oder Intrusion-Detection-Systemen
- Einige Systeme verschicken automatisch Abuse-Meldungen
- Hosting-Anbieter können fälschlich annehmen, der betroffene Server sei kompromittiert oder bösartig
Wiederholtes Muster bei anderen Tor-Relays
- Der Autor überprüfte erneut, dass sein Server als Tor-Relay arbeitet
- Ein Tor-Relay ist ein interner Node des Tor-Netzwerks und kommuniziert, sofern es kein Exit-Node ist, nicht direkt mit dem öffentlichen Internet
- Relays leiten verschlüsselten anonymen Traffic zwischen teilnehmenden Nodes im Tor-Netzwerk weiter
- Einige Relays fungieren als Guard Nodes und können Einstiegspunkte ins Tor-Netzwerk sein
- Auf zwei weiteren Relays in unterschiedlichen Ländern und bei unterschiedlichen ISPs wurde ebenfalls
tcpdumpausgeführt- Ein Relay an einem privaten Internetanschluss
- Ein Relay auf einem Linode-VPS in Japan
- Auch auf diesen beiden Relays zeigte sich dasselbe Muster gespoofter TCP-Antworten von externen
22/tcp-Ports an die Relay-IP - Der Autor schrieb an die
tor-relays-Mailingliste, und es gab bereits einen Issue beim Tor Project, der dasselbe Phänomen seit einigen Tagen diagnostizierte - Dieser Spoofing-Angriff begann vor den Relays bei anderen Arten von Nodes, und es gab Fälle, in denen einige Nodes durch gefälschte Verbindungen in größerem Umfang zeitweise offline gingen
Ein Angriffsmuster, bei dem jeder zum Ziel werden kann
- Ein möglicher Angriffsablauf sieht so aus
- Der Angreifer erhält Zugang zu einem Netzwerk ohne BCP38-Filterung
- Er sendet TCP-Verbindungsanfragen an
22/tcpmehrerer beliebiger Internet-Hosts - Als Quell-IP fälscht er die IP des Opfers
- Ziel-Hosts oder Sicherheitssysteme sehen es so, als habe das Opfer die Verbindung versucht, und verschicken Abuse-Meldungen
- Bei ausreichendem Umfang landet die Opfer-IP auf mehreren Blocklisten, und der Hosting-Anbieter kann den Server sperren
- Dieser Angriff enthält nichts Tor-Spezifisches
- Für einen einzelnen motivierten Angreifer wirkt die Durchführung nicht besonders schwierig
- Das Opfer ist nicht der tatsächliche Angreifer, sondern der Besitzer der gefälschten Quell-IP; durch automatisierte Abuse-Meldungen und Reaktionen des Hosting-Anbieters kann es dennoch betrieblichen Schaden erleiden
Ein 2024 weiterhin bestehendes Problem des Internetbetriebs
- Dass gefälschte Quell-IPs auch 2024 noch ein Problem sind, kommt einem Versagen des Internetbetriebs nahe
- Nicht nur BCP38, auch RPKI hatte ähnliche Probleme bei der Verbreitung; erst als große Internetunternehmen begannen, Anforderungen direkt gegenüber ihren Peers durchzusetzen, nahm die Einführung zu
- Die nächsten Schritte gegen diesen Angriff sind unklar
- Er findet bereits real statt
- Der Autor weiß nicht, ob es sich um einen bereits dokumentierten Angriff handelt
- Er kennt keine Möglichkeit, die tatsächliche Quelle der gefälschten IP-Pakete im Nachhinein zurückzuverfolgen
- Betreiber, die ähnliche Abuse-Meldungen erhalten, sollten prüfen, ob ihr Server nicht Täter, sondern Opfer ist, und Belege sammeln, um dies dem Hosting-Anbieter erklären zu können
1 Kommentare
Meinungen auf Hacker News
Diese Art von Problem ist wirklich nervig zu behandeln. Denn die legitime Antwort auf eine Abuse-Meldung – „Jemand hat meine IP gespooft, ich war es nicht, und meine Geräte sind auch nicht kompromittiert“ – ist exakt dieselbe Ausrede, die ein böswilliger Akteur vorbringen würde.
Am Ende muss man, wie im Artikel, gegenüber einer Gegenpartei, die sich kaum dafür interessiert, die Abwesenheit beweisen, was praktisch nahezu unmöglich ist.
Eine automatische Abuse-Meldung zu etwas, das leicht zu spoofen ist, rechtfertigt die Meldung selbst zwar nicht, kann aber ein Grund sein, schnell zu prüfen, ob der eigene Server normal läuft und nicht übernommen wurde.
Mindestens wären Belege zur Identität und zur Gerichtsbarkeit nötig, vielleicht sogar etwas wie ein Videoanruf. Im Internet anonym zu behaupten „Ich bin ein guter Mensch“ und darum zu bitten, einem zu glauben, reicht nicht aus.
Dasselbe gilt für gespoofte MAC-Adressen, E-Mail-Adressen, ARP-Nachrichten, Neighbor Discovery und Man-in-the-Middle-TLS-Zertifikate.
Es ist eigentlich erstaunlich, dass überhaupt noch irgendetwas funktioniert.
Hätte man es so gebaut, dass es perfekt entworfen und betrieben werden muss, wäre es vermutlich sogar ziemlich oft massiv kaputtgegangen. Die Eigenschaft, ein gewisses Maß an Unvollkommenheit zu tolerieren, hat wesentlich zur Robustheit und Nützlichkeit des Internets beigetragen.
Das heißt nicht, dass man nichts verbessern sollte; es ist eher eine Warnung, dass das Streben nach Perfektionismus leicht zu großen Fehlern führen kann, die alles ruinieren.
Früher habe ich auf ähnliche Weise nach DrDoS-Reflection-Servern gescannt. Kein Hosting-Anbieter möchte Portscan-Meldungen bekommen; wenn man also als Quelladresse des Scans die IP eines seriösen, unschuldigen Cloud-Anbieters nimmt, schicken die Reflection-Server ihre UDP-Antworten brav dorthin.
Der Cloud-Anbieter bekommt natürlich eine riesige Menge Beschwerden, aber wenn man sagt, dass von meinem Server keine Scans ausgehen, prüft der Anbieter das und schaltet den Dienst nicht ab. Da der Server, der die gespooften Scan-Pakete sendet, nicht erkannt wird, konnte man das gesamte Internet wiederholt scannen, ohne die üblichen Abuse-Meldeprobleme zu bekommen.
Ich weiß nicht, wie oft das tatsächlich passiert, aber durch Zusammenarbeit mit Transit-Providern und Rückverfolgung über die Hops lässt sich die Quelle gespoofter Pakete ermitteln. Einmal arbeitete JPMorgan mit Cogent zusammen und teilte mit, keine Pakete an ihre IP-Adressen zu senden. Nebenbei: Cogent ist selbst unter Tier-1-Providern des Internets ziemlich tolerant gegenüber Spoofing.
Dass diese Methode gezielt gegen Tor eingesetzt wurde, höre ich zum ersten Mal, und es wirkt etwas kontraintuitiv. Denn die Person, die gespoofte Pakete verschickt, würde ich eher für einen Tor-Unterstützer halten. Wahrscheinlich ist es einfach ein Troll, und zum Glück dürften Anbieter, die Tor hosten, sich darüber nicht allzu sehr aufregen.
Es könnte einfach ein Troll sein, aber es könnte auch jemand sein, der Tor als Hindernis für Überwachungsarbeit sieht und es wie radioaktiven Abfall behandelt wissen will.
Das ist nichts Neues. Vor einigen Jahren habe ich eine sehr einfache Firewall-Regel erstellt: Bei eingehenden TCP-Paketen mit Zielport 22 und SYN=1, ACK=0 wurde die Quell-IP für einen Tag gesperrt.
Dann gab es Beschwerden, dass bestimmte Websites und Dienste nicht funktionierten, und es stellte sich heraus, dass alle paar Tage solche Pakete von IPs populärer Server wie 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram und diversen Chatdiensten eingingen. Natürlich waren das alles gespoofte Pakete, und am Ende musste ich der Firewall-Regel etwas mehr Validierung hinzufügen.
Daher bin ich ziemlich sicher, dass das recht verbreitet ist. Mir ist bewusst, dass ich persönlich ein Sonderfall bin, weil ich mehrere IP-Adressen betreibe, aber ich brauche die Flexibilität, Pakete mit beliebigen meiner Quelladressen über jeden ISP senden zu können. Das ist für mich wichtig, und wenn ein ISP nach Quelladresse filtert, ist das für mich ein Kündigungsgrund und ich wechsle zu einem anderen ISP.
Letzteres fällt eher in die Kategorie „Leertasten-Heizung wieder einschalten“, und ich hoffe, dass ISPs ihre kaputten Netze reparieren.
Ein Unternehmen hostete einige Web-Assets in einer Niederlassung on-premises, die dort eine 1-Gbps-Leitung hatte. In der Zentrale gab es mehrere 10G-Leitungen und ein recht ordentliches Rechenzentrum, also wurden die Web-VMs in die Zentrale verschoben, während die zugewiesenen IP-Adressen, also die öffentlichen statischen IPs von ISP-A, beibehalten wurden. Per VPN wurde bis zur Zentrale geroutet, und der Server sendete Antworten mit ISP-A-Quell-IP über sein Default Gateway über die 10G-Leitung von ISP-B.
So war der Eingang zwar auf 1G begrenzt, der Ausgang konnte aber 10G nutzen. Es waren ohnehin nur GET-Requests. Es war keine optimale Konfiguration, und am Ende wurden die IPs geändert, aber es wirkt wie ein valider Use Case.
Zweitens gab es zwei Leitungen von unterschiedlichen ISPs, eine eigene ASN und ein eigenes /23. Um einen Teil des Traffics zu load-balancen, wurde die Hälfte der IPs über ISP-A und die andere Hälfte über ISP-B geschickt. Das funktionierte gut, aber als man die Balance etwas mischen wollte, trat ein interessantes Problem zutage. Das erste /24 wurde bei ISP-A announced, das zweite /24 bei ISP-B, aber ISP-A hatte RP-Filtering. Deshalb mussten alle IPs auch dort announced werden.
Wegen der Funktionsweise des RP-Filters kann man nichts wie Prepending machen; der gesamte Traffic muss über sie hereinkommen. Wenn für das Präfix eine bessere Route sichtbar ist, wird gefiltert. Monatelang weigerten sie sich, das aus Sicherheitsgründen zu ändern. Da es mit dem Argument Security Best Practice begründet wurde, kann ich den Namen des ISP nennen: Es war Virgin Media.
Zur Einordnung: Die Internetleitung mit rp_filter kostete nicht 20 Dollar im Monat, sondern über 5.000 Dollar im Monat. In der Region gab es keine Alternative, daher konnten wir nicht wechseln; hätte es eine gegeben, wäre klar gewesen, wer den Vertrag verloren hätte.
Die Hypothese „jemand hasst Tor-Relays“ wirkt gemessen am Aufwand wenig überzeugend.
Es könnte sein, dass Akteure, die bösartige Relays betreiben, legitime Relays auf unethische Weise vom Netz drängen wollen, um den Anteil des von ihnen kontrollierten Netzwerks zu erhöhen.
Ein paar BitTorrent-Downloads könnten dafür schon reichen.
Was wäre nötig, damit genügend Netzbetreiber den Traffic aller AS ablehnen, die BCP38 nicht implementieren, sodass Spoofing nicht mehr möglich ist?
Da sie bereits genügend eingehenden Traffic kontrollieren, könnte „Verbindungssicherheit wird überprüft“ tatsächlich Bedeutung bekommen.
Allerdings ist es deutlich einfacher, den Reflexions-Verstärkungsfaktor zu reduzieren. Bei IPv4 kann man nach Reflexionsvektoren scannen und sich bei denen beschweren, die mit dem Zehnfachen der Eingangsbytes antworten.
Es ist ein ähnliches Problem wie Swatting. Es beruht darauf, dass eine befugte Stelle auf Grundlage ungeprüfter Problemhinweise harte Maßnahmen ergreift.
Der Unterschied dürfte sein, dass man statt der direkten Kontaktaufnahme mit der befugten Stelle unbeteiligte Dritte dazu benutzt, Meldungen zu verschicken.
Bei Anfragen, die nur aus einem einzelnen Paket bestehen und keinen Roundtrip haben, sollte ein System meiner Meinung nach keine Abuse-Meldungen automatisch verschicken, solange es sich nicht um Traffic auf DoS-Niveau handelt.
Gerade bei SSH gibt es vor irgendeiner Art von Handshake keine Möglichkeit, das als gültigen Verbindungsversuch zu betrachten.
Mein Hauptserver wurde auch schon einmal wegen einer gefälschten Abuse-Meldung abgeschaltet. Es wurde behauptet, von meiner IP sei ein DoS-Angriff mit über 1 Gbit/s ausgegangen, aber die Leitung meines Servers war auf 400 Mbit/s begrenzt. Hätte ein Mensch die Meldung nur gelesen, wäre klar gewesen, dass das unmöglich ist, und ich hätte mich im Urlaub nicht zwei Tage lang mit dem Telefonsupport herumstreiten müssen.
Das ist die IP-Version von Swatting, Patent-Trolling, dem Anhängen falscher Anschuldigungen an Unschuldige oder DMCA-Takedown-Anträgen, mit denen man Konkurrenten ausschalten will.
Im Kern wird ein Abuse-Abwehrmechanismus als Waffe eingesetzt, um Ziele anzugreifen, die einem nicht passen. Interessant ist, dass eine befugte Stelle zum schwachen Glied wird und aktiv für die Ziele unmoralischer Akteure eingespannt werden kann; völlig neu ist das Phänomen aber nicht.
Nach den Graphen zur Relay-Anzahl und zur „advertised bandwidth“ auf metrics.torproject.org scheint das keinen großen Unterschied gemacht zu haben, interessant ist es aber trotzdem.
Das Schlimmste ist, dass Stellen, die Einschüchterer wie „Watchdog Cyber Defense“, Spamhaus, Shadowserver oder UCEPROTECT nachahmen, Millionen automatischer Meldungen einreichen können, und Hosts praktisch gezwungen sind, darauf zu hören, wenn sie nicht wollen, dass ihre IP-Bereiche auf Blocklisten landen.
Für dieses Problem gibt es keine In-Band-Lösung, aber es könnte Out-of-Band-Lösungen geben.
Zum Beispiel: (1) dem Ziel-ISP mitteilen, dass man Rückverkehr erhält, (2) dieser ISP prüft, woher die Pakete kommen, und informiert den entsprechenden ISP, (3) Schritt 2 wiederholen, bis die Quelle gefunden ist, (4) den betreffenden Netzwerkteil isolieren, bis er korrekt funktioniert.
Am Ende besteht das Internet aus Menschen.