intruder detected, Meldung alle 2-3 Minuten

Anmeldungsdatum: 04.01.2005 Beiträge: 66

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

Anmeldungsdatum: 31.01.2005 Beiträge: 115 Wohnort: München

andreas hat folgendes geschrieben:

Ist es möglich, dass auf der Broadcast-Adresse eine einzige Anfrage reicht, damit die Meldung ausgegeben wird?

Hallo Andreas,

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

Anmeldungsdatum: 04.01.2005 Beiträge: 66

AndreasMarx hat folgendes geschrieben:

Das IDS der LANCOMs mag es nicht, wenn Broadcasts von der WAN-Seite kommen.

Wobei das doch eigentlich keine Broadcasts sind, zumindest in meinen Logs, da wird meistens ein Zugriff von den "Windows-Ports" verzeichnet.

Ansonsten würde ich mir schon wünschen, dass das LCOS an dieser Stelle den Zugriff nicht fehl interpretiert.

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi andreas,

Zitat:

Wobei das doch eigentlich keine Broadcasts sind, zumindest in meinen Logs, da wird meistens ein Zugriff von den "Windows-Ports" verzeichnet.

wie AndreasMarx schon sagte: die x.x.x.135 ist in deinem Fall ein Broadcast.

Zitat:

Ansonsten würde ich mir schon wünschen, dass das LCOS an dieser Stelle den Zugriff nicht fehl interpretiert

Das ist keine Fehlinterpretation, sondern beabsichtigt.

Wenn du wirklich willst, daß Broadcasts für das LAN aus dem WAN erlaubt sind, dann mußt du sie explizit zulassen:

Code:

Quelle: alle Stationen
Ziel: Broadcastadresse (in deinem Fall x.x.x.135)
Aktion: übertragen

Das kannst du ggf. auch noch auf bestimmte Ports einschränken

Gruß
Backslash

Anmeldungsdatum: 04.01.2005 Beiträge: 66

Danke noch mal für die Erklärung, aber irgendwo stehe ich da noch auf der Leitung und würde das gerne verstehen.

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?

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi andreas

Zitat:

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?

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.

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

Anmeldungsdatum: 04.01.2005 Beiträge: 66

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.:

backslash hat folgendes geschrieben:

Schicke einfach mal unter Linux ein Ping an die Broadcast-Adresse und schau nach, wer sich da alles meldet...

ups

das war mir gar nicht so bewust.

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi andreas,

Zitat:

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?

Erstelle eine Regel, die die Broadcasts blockt und keine Meldungen erzeugt:

Code:

Quelle: alle Stationen
Ziel: Broadcastadresse (in deinem Fall x.x.x.135)
Aktion: Zurückweisen, alle Häkchen unter "Sonstige Maßnamen" aus

ggf. wieder zusätzlich auf bestimmte Ports beschränkt

Sinvoller wäre allerdings, die Broadcasts bereits beim Absender zu unterbinden...

Gruß
Backslash

Anmeldungsdatum: 04.01.2005 Beiträge: 66

Hi backslash,

danke für deine Geduld.

backslash hat folgendes geschrieben:

Erstelle eine Regel, die die Broadcasts blockt und keine Meldungen erzeugt

Hatte ich schon versucht, die Meldungen bleiben leider.

backslash hat folgendes geschrieben:

Sinvoller wäre allerdings, die Broadcasts bereits beim Absender zu unterbinden...

Irgendwie hab ich da immer noch ein Verständnissproblem, oder aber ich hab Euch noch etwas nicht richtig beschrieben.
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

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi andreas

Zitat:

Jetzt geht ein neugieriger Zeitgenosse hin und scannt den Bereich:

Das ist doch schon ein Einbruchsversuch - er wird aber solange ignoriert, bis der Angreifer die Broadcastadresse trifft...

Zitat:

Ist da mein Provider gefragt und er muß in seinem Router den Zugriff auf 1.2.3.135 sperren

nein, denn es könnte ja gewollt sein...

Zitat:

kann es ein, dass ein Zugriff auf 1.2.3.255 auch bei meinem Router landet

nein, das IDS schlägt ja schon bei der 135 zu...

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

Anmeldungsdatum: 15.11.2004 Beiträge: 1239

Hallo Backslash,

Zitat:

Dazu brauchst du zwei Regeln, von denen die Erste den Broadcast zuläßt und die Zweite ihn blockt.

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.

Gruß

Mario

Anmeldungsdatum: 04.01.2005 Beiträge: 66

Hi backslash,

backslash hat folgendes geschrieben:

Und schon ist Ruhe - zumindest was den Broadcast angeht...

Wie wahr

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:

eddia hat folgendes geschrieben:

Hallo Backslash,

Zitat:

Dazu brauchst du zwei Regeln, von denen die Erste den Broadcast zuläßt und die Zweite ihn blockt.

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.

Gruß

Mario

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.

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi andreas

Zitat:

Wenn ich jetzt einen Ping auf diesen "Backupzugang" mache,

was meinst du mit ping auf den Backupzugang?
Solange die Hauptverbindung besteht wird die Backupverbindung doch gar nicht aufgebaut...

Zitat:

wird der als IDS angezeigt, das hängt definitiv mit der Änderung zusammen hab es extra noch einmal rückgängig gemacht.

garantiert nicht! Die zwei Regeln dienen einzig und allein dazu das IDS mundtot zu machen... Dadurch können garantiert keine weiteren IDS-Meldungen auftauchen...

Zitat:

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.

wie bereits gesagt: die Krücke dient nur dazu, das IDS mundtot zu machen und hat keinerlei weitere Nebenwirkungen...

Gruß
Backslash