RFC1918-Adressen aus dem Telekom-Netz
vor 5 Monaten
Hallo zusammen!
Ich bin seit 14.02.2024 bei der Telekom (vorher Vodafone). Ich habe einen Glasfaseranschluss mit 250/50 MBit/s, an dem mittels "Telekom Glasfaser-Modem 2" ein Debian GNU/Linux als Router hängt, der die PPPoE-Einwahl durchführt und Routing (IPv6) bzw. Routing + Source-NAT (IPv4) durchführt.
Ich arbeite seit 24 Jahren im Bereich IT-Sicherheit, habe also durchaus etwas Ahnung von diesem Bereich. Dadurch entwickelt man eine gewisse Paranoia und versucht auch Dinge zu verhindern, die eigentlich gar nicht passieren können.
Daher habe ich in der nftables-Firewall RFC1918-, RFC3927- und RFC6598-Adressen am WAN-Interface des Debian-Routers geDROPt, auch wenn diese ja - bedingt durch ihre Unroutbarkeit im Internet - gar nicht am WAN-Interface auftauchen können. Sollte dies trotzdem passieren, gibt es - zusätzlich zum DROP - einen Logeintrag.
Gestern habe ich festgestellt, dass es alleine seit dem 25.08.2024 - also in den letzten 3 Wochen - 389 Datenpakete gab, die von RFC1918- und RFC3927-Adressen an meinen Router gerichtet waren. Allesamt TCP-Verbindungsversuche, 186 davon an HTTP (80), 178 an HTTPS (443), 14 an SMB (445), sowie geringe Mengen an SSH/Telnet/MSSQL.
Liebe Telekom, das ist Adressspoofing! Dass ihr das bei öffentlichen IP-Adressen nur schwer verhindern könnt, leuchtet mir ein - aber wir reden hier von Adressräumen, die - siehe obige RFCs - NIEMALS im Internet unterwegs sein können, weil sie dort schlicht und ergreifend nicht routingfähig sind. Pakete mit solchen Absenderadressen müssten doch spätestens am ersten Router in Eurem Core-Netz geDROPt werden. Wie kann es sein, dass sowas an meinem Endkundenanschluss aufschlägt?
Danke für eine kurze Erläuterung!
Sven D.
317
10
Das könnte Ihnen auch weiterhelfen
vor einem Jahr
163
0
2
in
212
0
2
vor 5 Jahren
in
403
2
1
in
224
0
3
vor 8 Jahren
37454
1
10
vor 5 Monaten
Hallo @sven_d ,
kann ich für meinen Anschluß so nicht bestätigen.
Ich tippe eher auf eine Fehlkonfiguration deines GNU/Linux Routers und die Pakete stammen allesamt aus deinem internen Netz.
3
Antwort
von
vor 5 Monaten
Aber warum sollte die Telekom den Wachhund geben und die Quelladressen prüfen?
Weil RFC1918 das so vorsieht. Zitat:
Uneingeloggter Nutzer
Antwort
von
vor 5 Monaten
Und wenn Du mal eine neue WAN IP beziehst. Geht es es dann weiter oder ist Ruhe?
1
Antwort
von
vor 5 Monaten
Und wenn Du mal eine neue WAN IP beziehst. Geht es es dann weiter oder ist Ruhe?
Das Verhalten habe ich mit 3 verschiedenen WAN-IPv4-Adressen (2 aus DTAG -DIAL16, 1 aus DTAG -DIAL20) beobachtet.
Danke für Deine Antwort!
Uneingeloggter Nutzer
Antwort
von
vor 5 Monaten
Im RFC Sprech müsste es doch SHALL, MUST oder REQUIRED heißen, wenn der ISP filtern muß (und nicht: "are expected").
Ansonsten habe ich mir gerade mein Firewall Log der letzten zwei Stunden durchgesehen. RFC1918 Traffic sehe ich da nicht.
1
Antwort
von
vor 5 Monaten
Im RFC Sprech müsste es doch SHALL, MUST oder REQUIRED heißen, wenn der ISP filtern muß (und nicht: "are expected").
Guter Punkt, aber: Nein. Nur wenn sich das RFC auf RFC2119 bezieht, muss das so bezeichnet sein. Ansonsten nicht. 🙂
Uneingeloggter Nutzer
Antwort
von
vor 5 Monaten
@Telekom_hilft, könnt Ihr Eure Security-Abteilung hier bitte mit ins Boot holen?
0
Uneingeloggter Nutzer
Antwort
von
vor 5 Monaten
Hallo @sven_d ,
Ich verstehe deine Bedenken hinsichtlich der unerwünschten Pakete und der Tatsache, dass sie von nicht routbaren Adressen stammen. Es ist jedoch wichtig zu beachten, dass wir als Telekom keine Kontrolle über den gesamten Datenverkehr im Internet haben. Adressspoofing ist ein bekanntes Problem, das häufig auftritt und durch verschiedene Quellen verursacht werden kann.
Zusätzlich überprüfen wir in unserem Netzwerk in der Regel nicht die Quell-IP-Adressen, sondern konzentrieren uns auf den Empfänger. Das bedeutet, dass wir möglicherweise nicht in der Lage sind, solche Pakete zu blockieren, bevor sie an deinen Anschluss gelangen.
Freundliche Grüße,
Tamer C.
0
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Antwort
von