Ich gebt mal ein paar kommentare aus meiner Sicht: At 21:02 27.08.03 +0200, Harald Huthmann wrote:
Hallo Michael,
Am Mittwoch, 27. August 2003 20:28 schrieb Michael Schulz
Harald Huthmann schrieb am 27.08.2003 um 19:59:29 +0200:
Am Mittwoch, 27. August 2003 19:40 schrieb Michael Schulz
Matthias Jänichen schrieb am 27.08.2003 um 19:23:30 +0200:
Das größte Problem ist die fehlende Unterstützung im Kernel. Dieses Manko behebt das MalwareScan Interface von RSBAC, das alle Syscalls überwacht und somit als echter Wächter arbeiten kann.
es ging im dem Test vor allen Dingen um Linux-Virenscanner im Server- einsatz mit heterogenen Clients. Da bringen dir die ueberwachten Syscalls des Linuxkernels nichts, denn Windows-Viren werden keine Linux-Kernel-Syscalls aufrufen ;-)
hätte ich auch fast geschrieben, aber: http://www.rsbac.org/nordse98.htm Das Ding scheint mehr zu können
Reichlich mehr, aber worauf es ankommt ist das Framework, das die Schnittstellen in den Syscalls bereitstellt. Die ganzen Zusätzlichen Dinge sind super, aber im Moment nicht Thema.
So wie ich das verstanden habe, geht es aber immer um oeffnen oder ausfuehren einer Datei auf dem _Linux_-Rechner.
Auch wenn eine Datei über ein Netzwerk einem anderen Client/Windose zur Verfügung gestellt wird, wird sie geöffnet/gelesen
Nicht auf den Windows-
Clients. Files die ueber ein Filesystem exportiert und auf dem Client importiert werden zaehle ich zu ersterem, also zum Linuxrechner.
Sehe ich auch so...
Wenn ich den Zugriff schon am Server sperren kann, baue ich damit eine zweite Hürde auf.
Was hilft mir ein Waechter, der wunderbar alles ueberwacht und scannt, was auf dem Linuxrechner passiert, wenn infizierte Dateien auf dem Windowsrechner ausgefuehrt werden?
Auf einen Wächter am Client kann/darf man nicht verzichten, denn es gibt da ja noch andere Quellen für Malware (Disketten/Internet) (https kan man definitonsgemäß nicht im GW scannen)
...nix...
stimmt nicht ganz, denn ich betreibe den Server ja für eine ganze Reihe von Clients...
Man muesste alles was $USER betrifft fuer die Windowskisten uebers Netz mounten, dann liegt alles auf dem Linux-Rechner und dort koennen diese Mechanismen greifen. Es darf aber nie ein File lokal auf den Windowsrechner gelangen, denn da kann dieser Mechanismus nicht greifen, denn er bekommt davon nichts mit. Also keine Floppy, keine CD-ROM/DVD. $USER darf nichts installieren.
Was nützt das, wenn die Schnittstellen am Client nach nem Overflow den Code ausführen (s. Blaster). Ohne Schutz am Client kannst Du alles vergessen!
Klar. Aber das ist bei jedem Virenscanner der auf der Linux-Kiste läuft nicht anders. Allerdings könnte man die Win-Clients an einer recht kurzen Leine halten, wenn man ihnen den Zugrff auf ihr locales Dateisystem abgewöhnt...
Vergiß es, das Filesystem ist heute nicht mehr das größte Problem...
Oder sehe ich das falsch?
Du siehst da sicher schon mehr als ich. Ich habe das nur "überflogen" und es mir für lange Winterabende aufgehoben.:-) Mich interessiert auch mehr die Überwachung von Linux bei dieser Sache.
Eben, wir müssen auch Linux in die Lage versetzten, jede Datei bei einem Zugriff zu überprüfen, dann ist es egal, ob da drauf über http, NFS, SAMBA oder lokal zugegriffen wird. Schaut euch mal RSBAC an, die Zugriffskontrolldinge sind auch super gelöst aber eine andere Baustelle. Für weitere Diskussionen zu RSBAC empfehle ich aber die RSBAC-Listen. Solange hier keiner was sagt, könenn wir gerne weiter über Viren diskustieren... Gruß Matthias