Communardo Techblog

Die meiste Software für eine Netzwerküberwachung versteht SNMP. Was liegt also näher, dieses Protokoll auch für Überwachung von PostgreSQL zu nutzen. Leider bringt PostgreSQL von Hause aus keine Unterstützung für SNMP mit. Seit geraumer Zeit gibt es jedoch pgsnmpd. Nach dem Download von der Homepage und dem Auspacken in das contrib-Verzeichnis der ausgepackten und übersetzten Quellen von PostgreSQL erfolgt die Installation mit

gmake && gmake install

Als nächstes werden auf allen Datenbanken, inklusive dem Template (so spart man sich das fehlerträchtige nachträgliche Installieren), die Unterstützungstabellen als PostgreSQL-Superuser installiert:

psql -d db -f /usr/share/postgresql/contrib/pgsnmpd.sql

Da auf meiner Maschine bereits ein SNMPd seinen Dienst tut, starte ich den pgsnmpd als Subagent. Dazu wird in der snmpd.conf der folgende Eintrag aktiviert:

master agentx

Startet danach der SNMP-Daemon nicht mehr, so muß in eventuell unter /var ein Verzeichnis agentx für den Socket angelegt werden. Danach kann man den pgsnmpd als Subagent starten:

/usr/bin/pgsnmpd -b -s -C"user=postgres host=localhost"

Bei mir fehlten allerdings noch die (aktuelle) RDBMS-MIB, APPLICATION-MIB, SYSAPPL-MIB und die NETWORK-SERVICES-MIB. Diese kann man sich aber schnell aus dem Internet besorgen.
Eine Verbindung zum RDBMS muss als PostgreSQL-Superuser erfolgen. Ist die Verbindung von Superuser auf localhost mit einem Passwort geschützt, wie sich das gehört, hilft eine .pgpass mit dem Inhalt

hostname:port:database:username:password

im Homeverzeichnis weiter. Erhält man dann vielleicht in den Logs noch ein:

registering pdu failed

sollte man in der Prozesstabelle schauen, ob der pgsnmpd bereits gestartet war. Zum Schluß binden wir den den pgsnmpd noch in die init-Skripte ein, um ein Hochfahren des Dienstes beim Reboot zu garantieren. Ich habe die /etc/init.d/local (Gentoo) dafür gewählt.

Nachdem ich im ersten Teil beschrieben habe, wie man ssh ohne Passwort nutzt und den so geschaffenen Zugang trotzdem einschränkt, komme ich zum interessanten Teil: dem eigentlichen Tunnelbau. Wir holen uns einen lokalen Zugang zu PostgreSQL auf einem entfernten Host über ssh. Dazu geben wir folgenden Befehl ein:

ssh -f -L 2222:remotehost:5432 -c blowfish user@remotehost /usr/bin/sleep 1800

Mit der Option -f wird ssh in den Hintergrund vor der Ausführund des Kommandos /usr/bin/sleep geschickt. Mit -L localport:remotehost:remotehostport wird ein Tunnel von dem PostgreSQL-Standardport 5432 auf remotehost zum Port 2222 auf localhost gebaut. Jetzt noch die Zugriffsrechte der Datenbank für localhost auf dem remotehost aktualisiert und wir können den ersten Test durchführen:

psql -U benutzer -d db -h localhost -p 2222

Wird diese Verbindung dauerhaft benötigt bietet es sich eine Automatisierung über cron an. Dazu habe ich folgendes Skript erstellt:

#!/bin/sh
PORT=`lsof -i | grep localhost:2222 | head -1 | cut -d" " -f1`
SSH=`which ssh`
if [ "${PORT}"x == "x" ]; then
$SSH -f -L 2222:remotehost:5432 -c blowfish user@remothost /bin/sleep 1800
fi

Diese prüft ab, ob der definierte Port offen ist, und startet die Verbindung einfach neu, wenn dies nicht der Fall ist.

Neben den “Klassikern”, den IDS’ (Intrusion Detection Systems), ob nun Host-(AIDE) oder Netzwerkbasierend (SNORT), gibt es noch zwei weitere kleine Tools, die sogenannte Rootkits aufspüren können. Die Rede ist von rkhunter und chkrootkit. Die Installation unter Gentoo gestaltet sich unspektakulär:

emerge -av rkhunter chkrootkit

Die effektivste Art, diese Tools zu nutzen, ist es, diese über cron ausführen zu lassen. Dazu wird unter Gentoo der Parameter ENABLE unter /etc/cron.daily/rkhunter von NO auf YES gesetzt. Die Variable UPDATE ebenfall auf YES zu setzen ist sinnvoll. Zum Aktivieren von chkrootkit wird in der /etc/cron.weekly/chkrootkit das Kommentarzeichen vor der einzelnen Kommandozeile entfernt.
Auch wenn diese Tools sinnvoll im Kampf gegen Eindringlinge sind, einen 100%-igen Schutz können sie nicht garantieren.