Snort... Was sind wirklich angriffe?

[killerhorse]

Hallo,

Seit einiger Zeit läuft auf meinem Server unter anderem SNORT. Es werden jedoch auch viele "Angriffe" angezeigt die meiner Meinung nach keine sind.
In der letzetzte Zusammenfassung z.B. waren folgende "Angriffsversuche:

(http_inspect) NON-RFC HTTP DELIMITER
WEB-PHP viewtopic.php access
ICMP PING NMAP
WEB-PHP read_body.php access attempt
WEB-MISC robots.txt access
WEB-CGI redirect access
WEB-CGI formmail access
MS-SQL Worm propagation attempt
FTP PASS format string attempt
(http_inspect) OVERSIZE CHUNK ENCODING
(http_inspect) BARE BYTE UNICODE ENCODING
ATTACK-RESPONSES 403 Forbidden

Wie kann ich nun erfahren was diese Angriffe wirklich sein sollen bzw warum Snort all das als Angriff bewertet?

MfG

Christian

[captaincrunch]

Wie kann ich nun erfahren was diese Angriffe wirklich sein sollen bzw warum Snort all das als Angriff bewertet?

Lies zunächst ganz genau sämtliche Doku, die du zu Snort finden kannst. Dann lies sie noch einmal. Dann fang an, die mitgelieferten Snort-Rulesets zu lesen und zu verstehen. Danach weißt du dann auch, was ein Angriff ist, und was nicht.

[killerhorse]

Das ist aber dann nicht wirklich sinnvoll...
Verwende Snort wie gesagt erst seit kurzem und hab es installiert, da es in einem hier empfolenem Buch ("Der eigene Webserver") hiess, es sei ein recht zuverlässiges Intrusion detection System.
Aber wenn ich erst überlegen muss was ein Angriff ist und was nicht, dann ist es glaub ich sicherer "nur" die Logfiles zu lesen, denn da fällt ein Ansehen meines Forums nich unter Alarm.
Ich bin der Meinung in dem "alert" File sollte nur dann was stehen wenn es sich wirklich un einen echten Angriff handelt.

bzw. Anders ausgedrückt:
Snort bedarf wohl einer aufwändigen Konfiguration um zuverlässig zu sein und ist kein wie in dem Buch dargestelltes "Installieren und fertig IDS" das man nach dem lesen von ca. 1-2 Seiten Verstehen kann.

MfG

Christian

[captaincrunch]

Das ist aber dann nicht wirklich sinnvoll...

Auch, wenn du es anders sehen magst, aber diese Vorgehensweise ist die einzig sinnvolle, wenn man ein solches IDS einsetzen will.

Verwende Snort wie gesagt erst seit kurzem und hab es installiert, da es in einem hier empfolenem Buch ("Der eigene Webserver") hiess, es sei ein recht zuverlässiges Intrusion detection System.

Oh toll...und ich hab mich schon gewundert, woher dieser neue "Trend", Snort einsetzen zu müssen kommt. ;) Mal ernsthaft: Snort ist schon ein verdammt gutes NIDS, setzt aber ein gerüttelt Maß an Fach- und Hintergrundwissen voraus.

Ich bin der Meinung in dem "alert" File sollte nur dann was stehen wenn es sich wirklich un einen echten Angriff handelt.

In dem Fall solltest du Snort wohl wirklich besser (erstmal) deaktivieren. Ohne eine gehörige Portion Feintuning ist ein IDS sonst wohl nichts für dich.

bzw. Anders ausgedrückt:
Snort bedarf wohl einer aufwändigen Konfiguration um zuverlässig zu sein und ist kein wie in dem Buch dargestelltes "Installieren und fertig IDS" das man nach dem lesen von ca. 1-2 Seiten Verstehen kann.

Du hast es erfasst! Ich hab's den anderen zuliebe, die es noch nicht verstanden haben noch mal fett gesetzt. ;)

[killerhorse]

Das ist aber dann nicht wirklich sinnvoll...

Auch, wenn du es anders sehen magst, aber diese Vorgehensweise ist die einzig sinnvolle, wenn man ein solches IDS einsetzen will.

Hab nicht gemeint, dass es sinnlos ist die Doku zu lesen, sondern, dass es im Moment für mich nicht sinnvoll ist Snort zu verwenden.

Werde dann wohl vorerst alle anderen mir bekannten Möglichkeiten ein System sicherer zu machen, noch optimaler einsetzen. Und die Logfiles beobachten (hab ja auch bei meinen IP-Tables Regeln einiges angegeben, was gesondert gelogt werden soll) und mich nur nebenbei mit Snort beschäftigen und irgendwann werde ich es dann zusätzlich einsetzen.

MfG

Christian

[dodolin]

Ich bin der Meinung in dem "alert" File sollte nur dann was stehen wenn es sich wirklich un einen echten Angriff handelt.

Das ist das Problem. Ein IDS kann das nicht "out-of-the-box" erkennen, denn das ist sehr systemspezifisch und das kann daher nur der Admin wissen. Wenn nun der Admin weiß, was auf seinem System ein "Angriff" und damit einer IDS-Meldung würdig ist, dann kann er sein IDS entsprechend konfigurieren. Es kann aber aus obigen Gründen systembedingt kein IDS geben, was out-of-the-box und für jedes System gleichermaßen und "gut" funktioniert.

Schade, wenn das im genannten Buch nicht so dargestellt wird. (Dient wohl der Auflage, wenn man es so darstellt, als wäre alles ein Kinderspiel :-/ ) IIRC wurde es nämlich hier im Forum schon des öfteren empfohlen.