Seite 3: Alarm, Alarm!

Inhaltsverzeichnis

Alarm, Alarm!

Entdeckt ein Wächter eine befallene Datei, modifiziert er den Fehlercode, den das Betriebssystem an die Anwendung zurückliefert. Manche Anwendungen ignorieren solche Fehlercodes vollständig, aber auch aus einer Rückmeldung wie "Speichern fehlgeschlagen" oder "Write Error" kann der Benutzer kaum auf die eigentliche Fehlerursache - Virenbefall - schließen. So ist es unumgänglich, dass ein Wächter weitere Methoden kennt, um Nutzer und Systemverwalter zu informieren. Bei den auf Samba fixierten Produkten geht das in der Regel über den Windows-Nachrichtendienst, über den sie eine Meldung an den betroffenen Benutzer zustellen. Andere Programme greifen auf E-Mail zurück oder können SNMP-Alerts auslösen, die dann in der Regel aber nur den Administrator erreichen. Mit etwas Mühe mag der geneigte Systemverwalter auch eigene Verfahren ergänzen können.

Auch die Art der Implementierung der einzelnen Produkte variiert: Die schlichteren beschränken sich auf einen einfachen Kommandozeilenscanner. Andere bringen einen Daemon mit, der den Scanvorgang beschleunigt: Der Daemon lädt die Scanengine und die Signaturen und hält sie ständig im Speicher parat. Im einfachsten Fall reicht der On-Demand-Scanner dann die zu scannenden Dateien einfach an den Daemon weiter. Das wirkt sich vor allem dann positiv aus, wenn häufig viele Dateien zu scannen sind - etwa bei einem Mailserver.

Produkte mit On-Access-Wächter kommen ohne Daemon nicht aus; schließlich kann ein Kernel-Modul schlecht Prozesse starten, etwa den Scanner anwerfen. Bei manchem Produkt bietet der Daemon nicht nur dem hauseigenen Scanner seine Dienste an, sondern auch anderen Prozessen. Das Samba-vscan-Modul etwa nutzt diese Schnittstelle, um mit verschiedenen Scannern zu kommunizieren -- mit einem reinen Kommandozeilenscanner kommt es nicht aus.

Noch muss man das Samba-vscan-Modul an den jeweils verwendeten Virenscanner anpassen -- Standards für die Kommunikation zwischen Scan-Daemon und anderen Serverdiensten sind erst im Entstehen. Seit einigen Monaten existiert für solche Content-Filter respektive -Prüfer immerhin ein RFC, der das "Internet Content Application Protocol" (ICAP) beschreibt [3] - einzig Symantec hat derzeit eine fertige Implementierung an Bord.

Bleibt die Frage, was mit einer infizierten Datei zu tun ist. Bei On-Demand-Scannern reicht es, wenn sie die befallenen Dateien in einem Format protokollieren, das sich vernünftig weiterbearbeiten lässt. Der Administrator kann dann beispielsweise mit Linux-Bordmitteln ein Skript schreiben, das die gewünschten Maßnahmen -- löschen, in ein Quarantäneverzeichnis verschieben, Zugriffsrechte entziehen -- vornimmt, so sie das Programm nicht selbst anbietet. Ein (halb-)automatisches Desinfizieren wird im Unternehmensumfeld kaum eine Option sein, zu groß ist die Gefahr, dass die Malware nicht korrekt entfernt oder die Datei beschädigt wird. Zudem bleibt das Risiko, dass beispielsweise ein Makrovirus Daten in einem befallenen Excel-Sheet manipuliert hat.

Wächter müssen auf jeden entdeckten Schädling sofort reagieren. Auch hier ist Desinfektion keine ernsthafte Option; in vielen Unternehmen gilt grundsätzlich die Policy, infizierte Dateien zu löschen und vom letzten Backup zu restaurieren. Die andere Möglichkeit, die die getesteten Wächter ebenfalls alle anbieten, ist ein Blockieren jedes weiteren Zugriffs auf die betroffene Datei.