DT prüft meine Ports oder was steckt dahinter?

[Gelöschtes Mitglied 63700]

Ich habe mein Netzwerk hinter einer pfSense, davor ist eine Fritzbox (172.25.0.1), die nur Internet und Telefonie macht (DT AG), wobei kein Telefon oder sonstwas angeschlossen ist außer der pfSense, sondern nur ein Faxgerät, welches ausgeschaltet ist.
Nun sehe ich in der pfSense Verbindungsversuche wie diese hier.

Ist das die Telekom, welche mein Netzwerk "scannt" oder was soll das sein? 10.11.*.* wird von mir nirgends genutzt. Besonders seltsam finde ich die IP-Adresse 192.168.1.8, die aus meinem LAN hinter der pfSense stammen könnte, aber diese IP wird ebenfalls nicht genutzt...
Auf der Fritzbox ist die Autokonfiguration für das Internet aktiv usw. könnte das dafür verantwortlich sein?

 

[underclocker2k4]

Hast du den pfsense als exposted Host drin?

Ansonsten ist es nicht so unüblich, dass die Provider die Ports auf den Routern nach Schwachstellen scannen. Wenn die PF als exposed host in der FB drin ist, dann leitet das Ding halt stumpf die Anfragen weiter, wenn auf dem Port kein Dienst läuft.

So kann dich dein Provider darauf hinweisen, dass bei dir der telnet server offen im Internet hängt. Gepaart mit den default logins, könnte eine solche Situation interessant werden.

 

[passat3233]

10.xxx ist eine private Adresse, wird nicht im Internet genutzt.
Ebenso 192.168.xxx.
Beide Adressbereiche werden auch nicht ins Internet geroutet (außer über ein VPN).
Die Anfragen kommen also definitiv nicht aus dem Internet sondern aus deinem lokalen Netzwerk.

 

[underclocker2k4]

Woran machst du das fest?
Ein carrier grade NAT nutzt auch private IPs, die aus Sicht des Endkunden aus dem Internet aka WAN kommen.

Und warum sollte, auch ohne carrier grade NAT, der Provider keine pirvaten IPs für einen solchen Scan nutzen können?

Also ja, die 10.xx wird nicht im Internet genutzt, das heißt aber nicht, dass sie nicht auf dem WAN-Port (auch an der FB) ankommen können.

 

[hominidae]

...evtl ein VPN mit den Adressen eingerichtet und ein Handy, aus aus dem heimischen WLAN nutzt das noch?

 

[underclocker2k4]

Kannst du auf der PF nen Dump ziehen, sprich nen "wireshark"-Mitschnitt machen? Was steht denn da drin?

 

[ctcn]

Die Ports sehen nach den üblichen Verdächtigen aus ( Netbios/SMB und MSSQL). Die Telekom wird einfach proaktiv die Anschlüsse der Kunden auf die typischen Sicherheitslücken prüfen und betroffene Personen direkt kontakieren.

Eine kurze Suche ergab auch, dass es scheinbar tatsächlich so praktiziert wird.

Finde ich jetzt aus professioneller Sicht auch nicht weiter bedenklich, schließlich tritt die Telekom an erster Stelle (Als abuse contact) wenn etwas von deren IP gewesen sein sollte..

 

[underclocker2k4]

Jo, wenn die da etwas finden, dann generiert das System automatisch ne Benachrichtigungsmail. Ist halt günstiger als sich mit 100en Verfahren wegen irgendwas auseinanderzusetzen.

 

[passat3233]

Die 62.155.240.82 gehört nicht der Telekom, sondern ist vergeben an eine Firma namens CenturyLink Communications in Louisiana/USA.

 

[passat3233]

Seltsam, heute nachmittag wurde CenturyLink von der Ripe-Datenbank ausgeworfen, jetzt wird die DTAG ausgeworfen.
Weshalb habe ich heute nachmittag da einen falschen Eintrag übermittelt bekommen?

 

[Hexcode]

Selbst das BSI scannt übrigens Deutsche IP Ranges und meldet dann sowas wie "hey, du hast da nen RPC Portmapper offen, wenn der da nicht hingehört mach den Mal zu".

 

[Hexcode]

Jep war im falschen Threads gelandet - und ja schon richtig: ging mir nur darum das ich mit vorstellen kann dass sowas gemacht wird. Warum das dann diese IPs sind ist mir jedoch schleierhaft - evtl zeigt die Firewall auch was falsches an, weil eigentlich kennt die DTAG ja dein privaten Ranges gar nicht.

 

[underclocker2k4]

@Hexcode
DTAG kennt auch die privaten IPs nicht, wie sollte sie auch.
Das Ding läuft so:
1. DTAG kennt die WAN-IP der FB.
2. DTAG sagt, its party time.
3. DTAG schickt an die jeweils zu scannenden Ports ein, in dem Fall, TCP sync auf Port XYZ mit der WAN-IP der FB als Ziel.
4. FB bekommt diese Anfrage und prüft zunächst selber, ob es für den Port einen Dienst laufen hat.
5. Hat die FB nix anzubieten, gehts in den Routingstack
6. FB schaut in der forwarding-Liste des PAT nach, wo das Teil hin soll.
7. Kein Eintrag -> drop.
8. ABER. Da der TE einen exposed host eingetragen hat, gibt es keinen drop, sondern default forward auf die PF (172.25.0.2).
8. Und wie sollte es nun auch anders sein, dass bei einem PAT dann die eigentlich dst.IP der FB (WAN-IP) gegen die neue dst.ip (WAN-IP PF) ausgetauscht wird.
9. Die PF bekommt den TCP sync, der ursprünglich an die FB ging, zugestellt, eben auch mit der eigenen IP, sonst wäre das ja witzlos. (andersfalls würde der Stack schon auf L3 das ding wegwerfen, da es kein L3-Interface gibt)

Schaltet der TE den exposed host aus, ist ganz urplötzlich Ruhe, versprochen. (inkl. aller anderen Dienste, ist ja klar).

@*******
Nunma keine Panik, gibt ja auch noch andere Sachen im Leben...
In der pcap steh nix spannendes drin. Die 10. irgendwas will nen TCP sync haben, wie man es halt so kennt. Was passiert, wenn darauf ein sync ack käme, müsste man dann aus probieren. Ich glaube aber, dass der DTAG das schon ausreichen würde, um festzustellen, dass da nen Dienst läuft und eben entsprechend Ruhe wäre.

Wie gesagt, soweit jetzt nichts ultraungewöhnliches.

Was die 192.168.1.8 anbelangt, müsstest du mal im wireshark schauen, ob denn die FB der Absender ist. Dazu kannst du im wireshark schauen, ob die 3C:A6:2F als src.mac-Anfang drinsteht. Dann kommt es von der FB und nicht von innen. (könnte auch nen loopback sein)
Wenn es von der FB kommt, könnte es ursprünglich wirklich von der FB kommen oder aber eben auch von außen, das kann man so ohne weiteres nicht erkennen.
Wenns von außen kommt, halte ich das für etwas schwachsinnig, weil die 192.168.1.0 eine gern genommener interner IP-Bereich ist und der tcp sync dann ja intern weiterläuft oder intern gedropt wird, den Weg also nicht zurück nimmt
Das könnte bei der 10er auch passieren, aber wer benutzt heute noch @home eine solche IP. (früher haben wir das gerne gemacht)

 

[sch4kal]

Die 62.155.240.82 gehört nicht der Telekom, sondern ist vergeben an eine Firma namens CenturyLink Communications in Louisiana/USA.

Vermutlich hat die DTAG vergessen ihre RFC1918 Filter auf den Kopplungen zu Level3 zu aktivieren ist nem Kollegen auch mal bei der Einrichtung eines neuen Borderrouters passiert. Glaubt man gar nicht was für nen scheiss man von großen Netzen bekommt ohne Filter.