WeizenSpr.eu

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öffentlichten (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 jede Domain eine weitere 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 sollte 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. Dieser neue Nutzer sollte der Account sein, von dem euer Hauptmailserver später die Mails abholen sollte, sobald er 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.

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

Ich bin kein Mensch, der exakt zu Silvester Vorsätze für das neue Jahr nimmt, sondern ich stelle mir selbst Ziele, wenn ich der Meinung bin, dass es nötig wird. Im letzten Jahr war dies im Sommer der Fall, in dem ich entschloss, abzunehmnen. Ich bin nun konstant bei unter 80kg und habe also mein Ziel erreicht.

Der Vorsatz, den ich gestern gefasst habe, wird jedoch leider schwieriger, als “einfach nur” meine Ernährung umzustellen. Natürlich wird es auch Spaß machen, aber in erster Linie wird es Arbeit sein. Meine Idee ist es, ein eigenes Content Management System zu schreiben. Nicht einfach nur ein CMS, sondern eins, dessen Hauptziel die Sicherheit der Anwendung sein soll. Trotzdem soll es ähnlich erweiterbar sein wie WordPress – nur ohne den ganzen Eyecandy-Balast und vor allem mit einer überschaubaren Struktur.

Natürlich könnte man jetzt sagen “Nimm doch CMS XYZ, das IST sicher!” oder “WordPress ist doch sicher genug!”. Leider muss ich bei meinen Recherchen immer wieder feststellen, dass es sich dabei immer nur um gefühlte Sicherheit handelt. Ich habe bisher noch kein CMS gefunden, das ein ausgewiesenes Sicherheitskonzept besitzt. Hier geht es mir garnicht darum, dass diese anhand von Penetrationtests “beweisen”, dass sie sicher sind, sondern darum, dass es eine Sicherheitsideologie bei der Entwicklung gibt.

Diese spreche ich z.B. per se allen Webanwendungen ab, die für die Sicherung der Datenbank ausschließlich Software-side Security einsetzen, sprich: Software, die einen einzigen Datenbanknutzer hat und innerhalb der Software erkennt, zu welcher Zeit welche Befehle ausgeführt werden dürfen. Ich halte diesen Ansatz für “Broken by Design” und werde entsprechend einen anderen Ansatz wählen.

Was ich übernehmen werde, ist das Filtersystem (man kann Code in die Seitengenerierung injizieren), sowie die Möglichkeit (nicht den Zwang), Slugs automatisch generieren zu lassen.

Was mir am schwersten fallen wird? Das wird wohl eindeutig das Eyecandy sein. Ich bin Architekt und Programmierer, kein Designer. Ich hoffe deshalb, dass das CMS zumindest so gut ankommen wird, dass sich ein Freiwilliger findet, der sich um das Aussehen der Anwendung kümmern wird. Das zumindest ist mein großer Wunsch.

Vorsätzliche Grüße, Kenny

Und wieder mal ist ein Jahr vorbei und letzte Artikel des Jahres ist gekommen. Dieses Mal gab es eher weniger Artikel – getreu dem Motto Klasse statt Masse (so zumindest meine Hoffnung). Die Artikel waren dieses Mal eher technisch. Ihr habt gesehen, wie mein neuer Server konfiguriert wird, ihr habt miterlebt, wie ich von Windows+Android Stück für Stück zu Mac OS und dann zu iOS gewechselt bin und es gab hier und da auch mal kleinere Projekte.

Aber aus dem Privaten habt ihr bisschen was gesehen – primär meine Diät (ich bin nun sogar knapp unter meinem Idealgewicht von 80kg angekommen) und meinen Umzug.

Ich hoffe, ihr hattet ein gutes Jahr 2011 und ich wünsche euch, dass das 2012 noch besser sein wird als das vorherige. Allen von euch einen guten Rutsch. Lasst die Sektkorken knallen.

Jahresendgrüße, Kenny

Nachdem ich das Thema nun schon eine ganze Weile vor mir herschiebe, habe ich heute nun doch endlich meinen Nginx-Server für die Verwendung von SSL konfiguriert. Hierbei gibt es mehrere Ansätze. Angefangen bei “je ein Server für HTTP und ein Server für HTTPS” über “ein zentraler HTTPS-Server” bis hin zu Mischmaschlösungen ist alles dabei.
Da bei mir die möglichst einfache Wiederverwendung der einzelnen Konfigurationsteile an erster Stelle steht, wollte ich euch einmal zeigen, wie ich das ganze nun gelöst habe.

Fangen wir nochmal vorne an: In meiner Konfiguration gibt es eine zentrale Konfigurationsdatei, die einen HTTP-Block enthält. Für jede Domain gibt es dann eine separate Konfigurationsdatei, in der die Domain-spezifischen Konfigurationen enthalten sind (Redirects, optional PHP, etc.).

Zuerst einmal habe ich den Großteil der Konfiguration in die zentrale Konfigurationsdatei “/etc/nginx/nginx.conf” ausgelagert. In den dort enthaltenen HTTP-Block habe ich folgende Zeilen eingefügt:

Hier konfigurieren wir, wo sich das SSL-Zertifikat und der private SSL-Schlüssel befinden. Wir geben an, welche SSL-Cipher (dazu gleich mehr) verwendet werden, welches SSL-Protokoll verwendet werden soll und wie groß der SSL-Session-Cache sein soll.

Kommen wir erst einmal zum Zertifikat. Genauso wie früher möchte ich mehrere Domains unter einer einzigen IP-Adresse hosten. Um für alle Domains SSL anbieten zu können, benötige ich ein Zertifikat, das mehrere Domain-Namen enthält. Wie das ganze grob funktioniert, hatte ich schon einmal beschrieben.

Kommen wir nun zu den SSL-Ciphern. Im Grunde besteht SSL aus einer Sammlung von Verschlüsselungs- und Hashing-Algorithmen, die jeweils einen Cipher ausmachen. Es gibt starke Cipher mit starken Algorithmen, aber auch schwache Cipher mit schwachen Algorithmen. Es gibt sogar Cipher komplett ohne Verschlüsselung oder auch welche ohne Authentisierung. Der genutzte Cipher-String sieht im ersten Moment möglicherweise etwas kompliziert aus, ist aber im Grunde halb so wild:
Da ich mich auf die Verwendung von SSLv3 beschränke, reduziere ich die verfügbaren Cipher auf starke SSLv3-Cipher. Zusätzlich werden (für alte Windows-Versionen) mittelstarke RC4-Cipher hinzugefügt. Abschließend werden Cipher mit MD5, Cipher mit 3DES und Cipher ohne Authentifizierung und ohne Verschlüsselung aus der Liste entfernt und die Liste anhand der Stärke der übrig gebliebenen Cipher sortiert. Dieser Blogeintrag hat mir sehr beim Verstehen des Cipher-Strings geholfen.

Nachdem nun also alles wichtige vorbereitet ist, gibt es in den einzelnen Domain-spezifischen Konfigurationsdateien nur noch eine Sache zu tun: Es muss angegeben werden, dass der Server für die entsprechende Domain mit SSL auf Port 443 horchen soll. Hierzu muss im entsprechenden SERVER-Block folgende Zeile ergänzt werden:

Voila! Wir haben SSL für alle Domains vorbereitet und können es nach Belieben für einzelne SERVER-Blöcke einschalten.

Verschlüsselte Grüße, Kenny

P.S.: Eine interessante Information, die ich nebenbei bei meiner Recherche gefunden habe: Mit folgendem Befehl kann man SSL-verschlüsselte Verbindungen aufbauen und testen (also so wie Telnet nur eben per SSL):