intruder detected, Meldung alle 2-3 Minuten
Moderator: Lancom-Systems Moderatoren
intruder detected, Meldung alle 2-3 Minuten
Hallo zusammen,
ich habe ein Netz mit 8 öffentlichen IP-Adressen, auf der Broadcast-Adresse bekomme ich alle 2-3 Minuten die Meldung "intruder detected", kann mir jemand sagen, welche Voraussetzungen erfüllt sein müssen, damit diese Meldung kommt?
Es macht mich etwas stutzig, das diese Meldung einzig und alleine die Broadcast-IP betrifft, auf allen anderen Adressen kommt diese Meldung nie. Ist es möglich, dass auf der Broadcast-Adresse eine einzige Anfrage reicht, damit die Meldung ausgegeben wird?
Viele Grüsse,
Andreas
Firewall, IDS:
Maximalzahl der Port-Anfragen: 70
IDS-Packet-Aktion: Verwerfen
Date: 2/5/2006 23:21:14
The packet below
Src: 82.97.148.xxx:2996 Dst: 82.xxx.xxx.135:445 (TCP)
45 00 00 30 45 b1 40 00 3a 06 cb 05 52 61 94 c4 | E..0E.@. :...Ra..
52 64 f6 87 0b b4 01 bd 6c 06 4e 3f 00 00 00 00 | Rd...... l.N?....
70 02 7f ff 0b 88 00 00 02 04 05 84 01 01 04 02 | p...... ........
matched this filter rule: intruder detection
filter info: packet to local broadcast address received from interface WAN
because of this the actions below were performed:
reject
send SNMP trap
block source address for 2 hours
ich habe ein Netz mit 8 öffentlichen IP-Adressen, auf der Broadcast-Adresse bekomme ich alle 2-3 Minuten die Meldung "intruder detected", kann mir jemand sagen, welche Voraussetzungen erfüllt sein müssen, damit diese Meldung kommt?
Es macht mich etwas stutzig, das diese Meldung einzig und alleine die Broadcast-IP betrifft, auf allen anderen Adressen kommt diese Meldung nie. Ist es möglich, dass auf der Broadcast-Adresse eine einzige Anfrage reicht, damit die Meldung ausgegeben wird?
Viele Grüsse,
Andreas
Firewall, IDS:
Maximalzahl der Port-Anfragen: 70
IDS-Packet-Aktion: Verwerfen
Date: 2/5/2006 23:21:14
The packet below
Src: 82.97.148.xxx:2996 Dst: 82.xxx.xxx.135:445 (TCP)
45 00 00 30 45 b1 40 00 3a 06 cb 05 52 61 94 c4 | E..0E.@. :...Ra..
52 64 f6 87 0b b4 01 bd 6c 06 4e 3f 00 00 00 00 | Rd...... l.N?....
70 02 7f ff 0b 88 00 00 02 04 05 84 01 01 04 02 | p...... ........
matched this filter rule: intruder detection
filter info: packet to local broadcast address received from interface WAN
because of this the actions below were performed:
reject
send SNMP trap
block source address for 2 hours
- AndreasMarx
- Beiträge: 131
- Registriert: 31 Jan 2005, 19:10
- Wohnort: München
Re: intruder detected, Meldung alle 2-3 Minuten
Hallo Andreas,andreas hat geschrieben: Ist es möglich, dass auf der Broadcast-Adresse eine einzige Anfrage reicht, damit die Meldung ausgegeben wird?
das hast Du genau richtig beobachtet, ein einziges Paket reicht. Bei einem 8er-Subnetz kannst Du nur 6 Adressen wirklich benutzen. Die 82.xxx.xxx.128 ist die Netzwerkadresse und die 82.xxx.xxx.135 die Broadcastadresse.
Das IDS der LANCOMs mag es nicht, wenn Broadcasts von der WAN-Seite kommen.
Gruß,
Andreas
LANCOM 1722,1724,1821+,L-322agn dual,1681V,1781EW,1781VA,1781EW+
Re: intruder detected, Meldung alle 2-3 Minuten
Wobei das doch eigentlich keine Broadcasts sind, zumindest in meinen Logs, da wird meistens ein Zugriff von den "Windows-Ports" verzeichnet.AndreasMarx hat geschrieben: Das IDS der LANCOMs mag es nicht, wenn Broadcasts von der WAN-Seite kommen.
Ansonsten würde ich mir schon wünschen, dass das LCOS an dieser Stelle den Zugriff nicht fehl interpretiert.
Hi andreas,
Wenn du wirklich willst, daß Broadcasts für das LAN aus dem WAN erlaubt sind, dann mußt du sie explizit zulassen:
Das kannst du ggf. auch noch auf bestimmte Ports einschränken
Gruß
Backslash
wie AndreasMarx schon sagte: die x.x.x.135 ist in deinem Fall ein Broadcast.Wobei das doch eigentlich keine Broadcasts sind, zumindest in meinen Logs, da wird meistens ein Zugriff von den "Windows-Ports" verzeichnet.
Das ist keine Fehlinterpretation, sondern beabsichtigt.Ansonsten würde ich mir schon wünschen, dass das LCOS an dieser Stelle den Zugriff nicht fehl interpretiert
Wenn du wirklich willst, daß Broadcasts für das LAN aus dem WAN erlaubt sind, dann mußt du sie explizit zulassen:
Code: Alles auswählen
Quelle: alle Stationen
Ziel: Broadcastadresse (in deinem Fall x.x.x.135)
Aktion: übertragen
Gruß
Backslash
Hi andreas
Es gibt aber weitere Punkte, bei denen das IDS von einem Einbruchsversuch ausgeht. Einer davon ist der Empfang von Broadcasts, da sich mit einem einzigen Broadcast das gesamte Netz ausspähen läßt... Schicke einfach mal unter Linux ein Ping an die Broadcast-Adresse und schau nach, wer sich da alles meldet...
Wenn nun, wie in deinem Fall, aus dem Internet ein SMB-Paket für die Broadcastadresse des Netzes empfangen wird und dieser einfach so weitergeleitet würde, dann würden prompt alle Windows-Rechner darauf antworten und der Angreifer hätte alle seine möglichen Ziele schon gefunden...
Daher mußt du dies explizit zulassen...
Gruß
Backslash
Das mit den Portanfragen ist eine Sache, Broadcasts eine andere. Die Portanfragen sind konfigurierbar, da es Umgebungen gibt, in denen eine hohe Zahl an Portanfragen normal sind und in denen die vorkonfigurierte Anzahl von 50 zu gering ist.Ich hab das IDS so verstanden, dass in meiner Einstellung bei >70 Portanfragen das LCOS sagt, hier ist ein Einbruchalarm. Ist denn ein Broadcast mit >70 Anfragen verbunden?
Es gibt aber weitere Punkte, bei denen das IDS von einem Einbruchsversuch ausgeht. Einer davon ist der Empfang von Broadcasts, da sich mit einem einzigen Broadcast das gesamte Netz ausspähen läßt... Schicke einfach mal unter Linux ein Ping an die Broadcast-Adresse und schau nach, wer sich da alles meldet...
Wenn nun, wie in deinem Fall, aus dem Internet ein SMB-Paket für die Broadcastadresse des Netzes empfangen wird und dieser einfach so weitergeleitet würde, dann würden prompt alle Windows-Rechner darauf antworten und der Angreifer hätte alle seine möglichen Ziele schon gefunden...
Daher mußt du dies explizit zulassen...
Gruß
Backslash
ahaaaa
So langsam lichtet sich das Fragezeichen, vielen Dank Backslash
Ich will die Broadcasts ja gar nicht zulassen. Was mich viel mehr interessieren würde, ist wie ich die Meldung nur dann bekomme kann, wenn wirklich mehrere Portanfragen kommen -Jetzt habe ich ca. 5000 IDS-Meldungen pro Woche- gibt es da eine Möglichkeit?
P.S.:
das war mir gar nicht so bewust.

Ich will die Broadcasts ja gar nicht zulassen. Was mich viel mehr interessieren würde, ist wie ich die Meldung nur dann bekomme kann, wenn wirklich mehrere Portanfragen kommen -Jetzt habe ich ca. 5000 IDS-Meldungen pro Woche- gibt es da eine Möglichkeit?
P.S.:
upsbackslash hat geschrieben:Schicke einfach mal unter Linux ein Ping an die Broadcast-Adresse und schau nach, wer sich da alles meldet...

Hi andreas,
ggf. wieder zusätzlich auf bestimmte Ports beschränkt
Sinvoller wäre allerdings, die Broadcasts bereits beim Absender zu unterbinden...
Gruß
Backslash
Erstelle eine Regel, die die Broadcasts blockt und keine Meldungen erzeugt:Ich will die Broadcasts ja gar nicht zulassen. Was mich viel mehr interessieren würde, ist wie ich die Meldung nur dann bekomme kann, wenn wirklich mehrere Portanfragen kommen -Jetzt habe ich ca. 5000 IDS-Meldungen pro Woche- gibt es da eine Möglichkeit?
Code: Alles auswählen
Quelle: alle Stationen
Ziel: Broadcastadresse (in deinem Fall x.x.x.135)
Aktion: Zurückweisen, alle Häkchen unter "Sonstige Maßnamen" aus
Sinvoller wäre allerdings, die Broadcasts bereits beim Absender zu unterbinden...
Gruß
Backslash
Hi backslash,
danke für deine Geduld.
Ich probiers noch einmal:
IP-Range: 1.2.3.0 - 1.2.3.255, aus diesem Netz habe ich einen Bereich von 1.2.3.128 bis 1.2.3.135 (Mask 255.255.255.248), die meißten anderen IP's sind einzeln vergeben (Mask 255.255.255.255)
Jetzt geht ein neugieriger Zeitgenosse hin und scannt den Bereich:
1.2.3.1
1.2.3.2
"
"
1.2.3.128 (Netzadresse)
1.2.3.129 (mein Gateway)
1.2.3.130 (Server 1)
"
"
1.2.3.135 (meine Broadcastadresse)
1.2.3.136 (Einwahl-IP eines anderen)
"
1.2.3.254 (usw)
Sobald der Scann an der BC-Adresse landet meldet das Lancom Intrusion Detect (habs von einem anderen Server probiert, bei den anderen 7 IP's passiert nichts) Oder einfach ein net use \\1.2.3.135\x und schon IDS-Alarm. Ist da mein Provider gefragt und er muß in seinem Router den Zugriff auf 1.2.3.135 sperren oder wenn ich das richtig verstanden habe, kann es ein, dass ein Zugriff auf 1.2.3.255 auch bei meinem Router landet und das das Problem ist?
Da fehlt mir dann doch ein wenig know how, sorry.
Gruss,
Andreas
danke für deine Geduld.
Hatte ich schon versucht, die Meldungen bleiben leider.backslash hat geschrieben:Erstelle eine Regel, die die Broadcasts blockt und keine Meldungen erzeugt
Irgendwie hab ich da immer noch ein Verständnissproblem, oder aber ich hab Euch noch etwas nicht richtig beschrieben.backslash hat geschrieben: Sinvoller wäre allerdings, die Broadcasts bereits beim Absender zu unterbinden...
Ich probiers noch einmal:
IP-Range: 1.2.3.0 - 1.2.3.255, aus diesem Netz habe ich einen Bereich von 1.2.3.128 bis 1.2.3.135 (Mask 255.255.255.248), die meißten anderen IP's sind einzeln vergeben (Mask 255.255.255.255)
Jetzt geht ein neugieriger Zeitgenosse hin und scannt den Bereich:
1.2.3.1
1.2.3.2
"
"
1.2.3.128 (Netzadresse)
1.2.3.129 (mein Gateway)
1.2.3.130 (Server 1)
"
"
1.2.3.135 (meine Broadcastadresse)
1.2.3.136 (Einwahl-IP eines anderen)
"
1.2.3.254 (usw)
Sobald der Scann an der BC-Adresse landet meldet das Lancom Intrusion Detect (habs von einem anderen Server probiert, bei den anderen 7 IP's passiert nichts) Oder einfach ein net use \\1.2.3.135\x und schon IDS-Alarm. Ist da mein Provider gefragt und er muß in seinem Router den Zugriff auf 1.2.3.135 sperren oder wenn ich das richtig verstanden habe, kann es ein, dass ein Zugriff auf 1.2.3.255 auch bei meinem Router landet und das das Problem ist?
Da fehlt mir dann doch ein wenig know how, sorry.
Gruss,
Andreas
Hi andreas
Aber nochmal zu den Regeln... Ich hab's gerade mal ausprobiert:
Das IDS ignoriert den Broadcast nur, wenn er explizit zugelassen wird, aber es gibt trotzdem Abhilfe...
Dazu brauchst du zwei Regeln, von denen die Erste den Broadcast zuläßt und die Zweite ihn blockt. Du mußt dafür sorgen, daß
a) die Allow-Regel zuerst matcht und
b) die Deny-Regel trotzdem ausgeführt wird.
Damit die Allow-Regel vor der Deny-Regel ausgeführt wird, benötigt sie eine höhere Priorität als die Deny-Regel.
Damit die Deny-Regel zusätzlich ausgeführt wird, mußt du in der Allow-Regel das Häkchen bei "Weitere Regeln beachten, nachdem diese Regel zutrifft" setzen.
Und schon ist Ruhe - zumindest was den Broadcast angeht...
Gruß
Backslash
Das ist doch schon ein Einbruchsversuch - er wird aber solange ignoriert, bis der Angreifer die Broadcastadresse trifft...Jetzt geht ein neugieriger Zeitgenosse hin und scannt den Bereich:
nein, denn es könnte ja gewollt sein...Ist da mein Provider gefragt und er muß in seinem Router den Zugriff auf 1.2.3.135 sperren
nein, das IDS schlägt ja schon bei der 135 zu...kann es ein, dass ein Zugriff auf 1.2.3.255 auch bei meinem Router landet
Aber nochmal zu den Regeln... Ich hab's gerade mal ausprobiert:
Das IDS ignoriert den Broadcast nur, wenn er explizit zugelassen wird, aber es gibt trotzdem Abhilfe...
Dazu brauchst du zwei Regeln, von denen die Erste den Broadcast zuläßt und die Zweite ihn blockt. Du mußt dafür sorgen, daß
a) die Allow-Regel zuerst matcht und
b) die Deny-Regel trotzdem ausgeführt wird.
Damit die Allow-Regel vor der Deny-Regel ausgeführt wird, benötigt sie eine höhere Priorität als die Deny-Regel.
Damit die Deny-Regel zusätzlich ausgeführt wird, mußt du in der Allow-Regel das Häkchen bei "Weitere Regeln beachten, nachdem diese Regel zutrifft" setzen.
Und schon ist Ruhe - zumindest was den Broadcast angeht...
Gruß
Backslash
Hi backslash,
Also, ich hab das so gemacht, funktioniert auch. Das IDS springt nicht mehr an, allerdings haben alle Rechner bei einem Ping auf .135 geantwortet. Das lag an einer anderen Regel, die Pings zulässt. Also habe ich die beiden Broadcastregeln noch eine Stufe höher gelegt:
bcast_allow prio 2
bcast_deny prio 1
die restlichen Regeln alle auf 0, so wie vorher. Jetzt antwortet der Router (.129) auf einen Ping an die .135, dass der Zielport nicht erreichbar ist, auch gut....
Aber noch etwas hat sich geändert. Ich habe zwei DSL-Zugänge auf dem Router: das besagte Netz und noch einen Account mit einem "normalen" Zugang, der ist als "Backupzugang" gedacht, wenn das eine Netz mal ausfällt. Wenn ich jetzt einen Ping auf diesen "Backupzugang" mache, wird der als IDS angezeigt, das hängt definitiv mit der Änderung zusammen hab es extra noch einmal rückgängig gemacht.
Tja....
Siehst Du eine Möglichkeit folgendes zu erreichen:
Pings auf die Adressen werden einfach beantwortet, wenn das entsprechende Device ok (vorhanden) ist, ansonsten nicht.
Zugriffe auf die IP's (auch die BCast-IP) werden erst als intrusion erkannt wenn die Anzahl > der eingestellte Wert ist.
Viele Grüsse,
Andreas
EDIT:
Wie wahrbackslash hat geschrieben:Und schon ist Ruhe - zumindest was den Broadcast angeht...

Also, ich hab das so gemacht, funktioniert auch. Das IDS springt nicht mehr an, allerdings haben alle Rechner bei einem Ping auf .135 geantwortet. Das lag an einer anderen Regel, die Pings zulässt. Also habe ich die beiden Broadcastregeln noch eine Stufe höher gelegt:
bcast_allow prio 2
bcast_deny prio 1
die restlichen Regeln alle auf 0, so wie vorher. Jetzt antwortet der Router (.129) auf einen Ping an die .135, dass der Zielport nicht erreichbar ist, auch gut....
Aber noch etwas hat sich geändert. Ich habe zwei DSL-Zugänge auf dem Router: das besagte Netz und noch einen Account mit einem "normalen" Zugang, der ist als "Backupzugang" gedacht, wenn das eine Netz mal ausfällt. Wenn ich jetzt einen Ping auf diesen "Backupzugang" mache, wird der als IDS angezeigt, das hängt definitiv mit der Änderung zusammen hab es extra noch einmal rückgängig gemacht.
Tja....
Siehst Du eine Möglichkeit folgendes zu erreichen:
Pings auf die Adressen werden einfach beantwortet, wenn das entsprechende Device ok (vorhanden) ist, ansonsten nicht.
Zugriffe auf die IP's (auch die BCast-IP) werden erst als intrusion erkannt wenn die Anzahl > der eingestellte Wert ist.
Viele Grüsse,
Andreas
EDIT:
Zumindest was die Interpretation als "möglicher Einbruch" bei einem einzelnen Zugriff auf die Broadcastadresse angeht würde ich mir das auch sehr wünschen. Ich persönlich würde auch mit der 'Krücke' leben, wenn sie denn nicht die o.g. Nebenwirkungen hätte. So ist das eigentlich gut Feature etwas schwer zu handeln.eddia hat geschrieben:Hallo Backslash,
nichts für ungut - aber wäre es mal nicht an der Zeit, das IDS konfigurierbar zu gestalten? Dann wären solche Krücken nicht notwendig.Dazu brauchst du zwei Regeln, von denen die Erste den Broadcast zuläßt und die Zweite ihn blockt.
Gruß
Mario
Hi andreas
Solange die Hauptverbindung besteht wird die Backupverbindung doch gar nicht aufgebaut...
Gruß
Backslash
was meinst du mit ping auf den Backupzugang?Wenn ich jetzt einen Ping auf diesen "Backupzugang" mache,
Solange die Hauptverbindung besteht wird die Backupverbindung doch gar nicht aufgebaut...
garantiert nicht! Die zwei Regeln dienen einzig und allein dazu das IDS mundtot zu machen... Dadurch können garantiert keine weiteren IDS-Meldungen auftauchen...wird der als IDS angezeigt, das hängt definitiv mit der Änderung zusammen hab es extra noch einmal rückgängig gemacht.
wie bereits gesagt: die Krücke dient nur dazu, das IDS mundtot zu machen und hat keinerlei weitere Nebenwirkungen...Ich persönlich würde auch mit der 'Krücke' leben, wenn sie denn nicht die o.g. Nebenwirkungen hätte. So ist das eigentlich gut Feature etwas schwer zu handeln.
Gruß
Backslash