In den letzten Tagen berichteten verschiedene Quellen von einer angeblich schwereren Sicherheitslücke in PostgreSQL. Mittlerweile wurde genannter Artikel ebenfalls analog zu den untenstehenden Ausführungen korrigiert.

Konkret geht es um ein ungeprüftes Ausführen von Executable Code im Kontext des PostgreSQL Dienstes mit Hilfe des Befehls

COPY <table> FROM|TO PROGRAM

Die Details hierzu werden in CVE-2019-9193 beschrieben.

Stellungnahme und Erläuterung

Diese Darstellung ist unter sachlicher Betrachtung allerdings keine Sicherheitslücke im eigentlichen Sinn. Vielmehr handelt es sich bei dem betroffenen COPY-Kommando um eine privilegierte Datenbankoperation, die unter allen Umständen entweder Superuserberechtigungen (in der Regel z.B. der Benutzer postgres) oder Mitgliedschaft in der Datenbankrolle pg_execute_server_program erfordert. In dieser Hinsicht enthält der im Link angegebene CVE auch einen Fehler, denn die Rolle pg_read_server_files ist nicht ausreichend, um als unprivilegierter Datenbankbenutzer überhaupt dieses Kommando ausführen zu können.

Gegeben sind in den folgenden Beispielen die Rollen bernd und test, wobei bernd eine Datenbankrolle mit Superuserprivileg ist und test lediglich das LOGIN-Privileg besitzt (also ein normaler Datenbankbenutzer).

bernd@db=# \duS bernd
                                   List of roles
 Role name │                         Attributes                         │ Member of 
───────────┼────────────────────────────────────────────────────────────┼───────────
 bernd     │ Superuser, Create role, Create DB, Replication, Bypass RLS │ {}
 
bernd@db=# \duS test
           List of roles
 Role name │ Attributes │ Member of 
───────────┼────────────┼───────────
 test      │            │ {}

Im Folgenden wird nun versucht, als Benutzer bernd die Ausgabe des Linux-Kommandos echo in eine Tabelle zu schreiben:

bernd@db=# CREATE TABLE test(val text);
CREATE TABLE
bernd@db=# SELECT current_role;
 current_role 
--------------
 bernd
(1 row)
bernd@db=# COPY test FROM PROGRAM '/bin/echo hallo welt';
COPY 1
bernd@db=# SELECT * FROM test;
    val     
------------
 hallo welt
(1 row)

Das hat funktioniert, da die Superuserprivilegien des Datenbankrolle bernd dies explizit erlauben. Anders sieht dies mit der unprivilegierten Rolle test aus:

test@db=> SELECT current_role;
 current_role 
--------------
 test
(1 row)
test@db=> COPY test FROM PROGRAM 'echo hallo welt';
FEHLER:  nur Superuser oder Mitglieder von pg_execute_server_program können COPY mit externen Programmen verwenden
HINT:  Jeder kann COPY mit STDOUT oder STDIN verwenden. Der Befehl \copy in psql funktioniert auch für jeden.

Das Ausführen von COPY FROM PROGRAM ist der Rolle test nicht gestattet. Man kann es jetzt wie im CVE beschrieben mit der Mitgliedschaft in der Rolle pg_read_server_files versuchen:

bernd@db=# GRANT pg_read_server_files TO test;
 
bernd@db=# SET ROLE test;
 
test@db=> COPY test FROM PROGRAM 'echo hallo welt';
FEHLER:  nur Superuser oder Mitglieder von pg_execute_server_program können COPY mit externen Programmen verwenden
HINT:  Jeder kann COPY mit STDOUT oder STDIN verwenden. Der Befehl \copy in psql funktioniert auch für jeden.

Auch das ist offensichtlich nicht ausreichend. Mit der Mitgliedschaft pg_execute_server_program kommt man dann jedoch an das Ziel:

bernd@db=# GRANT pg_execute_server_program TO test;
 
bernd@db=# SET ROLE test;
 
test@db=> COPY test FROM PROGRAM 'echo hallo welt';
 
test@db=> SELECT * FROM test;
    val     
────────────
 hallo welt
 hallo welt
(2 rows)

Normale Datenbankrollen mit entsprechend fehlenden Berechtigungen sind folglich nicht in der Lage, dieses Kommando auszuführen. Dies ist das Standardverhalten und benötigt keine entsprechenden Änderungen an der Datenbankkonfiguration. Nur Superuser der PostgreSQL-Instanz besitzen standardmäßig die Berechtigung für das erfolgreiche Ausführen von COPY TO|FROM PROGRAM. Dieser Sachverhalt ist auch entsprechend in der PostgreSQL Dokumentation beschrieben.

Das mit COPY TO|FROM angegebene Executable wird immer im Kontext des Betriebssystem-Benutzers ausgeführt, unter dem die jeweilige PostgreSQL-Instanz läuft (in der Regel eigentlich immer postgres). D.h. die Ausführung des Executable unterliegt immer dem Berechtigungskontexts dieses Benutzers. Dieser ist in der Regel eher eingeschränkt, da PostgreSQL bspw. als root nicht gestartet werden kann. Das heißt, beliebige Zugriffe sind somit ausgeschlossen. Folgendes Beispiel versucht nun mit der Rolle test die Datei /etc/shadow mit den Passwörtern des Betriebssystems zu lesen:

test@db=> COPY test FROM PROGRAM 'cat /etc/shadow';
FEHLER:  Programm »cat /etc/shadow« fehlgeschlagen
DETAIL:  Kindprozess hat mit Code 1 beendet

Dies schlägt fehl, denn der angesprochene Berechtigungskontext des Betriebsystem-Benutzers, unter dem die PostgreSQL-Instanz ausgeführt wird, hat keine Zugriffsberechtigung auf /etc/shadow.

Zusammenfassung

Es ist nicht möglich als Standard-Datenbankrolle ohne entsprechend erteilte Berechtigungen ohne weiteres die angebliche Sicherheitslücke wie im CVE beschrieben auszunutzen. Datenbankrollen müssen entgegen der empfohlenen Praxis entweder über SUPERUSER Privilegien verfügen oder explizit die Berechtigung der Rolle pg_execute_server_program erhalten. Daher ist es wichtig bei PostgreSQL Installationen beim Anlegen und Verteilen von Berechtigungen entsprechend sorgfältig vorzugehen. Der Blogartikel des Core Committee Mitglieds Magnus Hagander (in englischer Sprache) beinhaltet ebenfalls eine entsprechende Erläuterung zum Sachverhalt und empfiehlt sich zur weiteren Lektüre.

An dieser Stelle soll explizit von der Verwendung von Datenbankrollen mit SUPERUSER Privileg für Anwendungen oder Nutzern abgeraten werden. Superuser verfügen noch über viel weitreichendere Berechtigungen als COPY TO|FROM PROGRAM. Sie können beliebige Shared Libraries laden, beliebige Objekte ändern und beliebige Konfigurationsänderungen vornehmen. Daher ist die Verwendung von derart privilegierten Rollen außerhalb des Administrationskontextes dringenst zu vermeiden.

Patroni ist eine Hochverfügbarkeitslösung für PostgreSQL mit einem Fokus auf Container-Technologie und Kubernetes. Die bisher vorhandenen Debian-Pakete mussten bislang aufwendig von Hand konfiguriert werden und haben sich nicht in die Distribution integriert. Für das bald erscheinende Debian 10 „Buster“ wurde Patroni nun von credativ in das Debian Standard PostgreSQL-Framework integriert und erlaubt einen einfachen Aufbau von Patroni-Clustern unter Debian.

Aufgrund der Verwendung eines externen „Distributed Consensus Store“ (DCS) wie Etcd, Consul oder Zookeeper kann Patroni zuverlässig Leader-Election und automatisierte Failover durchführen. Dazu kommen planbare Switchover und eine einfache Änderung der Cluster-weiten Konfiguration. Es bietet außerdem eine REST-Schnittstelle, mit der z.B. via HAProxy ein Load-Balancing aufgebaut werden kann. Auf Grund dieser Vorteile hat Patroni in letzter Zeit das früher häufig verwendete Pacemaker als Open Source Projekt der Wahl für die Herstellung einer PostgreSQL-Hochverfügbarkeit abgelöst.

Viele unserer Kunden verwenden allerdings PostgreSQL auf Debian- oder Ubuntu-Systemen. Hier hat sich Patroni bisher nicht gut in das System integriert. So verwendete es nicht das postgresql-common Framework und wird nicht wie übliche Instanzen in pg_lsclusters angezeigt.

Integration in Debian

In Zusammenarbeit mit dem Patroni-Hauptentwickler Alexander Kukushkin von Zalando ist es nun gelungen, das Debian Patroni-Paket weitgehend in das postgresql-common-Framework zu integrieren. Dies geschah sowohl durch Änderungen in Patroni, als auch durch zusätzliche Programme im Debian-Paket. Die aktuelle Version 1.5.5 von Patroni, die alle diese Änderungen enthält, ist nun auch in Debian „Buster“ (testing) verfügbar und kann für den Aufbau von Patroni-Clustern unter Debian verwendet werden.

Zur Verfügung stehen die Pakete auch auf apt.postgresql.org und sind damit auch unter Debian 9 „Stretch“ und Ubuntu 18.04 „Bionic Beaver“ LTS benutzbar. Außerdem kann so jede beliebige PostgreSQL-Version von 9.4 bis 11 verwendet werden.

Wichtigster Punkt ist hierbei die automatische Erstellung einer geeigneten Patroni-Konfiguration mit dem Befehl pg_createconfig_patroni. Der Aufruf erfolgt analog zu pg_createcluster mit der gewünschten Major-Version und dem Instanz-Namen als Parameter:

pg_createconfig_patroni 11 test

Dieser Aufruf erstellt eine Datei /etc/patroni/11-test.yml, wobei die Konfiguration für das DCS aus der Datei /etc/patroni/dcs.yml verwendet wird, die entsprechend dem lokalen Setup angepasst werden muss. Der Rest der Konfiguration entstammt dem Template /etc/patroni/config.yml.in, welches von sich aus lauffähig ist, vom Nutzer aber auch an die eigenen Bedürfnisse angepasst werden kann. Anschließend kann die Patroni-Instanz analog zu regulären PostgreSQL-Instanzen via systemd gestartet werden:

systemctl start patroni@11-test

Cluster-Aufbau in wenigen Schritten

Ein einfacher 3-Knoten Patroni-Cluster kann also mit den wenigen folgenden Befehlen erstellt und gestartet werden, wobei die drei Knoten pg1, pg2 und pg3 als Hostnamen angenommen werden, sowie dass es eine lokale Datei dcs.yml für die DCS-Konfiguration gibt:

for i in pg1 pg2 pg3; do ssh $i 'apt -y install postgresql-common'; done
for i in pg1 pg2 pg3; do ssh $i 'sed -i "s/^#create_main_cluster = true/create_main_cluster = false/" /etc/postgresql-common/createcluster.conf'; done
for i in pg1 pg2 pg3; do ssh $i 'apt -y install patroni postgresql'; done
for i in pg1 pg2 pg3; do scp ./dcs.yml $i:/etc/patroni; done
for i in pg1 pg2 pg3; do ssh @$i 'pg_createconfig_patroni 11 test' && systemctl start patroni@11-test'; done

Danach kann man den Status des Patroni-Clusters folgendermaßen ansehen:

ssh pg1 'patronictl -c /etc/patroni/11-patroni.yml list'
+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 | Leader | running |  1 |           |
| 11-test |  pg2   | 10.0.3.41  |        | stopped |    |   unknown |
| 11-test |  pg3   | 10.0.3.46  |        | stopped |    |   unknown |
+---------+--------+------------+--------+---------+----+-----------+

Man sieht, dass eine Leader Election durchgeführt wurde und pg1 der Primary wurde. Dieser hat seine Instanz mit dem Debian-spezifischen pg_createcluster_patroni Programm erstellt, welches im Hintergrund pg_createcluster aufruft. Darauf klonen sich die anderen beiden Instanzen vom Primary mit dem pg_clonecluster_patroni Programm, welches eine Instanz mit pg_createcluster erstellt und dann einen Standby via pg_basebackup vom Primary erstellt. Danach sind alle Knoten im Status running:

+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 | Leader | running |  1 |         0 |
| 11-test |  pg2   | 10.0.3.41  |        | running |  1 |         0 |
| 11-test |  pg3   | 10.0.3.46  |        | running |  1 |         0 |
+---------+--------+------------+--------+---------+----+-----------+

Die altbekannten Debian postgresql-common Befehle funktionieren ebenfalls:

ssh pg1 'pg_lsclusters'
Ver Cluster Port Status Owner    Data directory                 Log file
11  test    5432 online postgres /var/lib/postgresql/11/test    /var/log/postgresql/postgresql-11-test.log

Failover-Verhalten

Wenn der Primary Knoten abrupt abgeschaltet wird, wird sein Leader Token nach einiger Zeit auslaufen und Patroni dann einen Failover mit anschließender erneuter Leader Election durchführen:

+---------+--------+-----------+------+---------+----+-----------+
| Cluster | Member |    Host   | Role |  State  | TL | Lag in MB |
+---------+--------+-----------+------+---------+----+-----------+
| 11-test |  pg2   | 10.0.3.41 |      | running |  1 |         0 |
| 11-test |  pg3   | 10.0.3.46 |      | running |  1 |         0 |
+---------+--------+-----------+------+---------+----+-----------+
[...]
+---------+--------+-----------+--------+---------+----+-----------+
| Cluster | Member |    Host   |  Role  |  State  | TL | Lag in MB |
+---------+--------+-----------+--------+---------+----+-----------+
| 11-test |  pg2   | 10.0.3.41 | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46 |        | running |  1 |         0 |
+---------+--------+-----------+--------+---------+----+-----------+
[...]
+---------+--------+-----------+--------+---------+----+-----------+
| Cluster | Member |    Host   |  Role  |  State  | TL | Lag in MB |
+---------+--------+-----------+--------+---------+----+-----------+
| 11-test |  pg2   | 10.0.3.41 | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46 |        | running |  2 |         0 |
+---------+--------+-----------+--------+---------+----+-----------+

Sobald der alte Primary erneut gestartet wird, kehrt er als Standby in den Cluster-Verbund zurück:

+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 |        | running |    |   unknown |
| 11-test |  pg2   | 10.0.3.41  | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46  |        | running |  2 |         0 |
+---------+--------+------------+--------+---------+----+-----------+
[...]
+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 |        | running |  2 |         0 |
| 11-test |  pg2   | 10.0.3.41  | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46  |        | running |  2 |         0 |
+---------+--------+------------+--------+---------+----+-----------+

Falls dies aufgrund von zusätzlichen Transaktionen in seiner alten Zeitleiste nicht möglich ist, wird er neu erstellt. Im Falle von sehr großen Datenmengen kann auch pg_rewind verwendet werden, hierfür muss allerdings ein Passwort für den postgres-Nutzer gesetzt und reguläre Datenbank-Verbindungen (im Gegensatz zu Replikations-Verbindungen) zwischen den Cluster-Knoten erlaubt werden.

Weitere Instanzen erstellen

Es ist ferner möglich weitere Instanzen mit pg_createconfig_patroni zu erstellen, dabei kann man entweder einen PostgreSQL Port explizit mit der --port-Option angeben oder pg_createconfig_patroni den nächsten freien Port (wie von pg_createcluster bekannt) nehmen lassen:

for i in pg1 pg2 pg3; do ssh $i 'pg_createconfig_patroni 11 test2 && systemctl start patroni@11-test2'; done
ssh pg1 'patronictl -c /etc/patroni/11-test2.yml list'
+----------+--------+-----------------+--------+---------+----+-----------+
| Cluster  | Member |       Host      |  Role  |  State  | TL | Lag in MB |
+----------+--------+-----------------+--------+---------+----+-----------+
| 11-test2 |  pg1   | 10.0.3.111:5433 | Leader | running |  1 |         0 |
| 11-test2 |  pg2   |  10.0.3.41:5433 |        | running |  1 |         0 |
| 11-test2 |  pg3   |  10.0.3.46:5433 |        | running |  1 |         0 |
+----------+--------+-----------------+--------+---------+----+-----------+

Ansible Playbook zum Download

Zur einfachen Erstellung eines 3-Wege Patroni Clusters haben wir auch ein Ansible-Playbook auf Github erstellt. Dieses automatisiert die Installation und Einrichtung von PostgreSQL und Patroni auf den drei Knoten, sowie eines DCS-Servers auf einem vierten Knoten.

Unterstützung

Falls Sie Unterstützung bei PostgreSQL, Patroni, PostgreSQL auf Debian oder anderer Aspekte von Hochverfügbarkeit benötigen, steht Ihnen unser PostgreSQL Competence Center zur Verfügung – Falls gewünscht auch 24 Stunden am Tag, an 365 Tagen im Jahr.

Wir freuen uns über Ihre Kontaktaufnahme.

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.

Heute wurde PostgreSQL Version 11 veröffentlicht. Das neue Release bringt Verbesserung in vielen Bereichen.

Schon seit Version 9.6 können Query-Pläne auf mehreren CPU-Kernen parallel ausgeführt werden, dies wird nun für weitere Plan-Typen unterstützt, insbesondere das Erstellen von B-tree-Indexen. Verbessert wurden auch Sequential Scans und UNION-Queries.

Brandneu ist die Möglichkeit, Queries per Just-in-Time-Compilation (JIT) zu optimieren. Dafür wird beim Kompilieren von PostgreSQL der Quellcode as LLVM-Bitcode gespeichert. Beim Ausführen einer Query, deren Planner-Kosten eine Schranke überschreiten wird dieser Bitcode von libllvm dann speziell für diese Query in nativen Maschinencode übersetzt. Da alle benutzten Datentypen usw. vorher bekannt sind, fallen im Maschinencode alle Fallunterscheidungen weg, die im allgemeinen Fall notwendig sind. Das Feature ist per default abgeschaltet und kann mit „SET jit = on;“ aktiviert werden. In PostgreSQL 12 soll es dann standardmäßig aktiv sein.

Bisher konnten auf SQL-Ebene nur Funktionen definiert werden. Neu sind nun Prozeduren, die selbständig BEGIN/COMMIT verwalten können. Damit können Batch-Operationen nun vollständig auf die Datenbankseite übertragen werden.

Der Bereich Tabellen-Partitionierung wurde weiterhin verbessert, und unterstützt nun auch Hash-Partitionierung. Die Integration mit Partitionen, die postgres_fdw benutzen, wurde ebenfalls verbessert. Es ist nun möglich, eine Default-Partition anzulegen, die Daten aufnimmt, die in keine der existierenden Partitionen fällt.

Weitere Verbesserungen sind die Möglichkeit, Spalten mit Default-Wert zu Tabellen hinzuzufügen, ohne dass die Tabelle komplett neu geschrieben werden muss. Mit „Covering Indexes“ können mehr Index-Zugriffe als „Index Only Scan“ durchgeführt werden. Window-Funktionen unterstützen nun auch die RANGE und GROUPS-Schlüsselwörter.

Weitere Informationen gibt es im Release-Announcement des PostgreSQL-Projekts.

Nächste Woche findet in Lissabon die PGConf.EU statt. Wir von credativ sind mit einem Stand vertreten und feiern das PostgreSQL-Release unter anderem mit unserem „This Amp goes to 11„-T-Shirt.

Das Shirt ist bei uns kostenlos am Stand erhältlich. Wer nicht an der Konferenz teilnimmt, kann sich ein Shirt bestellen. Der Erlös wird an das PostgreSQL-Projekt gespendet.

In der aktuellen Ausgabe beschäftigt sich das Linux Magazin in einem sehr interessanten Artikel mit einer Frage, die derzeit in vielen Unternehmen intensiv diskutiert wird:

Betreibt man seine Datenbank auf der eigenen Hardware, oder verlagert man sie in die Cloud?

Um die einzelnen Vor- und Nachteile zu untersuchen, wurden Datenbanklösungen diverser Cloud-Anbieter mit einer lokalen PostgreSQL-Installation verglichen. Für die Tests auf der lokalen Installation wurde auch die von credativ entwickelte PostgreSQL Appliance „Elephant Shed“ verwendet.

Den vollständigen Artikel inklusive Testergebnissen findet man in der neuesten Ausgabe des Linux Magazins (10/18). Optional kann der Artikel auf der Seite des Linux-Magazins auch online erworben werden.

Über PostgreSQL

PostgreSQL ist eines der führenden Open-Source-Datenbanksysteme, mit einer weltweiten Community bestehend aus Tausenden von Nutzern und Mitwirkenden. Das PostgreSQL Projekt baut auf über 25 Jahre Erfahrung auf, beginnend an der University of California, Berkeley, und ist bald schon in der Version 11 verfügbar.

Für PostgreSQL bietet credativ umfangreiche Services und einen tiefgehenden Entwicklersupport an. Von der Konzeption, zur Datenbankmigration, Optimierungen und Tunings, bis hin zur Hochverfügbarkeit: Der gesamte PostgreSQL-Datenbank-Lifecycle wird durch credativ abgedeckt.

Um eine komfortablere und flexiblere Administration zu ermöglichen, hat credativ die Elephant Shed PostgreSQL Appliance entwickelt.

Über Elephant Shed

Elephant Shed ist eine vollständig freie, leistungsfähige Open Source-Lösung, die eine enorme Erleichterung für den Betrieb von PostgreSQL im Unternehmenseinsatz bietet.

Elephant Shed baut auf bewährten Komponenten auf, die ausschließlich unter anerkannten Open Source Lizenzen veröffentlicht werden – und bietet somit den vollständigen Softwarestack für die Administration, das Monitoring, die Erstellung von Backups, und vielem mehr für PostgreSQL-Datenbanken.

Weitere Informationen über PostgreSQL und Elephant Shed erhalten Sie auf der jeweiligen Projektseite.

Die zweite Beta-Version von PostgreSQL 11, welche sich nun im Feature-Freeze befindet, ist kürzlich erschienen. Zeit also, einige Verbesserungen vorzustellen, die credativ zu dieser Version im Bereich Checksummen und Basebackups beigetragen hat.

Checksummen-Überprüfung während Basebackups

Checksummen für den Tabellen und Indexen zugeordneten Dateien können seit Version 9.3 beim Anlegen einer PostgreSQL-Instanz verwendet werden und warnen bei Bitfehlern in einzelnen Daten-Pages. Sie ermöglichen damit die frühzeitige Erkennung von Storage-Problemen. Allerdings wurden diese bisher nur im Rahmen von Abfragen geprüft, wenn auf den entsprechenden Datensatz zugegriffen wurde. Eine explizite Prüfung ist erst ab Version 11 mit dem neuen pg_verify_checksums Tool möglich, welches allerdings nur bei ausgeschalteter Instanz funktioniert.

Unsere Änderung erlaubt nun Checksummen beim Erstellen eines Basebackups zu überprüfen. Da bei einem Basebackup naturgemäß alle Datenblöcke gelesen werden müssen, ist dies eine gute Gelegenheit deren Konsistenz zu überprüfen. Checksummen-Fehler werden dabei als Warnungen und nicht als Fehler geloggt, damit nicht das gesamte Basebackup abgebrochen werden muss. Dem normalerweise für die Erstellung von Basebackups bzw. Standby Clones verwendeten Programm pg_basebackup wurde eine Option --no-verify-checksums hinzugefügt, die optional diese Überprüfung abschaltet.

Replikations-Slots bei Basebackups

Die zweite Änderung betrifft die Behandlung von Replikations-Slots von pg_basebackup bei der Erstellung von Standby-Servern. Diese erlauben es einem Primary, die für den im Slot spezifizierten Standby benötigten Transaktionslogs vorzuhalten, auch wenn dieser temporär nicht verfügbar ist. Zwar konnte man pg_basebackup einen Replikations-Slot nennen, welcher dann während des Basebackups verwendet wird, allerdings musste dieser bereits vorher manuell angelegt worden sein, da es ansonsten zu einer Fehlermeldung kommt. Unsere Änderung erlaubt nun mit der neuen Option -C bzw. --create-slot in einem Kommando einen Standby-Clone inklusive Verwendung von Replikations-Slots zu erstellen:

$ pg_basebackup -v -h primary.lan -D data --slot=standby1 --create-slot --write-recovery-conf
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1D000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created replication slot "standby1"
pg_basebackup: write-ahead log end point: 0/1D0000F8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed
$ cat data2/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=postgres passfile=''/var/lib/postgresql/.pgpass'' host=primary.lan
  port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'standby1'

Danach muss nur noch der Standby gestartet werden und repliziert nun automatisch.

Darüberhinaus wurden einige weitere kleine Verbesserungen an pg_basebackup bzw. dessen Tests von uns umgesetzt.

Paralleler Dump nach /dev/null

Einen Patch, der es nicht in das Release schaffte, wollen wir aber dennoch vorstellen: Paralleler pg_dump nach /dev/null im Directory-Format. Grund hierfür ist die gebräuchliche Verwendung von pg_dump für die Überprüfung von PostgreSQL-Instanzen auf Fehler, wobei als Zielort /dev/null verwendet wird, sodass kein zusätzlicher Speicherplatz benötigt wird. Das Problem hierbei ist, dass /dev/null nur im Custom-Format verwendet werden kann, welches aber keine Parallelität erlaubt. Das Directory-Format erlaubt zwar mehrere Prozesse gleichzeitig zu verwenden, allerdings nicht in Verbindung mit /dev/null; letzteres wird durch unseren vorgeschlagenen Patch ermöglicht.

Die Begründung für die Ablehnung war nicht technischer Natur, sondern das pg_dump kein Diagnose-Werkzeug ist und deswegen keine spezielle Unterstützung hierfür eingebaut werden sollte. Nichtsdestotrotz funktioniert der vorgeschlagene Patch und wird auch bei Kunden von uns eingesetzt. Versionen des Patches für PostgreSQL 9.3, 9.4, 9.5, 9.6 und 10 sind verfügbar.

Elephant Shed bündelt und integriert bewährte Komponenten, die für das Management eines PostgreSQL-Servers benötigt werden. Dabei werden erprobte Tools für alle relevanten Bereiche bereits vorinstalliert und vorkonfiguriert. Die Mehrzahl dieser Tools kann über eine komfortable Weboberfläche gesteuert werden. Selbst gestandene PostgreSQL-Administratoren werden kaum einen Bereich finden, der von Elephant Shed nicht abgedeckt wird.

Neu in Version 1.2 ist die Unterstützung von Ubuntu Bionic (18.04), neben der bisherigen Unterstützung für Debian Stretch (9). Beide Distributionen sind für die Architekturen amd64 (x86_64) und ppc64el (IBM POWER) verfügbar.

Nach Rückmeldungen durch Benutzer wurde für die Version 1.2 das Grafana-Dashboard überarbeitet. Verschiedene PostgreSQL-Cluster pro Maschine werden nun durch den Cluster-Namen wie „10/main“ unterschieden. Alle Metrikpanels benutzen nun korrekte Einheiten, d.h. die Achsen sind nun mit „Bytes pro Sekunde“ oder „Operationen pro Minute“ beschriftet. Grafana wurde auf Version 5 aktualisiert.

Die Prometheus-Timeseries-Datenbank wurde auf Version 2 aktualisiert, mit besserer Performance und kompakterer Datenhaltung. Leider ist das Speicherformat nicht kompatibel, alte Monitoring-Daten werden nicht erhalten.

Bug-Fixes und Verbesserungen:

• prometheus-sql-exporter: Die automatische Erkennung von PostgreSQL-Clustern und Datenbanken wurde neu geschrieben und ist nun stabiler
• Prometheus nutzt nun den Host- und Cluster-Namen in Timeseries-Labels
• prometheus-node-exporter wurde auf Version 0.15 aktualisiert
• pgBadger: Handhabung von log_line_prefix korrigiert

Die aktualisierten Pakete stehen über packages.credativ.com zum Download bereit. Wer Elephant Shed bereits installiert hat, kann die Updates wie gewohnt über apt einspielen.

Elephant Shed ist ein Open-Source-Projekt, entwickelt und gepflegt von credativ. Für Elephant Shed bietet die credativ einen umfassenden technischen Support mit garantierten Service Level Agreements, der optional auch an 365 Tagen im Jahr rund um die Uhr zur Verfügung steht.

Unsere PostgreSQL-Appliance Elephant Shed bringt fertig konfiguriertes Datenbank- und System-Monitoring mit. Wir setzen dabei auf Grafana und Prometheus. Hier stellen wir die Grundlagen vor, auf denen diese Monitoring-Architektur basiert.

Im Vordergrund steht hier Performance-Monitoring, d.h. die Sammlung quantitativer Metriken über die Zeit, z.B. den Verlauf der Zahl der Transaktionen pro Sekunde. Qualitative Metriken wie „ist die Festplatte vollgelaufen“ und Alerting können von Grafana und Prometheus ebenfalls erfasst werden, sollen hier aber nicht behandelt werden.

Prometheus-Exporter

Prometheus als Timeseries-Datenbank bildet die Zentrale des Monitorings. Metriken haben hier einen Namen und verschiedene Labels, z.B. sql_pg_stat_database mit Labels datname=“omdb“ und col=“xact_commit“.

Prometheus bezieht seine Daten von sogenannten Exportern, die periodisch (z.B. alle 30 s) abgefragt werden. Wohl in jeder Installation zu finden ist der Node-Exporter, der System-Daten wie Dateisystem-Füllstand, CPU-Auslastung und Speicherbelegung auswertet. Für die PostgreSQL-Überwachung setzen wir den SQL-Exporter in einer von uns gepatchten Version ein.

Im SQL-Exporter sind SQL-Abfragen konfiguriert, die in allen PostgreSQL-Clustern und -Datenbanken auf dem System ausgeführt werden. Dabei ist es üblich, immer absolute Werte abzufragen, z.B. Transaktionen seit Systemstart, und nicht schon vorzuverarbeiten. Ein Wert wie „Transaktionen pro Sekunde“ wird dann durch Prometheus aus den Rohdaten berechnet.

# SELECT datname, xact_commit, xact_rollback
  FROM pg_stat_database
  WHERE datname !~ 'template(0|1)'
  ORDER BY datname;
 
 datname  | xact_commit | xact_rollback
----------+-------------+---------------
 foo      |        8881 |             0
 omdb     |       29149 |         18926
 postgres |       43780 |          1754
(3 Zeilen)

Das Ergebnis stellt der Exporter dann per http auf localhost:9237 zur Verfügung:

sql_pg_stat_database{col="xact_commit", datname="omdb", host=":5432", sql_job="10/main", user="postgres"} 29149
sql_pg_stat_database{col="xact_rollback", datname="omdb", host=":5432", sql_job="10/main", user="postgres"} 18926

Prometheus-Abfrage

Im Webinterface von Prometheus können die gesammelten Daten dann abgefragt werden. Im einfachsten Fall besteht eine Prometheus-Query einfach aus dem Namen der Timeseries:

sql_pg_stat_database{col=~'xact_commit|xact_rollback',datname='omdb',host=':5432'}

Die Graphik zeigt die steigende Zahl von durchgeführten Transaktionen. Um nun auf die Rate der Transaktionen pro Sekunde zu kommen, benutzt man die Funktion rate(), wobei über ein angegebenes Intervall gemittelt wird, hier 1 Minute:

rate(sql_pg_stat_database{col=~'xact_commit|xact_rollback',datname='omdb',host=':5432'}[1m])

Grafana

Grafana dient nun dazu, die von Prometheus gesammelten Daten hübsch formatiert in Dashboards anzuzeigen. Für jedes „Panel“ im Dashboard werden Prometheus-Queries hinterlegt und Achsenbeschriftungen und andere Grapheigenschaften konfiguriert. Dabei passiert das Rendering der Daten vollständig im Browser, Grafana stellt lediglich Umgebung zur Verfügung, der Browser bezieht dann die Timeseries-Werte direkt als JSON von Prometheus.

Elephant Shed

Das von uns für Elephant Shed entwickelte PostgreSQL-Dashboard kann natürlich auch für andere Setups genutzt werden. Alle benötigten Dateien finden sich im Git-Repository.

In diesem Jahr ist es endlich wieder soweit – Die PGConf.DE öffnet am 13. April 2018 ihre Pforten!

Mit ca. 200 Besuchern ist die PGConf.DE die deutschlandweit größte PostgreSQL Veranstaltung, und findet in diesem Jahr in Berlin statt. Zuletzt wurde die PGConf.DE 2015 in Hamburg ausgetragen.

credativ ist natürlich wieder mit dabei – in diesem Jahr als Platin-Sponsor. Insgesamt halten unsere Kollegen drei Vorträge:

• PostgreSQL-Monitoring mit Grafana und Prometheus – von Christoph Berg
  • „PostgreSQL liefert eine Vielzahl von Performance-Metriken. In diesem Vortrag zeigen wir, wie man diese Daten von PostgreSQL-Clustern mit Prometheus-Exportern abruft und als Graphen in Grafana darstellt. Die Präsentation erläutert die Monitoring-Grundlagen, und in einer Live-Demo werden neue Graphen in das Grafana-Dashboard eingefügt.“
• PostgreSQL und alles was dazugehört – Elephant Shed – von Adrian Vondendriesch und Alexander Sosna
  • „PostgreSQL ist für viele Nutzer heute ein zentrales Element ihrer IT-Infrastruktur, oder auf dem Weg dahin. Für einen reibungslosen Betrieb wird jedoch eine entsprechende leistungsfähige Umgebung benötigt. Im Vortrag wird eine Stand-Alone-Datenbankserver-Umgebung vorgestellt, die für Entwicklung und Produktion verwendet werden kann und sowohl PostgreSQL-Neueinsteigern, -Umsteigern, als auch Veteranen das Leben möglichst einfach macht.“
    Elephant Shed ist eine von credativ entwickelte, leistungsfähige PostgreSQL Appliance, die vollständig als freie Open Source-Lösung zum Download zur Verfügung steht.
• Hat Open Source eine Zukunft? – von Dr. Michael Meskes

Das vollständige Vortragsprogramm kann auf der Veranstaltungswebsite eingesehen werden.

Wir freuen uns auf Euren Besuch an unserem Stand und in den Vorträgen! Wenn Ihr noch nicht registriert seid, müsst Ihr schnell sein – Laut Veranstalter werden die Tickets bereits knapp.

Weitere Informationen erhaltet Ihr auf der Veranstaltungswebsite PGConf.DE

Neben den Vortragenden beschäftigt die credativ viele Mitglieder der PostgreSQL-Community. Einige Mitarbeiter waren schon vor Firmengründung an dem Projekt beteiligt und leisten auch heute noch einen wichtigen Beitrag für die Software. Auch daraus entstand für die credativ eine enge und langjährige Verbundenheit mit dem PostgreSQL-Projekt und der Community.