Guardian blockiert keine Angriffe

*cerox*

Lt. Commander
Registriert
Feb. 2005
Beiträge
1.357
Hallo zusammen,

ich habe hier auf einem Debian 3.1 System snort per apt installiert; das funktioniert auch alles soweit, er loggt usw...

Nun wollte ich mal guardian ausprobieren, der ja die logs in Echtzeit lesen, die IP Adressen eines eventuellen Angreifers extrahieren und dann die IP Adresse mit iptables blockieren soll.

Dazu habe ich die guardian.pl, guardian_block.sh und guardian_unblock.sh in /usr/local/bin kopiert. Die /etc/guardian.conf habe ich angepasst und die guardian.ignore in /etc ebenfalls.

Guardian starte ich mit: ./guardian.pl -c /etc/guardian.conf

Code:
OS shows Linux                                           
My ip address and interface are: 192.168.5.5       eth0  
Loaded 4 addresses from /etc/guardian.ignore             
Becoming a daemon..

Das funktioniert wie man sieht wunderbar.

Die log liegt in /var/log/guardian.log und dort stands anfangs wenn ich einen Angriff auf den Rechner starte, der auch im snort alert-log auftaucht:

Code:
Odd.. source = 192.168.5.8, dest = 192.168.5.5. No action done.

Zu dem Zeitpunkt waren die block/unblock-Scripte nicht ganz richtig, da dort noch ipchains eingetragen war; ich habe das jetzt abgeändert - die Scripte sind jetzt funktionstüchtig.

Mein Problem ist nun:

1) In der log taucht bei einem Angriff nichts mehr auf. Dort steht nur noch wann ich guardian starte und beende...

2) Er sperrt folglich auch keine IP-Adressen.

Weiß jemand woran das liegt? Der "Angreifer" steht nicht in der guardian.ignore.
 
Manchmal schicken die Debian-Paketler ein README mit und "verstecken" es irgendwo in /usr/share/doc/
Code:
find /usr/share/doc/ -iname README | grep guardian
Dort steht dann zum Beispiel, dass man Zeile xy erst auskommentieren muss, bevor das Skript funktioniert.
Hast Du sowas gefunden?
Poste mal deine /etc/guardian.ignore und deine /etc/guardian.conf
Vll ist irgendwo ein Denk/Tippfehler.
Änder sich die Ketten von iptables?
Code:
iptables -L
Hast Du zwei Netzwerkinterfaces, und das "falsche" wird von Guardian überwacht?
 
Hi,

danke erstmal für deine Antwort.

Manchmal schicken die Debian-Paketler ein README mit und "verstecken" es irgendwo in /usr/share/doc/

Ich kann leider nichts finden und wie sollte die ReadMe auch dahin gekommen sein; ich habe schließlich nur ein Archiv heruntergeladen, wo die Scripte und das Perl-Script drin waren. Die "normale" ReadMe von guardian habe ich ja auch genauso befolgt.

Änder sich die Ketten von iptables?

Nein, es ändert sich nicht; ansonsten würde der "Angreifer" ja auch blockiert, da die Regeln mit eingefügt (I) und nicht angehängt (A) werden. Die Regel müsste somit als erste INPUT-Regel auftauchen.

Hast Du zwei Netzwerkinterfaces, und das "falsche" wird von Guardian überwacht?

Nein, ich habe nur ein aktives, physikalisches Interface und Guardian überwacht das Richtige.

Da ich iptables und nicht ipchains, welches ja inzwischen veraltet ist, verwende, musste ich die block/unblock Scripte anpassen.

guardian_block.sh

Code:
#!/bin/sh                                                 
source=$1                                                 
interface=$2                                              
/sbin/iptables -I INPUT -s $source -i $interface -j DROP

guardian_unblock.sh

Code:
debian:/usr/local/bin# less guardian_unblock.sh            
#!/bin/sh                                                  
source=$1                                                  
interface=$2                                               
/sbin/iptables -D INPUT -s $source -i $interface -j DROP

guardian.conf

guardian.ignore

Der "Angreifer" hat die IP-Adresse 192.168.5.8.
 
Hat keiner mehr eine Idee was ich falsch machen könnte?
 
dass Du die Schritte, die Guardian mittels Skript ausführen soll, mal händisch machst.

Du meinst die block/unblock Scripte? Das habe ich ja bereits angepasst, so dass die iptables-Zeile definitiv korrekt ist und dass ich so Regeln einfügen kann. Ich weiß allerdings nicht was es mit den Variablen da in den Scripten auf sich hat, die, nehme ich mal an, vom Perl Script übergeben werden. Von Perl habe ich leider absolut keine Ahnung, wodurch ich das Script jetzt nicht mal eben kontrollieren kann.

Berechtigungen:
Sollten alle vorhanden sein - guardian läuft zum Test erstmal als root.
 
Die Werte scheinen leer zu sein.

Zum Test habe ich das Script mal verändert, so dass die Variablen erstmal keine Rolle spielen.

Code:
#!/bin/sh                                                                                         
/sbin/iptables -I INPUT -s 192.168.5.8 -i eth0 -j DROP

Dieses Script kann man wunderbar ausführen und es fügt auch die Regel korrekt in die INPUT-chaine ein.

Guardian macht weiterhin überhaupt nichts. Von daher liegt das Problem wahrscheinlich nicht an den Variablen, denn wenn guardian das abgeänderte Script nichtmal aufruft, kann das perl-Script auch keine Variablen übergeben.

edit:
Also es liegt definitiv am Perl-Script oder ich mache sonst was falsch. Ich habe zum Test mal "./guardian_block.sh 192.168.5.8 eth0" aufgerufen (so stand es anfangs als Kommentar; da stand, dass Perl Script würde es so aufrufen) und es funktioniert wunderbar.

Ich nehme an, Perl-Script liest die snort-alert nicht in Echtzeit oder gar nicht, denn es tauchen ja in der guardian.log auch keine Ereignisse auf, bis auf das Beenden und Starten des Dämons.
 
Zuletzt bearbeitet:
Zurück
Oben