[gelöst]Unbekannte Geräte melden sich an der Fritzbox an

[halo44]

Auf meiner Fritzbox 7590 werden an einzelnen Tagen Anmeldungen unbekannter Geräte protokolliert. Hier ein Beispiel von heute:

29.08.24 11:55:25 Netzwerkgerät Name: PC-46-7E-5A-11-85-9E, MAC: 46:7E:5A:11:85:9E hat sich mit der FRITZ!Box verbunden.

Die Namen der Geräte und deren MAC-Adresse sind immer wieder neue.

Das Journal zeigt immer zu den Uhrzeiten der Anmeldung folgende Einträge

Aug 29 11:55:14 dt-debian kernel: device enp34s0 entered promiscuous mode
Aug 29 11:57:13 dt-debian kwin_x11[2809]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 22606, resource id: 69206060, major code: 15 (QueryTree), minor code: 0
Aug 29 11:57:14 dt-debian kernel: device enp34s0 left promiscuous mode

Dieser "promiscuos mode" findet sich nur zu den Zeiten der protokollierten Anmeldungen, nie anderswo im Journal. In diesem Modus sollen eingehende Netzwerkpakete erkannt werden.

Eine Rückfrage bei AVM brachte mich nicht weiter. Sinngemäß könne dies z.B. passieren, wenn an einem Smartphone im Heimnetz der "Privacy Mode" im WLAN aktiviert sei. Die Meldungen signalisieren aber die Ereignisse für das Gerät enp34s0, also LAN-Netz.

An den LAN-Anschlüssen hängen mein Desktoprechner, mein Notebook und ein Magenta-Mediareceiver. Der Notebook war zu den Ereignissen nicht hochgefahren. Der Mediareceiver hat eine konstant bleibende MAC-Adresse, wie auch zwei Smartphones und ein Tablet.

Die Ereignisse treten nur auf, wenn der Desktoprechner in Betrieb ist, d.h. nie nachts. Nachts nehme ich mit dem Mediareceiver zwar Sendungen auf, aber zu keiner Zeit traten während dessen Ereignisse auf. Auch bei Wiedergabe vom Mediareceiver wurde nichts protokolliert. Damit möchte ich den Mediareceiver als "Übeltäter" ausschließen.

Hat jemand eine Idee womit diese "Anmeldungen" zu erklären wären?

Vielen Dank für jeden Hinweis.

Gruß H.

[mludwig]

in den Einstellungen der netzwerkkarte so etwas wie zufällige MAC Adresse aktiviert? Das wurde für den Datenschutz eingeführt, ist zu Hause aber unnötig.

[halo44]

in den Einstellungen der netzwerkkarte so etwas wie zufällige MAC Adresse aktiviert? Das wurde für den Datenschutz eingeführt, ist zu Hause aber unnötig.

Ich arbeite mit systemd-networkd. Die Konfiguration in /etc/systemd/network/enp34s0 enthält

Code: Alles auswählen

[Match]
Name=enp34s0

[Network]
Address=192.168.2.201/24
Gateway=192.168.2.1

Dort also nichts dergleichen. Wo sonst könnte noch etwas in der Richtung zu finden sein?

Gruß H.

[michaa7]

Hast du schon immer systemd-networkd benutzt?

Hast du sonst im journald irgendwelche Netzwerk Fehler oder Warnungen? Erscheinen die beim/kurz nach dem Booten?

[Draal]

enp34s0 klingt mir nach WLAN.
Vielleicht liege ich falsch, aber bei meinen FritzBoxen konnte ich den Zugriff per WLAN immer auf bekannte MAC Adressen beschränken.
Wer weiß schon, was da auf den Smartphones herumwuselt.

[MSfree]

enp34s0 klingt mir nach WLAN.

Nein, das sind normalerweise die Bezeichnungen für Ethernetschnittstellen. WLAN fängt normalerweise mit wl an.

bei meinen FritzBoxen konnte ich den Zugriff per WLAN immer auf bekannte MAC Adressen beschränken.

Und das ist so ziemlich die sinnloseste Einstellung, die man machen kann. Das schützt überhaupt nicht und macht nur Ärger, wenn Rechner seit neuestem MAC-Randomization nutzen.

Wer weiß schon, was da auf den Smartphones herumwuselt.

Ja und? Die kommen ohne den Schlüssel sowieso nicht weit.

[halo44]

Hast du schon immer systemd-networkd benutzt?

Hast du sonst im journald irgendwelche Netzwerk Fehler oder Warnungen? Erscheinen die beim/kurz nach dem Booten?

Ich nutze systemd-networkd schon seit Buster. Keine Fehler beim Booten.

Die Smartphones und das Tablet haben konstant immer die gleichen MAC-Adressen.

Gruß H.

[Livingston]

promiscuous mode heißt, das die Netzwerkkarte darauf eingestellt ist, jeden Netzwerkverkehr mitzulesen, selbst wenn er nicht für sie bestimmt ist.
Im normalen Modus "hört" die Karte nur auf ihre eigene MAC-Adresse, während sie im promiscuous mode auch Daten für andere Geräte auf dem Kabel mitlesen kann.
So was macht man eigentlich nur in Ausnahmefällen z.B. zum Debuggen oder wenn man ein Netzwerk vollständig ausschnüffeln möchte.

[MSfree]

So was macht man eigentlich nur in Ausnahmefällen

Nicht wirklich. Der Kernel schaltet schon beim Booten die NIC in den promiscuous mode. Programme wie tcpdump funktionieren ohne promiscuous mode auch nicht.

z.B. wenn man ein Netzwerk vollständig ausschnüffeln möchte.

Das verhindern heutzutage die Switches, die dafür sorgen, daß Netzwerkpakete nur an die adressierte NIC gehen.

Mit managed Switches kann man allerdings einzelne Ports zum "Ausschnüfflen" freischalten. Bei den alten Hubs ging sowieso jedes Netzwerkpaket an jede NIC.

[halo44]

Eine weitere interessante Information: ich habe auf meinem Notebookrechner, der ebenfalls mit Debian 12 läuft, das Journal ausgewertet.

Das Journal startet am 29.06.2024. An diesem Tag habe ich Debian 12 auf den neuen Notebook installiert. Im heute ausgewerteten Journal fanden sich am 13.08.2024 sieben Mal die Pärchen "entered promiscuous mode / left promiscuous mode". Entsprechend finden sich an diesem Tag zu den entsprechenden Uhrzeiten auch sieben Mal Anmeldungen unbekannter Geräte im Router-Ereignis-Protokoll. Ab dem 14.08.2024 fanden sich keine promiscuous-Meldung im Journal mehr.

Der Notebook wurde im Juni, Juli und August fast an jedem Tag gebootet, wenn auch für unterschiedliche Laufzeiten. Merkwürdig ist das massive Auftreten der Meldungen an einem einzigen Tag.

Ich werde spätestens morgen testhalber auch die Journale der Testing-Installationen beider Rechner mal auswerten. Hierbei beschränken sich allerdings die Laufzeiten auf Updates und kurze Anwendungstests.

Gruß H.

[Livingston]

So was macht man eigentlich nur in Ausnahmefällen

Nicht wirklich. Der Kernel schaltet schon beim Booten die NIC in den promiscuous mode. Programme wie tcpdump funktionieren ohne promiscuous mode auch nicht.

Für tcpdump brauche ich den PM, falls ich den nicht für die Karte bestimmten Traffic abgreifen möchte, und dann schalte ich explizit auf den PM um. Das macht nicht der Kernel von sich aus, sondern ich bitte ihn mit Root-Rechten, das zu tun.
Ein

Code: Alles auswählen

$ ip -d link

ergibt zumindest bei mir auf einer Maschine, an der ich nicht am Netzwerk geschraubt habe:

Code: Alles auswählen

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff promiscuity 0 ...

Man achte auf die 0 hinter promiscuity.

z.B. wenn man ein Netzwerk vollständig ausschnüffeln möchte.

Das verhindern heutzutage die Switches, die dafür sorgen, daß Netzwerkpakete nur an die adressierte NIC gehen.

Mit managed Switches kann man allerdings einzelne Ports zum "Ausschnüfflen" freischalten. Bei den alten Hubs ging sowieso jedes Netzwerkpaket an jede NIC.

Ja, die Switches sollte man dann auch freischalten.

[thunder11]

In der Fritte finde ich Nichts - dafür im Journal:
Natürlich weiß ich nicht, ob das bei dir gleiche Ursachen hat.

Code: Alles auswählen

journalctl |grep -i promiscuous
[......]
Aug 26 00:14:36 XFCE lynis[58125]: - Checking promiscuous interfaces [ OK ]
Aug 27 00:10:40 XFCE lynis[88014]: - Checking promiscuous interfaces [ OK ]
Aug 28 00:09:49 XFCE lynis[93831]: - Checking promiscuous interfaces [ OK ]
Aug 29 00:02:52 XFCE lynis[97858]: - Checking promiscuous interfaces [ OK ]

Weiß gar nicht, wie und wann mir diesen Dienst eingefangen habe.

Code: Alles auswählen

systemctl status lynis.timer
● lynis.timer - Daily timer for the Lynis security audit and vulnerability scanner
     Loaded: loaded (/usr/lib/systemd/system/lynis.timer; enabled; preset: enabled)
     Active: active (waiting) since Thu 2024-08-29 17:29:33 CEST; 2h 19min ago
 Invocation: 69a4cadbb7024aebb62073251cd7e575
    Trigger: Fri 2024-08-30 00:11:25 CEST; 4h 22min left
   Triggers: ● lynis.service

Aug 29 17:29:33 XFCE systemd[1]: Started lynis.timer - Daily timer for the Lynis security audit and vulnerability scanner.

Code: Alles auswählen

 systemctl status lynis.service
○ lynis.service - Security audit and vulnerability scanner
     Loaded: loaded (/usr/lib/systemd/system/lynis.service; static)
     Active: inactive (dead)
TriggeredBy: ● lynis.timer
       Docs: https://cisofy.com/docs/

Das Ding startet jeden Tag um hinterlässt 700 Zeilen Protkoll im Journal.

Code: Alles auswählen

apt info lynis
Package: lynis
Version: 3.1.1-1
Priority: optional
Section: utils
Maintainer: Marc Dequènes (Duck) <Duck@DuckCorp.org>
Installed-Size: 1.717 kB
Depends: e2fsprogs
Recommends: menu
Suggests: dnsutils, apt-listbugs, debsecan, debsums, tripwire, samhain, aide, fail2ban
Homepage: https://cisofy.com/lynis/
Tag: interface::commandline, role::program, scope::utility,
 security::integrity, security::log-analyzer, use::checking,
 use::monitor
Download-Size: 266 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian testing/main amd64 Packages
Description: Werkzeug zur Sicherheitsprüfung von Unix-basierten Systemen
 Lynis ist ein Auditing-Werkzeug zum Härten von GNU/Linux- und Unix-basierten
 Systemen. Es scannt die Systemkonfiguration und erstellt einen Überblick
 über Systeminformationen und Sicherheitsprobleme, die von professionellen
 Prüfern verwendet werden können. Das Programm kann bei automatisierten
 Audits helfen.
 .
 Lynis kann zusätzlich zu anderer Software wie Sicherheitsprüfern,
 Benchmarkprogrammen und Werkzeugen zur Feinabstimmung genutzt werden.

[MSfree]

Ein

Code: Alles auswählen

$ ip -d link

Da sind alle meine Linuxkisten auf promiscuity 1. Explizit eingeschaltet habe ich das nicht. dmesg liefert bei mir zumindest, daß der promiscuous mode rund 2.8s nach Beginn des Bootvorgangs eingeschaltet wird.

[mat6937]

Die Namen der Geräte und deren MAC-Adresse sind immer wieder neue.

Das Journal zeigt immer zu den Uhrzeiten der Anmeldung folgende Einträge

Aug 29 11:55:14 dt-debian kernel: device enp34s0 entered promiscuous mode
Aug 29 11:57:13 dt-debian kwin_x11[2809]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 22606, resource id: 69206060, major code: 15 (QueryTree), minor code: 0
Aug 29 11:57:14 dt-debian kernel: device enp34s0 left promiscuous mode

Schau mal mit tcpdump nach, ob über die enp34s0-NIC auch Daten mit einer anderen source-/dst-MAC-Adresse gesendet werden:

Code: Alles auswählen

tcpdump -c 200 -vvveni enp34s0 not ether src <richtige-MAC-Adresse> and not ether dst <richtige-MAC-Adresse> and not ether src <MAC-Adresse-FritzBox> and not multicast

[halo44]

... Schau mal mit tcpdump nach, ob über die enp34s0-NIC auch Daten mit einer anderen source-/dst-MAC-Adresse gesendet werden ...

tcpdump sagt mir

Code: Alles auswählen

tcpdump: listening on enp34s0,link-type EN10MB (Ethernet), snapshot length 262144 bytes

Gehe ich recht in der Annahme, dass ich dies bei jedem Bootvorgang absetzen muss? Da die Anmeldungen der unbekannten Geräte nicht an jedem Tag auftreten.

Ich kenne tcpdump bisher nicht und habe daher Fragen. Ich nehme an, dass der abgesetzte Befehl auf Ereignisse wartet, die auf die Bedingungen zutreffen und diese protokolliert. Wo finde ich dieses Protokoll? Wird es auch dann ausgegeben, wenn sich keine Treffer ergaben?

Gruß H.

[MSfree]

Gehe ich recht in der Annahme, dass ich dies bei jedem Bootvorgang absetzen muss? Gruß H.

tcpdump ist ein Werkzeug zur Fehlersuche, das man im normalen Betrieb überhaupt nicht braucht.

[mat6937]

Gehe ich recht in der Annahme, dass ich dies bei jedem Bootvorgang absetzen muss? Da die Anmeldungen der unbekannten Geräte nicht an jedem Tag auftreten.

Ja, bei jedem Bootvorgang.
Du musst aber auch den richtigen Filter für tcpdump benutzen. D. h. die MAC-Adresse vom enp34s0-Interface und die zuständige MAC-Adresse der FritzBox. Siehe dazu, die Ausgaben von:

Code: Alles auswählen

ip link show dev enp34s0
ip n s

[halo44]

... Ja, bei jedem Bootvorgang.
Du musst aber auch den richtigen Filter für tcpdump benutzen. D. h. die MAC-Adresse vom enp34s0-Interface und die zuständige MAC-Adresse der FritzBox. Siehe dazu, die Ausgaben von:

Code: Alles auswählen

ip link show dev enp34s0
ip n s

Ja ich nehme die richtigen MAC-Adressen für beide. Dabei nehme ich für das enp34s0-Interface die MAC-Adresse, die mir

Code: Alles auswählen

ip a

zeigt. Die zugehörige IP-Adresse ist richtig die 192.168.2.201.

Allerdings zeigt mir das von Dir vorgeschlagene

Code: Alles auswählen

ip n s

diese Ausgabe

Code: Alles auswählen

192.168.2.52 dev enp34s0 MAC-Adresse des Mediareceivers REACHABLE 
192.168.2.1  dev enp34s0 MAC-Adresse der Fritzbox STALE 
192.168.2.21 dev enp34s0 MAC-Adresse des TV-Geräts STALE

Hier fehlt die richtige IP-Adresse 192.168.2.201 und deren MAC-Adresse.

Ich nehme aber an, dass die oben von mir erwähnten Filter die richtigen sind.

Gruß H.

[halo44]

@thunder11 lynis ist bei mir nicht installiert.

Gruß H.

[mat6937]

Allerdings zeigt mir das von Dir vorgeschlagene

Code: Alles auswählen

ip n s

diese Ausgabe

Code: Alles auswählen

192.168.2.1  dev enp34s0 MAC-Adresse der Fritzbox STALE 

Diese Ausgabe soll dir u. a. (nur) die MAC-Adresse der FritzBox zeigen, die Du im Filter benutzt.

Hier fehlt die richtige IP-Adresse 192.168.2.201 und deren MAC-Adresse.

Nein, in der Ausgabe von "ip n s" fehlt nichts. "n" steht für neighbor. D. h. statt "ip n s" kannst Du auch

ip neighbor show

benutzen oder auch "/usr/sbin/arp -av" (... wenn arp installiert ist; siehe "apt show net-tools") benutzen oder (als root) wenn arp-scan installiert ist:

Code: Alles auswählen

arp-scan -I enp34s0 -l

benutzen.

Ich nehme aber an, dass die oben von mir erwähnten Filter die richtigen sind.

Ich weiß es nicht. Poste mal den von dir benutzten und richtig/brauchbar anonymiserten Filter (für tcpdump).

[halo44]

... Poste mal den von dir benutzten und richtig/brauchbar anonymiserten Filter (für tcpdump).

Dies habe ich benutzt

Code: Alles auswählen

tcpdump -c 200 -vvveni enp34s0 not ether src "MAC-Adresse aus ip a für enp34s0" and not ether dst "MAC-Adresse aus ip a für enp34s0" and not ether src "MAC-Adresse aus arp 192.168.2.1" and not multicast

Gruß H.

[halo44]

Es gab zwar jetzt keine Anmeldung unbekannter Geräte, aber tcpdump meldete mir jetzt:

Code: Alles auswählen

18:19:51.093413 86:35:d6:6c:b6:78 > 72:86:a1:bb:43:62, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.23 tell 192.168.2.24, length 46
18:19:51.893154 86:35:d6:6c:b6:78 > 72:86:a1:bb:43:62, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.23 tell 192.168.2.24, length 46

Die IP-Adresse gehört zum Tablet meiner Frau. Die MAC-Adresse ist richtig und gehört auch zum Tablet. Dieses ist jedoch nur per WLAN verbunden, nicht - wie tcpdump weint ethernet.

Gruß H.

[mat6937]

Die IP-Adresse gehört zum Tablet meiner Frau. Die MAC-Adresse ist richtig und gehört auch zum Tablet. Dieses ist jedoch nur per WLAN verbunden, nicht - wie tcpdump weint ethernet.

Mit tcpdump werden auch arp-requests von Geräten die per Wlan verbunden sind, gesnifft. Kannst arp (negiert) in den Filter aufnehmen, damit die arp-Verbindungen nicht angezeigt werden.

[halo44]

Danke, habe "and not arp" angehängt. Richtig?

Gruß H.

[halo44]

Jetzt meldet tcpdump mir:

Code: Alles auswählen

11:09:41.280992 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40172, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.52022 > 192.168.2.24.51024: [udp sum ok] UDP, length 315
11:09:41.281906 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40173, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.48553 > 192.168.2.24.52024: [udp sum ok] UDP, length 315
11:09:41.483386 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40215, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.52022 > 192.168.2.24.51024: [udp sum ok] UDP, length 315
11:09:41.483409 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40216, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.48553 > 192.168.2.24.52024: [udp sum ok] UDP, length 315
11:09:41.684908 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40258, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.52022 > 192.168.2.24.51024: [udp sum ok] UDP, length 315
11:09:41.684983 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40217, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.48553 > 192.168.2.24.52024: [udp sum ok] UDP, length 315
11:09:41.886910 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40272, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.48553 > 192.168.2.24.52024: [udp sum ok] UDP, length 315
11:09:41.886977 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40273, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.52022 > 192.168.2.24.51024: [udp sum ok] UDP, length 315
11:09:42.087633 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40274, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.52022 > 192.168.2.24.51024: [udp sum ok] UDP, length 315
11:09:42.088528 72:86:a1:bb:43:62 > 86:35:d6:6c:b6:78, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 64, id 40275, offset 0, flags [DF], proto UDP (17), length 343)
    192.168.2.23.48553 > 192.168.2.24.52024: [udp sum ok] UDP, length 315

192.168.2.23 ist - wie schon gesagt - ein Tablet. 192.168.2.24 ist ein Smartphone. Bei beiden stimmen die gezeigten MAC-Adressen.

Im Journal findet sich zu der Uhrzeit nichts und auch im Router-Ereignis-Protokoll nicht.

Gruß H.