Dazuko (on-access-scanner für clamav)

  • Halli hallo,

    ich bin gerade dabei, den ClamAV-Virenschutz für mein System aufzusetzen, da ich seit neuem auch anderen Leuten FTP-Zugang geben möchte und kein Bock auf z.B. eine ShellC99.php im Upload habe.
    Also, dachte ich mir, flugs ClamAV mit On-Access-Dazuko-Scanner installiert.
    Doch wieder einmal macht sich der Nachteil eines virtuellen vServers (nein, nicht versehentlich doppelt) bemerkbar:

    Code
    checking host system type... Linux
    checking for make utility... ok (make)
    checking for C compiler... ok (cc)
    kernel source in /lib/modules/2.6.31.7-vs2.3.0.36.27-beng/source... no
    kernel build source in /lib/modules/2.6.31.7-vs2.3.0.36.27-beng/build... no
    kernel build source in /usr/src/linux... no
    kernel source in /usr/src/linux... no
    error: no kernel source files found

    Gibt es eine Möglichkeit, FTP-Uploads von proftpd sofort zu sperren und zu scannen? Ich habe bei meinen Webhostern schon dieses Verhalten gesehen. Die versuchsweise hochgeladene ShellC99 wird umgehend gelöscht, keine Chance.

    Vielen Dank und liebe Grüße,
    Artimis

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Wie genau ist denn das verhalten des Webhosters?

    Bisher hast du folgendes erwähnt:
    ShellC99.php hochgeladen, wurde gelöscht.

    Was ist wenn du die gleiche Datei unter anderem Namen hochlädst? Wird diese dann angenommen?
    Falls ja deutet das zuerst nur auf eine einfache Namensüberprüfung hin.

  • Zitat

    Wie genau ist denn das verhalten des Webhosters?

    Bisher hast du folgendes erwähnt:
    ShellC99.php hochgeladen, wurde gelöscht.

    Was ist wenn du die gleiche Datei unter anderem Namen hochlädst? Wird diese dann angenommen?
    Falls ja deutet das zuerst nur auf eine einfache Namensüberprüfung hin.


    Natürlich habe ich die Datei nicht unter dem namen ShellC99.php hochgeladen. Sonst könnte ich ja gleich in die Polizeiwache stürmen und versuchen, einem Polizisten eine zu geben.
    Die Datei war getarnt als Funktion in einem Galeriemodul.
    Eine reine Namensüberprüfung wird denke ich mal von niemanden durchgeführt, weil es einfach Schwachsinn ist.
    Es wäre ja, als ich ich beim Banküberfall nicht belangt werden könnte, weil ich "Hände hoch, dies ist ein Blumentop" schreie.
    Sry für die Vergleiche, gucke gerade nen Krimi ;)

    Zitat

    Auf der Seite von ProFTPD gibt es eine Anleitung wie man Virenscanner in die Uploads einbindet: http://wiki.clamav.net/bin/view/Main/ProFTPD


    Danke für den Link! Ich bin zwar schon auf dieses Modul gestoßen, jedoch auf nicht sehr seriös wirkenden Seiten.

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Hmm, hier nochmal ich.

    Habe mir das Modul angesehen, jedoch keien Möglichkeit gefunden, es in den laufenden proftpd einzubauen.
    Neu kompilieren möchte ich das Ding eig. nicht, denn
    1) never touch a running system, wer weiß, wie viele Stunden ich wieder verliere. Ich sitze gerade STUNDEN beim Wechsel von Asterisk 1.6.0 auf Asterisk 1.6.2, weil die alten Konfig nicht gehen und die netcup-Server kein Dahd erlauben.
    2) Möchte ich den proftpd-Server gerne weiter über die Paketverwaltung aptitude updaten und ggf. deinstallieren können. Ich mag diese rumliegenden Sources nicht und der Updatevorgang gestaltet sich teilweise doch recht komplex (s. auch mein Asterisk, zuvor habe ich nämlich ein Update versucht in der Hoffnung, dass app_confbridge implementiert wurde).

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Das Modul brauchst du doch nur in der /etc/proftpd/modules.conf mit LoadModule einzubinden. Dafür müsstest du nur das oben genannte Modul kompilieren (mod_clamav.h und mod_clamav.c an gcc übergeben) und das fertige Modul in den richtigen Ordner kopieren. Notfalls einfach den Patch auf die ProFTPD Sourcen anwenden (wie auf der Seite beschrieben), kompilieren und nur das fertige Modul rüber kopieren. Solange du make install nicht ausführst sollte das so klappen, denn da bleibt dir dein ProFTPD aus der Paketverwaltung erhalten. Backup machen schadet natürlich trotzdem nicht :)

    Update: Ok, scheinbar braucht man trotzdem noch den angewendeten Patch. Der wirkt sich allerdings nur auf ein anderes Modul aus, dass man dann ebenfalls einfach austauschen könnte:


    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hmm, ich habe es eben probiert, es wird jedoch keine mod_clamav.SO erzeugt, die dann in /usr/lib/proftpd/ passen würde.
    Leider habe ich auf dem Gebiet des Kompilierens so gut wie kein Plan. Ein "./configure, make menuconfig, make, make install" kriege ich noch hin, das war es aber auch schon fast.

    Ich werde wohl doch den proftpd rausschmeißen und ersetzen müssen. :(

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Ich konnte das fertige Modul jetzt nicht austesten, folgendes habe ich am Testsystem einmal kompiliert


    Und danach existieren folgende zwei Module, die man theoretisch kopieren und in der Config aktivieren kann:

    Code
    proftpd/proftpd-1.3.3/modules/mod_clamav.o
    proftpd/proftpd-1.3.3/modules/mod_xfer.o


    Ob das so auch in der Praxis funktioniert weiß ich nicht, keine Ahnung wie ProFTPD damit umgeht. Dafür kenne ich mich mit der Thematik professionelle Programmierung mit Modulen o.ä. zu wenig aus.


    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Boa, nun bin ich völlig verwirrt.


    • Im Modulordner finde ich lediglich Dateien mit der Endung .SO
    • In der modules.conf des proftpd finde ich nur die Endung .C
    • Und du bietest mir nun Module mit der Endung .O an

    Häh? :D
    Ich bin zu blöde dafür.

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Ob .so und .o nun einen Unterschied macht: Keine Ahnung. Beides sind jedenfalls Binärdateien und sehen korrekt aus. Und .c ist halt die scheinbar interne Angabe, von den Original-C-Source-Dateien. Das ist beim Apache z.B. auch so.


    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ja, eben.
    Aber nun habe ich gerade auch noch gesehen, dass man bei den mod_clamav genau wie bei allen anderen Modulen eine .C-Datei einbinden soll.
    Allerdings finde ich nirgendwo im System diese .C-Dateien, lediglich die .SO-Dateien.

    Dass die .SO-Dateien und .O-Dateien vom Typ her identisch sind, mag stimmen. Aber wo sind die .C-Dateien, die proftpd in der Config erwartet?

    Code
    IfModule mod_clamav.c>
     ClamAV on
     ClamLocalSocket /tmp/clamd
    </IfModule>
    Code
    :/usr/lib/proftpd# ls
    mod_ban.so          mod_dynmasq.so    mod_ldap.so      mod_quotatab_file.so    mod_quotatab_sql.so  mod_rewrite.so    mod_sql_mysql.so     mod_wrap.so        mod_wrap2_sql.so
    mod_clamav.o        mod_facl.so       mod_load.so      mod_quotatab_ldap.so    mod_radius.so        mod_site_misc.so  mod_sql_postgres.so  mod_wrap2.so       mod_xfer.o
    mod_ctrls_admin.so  mod_ifsession.so  mod_quotatab.so  mod_quotatab_radius.so  mod_ratio.so         mod_sql.so        mod_tls.so           mod_wrap2_file.so
    Code
    :/tmp/tmp/proftpd-1.3.2/modules# ls
    Makefile     install-sh  mod_auth_file.c  mod_auth_unix.c  mod_cap.o     mod_core.c   mod_delay.c  mod_facl.c   mod_ident.c  mod_log.c  mod_ls.o    mod_xfer.c       module_glue.c
    Makefile.in  mod_auth.c  mod_auth_file.o  mod_auth_unix.o  mod_clamav.c  mod_core.o   mod_delay.o  mod_facts.c  mod_ident.o  mod_log.o  mod_site.c  mod_xfer.c.orig  module_glue.c.tmpl
    glue.sh      mod_auth.o  mod_auth_pam.c   mod_cap.c        mod_clamav.o  mod_ctrls.c  mod_dso.c    mod_facts.o  mod_lang.c   mod_ls.c   mod_site.o  mod_xfer.o       module_glue.o

    Boa, ey, mir wummert der Schädel. Nicht nur den verflixten Asterisk wieder in Gang setzen und das bei massiv lagenden Server (s. anderen Threat), nebenher auch noch zwei Reklamationen, Stress mit Kabel Deutschland, weil die ihre Rechnungen mind. doppelt bezahlt haben wollen, Mathematik lernen fürs Studium und voll die Erkältung dazu.

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Baldige Besserung!

    Na die hat man doch vorher kopiert:

    Code
    cp mod_clamav-0.10/mod_clamav.* proftpd-1.3.3/contrib


    Und eingebunden werden sie durch folgende Zeile vom Patch:

    Code
    #include "mod_clamav.h"


    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Eine .o Datei ist überlicherweise eine kompilierte .c Datei. Da ein Programm aber aus mehreren Teilen, sprich .c Dateien bestehen kann, müssen diese .o Dateien mit dem Linker zusammengefügt werden. Das kann entweder statisch passieren, dann gibt es eine Datei ohne Endung, oder dynamisch, dann produziert der Linker eine .so (shared object file, auch library genannt). So eine .so kann dann zur Laufzeit von einem Programm nachgeladen werden, dynamisch eben.