Backup von Websites leicht gemacht

Viele Webseiten oder Blogbetreiber machen sich wenig Gedanken über Backups. Was ist, wenn der Webhoster ausversehen die Platte schreddert, oder jemand mit zu viel destruktiver Energie über eine Sicherheitslücke Zugriff auf den Server bekommt und einfach mal eure Website löscht? Was, wenn ein Update z.B. von Wordpress mal nicht sauber durch läuft, oder ihr ausversehen etwas löscht, was ihr gar nicht löschen wolltet? Diese Dinge sind in meinem Umfeld schon das ein oder andere mal geschehen, weshalb ich regelmäßig ein lokales Backup von Datenbanken und Dateien meiner Websites mache.

Ich will euch nun zeigen, wie ihr recht einfach mit UNIX-Bordmitteln entsprechende Backups ziehen könnt, ohne Shell-Zugriff auf den Webserver haben zu müssen. (Ein Backup mit Hilfe von rsync oder ähnlichem, per SSH ist dieser Methode definitiv vorzuziehen. Vorsicht, diese Methode sendet eure Logindaten unverschlüsselt übers Internet!)

Vorbereitung

Für dieses Tutorial braucht ihr das UNIX-Tool wget. Unter Mac OS X ist dies nicht standardmässig installiert, weshalb ihr es z.B. mit MacPorts, Fink oder Homebrew nachinstallieren solltet. Ich persönlich nutze Homebrew und habe darüber nicht nur wget, sondern auch andere nützliche Helferlein wie nmap, htop und einige andere installiert. Für Windows gibt es das Projekt Cygwin.

Anleitungen zur Installation dieser Paket-Manager findet ihr auf den entsprechenden Seiten. Bitte lest erst weiter wenn Ihr wget nachgerüstet habt.

Es empfiehlt sich nun, an passender Stelle eine Ordnerstruktur für eure Backups anzulegen. In meinem falle ist dies /Users/julius/Daten/websites/backups/. Wget legt dort für jede Website einen Unterordner an, um die einzelnen Backups auseinander zu halten.

Nun müssen wir ein bisschen schwarze Magie auf der Komandozeile ausführen. Aber keine Angst unter OS X gibt es Möglichkeiten, das Ganze später mit einem Mausklick oder per Cron-Job auszuführen.

Mit dieser einfachen Zeile im Terminal ladet ihr euch rekursiv den kompletten Inhalt des FTP-Servers in einen neuen bzw. bestehenden Ordner herunter.
Für viele ist hier schon Schluss, da es für einfache HTML-Webseiten ausreicht.

Wenn man möchte kann man nun diversen Voodo mit seiner Sicherheitskopie anstellen. Man kann ein rotierendes Backup erstellen, kann die Dateien mit Git Versionieren (das ist das, was ich momentan mache), sie komprimieren und auf dem Netzlaufwerk archivieren etc. Der Fantasie sind hier keine Grenzen gesetzt.

Sobald ich meinen Workflow so habe wie ich es mag, werde ich das noch mal etwas ausführlicher beschreiben.

Wie immer: Solltet ihr Fragen, Wünsche, Feedback haben, immer her damit!

Weihnachtsgeschenke…

Falls ihr noch Weihnachtsgeschenke für mich, eure Bekannten oder für euch selbst sucht:

Das Smashing Magazine hat ein cooles Buch veröffentlicht. #habenwill

Alternativ gibt es natürlich meinen Amazon Wunschzettel.

Ich bin selbst noch etwas planlos, was ich dieses Jahr verschenken soll und hoffe, wenigstens euch ein klein wenig geholfen zu haben. :)

Datenskandal bei haeft.de

Das ist ja wohl mal der Hammer. haeft.de eine Community für Kinder war offen wie ein Scheunentor. Die Seite wurde nun bis auf weiteres offline genommen.

Hier ein Auszug aus der Pressemeldung von CCC.de:

Jedes Zugangskonto der Kinder soll durch ein Paßwort geschützt sein. Jedoch konnten auch ohne Mühe und ohne Kenntnis dieses Paßwortes alle hinterlegten Daten der Schüler eingesehen werden. Selbst die Administrationskonten der offenkundig ungesicherten Plattform waren frei zugänglich. Somit konnten sämtliche gespeicherten Daten aller Nutzer von jedem nach Belieben eingesehen werden, dem diese Lücke aufgefallen ist. Darüberhinaus konnte sich jeder als ein angemeldetes Kind ausgeben und als dieses in der Community agieren. Dafür machte es haefft.de Neugierigen besonders leicht: Passende und ständig neue Nutzernamen wurden noch vor dem Einloggen auf der Community-Seite per “Grußkarte” offenbart – bereit zum Kopieren und Einfügen in das Anmeldefeld.

Schockierend! Noch etwas detailreicher bringt es Dirk auf den Punkt:

“Die Entwickler bei haefft.de haben sich dabei so ziemlich alle Anfänger-Programmierfehler geleistet.” Die Kennwörter waren nicht wie üblich gehasht, sondern im Klartext gespeichert. Zudem wurden sie mit dem ILIKE-Operator nur auf Ähnlichkeit verglichen, so daß sich die Paßwort-Abfrage mit einfachsten Mitteln umgehen ließ. Die Eingabedaten des Benutzers wurden ungefiltert als Befehl an die Datenbank weitergereicht. Marktübliche Techniken zur verschlüsselten Übertragung der Zugangsdaten wie HTTPS scheinen bei haefft.de unbekannt.

Quelle: http://www.ccc.de/de/updates/2009/haefft-datenloch

Hier wurde also eine Plattform betrieben, die auf Kinder, nicht ältere Schüler oder Studenten, sondern Schulkinder ab Grundschulalter ausgerichtet war, bei deren Konzeption und Umsetzung jegliche Grundprinzipien der sicheren Programmierung für Webanwendungen missachtet wurden.

Sehr witzig finde ich die Pressemeldung von haeft.de

Der Geschäftsführer Stefan Klingberg meint:

Im Moment gehe der Verlag davon aus, dass es sich ausschließlich um ein bereits gefixtes potenzielles und noch nicht reales Problem handele

Ein paar Sätze weiter steht:

Unter Hochdruck arbeiten wir derzeit an der Beseitigung der Sicherheitslücken. Ein aktueller Termin, wann die Probleme behoben sein werden, kann im Moment noch nicht gegeben werden.

Wie passt das denn zusammen? “Bereits gefixt” und “Unter Hochdruck arbeiten wir bereits an einer Beseitigung der Sicherheitslücken”? Das Problem scheint ja doch nicht so trivial zu sein, denn sie wissen nicht, wann sie wieder online gehen können.
Quelle: http://presse.haefft.de/?p=401

Wie passt das denn alles zusammen? Für eine Community die es seit 1998 gibt (ich glaube vorher hieß das Ganze funcity.de) ist das aber ein herber Schnitzer. Wurde an dem Code seit dem nix mehr gemacht? Gab es die Lücken etwa seit 1998? Sieht fast so aus. :)

Eigentlich müsste man den Verantwortlichen verbieten weiterhin in diesem Bereich zu arbeiten, und für solche Angebote strengste Kriterien bezüglich Sicherheitsmaßnahmen auferlegen. Das vielgepriesene TÜV-Siegel ist ja, wie wir im Falle Libri gemerkt haben, kein Garant für sichere Anwendungen.

Daher muss meiner Meinung nach der Gesetzgeber sofort einschreiten und mit Hilfe von unabhängigen Experten Routinen und Verfahren austüfteln, wie eine Evaluierung der Sicherheit solcher Portale realisierbar ist. Und zwar so, dass es wirklich was bringt. Sich so ein Siegel beim TÜV zu kaufen sollte nicht ausreichen. :)

Ich hoffe, dass haeft.de nach dem Fixen Ihres Portals externe Pentester und Leute die sich den Code sehr genau angucken einkauft. Alles andere wäre unverantwortlich und gehört bestraft.

Über den Unsinn der Google-Analytics Diskussion

Google Analytics ist mal wieder in aller Munde. Wer es nicht kennt: Google Analytics ist ein von Google bereitgestellter Service zur Analyse von Webseitenstatistiken.

Um Google Analytics nutzen zu können, baut man einen simplen JavaScript Code in seine Website ein und erhält so ausführliche Seitenstatistiken wie Besuchszahlen, Referrer, Betriebssysteme, Browserkennungen usw. Es ist also ein gutes Mittel um die Reichweite seiner Inhalte zu prüfen und ggf. Verbesserungen in der Struktur seiner Website vornehmen zu können.

Der Knackpunkt der ganzen Diskussion ist die Übermittlung von Personenbezogenen Daten, also in diesem Falle das, was der Besucher freiwillig über sich verrät, nämlich seine IP-Adresse, und die Browseridentifikation an einen Dritten, in diesem Falle Google, stattfindet. Google weiß also wer eure Website besucht. Die Speicherung und Übermittlung solcher Daten an Dritte ist in Deutschland nur nach vorheriger Zustimmung möglich, was beim Einsatz von Google Analytics oder ähnlichen Services nicht praktikabel umsetzbar ist.

Soweit so gut. Die Speicherung und gar Übermittlung von personenbezogenen Daten ist nicht zulässig. – Das finde ich persönlich gar nicht so schlecht. Im Folgenden werde ich kurz darlegen, warum ich die Diskussion trotzdem für unsinnig halte, oder weitergehende Schritte fordere:

Sobald eine Datei von einem Webseitenbesucher bzw. seinem Browser heruntergeladen wird, taucht in den Logfiles des bereitstellenden Webservers ein Eintrag auf, der in der Regel IP-Adresse, Uhrzeit und Browserkennung beeinhaltet. Viele Webserver unterstützen die Funktion, diese Daten vor dem Schreiben ins Logfile zu verstümmeln oder gar komplett zu anonymisieren. Jedoch bieten dies bei weitem nicht alle Anbieter von Webspace an, oder die entsprechenden Admins sehen gar keine Notwendigkeit, dies einzurichten. Der Apache Webserver hat für seine Defaulteinstellung, die Daten komplett im Logfile abzulegen, bereits den BigBrother-Award erhalten. (Auf dieser Website werden die IP-Adressen nur gekürzt im Logfile abgelegt und sind daher zum größten Teil anonymisiert.)

In der Praxis sieht es folgendermaßen aus:

• Viele Webseiten anonymisieren ihre Logfiles nicht, weil es entweder niemanden interessiert, oder schlichtweg für den Betreiber nicht möglich ist.
• Auf Webseiten werden bewusst Trackingtools eingesetzt um die Analyse des Besucherverhaltens zu ermöglichen. Eines dieser Tools ist Google Analytics.
• Websites schalten Werbung. Diese wird von einem Werbeanbieter über deren AdServer geliefert. In diesem Falle bedingt schon allein die Notwendigkeit der Abrechnung und Messung der Reichweite sowie Klickverhalten das Analysieren der IP-Adressen und ggf. das Setzen eines Cookies. (Siehe Cash per Click, Costs per Lead, etc.)
  
  Wichtig ist hierbei, dass die Werbung in der Regel nie auf selbst betriebenen AdServern liegt, sondern von Anbietern wie Doubleclick, Google-Adsense o.ä. geholt wird. Diese Tracken dann auch die Klickzahlen, Leads, usw. Weiterhin verhindern Sie mit diversen Algorithmen, dass der Webseitenbetreiber selbst auf die Werbung klickt, und sich somit Geld ergaunert.
  D.h.: Ohne den Einsatz solcher Techniken, die die Übertragung von Personenbezogenen Daten an Dritte implizieren, ist das Schalten von Werbung auf Webseiten, und somit oft der einzige Weg der Monetarisierung von Inhalten, schlichtweg für den Großteil der Webseitenbetreiber nicht möglich.
• JavaScript Bibliotheken werden oft von externen Quellen (z.B. Google) eingebunden. Dies verursacht wiederum eine Übermittlung der IP-Adresse usw. an Google
• Oft werden gerade große Datenmengen wie Bilder auf externe Dienstleister ausgelagert. Bei jedem Laden der Datei werden auch hier wieder Personenbezogene Daten an Dritte übermittelt. (Flickr, Googles Picasa, Dropbox, etc.)
• Beliebt sind auch Widgets (z.B. Twitter, Wetter, Uhrzeit, Börsenkurse o.ä.) die per JavaScript eingebunden werden, sowie Videos per Youtube, Vimeo o.ä. Auch hier liegen die Inhalte wieder auf fremden Servern. Es findet also auch eine Übermittlung personenbezogener Daten an Dritte statt.

Was ist eigentlich mit dem in der deutschen Internetwirtschaft so viel gepriesenen IVW? Dieses Instrument zur Reichweitenmessung ist auf sehr vielen großen Webseiten vertreten. Zitat von IVW.de:

Erfassung von Daten

Sie können unsere Online-Präsentation grundsätzlich ohne Offenlegung Ihrer persönlichen Daten nutzen. Durch das Aufrufen unserer Websites werden auf unseren Servern Daten für Sicherungszwecke gespeichert, wie der Name Ihres Internetserviceproviders, die Website, von der aus Sie uns besuchen, die Websites, die Sie bei uns besuchen und Ihre IP-Adresse. Diese Daten können zu statistischen Zwecken ausgewertet werden, wobei der einzelne Benutzer jedoch anonym bleibt.

Quelle: http://ivw.de/index.php?menuid=1&reporeid=12

Hier findet also auch eine Übermittlung von personenbezogenen Daten statt. #fail?

Fordert man nun ein Verbot von Google Analytics in Deutschland, so müsste man auch das Einbinden von Inhalten verbieten, die nicht auf dem eigenen Webserver und damit unter eigener Kontrolle stehen, verbieten.

Dies würde dem Web wie wir es heutzutage kennen, vieles von dem nehmen, was es ausmacht. Nur richtig große, kommerzielle Webseiten, hätten die Möglichkeit Werbung zu schalten, Videos anzubieten usw. Das ganze (Buzzwordalarm) Web 2.0 wäre dem Untergang geweiht.

Ich persönlich finde es sehr witzig, dass auf Webseiten, die lautstark ein Verbot von Google Analytics fordern, z.T. Werbung geschaltet wird, Youtube Videos eingebunden werden usw. Ein typischer Fall von “Wenn man keine Ahnung hat: Einfach mal Fresse halten.”

05 Dez 2009 9 Meinungen Tweet this

Neues Layout

Seit gestern ist das neue Layout quasi fertig. Nun werden lediglich kleinste Veränderungen folgen um die Usability und Funktionalität ein klein wenig zu erhöhen. Das aktuelle Template basiert auf einem der Beispiele des YAML:3 Frameworks, welches für die Erstellung dieses Templates eingesetzt wurde.

Weiterhin setzt dieses Template stringent auf die Nutzung der Schriftart Cicle von http://www.tipomatika.co.nr für Überschriften. Die Lizenz sieht das distributieren der Schriftart mittels @font-face nicht ausdrücklich vor, jedoch habe ich von Joan per E-Mail die Erlaubnis dazu erhalten.

Das komplette Paket der Fonts werde ich ggf. demnächst hier zum Download anbieten, oder zumindest verlinken. Mit fertigem CSS für alle Browser und den entsprechenden Font-Dateien.

Ich hoffe, ihr findet euch hier gut zurecht und die Seite ansprechend, klar und aufgeräumt. In Zukunft wird es auch wieder ein wenig mehr Content geben. :)