intruder detection

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
silent303
Beiträge: 4
Registriert: 20 Okt 2020, 13:19

intruder detection

Beitrag von silent303 »

Hallo,
ich versuche mich gerade daran einen WLAN Access Point hinter einen WLC-4006 zu betreiben. Soweit funktioniert das auch, jedoch bekomme ich laufend Meldungen von der Firewall. Leider bin ich etwas unbeholfen mit dieser Thematik :-)

Code: Alles auswählen

[Firewall] 2020/10/20 13:26:09,906  Devicetime: 2020/10/20 13:26:11,004
Packet matched rule intruder detection
DstIP: 255.255.255.255, SrcIP: 0.0.0.0, Len: 156, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 52011, SrcPort: 52012

Filter info: packet from invalid address 0.0.0.0 received from interface LAN-1
send SNMP trap
packet dropped
Hat vieleicht jemand eine Idee was ich tun muss?
Liebe Grüße
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: intruder detection

Beitrag von backslash »

Hi silent303,

da hilft diur nur das Gerät zu finden, daß diese "kaputten" Pakete sendet und es entweder korrekt zu konfigurtieren oder es in die Tonne zu werfen.
Die Quell-Adresse 0.0.0.0 ist nur für DHCP-Clients erlaubt. der Port 52011 ist aber nicht der DHCP-Port - der wäre 67...

Gruß
Backslash
GrandDixence
Beiträge: 1055
Registriert: 19 Aug 2014, 22:41

Re: intruder detection

Beitrag von GrandDixence »

backslash hat geschrieben: 20 Okt 2020, 15:30 Die Quell-Adresse 0.0.0.0 ist nur für DHCP-Clients erlaubt.
Die Quell-IPv4-Adresse 0.0.0.0 wird von Netzwerkteilnehmern korrekterweise verwendet, denen keine (gültige) IPv4-Adresse zugewiesen wurde. Zum Beispiel: Kabelmodeme, die als Bridge fungieren. Siehe auch Seite 3 von:
fragen-zur-lancom-systems-routern-und-g ... 9-s30.html

https://en.wikipedia.org/wiki/0.0.0.0

https://de.wikipedia.org/wiki/Bridge_(Netzwerk)

Dieser Netzwerkteilnehmer produziert keine kaputten IP-Pakete. Dieser Netzwerkteilnehmer erzeugt völlig korrekte IP-Datenpakte mit der korrekten Quell-IPv4-Adresse und der korrekten Ziel-IPv4-Adresse (Broadcast).
https://de.wikipedia.org/wiki/Broadcast

Deswegen muss man diesen Netzwerkteilnehmer noch lange nicht in die Mülltonne werfen...

Mit Wireshark die Quell-MAC-Adresse der Datenpakete feststellen, dann hat man schnell die Quelle der IP-Datenpakete mit Quell-IPv4-Adresse 0.0.0.0 gefunden.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: intruder detection

Beitrag von alf29 »

Moin,
Die Quell-IPv4-Adresse 0.0.0.0 wird von Netzwerkteilnehmern korrekterweise verwendet, denen keine (gültige) IPv4-Adresse zugewiesen wurde. Zum Beispiel: Kabelmodeme, die als Bridge fungieren.
Nunja, ein Client, der keine IP-Adresse hat, kann auch nicht per IP kommunizieren, und für Bridges gibt es passende Layer2-Protokolle. Wie sollte man z.B. an so ein Gerät auf der Adress 0.0.0.0 antworten? Spätestens wenn man mehrere von dieser Sorte im Netz hat...

Wie backslash schon geschrieben hat, ist 0.0.0.0 nur in wenigen Ausnahmefällen als Quelladresse erlaubt. Mir selber fallen jetzt spontan außer DHCP-Requests nur IGMP-Queries von Switchen ein, die als IGMP-Proxy agieren (RFC 4541). Dies hier sind aber keine IGMP-, sondern UDP-Pakete.

Also laßt uns wie vorgeschlagen genauer anschauen, was das für Pakete sind. Dann kann man immer noch diskutieren, ob sie irgendeinem Standard entsprechen oder nicht.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
silent303
Beiträge: 4
Registriert: 20 Okt 2020, 13:19

Re: intruder detection

Beitrag von silent303 »

Hallo,

ganz lieben Dank für eure Antworten. Ich installiere mir Wireshark und suche die MAC Adresse die das verursacht?

Viele Grüße
Tobias
silent303
Beiträge: 4
Registriert: 20 Okt 2020, 13:19

Re: intruder detection

Beitrag von silent303 »

Ich habe mir mal Wiresshark installiert. Nur wie kann ich jetzt die IP oder MAC rausfinden? Weder finde ich die erwähnten Ports noch die IPs. Wie gesagt bin ich nicht der Pro :-(
silent303
Beiträge: 4
Registriert: 20 Okt 2020, 13:19

Re: intruder detection

Beitrag von silent303 »

Glaube hab etwas gefunden:

Code: Alles auswählen

Frame 3383: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits) on interface \Device\NPF_{A68A189A-4A3D-4038-8EB0-331FE90C1918}, id 0
    Interface id: 0 (\Device\NPF_{A68A189A-4A3D-4038-8EB0-331FE90C1918})
    Encapsulation type: Ethernet (1)
    Arrival Time: Oct 21, 2020 22:56:46.565788000 Mitteleuropäische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1603313806.565788000 seconds
    [Time delta from previous captured frame: 0.038438000 seconds]
    [Time delta from previous displayed frame: 0.038438000 seconds]
    [Time since reference or first frame: 25.581335000 seconds]
    Frame Number: 3383
    Frame Length: 170 bytes (1360 bits)
    Capture Length: 170 bytes (1360 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Shenzhen_33:e8:30 (80:c5:48:33:e8:30), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Shenzhen_33:e8:30 (80:c5:48:33:e8:30)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 156
    Identification: 0x72ee (29422)
    Flags: 0x0000
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x0764 [validation disabled]
    [Header checksum status: Unverified]
    Source: 0.0.0.0
    Destination: 255.255.255.255
User Datagram Protocol, Src Port: 52012, Dst Port: 52011
    Source Port: 52012
    Destination Port: 52011
    Length: 136
    Checksum: 0x3f79 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 1]
    [Timestamps]
Data (128 bytes)
    Data: 3537303257333365383330325968744100000000aabbccdd…
    [Length: 128]
Und:

Code: Alles auswählen

Frame 715: 92 bytes on wire (736 bits), 92 bytes captured (736 bits) on interface \Device\NPF_{A68A189A-4A3D-4038-8EB0-331FE90C1918}, id 0
    Interface id: 0 (\Device\NPF_{A68A189A-4A3D-4038-8EB0-331FE90C1918})
        Interface name: \Device\NPF_{A68A189A-4A3D-4038-8EB0-331FE90C1918}
        Interface description: Ethernet 2
    Encapsulation type: Ethernet (1)
    Arrival Time: Oct 21, 2020 23:11:01.828084000 Mitteleuropäische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1603314661.828084000 seconds
    [Time delta from previous captured frame: 0.032131000 seconds]
    [Time delta from previous displayed frame: 0.032131000 seconds]
    [Time since reference or first frame: 5.499170000 seconds]
    Frame Number: 715
    Frame Length: 92 bytes (736 bits)
    Capture Length: 92 bytes (736 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:data]
Ethernet II, Src: Shenzhen_33:e8:30 (80:c5:48:33:e8:30), Dst: 00:00:00_12:34:57 (00:00:00:12:34:57)
    Destination: 00:00:00_12:34:57 (00:00:00:12:34:57)
        Address: 00:00:00_12:34:57 (00:00:00:12:34:57)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Shenzhen_33:e8:30 (80:c5:48:33:e8:30)
        Address: Shenzhen_33:e8:30 (80:c5:48:33:e8:30)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: Unknown (0x9688)
Data (78 bytes)
    Data: 011122cc5701004480c54833e83000013537303231303038…
    [Length: 78]
Es muss sich um den WLAN AP handeln den ich hinter den Lancom gesetzt habe sein. Er wird eigentlich im Bridgemodus betrieben und die Clients bekommen ihre IP vom Lancom, was auch funktioniert.

Könnte es sein, dass dies der DHCP von der Kiste ist?
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: intruder detection

Beitrag von alf29 »

Moin,
Glaube hab etwas gefunden:
Ja, das sieht nach so einem Frame aus. Der Inhalt scheint irgendwelcher ASCII-Text zu sein ("5702W33e8302YhtA..."), dem kann man leider nicht großartig ansehen, was das für ein Protokoll sein soll.

Das zweite Paket ist kein IP-Paket, das ist erstmal unkritisch und Ethernet-Protokoll 0x9688 ist jedenfalls nicht offiziell beim IEEE (http://standards-oui.ieee.org/ethertype/eth.txt) registriert, es scheint aber ähnliche Daten zu enthalten, die ASCII-Zeichen 57021008 sehen so ähnlich aus. Die Ziel-MAC-Adresse 00:00:00:12:34:57 in diesem Paket ist auch eher willkürlich, OUI 00:00:00 ist - wenn überhaupt - an Xerox zugewiesen und 12:34:57 sieht verdächtig nach 123456 aus.
Es muss sich um den WLAN AP handeln den ich hinter den Lancom gesetzt habe sein.
Das kann der AP selber sein (wenn es kein LANCOM-AP ist, LANCOM-APs erzeugen keine solchen Pakete und hätten eine MAC-Adresse 00:A0:57:...), oder ein Client, der an diesem AP angemeldet ist, und der AP leitet die Pakete vom Client einfach nur weiter. Du müßtest Dich jetzt auf die Suche nach einem Gerät mit der MAC-Adresse 80:c5:48:33:e8:30 begeben.
Wenn du das gefunden hast, dann müßtest dessen Hersteller fragen, was das sein soll.

Persönlich tippe ich eher auf einen am AP angemeldeten Client, wahrscheinlich irgendein IoT-Krams. Gerade im IoT/Embedded-Umfeld findet man öfters Geräte mit merkwürdigen oder unvollständigen TCP/IP-Implementierungen, die dann bei anderen Geräten im Netz, die TCP/IP gemäß den RFCs implementieren, für solche Meldungen sorgen. Gefühlt würde ich sagen, Du wirst von backslash keine Hilfe bekommen, die Meldungen der Firewall abzuschalten, einfach weil das nicht standardkonform ist, was dieses Gerät da macht. Du mußt dann entweder mit diesen Meldungen leben, oder das fragliche Gerät zumindest dazu bewegen, nicht mehr diese komischen IP-Broadcasts zu schicken.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: intruder detection

Beitrag von backslash »

Hi alf
Du wirst von backslash keine Hilfe bekommen, die Meldungen der Firewall abzuschalten, einfach weil das nicht standardkonform ist, was dieses Gerät da macht. Du mußt dann entweder mit diesen Meldungen leben, oder das fragliche Gerät zumindest dazu bewegen, nicht mehr diese komischen IP-Broadcasts zu schicken.
korrekt...

Gruß
Backslash
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: intruder detection

Beitrag von plumpsack »

backslash hat geschrieben: 20 Okt 2020, 15:30
Die Quell-Adresse 0.0.0.0 ist nur für DHCP-Clients erlaubt. ...
Was ist das hier, steht in meinem Syslog unter "0.0.0.0"?
2020-10-15 18:42:48 LOCAL3 Alarm Dst: 0.0.0.0, Src: 185.85.2.202 (ICMP): intrusion detection
2020-10-04 12:25:44 LOCAL3 Alarm Dst: 0.0.0.0, Src: 172.105.17.67 (ICMP): intrusion detection
2020-10-01 07:43:04 LOCAL3 Alarm Dst: 0.0.0.0, Src: 195.251.255.69 (ICMP): intrusion detection
2020-09-15 10:48:32 LOCAL3 Alarm Dst: 0.0.0.0, Src: 185.85.2.202 (ICMP): intrusion detection
2020-09-15 10:32:33 LOCAL3 Alarm Dst: 0.0.0.0, Src: 185.85.2.202 (ICMP): intrusion detection
2020-09-14 05:35:06 LOCAL3 Alarm Dst: 0.0.0.0, Src: 58.242.248.138 (ICMP): intrusion detection
2020-09-12 14:43:40 LOCAL3 Alarm Dst: 0.0.0.0, Src: 195.169.125.251 (ICMP): intrusion detection
2020-08-03 03:35:09 LOCAL3 Alarm Dst: 0.0.0.0, Src: 14.182.157.140 (ICMP): intrusion detection
2020-07-14 03:00:22 LOCAL3 Alarm Dst: 0.0.0.0, Src: 52.81.228.20 (ICMP): intrusion detection
2020-07-13 04:39:29 LOCAL3 Alarm Dst: 0.0.0.0, Src: 52.81.237.99 (ICMP): intrusion detection
2020-07-11 11:20:44 LOCAL3 Alarm Dst: 0.0.0.0, Src: 46.146.202.91 (ICMP): intrusion detection
2020-07-09 16:42:31 LOCAL3 Alarm Dst: 0.0.0.0, Src: 185.94.111.1 (ICMP): intrusion detection
2020-06-30 15:29:07 LOCAL3 Alarm Dst: 0.0.0.0, Src: 54.223.180.52 (ICMP): intrusion detection
2020-06-17 23:28:51 LOCAL3 Alarm Dst: 0.0.0.0, Src: 54.223.180.52 (ICMP): intrusion detection
2020-06-16 23:09:00 LOCAL3 Alarm Dst: 0.0.0.0, Src: 117.131.215.170 (ICMP): intrusion detection
2020-06-09 12:52:49 LOCAL3 Alarm Dst: 0.0.0.0, Src: 23.92.31.220 (ICMP): intrusion detection
Wollen die nur spielen?
:G)
Antworten