Fehlkonfig as a Service: Unzustellbaren Verkehr sinnvoll beantworten

Zusammenfassung

Lutz Donnerhacke leitet im Februar 2026 Kundenverkehr an private IPv4-Adressen, der im Providernetz landet, auf eine eigene Maschine um und schaut nach, was dort ankommt. Statt die Pakete still zu verwerfen, soll diese Maschine so antworten, dass fehlerhafte Geräte Ruhe geben und Nutzer erkennen, was falsch läuft. Unter FreeBSD scheitert die nötige Adressumschreibung, unter Linux gelingt sie mit einer kurzen nftables-Regel.

Warum das Problem existiert

RFC 1918 reserviert 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 für private Netze; im Internet sind diese Ziele nicht erreichbar. Gebraucht gekaufte IoT-Geräte, an VPNs vorbei laufender Firmenverkehr oder alte Konfigurationen schicken trotzdem Pakete dorthin, oft mehrmals pro Sekunde. Den Bereich 100.64.0.0/10 aus RFC 6598 lässt Lutz Donnerhacke bewusst aus, weil der Provider ihn selbst für Endkunden nutzt.

Für DNS gibt es eine verwandte, seit Jahren etablierte Lösung: Die AS112-Server nach RFC 7534 beantworten Rückwärtsanfragen für private Adressbereiche, die sonst die zuständigen autoritativen Server im öffentlichen DNS belasten würden. Der Ansatz von Lutz Donnerhacke überträgt diese Idee auf beliebige Protokolle.

Wie die Linux-Lösung arbeitet

Eine nftables-Regel im prerouting-Hook schreibt alle Pakete an private Ziele per DNAT auf 127.0.0.2 um und merkt sich die Zuordnung; auf dem Rückweg setzt der Kernel die ursprüngliche Adresse als Absender wieder ein. Ohne laufende Dienste antwortet der Kernel selbst: auf Ping mit Echo Reply, auf TCP mit Reset und auf UDP mit Port Unreachable. nftables gibt es ab Linux 3.13.

Ideen

• Viele Geräte hören bei Fehlermeldungen nicht auf, sondern wiederholen hartnäckig.
• Verkehr an private Adressen im Providernetz zeigt verbreitete Fehlkonfigurationen.
• Eine Catch-all-Maschine kann diesen Verkehr gezielt beantworten.
• Antworten müssen scheinbar vom ursprünglich angefragten Ziel stammen.
• Der Kernel beantwortet Ping, TCP und UDP auch ohne eigene Dienste korrekt.
• Managementzugriffe auf die Catch-all-Maschine brauchen eine eigene Filterregel.

Einsichten

• Stilles Verwerfen kann mehr Last erzeugen als eine klare Ablehnung.
• Fehlkonfigurationen beim Kunden werden zum Betriebsproblem des Providers.
• Dieselbe Funktion kann je nach Paketfilter-Implementierung gelingen oder scheitern.

Zitate

• Leider geben sich die meisten Geräte nicht mit Ablehnungen und Fehlermeldungen zufrieden, sondern bestehen auf einer Antwort. (Lutz Donnerhacke)

Fakten

• Beobachtet wurden unter anderem Ping, LDAP, DNS und Zugriffe auf eine Steuerkonsole für PV-Anlagen.
• Die DNAT-Regel zählte im gezeigten Stand 2.598.458 umgeleitete Pakete.
• RFC 6598 reserviert 100.64.0.0/10 als Shared Address Space für Provider.
• RFC 7534 beschreibt AS112-Server für Rückwärtsanfragen zu privaten Adressbereichen.

Referenzen

• Lutz Donnerhacke: Fehlkonfig as a Service
• RFC 1918: private IPv4-Adressbereiche.
• RFC 6598: Shared Address Space 100.64.0.0/10.
• RFC 7534: AS112 Nameserver Operations (2015)
• nftables-Wiki: What is nftables?

Bemerkungen

• In den Kommentaren berichtet Lutz Donnerhacke, dass zumindest die DNS-Anfragen deutlich zurückgingen.

Empfehlungen

• Filtere an der eigenen Netzgrenze ausgehenden Verkehr an RFC-1918-Ziele.
• Werte bei Providern den Verkehr an private Ziele aus, bevor du ihn verwirfst.
• Sichere Catch-all-Systeme mit einer eigenen Regel für Managementzugriffe ab.

Originalartikel lesen →

Im Webarchiv suchen

Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.