pbreak2001
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
Hoffe dies ist das richtige Forum. Beim anpingen von einer IP vom Bereich 192.168.X.X antwortet ein Rechner der deutschen Telekom. Nur und ausschließlich bei einer einzigen IP in diesem Bereich. Der Hostname lautet p3e9bf678.dip0.t-ipconnect.de. Es wurde keinerlei Route o.ä. hier festgelegt. Hintergrund dieser Feststellung war ein Eintrag in meinem Googlekonto bzw in dessen Passwortmanager. Dieser Eintrag stammte nicht von mir. Dort war auch ein Benutzername und Passwort hinterlegt. Was könnte dort für ein Schindluder getrieben worden sein? Danke für Antworten.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Private IP-Adressen (192.168.x.x gehört dazu) brauchst du in der Regel nicht anonymisieren. Eine ungeeignete Anonymisierung führt oftmals dazu, dass wichtige Details zur Beantwortung der Frage verloren gehen. Anders sieht es mit dem Hostnamen aus: Mit dem kann nach meinem Kenntnisstand zumindest zeitweise ein Internetanschluss identifiziert werden. Hast du schon überprüft, ob eines deiner anderen Geräte im Netzwerk (einschließlich deines Routers) diese IP-Adresse benutzt? Wenn du einen DHCP-Server betreibst (z.B. den im Internetrouter integrierten), kannst du dort nachschauen, ob er diese IP-Adresse vergeben hat. In der Regel findest du dann auch die MAC-Adresse des Geräts heraus und kannst somit z.B. den Hersteller bestimmen. Dafür gibt es mittlerweile einige Webseiten - z.B. das Wireshark - OUI Lookup Tool. Falls du das nicht im DHCP-Server/Router sehen kannst, ping die Adresse nochmal an und benutze dann
oder
wenn die net-tools nicht installiert sind. Da die Adresszuordnung im ARP-Cache nach ein paar Sekunden (normalerweise 30 davon) entfernt wird, musst du also erst irgendwie Netzwerkverkehr zur Ziel-IP verursachen - und das geht mit ping in der Regel ausreichend gut. Mit diesen Informationen bewaffnet kannst du dann auf die Suche nach einem Gerät gehen im Einzugsbereich deines lokalen Netzwerks gehen. Und wenn du sonst nichts herausfindest, besteht die Möglichkeit, dass sich jemand in deinem WLAN eingenistet hat. Kannst du denn aus dem Benutzernamen nichts schließen? Ist das einer, den du benutzen würdest? Hast du vielleicht mal jemanden an deinen Rechner gelassen, der sich versehentlich mit seinen Anmeldedaten in deinem Passwortmanager verewigt hat?
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
Danke dir für die ausführliche Antwort. Wollte da nichts anonymisieren, sorry. die genaue interne IP lautet 192.168.176.1. Das interne Netz hat aber eine ganz andere Range. Macht die Sache irgendwie total verdächtig. Router habe ich gecheckt, es gibt keinen Eintrag irgendwo, der auf die genannte oder externe IP hindeutet. Habe diesen Eintrag mit den Passwörtern natürlich gelöscht und den Zugang zu Google geändert.
Keines meiner Zugangsdaten oder welche, die ich verwenden würde. Nutzer und Passwort jeweils 6stellige Zahlenfolge. Leider steht/stand da auch nicht, wann der Eintrag gemacht wurde. Ist der externe denn eine "Dial up" IP oder könnte das auch eine Feste für einen Server sein? Kommt seit 3 Tagen die gleiche Antwort von der gleichen IP (beim pingen).
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
pbreak2001 schrieb: Ist der externe denn eine "Dial up" IP oder könnte das auch eine Feste für einen Server sein? Kommt seit 3 Tagen die gleiche Antwort von der gleichen IP (beim pingen).
Wie sind die Ausgaben von:
host -t A p3e9bf678.dip0.t-ipconnect.de
mtr -4nr -c 1 62.155.246.120
mtr -4nr -c 1 192.168.176.1
dig -x 192.168.176.1 +short
?
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
host -t A p3e9bf678.dip0.t-ipconnect.de
p3e9bf678.dip0.t-ipconnect.de has address 62.155.246.120
mtr -4nr -c 1 62.155.246.120
Start: 2020-06-05T15:22:53+0200
HOST: MYCOMPUTER Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.178.1 0.0% 1 10.6 10.6 10.6 10.6 0.0
2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
mtr -4nr -c 1 192.168.176.1
Start: 2020-06-05T15:23:27+0200
HOST: MYCOMPUTER Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.178.1 0.0% 1 8.1 8.1 8.1 8.1 0.0
2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
dig -x 192.168.176.1 +short
(kein Eintrag)
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
So ein Eintrag im PW-Manager von Google macht doch nur Sinn, wenn man was synchronisieren will, oder? Habe die Funktion nie genutzt, daher vorher auch nicht reingeschaut. ping 192.168.176.1
PING 192.168.176.1 (192.168.176.1) 56(84) bytes of data.
From 62.155.246.120 icmp_seq=1 Destination Net Unreachable
... Nach wie vor. Müsste man nur noch wissen, wo das übersetzt wird.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
pbreak2001 schrieb: mtr -4nr -c 1 62.155.246.120
Start: 2020-06-05T15:22:53+0200
HOST: MYCOMPUTER Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.178.1 0.0% 1 10.6 10.6 10.6 10.6 0.0
2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
Dann blockst Du evtl. das icmp-Protokoll, in deinem Linux-PC?
Wie sind die Ausgaben von:
sudo iptables -nvx -L
?
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
792085 1058789405 ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
792085 1058789405 ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
9965 840329 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
346 16079 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
346 16079 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
346 16079 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-before-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-reject-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-track-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
604030 4108156950 ufw-before-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
604030 4108156950 ufw-before-output all -- * * 0.0.0.0/0 0.0.0.0/0
32304 5576977 ufw-after-output all -- * * 0.0.0.0/0 0.0.0.0/0
32304 5576977 ufw-after-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
32304 5576977 ufw-reject-output all -- * * 0.0.0.0/0 0.0.0.0/0
32304 5576977 ufw-track-output all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-after-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-after-input (1 references)
pkts bytes target prot opt in out source destination
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
1 266 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ufw-skip-to-policy-input all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-after-logging-input (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-after-logging-output (1 references)
pkts bytes target prot opt in out source destination
10 814 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "
Chain ufw-after-output (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-before-forward (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 12
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 ufw-user-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-before-input (1 references)
pkts bytes target prot opt in out source destination
24 2584 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
88 59862 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
4 208 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
4 208 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 12
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
2 464 ufw-not-local all -- * * 0.0.0.0/0 0.0.0.0/0
1 198 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353
0 0 ACCEPT udp -- * * 0.0.0.0/0 239.255.255.250 udp dpt:1900
1 266 ufw-user-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-before-logging-forward (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW AUDIT] "
Chain ufw-before-logging-input (1 references)
pkts bytes target prot opt in out source destination
10 889 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW AUDIT] "
Chain ufw-before-logging-output (1 references)
pkts bytes target prot opt in out source destination
10 872 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW AUDIT] "
Chain ufw-before-output (1 references)
pkts bytes target prot opt in out source destination
24 2584 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
93 11616 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
23 1840 ufw-user-output all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-logging-allow (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "
Chain ufw-logging-deny (2 references)
pkts bytes target prot opt in out source destination
4 208 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW AUDIT INVALID] "
4 208 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-not-local (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
1 198 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
1 266 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
0 0 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-reject-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-reject-input (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-reject-output (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-skip-to-policy-forward (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-skip-to-policy-input (7 references)
pkts bytes target prot opt in out source destination
1 266 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-skip-to-policy-output (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-track-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-track-input (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-track-output (1 references)
pkts bytes target prot opt in out source destination
15 900 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
8 940 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
Chain ufw-user-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-input (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:992
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:992
Chain ufw-user-limit (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW LIMIT BLOCK] "
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-user-logging-forward (0 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-logging-input (0 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-logging-output (0 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-output (1 references)
pkts bytes target prot opt in out source destination
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
pbreak2001 schrieb:
792085 1058789405 ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
Gibt es einen bestimmten Grund, die ufw zu benutzen?
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
läuft in Verbindung mit dem FW-Konfigurator, welcher lediglich aus dem Stadardprofil "zuhause" besteht. die ufw log gibt nur die IP in Verbindung mit dem Pingen wieder.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
pbreak2001 schrieb: läuft in Verbindung mit dem FW-Konfigurator, welcher lediglich aus dem Stadardprofil "zuhause" besteht. die ufw log gibt nur die IP in Verbindung mit dem Pingen wieder.
Funktionieren diese Pings:
ping -c 3 1.1.1.1
ping -c 3 heise.de
?
Wenn nicht, dann teste mal mit deaktivierter ufw.
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
Funktionieren diese Pings:
ping -c 3 1.1.1.1
ping -c 3 heise.de
?
Wenn nicht, dann teste mal mit deaktivierter ufw.
JA
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
pbreak2001 schrieb: JA
Dann sollte das traceroute mit mtr, auch mehr als nur einen Sprung anzeigen. Z. B. so ähnlich:
~$ mtr -4nr -c 1 62.155.246.120
Start: Sat Jun 6 12:17:03 2020
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.178.1 0.0% 1 2.7 2.7 2.7 2.7 0.0
2.|-- 3y.xx.yy.# 0.0% 1 12.1 12.1 12.1 12.1 0.0
3.|-- 81.210.144.118 0.0% 1 11.8 11.8 11.8 11.8 0.0
4.|-- 84.116.190.181 0.0% 1 15.4 15.4 15.4 15.4 0.0
5.|-- 84.116.140.205 0.0% 1 16.2 16.2 16.2 16.2 0.0
6.|-- 84.116.140.190 0.0% 1 20.6 20.6 20.6 20.6 0.0
7.|-- 62.157.248.133 0.0% 1 15.0 15.0 15.0 15.0 0.0
8.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
|
pbreak2001
(Themenstarter)
Anmeldungsdatum: 23. Februar 2016
Beiträge: 23
|
Leider nein, geht nur bis Punkt 2 und da steht "???".Auch, wenn ufw abgeschaltet ist. Habs gerade mit anderen IPs versucht, da gehts die Reihe durch.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
pbreak2001 schrieb: Leider nein, geht nur bis Punkt 2 und da steht "???"... Habs gerade mit anderen IPs versucht, da gehts die Reihe durch.
Dann wird der Ping zu dieser IP-Adresse (62.155.246.120) entweder durch deinen Router oder durch deinen ISP geblockt.
Der Ping auf die IP-Adresse 192.168.176.1 wird m. E. in deinem Router umgeleitet. Welchen Router hast Du bzw. bei welchem Provider hast Du deinen Internetanschluss?
|