Nachdem ein Apache keine Seiten mehr auslieferte und ein Neustart des Apaches immer mit der Fehlermeldung “no space left on device” abbrach, war guter Rat teuer. Ein
df -h
zeigte auf allen Mountpoints genügend Speicherplatz an. Nur ein Neustart half mir vorübergehend aus der Misere. Leider bot die betroffene Maschine noch andere essentielle Dienste an, sodass das keine dauerhafte Lösung sein konnte. Eine Recherche ergab, dass der Apache unter Umständen zu viele sogenannte Semaphoren-Arrays belegt. Bei einem erneuten Auftreten des Fehlers überprüfte ich das mit einem
ipcs -s | grep apache
Apache steht hier für den Benutzer, unter dem der Webserver betrieben wird. Damit bestätigte sich die oben genannte These. Um die nicht mehr benötigten Ressourcen zu löschen verwendete ich
ipcrm -s SemID
oder eleganter in einer Schleife:
for i in `ipcs -s | grep apache | awk {'print $2'}`; do ipcrm -s $i; done
Danach stand einem Neustart des Apaches nichts mehr im Weg.

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.

Neuere Apache-Versionen unterstützen sogenannte Multidomainzertifikate. Damit ist es möglich, mehrere vhost mit nur einem SSL-Zertifikat, welches der Browser als gültig akzeptiert, abzusichern. Um jedoch ein Zertifikat von einer CA zu erhalten, müssen wir ein CSR (Certificate Signing Request) erzeugen. Mit openssl ist diese Aufgabe schnell erledigt. Wie kann man hier aber mehrere Domains angeben? Ein möglicher Weg kann die Erstellung eines CSRs mit mehreren CommonNames sein. Dazu editieren wir /etc/ssl/openssl.cnf. In der Sektion [ req_distinguished_name ] ändern wir den Eintrag:

commonName = Common Name (eg, YOUR name)
commonName_max = 64

in:

0.commonName = Common Name 1 (eg, YOUR name)
0.commonName_max = 64

1.commonName = Common Name 2 (eg, YOUR name)
1.commonName_max = 64
.
.
.
um. Mit einem 0.commonName_default=www.domain.tld kann man auch gleich einen passsenden Standardwert einstellen. Zum Schluß generieren wir uns den Schlüssel mit 2048 bits und den CSR:

openssl req -new -nodes -keyout dateiname.key -out dateiname.csr -newkey rsa:2048

Weitere mögliche Wege gehen über “subjectAltName” oder über “commonName” und “subjectAltName”.

In einigen wenigen Fällen ist erwünscht oder sogar erforderlich, dass man sich auf eine fremde Maschine per ssh ohne Passwortabfrage einloggt. Denkbare Anwendungsfälle sind der Einsatz in Shellskripten oder wie hier näher erläutert, der Aufbau eines Tunnels über ssh, um z.B. ein ungeschütztes Protokoll über das Internet von einer entfernten Maschine auf eine lokale Maschine zu Verfügung zu stellen. Beispielhaft werde ich in den beiden Teilen schildern, wie man PostgreSQL von einer gehosteten Maschine ins lokale Netzwerk bekommt.

In einem ersten Schritt generieren wir uns einen passenden Schlüssel mit dem Kommando ssh-keygen. Wir haben die Auswahl unter RSA-Schlüsseln mit einer Länge von 768 bis 2048 bits und einem DSA-Schlüssel mit genau 1024 bits. Bei RSA-Schlüsseln wird eine Länge von 2048 bits als ausreichend sicher angenommen.

ssh-keygen -t rsa -b 2048

ssh-keygen -t dsa

Die Frage nach dem Speicherort kann man in den meisten Fällen bestätigen, im Normalfall unter ~/.ssh/id_dsa oder id_rsa. Braucht man mehr als einen Standardschlüssel, gibt man einfach einen anderen Namen ein. Die Frage nach einem Passwort und dessen Wiederholung lassen wir leer. Nun müssen wir den öffentlichen Teil des Schlüssels auf den Remothost installieren. Auch hier bringt Linux gleich die passenden Tools mit:

ssh-copy-id -i ~/.ssh/id_dsa.pub user@remotehost

Werden mehere Schlüssel für unterschiedliche Accounts/Maschinen gebraucht, ergänzt man die ~/.ssh/config um folgende Einträge:

Host remotehost
Port 22
IdentityFile ~/.ssh/<key>

Da ich ein Login mit einem ungesicherten Key aus Sicherheitsbedenken ablehnen muss, zeige ich einen eher unbachteten Weg, den so gewonnen Zugang soweit einzuschränken, dass nur die Ausführung eines Kommandos erlaubt wird. Man ergänzt auf dem Remotehost im Homeverzeichnis des users die .ssh/authorized_keys die neu erstellte Zeile, die je nach Art des erstellten Schlüssels mit ssh-rsa für einen RSA-Key bzw. mit ssh-dss für einen DSA-Key beginnt um z.B. den Eintrag:

command="/usr/bin/sleep 1800", ssh-dss ...

Jetzt darf der Besitzer des Schlüssel nur noch /usr/bin/sleep 1800 auf dem Remotehost ausführen. Für unsere Zwecke des Tunnelbaus ideale Voraussetzungen…

Betreibt man einen Apache als Reverse Proxy, so hat man im Allgemeinen das Problem, dass alle
Zugriffe auf dem Backend-Apache als Zugriffe des Frontends geloggt werden. Damit ist es
praktisch unmöglich eine vernünftige Statistik zu erstellen.
Abhilfe schafft hier das rpaf-Modul (reverse proxy add forward). Dieses Modul kann die für andere
Apache-Module sichtbare Remoteadresse ändern. Installiert wird das Modul auf dem Backend. Die
Konfiguration gestaltet sich sehr einfach:

LoadModule rpaf_module mod_rpaf.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.2

Zuerst wird das Modul geladen und eingeschalten.Mit RPAFsethostname werden die selben
Hostnamen wie auf dem Frontend verwendet. Zum Schluß werden die Frontends definiert. Der
Vollständigkeithalber die letzte Direktive:

RPAFheader X-Forwarded-For #wählt Header X-Forwarded-For oder X-Real-IP

Betreibt man in einem Netzwerk ein Active Directory und Subversion (HTTP basierend), bietet es
sich an, das AD für eine Rechtevergabe für das SVN zu verwenden. Mit dem Umweg über ADISS
(Active Directory Interface for Subversion Security) ist dies auch problemlos möglich.
Vorausetzungen sind ein Apache, php (ldap,mysql), mySQL und ein (lesender) Zugriff auf das AD.
Folgt man den Anweisungen in der INSTALL.txt, so ist man in wenigen Minuten am Ziel und
automatisiert so die Verwaltung der Zugriffsrechte auf das Subversion über die
Gruppenzugehörigkeit im AD. Zu finden ist Adiss auf Sourceforge