8
192.168er Adresse im öffentlichen Netz
Hallo,
eher rein zufällig habe ich in der log-Datei meiner Firewall entdeckt, dass eine 192.168er Adresse von außen über WAN (PPPoE-Verbindung) kommend offensichtlich versucht hat, über Port 22 in mein privates Netzwerk einzudringen (siehe Bild1). Nachdem die Firewall das geblockt hat, bin ich da jetzt nicht soo beunruhigt, möchte aber erwähnen, dass ich kein Experte auf dem Gebiet bin.
Wie ich in den unten verlinkten Beiträgen lesen konnte, müsste mein ISP (Ex-Staatsunternehmen - hoher Preis bei kleinster Datenrate) derartige Adressen eigentlich herausfiltern.
Es ist schon unglaublich, in welcher Intensität mittlerweile auf die Ports 22 oder 23 "geschossen" wird, nicht selten im Sekundentakt (Bsp. siehe Bild2).
Sonnige Grüße
IP Spoofing vom Internet mit privaten IP-Adresse (Fake Adressen)
Routing privater IP-Adressen im öffentlichen Netz
eher rein zufällig habe ich in der log-Datei meiner Firewall entdeckt, dass eine 192.168er Adresse von außen über WAN (PPPoE-Verbindung) kommend offensichtlich versucht hat, über Port 22 in mein privates Netzwerk einzudringen (siehe Bild1). Nachdem die Firewall das geblockt hat, bin ich da jetzt nicht soo beunruhigt, möchte aber erwähnen, dass ich kein Experte auf dem Gebiet bin.
Wie ich in den unten verlinkten Beiträgen lesen konnte, müsste mein ISP (Ex-Staatsunternehmen - hoher Preis bei kleinster Datenrate) derartige Adressen eigentlich herausfiltern.
Es ist schon unglaublich, in welcher Intensität mittlerweile auf die Ports 22 oder 23 "geschossen" wird, nicht selten im Sekundentakt (Bsp. siehe Bild2).
Sonnige Grüße
IP Spoofing vom Internet mit privaten IP-Adresse (Fake Adressen)
Routing privater IP-Adressen im öffentlichen Netz
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 326829
Url: https://administrator.de/contentid/326829
Ausgedruckt am: 23.11.2024 um 02:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
nun, Login Versuche über 22 und 23 kann man ignorieren wenn man die Ports einfach dicht macht.... aber das weist du ....
Die 192.168 Adressen sehe ich als Problem deines Providers.... da macht er entweder Mist... oder er vernwedet für die Kommunikation zwischen seinem Backbone und deinem Route evtl. für irgendwas IPv4 RFC 1918 Adressen. Wenn du allerdings an einem UMTS hängst ist das überhaupt nicht ungewöhnlich.... Da ist die Verwendung von RFC1918 durchaus normal .... IPv4 ist halt ziemlich kanpp inzwischen und IPv6 ist ja sooooo kompliziert... und überhaupt noch nicht ausgereift ....ist ja erst 1998 standardisiert worden... als seit letztem Jahr volljährig....
brammer
nun, Login Versuche über 22 und 23 kann man ignorieren wenn man die Ports einfach dicht macht.... aber das weist du ....
Die 192.168 Adressen sehe ich als Problem deines Providers.... da macht er entweder Mist... oder er vernwedet für die Kommunikation zwischen seinem Backbone und deinem Route evtl. für irgendwas IPv4 RFC 1918 Adressen. Wenn du allerdings an einem UMTS hängst ist das überhaupt nicht ungewöhnlich.... Da ist die Verwendung von RFC1918 durchaus normal .... IPv4 ist halt ziemlich kanpp inzwischen und IPv6 ist ja sooooo kompliziert... und überhaupt noch nicht ausgereift ....ist ja erst 1998 standardisiert worden... als seit letztem Jahr volljährig....
brammer
Hi,
Mein Verdacht: Hair-Pin NAT.
mfg
Cthluhu
Mein Verdacht: Hair-Pin NAT.
mfg
Cthluhu
1Zitat von @brammer:
Hallo,
nun, Login Versuche über 22 und 23 kann man ignorieren wenn man die Ports einfach dicht macht.... aber das weist du ....
...
Hallo,
nun, Login Versuche über 22 und 23 kann man ignorieren wenn man die Ports einfach dicht macht.... aber das weist du ....
...
Vielen Dank für die Infos.
(...) Wenn du allerdings an einem UMTS hängst ist das überhaupt nicht ungewöhnlich....
Hab´ Dorf-DSL (384 kbit/s).Sonnige Grüße
Hi,
musste ich erst mal googeln. Hättest du mir vielleicht ein kurzes Beispiel, wie sich das bei mir evtl. abgespielt haben könnte?
(Die Verbindung zu meinem Provider sieht so aus: PCs --> Switch --> pfsense --> einfaches DSL-Modem Speedport 201 --> Splitter --> ISP)
Sonnige Grüße
musste ich erst mal googeln. Hättest du mir vielleicht ein kurzes Beispiel, wie sich das bei mir evtl. abgespielt haben könnte?
(Die Verbindung zu meinem Provider sieht so aus: PCs --> Switch --> pfsense --> einfaches DSL-Modem Speedport 201 --> Splitter --> ISP)
Sonnige Grüße
Zitat von @visco-c:
Hättest du mir vielleicht ein kurzes Beispiel, wie sich das bei mir evtl. abgespielt haben könnte?
(Die Verbindung zu meinem Provider sieht so aus: PCs --> Switch --> pfsense --> einfaches DSL-Modem Speedport 201 --> Splitter --> ISP)
Fall HairPin NAT auf deiner pfsense aktiviert ist, können die PCs über die WAN IP-Adresse der pfsense auf dahinter genattete Ports zugreifen und der Traffic wird als eingehender Traffic betrachtet.Hättest du mir vielleicht ein kurzes Beispiel, wie sich das bei mir evtl. abgespielt haben könnte?
(Die Verbindung zu meinem Provider sieht so aus: PCs --> Switch --> pfsense --> einfaches DSL-Modem Speedport 201 --> Splitter --> ISP)
Hast du jetzt einen kompromitierten Rechner (Kamera, NAS, Raspberry,...) im eigenen Netz (192.168.*) kann das solchen Traffic (Port 22 wird gerne von Portscannern wie shodan und script-kiddies abgegrast) wie du ihn siehst verursachen.
mfg
Cthluhu
Das kann ich definitiv ausschließen.
So wie ich das jetzt einschätze, wird es eine andere "HairPin NAT Möglichkeit" bezogen auf mein System wohl nicht geben, oder?
Gruß
visco
Hast du jetzt einen kompromitierten Rechner (Kamera, NAS, Raspberry,...) im eigenen Netz (192.168.*) ...
Lässt sich ebenso ausschließen.So wie ich das jetzt einschätze, wird es eine andere "HairPin NAT Möglichkeit" bezogen auf mein System wohl nicht geben, oder?
Gruß
visco
Sowas sehe ich auf unseren IP-Adressen hin und wieder (wenngleich sehr selten) auch.
Das kommt tatsächlich durchs Internet rein und sollte optimalerweise bereits am Ingress-Router verworfen werden.
Ich sehe in unseren Flowdaten pro Tag ca. 1.500 bis 2.000 Pakete mit Source-IP aus RFC1918 bzw. RFC6890, teilweise sogar aus 127.0.0.0/8.
Die Ursachen dafür sind vielfältig, meistens kommen die Pakete wahrscheinlich aus den Netzen von Providern die Carrier-NAT betreiben und bei denen teilweise die Adressübersetzung wegen Konfigurationsfehlern manchmal nicht funktioniert.
Das kommt tatsächlich durchs Internet rein und sollte optimalerweise bereits am Ingress-Router verworfen werden.
Ich sehe in unseren Flowdaten pro Tag ca. 1.500 bis 2.000 Pakete mit Source-IP aus RFC1918 bzw. RFC6890, teilweise sogar aus 127.0.0.0/8.
Die Ursachen dafür sind vielfältig, meistens kommen die Pakete wahrscheinlich aus den Netzen von Providern die Carrier-NAT betreiben und bei denen teilweise die Adressübersetzung wegen Konfigurationsfehlern manchmal nicht funktioniert.
1
Leider ganz nomal. Da wird Datenverkehr nicht ordentlich genattet,
der (remote) ISP hat keine mindest-acl auf der kundenanbindung (ip verify unicast ... wuerde schon viel helfen),
der (lokale) ISP hat auf seinem Transits und Peering keine "RFC"-schmutzfangfilter.
... und oft sind dann acuh die sog. "firewalls" schuld, die nciht allen "internen" traffic natten, den nicht-genatteten traffic jedoch nicht droppen sondern einfach rausrouten; und auf dem abgehenden interface ist nicht mals
ein einfachster Filter "nur meine globalen ip-adressen duerfen SRC sein" implementiert.
Sehe ich leider Tag-fuer-Tag viel zu oft, insb. bei firewalls, die ihren "linux" kern als feature darstellen.
der (remote) ISP hat keine mindest-acl auf der kundenanbindung (ip verify unicast ... wuerde schon viel helfen),
der (lokale) ISP hat auf seinem Transits und Peering keine "RFC"-schmutzfangfilter.
... und oft sind dann acuh die sog. "firewalls" schuld, die nciht allen "internen" traffic natten, den nicht-genatteten traffic jedoch nicht droppen sondern einfach rausrouten; und auf dem abgehenden interface ist nicht mals
ein einfachster Filter "nur meine globalen ip-adressen duerfen SRC sein" implementiert.
Sehe ich leider Tag-fuer-Tag viel zu oft, insb. bei firewalls, die ihren "linux" kern als feature darstellen.
