Captain's blog

Nachdem Peter Gutmann und ich vor einiger Zeit TrueCrypt und Co. auf Nutzbarkeit und Sicherheit der Verschlüsselung getestet haben, haben sich mittlerweile ein paar Dinge an dieser Front getan:
Die Entwickler haben in Zwischenzeit eine neue Version (4.3) herausgegeben, die ein paar Verbesserungen (leider fast ausschließlich für Windows-User) mit sich bringt. Daraufhin haben sich findige Leute einmal auf andere Angriffsvektoren auf die Software konzentriert, und sind prompt (bei der Linux-Version) fündig geworden...

Wer ein öffentlich erreichbares (Unix-) System betreibt, kennt die Problematik der diversen gescheiterten Anmeldeversuche per SSH. Hervorgerufen durch Bots, die triviale Kombinationen und Passworten durchprobieren, müllen sie Logfiles zu, und finden schlimmstenfalls sogar wirklich einen Luser, der ein leicht zu erratendes Passwort nutzt.
Lösungen für dieses Problem sind (nicht nur hier) bereits mehrfach angesprochen worden; angefangen bei einfachen Maßnahmen wie der Verlegung des Port von 22 auf einen anderen, nicht standardgemäßen. Nutzung von SSH-Public Keys. Weiter über Paketfilter und eigens hierfür entwickelte Tools wie z.B. denyhosts oder fail2ban.

Eine gänzlich andere Möglichkeit, die darüber hinaus noch weitere Vorteile bietet ist die Authentisierung über Einmalpassworte. In Verbindung mit einer Zwei-Faktorauthentisierung (wie sie z.B. RSA mit den SecureID-Tokens) vormacht kommt zusätzlich zum Passwort noch eine Besitzkomponente hinzu. Ohne Token, das das OTP anzeigt, ist kein Zugang möglich.

Leider lohnen sich der Kauf dieser Token für den "Privatgebrauch" nicht wirklich, immerhin existieren mittlerweile (freie) Projekte, die diese Technik sehr kostengünstig ermöglicht. Das wohl vielversprechendste ist hier wohl FreeAuth.
Statt eines Hardwaretokens kommt hier das (in den allermeisten Fällen eh vorhandene) Handy zum Einsatz, das mit Hilfe eines kleinen Stückchen Java-Software die Funktion schnell und einfach nachbildet.

Im Zuge des (hoffentlich) bald fertigen Artikels über Crypto-Filesysteme unter Linux habe ich kürzlich endlich einmal ein Projekt in Angriff genommen, das ich schon längst einmal angegangen sein wollte: die Verschlüsselung des gesamten Systems auf der Festplatte.
Im Gegensatz zu einem meiner älteren Artikel, der die Verschlüsselung von /home und Swap mit Hilfe des (mittlerweile obsoleten) Cryptoloop-Systems beschreibt, kommt in diesem Fall DM-Crypt inklusive der LUKS-Erweiterung(en) zum Einsatz. Glücklicherweise sind die meisten Werkzeuge für das Vorhaben bereits unter Dapper bereit, ein paar Hürden galt es jedoch zu überwinden.

Inspiriert ist dieses kurze Howto durch einen Blogeintrag von Sternensucher, sowie einem (eigentlich veralteten) Thread im Ubuntu-Forum.
Obwohl das Vorhaben sicherlich auch aus einem laufenden System heraus machbar wäre, wird das System im folgenden komplett neu installiert.

Bevor es losgeht, noch der obligatorische Disclaimer:
1. Dieses Howto richtet sich an Personen, die (wenigstens ungefähr) wissen, was sie damit anstellen. Die hier vorgestellte Vorgehensweise hat sich für mich als stabil und gangbar erwiesen. Sollte das bei dir nicht der Fall sein, kann ich dich (zur Zeit) nur schlecht bis gar nicht supporten.
2. Eine Datensicherung bereits im Vorfeld ist unabdingbar.
3. Solltest du deine Daten (durch dieses Howto, eine vergessene Passphrase, whatever) verlieren, übernehme ich keine Verantwortung dafür.

Da auch das geklärt ist, kann's ja nun losgehen:

Seit dem gestrigen Update meiner Dapper-Installation auf dem T30 war es mir nicht mehr möglich, eine automatisierte WPA-Verbindung zum Access-Point aufzubauen.

Bei der Analyse des Problems fiel mir dann auch sehr schnell ins Auge, dass drei wichtige, zum Paket gehörende Dateien (/etc/default/wpasupplicant, /etc/init.d/wpasupplicant und /etc/wpa_supplicant.conf) umbenannt waren, und nunmehr die Endung ".dpkg-bak" trugen.
Da ich es zu dem Zeitpunkt gestern relativ eilig hatte, brachte ein beherzter manueller Aufruf (wpa_supplicant -B -D wext -c /etc/wpa_supplicant) erst einmal das gewünschte Ergebnis: die Verbindung war wiederhergestellt.

Dass (fast) alle getroffenen Sicherheitsmaßnahmen, vor allem "externe" wie z.B. Firewalls etc. herzlich nutzlos sind, sobald ein Angreifer die physikalische Kontrolle über einen Rechner hat, ist wohl seit langem kein großes Geheimnis.
Spätestens durch das Booten einer passenden CD (günstigstensfalls, nachdem man BIOS- und sonstige Bootloaderpassworte überlistet hat), hat man volle Kontrolle über die auf der Festplatte liegenden Daten. Sind diese verschlüsselt, dürfte der Zugriff allerdings erheblich schwieriger sein. Nicht zuletzt deshalb bietet sich eine solche Vorgehensweise besonders bei Notebooks an.

So lange ein Rechner läuft, und die verschlüsselten Daten im Klartext vorliegen, sind allerdings auch diese angreifbar. Neuere "Forschungen" lassen aber auch den besten lokalen Schutz, seien es hochsichere Passworte oder vollständig für die Außenwelt geschlossen Ports recht alt aussehen.

Es ist mal wieder so weit: entgegen den bisherigen Plänen, einen Artikel über Tarantella (ups sorry, soll natürlich Sun) Secure Global Desktop und NX zu schreiben, genießt ein ganz anderes Thema seit gestern Prio eins.

Dieser Artikel wird wohl der für mich bisher interessanteste, nicht zuletzt deshalb, weil ich ihn in Zusammenarbeit mit jemand anderem schreibe. Ich werde dabei die Praxistauglichkeit von Festplatteverschlüsselungs-Tools unter Linux testen, darunter die beiden im Userspace arbeitenden EncFS und CryptoFS, sowie die kernelbasierten DM-Crypt, TrueCrypt und (unter Umständen) das kommerzielle BestCrypt.
Das eigentlich interessante an der Sache ist jedoch, dass kein geringerer als Peter Gutmann (Autor u.a. von "Secure Deletion of Data from Magnetic and Solid-State Memory") die theoretische Seite der Software untersuchen wird, der Artikel also letztendlich einem (kleinen) Security-Audit ziemlich nahe kommen wird.

Der erste Kontakt mit Peter war jedenfalls schon äußerst positiv, besonders, da ich ihm aus lauter Faulheit auch auf deutsch schreiben kann...was eigentlich auch ein Vorteil für ihn ist, da er mein grottenschlechtes Englisch so nicht ertragen muss.

Ich freue mich jedenfalls schon sehr auf die weitere Zusammenarbeit und auf das, was sie zutage fördern wird.

Nachdem ich jetzt mittlerweile ein paar Tage mit EncFS herumgespielt habe, frage ich mich zunehmend, wieso die Verschlüsselung von mehreren Dateien und / oder Verzeichnissen bislang so aufwändig war. Wenn ich daran denke, welchen Aufwand ich für meinen damaligen Artikel über verschlüsselte Filesysteme betrieben habe, kommt mir die Arbeit mit EncFS vor wie ein Kinderteller.

Auch wenn's doch erst sehr spät kommt, wünsche ich allen hier lesenden ein gutes und erfolgreiches neues Jahr,. Ich für meinen Teil bin am Abend des 1.1. wieder zuhause angekommen, und habe bis heute schon wieder einiges erlebt. Mit Details möchte ich euch an dieser Stelle aber nicht langweilen, immerhin habe ich mich in letzter Zeit ja doch recht rar gemacht, und will niemanden mit belanglosen persönlichen Dingen vergraulen..

Den ersten Eintrag des Jahres werde ich auch recht kurz halten, da ich leider erst seit gestern mit alternativen Möglichkeiten der Verschlüsselung von Daten auf Festplatten befasse. Seit meinem Artikel zum Thema im Linux-Magazin hat sich diesbezüglich ja doch einiges getan.
Durch ein Posting im RootForum bin ich zum ersten Mal auf die Möglichkeit gestoßen, mit Hilfe von fuse für Verschlüsselung zu sorgen. Das Ganze nennt sich dann schlicht und ergreifend encfs, dessen Möglichkeiten ich immer interessanter finde.

Das auch im Posting genannte TrueCrypt hingegen regt mich irgendwie (rein subjektiv) nicht so zum "rumspielen" an. Vielleicht täuscht mich mein Gefühl in diesem Punkt ja vollkommen, und sofern mich jemand da eines besseren belehren kann, würde ich mich sehr über Erfahrungsberichte freuen.

Bis dahin aber teste ich auch weiterhin mit encfs rum, und werde Erfahrungsberichte im Laufe der nächsten paar Tage hier als "Rückkehr" veröffentlichen. Vielleicht entwickelt sich bis dahin ja hier schon eine kleine Diskussion.

Kaum durchwühlt man "kurz" wieder die Neuigkeiten, die einem sein Feedreader so ins Haus liefert, wird doch wieder was längeres daraus...

In diesem Fall hielt mich ein Interview auf SecurityFocus auf Trab, in dem auf neue Features der kommenden OpenSSH-Version (4.3) eingegangen wird.

Kryptologen bezeichnen mit "Snake Oil" (meist kommerzielle) Verschlüsselungsmethoden, die bei genauer Betrachtung nur sehr wenig bis gar keinen Schutz bieten.

In "Admin-Kreisen" spricht man zumeist von selbstsignierten SSL-Zertifikaten, die Webseiten "absichern" sollen, beim Client aber jedes Mal auf's Neue sämtliche Warnfenster des Browsers anspringen lassen. Dass die meisten User diese Warnungen mittlerweile einfach ignorieren und wegklicken, ist wohl kein großes Geheimnis mehr.

Im Moment "überzeuge" ich hier im Blog wohl doch eher durch Masse statt Klasse. Sorry dafür...

Anscheinend muss ich dieses Jahr kurz nach Weihnachten doch mal nach Berlin: der "Fahrplan" ist seit heute online. Da ich aber über Weihnachten wohl weiter unten im Süden Deutschlands sein werde, könnte das eine etwas längere Tour werden...wenn ich mir das Programm aber so anschaue, fallen mir aber direkt ein paar Punkte auf, die ich nur zu gerne miterleben möchte.

Sollte meine Zeitplanung also funktionieren, habe ich wohl ein sehr straffes Programm vor mir :

Über Freshmeats RSS-Feed bin ich heute Morgen (nach längerer Zeit mal wieder) auf pam_usb gestoßen.

Es handelt sich hierbei um ein PAM, mit dessen Hilfe sich Logins anhand von Public Key-Kryptographie (DSA) bewerkstelligen lassen. Der private Teil des Schlüssels befindet sich dabei auf einem Wechselmedium wie z.B. einem USB-Stick, auch Disketten (für diejenigen, die sowas nicht mehr kennen gibt's noch den Wikipedia-Eintrag zu Disketten ) oder CD-ROMs kommen in Frage.
Da die beiden letztgenannten Varianten allerdings zum Teil nicht so einfach zu transportieren sind, wird im folgenden nur auf die Nutzung via USB eingegangen.

Auch wenn ich das Teil vor gar nicht so langer Zeit wieder abgegeben habe, liebäugle ich irgendwie immer noch mit dem BlackBerry. Nicht zuletzt deshalb fand ich die Neuigkeiten zu dem Gerät heute auf Heise extrem interessant.

Die Idee, USB-Sticks mit seiner favorierten Linux-Distribution zu bestücken ist ja nicht neu. Selbst der iPod Nano fasst ein vollständiges SLAX (das seinerseits auf Slackware beruht).

Sicherheitstechnisch betrachtet ist das Booten eines "sauberen" Systems auf einem nicht vertrauenswürdigen Rechner schon einmal die halbe Miete. Wem das allerdings immer noch nicht paranoid genug ist, findet auf Debian-Administration ein sehr gutes Tutorial das beschreibt, wie sich Debian vollständig verschlüsselt auf einem USB-Stick unterbringen lässt. Immerhin sind diese heutzutage immerhin so groß, dass sie ein sehr komplettes System fassen können.
Vor einem Hardware-Keylogger schützt einen allerdings leider auch die stärkste Verschlüsselung nichts...was aber nichts ist, was sich nicht z.B. via xvkbd lösen ließe.

Ich finde das Projekt jedenfalls so interessant, dass ich's demächst (wenn irgendwann einmal wieder Zeit da ist ) unbedingt mal ausprobieren werde...auch wenn ich mich, wenn ich mal (ausnahmsweise) ohne Laptop unterwegs bin schon irgendwie etwas "nackt" fühle.

Wer "nur mal kurz" ein paar Dateien verschlüsseln will, greift meist zum allseits beliebten GPG (hierzu ein kleines Tutorial).

Wem es allerdings zu kompiliziert ist, Schlüssel anzulegen, zu verwalten etc., oder der Meinung ist, solche Tools nicht zu benötigen (gibt's leider noch viel zu oft), findet im (meist ohnehin vorhandenen) OpenSSL eine einfache, aber recht interessante Alternative.
Statt mit Public Key-Kryptographie kommen dabei allerdings gute alte Passwörter zum Einsatz. Im direkten Vergleich sind diese zwar (alleine aufgrund der Länge) um einiges "unsicherer", für den "normalen Hausgebrauch" reicht es aber meist trotz allem aus.