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

Dank der Bounce-Messages von lernresistenten Mailprovidern wie Yahoo und Hotmail (= Microsoft) habe ich mitbekommen, dass mal wieder irgendein Spaßvogel Spam-Nachrichten versendet und die Absenderadresse fälscht, sodass es aussieht, als ob die Mails von der Domain WeizenSpr.eu versendet werden würden. Für die Leute, die sich mit der Materie nicht so auskennen: Diese Nachrichten stammen nicht von mir. Es ist mir zudem nicht möglich, Personen daran zu hindern, Mails mit falschem Absender zu verschicken.

Um einen Vergleich zur Offline-Welt zu ziehen: Es ist auch im realen Leben jedem problemlos möglich, einen Brief zu schreiben und darin anzugeben, der Brief würde von Yahoo, Microsoft, Google oder sonstwem kommen. Selbst diese großen Firmen können nicht verhindern, dass jemand solche gefälschten Briefe schreibt. Genau das gleiche gilt für E-Mails.

Dieses Problem hatte ich Ende 2010 schon einmal und verwende seitdem SPF-Records für die von mir betreuten Domains. Diejenigen Leute, die also trotzdem Spammails von der Domain WeizenSpr.eu zu sehen bekommen haben, sollten sich freundlich an ihren eigenen Mailprovider wenden und diesen Fragen, weshalb er keine SPF-Records zur Spambekämpfung auswertet.

Genervte Grüße, Kenny

Wie ihr letztens wahrscheinlich gelesen habt, hat sich ein Amtsrichter aus Reutlingen dazu entschieden, in einem Einbruchsfall den Facebook-Account eines Angeklagten zu beschlagnahmen. Die Idee: Der Angeklagte soll dem Einbrecher via Facebook einen Tipp gegeben haben, wie dieser am besten einbrechen könne. Mit Hilfe der Beschlagnahmung versucht das Gericht nun, an die privaten Facebook-Nachrichten des Angeklagten zu kommen - soweit so unglaublich Übelkeit erregend.

Aber was würde es denn bedeuten, wenn das Gericht hier tatsächlich Einblick in die privaten Nachrichten erhalten würde? Im ersten Schritt würde das bedeuten, dass private Nachrichten bei Facebook nicht dem gleichen Schutz unterliegen, wie private Briefe. Es würde aber auch bedeuten, dass zukünftig wegen jeder Bagatelle die intimsten Nachrichten Gegenstand eines Prozesses werden könnten.

Um dem ein bisschen entgegen zu wirken, wäre es sinnvoll, über Facebook versendete Nachrichten einfach verschlüsseln zu können, sodass nur der tatsächliche Empfänger sie lesen kann. Leider ist soetwas oft sehr umständlich. Entweder man verwendet einen separaten Client, der diese Funktionalität anbietet, oder aber man muss immer ein Verschlüsselungsprogramm laufen lassen, in das man die Texte rein- und wieder rauskopiert.

Aus diesem Grund habe ich mich mal an einem Proof-of-Concept versucht: fbPGP - Facebook with GnuPG. Dort habe ich ein Greasemonkey-Script geschrieben, das sich in die Nachrichtenseite von Facebook einklinkt. Durch dieses wird die Facebook-Nachrichten-Seite um das ver- und entschlüsseln von versendeten/empfangenen Nachrichten erweitert.

Verschlüsselte Nachricht in Facebook

Das ganze funktioniert wie folgt: Man hat einen Server (z.B. lokal), auf dem zwei kleine PHP-Scripte bereitstehen. Auf diesem Server ist zudem GnuPG installiert. Wenn man auf der Facebook-Nachrichten-Seite einen Text abschickt, wird dieser an eines der PHP-Scripte übergeben, von diesem verschlüsselt und die verschlüsselte Version an die Facebook-Nachrichten-Seite zurückgegeben. Diese sendet diese dann an den Empfänger.
Wenn man sich eine empfangene Nachricht ansieht, wird diese genommen, an das andere PHP-Script übergeben, von diesem wieder entschlüsselt und dann auf der Facebook-Nachrichten-Seite zur Anzeige gebracht.

Entschlüsselte Nachricht in Facebook

Die Besonderheit an der verwendeten Verschlüsselung ist, dass der Schlüsselaustausch problemlos möglich ist. Das kann man sich wie einen Briefkasten vorstellen: Jeder hat Zugang zu dem Briefkasten und kann dort eine Nachricht einwerfen, aber nur der Briefkastenbesitzer kann diesen öffnen und die Nachrichten lesen.
Genauso verhält es sich bei GnuPG. Es gibt dort zwei "Passwörter" (Schlüssel genannt) - ein öffentliches und ein privates. Das öffentliche kann man (wenn man will) auf Plakate drucken und überall aufhängen, jedem per E-Mail schicken, auf seiner Webseite präsentieren und soweiter. Dieses öffentliche "Passwort" wird zum Verschlüsseln von Nachrichten verwendet (= das Einwerfen der Nachricht in den Briefkasten). Das private "Passwort" hingegen ist geheim - es darf an niemanden weitergegeben werden. Jeder, der das private "Passwort" kennt, kann die empfangenen Nachrichten entschlüsseln.

Die Idee ist nun, dass dem PHP-Script, das die Verschlüsselung vornimmt, sämtliche öffentlichen Schlüssel der angeschriebenen Facebook-Kontakte bekannt sind. Praktisch wäre hier natürlich, wenn es sich diese automatisch irgendwoher besorgen könnte. Das ist jedoch noch nicht implementiert.
Das PHP-Script, das die Verschlüsselung vornimmt, muss natürlich den eigenen privaten Schlüssel kennen. Deshalb ist es sinnvoll, dieses Script lokal auf dem eigenen Rechner zu verwenden. Zudem ist es sinnvoll, den privaten Schlüssel noch einmal mit einem Passwort zu versehen.

Warum erzähle ich euch das alles? Ich denke, dass langsam aber sicher etwas getan werden muss. Überall versuchen die Regierungen dieser Welt, immer weiter in den privaten Lebensraum vorzudringen. Das beginnt beim richterlichen Eingriff in die private Kommunikation und hört beim Infizieren von privaten Rechnern mit Schadsoftware durch Bundesbehörden noch lange nicht auf.
Ich denke, dass es notwendig ist, dem normalen Internetnutzer Tools an die Hand zu geben, mit denen er sich ohne viel Aufwand vor solchen Eingriffen schützen kann. Und damit meine ich nicht den e-Postbrief oder DE-Mail, die zwar angeblich "sicher" sind, jedoch genau an ihren Übergangspunkten problemlos mitgelesen werden können. Wie man an der krampfhaften Erklärung oben sieht, ist das jedoch nicht so einfach. Klar: Für mich ist es kein großes Problem, einen Webserver mit PHP einzurichten, GnuPG zu installieren und 2 PHP-Scripte darüber laufen zu lassen. Für andere ist das jedoch unverständliches Hexenwerk. Auch diese Leuten muss man mit einfach nutzbaren, sicheren Lösungen in der heutigen, digitalen Welt unterstützen. In meinen Augen ist es deshalb auch sehr wichtig, dass sich diese Lösungen möglichst nahtlos in die vertraute Umgebung einbetten.

Ich hoffe, es finden sich Leute, die sich dieses Themas annehmen.

Verschlüsselnde Grüße, Kenny

P.S.: Hier als Backup noch einmal die einzelnen Quelltexte.

fbPGP.user.js:

encrypt.php:

decrypt.php:

Manchmal ist die Verwendung einer chroot-Umgebung für PHP mehr Fluch als Segen. Auf der einen Seite ist es ein wirklicher Sicherheitsgewinn. Aber auf der anderen Seite findet man immer wieder Kleinigkeiten, die einen eine ganze Weile aufhalten, bevor man bestimmte Funktionen nutzen kann.

Ein Beispiel hierfür ist die exec() Funktion, die es ermöglicht, Systembefehle auszuführen und deren Ergebnis auszulesen. Es ist nirgendwo richtig dokumentiert, aber damit sie funktioniert, muss die Binärdatei "/bin/sh" in der chroot-Umgebung zur Verfügung stehen.

Anschließend kann man per

prüfen, welche Bibliotheken mit welchen Pfaden zusätzlich noch bereitgestellt werden müssen.

Gechrootete Grüße, Kenny

Eine der wichtigsten Dienste für eine Domain (neben HTTP) ist wahrscheinlich SMTP - also die Möglichkeit, E-Mails senden und empfangen zu können. Der Verlust von neuen Nachrichten ist wahrscheinlich eine der größten Gefahren, denen ein privater Server ausgesetzt ist. Gehackte Server kann man löschen und neu aufsetzen, gelöschte Webseiten und Datenbanken kann man aus Backups wiederherstellen. Aber Mails wieder zu bekommen, die aufgrund eines Fehlers garnicht oder nur fehlerhaft empfangen werden konnten, ist nicht möglich.

Deshalb sollte man sich, wenn man seine Domains ernsthaft betreiben will, irgendwann einmal Gedanken darüber machen, wie man den Verlust von Mails (z.B. aufgrund eines Serverausfalls) verhindern will. Auch ich habe diese Überlegungen hinter mir. Da gibt es einiges zu beachten. So sollte der Backupserver nicht beim gleichen Hoster stehen - für den Fall, dass dieser insgesamt Probleme hat (bezeichnet man als Geo-Redundanz), der Backupserver sollte eine hohe Verfügbarkeit aufweisen, gleichzeitig sollte er jedoch (zumindest für den privaten Bereich) nicht zu teuer sein, da es ja eben doch nur ein Backupserver ist.
Auch, wenn man endlich mal einen passenden Anbieter für den Backupserver gefunden hat, ist es garnicht so einfach, diesen zu betreiben. Viel zu leicht gerät man in die Versuchung, den "ungenutzten" Rechner irgendwie zu nutzen. Deswegen bin auch ich irgendwann wieder dazu übergegangen den eigentlich Backupserver auch wieder für andere Dinge zu nutzen...

...bis ich endlich eine Alternative gefunden hatte: Google Apps!

Google Apps muss man sich als Cloud-Lösung für Unternehmen vorstellen. Dort sind viele Google-Dienste gesammelt, die für Nutzer eines Unternehmens vorkonfiguriert zur Verfügung gestellt werden können. Dazu gehört auch das Anbieten von Gmail für eine eigene Domain. Sprich: Man nutzt Gmail zum Versenden und Empfangen von Mails, verwendet jedoch Adressen in der Form von xyz@example.com.
Google bietet hier also direkt eine Möglichkeit, als Mailserver (und mehr) zu fungieren. Dabei bieten sie ingesamt 5 verschiedene MX-Server an, die sich um den Empfang von E-Mails kümmern können.

Da ich diesen Service sicherlich noch öfter nutzen werde, habe ich mir gedacht, ich dokumentiere, wie ich vorgegangen bin. So habe ich später eine einheitliche Konfiguration und andere können dieses Wissen evtl. auch gebrauchen.

Als erstes muss man natürlich einen Account anlegen. Dazu geht man auf die Seite von Google Apps. Neben der kostenpflichtigen Variante für Unternehmen gibt es auch eine kostenlose Variante für Gruppen.
Man gibt als erstes seine Domain ein; dann ein paar persönliche Daten; die Daten des administrativen Nutzers (hier solltet ihr einen Namen nehmen, der nicht im öffentlichen Schriftverkehr genutzt wird - warum erkläre ich später); deaktiviert das automatische Bereitstellen von neuen Diensten und ist mit der Registrierung auch schon fertig.

Google Apps Registrierung

Als nächstes prüft Google, ob man wirklich Besitzer der angegebenen Domain ist. Es gibt mehrere Möglichkeiten, wobei die Prüfung per DNS-Eintrag wahrscheinlich das einfachste sein dürfte. Und da ihr sowieso schon dabei seid, eure DNS-Einträge zu verwalten, könnt ihr auch gleich, die MX-Einträge zur Verwendung der Google-Server eintragen:

Falls ihr diese Prüfung hinter euch habt, könnt ihr euch das erste mal mit dem Administratoraccount einloggen. Ihr werdet direkt mit einem Setup-Assistenten begrüßt. Klickt diesen einfach mal durch. Wirklich wichtig ist er nicht. Anschließend solltet ihr schonmal auf den Reiter "Einstellungen" gehen und dort die nicht benötigten Dienste deinstallieren oder zumindest deaktivieren. Das sind primär "Chat", "Google Docs", "Kalender", "Kontakte", "Mobil" (kann man nur deaktivieren aber nicht deinstallieren) und "Sites".

Google Apps Einstellungen

Damit habt ihr die bereitstehenden Dienste schon einmal stark reduziert. Als nächstes solltet ihr nun ein paar "Domain-Einstellungen" vornehmen. Die wichtigsten sind das Aktivieren von SSL und das Deaktivieren von geplanten Veröffentlichungen (sprich dem Hinzufügen von neuen Diensten). Nachdem ihr die Änderungen gespeichert habt, solltet ihr in den "Domain-Einstellungen" den Unterreiter "Domain-Namen" aufsuchen. Es wird nämlich standardmäßig für jeden Account eine Testdomain eingerichtet, die auf ".test-google-a.com" endet. Diesen sogenannten Testalias solltet ihr deaktivieren. Er wird später nicht mehr benötigt.

Google Apps Domain-Einstellungen

Als nächstes solltet ihr einen weiteren Nutzer anlegen. Dieser Nutzer wird später derjenige sein, der sämtliche E-Mails empfängt (also als "Catchall" dient). Deswegen war es auch so wichtig, dem Administratoraccount einen Namen zu geben, der im öffentlichen Schriftverkehr nicht genutzt wird - denn alle Mails, die an den Admin-Account gehen, müssen separat abgerufen werden. Sinn ist es aber, dass möglichst alle Mails an die Catchall-Adresse geschickt werden. Man könnte natürlich auch den Admin-Account als Catchall-Adresse nutzen, aber dann müsstet ihr die Zugangsdaten zu eurem Admin-Account in einem Script hinterlegen (= nicht gut) Deshalb sollte der neue Nutzer der Account sein, von dem euer Hauptmailserver später die Mails abholt, sobald dieser wieder läuft. (Wie man soetwas einrichten kann, erkläre ich, wenn ich es selbst umgesetzt habe. )
Geht dazu auf "Organisation und Nutzer" und legt in der Maske den neuen Nutzer an. Merkt euch die E-Mail-Adresse, die ihr diesem Nutzer gebt, ihr werdet sie noch brauchen. Nachdem ihr den neuen Nutzer angelegt habt, könnt ihr alle weiteren Services deaktivieren. Dazu geht ihr auf den Unterreiter "Services", klickt bei "Weitere Services" auf "Aus" und speichert anschließend die gemachten Änderungen.

Google Apps Nutzer und Services

Als finalen Schritt müsst nun noch einmal zu den "Einstellungen" gehen und bei "E-Mail" für die "Auffangadresse" die Einstellung "E-Mail weiterleiten an:" aktivieren und dort die E-Mail-Adresse eures neu angelegten Nutzers eintragen. Nach dem Speichern der Änderung seid ihr fertig!

Google Apps E-Mail Auffangadresse

Unglaublich! Ihr habt in den letzten paar Minuten einen Google Apps Account für eure Domain angelegt; eure DNS-Einträge geändert, damit Google als euer Mailserver dient und habt Google Apps so konfiguriert, dass es alle E-Mails für eure Domain annehmen kann.

Die Daten, die ihr benötigt, um Mails über Google zu verschicken und die Mails von Google abzurufen, sind in diesem Google Support-Artikelbeschrieben. Darüber hinaus bietet Google für einige Mailclients umfassende Konfigurationsanleitungen an.

Ich hoffe, der Artikel war interessant für euch und ich würde mich natürlich - wie immer - über Anregungen, Kritik und allgemeines Feedback freuen.

Update:
Bevor ich es vergesse und jemand in diese Falle läuft. Ja, Google Apps ermöglicht es, mehrere Domains mit einem Google Apps Account zu verbinden. Hier ist jedoch Vorsicht geboten, denn für keine der zusätzlichen Domains ist es möglich, eine Catchall-Adresse einzurichten, wie es in diesem Artikel beschrieben worden ist. Das bedeutet: Für jede Domain muss man einen neuen Google Apps Account erstellen - ein Kombinieren ist nicht möglich.

Update:
Den Absatz über den neuen Nutzer nochmal umgeschrieben und genauer erklärt, weshalb ein zusätzlicher Nutzer eingerichtet werden sollte.

Update:
Nochmal als eigene Antwort auf das erste Update. Es ist in der Tat möglich, durch das Einrichten eines "Domain-Alias" mehrere Domains über ein und denselben Google Apps Account abzudecken. Das funktioniert auch mit der eingerichteten Catchall-Adresse. Worauf man unbedingt achten muss (was ich damals anscheinend nicht getan habe), ist, dass Google wohl Probleme mit diesem Domain-Gerödel hat. Nach dem Hinzufügen des Domain-Aliases (und dem Verifizieren) muss dieser in der Domain-Übersicht sofort aktiv sein. Wenn dort ein gelbes Ausrufzeichen in der Liste steht, ist irgendwas schief gelaufen und der Domain-Alias funktioniert nicht. Einzige mir bekannte Lösung: Domain-Alias löschen und neu hinzufügen. Irgendwann sollte es klappen.

Mailende Grüße, Kenny

Ich habe diese Woche damit verbracht, mir einen Überblick darüber zu verschaffen, was das zukünftige Content Management System später leisten soll und worauf besonders Wert gelegt werden soll. Kurz um: Ich habe eine Feature-Liste erarbeitet. Auf Basis dieser Feature-Liste sollen das technische Feinkonzept und das Sicherheitskonzept entstehen. Beides werde ich in einem großen, umfassenden Dokument beschreiben. (Ja, normalerweise kommt erst ein Lastenheft, dann ein Pflichtenheft, dann ein technisches Grobkonzept, dann ein technisches Feinkonzept und abschließend ein Sicherheitskonzept. Da ich jedoch mein eigener Kunde bin, komme ich gleich zum Knackpunkt.)

Einen Namen für das CMS habe ich nun übrigens auch gefunden. Eigentlich hatte ich ja "SecWCMS" im Kopf, aber ehrlich gesagt fand ich den Namen schlussendlich doch doof. Ich habe mich deshalb für den Namen Brooke.cc entschieden. Brooke ist ein meist weiblicher Vorname, heißt so viel wie Fluss oder Bach und soll den Informationsfluss, der durch ein CMS entsteht, symbolisieren. Außerdem erinnert mich das Wort sehr an "book" (dt. "Buch"), zudem beginnt es mit "br", dem HTML-Tag für Zeilenumbrüche. Das ".cc" der Domain habe ich übrigens mit in den Namen aufgenommen. "CC" steht bei E-Mails ja angeblich für "Carbon Copy". Meiner Meinung nach irgendwie passend für ein OpenSource-Projekt.

Hier also die von mir zusammengestellten Anforderungen:

• Umfassende Konzeption inkl. Sicherheitsbetrachtung
• die Rollen Administrator, Moderator, Autor und Besucher sollen strikt getrennt werden
• Sämtliche Eingaben sollen geprüft und escaped werden
• URLs zu den Inhalten sollen frei bestimmbar, aber auch aus Platzhaltern generierbar sein
• Inhalte sollen in (verschachtelbaren) Gruppen/Kategorien angeordnet werden können
• es soll Übersichtsseiten über Gruppen/Kategorien geben
• für Gruppen/Kategorien soll es Feeds (RSS oder Atom) geben
• Inhalte sollen als Textbausteine in anderen Bereichen einer Seite einsetzbar sein
• alle Aktionen von Administratoren, Moderatoren und Autoren sollen aufgezeichnet werden
• für Besucher soll eine Statistik erzeugt werden, die ohne Speicherung der IP des Besuchers auskommt (abschaltbare)
• alle Bereiche sollen HTTPS unterstützen, für die Bereiche der Administratoren, Moderatoren und Autoren soll HTTPS erzwungen werden können (abschaltbar)
• die Seite soll sich nicht in Frames einsperren lassen dürfen (abschaltbar)
• Besucher sollen keine Session benötigen; Cookies sollen nur gesetzt werden, wenn unbedingt nötig
• Inhalte sollen kommentierbar sein, dies soll für jeden Inhalt separat abschaltbar sein
• Inhalte einer Gruppe/Kategorie sollen als besonders wichtig markierbar sein; diese sollen in der Auflistung ganz oben stehen
• Administratoren sollen keinen Zugriff auf das Erstellen, Veröffentlichen oder Freigeben von Inhalten haben; Autoren sollen Inhalte erstellen aber nicht veröffentlichen können; Moderatoren Inhalte erstellen, veröffentlichen und Kommentare freigeben können
• Kommentare sollen vor Spam geschützt werden (abschaltbar)
• Kommentare sollen vor der Veröffentlichung in eine Moderationsliste gestellt werden (abschaltbar)
• Kommentare bestimmer Kommentatoren sollen immer automatisch veröffentlicht werden, wenn die Moderationsliste aktiviert ist
• in Kommentaren soll BB-Code verwendbar sein
• in Inhalten von Besuchern darf kein JavaScript vorhanden sein
• Inhalte sollen depublizierbar sein
• Inhalte sollen (optionale) von- und bis-Werte haben, die die Sichtbarkeit des Inhalts zeitlich einschränken; diese sollen auch wirken, wenn die Inhalte an anderer Stelle genutzt werden
• Inhalte sollen Funktionen zum Darstellen von Bildern und Quelltext, sowie dem Hervorheben von Links erhalten
• in Bearbeitung befindliche Inhalte sollen regelmäßig gesichert werden
• veröffentlichte Inhalte, die anschließend von ihrem Autoren verändert werden, müssen erneut veröffentlicht werden, damit die Änderung aktiv wird
• es soll einstellbar sein, ob ein Autor die Inhalte anderer Autoren lesen oder sogar bearbeiten darf
• Inhalte sollen über eine Suchfunktion auffindbar sein
• es soll eine sitemap.xml bereitgestellt werden
• Suchmaschinen sollen über neue Inhalte informiert werden
• es sollen Trackbacks unterstützt werden
• es sollen Pingbacks unterstützt werden
• die Anwendung soll keine E-Mails versenden
• Passwörter sollen sicher abgelegt werden
• die Darstellung soll auf Templates basieren
• es soll dynamisch zwischen verschiedenen Designs umschaltbar sein (z.B. ein Desktop- und Mobil-Design)
• der Upload und das Löschen von Dateien soll möglich sein; hochgeladene Bilder sollen skaliert werden
• Nutzer sollen bei mehrmaligen (einstellbar) fehlerhaften Login-Versuchen für eine definierbare Zeit ausgesperrt werden
• bei einem fehlgeschlagenen Loginversuch soll nicht ersichtlich sein, weshalb dieser fehlgeschlagen ist
• es sollen Passwortrichtlinien aktivierbar sein
• Nutzer sollen nach einer einstellbaren Zeit automatisch ausgeloggt werden
• es soll eine Funktion zum Suchen ähnlicher Inhalte bereitgestellt werden
• die Software muss Mehrsprachigkeit unterstützen
• die Software soll um neue Funktionen erweiterbar sein
• die Ausgabe soll durch Plugins veränderbar sein
• die Software soll in PHP geschrieben sein
• die Software soll MySQL verwenden
• der DB-Zugriff soll keine Transaktionen benötigen
• es soll eine umfassende Installationsanleitung erstellt werden

So, das ist doch mal eine ganz annehmbare Liste für ein kleines CMS. Sollten euch noch weitere Funktionen einfallen, die ein CMS unbedingt benötigt, dann hinterlasst diese doch bitte in den Kommentaren.

Managende Grüße, Brooke Kenny