WeizenSpr.eu

Wenn man einen Server aufsetzt, auf dem potentiell auch persönliche Daten (z.B. E-Mails) abgelegt werden sollen, kommt man früher oder später an den Punkt, an dem man sich über die Sicherung dieser Daten Gedanken macht. Für die permanente Verschlüsselung auf der Festplatte gibt es inzwischen glücklicherweise gute Standardtools, die einem viel Arbeit abnehmen können.

Um sie nutzen zu können, muss man sie jedoch erst einmal installieren. Dazu könnt ihr (unter Debian) folgenden Befehl nutzen:

Beginnen wir mit etwas einfachem. Zuerst einmal wollen wir die Swap-Partition verschlüsseln. Was bringt es uns, die Daten zu verschlüsseln, wenn sie bei Speichermangel trotzdem unverschlüsselt auf der Platte landen? Hierfür deaktivieren wir erst einmal die derzeit verwende Swap-Parrtition:

Anschließend gehen wir in die Datei "/etc/fstab" und sehen uns an, wie das Swap-Device heißt. In meinem Fall (da ich ein Software-RAID verwende) finde ich folgende Zeile:

Das Device heißt bei mir also "/dev/md0". Hier könnte auch "/dev/sda1" oder soetwas stehen. Das hängt ganz von eurer Plattenkonfiguration ab! Diese Zeile könnt ihr übrigens gleich auskommentieren und die Datei durch folgende, neue Zeile ergänzen:

Als nächstes gehen wir nun in die (während der Installation von cryptsetup angelegte) Datei "/etc/crypttab". Dort können wir verschlüsselte Devices definieren, die während dem Hochfahren geöffnet werden sollen. Hier tragt ihr nun eine neue Zeile ein:

Denkt daran, den Devicenamen "/dev/md0" durch den zu ersetzen, den ihr in eurer "/etc/fstab" Datei gefunden habt (also z.B. "/dev/sda1")!

Bevor ihr die Partition tatsächlich nutzt, solltet ihr sie noch einmal mit Zufallsdaten überschreiben, um sicher zu gehen, dass sich dort nicht bereits Daten befinden, die ausgelesen werden könnten. Einfache Gemüter können einen BadBlocks-Lauf mit Zufallsdaten durchführen:

Denkt daran, "/dev/md0" wieder durch euer richtiges Device zu ersetzen! Paranoide Gemüter können natürlich per DD bessere Zufallsdaten schreiben lassen:

Denkt auch hier daran, "/dev/md0" durch euer richtiges Device zu ersetzen! Wenn ihr damit fertig seid, könnt ihr auch schon anfangen, eure verschlüsselte Swap-Partition zu nutzen. Dazu führt ihr folgende Befehle aus:

Um zu gucken, ob alles funktioniert hat, könnt ihr folgenden Befehl nutzen:

Hier sollte nun im Idealfall folgendes ausgegeben werden:

Es ist möglich, dass hier anstelle von "/dev/dm-0" ein anderes Device steht. Es sollte allerdings unbedingt mit "/dev/dm-" beginnen! Auch die Werte "Size", "Used" und "Priority" könnten bei euch anders sein. Falls dort jedoch immernoch etwas wie "/dev/sda1" steht, ist etwas schief gelaufen!

Kommen wir nun zur Verschlüsselung einer Datenpartition. Auch hierzu solltet ihr wieder in die Datei "/etc/fstab" gehen und das richtige Device heraussuchen. In meiner Datei befindet sich dort die passende Zeile:

In meinem Fall heißt das Device also "/dev/md2". Darüber hinaus ist es bei mir als Ordner "/daten" gemounted und ist als EXT4-Dateisystem formatiert. Das hängt natürlich wieder von eurer jeweiligen Konfiguration ab! Dort könnte also als Device "/dev/sdb2", als Mountpoint "/tmp" und als Dateisystem "ext3" stehen oder ähnliches. Ihr könnt die Zeile nun auskommentieren - ihr werdet das Device später mit einem eigenen Script laden und mounten.

Als nächstes könnt ihr mit folgendem Befehl gucken, ob das entsprechende Device noch gemounted ist:

Sollte sich in der Konsolenausgabe eine Zeile mit dem Devicenamen (z.B. "/dev/md2") und dem Mountpoint (z.B. "/daten") befinden, müsst ihr das Device zuerst unmounten - in meinem Beispiel mit:

Als nächstes überschreiben wir die Partition wieder mit Zufallsdaten. Achtung! Ihr verliert durch diesen Schritt sämtliche Daten, die auf dieser Partition gespeichert sind! Hier wieder die jeweiligen Befehle. Ihr müsst "/dev/md2" durch euren entsprechenden Devicenamen ersetzen:

...oder...

Als nächstes erstellen wir bereits die neue Partition. Hierfür führen wir nacheinander folgende Befehle aus. Der erste Befehl fragt, ob ihr wirklich fortfahren wollt und bittet euch dann um die Eingabe eines Passwortes. Dieses Passwort ist sehr wichtig! Ihr werdet es zukünftig brauchen, um auf die Partition zugreifen zu können. Ihr solltet ein sicheres Passwort verwenden! Von diesem Passwort hängt die Sicherheit der Verschlüsselung ab! Leicht erratbare Passwörter bringen mehr Schaden als Nutzen. Vergewissert euch zudem, dass der Devicename korrekt ist und ersetzt "/dev/md2" entsprechend!

Nachdem mit dem ersten Befehl das neue verschlüsselte Device angelegt (und entsprechende Header auf die Platte geschrieben wurden), wurde mit dem zweiten Befehl das Device geöffnet - dafür musstet ihr das vorher eingerichtete Passwort kennen. Danach wurde auf diesem Device ein Dateisystem (EXT4) eingerichtet. Abschließend wurde das Device wieder geschlossen. Super! Damit habt ihr euer verschlüsseltes Device erstellt!

Normalerweise würde man die verschlüsselte Partition nun in der Datei "/etc/crypttab" hinterlegen, damit sie beim Hochfahren automatisch geöffnet und gemounted wird. Bei einem Remote-System, das wir nur per SSH erreichen, haben wir jedoch das Problem, dass wir beim Bootvorgang gar nicht die Möglichkeit haben, das benötigte Passwort einzugeben. Bei der Swap-Partition konnten wir das tun, da wir dort einfach bei jedem Start ein neues Passwort (aus "/dev/urandom") erzeugen. Für die Swap-Partition ist das nicht problematisch - die Daten werden nach dem Neustart sowieso nicht mehr benötigt. Bei allen anderen Partitionen würde dies jedoch einen vollständigen Datenverlust nach jedem Reboot bedeuten.
Man könnte nun natürlich anfangen und Schlüsseldateien hinterlegen. Dadurch würde jedoch das ganze System gebrochen werden. Denn auch jeder externe Angreifer könnte sich diesen Schlüssel (der ja unverschlüsselt vorliegen muss) von der Platte holen.

Aus diesem Grund gehen wir den einfachen Weg: Wir erstellen uns ein Script, das das Öffnen und Mounten des Devices für uns übernimmt. Dieses müssen wir lediglich nach jedem Reboot einmal ausführen, um unser System wieder in einen arbeitsfähigen Zustand zu bringen:

Ersetzt den Devicenamen und den Mountpoint durch das, was ihr benötigt (z.B. durch das, was vorher in eurer "/etc/fstab" Datei stand). Ihr solltet euch zudem ein Script anlegen, das ihr immer dann ausführt, wenn ihr das System herunterfahren wollt. Auch dieses müsst ihr an eure Bedürfnisse anpassen:

Ein Angriffsvektor bleibt leider bestehen: Das eigentliche Linux-System kann nicht verschlüsselt werden. Der Grund ist der gleiche wie eben. Wir müssten hierfür beim Booten das entsprechende Passwort eingeben. Zu dieser Zeit haben wir bei einem Remote-System jedoch noch garkeinen Zugriff. Wir müssen den Server also mindestens dahin kriegen, dass der SSH-Server läuft. Erst dort können wir aufsetzen und alles weitere manuell starten. Leider.

Ich hoffe, die Informationen helfen dem einen oder anderen sein lokales oder sein Remote-System ein bisschen sicherer zu machen.

Und wie immer gilt: Ich hafte nicht für Schäden an Software, Hardware oder für Vermögensschäden, die durch Anwendung dieser Änderungen entstanden sind oder entstehen könnten.

Remote-Verschlüsselte Grüße, Kenny

WeizenSpr.eu - das ist ein Blog, der seit dem Februar 2009 existiert. Das ist ein Blog, der mich bereits durch mehrere Etappen meines Lebens begleitet hat. Das ist ein Blog, der schon mehrmals auf neue technische Füße gestellt wurde. Das ist ein Blog, in dem ich Projekte, Gedanken, Privates und Belangloses veröffentlicht habe. Aber vor allem ist es ein Blog, der sich verändert hat.

Früher habe ich hier wirklich alles mögliche veröffentlicht - inklusivem vielem Kleinkram und einigen Belanglosigkeiten. Heutzutage gibt es dafür Twitter. Zugegeben, einige Dinge wurden einfach nur verfasst, um überhaupt einen Artikel zu veröffentlichen. Von dieser Praxis habe ich in den letzten Jahren immer weiter Abstand genommen und ich denke, dass es der inhaltlichen Qualität des Blogs gut getan hat - auch, wenn die Quantität der Artikel dabei stark nachgelassen hat.

Diesen Weg möchte ich gerne weitergehen. Aktuelle Nachrichten wird es geben, wenn ich der Meinung bin, dass ich der Diskussion eine neue Sichtweise hinzufügen kann. Konzentrieren möchte ich mich jedoch auf Technisches und auf eigene Ideen - aber auch private Artikel sollen weiterhin vorkommen. So will ich z.B. im Herbst wieder anfangen zu studieren. Das Informationsmaterial der entsprechenden Uni sind bereits angekommen.
Um den Blog in diese neue Richtung zu bringen, habe ich in den letzten Tagen einen Haufen alter Artikel offline genommen. Es ist durchaus möglich, dass dadurch einige Verlinkungen zu Bruch gegangen sind. Diese werde ich im nächsten Schritt herausfiltern und dann entsprechend korrigieren.

Na dann... auf die nächsten 3 Jahre.

Strukturierte Grüße, Kenny

Dies ist ein honorierter Werbeartikel.

Wie oft kommt es vor, dass man für jemanden ein wirklich originelles Geschenk sucht aber beim besten Willen keines findet? Bei einigen Leuten ist es ziemlich einfach - sie freuen sich über die neusten Technik-Gadgets oder haben sogar explizite Wünsche. Es gibt jedoch auch Leute, für die es wirklich schwer ist, ein passendes Geschenk zu finden.

Eine interessante Idee ist da in meinen Augen das Angebot von Historische-Zeitungen-bestellen.de. Wie der Name schon verrät, kann man dort historische Zeitungen - geordnet nach dem Erscheinungsdatum - bestellen. Derzeit existiert laut deren Webseite ein Archiv aus 5 Millionen Zeitungen. Alle angebotenen Zeitungen sind echte Originale und haben teilweise bereits einhundert Jahre und mehr auf dem Buckel!
Sämtliche Zeitungen werden vor dem Versand auf Mängel geprüft. Zu jeder Zeitung erhält man zudem eine Geschenkmappe und ein Echtheitszertifikat - dadurch wird das Geschenk meiner Meinung nach gut abgerundet und wird so zu einem echten Vorzeigeobjekt. Der verlangte Preis ist - nach Onlinesichtung - marktüblich. Man muss schließlich bedenken, dass hier eine ganze Menge an Zeitungen über Jahrzehnte hinweg aufbewahrt werden mussten.

Auch zur Bereicherung des Geschichtsunterrichts könnte ich mir die historischen Zeitungen gut vorstellen. Es ließe sich so zum Beispiel gut klären, was die deutsche Bevölkerung denn in den Kriegsjahren in der Zeitung zu lesen bekam. Aber das ist nur ein Beispiel.

Neben den historischen Zeitungen gibt es auch weitere, individuelle Geschenke wie zum Beispiel Jahrgangschronik-Bücher mit den wichtigsten Informationen rund um das jeweilige Jahr, Jahrgangsmusik-CDs mit den Originalsongs, die im jeweiligen Jahr gespielt wurden, Jahrgangschronik-DVDs mit Filmausschnitten der bewegendsten Momente des Jahres und sogar Jahrgangs-Cognacs, der im jeweiligen Jahr hergestellt worden ist! Die meisten der Geschenke kann man darüber hinaus mit individuellen Gravuren noch weiter personalisieren.

Die Webseite selbst ist übersichtlich gestaltet, sodass auch unbedarfte Nutzer schnell das individuelle Geschenk zusammenstellen können sollten, das sie suchen. In meinen Augen ein großer Pluspunkt für den Shop ist, dass es sich um einen Trusted Shop handelt. Dadurch hat man die Gewissheit, bei Problemen den bekannten Trusted Shops Käuferschutz in Anspruch nehmen zu können. Ebenso positiv fällt auf, dass der Support über eine reguläre Festnetznummer erreichbar ist.

Wie anspruchsvoll der Beschenkte aus sein möge, die Geschenke von Historische-Zeitungen-bestellen.de sind sicherlich eine Überraschung wert. Wann bekommt man schon mal eine Zeitung oder gar keinen Cognac aus dem Jahr seiner Geburt geschenkt? Als Tipp: Mit dem Gutscheincode ba2012hzb erhält man derzeit noch einmal einen Rabatt von 5% auf seine Bestellung.

Ich wünsche euch viel Spaß beim Entdecken des Angebotes.

Historische Grüße, Kenny

Blog-Marketing ad by hallimash

Derzeit tobt innerhalb der Piratenpartei ein Streit darüber, wie man zukünftig mit dem Tool Liquid Feedback weitermachen will. Es herrscht (zumindest im Berliner Landesverband) Konsens darüber, dass man über das Tool langfristig Impulse an die Politiker in den BVVen und im AGH geben will. Nicht klar ist bisher jedoch, ob das mit dem derzeitigen Tool möglich ist.

Genauer gesagt ist derzeit nicht geklärt, ob man dies mit den derzeitig verwendeten Pseudonymen erlauben kann, oder ob man sich mit seinem bürgerlichen Namen online - und damit weltweit - zu sämtlichen politischen Themen outen muss, um überhaupt an der innerparteilichen Willensbildung teilhaben zu dürfen.
Von Pro-Klarnamen-Piraten wird dabei meist auf den überlangen Blogeintrag von @Loreena1968 verwiesen. Meine Antwort darauf: TL;DR.

Irgendwann wurde mir dieser Text einfach zu seicht, zu blauäugig, zu... unüberlegt. Kurz zusammengefasst: Man muss unbedingt mit bürgerlichem Namen auftreten, denn ansonsten kann "man" nicht nachvollziehen, ob eine Abstimmung korrekt abgelaufen ist. Dabei geht es explizit um die Punkte

• zu erkennen, dass der Teilnehmer einer reale Person zuzuordnen ist
• zu erkennen, dass der Teilnehmer nur einen Account besitzt
• den Vorwurf von Manipulationen entkräften bzw. klären zu können.

Das Allheilmittel soll es nun sein, Klarnamen zu verwenden, die auf Akkreditierungs-/Vorstellungs-/Whatever-Treffen überprüft und (möglichst) publik gemacht werden. Alles was danach passiert oder passieren kann, wird leider nicht erklärt. Aus gutem Grund: Die Verwendug von Klarnamen, wie sie dort beschrieben wird, ist überhaupt keine Lösung für die angesprochenen Probleme.

Es wird immer gesagt, dass man mit Technik keine sozialen Probleme lösen könne. Hier wird im Umkehrweg versucht, ein technisches Problem mit einer sozialen Lösung zu beseitigen - ebenso erfolglos. Kleines Quiz:

Was passiert denn, wenn man eine "Akkreditierungsrunde" im kleinen Kreis machen muss? Wer garantiert, dass es legitim gewesen ist? Hier ist die Antwort: niemand!

Wer garantiert, dass keine nicht existierende Person eingeschmuggelt worden ist? Hier ist die Antwort: niemand!

Wer überprüft denn anhand der Aufzeichnungen zu allen gemachten "Akkreditierungsrunden", dass eine Abstimmung wirklich ohne Beanstandungen abgelaufen ist? Hier ist die Antwort: niemand!

Man kann diese Probleme nicht durch persönliches Kennen der Teilnehmer lösen. Selbst wenn man sämtliche Teilnehmer kennen würde, wer stellt dann sicher, dass wirklich diese Person abgestimmt hat und nicht irgendjemand den Abstimmungseintrag dieser real existierenden, akkreditierten Person einfach in die Abstimmungsdatenbank geschleust hat? Hier ist die Antwort: niemand!

Jetzt, wo wir hoffentlich verstanden haben, dass die Verwendung von Klarnamen überhaupt keinen Mehrwert für die Aussagekraft der übertragenen Bits & Bytes hat, möchte ich aufzeigen, wie eine Lösung aussehen könnte.

Fangen wir mit den nicht-technischen Basics an: Woher weiß man, dass eine Person stimmberechtigt ist? Durch die Mitgliederdatenbank. Das ist der zentrale Punkt. Wer dort drin steht (und ein Flag hat, dass sein Beitrag entrichtet wurde) darf auch wählen. Diese Rolle (stimmberechtigtes Mitglied) wird bei der Akkreditierung bei einer Versammlung mit einer realen Person verknüpft. Diese reale Person erhält dann die Abstimmunterlagen. Ob sie selber die Karten hebt und selber die Kreuzchen macht wird anschließend nie wieder geprüft.

Es wäre also sinnvoll, die Verwendung von Liquid Feedback ebenfalls an eine Akkreditierung zu koppeln. Die Frage ist leiglich: Wie sehen die Abstimmunterlagen aus? Bei Computern würde ein asymmetrisches Schlüsselpaar sinnvoll sein. Damit könnte dann der akkreditierte Pirat seine virtuellen Stimmzettel signieren, nachdem er sie ausgefüllt hat.

Diese Abstimmunterlagen sollten natürlich immer nur bis zum Ende des Jahres gültig sein - so könnte man nicht mehr gültige Stimmunterlagen automatisch aussieben. Abstimmkarten vom BPT 2010 sind in 2012 schließlich auch nicht mehr gültig.

Ich stelle mir das in etwa so vor: Jemand, der an Liquid Feedback teilnehmen will, generiert sich ein asymmetrisches Schlüsselpaar und geht damit zu einer Akkreditierungsveranstaltung. Auf dieser wird geprüft, ob die Person stimmberechtigtes Mitglied ist. Falls ja, wird der öffentliche Schlüssel dieses Piraten zertifiziert - von mindestens 2 Mitgliedern des entsprechenden Vorstandes.
Dieser zertifizierte Schlüssel wird im Liquid Feedback System hinterlegt. Gleichzeitig wird der Schlüssel auch noch auf einem weiteren System öffentlich zugänglich hinterlegt, auf den die Betreiber von Liquid Feedback keinen Zugriff haben. Und: in der Mitgliederdatenbank wird gespeichert, dass der entsprechende Pirat für das aktuelle Jahr einen Liquid Feedback Schlüssel akkreditiert hat.

Jetzt werde ich ein bisschen orthodox: Bei Abstimmungen ist es mir doch total egal, wieviele Accounts eine Person hat. Das einzige, was mich interessiert ist, dass jede natürliche Person bei einer Abstimmung nur eine Stimme abgeben kann. Genau das wird bei der Akkreditierung sichergestellt. Jemand, der bereits einen zertifizierten Schlüssel hat, darf keinen zweiten zertifizierten Schlüssel für das laufende Jahr erhalten. Hiermit wäre sogar möglich, Abstimmungen ohne Login durchzuführen. Der entsprechende Wähler benötigt einfach nur seine Stimmunterlagen (sein Schlüsselpaar).

Viel wichtiger als ein Account ist, dass die Menge der zugelassenen Schlüssel nicht manipuliert werden kann. Und deshalb ist es wichtig, das Abstimm-/Auswertungstool und die Liste der stimmberechtigten Nutzer (die zertifizierten, öffentlichen Schlüssel) strikt zu trennen. Man bezeichnet dies hinlänglich als Separation of Duties.

Der Vorstand, der sämtliche Schlüssel signieren muss, muss seinen öffentlichen Schlüssel selbstsigniert online stellen. Anschließend kann jeder prüfen, ob alle stimmberechtigten Schlüssel wirklich valide sind. Anhand dieser validen Schlüssel kann wiederum geprüft werden, ob die abgegebene Stimme von einem validen Schlüssel unterzeichnet wurde. Und damit kann sichergestellt werden, dass die Abstimmung nicht manipuliert worden ist.

Wenn man nun die eigentliche Akkreditierung anzweifelt: Man könnte festlegen, dass Akkreditierungen nur an bestimmten Tagen zu bestimmten Uhrzeiten erlaubt sind. Man könnte die Akkreditierung öffentlich machen. Heißt: man kann mitzählen, wieviele neue Schlüssel für den entsprechenden Tag auf dem Schlüsselserver erscheinen müssten. Die Überprüfung der Akkreditierung könnte man nochmal dadurch absichern, dass bei der Akkreditierung des Schlüssels der Hash des Schlüssels bekanntgegeben wird. Ein Akkreditierungsbeobachter könnte nach Veröffentlichung der neuen Schlüssel den Hash kontrollieren um sicherzugehen, dass der Schlüssel nicht zwischendurch ausgetauscht wurde.

Als Abschluss: Nur, weil man Klarnamen im Liquid Feedback hat, heißt das noch lange nicht, dass man die getätigten Stimmen nicht manipulieren kann. Hierfür müsste sichergestellt werden, dass niemand die Datenbasis manipulieren kann. Mit Signaturen wäre man hierzu in der Lage - mit Klarnamen nicht.

Flüssige Grüße, Kenny

Es kommt durchaus mal vor, dass man WordPress auf einem Server einsetzt, der keinen Mailversand über die PHP-Funktion mail() zulässt. In solchen Fällen muss man auf den Mailversand per SMTP zurückgreifen. Leider bietet WordPress nicht die Möglichkeit, die SMTP-Konfiguration direkt vorzunehmen. Das ist sehr schade, denn eigentlich wäre es kein großer Aufwand, dies bereitzustellen. Folgendermaßen muss man vorgehen, um WordPress dazu zu bringen, Mails via SMTP zu verschicken.

Zuerst einmal müsst ihr die SMTP-Konfiguration irgendwo hinterlegen. Ich dazu die wp-config.php ausgewählt, da dort sowieso auch alle anderen, fest verdrahteten Informationen abgelegt sind. Dort habe ich die Funktion smtp_wp_mail() hinterlegt, die wie folgt aussieht:

Wie man sieht, wird hier kein Stückchen Logik benötigt, sondern einfach nur reine Konfigurationseinstellungen. Das hat einen einfachen Grund: WordPress verwendet intern für den Mailversand die Funktion wp_mail(), die wiederum die Klasse PHPMailer kapselt. Oder anders ausgedrückt: Die Funktionalität ist bereits vorhanden, sie müsste nur genutzt werden.

Um das nun auch zu tun, muss noch die Funktion wp_mail(), die sich in der Datei wp-includes/pluggable.php befindet, angepasst werden. In ihr gibt den folgenden Codeblock:

Dieser muss wie folgt abgeändert werden. Dadurch wird das interne Mailobjekt an unsere oben geschriebene Funktion übergeben, dort für den Mailversand per SMTP umkonfiguriert und danach mit dem Mailversand in der Funktion wp_mail() weitergemacht.

Das war es auch schon! Ich weiß, es gibt auch Plugins dafür, wie z.B. WP Mail SMTP oder Configure SMTP aber wenn ich ehrlich sein soll, finde ich diese viel zu überladen für die paar gerade gezeigten Codezeilen.

Update:
Wie Oliver gezeigt hat, kann man sich die Änderung der pluggable.php auch sparen und stattdessen den Hook "phpmailer_init" verwenden. So könnte man z.B. ein Plugin schreiben, das einfach nur folgendes macht:

Mailende Grüße, Kenny