Als dieser Beitrag entstand war das Grundsystem bereits aktualisiert, auf 13 Jails lief gerade make installworld durch. Ist dieses beendet steht der nächste Reboot an. Dann folgt die Rekompilierung aller aktuell installierter Softwarepakete gegen die neuen Systembibliotheken. Die ganze Aktion wird wohl noch bis Freitag früh dauern, da ich per Reboot sicherstellen möchte, dass garantiert alle Dienste richtig gestartet wurden.

Uptime-Pr0n ist nix für mich. Da vermeidet man einen Reboot und einige Minuten Downtime und vergisst eine Applikation, die noch mit alten Bibliotheken im Speicher läuft. Nach ein paar Wochen wundert man sich, wenn die sich nach einem Reload komisch verhält. Daher gilt heute ausnahmsweise auch unter Unix: Reboot tut gut.

1. SSL-Verbindungen testen

Relativ nah am üblichen Einsatzzweck liegt die Möglichkeit, mit einem simplen Client zu testen, ob ein Server korrekt SSL anbietet oder in den TLS-Modus umschaltet, wenn dies angefordert wird. Am einfachsten geht dies bei einem SSL-gesicherten Webserver, der auf dem Standard-Port 443 lauscht:

openssl s_client -connect mail.rootserverexperiment.de:443

Der s_client wird nun das Zertifikat anzeigen und gegebenenfalls auf Probleme hinweisen, ein “Verify return code” zeigt gegebenenfalls selbst signierte Zertifikate an. Ist das Zertifikat durch, besteht die Möglichkeit, beispielsweise GET-Sequenzen abzusetzen um Webseiten anzufordern.

Ein wenig aufwendiger ist die Kontaktaufnahme mit einem SMTP-Server. Mit diesem wird zunächst Klartext gesprochen, bevor die Anweisung zur Verwendung einer verschlüsselten Verbindung gegeben wird. Auch den Schritt, TLS zu starten, übernimmt openssl mit einem zusätzlichen Schalter:

openssl s_client -connect mail.rootserverexperiment.de:25 -starttls smtp

Nachdem man die Zertifikate betrachtet hat, kann man hier — wie bei Telnet oder Netcat bei unverschlüsselten Verbindungen üblich, die Kommunikation mit SMTP-Befehlen fortsetzen:

EHLO whitehouse.gov
MAIL FROM: george@whitehouse.gov
RCPT TO: mattias@rootserverexperiment.de
...

Der geneigte Admin erkennt schnell: Mit diesem Test ist sichergestellt, dass nicht nur das Zertifikat selbst in Ordnung ist, sondern dieses auch richtig in die Konfiguration des Servers eingebunden wurde (Zugriffsrechte, Pfade). Schlampigkeiten bei der Installation des Zertifikates werden so flott identifiziert.

2. Prüfsummen erstellen

Nicht auf jedem Rechner, auf dem man gerade unterwegs ist, stehen die gängigen Werkzeuge zum Erstellen und Checken von Prüfsummen bereit. Ist OpenSSL installiert, kann dieses verwendet werden um praktisch alle gängigen “Message Digests” zu erstellen. Die (kollisionsfreudige) MD5 zum Beispiel

openssl md5 /tmp/test.bin

oder den eher exotischen RMD160:

openssl rmd160 /tmp/test.bin

3. Dateien verschlüsseln

Verschlüsselung auf die Schnelle? Kein Problem mit OpenSSL! Zumindest symetrische Algorithmen beherrscht das Kommandozeilenwerkzeug perfekt. Das reicht, um eine Datei mit einem Passwort zu versehen und weiterzugeben. Das Passwort kann auf der Kommandozeile übergeben werden. Lässt man es weg, öffnet OpenSSL einen Passwort-Prompt — hier die Verschlüsselung mit 256Bit-AES:

openssl enc -aes256 -k 'Ganz geheimes Passwort' -in datei.txt -out datei.crypt

Der Empfänger (welcher das Passwort auf einem sicheren Weg erhalten hat) kann dann mit dem zusätzlichen Schalter -d die Entschlüsselung starten:

openssl enc -aes256 -d -in datei.crypt -out datei.txt

Diese Form der symetrischen Verschlüsselung hat natürlich den Nachteil, dass der Schlüssel auf Sender- und Empfängerseite bekannt sein muss. Sie taugt daher nicht dazu, bspw. auf einem Server die Logdateien täglich zu verschlüsseln und sie so für Angreifer unbrauchbar zu machen — schließlich ist das Passwort irgendwo im Klartext gespeichert oder es lässt sich schlimmstenfalls über die Prozessliste auslesen. Dafür eignet sich die symetrische Verschlüsselung dafür, Dateien für den Versand an Linux nutzende Empfänger vorzubereiten, die sonst mit Verschlüsselung wenig am Hut haben: OpenSSL ist immer installiert, das Passwort kann am Telefon übergeben werden und die Entschlüsselung ist leicht zu verstehen.

4. Dateien Base64-kodieren

Ganz praktisch ist auch die Möglichkeit, Dateien für dem Versand per Email oder den Einbau in selbst extrahierende Shell-Scripte Base64 zu kodieren. Die Umwandlung einer unverschlüsselten Datei Datei in eine Base64 kodierte entspricht weitgehend der Verschlüsselung, weshalb ich auf auf die Dekodierung nicht weiter eingehe:

openssl base64 -in test.bin -out test.b64

Ein sehr schönes Feature ist jedoch die Möglichkeit, eine Datei zu verschlüsseln und anschließend Base64 zu kodieren, hierbei ist bei der Verschlüsselung und Entschlüsselung der zusätzliche Schalter -a notwendig:

openssl enc -aes256 -k 'Ganz geheimes Passwort' -a -in datei.txt -out datei.crypt.b64

Wofür Sie diese Funktion verwenden, ist Ihnen überlassen — Sinn macht sie beispielsweise beim direkten Versand per Pipeline einer Datei via Mail (einfach den Parameter -out weglassen) oder beim Einbetten binärer und verschlüsselter Daten in Shellscripte.

5. Passwort-Hashes generieren

Haben Sie schoneinmal mit einer 32Bit-Rettungs-CD oder einem 32Bit-Rettungssystem einen Rechner zu reparieren versucht, auf dem ein 64Bit-Linux läuft. Spätestens beim chroot in die gemountete Festplatte des havarierten Systems wird klar, dass die übliche Methode, das Rootpasswort mit passwd zu setzen fehlschlägt. Hier hilft openssl. Mit dem Subkommando passwd entsteht ein Passwort-Hash, der in die Datei /etc/shadow eingetragen werden kann. Der bei Linux übliche MD5-Hash erfordert einen zusätzlichen Parameter:

openssl passwd -1

Passwort-Hashes werden auch bei anderen Anwendungen benötigt: Viele Blogsysteme speichern Hashes für Zugangspasswörter in der Datenbank und Apache vertraut in seinen .htpasswd-Dateien ebenfalls auf MD5-Hashes. opensslbeherrscht natürlich noch andere Hashes, im Zweifel hilft nur ausprobieren.

Alle hier gezeigten Beispiele stammen mehr oder weniger unverändert aus der Manual-Page von openssl beziehungsweise den separaten Manualpages von enc und s_client. Sollten diese auf Ihrem System nicht installiert sein, verwenden Sie die Links um direkt zu den Original-Manualpages zu gelangen.

Das Image kann nach einigen kleinen Absicherungsmaßnahmen durchaus als Produktivsystem eingesetzt werden (beispielsweise Demo-Webserver hinter NAT-Gateway mit DynDNS). Per Default sind die folgenden Dienste nach außen aktiv:

• Apache Webserver mit PHP als Modul, bitte phpinfo.php im Serverroot beachten
• MySQL 5.0.x
• SSHD
• Samba exportiert das WWW-Verzeichnis
• IMAPD (fertig konfiguriert) kann dazu genutzt werden, Mails umzuziehen

Die Passwörter der Defaultnutzer (“pcpraxis” und “root”) lautet “pcpraxis”. Bitte beachten Sie die LIESMICH.txt bezüglich der Absicherung beim Einsatz als “Real World Server”!

• Download FreeBSD Rootie Image

Dear english speaking readers: Currently 50% of all downloads originate from non german speaking countries, but unfortunately I did not yet have the time to provide some english information. If you can’t guess what the LIESMICH.txt says, don’t hesitate to contact me. I’ll provide a “raw translation” immediately.

Die Rolle des Brot- und Butter-UNIX von PDA bis zur zSeries hat bereits vor Jahren Linux übernommen. Dass sich damit nicht unbedingt die technisch beste Lösung durchgesetzt hat, kann ich verkraften, alleine der durch Linux erreichte Grad an Homogenität gegenüber der Situation vor etwa zehn Jahren ist eine deutliche Erleichterung für Anwender und Admins. Wirklich sterben werden die großen Unices nicht so schnell — they’ll just fade away — wenn es dann aber soweit ist, finden Dateisysteme und Konzepte aus “fremden” Kerneln den Weg in Linux und die BSDs.

Schon viele sterbende Sterne haben neue Sonnen geboren.

• Virtualisierung: Ich erstelle zur Zeit viele DVDs für Computerzeitschriften. Qemu ist nicht immer ideal zum Testen, ich möchte in Zukunft auch VMware nutzen können — Und gerade modifizierte Linux-Live-CDs lassen sich besser unter Linux bauen und testen
• Chroot: Ich muss in der Lage sein, schnell und einfach mehrere Linux-Chroot-Umgebungen für Kundenprojekte nutzen zu können. Mit FreeBSDs Linuxolator geht das zwar, aber nicht immer optimal
• Datenaustausch: Wir haben hier mittlerweile einiges an externen Festplatten, die EXT3 formatiert sind — das lässt sich mittlerweile fast so gut als Austauschmedium verwenden wie FAT. Dazu kommen mit SquashFS statt ISO9660 erstellte DVDs — proprietär, aber auch das geht mit Linux
• Ich will Spaß: Mein Garmin GPS 60 möchte ich auch am Desktop auslesen können, fürein Flash-Plugin möchte ich keine Verrenkungen in Kauf nehmen und das N800 soll auch unter Linux flashable sein

Ein FreeBSD-Rechner bleibt wohl im Büro, sei es nur zu Testzwecken. Auf dem Server werde ich bei FreeBSD bleiben. Ich betreibe zwar auch drei Server mit Xen und einigen Linux-Instanzen, aber FreeBSD hat doch den einen oder anderen Vorteil:

• Virtualisierung: Linux bringt keine im Kernel enthaltene Virtualisierungstechnik wie Jails mit. Mit den BSD-Jails lassen sich virtuelle Server ähnlich effizient einsetzen wie sonst nur Shared Hosting — wenn die Kunden hinsichtlich der Prozessorlast nicht allzu sehr in die vollen gehen. Mit den richtigen Nutzern sind deshalb dort 30 Jails möglich wo sonst nur 10 Xen-Instanzen gegangen wären
• Software: Das Ports-Packages-System ist robust und flexibel zugleich. Nichts unter Linux kommt an dieses Paketsystem heran.
• Aufbau: Die klare Trennung zwischen Grundsystem und zusätzlicher Software erlaubt es, jenseits der kritischen Basis “Bleeding Edge” zu fahren und dennoch ein am Fundament stabiles System zu nutzen.
• Verlässlichkeit: Bei FreeBSD gibt es klare Roadmaps für das gesamte System während man bei Linux darauf hoffen muss, dass die Distributoren die richtige Kombination treffen.

Auf dem Server kann ich mir deshalb zur Zeit schwer ein Leben ohne BSD vorstellen. Ideal wäre natürlich die Kombination: FreeBSD-DomUs unter Xen, die wiederum Jails enthalten. Doch zu den ganzen Virtualisierungslösungen werde ich in den nächsten Tagen mal meinen Senf abgeben. Und außerdem ist noch ein Artikel in der Pipeline, der die FreeBSD-Installation auf einem Strato-Rootserver beschreibt. Ganz ohne FreeBSD wird es michdemnach so schnell nicht geben.

PS: Das Update auf Xorg 7.3 hat problemlos geklappt

Ich bin mittlerweile Bücher gewohnt, die wie Kochrezepte einzelne Probleme kurz und knackig abhandeln und am Ende das elektronische Äquivalent eines fertigens Kuchens oder saftigen Bratens zur Folge haben und erst beim nächsten Problem wieder zur Hand genommen werden.

“Mastering *BSD Security” ist anders, lädt zum Schmökern ein. Ich war positiv überrascht, dass bereits das Inhaltsverzeichnis auf den ersten 70 Seiten allgemeine BSD-Sicherheits-Informationen verspricht, und dieses Versprechen mit ausführlichen Hintergrundinformationen zum besprochenen Kapitel einlöst. Beim ersten Lesen des Buches war ich etwas irritiert, besprachen doch viele Abschnitte “nur” die saubere Einrichtung eines *BSD-Servers. Wahrscheinlich liegt in der konsequenten Anwendung des Grundsatzes, dass Sicherheit nicht nachgerüstet werden kann, sondern zu jeder Zeit einbezogen werden muss, das Geheimnis des Buches.

Die Konzentration auf Sicherheit beim Einrichten und Konfigurieren des Systems lässt dennoch genug Platz für die Bergung des Kindes aus dem Brunnen: Kein Sicherheitskonzept ist perfekt, es kann immer wieder zu Zwischenfällen, versuchten und erfolgreichen Angriffen kommen. Allerdings müssen dreissig Seiten für Analyse und Forensik genügen. Arbeiten wie das korrekte Erstellen bitgetreuer Partitionimages setzen die Autoren einfach voraus.

Unter dem Strich ein sehr gutes Buch, das allerdings beim Update- und Patchmanagement zwanzig Seiten mehr vertragen könnte. Linuxer können lediglich von den allgemein gehaltenen Tipps profitieren, diese aber oft auch nicht umsetzen — so ist der MTA sendmail unter *BSD (mit Rechteseparation) weit verbreitet, aber unter Linux verpönt.

Mastering FreeBSD and OpenBSD Security von Yanek Korff, Paco Hope & Bruce Potter ist bei O’Reilly erschienen und kostet 48 Euro. ISBN 0-596-00626-8. Das erste Kapitel kann online gelesen werden.

Das zweite ist openSUSE 10.1. Bei diesem ist SSH und XDMCP offen, es dient mehr zum Testen des Desktops und zum Angeben: wer einen schnellen Prozessor und genug RAM hat, kann auf jeder virtuellen Konsole den Desktop einer anderen Distribution laufen lassen.

Mehr Infos derzeit noch in meinem privaten Blog. Eine offizielle Ankündigungen und Torrents folgen.

mysqldump -u mattias –password=’geheim’ sourcedb | \
ssh -C mattias@ziel.xyz \
“mysql -u mattias –password=’geheim’ draindb”

Der Befehl “mysqldump” schreibt auf die Standardausgabe welche von der SSH angenommen wird. Auf der anderen Seite ruft SSH direkt den MySQL-Client auf und übergibt diesem den Dump. Wichtig ist es, denn auf am Ziel aufzuführenden Befehl in Anführungszeichen zu setzen. Je nach MySQL-Version kann es auch nötig sein, beim Dump oder beim Einlesen mit Gewalt (-f) zu arbeiten.

Die größten Vorteile sind natürlich, dass keine temporäre Datei benötigt wird und der MySQL-Port nicht nach außen geöffnet werden muss. In der Regel stellen auch unterschiedliche MySQL-Versionen kein Problem dar. Und in vielen Fällen reicht diese simpelste Art der Replikation voll aus.

Ganz recht: ich habe das Blog (vorläufig) in den BSD-Jail umgezogen, in dem ich einige weitere eigene Inhalte hoste. Grund für den Umzug ist, dass ich den Hetzner-Rootserver in den nächsten Tagen einmal plattmachen werde, um verschiedene Strategien für die Installation einer anderen Distribution auszuprobieren.

In einem Zug habe ich die Wordpress-Version auf 2.0 aktualisiert. Mit der Umstellung habe ich einige Kleinigkeiten bei der Konfiguration geändert. Permalinks funktionieren nun und Kommentare sind direkt und ohne Bestätigung möglich. Ich werde jeden Abend aussieben.