Am vergangen Freitag konnte ich nach knapp 3 Monaten Wartezeit mein Galaxy S2 aus der Packstation abholen. Erst etwas erstaunt, das das Amazonpaket so klein ist, zeigte sich nach dem entpacken dann eine nochmals deutlich kleinere Schachtel die das Handy beinhalten sollte. Das Handy war natürlich enthalten, doch hätte man eine deutlich imposantere Schachtel bei einem derartigen (teuren) Gerät erwarten können. Aber die Umwelt dankt es Samsung sicher.

Hier mal ein paar Bilder, aufgenommen noch mit meinem Übergangshandy, einem Nokia 6303i, dazu aber später noch mehr.

Nach dem Auspacken und den ersten Gehversuchen mit dem mir bis dahin noch unbekannten Betriebssystem ging es darum die Kontakte vom alten auf das neue Handy zu transferieren. Der einfachste Weg hierfür ist eine Synchronisation mit Google mit Hilfe der Nokia Software Mail for Exchange. Leider unterstützt mein aktuelles Handy diese Software nicht, also auf zu Plan B.

Exportieren aller Kontakte als vcf-Dateien mit Hilfe des Programms PC Suite und Übermittlung auf das neue Handy mittels MMS. Hierfür ist natürlich eine zweite, aktivierte SIM-Karte nötig, die hatte ich aber noch rumliegen. Doch auch ier machte mir das Nokia einen Strich durch die Rechnung. Die MMS wollte sich aber leider nicht verschicken lassen, auch hier machte mir das 6303i einen Strich durch die Rechnung. Plan C stand aber schon parat: Übertragen jeder einzelnen vcf-Datei von Handy zu Handy über Bluetooth.

Damit das ganze nicht ausartet nutzte ich die Gunst der Stunde und lichtete das Adressbuch ein wenig, so waren es dann nur knapp über 100 Dateien die übertragen werden mussten. Alternativ gibt es noch die Möglichkeit, die Kontakte mit Hilfe eines funambol-Servers zu synchronisieren. Diesen hatte ich vor einigen Jahren schon einmal kurz vorgestellt.

Nachdem die Kontakte ihren Weg auf das Handy gefunden hatten, sollten diese auch gleich mit Google synchronisiert werden. Hier ergaben sich anfangs einige Probleme. So ließen sich die Kontakte und Teile des Kalenders nicht synchronisieren. Abhilfe schaffte hier ein Löschen aller bereits vorhanden Daten im lokalen Kalender. Nach erneutem hinzufügen des Google-Kontos klappte die Synchronisation sofort. Bei den Kontakten reichte eine erneute Bestätigung, dass das Handy sich mit dem Google-Konto verbinden soll. Andere Nutzer hatten hier anscheinend größere Probleme, die unter anderem dazu geführt haben, dass alle Kontakte nochmals eingelesen bzw. eingegeben werden mussten.

Nachdem die ersten Schritte also mehr oder weniger problemlos geklappt haben, habe ich mich in die Fluten des Android-Markets gestürzt, mich ein wenig treiben lassen und Unmengen Apps ausprobiert. Hängen geblieben sind einige Apps die die Sicherheit erhöhen sollen, z.B. Anti-Virus Free, oder den Akku schonen helfen, z.B. Juice Defender Ultimate und Llama. Dazu kommen noch einige andere Apps wie Dropbox, WordPress, Backgrounds, Opera Mobile, Heise online, Droidstats, … .

In den nächsten Wochen werde ich hier sicher noch die ein oder andere App-Perle vorstellen und auch über das ein oder andere Erlebnis mit meinem Handy berichten.

Das Server-System

Der erste Schutz für euren Server ist ein passendes Betriebssystem. Wie die Überschrift bereits verrät kommt bei mir OpenSUSE zum Einsatz, genauer: Version 11.4. Einen eigenen Webserver kann man natürlich auch unter Windows betreiben, z.B. mit dem Paket von Apachefriends. Allerdings ist Windows hierfür meiner Meinung nach nicht die erste Wahl, es ist schlicht zu groß und zu Ressourcen-hungrig für die hier gestellten Aufgaben. Ein einfaches, nacktes Linux ist absolut ausreichend, es nimmt fast keinen Platz ein, lässt sich einfach Administrieren und läuft auch auf der kleinsten Kiste.

Je nach dem wie kritisch die Daten sind die auf dem Server hinterlegt werden sollen, sollte man sich genau überlegen, welche Sicherungen man einbaut. Grundsätzlich gilt: Wenn ein Externer via SSH auf den Server zugreifen kann, sind viele der Daten erst lesbar, wenn er auch das root-Passwort “errät”. Kommt der Server hingegen durch einen echten Einbruch in fremde Hände, können viele der Daten direkt von der Festplatte gelesen werden (z.B. mit einer LiveCD), das Knacken der Passwörter fällt dann auch leichter, da ein direkter Zugriff möglich ist.

Im ersten Fall helfen gute Passwörter, das Unterbinden eines direkten root-Logins via SSH (verhindert das Mitlesen des Passworts) und eine regelmäßige Durchsicht der Logs um Einbruchversuche früh zu erkennen (siehe Sicherung 2). Im zweiten Fall hilft die Unterbringung in einem sicheren Raum (Serverraum) und /oder eine Verschlüsselung des Laufwerks bzw. der Partitionen.

Grundlegend gilt allerdings: 100%ige Sicherheit gibt es nie! Auch aus gesicherten Serverräumen wird mal was geklaut, und auch alle Kriterien erfüllende Passwörter können mal geknackt werden.

Aber wir werden unser möglichstes versuchen.

Sicherung 1: SSH

SSH ist eine einfache Möglichkeit unseren Server aus der Ferne zu warten. Da in der minimalen Serverinstallation X sowieso fehlt, ist die Kommandozeile unser Freund, also SSH absolut ausreichend. SSH wird bei OpenSUSE 11.4 in der minimalen Serverinstallation gleich mit installiert, wer will kann die SSH-YAST-Konfiguration noch hinzufügen, es geht aber auch alles via Konfigdatei (/etc/ssh/sshd.config).

Um automatisierte Login-Versuche über den Standard-Port von SSH (22) zu unterbinden, lassen wir den SSH-Server auf einem beliebigen Port lauschen (Bsp: 36532). Dies kann mit Hilfe von YAST oder direkt in der ssh-Konfigurations-Datei erledigt werden. Natürlich muss dieser Port auch in der Firewall geöffnet werden. Steht der Server zudem noch hinter einer weiteren Firewall oder daheim hinter einem Router, muss auch dort der Port freigeschaltet bzw. weitergeleitet werden.

Den direkten Login von root verhindern wir mit der Einstellung  PermitRootLogin yes, es bietet sich auch an, die erlaubten Login-Versuche von sechs auf zwei zu reduzieren. Neben der Möglichkeit sich mittels Passwort zu authentifizieren, ermöglicht SSH auch einen Login mit Hilfe von Schlüsseldateien. In beiden Fällen ist darauf zu achten, die Dateien sicher zu verwahren (wenn z.B. der Heimrechner mal die Grätsche macht, sollte eine Sicherung der Schlüssel vorhanden sein). Aber auch die Passwörter sollten sicher aufbewahrt werden, entweder auf einem Zettel im Lieblingsbuch, im Gedächtnis oder mit Hilfe von speziellen Programmen (Bsp.: KeePass). Sollen die Daten nach eurem, eventuell spontanen, Verscheiden auch noch anderen Leuten zugänglich sein, solltet ihr einen Platz wählen, an dem man sie auch findet!

Nun haben wir unseren SSH-Zugang schon etwas besser abgesichert, je nachdem, wie wichtig die Daten auf dem Server sind, können wir die Sicherheit durch Zusatzsoftware wie z.B. den SSHGuard noch erhöhen. Hier muss jeder entscheiden, wie sicher einem sicher genug ist.

Ich empfehle aber allen, ab und an die Log-Dateien des Systems zu überfliegen, um mögliche Angriffe (meist automatische Skripte) frühzeitig zu erkennen und eventuell reagieren zu können (Port wechseln, Passwörter ändern, …).

Sicherung 2: Firewall

Die Firewall schützt unseren Computer vor ungebetenen Gästen, indem sie alle Anfragen auf Ports blockt, die von keinem aktiven Service des Servers erwartet werden. Um einen Zugriff von Extern auf den Webserver zu ermöglichen, müssen wir den Port 80 der Firewall öffnen, für unseren SSL-geschützten Server ist es der Port 443. Um uns mit Hilfe von Putty oder einem anderen SSH-Client auf dem Server einloggen zu können, muss der Port 22 geöffnet sein bzw. der Port, an dem wir unseren SSH-Server “lauschen” lassen (s. Sicherung 1).

Alle Ports die nicht benötigt werden, sollten geschlossen bleiben. Wird wie in Abschnitt 1 beschrieben, der SSH-Port verlegt, sollte der Port 22 geschlossen werden. Ebenso bleibt der 80er Port des Webservers geschlossen, wenn sowieso nur via https Anfragen ausgeliefert werden.

Sicherung 3: SSL Verschlüsselung für alles!

Der Server soll später als Webserver genutzt werden, erster Schutzmechanismus ist dabei natürlich SSL. An sich gibt es keinen Grund HTTP noch unverschlüsselt zu nutzen, auch wenn man es bisher fast nur von Webshops, Internet Banking und Co. kennt.

Ein gutes Beispiel bietet hier Google, die unter https://encrypted.google.com/ bereits eine https-geschützte Suchanfrage ermöglichen.

Um die Website via SSL absichern zu können, wird das Paket OpenSSL benötigt, welches bei der Standard-Server-Installation von OpenSUSE 11.4 bereits vorhanden ist. Mit Hilfe dieses Programms wird das Zertifikat für die Webseite erstellt. Ein erstes Zertifikat kann mit dem Befehl:

erstellt werden. Es handelt sich dabei aber nur um ein vorläufiges Zertifikat, dass aber für erste Testzwecke vollkommen ausreichend ist. Mit folgenden Befehlen wird ein individuelles Zertifikat für den Server erstellt und im zugehörigen Verzeichnis des Webservers abgelegt.

Ist das Zertifikat erstellt und abgelegt, können wir den ersten Start des Servers durchführen.

Nun sollte der Server über die Adresse: https://localhost eine erste Seite anzeigen.

In der ssl.conf im Verzeichnis /etc/apache2/vhosts.d/ können nun weitere Angaben für die Website eingegeben werden. Sollen weitere Websites auf dem Server gehostet werden, so ist dies leider nur über Aliase, IP-based oder Server Name Indication (SNI) machbar, da Apache2 mit SSL noch keine name-based vhosts akzeptiert.

Eine gute Erläuterung warum dies so ist gibt es hier, eine mögliche Konfiguration eines Alias folgt im Anschluss. Diesen Alias würdet ihr zum Beispiel über den Aufruf https://website.url/test/ aufrufen können.

Sicherung 4: mysql

Nach der Installation des MySQL-Servers sollte nach dem ersten Start ein root-Passwort für den MySQL-Server vergeben werden. Dies kann gleich mit dem Befehl

durchgeführt werden. Der Befehl entfernt darüber hinaus auch den Test-User, die Test-Datenbank und unterbindet von Anfang an einen root-Login von Extern. In meinem Beispiel läuft der mysql-Server auf der gleichen Maschine wie der Webserver, daher kann ich den externen Zugriff komplett verbieten und erspare mir so einige Sicherheitslücken.

Laufen auf eurem System mehrere Datenbanken für verschiedene Anwendungen, empfiehlt es sich, für jede Anwendung und Datenbank einen eigenen Nutzer anzulegen. So stellt ihr sicher, das bei bekannt werden eines Benutzernamen/Passwort-Paares, alle Datenbanken ausgelesen werden könnten. Mit Hilfe der Erweiterung phpMyAdmin lassen sich die Rechte der einzelnen Nutzer sehr gut anzeigen und auch testen. Loggt euch mit dem jeweiligen Nutzer in euer phpMyAdmin ein, und euch wird nur angezeigt, was dieser Nutzer auch sehen darf. Ob ihr schreiben, löschen oder die ganze Datenbank löschen dürft, könnt ihr so auch ganz schnell testen. Vorher aber ein Backup machen, s. Sicherung 6!

Sicherung 5: htaccess

Alle Verzeichnisse in denen der Otto-Normal-User nichts zu suchen hat, solltet ihr immer mittels .htaccess-Dateien absichern. Einige Beispiele wären /wp-admin/ wenn ihr WordPress benutzt, /phpMyAdmin/ wenn ihr das besagte Tool für die Verwaltung eurer Datenbanken nutzt, … . In der .htaccess-Datei (s.u.) legt ihr fest, dass nur Nutzer auf das Verzeichnis zugreifen können, die die benötigten Nutzerdaten kennen. Die Passwortdatei, die diese Informationen enthält, erstellt ihr mittels htpasswd2 (Anwendung siehe “man htpasswd2”).

Mit Hilfe der htaccess-Dateien ist es euch auch möglich, einige Servereinstellungen für einzelne Ordner zu ändern. So gibt es immer noch Software die z.B. die php-Einstellung “register_globals = ON” benötigt. Dies könnt ihr mit dem Zusatz “php_flag register_globals on” in der lokalen .htaccess-Datei erreichen.

Beispiel einer .htaccess-Datei zum Schutz eines Verzeichnisses (in diesem Fall der Adminbereich einer WordPress-Installation):

Da die .htaccess-Datein bei jedem Seitenaufruf erneut ausgewertet werden, kann eine allzu häufiger Gebrauch den Webserver etwas ausbremsen. Solltet ihr für viele eurer Verzeichnisse spezielle Regeln aufstellen wollen, so empfiehlt es sich, dies direkt in der Serverkonfiguration zu machen. Die hier hinterlegten Regeln werden nur einmalig eingelesen, werden aber auf alle Anfragen angewendet.

Sicherung 6: Backup

Jedem ist schon einmal eine Datei verloren gegangen. Sie wurde aus versehen gelöscht, oder bei einem Programmabsturz beschädigt etc.. Auch die Daten auf dem Server können durch einen Crash, äußere Einwirkungen (Feuer, Löschwasser, …) oder durch Diebstahl beschädigt, zerstört oder eben geklaut werden.
Damit die Daten dann nicht verloren sind, müssen in regelmäßigen Abschnitten Backups angelegt werden. Bei dem hier beschriebenen Webserver ändern sich nur die Inhalte der Datenbanken, daher wird von diesen ein Backup erstellt.

Das unten aufgeführte Skript nimmt einem diese Arbeit komplett ab. Die in Zeile 4 angegebenen Namen der Datenbanken werden mit Hilfe des Befehls mysqldump in separate Dateien gesichert und mit einem Datum versehen. Damit das Skript mehrere Datenbanken sichern kann, ist darauf zu achten, dass als mysql-Nutzer ein Nutzer eingetragen wird, der für alle angegeben Datenbanken Leserechte besitzt und das Recht die Datenbanken zu Sperren (Lock Table). Letzteres wird während des Auslesens benötigt, da so verhindert wird, das irgendwer während des Backups noch etwas in der Datenbank ändert.

Damit das Skript nun nicht immer manuell aufgerufen werden muss, bedienen wir uns der cronjobs. Mit dem Befehl “crontab –e” öffnet ihr die Steuerdatei für eure cronjobs. Hier könnt ihr nun Befehle anlegen, die zu einer bestimmten Uhrzeit, an einem bestimmten Tag etc. ausgeführt werden sollen. Hier ist also der richtige Platz für unser Skript, so stellen wir sicher, dass die uns wichtigen Daten alle 24h, oder wenn es bei euch arg dynamisch zugeht, auch öfter, gesichert werden.

Weitere Infos zu den cronjobs findet ihr hier.

Habt ihr noch andere dynamische Dateien die ihr sichern wollt, so könnt ihr die zugehörigen Verzeichnisse ebenfalls in verschlüsselte Archive sichern lassen. Dies ist zum Beispiel bei WordPress der Fall, hier finden sich in /wp-content/uploads eure eingebundenen Bilder und andere Daten die ihr auf eure WordPress-Seite hochgeladen habt.

Darüber hinaus solltet ihr natürlich auch den Code eurer Website zumindest einmalig irgendwohin sichern, schreibt ihr daran noch oft herum, dann macht euch ein Skript dafür, s.o..

Sicherung 7: Backup in die Cloud

Alle Backups werden auf einen zentralen FTP-Server übertragen um einen Datenverlust im Falle eines Brandes, Diebstahls etc. zu vermeiden. Die Backups sind alle, wie in Kapitel 6 erläutert, verschlüsselt und werden zudem über eine verschlüsselte Leitung auf den FTP-Server transferiert.

Da unsere Daten mittels cronjob jede Nacht auf den FTP-Server übertragen werden sollen, kann für diese Aktion nur ein Kommandozeilenprogramm in Betracht kommen. Um die Übermittlung der Daten mittels FPES sicherzustellen, bedarf es in diesem Fall eines kleinen Tricks. Die Daten werden nicht direkt in einer Kommandozeile an den Server übertragen, sondern der FTP-Server wird mittels curlftpfs gemountet. Die Verbindung zwischen curlftpfs und dem Server erfolgt dabei mittels TLS. Auf das gemountete Verzeichnis kann nun mittels einfacher cp, mv und rm Befehle zugegriffen werden.

Sollen mehrere Dateien aus verschiedenen Ordnern gesichert werden, verwenden wir das Programm rsync, ansonsten ist der cp-Befehl ausreichend.

Die einzelnen Befehle lauten:

Ende

Unser Server ist nun bestimmt nicht 100%ig sicher, aber die ersten wichtigen Schritte haben wir getan. Eine weitere, hier nicht genannte Sicherheitslücke, stellen “Einbrüche” über eure Website dar. Hier kann mittels SQL-Injection, Cross-Site-Scripting und weitere Techniken Zugriff auf euren Server bzw. eure Daten erlangt werden. Als Gegenmaßnahme hilft hier nur umsichtiges Programmieren bzw. regelmäßige Updates der verwendeten Softwarepakete.

Eine Lösung des Problems wäre ein kleines Skript, das die einzelnen Kalender ausliest, sie in einen Kalender zusammen fasst und dieser dann mit dem Handy synchronisiert wird. Auf diese Weise ist es aber leider nicht möglich, über das Handy Einträge zu verfassen, die dann auch korrekt im betreffenden Google-Kalender auftauchen.

Nun gibt es für derartige Probleme meist doch eine clevere Lösung, die aber oft, und auch hier, Geld kostet. Die beiden kommerziellen Programme GoogaSync und GooSync springen einem hier zur Seite und bieten auch die Option, mehrere Google Kalender mit dem Handy zu synchronisieren. Die Programme unterscheiden sich dabei grundlegend in ihrer Funktionsweise.

GoogaSync stellt ein Programm für das Handy zur Verfügung, dass die einzelnen Google Kalender auf das Handy herunterlädt, und diese mit den Einträgen auf dem Handy abgleicht. Die Namen der verschiedenen Kalender, z.B. Job oder Privat werden den Einträgen im Handykalender in eckigen Klammern vorangestellt, somit ist es ein leichtes die Termine im Auge zu behalten.
Um nun einen neuen Eintrag in einem der Google Kalender vorzunehmen, langt es im Betreff des lokalen (Handy) den Namen des Google Kalenders voranzustellen, also z.B.: [Privat] Zahnarzt, und schon erscheint der Eintrag nach dem nächsten Sync auch im Google Kalender.
Das Programm kostet einmalig 17,90 €, eine 14-tägige Testversion ist verfügbar.

GooSync funktioniert ein wenig anders. Auch hier wird eine Anwendung auf dem Handy installiert, die die Kalenderdaten allerdings nicht von Google direkt herunterlädt und lokal verarbeitet, sondern von einem Server von GooSync, der die Daten vorab von Google heruntergeladen hat. Der Anbieter versichert, dass alle Daten vertraulich behandelt werden, hier muss jeder entscheiden, in wie weit er hierauf vertrauen will. Der Service ist etwas teurer als der Konkurrent, durch den Server der die Daten von Google lädt und für die Anwendung vorbereitet, entstehen dem Anbieter laufende Kosten. Daher gibt es für diesen Service ein anderes Preismodell. Für die Premiumvariante (diese wird für den abgleich mehrere Google Kalender benötigt) fallen im Jahres Abo 19,95 Pfund an, im Zweijahres Abo sind es 29,95 Pfund und für das lebenslange Abo gar 39.95 Pfund. Mit der Free-Variante kann zumindest ein Kalender abgeglichen werden (14 Tage in die Zukunft, 7 Tage zurück, maximal 1 Endgerät), mit der Lite-Variante ist es ebenfalls nur ein Kalender (45 Tage in die Zukunft, 14 Tage zurück, 2 Endgeräte), die Premium-Variante kann dann mehrere Kalender synchronisieren, verteilt auf mehrere Endgeräte.

Beide Programme bieten die Möglichkeit die Kalender in festen Perioden abzugleichen, bei GooSync können für die Arbeits- und Freizeit unterschiedliche Intervalle angegeben werden. Beide Programme synchronisieren sowohl im WLAN als auch über UMTS. Ist ein gespeichertes WLAN verfügbar, wird dieses natürlich bevorzugt genutzt.

Ich habe mich letztendlich für GoogaSync entschieden. Dies führt zu etwas mehr Traffic auf dem Handy, da alle Kalender bei einem Sync überprüft werden müssen, die Änderungen also nicht, wie beim zweiten Anbieter, schon auf dem “Zwischen”-Server aufbereitet vorliegen. Dafür gelangen die Kontodaten und Einträge der Kalender von Google direkt auf das Handy, alles natürlich über SSL verschlüsselt, und sollten somit etwas sicherer sein.

Ich nutze das Programm nun schon 3 Wochen, und kann es bisher nur empfehlen.

Nun gibt es das Plugin Firefox Sync. Damit ist es ebenso möglich die Lesezeichen, die Passwörter aber auch z.B. die komplette Chronik zwischen mehreren Rechner zu synchronisieren. Auch hier können diese Daten auf einem eigenen Server abgelegt werden, oder aber auf den Server der Mozilla Foundation. Diese können mit den Daten nichts anfangen, da sie mit einer selbst gewählten Passphrase verschlüsselt sind, die auf dem eigenen Rechner verbleibt und nicht mit übertragen wird.

Ich habe mir das Plugin installiert, auch wenn ich es nicht oft benutzen muss, da mein Firefox und mein Thunderbird aus der Dropbox heraus genutzt werden.