Worum es geht

»Wuala« (gesprochen »Voilà«), ein Kollege hatte mich bekehrt, mir hier einen Account zu holen und ich muss sagen, dass ich doch recht begeistert bin von dem Service. »Wuala« ist quasi eine Online-Festplatte, ähnlich wie »Dropbox«. Der Unterschied liegt aber in der Art, wie auf die Daten zugegriffen wird. Bei der »Dropbox« wird auf der Festplatte ein Ordner angelegt. Alles was dort rein kopiert wird, wird automatisch auf einen zentralen Server kopiert und zwischen diesen beiden Orten synchronisiert. Ich habe den Dienst damals hauptsächlich genutzt, um Dateien mit meinem Android-Smartphone auszutauschen. Mittlerweile hat »Wuala« diese Aufgabe übernommen. Anders als bei »Dropbox« wird hier direkt auf die Online-Festplatte zugegriffen. Gut es gibt für den schnelleren Zugriff auf diese Daten einen in der Größe einstellbaren Caching-Bereich auf der lokalen Festplatte, im Prinzip aber werden die Daten direkt online gespeichert. Laut FAQ verschlüsselt »Wuala«die Daten bereits im Client und lädt die Datei dann, gestückelt in Fragmente, an unterschiedliche Orte hoch. 1GB bekommt hier jeder zu Anfang, wer meinen Promocode nutzt startet mit 2GB. Im Internet sind weitere Codes erhältlich, mit denen man sein Kontingent nach der Anmeldung noch weiter erweitern kann (einfach mal googlen). Gibt man noch einen Bereich seiner Festplatte für andere Nutzer frei und hält den eigenen PC mind. 4 Std. am Tag online, so bekommt man anteilig noch weiteren Speicherplatz zugeordnet. Eine schöne Idee wie ich finde.

Jetzt aber zu dem eigentlichen Vorhaben. Was die Verschlüsselung der Daten angeht, so muss man dem vertrauen, was die Macher von »Wuala« auf ihrer Seite versprechen. Die Software ist leider Closed-Source. Und genau hier liegt das Vertrauensproblem. Annähernd private oder sogar vertrauliche Daten würde ich hier nicht ablegen. Jetzt ist der Speicherplatz aber nach einiger Zeit so weit gewachsen, dass man ihn durchaus auch für das Backup von Daten nutzen könnte. Also einfach noch eine eigene Verschlüsselungsebene implementieren hab ich mir gedacht. Hier gibt es sicher viele Möglichkeiten, wenn es aber noch einigermaßen performant sein soll, fällt z.B. »TrueCrypt« raus. Es muss irgendetwas her, was auf Dateibasis verschlüsselt. Unter »Ubuntu Linux« ist hier  »eCryptfs« zum Standard geworden, um z.B. das Home-Verzeichnis zu verschlüsseln. Ich hab es genutzt, um einen Bereich in meinem Home-Verzeichnis zu verschlüsseln, und die verschlüsselten Daten dann auf »Wuala« zu synchronisieren. Hierbei direkt auf dem »WualaDrive« zu arbeiten hat leider nicht funktioniert. Trotzdem ist es eine, wie ich finde, recht schöne Lösung.

Installation und Initialisierung von eCryptfs

Als erste schaffen wir die Grundvoraussetzungen. Unter »Ubuntu Linux« wird »eCryptfs« wie folgt installiert.

sudo apt-get install ecryptfs-utils keyutils

Wer nicht vor hat, »OpenSSL« und zusätzlich zu der Passphrase einen Key für die Verschlüsselung zu benutzen, kann die »keyutils« auch weglassen. In diesem einfachen Beispiel wird das Paket nicht benötigt.

Im Home-Verzeichnis werden nun die beiden für »eCryptfs« benötigten Verzeichnisse eingerichtet.

mkdir ~/.WualaDrive-Secret
mkdir ~/WualaDrive-Secret

Im ersteren Verzeichnis liegen später die verschlüsselten Daten, letzteres bietet Zugriff auf die selbigen. Wer »eCryptfs« bereits genutzt hat wird sich an dieser Stelle fragen, warum 2 verschiedene Verzeichnisse genutzt werden. Die Antwort ist einfach: Wir wollen sicher gehen, dass »Wuala« nicht versehentlich die unverschlüsselten Daten synchronisiert.

Nun wird die Verschlüsselung eingerichtet:

sudo mount -t ecryptfs ~/.WualaDrive-Secret ~/WualaDrive-Secret

Nun wird die Passphrase vergeben, also quasi das Passwort, mit dem die Daten verschlüsselt werden. Hier solltet ihr euch z.B. einen Satz ausdenken und diesen z.B. mit Sonderzeichen und Zahlen verfeinern. Wichtig aber ist, dass diese Passphrase bei jedem mounten des verschlüsselten Bereichs eingegeben werden muss. Die Komplexität sollte also in Abhängigkeit von der Wichtigkeit der Daten bestimmt werden.

Passphrase: [HIER DEINE PASSPHRASE EINGEBEN]

An dieser Stelle wird der Verschlüsselungsalgorithmus ausgewählt, »AES« ist hier eine gute Wahl.

Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]: [ENTER FUER AES]

Ebenfalls in Abhängigkeit von der Wichtigkeit der Daten wird hier die Keysize bestimmt. Wer hier glaub mehr ist mehr, findet in diesem Dokument möglicherweise eine wichtige Entscheidungshilfe (danke an j-zero an dieser Stelle). Wir wählen hier also 16 Bytes, sprich eine 128bit AES-Verschlüsselung.

Select key bytes:
1) 16
2) 32
3) 24
Selection [16]: [ENTER FUER 16 BYTES, SPRICH 128bit KEYSIZE]

Folgendes hab ich auch nicht verstanden, glaube aber es handelt sich hierbei um eine Textdatei, in der wir unsere Passphrases übergeben können. Unsicher, wollen wir nicht, also »n«.

Enable plaintext passthrough (y/n) [n]:

Sollen die Dateinamen ebenfalls mit verschlüsselt werden? Aber »ja«.

Enable filename encryption (y/n) [n]: y

Nun werden uns die Optionen angezeigt, mit denen das Verzeichnis gemountet wird. Die Signaturen bitte merken und ebenfalls die Optionen, solltet ihr hier von meinem Beispiel abgewichen sein.

Filename Encryption Key (FNEK) Signature [xxxxxxxxxxxxxxxx]:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=xxxxxxxxxxxxxxxx
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=xxxxxxxxxxxxxxxx
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Bei dem ersten Mount bekommt ihr hier diese Warnung. Dies ist völlig normal, da die Verschlüsselung vorher ja noch nicht aktiv war. Wir wollen also mit den oben genannten Optionen weitermachen.

Would you like to proceed with the mount (yes/no)? : yes

Fertig, die Ausgabe von »mount« sollte nun folgendes mit ausgeben.

Nach dem Anlegen von ein paar Testdateien unter ~/WualaDrive-Secret/ sollten sich die Verzeichnisse wie folgt präsentieren.

 Synchronisierung mit Wuala

Die Synchronisierung ist unter »Wuala« recht schnell eingerichtet. Wie wollen hier natürlich nur den verschlüsselten Ordner hochladen.

• Wuala öffnen
• Im Menü “Ansicht” den Punkt  “Sync Überblick” auswählen oder einfach STRG+F9 drücken
• Rechts auf das grüne “+” (Neuen Sync-Ordner anlegen)
• “Lokaler Ordner” ist der versteckte Ordner (bei mir /home/carsten/.WualaDrive-Secret) . Unter Gnome mit STRG+H ggf. die Anzeige von versteckten Dateien aktivieren
• “Ordner in Wuala” wird automatisch generiert und kann so übernommen werden

Fertig, die Synchronisierung kann nun auf jeden beliebigen weiteren Linux-Rechner, auf dem »Wuala« im Einsatz ist, übernommen werden.

Mounten und unmounten von eCryptfs

Das Mounten kann im Grunde wieder jedesmal genauso durchgeführt werden, wie auch das Einrichten weiter oben beschrieben wurde. Um sich aber nicht jedesmal durch die vielen Abfragen kämpfen zu müssen, können diese Optionen bei dem Mount mit übergeben werden. Ihr erinnert euch und habt eure Optionen vorhin doch sicher notiert? Wenn ihr meine Optionen übernommen habt, müsst ihr nur die Signatur austauschen.

Um das Ganze etwas zu beschleunigen habe ich mir für das Mounten/unmounten folgendes Script angelegt.

Der Aufruf »mountSecret.sh« hängt das verschlüsselte Laufwerk ein, fragt ggf. zuerst nach dem Sudo-Passwort und hinterher nach der Passphrase. Um das Laufwerk hinterher wieder auszuhängen reicht der Aufruf »mountSecret.sh stop« oder »mountSecret.sh unmount«.

Nun wünsche ich viel Spaß mit »Wuala«. Wenn ihr noch keinen Account habt und euch anmelden wollt, nutzt, wie oben schon erwähnt, meinen Promocode. Ihr startet automatisch mit 2GB anstatt 1GB.

Nachdem ich heute auf einen Windows Server 2003 die aktuellen Updates eingespielt hatte, streikte die LDAP-Apache Anmeldung an einer meiner Intranet-Seiten mit folgenden Meldung:

Zugegeben war der Windows Server 2003 etwas in Vergessenheit geraten und sehr lange schon nicht mit Updates versorgt, ich kann also nicht sagen, welches hier schuld gewesen ist. Begründung und Lösung wird in diesem ebenfalls sehr alten Bug Report beschrieben. Kurz zusammengefasst liegt das Problem möglicherweise daran, dass bei der Abfrage eines Benutzers mehrere Referenzen zurückgeliefert werden. Umgangen werden kann dies, indem man etwas später erst in den Baum einsteigt, z.B. nur in der OU sucht, in der auch die Benutzer liegen:

Sollte dies nicht möglich sein, weil man z.B. in mehreren OUs suchen möchte oder muss, so kann man seine » AuthLDAPURL« auf den »Global Catalog« verlegen, hier werden die bösen Referenzen nicht mit zurückgeliefert. Ob der Port 3268 offen ist, verrät ein »nmap«, hier ein Auszug der normalen LDAP-Ports und der des »Global Catalog«:

Sind Port 3268 und 3269 nicht offen, so wird hier erklärt, wie der »Global Catalog« erstellt wird.

Tauscht man den Port 389 also einfach gegen 3268, so kann man wieder problemlos das gesamte Verzeichnis durchsuchen:

Für mich funktionieren beiden Lösungen, ich bleibe nun aber bei der Nutzung des »Global Catalog«.

Nachdem ich heute einmal meine Logfiles durchgegangen war, ist mir aufgefallen, wie viele verschiedene Hosts mitlerweile permanent damit beschäftigt sind Bruteforce-Attacken auf meinen SSH-Port durchzuführen. Echt unterhaltsam zu sehen, welche Logins hier teilweise durchprobiert werden. Um diese Hosts nun zu blocken bin ich im Internet auf mehrere Möglichkeiten gestossen. Ich wollte es eigentlich sportlich sehen und selber etwas scripten, bin dann aber auf ein Tool Namens »fail2ban« gestossen, welches in den Debian- und Ubuntu-Repositories enthalten ist und ganz einfach über

installiert werden kann. »Whois« wird hier als optionale Abhängigkeit gleich mit installiert und bei dem Versand von Mails dazu genutzt, nützliche Informationen über den Angreifer-Host mitzuliefern, hierzu gleich mehr. Kurz überprüft ob der Daemon auch gestartet wurde, ist nun im Prinzip schon alles Wichtige getan. Administratoren mehrerer Server können so also sehr schnell zusätzliche Sicherheit in ihre Systeme bringen.

Iptables deaktivieren

Auf Systemen, auf denen »iptables« schon eingesetzt wird, bzw. ein anderes Firewall-Script die Hoheit über das durchaus schnell chaotisch wirkende Regelwerk hat, kann es sinnvoll sein, von »iptables« auf die »/etc/hosts.deny«-Methode auszuweichen. Jeder Host, der z.B. zu viele SSH-Anfragen getätigt hat, wird dann über die »/etc/hosts.deny« komplett geblockt. Hierzu kann die Datei »/etc/fail2ban/jail.conf« in Zeile 45 folgendermassen verändert werden:

Mailversand aktivieren

Es ist natürlich jedem selbst überlassen, ob er bei jedem Ban mit E-Mails belästigt werden möchte. Per Default ist es erst einmal deaktiviert und das ist sicher auch gut so, wenn ich sehe was bei mir hier momentan alles eingeht. Die Tätigkeiten von »fail2ban« werden lückenlos in der Datei »/var/log/fail2ban.log« protokoliert, wer trotzdem per Mail informiert werden möchte kann dies in der Datei »/etc/fail2ban/jail.conf« in Zeile 34 und 72 aktivieren:

»action_mwl« bewirkt, dass neben dem Whois-Report über den Angreifer auch alle relevanten Logeinträge angehängt werden

Sollte jemand Erfahrungen mit anderen Tools gesammelt haben, evtl. auch richtigen »IDS«, die schnell und ohne großen Anpassungsaufwand eingesetzt werden können, würde ich mich über einen Kommentar freuen.

Da soll also ein kritischer Server, der unter VMWare in der DMZ läuft, per VMotion verschoben werden. Nur wie wird das Ganze überwacht? Im Normalfall lasse ich hier einen Ping laufen, einfach um zu sehen, dass das Zielnetz auf dem neuen Host auch vernünftig durchgereicht wird und der Server durchgehend erreichbar bleibt. Per ICMP-Echo ist die gute Maschine in der DMZ aber nicht erreichbar, also per WHILE-Schleife ein »Ping« auf Port 80. So die einfache Idee, leicht erweitert sollte das folgende Script in keiner Tools-Sammlung fehlen:

tcpping.sh:

j-zero, der bei der Umsetzung geholfen hat, wird das Script sicherlich noch um das eine oder andere Feature erweitern.

Wer Ubuntu Hardy (8.04) nativ auf einem IBM Blade vom Typ HS21 XM (7995) einsetzt, sollte einmal überpüfen, ob das System bei Volllast nicht unerwartet in einen Freeze läuft. Bei uns ist dies nun zum 2. Mal aufgetreten (siehe Bild), beim ersten Mal hatte der Blank-Screen den Absturzgrund erfolgreich verstecken können, Logeinträge bleiben hier natürlich ebenfalls aus. Da es sich um keinen Hardwarefehler handelt, hüllt sich ebenfalls auch das Eventlog vom Bladecenter in Schweigen.

Der »Konsolen-Bildschirmschoner« lässt sich über folgenden Eintrag in der »/etc/rc.local« abschalten (hinterher muss natürlich entweder neu gestartet oder »/etc/rc.local« einmalig manuell über tty1 ausgeführt werden):

Kurze Zeit später ist der Fehler erneut aufgetreten, das hängende »htop« hat noch 3 CPU-Kerne auf 100% angezeigt, in der Console war folgender Fehler zu erkennen (siehe auch Bild):

Um den Fehler nun zu umgehen, wird der Kernelaufruf um die Parameter »nmi_watchdog=0 nohpet« ergänzt. Die Kernelparameter werden dafür in der Datei »/boot/grub/menu.lst« folgendermassen editiert:

Im Anschluss wird die menu.lst über »update-grub« aktualisiert, das System kann neu gestartet werden und sollte nun auch unter Volllast stabil laufen. Bei mir tut es dies nun seit 3 Tagen.