HINWEIS: Aufgrund der letzten Umstrukturierungen haben sich teilweise Änderungen in der Abfolge ergeben, sodass es zu unerwarteten Fehlermeldungen kommen kann. So auch in diesem Tutorial. Du brauchst für den Virenscanner die Kernel-Quellen. Wie du diese für dein System installierst findest du unter Punkt 3 bis 5 unter "Jails mit EzJail".
Um einen sogenannten "OnAccess-Virenscanner" zu installieren, brauchen wir unter FreeBSD das Modul "Dazuko". Dieses ermöglicht uns den OnAccess-Zugriff, ist also alleine kein Virenscanner. Als Virenscanner verwenden wir den OpenSource-Scanner "ClamAV". Der OnAccess-Scan ist noch experimentell, daher teste es erst auf deinem System bevor du es in den Produktiveinsatz übernimmst.
- Um beim Starten eines der Dienste später keinen Fehler bzgl. einer nicht vorhandenen 'libc.so.5' zu erhalten, erstellen wir einfach einen (Soft-)Link auf die 'libc.so.6', die sich im Verzeichnis '/lib' befindet:
# ln -s libc.so.6 libc.so.5 - Zunächst kompilieren wir das Modul 'Dazuko' aus den Ports, da ich mit dem Package ein Problem hatte. Es wurde bei mir nicht sauber installiert.
# cd /usr/ports/security/dazuko && make install clean
Hinweis: Unbedingt die Hinweise während der Installation beachten, wie das Modul geladen werden muss! - Jetzt laden wir das Modul, falls das nicht während der Installation passiert ist:
# kldload dazuko - Um das Modul beim Systemstart zu laden, editieren wird die Datei '/etc/rc.local' und schreiben folgende Zeile hinein:
/usr/sbin/kldload dazuko - Aus den Ports installieren wir jetzt den ClamAV. Dieser befindet sich im Verzeichnis '/usr/ports/security/clamav'. Um den OnAccess-Scan zu nutzen, müssen wir die Datei "Makefile" bearbeiten und zwar die Zeile "--disable-clamuko" löschen oder duch "--enable-clamuko" ersetzen.
# make install clean
Wir müssen nun '/dev/dazuko' noch an den Benutzer "clamav" übergeben:
# chown clamav:clamav /dev/dazuko - Für etwas Verwirrung sorgen manchmal (bei mir zumindest
) die verschiedenen Programme, die zu ClamAV gehören. Hier also eine kurze Übersicht welches Programm welche Aufgaben übernimmt: - clamd: Das ist der Daemon, der im Hintergrund auf Virenprüft. Dieser wird später auch "OnAccess" scannen.
- clamscan: Hiermit kannst du Dateien manuell scannen lassen. Du hast bspw. eine Datei heruntergeladen und willst diese auf Viren prüfen, dann nimmst du den clamscan.
- freshclam: Dieser Dienst hält deine Virendatenbank auf dem aktuellen Stand. Er wird auch im Hintergrund laufen und in einem festgelegten Rhythmus die Datenbank aktualisieren.
- clamdscan: Dies ist ein clamd-Client. Er macht das gleiche wie auch das Programm clamscan, hängt aber nur vom clamd ab.
- clamuko: Ist die OnAccess-Unterstützung. Sie muss in der clamd.conf aktiviert werden.
- Zu allererst passen wir die Konfiguration des Update-Dienstes "freshclam" an. Wir passen also die Datei '/usr/local/etc/freshclam.conf'. Die Datei ist gut kommentiert, ich sage dir nur was ich geändert habe:
- DNSDatabaseInfo current.cvd.clamav.net
- DatabaseMirror db.de.clamav.net
- ScriptedUpdates yes
- OnErrorExecute mail -s "FreshClam-Fehler: Update Fehler!" email@adresse.de
Im Falle eines Update-Fehlers, erhalte ich eine eMail.
Nach dem Speichern kannst du die Konfiguration an freshclam übergeben und gleichzeitig prüfen, dass du keinen Fehler gemacht hast:
# freshclam - Abschließend müssen wir noch den ClamAV konfigurieren. Das erfolgt über die Datei '/usr/local/etc/clamd.conf'. Ich verwende hier die Default-Konfiguration. Lediglich die Clamuko-Konfiguration habe ich wie folgt angepasst:
- VirusEvent mail -s "Virus gefunden: %v" email@adresse.de
- ClamukoScanOnAccess yes
- ClamukoScanOnOpen yes
- ClamukoScanOnClose yes
- ClamukoScanOnExec yes
- ClamukoIncludePath /
- ClamukoExcludePath /proc
Alle Verzeichnisse (Unterverzeichnisse sind dann eingeschlossen) solltest du in jeweils eine Zeile schreiben. Andere Verzeichnisse, die du ausschließen könntest, wären bspw. '/dev' oder '/cdrom' oder '/usr/ports'.
HINWEIS: Du solltest, wenn du mit den Ports arbeitest, das Verzeichnis '/usr/ports' unbedingt ausschließen. Überlege dir auch genau, welche der "On-"-Funktionen zu verwenden willst. So wie ich es hier darstelle, ist die Prozessorlast maximal und das Entpacken der Ports bspw. dauert sehr sehr lange. Je nach Rechenleistung solltest du dir das also überlegen. - Damit Freshclam und Clamd beim Systemstart auch starten, tragen wir noch folgende Zeilen in die '/etc/rc.conf' ein:
clamav_clamd_enable="YES"
clamav_freshclam_enable="YES" - Anschließend starten wir den "clamd" neu, sodass die Konfiguration bekannt ist:
# /usr/local/etc/rc.d/clamav-clamd.sh restart - Wenn das dazuko-Modul geladen wird, wird ein Device '/dev/dazuko' angelegt, allerdings hat es die falschen Berechtigungen. Jetzt gibt es zwei Möglichkeiten dies zu beheben, wobei ich festhalten muss, dass die zweite eleganter und empfehlenswert ist.
1) Erstelle eine Datei '/usr/local/etc/dazuko-fixown.sh' und schreibe folgende Zeilen hinein:DAZUKO_DEVICE=/dev/dazuko
Jetzt sorgen wir noch dafür, dass das Skript ausführbar ist und nach dem Laden des dazuko-Moduls gestartet wird. Dies erreichen wir indem wir folgende Zeile in die Datei '/etc/rc.local' NACH der Zeile '/usr/sbin/kldload dazuko' eintragen:
if [ -e $DAZUKO_DEVICE ]; then
chown clamav:clamav /dev/dazuko
fi/usr/local/etc/dazuko-fixown.sh
Anschließend, um es ausführbar zu machen, geben wir noch folgenden Befehl ein:
# chmod u+x /usr/local/etc/dazuko-fixown.sh
Damit wird bewirkt, dass das Dazuko-Device dem richtigen Besitzer gehört.
2) (besser!!): Trage in die Datei '/etc/devfs.rules' folgende Zeile ein (Danke an Markus Mann):
[localrules=10]
add path 'dazuko' mode 0700 user clamav group clamav
devfs_system_ruleset="localrules"
Jetzt kannst du entweder den Server neustarten oder das Modul entladen, devfs neustarten, das dazuko-Modul wieder laden und die Berechtigung im Verzeichnis '/dev' überprüfen:
# kldunload dazuko
# /etc/rc.d/devfs restart
# kldload dazuko
# ls -la | grep dazuko
Jetzt haben wir den Virenscanner schonmal erfolgreich am Laufen. Sehr gut. Als weiteren Schritt installieren wir nun noch den "Rootkit Hunter" (kurz: RkH). Dieser wird unseren Server regelmäßig nach Rootkits durchsuchen.
ACHTUNG: Der Rootkit Hunter SUCHT nach Hinweisen auf Rootkits, er entfernt sie aber NICHT! Warum nicht? Nun, auch eine sehr gute Software kann Fehler machen und auf einem Server kann das große Schäden verursachen. In der Readme/FAQ des RkH stehen viele wichtige Hinweise dazu, was zu tun ist wenn der Hunter anschlägt!
- Wir installieren auch den Rootkit Hunter über die Ports:
# cd /usr/ports/security/rkhunter && make install clean - Wie du den Installationshinweisen entnehmen kannst, müssen wir folgende Zeilen in die Datei '/etc/periodic.conf' einfügen, um die Definitionen aktuell zu halten:
daily_rkhunter_update_enable="YES"
daily_rkhunter_check_enable="YES" - Jetzt müssen wir den RkH noch konfigurieren. Dafür müssen wir die Konfigurationsdatei '/usr/local/etc/rkhunter.conf' anpassen. Schau dir die Kommentare in der Beispieldatei an und passe sie an deine Bedürfnisse an. Ziehe auch die Website/das Handbuch zu Rate.
Für mich erstmal wichtig ist die Option "MAIL-ON-WARNING". Hier trage deine eMail-Adresse ein, an die Benachrichtigungen geschickt werden sollen. Das ist sehr wichtig! Anschließend sollten wir noch ein Update machen:
# rkhunter --update
Ein weiteres Tool ist "chkrootkit". Dieses ist vielleicht noch bekannter als der Rootkit Hunter. Doppelt genäht hält besser, daher setzen wir dieses Tool auch noch ein. Installieren ist ganz einfach:
- Wir installieren das Tool wie gewohnt aus den Ports:
# cd /usr/ports/security/chkrootkit/ && make install clean - Starten können wir "chkrootkit" mit folgendem Befehl. Es werden alle Tests durchgeführt:
# /usr/local/sbin/chkrootkit
Mit folgendem Befehl kannst du dir die verfügbaren Tests ausgeben lassen, die du dann per Parameterübergabe auch einzeln aufrufen kannst:
# /usr/local/sbin/chkrootkit -l - Abschließend würde ich noch empfehlen, einen Cronjob einzurichten, der täglich auf Rootkits prüft. Ich rate allerdings den Test nicht gleichzeitig mit RKHunter laufen zu lassen.
Einen Kommentar hinzufügen
Hi Michael,
Du kannst die Update-Funktion abschalten wenn du möchtest, empfehle ich dir aber nicht.
Du solltest einfach eine Firewallregel anlegen, die Zugriff auf http://rkhunter....net erlaubt. Damit sollte das dann funktionieren.
Dass er gehackt wurde ist nicht gut. Wie sind die auf deinen Server gekommen? Hattest du ihn nicht ausreichend geschützt oder war es ne Lücke in Plesk oder ne anderen Software?
Schönen Gruß,
Benedikt
Hallo Benedikt,
danke für die schnelle Antwort.
Ja, rkhunter ist bei Plesk (8.2.0) mit dabei. habe jetzt wieder jeglichen ausgehenden Traffic freigegeben, damit funktionierts wieder. rkhunter will auf dem Server http://rkhunter.sourceforge.net nachschauen, ob es einen aktualisierte Datei gibt. Dies war ja durch sperren des Traffics nicht möglich.
Ich hatte das Problem, das der Server gehackt wurde und als Filesharingserver benutzt wurde und zusätzlich noch ausgehende DoS Attacken veranstaltete.
Jetzt schaue ich mal die Tage,
Gruß
Michael
Hi Michael,
Kenne mich mit Plesk leider nicht aus, aber kann es sein, dass du in der Firewall den Zugriff auf 127.0.0.1 auch in irgend einer Weise blockierst?
Habe mal kurz gesuchmaschint und nur herausgefunden, dass rkhunter bei Plesk schon mit dabei ist. In dem Fall solltest du vielleicht mal bei SWSoft nachfragen. Auf der Website habe ich auch nix zu nem Port gehört.
Ich bin mir nicht sicher ob rkhunter überhaupt einen Port benötigt, da es nicht als Dienst läuft, sondern meines Wissens nach nur Dateien prüft, ist ja kein Portscanner, aber vielleicht irre ich mich.
Was bedeutet "wird nicht ausgeführt", das Update nicht oder garnix? Blockierst du den Datenverkehr von innen nach außen?
Ich habe für rkhunter keinen Port freigegeben, blockiere aber auch keinen Verkehr von innen nach außen.
Wenn du den Fehler findest wäre es schön wenn du es mir mitteilst. Schreib mir auch gerne ne E-Mail diesbezüglich...
Gruß,
Benedikt
Kann mir jemand sagen, über welchen Port (tcp, udp) rkhunter mit dem Server kommuniziert?
Plesk 8.2 mit der internen Firewall.
offene Ports nur die üblichen, Rest ist zu.
Habe das Problem, das rkhunter nur ausgeführt wird, wenn der Rest der Ports offen ist, dies möchte ich aber nicht.
Ich bin so blind... Danke dir! Jetzt funktionierts wie gewollt!
RTFMC ;-)
Gruß,
Benedikt
Hallo!
Sorry for the delay ];-) Ausprobiert habe ich das nicht (jedenfalls nicht für dazuko), aber hast du diesen Absatz aus der Manpage beachtet?
<manpage="devfs.rules">
One custom ruleset has to be enabled in /etc/rc.conf, otherwise it will not be applied to the /dev file system by the default system startup process. For example, to enable a ``localrules'' ruleset for the /dev file system, you would have to use something like this in your rc.conf file:
devfs_system_ruleset="localrules"
</manpage>
Das setzt sich auch im
@Markus Mann: Ich habe es mit devfs.rules probiert, aber das funktioniert bei mir auch nicht. Er setzt nicht einmal die Gruppe richtig. Hast du es bei dir probiert und es funktioniert?
Gruß,
Benedikt
Hallo!
Stimmt auffällig: /etc/devfs.conf ist nur für Devices, die beim Booten schon existieren. Für später dazukommende kann man /etc/devfs.rules bemühen (ist leider eine Spur weniger intuitiv zu konfigurieren finde ich).
Ciao.
Markus Mann
@Markus Mann: Ich habe das mal ausprobiert so wie du das beschrieben hast, aber es hat bei mir nichts geholfen.
Ich kenne mich mit devfs nicht so gut aus, daher geht meine Vermutung bzgl. der Ursache dahin, dass devfs nicht mehr greift, da das Modul "manuell" über die rc.local geladen wird und devfs dann nicht mehr reagiert?
Ich hatte versucht dazuko in den Ordner /boot/kernel zu kopieren und in die /boot/loader.conf "dazuko_enable='YES'" einzutragen, allerdings resultierte eine Kernel panic.
Vielleicht kannst du mir näher erläutern, wie das machbar ist?
Würde mich freuen wenn du auf mich zurück kämst.
Gruß und danke für die Anmerkung,
Benedikt
Hallo!
Punkt 11 kann man IMHO eleganter lösen (zumindest seit FreeBSD 5 mit devfs). Man trägt in die /etc/devfs.conf ein:
# Allow clamav everything on dazuko
own dazuko clamav:clamav
Damit erspart man sich die Änderung eines Startskriptes, das beim nächsten Update von clamav wieder jungfräulich würde.
HTH & Ciao.
Markus