Virenscanner und Datenbanksysteme (Fokus PostgreSQL^®)

Viele Nutzer sind durch Herstellervorgaben, Verordnungen oder Arbeitsanweisungen dazu gezwungen, auf sämtlichen IT-Geräten Virenscanner zu betreiben. Diese Verallgemeinerung kann gerade dann, wenn es nicht um klassische Desktops oder Dateiserver geht, zu Problemen führen.

Nach landläufiger Auslegung des Grundschutzes ist dieser gewährleistet, wenn auf allen Systemen ein Virenscanner vorhanden ist und die Signaturen aktuell gehalten werden. Die Einhaltung der beiden Kriterien kann über ein klassisches Monitoring überwacht werden.

Probleme treten jedoch oft dann auf, wenn sogenannte On-Access-Scanner aktiv sind und in die Arbeit mit dem Dateisystem eingreifen. Die PostgreSQL^®-Entwickler raten sogar dringend von der Verwendung von Antivirensoftware ab!

Virenscanner

Was sind (On-Access-) Virenscanner und weshalb werden sie benötigt? Große Teile der verwendeten (Endanwender-) Software unterscheidet nicht klar zwischen Code und Daten. So enthält eine reine Textdatei ausschließlich Daten und keinen Programmcode, es besteht keine Notwendigkeit je einen Teil einer Textdatei als Code zu interpretieren und auszuführen. Leider wird diese Trennung nicht flächendeckend praktiziert. So können viele Dateien z.B. Office-Dokumente sowohl Daten als auch Code enthalten. Hierdurch ergibt sich ein Angriffsvektor. Angreifer können Code in Daten verstecken, der dann unbemerkt vom Nutzer ausgeführt wird.

Da das zugrundeliegende Problem aufwendig zu lösen und auch keine positive Tendenz ersichtlich ist, bieten Virenscanner in vielen Bereichen eine Linderung der Symptome. So ist es gängige Praxis und sinnvoll, eingehende Fremddaten und nicht vertrauenswürdige Nutzereingaben zu validieren und zu prüfen. Hierbei werden diese mit einer Blacklist von bekannten Angriffsmustern verglichen und im Falle einer Übereinstimmung entsprechend behandelt.

Auch wenn neue, maßgeschneiderte oder unbekannte Angriffe durch solche Systeme nicht erkannt werden können, kann die Kosten-Nutzen-Rechnung doch an einigen Stellen aufgehen.

Arbeiten mit dem Dateisystem

Möchte eine Anwendung (A) Daten lesen oder schreiben erfolgt die Interaktion mit dem Speichermedium (B) über Systemcalls. Die Anwendung übergibt die zu schreibenden Daten und erhält eine Bestätigung zurück, ob die Daten erfolgreich geschrieben wurden, bzw. im Fehlerfall einen entsprechenden Fehlercode.

Funktionsweise Echtzeitscanner

Ein Echtzeitscanner oder On-Access-Scanner greift nun in diesen Ablauf ein und setzt sich selbst als Man-in-the-Middle zwischen Applikation (A) und Hardware (B). Der Linux-Kernel bietet hierfür seit einiger Zeit die API fanotify. Verschiedene Hersteller verwenden aber oft eigene, nicht standardisierte Verfahren, um in den Datenstrom einzugreifen. Es gibt diverse mögliche Eingriffspunkte – z.B. die Applikationen selbst oder verwendete E/A-Bibliotheken. Auch Eingriffe in das Dateisystem werden verwendet.

Problem Performance

Durch den Eingriff in die E/A-Zugriffe werden diese deutlich aufwendiger! Je nach Eingriffspunkt und verwendeter Scanengine werden Speicherzugriffe um Größenordnungen langsamer. Auf Office-Desktopsystemen oder Applicationservern (stateless) sind auf Grund niedriger IO und weniger Writes oft keine starken Auswirkungen spürbar. Auf schreiblastigen Systemen können diese jedoch gravierend sein. Wenn viele kleine Bereiche beschreiben werden und es nicht nur auf den mittleren Datendurchsatz, sondern um das schnelle Abarbeiten einzelner Schreibvorgänge mit niedrigen Latenzen geht, ist mit großen Einbußen zu rechnen.

Durch ihre speziellen Nutzungsmuster und komplexe Dienstfunktionalität sind Datenbanksysteme besonders betroffen. Hinzu kommt noch, dass beim eigentlichen Scanvorgang auch CPU-Zeit benötigt wird. Je nach eingesetzter Antiviren-Lösung kann es auch hier zu Engpässen kommen.

Problem Datensicherheit

Wenn zum Abfangen der E/A-Anfragen nur die kerneleigenen APIs verwendet werden, erhöht sich bereits die theoretische Fehlerwahrscheinlichkeit, da mehr Code ausgeführt wird und die Vorgänge komplexer werden. In der Praxis verkompliziert sich hierdurch zwar Debugging und Fehlersuche, mit deutlichen Einbußen in der Datensicherheit ist jedoch nicht zu rechnen, korrekte API-Verwendung vorausgesetzt. fanotify ist jedoch derzeit in den verbreiteten Antivirenlösungen nicht der Standard.

Durch die eigene Implementierung von E/A-Hooks bietet sich eine ganze Menge Fehlerpotenzial. So konnten wir bei der Ursachenermittlung eines korrupten Datenbanksystems sehen, dass die Antivirenlösung E/A-Fehler von Hardware und Treibern teils nicht weitergeleitet hat.

Fehlerbeispiel:

1. Die Datenbank sendet eine Schreib-Anforderung an das Dateisystems (8k-Block schreiben, Herausschreiben auf Platte)
2. write() wird von der Antivirenlösung abgefangen
3. Der Virenscanner überprüft die Daten (kein Fund)
4. write() wird an das Dateisystem weitergegeben
5. Das Dateisystem übermittelt die Daten per Treiber an die Hardware
6. Es tritt ein Hardwareproblem auf! Daten können nicht geschrieben werden!
7. Der Treiber meldet dem Dateisystem den Fehler
8. Das Dateisystem meldet dem Virenscanner den Fehler
9. Der Virenscanner “verschluckt” den Fehler und meldet der Datenbank das erfolgreiche Schreiben
10. Die Datenbank meldet dem Client die erfolgreiche Dürchführung einer Transaktion

So entstand eine schleichender Datenverlust, der erst entdeckt wurde als den Nutzern der angeschlossenen Systeme Fehler in den Bestandsdaten auffielen. Der Virenscanner hat hier durch sein nicht standardkonformes Verhalten eine der Kernfunktionalität des Datenbanksystems sabotiert.

PostgreSQL^®

PostgreSQL^® praktiziert eine strikte Trennung zwischen Daten und Code. Einträge in Tabellen, auch in Binärblöcken, können designbedingt nicht ausgeführt werden.

Aufgrund dieser strikten Trennung ist es für PostgreSQL^® selbst nicht notwendig, den eigenen Datenbestand auf Viren zu untersuchen. Für weniger gut differenzierende Anwendungssoftware kann es jedoch sinnvoll sein, Teilmengen zu überprüfen. Werden in der Datenbank beispielsweise Emails oder Dateien, die Code enthalten (z.B. Office-Dokumente), abgelegt, kann es durchaus Mehrwert bieten, diese Spalten auf bekannte Schadsoftware hin zu überprüfen.

In der Praxis wird hier jedoch fast immer ein generischer Echtzeitscanner verwendet, der nicht nur die erforderlichen Bereiche prüft, sondern On-Access-Methoden verwendet, und daher sämtliche im ersten Teil angesprochenen Probleme mit sich bringt.

Schadsoftware gefunden, was nun?

Erschwerend kommt hinzu, dass die Bearbeitung von Schadsoftware-Funden bei einer externen Software sehr schwer ist. Was soll z.B. im Falle eines gefundenen trojanischen Pferds passieren?

Automatischer Eingriff

Auf einem Desktop-System möchte man beispielsweise, dass die betroffene Datei in Quarantäne verschoben oder gelöscht wird. Mit dem Betrieb eines Datenbank-Servers ist solches Verhalten jedoch nicht vereinbar. Da es sich bei den Dateien um die physische Repräsentation der Datenbasis handelt, wird durch diesen Mechanismus Datenkorruption verursacht, die sich z.B. als stiller Datenverlust oder auch Verletzung von Konsistenzbedingungen wie das Nichterkennen von Duplikaten äußern kann.

Alarmierung

In der Praxis ist es daher meist sinnvoll, nur Alarmierungen zu erzeugen, die dann von einem Administrator bearbeitet werden. Doch was ist das geeignete Vorgehen, wenn der Virenscanner gestern Nacht eine Infektion der Datei “/var/lib/postgresql/11/main/base/13090/1255” gemeldet hat?

• Wo ist der infizierte Code in der Datenbank?
• Wo kam er her?
• Ist die Meldung überhaupt richtig? False-Positive?

Gibt es bereits zufriedenstellende Lösungen?

Der beschriebene Status-Quo erfüllt offensichtlich nicht alle Anforderungen. Gibt es für Datenbanken (PostgreSQL^®) eine bessere Lösung?

Derzeit bleibt die Überprüfung in der Anwendung oder Fremdsystemen die verbreitetste Methode. Verschiedene Hersteller bieten auch Netzwerk-Virenscanner an, die den Netzwerkverkehr überwachen und durchsuchen. Aber auch hier gibt es viele der bereits angesprochenen konzeptionellen Schwächen, z.B. wie ein Fund behandelt wird.

Lösungsversuch

Wünschenswert wäre es, die Überprüfung auf Schadcode und auch die Behandlung von Funden im Datenbanksystem selbst abzuwickeln. Optimalerweise per SQL-Schnittstelle, so dass Entwickler oder DBAs die Funktionalität in den normalen Anwendungsbetrieb integrieren können.

So könnte genau definiert werden, wann welche Eingabe zu überprüfen ist. Positiv-Funde können dann über die gemeinen SQL-Fehlercodes gemeldet werden, und würden nicht länger die Dienstfunktionalität gefährden. Man könnte sich beispielsweise eine Tabelle mit einer Text-Spalte vorstellen, in der Usereingaben gespeichert werden. Nun kann vor jedem INSERT oder UPDATE überprüft werden, ob bekannter Schadcode vorliegt und die Eintragung per CONSTRAINT verhindert werden.

Um die Machbarkeit einer solch integrierten Antivirenlösung aufzuzeigen, hat credativ die PostgreSQL^®-Erweiterung pg_snakeoil veröffentlicht. Diese macht die Funktionen von ClamAV in der SQL-Welt zugänglich, und erlaubt eine Schadcode-Prüfung bei voller ACID-Konformität. pg_snakeoil wurde unter der PostgreSQL^®-Lizenz veröffentlicht und kann in der aktuellen Version bei Github gefunden werden.

Unterstützung

Falls Sie Unterstützung bei PostgreSQL^®, Malware-Prävention, IT-Grundschutz oder anderer Aspekte der IT-Infrastruktur benötigen, steht Ihnen unser Open Source Support Center zur Verfügung – Falls gewünscht auch 24 Stunden am Tag, an 365 Tagen im Jahr.

Wir freuen uns über Ihre Kontaktaufnahme.