Hallo,
das Intrusion Detection System bei LCOS (mindestens seit 6.32, auch in 7.22) zeigt eine Schwäche (oder sollen wir es Bug nennen?) mit ZeroConf-Netzen (alias Microsoft "Auto-Configuration", alias Apple "Bonjour").
Es springt nämlich bei eingehenden Paketen auf angeschlossenen Netzen mit Absender 169.254/16 an, obwohl das nur auf dem WAN-Default-Interface sinnvoll wäre. ZeroConf-Netze dürfen nicht geroutet werden und Clients, bei denen DHCP aus irgendeinem Grund nicht funktioniert, konfigurieren sich gerne selbst mit einer solchen Adresse, ohne dass es sich dabei um einen Intruder handelt.
Das IDS sollte für diese Adressen tolerant sein und still halten oder zumindest eine Option bekommen, die es für 169.254/16 tolerant macht. In größeren Umgebungen könnte sonst das Syslog ziemlich viel solcher unbedeutender Alarme enthalten.
Im Beispiel unten (LCOS 7.22: hier 1811) war es ein WinXP-Client mit LANCAPI, die versucht hat per tftp Kontakt aufzunehmen!
Hat irgendjemand ein Rezept gefunden, das IDS zu trimmen und solche Fehlalarme zu verhindern?
Gruß,
Rougu
-------- Original-Nachricht --------
Delivery-date: Wed, 19 Sep 2007 12:21:55 +0200
From: firewall.myrouter>
Date: 19 Sep 2007 12:21:55 +0200
Subject: intruder detected
Date: 9/19/2007 12:21:55
The packet below
Src: 169.254.161.44:1218 Dst: 255.255.255.255:69 (UDP)
MAC-Header (14 Bytes)
ff ff ff ff ff ff 00 0b cd 8d 4d e1 08 00 | ........ ..M...
IP-Packet (44 Bytes):
45 00 00 2c 26 d4 00 00 80 11 c8 c2 a9 fe a1 2c | E..,&... .......,
ff ff ff ff 04 c2 00 45 00 18 93 78 00 01 73 79 | .......E ...x..sy
73 69 6e 66 6f 00 6f 63 74 65 74 00 | sinfo.oc tet.
matched this filter rule: intruder detection
filter info: packet received from invalid interface WLAN-1-2
because of this the actions below were performed:
reject
send syslog message
send SNMP trap
send email to administrator
IDS-Alarm bei ZeroConf-Netzen (169.254/16)
Moderator: Lancom-Systems Moderatoren
Hi Rogu
Wenn das auftaucht - und insbesondere noch in einem DHCP-Request, dann *IST* das ein Fehler des Herstellers dieses Systems (denn hier müßte 0.0.0.0 stehen). Auch wenn das System vermutlich ein Windows ist (weil andere Systeme geben sich keine APIPA-Adresse), ändert es nichts daran, daß das System fehlerhaft ist.
Gruß
Backslash
Das ist kein Bug und auch keine Schwäche, sondern einfach nur korrekt! APIPA-Adressen *DÜRFEN* im LAN als Absenderadresse *NICHT* auftauchen (es sei denn dein LAN wäre tatsächlich 169.254/16).das Intrusion Detection System bei LCOS (mindestens seit 6.32, auch in 7.22) zeigt eine Schwäche (oder sollen wir es Bug nennen?) mit ZeroConf-Netzen (alias Microsoft "Auto-Configuration", alias Apple "Bonjour").
Es springt nämlich bei eingehenden Paketen auf angeschlossenen Netzen mit Absender 169.254/16 an, obwohl das nur auf dem WAN-Default-Interface sinnvoll wäre. ZeroConf-Netze dürfen nicht geroutet werden und Clients, bei denen DHCP aus irgendeinem Grund nicht funktioniert, konfigurieren sich gerne selbst mit einer solchen Adresse, ohne dass es sich dabei um einen Intruder handelt
Wenn das auftaucht - und insbesondere noch in einem DHCP-Request, dann *IST* das ein Fehler des Herstellers dieses Systems (denn hier müßte 0.0.0.0 stehen). Auch wenn das System vermutlich ein Windows ist (weil andere Systeme geben sich keine APIPA-Adresse), ändert es nichts daran, daß das System fehlerhaft ist.
Gruß
Backslash
HiBackslash,
Ok, das LCOS verhält sich also korrekt. Aber wäre es nicht einfach das Normativ des Faktischen, dass es fehlhafte Windows-Clients gibt, die auf diese Weise Intrusionalarme auslösen, die man als Admin sieht und wegwerfen muss?
Und: 69/udp = TFTP nicht DHCP. Und auf die Gefahr hin, dass ich mich irre: Das Paket in meinem Beispiel kommt von einem LANCAPI-Dienst unter Windows, von dem ich so gelernt zu haben glaube, wie seine Discovery funktioniert.
Ich möchte solche Alarme gerne unterdrücken.
Gruß,
Rougu
PS: Edit wegen 69/udp
Ok, das LCOS verhält sich also korrekt. Aber wäre es nicht einfach das Normativ des Faktischen, dass es fehlhafte Windows-Clients gibt, die auf diese Weise Intrusionalarme auslösen, die man als Admin sieht und wegwerfen muss?
Und: 69/udp = TFTP nicht DHCP. Und auf die Gefahr hin, dass ich mich irre: Das Paket in meinem Beispiel kommt von einem LANCAPI-Dienst unter Windows, von dem ich so gelernt zu haben glaube, wie seine Discovery funktioniert.
Ich möchte solche Alarme gerne unterdrücken.
Gruß,
Rougu
PS: Edit wegen 69/udp