Weitere Informationen zu WordPress 2.9 mit dem Codenamen “Carmen” gibt es bei WordPress.

Im folgenden soll auf ein paar Punkte hingewiesen werden, die einem die Suche nach der richtigen Antwort auf die Frage geben soll: Wie finde ich raus, ob ich betroffen bin? Was sollte ich auf jeden Fall machen? Sollte ich lieber eine andere Blogsoftware auf meinem Server einsetzen oder gar zu einem fullservice Blogdienst wechseln?

1. Wie finde ich raus, ob meine WordPress Installation gehackt wurde?

Was den aktuellen “Wurm” angeht, gibt es verschiedene Möglichkeiten das zu überprüfen. Erster Anhaltspunkt sollte sein, sich die Permalinks von WordPress anzuschauen. Haben diese komischen Code am Ende, so hat der Wurm zugeschlagen:

blogadresse.de/beitrag/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/

Dabei sind die Code Schnipsel “eval” und “base64_decode” entscheidend. Diese Veränderung der Permalink-Struktur erfolgt aber anscheinend erst in einem späteren Schritt, wenn der Wurm bereits im System sein Unwesen treibt. Der erste Schritt ist nämlich, dass der Wurm einen weiteren Administrator als Benutzer anlegt. Dabei geht er aber so geschickt vor, dass man nicht einfach im Backend im Benutzerbereich nachschauen kann, denn dort versucht der Wurm mittels JavaScript den zweiten Administrator auszublenden. Wenn man das also überprüfen will entweder JavaScript ausschalten oder am besten direkt in der MySQL Datenbank nachschauen.

Dafür sollte man in phpMyAdmin entweder in der Userdatenbank nachschauen oder einfach folgendem Tipp von Dougal Campell folgen und diese SQL Abfrage laufen lassen:

Sofern ein eigenes Tabellenschema verwendet wird, muss der Präfix wp_ entsprechend angepasst werden.

Auch hier nur ein Admin Account? Dann ist erstmal Entwarnung angesagt. Trotzdem kein Grund sich entspannt zurückzulehnen. Was nicht ist, kann (leider) noch werden.

2. Was sollte ich auf alle Fälle tun?

Der häufig genannteste Tipp in Zusammenhang dieser Tage ist: Updaten. Denn insbesondere ältere Versionen von WordPress und deren Sicherheitslücken nutzt der Wurm um sich Zugang zum System verschaffen. Generell empfiehlt es sich, seine WordPress Installation auf dem neuesten Stand zu halten, was dank der neuen Auto-Update Funktion auch wirklich ein Kinderspiel ist.

In diesem Zusammenhang wird allerdings häufig angeführt, dass dabei aber Probleme mit den verwendeten PlugIns und Themes entstehen. Dies stimmt nur in den seltensten Fällen und ist dann meist durch eine aktualisierte PlugIn Version behoben. Aber das führt gleich zum nächsten Sicherheitsaspekt: So viele Plugins wie nötig, aber so wenige wie möglich.

Plugins sind eine feine Sache und ermöglichen es WordPress so vielfältig einzusetzen, wie es nur geht. Durch Plugins können Funktionen ergänzt und die Sicherheit verbessert werden. Doch Plugins bedeuten auch weiteren Code und stellen damit auch ein weiteres Sicherheitsrisiko dar. Es ist daher ratsam die Zahl der aktivierten Plugins möglichst gering zu halten und Plugins deaktiviert werden, wenn sie nicht mehr benötigt werden. Zu den nötigen und sinnvollen Plugins in einem späteren Teil dieser Reihe.

Ein weiterer Punkt, der die Sicherheit einer eigenen WordPress Installation erhöht ist die Personalsierung von WordPress. Dazu gehört zunächst natürlich ein effektiver Passwortschutz der einzelnen Benutzer. Passwörter sollten also möglichst lang sein und Zahlen und Sonderzeichen enthalten. Dieses sollte man Anhand eines Passwortgenerators überprüfen (Mac OS X bietet diese Möglichkeit im Schlüsselbund oder ein Programm wie 1Password ist dazu auch geeignet). Daneben sollte man die Installation von WordPress anpassen. Dem Administrator sollte man am besten nicht den Kurznamen “admin” geben, wie WordPress dies standardmäßig tut. Außerdem sollte die Datenbankstruktur nicht dem klassischen  Schema “wp_TABELLENNAME” folgen, sondern vor dem Unterstrich individualisiert sein. Beides sind Punkte, die man am Besten direkt beim Anlegen des Blogs festlegt. Dieses bei einem laufenden Blog zu ändern, ist etwas schwieriger. Wie es doch geht, wird in einem späteren Teil dieser Reihe gezeigt.

3. Sollte ich eine andere Blogsoftware einsetzen?

Eine Alternative wäre es, eine andere Blogsoftware auf dem eigenen Server zu betreiben. Als solche nennenswert sind sicherlich Movabletype und ExpressionEngine. Beide entsprechen vom Funktionsumfang etwa WordPress und können daher als Alternative herangezogen werden, wenn man einen Wechsel der Software erwägt. Doch ist ein Wechsel wirklich sinnvoll? Schwerwiegende oder vermehrte Sicherheitsmängel und Angriffe sind in der Vergangenheit nur von WordPress bekannt, der Eindruck liegt daher nahe, das ein Wechsel zu mehr Sicherheit führt. Das ist jedoch ein Trugschluss. Hier kann man einen Vergleich zu den Betriebssystemen ziehen und etwa WordPress mit Windows und ExpressionEngine mit Mac OS X vergleichen. Auf Grund der Verbeitung und (dank der Plugins) größeren Angriffsfläche ist WordPress für Hacker ein attraktiveres Ziel, doch sind andere Blogsoftware davon nicht verschont. Sie enthalten ebenso Sicherheitslücken und Schwachstellen und auch dort ist die Gefahr eines Hackerangriffes nicht ausgeschlossen. Wer also kein Vertrauen mehr in WordPress hat, sollte sich konkurrierende Softwarelösungen anschauen, doch letztlich wird ein Wechsel kein mehr an Sicherheit bringen, gegenüber einer gepflegten und überwachten WordPress Installation.

4. Ist es nicht besser auf einen Fullservice Blogdienst zu vertrauen?

Sicherheit ist vor allem eine Frage der Wartung und der Kontrolle. Wer also einmal eine Blogsoftware auf seinem Webspace installiert hat und diese dann kaum wartet oder kontrolliert, der setzt sich einem entsprechenden Sicherheitsrisiko aus. Wer sich nicht großartig um Wartung und Kontrolle der Software kümmern will, der sollte über den Wechsel zu einem Blogdienst überlegen. Zum Fullservice dieser Dienste gehört in erster Linie die Wartung und Kontrolle des gesamten Systems. Der Blogger kann sich ganz auf das Bloggen konzentrieren und muss sich nicht groß um Sicherheit, Updates und Kontrolle kümmern. Er kann es auch nicht. Blogdienste gibt es wie Sand an mehr. Spontan fallen mir da Tumblr, Posterous, Blogger, Typepad, WordPress.com und Squarespace ein.

Viele Dienste für die unterschiedlichsten Lösungen. Keines ist sicherlich so komplett und flexibel wie eine eigene WordPress Installation mit voller Kontrolle über Plugins und insbesondere das Aussehen des Blogs. Tumblr, Posterous und Blogger sind da eher für das schnelle Bloggen geeignet, während Typepad, WordPress.com und Squarespace wahrscheinlich bis zu 90% der Funktionen abdecken, die eine eigene WordPress Installation bietet, meist jedoch gegen Aufpreis. Hier stellt sich also die Frage, was will man sich die Sicherheit und den Fullservice kosten lassen. Auch auf diese Möglichkeit werde ich in einem späteren Teil der Reihe detailierter eingehen, da genau diese Frage mich persönlich für dieses Blog auch beschäftigt.

5. Fazit

WordPress ist eine gute und umfangreiche Blogsoftware. Die Sicherheitsrisiken sind nicht zu unterschätzen, sollten allerdings auf der anderen Seite auch nicht dramatisiert werden. Lücken und Hackerangriffe sind bei jeder Webanwendung vorhanden. Es bleibt also nur die Frage wie gut man sich persönlich davor schützen kann oder wem man diese Aufgabe überträgt. In einem zweiten Teil möchte ich auf sinnvolle Plugins hinweisen, die die Sicherheit fördern und auch welche Personalisierungen man im Detail machen sollte und wie das am Besten funktioniert. In einem weiteren Teil werde ich die Alternativen im Bereich der Blogdienste aufzeigen und welche Tücken/Vorteile ein Wechsel hat.

Jalkuts Beobachtungen und Fazit sind nicht neu, doch stellen für die einen so etwas wie Gotteslästerung dar. Jalkuts Problem mit der GPL (und das vieler anderer Software-Entwickler, wie ich selbst schon häufig genug hören durfte) ist das Copyleft der GPL. Das Copyleft der GPL wird häufig (auch von Seiten der Free Software Foundation, die die GPL entwickelt) als “Virus” bezeichnet. Für Jalkut dürfte der Begriff absolut treffend gewählt sein, handelt es sich doch bei einem Virus in der Regel um eine Krankheit und somit einen negativ belegten Begriff.

Das Copyleft der GPL-Lizenz sorgt dafür, dass jede Weiterentwicklung, Ergänzung oder Veränderung eines Softwarecodes der unter GPL lizenziert wurde, abermals unter der GPL lizensiert werden muss um sicherzustellen, dass die Software nicht durch minimale Veränderungen unter einer anderen (womöglich kommerziellen) Lizenz veröffentlicht werden kann. Das Copyleft ist insbesondere dann störend, wenn Unternehmen in umfangreiche Softwarelösungen ein winziges Bauteil einprogrammieren, das welches unter der GPL lizensiert ist. Sofern diese Software weiterverteilt werden soll (also nicht nur für den eigenen Gebrauch verwendet wird) muss sie dann, “dank” Copyleft unter der GPL weiterverbreitet werden und die Wertschöpfung aus der umfangreichen Entwicklungsarbeit ist für das Unternehmen gleich Null.

Die Free Software Foundation rühmt sich auf ihrer Website damit, dass sie seit Jahren für “essentielle Freiheiten” der Computer User kämpfen. Doch genau das wird in der aktuellen Diskussion in Frage gestellt. Wer für Programme entwickelt oder solche verwendet die mit der GPL lizensiert sind, der ist nicht frei, so Jalkuts Vorwurf. Er ist auf immer und ewig an die GPL gebunden. Jalkuts These, dies schreckt eine Mehrheit von Entwicklern ab, die eben keine Glaubensfanatiker sind und alles unter der “freien” GPL lizensiert sehen wollen, sondern die sowohl für kommerzielle als auch freie Entwicklungen offen sind. Matt Mullenweg, der Erfinder/Hauptentwickler des Blogsystems WordPress, hält in der idealistischen Sichtweise der GPL dagegen: WordPress ist eine gigantische Community, die sich prächtig entwickelt dank der GPL, die so die Freiheiten der Nutzer garantiert.

Wie der Entwickler und Blogger John Gruber richtig feststellt, reden die beiden aneinander vorbei. Der eine spricht von der Freiheit der Entwickler, der andere von der Freiheit der Nutzer. Die GPL ist an sich kein Teufelszeug. Das behauptet Jalkut allerdings auch nicht. Aber sie ist bei weitem nicht der heilbringende Gral für den sie die FSF und auch Mullenweg halten. Allerdings liegt darin gleichermaßen der Erfolg und Nachteil der GPL:

1. Die GPL ist Endnutzer freundlich. Der Endnutzer kann ohne Lizenzgebühren die Software verwenden und nach seinen Wünschen anpassen. Das garantiert unter GPL lizensierter Software eine große Verbreitung (siehe allein WordPress und Linux) aber auch eine große Community, die diese Softwareprodukte weiterentwickeln, vieles darunter aber sicherlich auch halbwegs talentierte Freizeitcoder.
2. Die GPL ist Entwickler unfreundlich. Für einen Software-Entwickler ist die GPL kein Synonym für Freiheit. In der Realtität hat die GPL mehr etwas von einer Zwangsjacke. Wer sich als Softwareentwickler auf die GPL einlässt, in dem er etwa Zusatzmodule für ein bestimmtes GPL-Softwareprodukt wie WordPress entwickelt, der wird etwa dieses Modul nicht angepasst auf ein andere Plattform nicht kommerziell vertreiben dürfen. Er muss das gleiche Produkt von der Pike auf neu entwickeln, um einer GPL Verletzung zu entgehen.

Das ganze ist allerdings keine Frage, für oder gegen OpenSource Software. OpenSource besteht nicht alleine aus der GPL-Lizenz, auch wenn das von der Free Software Foundation gerne mit Vehemenz vertreten wird. Daneben gibt es etwa die weitaus älteren OpenSource Lizenzen, wie die MIT oder BSD Lizenz. Auch hierbei handelt es sich um OpenSource Lizenzen und ebenfalls sehr erfolgreiche OpenSource-Programme verwenden diese Lizenzen, etwa FreeBSD oder Webkit um nur zwei beispiele zu nennen. Der Vorteil dieser Lizenzen ist allerdings, dass sie kein Copyleft besitzen und wenn der Entwickler oder ein Unternehmen will, kann es diese Softwareprodukte für eigene kommerzielle Produkte verwenden. Dank dieser Lizenzen muss man sich der Entwicklung von Mac OS X und Browsern wie Safari oder Google Chrome erfreuen.

Beide freien Plattformen haben auch durch die kommerzielle Weiterentwicklung seitens Apple profitiert. Die Befürchtung etwa der Free Software Foundation, dass die entsprechenden Programme damit völlig absorbiert werden und eigentlich der OpenSource Gemeinde nicht mehr zur Weiterentwicklung zur Verfügung stehen, haben sich nicht bewahrheitet. Die GPL hat mit dem Copyleft ein Schutzschild gegen das Ausplündern der OpenSource Software durch große Softwarekonzerne wie etwa Microsoft im Sinn gehabt. Entwickler für entsprechende Programme konnten sich sicher sein, dass ihre Software auf immer und ewig frei und kostenlos weiterverteilt werden kann.

Doch Mac OS X zeigt, dass der Softwaremarkt nicht nur aus Raubrittertum besteht und freie und kommerzielle Software sehr wohl nebeneinander existieren können und so sogar den Softwaremarkt beleben können durch ein Maximum an Flexibilität. Das Copyleft der GPL mag für den Aufbau einer Softwareplattform sehr hilfreich sein, aber auf Dauer, dürfte es die Entwicklung und Verwendung hemmen. Die GPL ist daher kein Garant echter Freiheit, da sie jegliche Flexibilität untersagt. Wer Freiheit für sein Softwareprodukt will, der sollte auf eine BSD-artige Lizenz zurückgreifen, auch wenn dies ein steinigerer und langsamerer Weg ist. Die Entwicklung ist damit jedenfalls genauso dauerhaft frei, wie bei der Lizenzsierung unter der GPL und kann von jedem verwendet werden, auch wenn andere durch geschickte Weiterentwicklungen damit kommerziell erfolgreich werden.

Das WordPress-plugin Wordbook bindet allerdings die Beiträge direkt ein und somit nur noch auf der eigenen Wall und nicht mehr im Stream der eigenen Freunde, was für die Verbreitung der Artikel doch eher nachteilig ist. Doch die Abhilfe war nicht weit. Sie kommt allerdings in Form einer neuen Facebook-Application entwickelt von James Andrews: FullCircle.

FullCircle bietet außerdem zahlreiche weitere Features: Neben facebook verwaltet das plugin auch die Integration nach Twitter und man kann in jedem einzelnen Beitrag optional entscheiden, ob der Artikel tatsächlich über die beiden Dienste veröffentlicht werden soll oder nicht.

FullCircle hat allerdings einen kleinen Haken zur Zeit. Da der Blogbeitrag als Link (und nicht als Note!) in Facebook gepostet wird, übernimmt facebook das erst beste Bild, dass es in passender größe im Quelltext finden kann. Das hat bei der Verwendung von Badges und Werbung den nachteil, das völlig unzusammenhängende Bilder verwendet werden.

Folgende Abhilfe habe ich gefunden: Da facebook das erste Bild aus dem Quelltext nimmt habe ich am Ende des Headers eine 100px große Version meines Logos eingefügt mit folgendem Code:

<img src="http://www.BILDURL.de/BILD.png" style="display:none;" />

Der Code bewirkt, dass beim normalen Betrachten des Blogs, das Bild nicht angezeigt wird. facebook allerdings ignoriert die style-Anweisung und übernimmt das Bild.

Et voila. :-)

Die Idee stammt aus der Schmiede der WordPressgründer. Diese sitzt natürlich in den USA und, wie ich hier in den letzten Monaten gelernt habe, hat man für das nun folgende weder Verständnis noch Gespür.

Akismet überträgt von dem heimischen Blog an den Akismet-Server in den USA für jeden Kommentar u.a. die E-Mail Adresse, die IP, den Namen, den Inhalt des Kommentars, die UserID von angemeldeten Usern, Serverdaten und und und. Aus dem langen Streit wissen wir, das IPs personenbezogene Daten sein können, E-Mail Adressen und Namen sicherlich und die Kombination von alle dem sowieso. Nach dem hohen deutschen (bzw. europäischen) Datenschutzniveau stellt sich daher die Frage, ob die Übermittlung an Akismet überhaupt rechtens ist.

Dabei kommen nach dem BDSG eigentlich nur 2 Konstellationen in Betracht:

1. Auftragsverarbeitung
2. Oder eine Übermittlung die nach §§ 28-30 BDSG gerechtfertigt ist.

1. Auftragsverwaltung

Eine Auftragsverwaltung liegt etwa im klassischen Outsourcingfall vor. Originäre Aufgaben eines Unternehmens werden an ein anderes ausgelagert. Das ursprüngliche Unternehmen bleibt aber bei dem ganzen Prozess Herr der Daten. Akismet errechnet für den jeweiligen Blogbetreiber, ob es sich bei dem abgegebenen Kommentar um SPAM handelt oder nicht. Von daher könnte man auf die Idee kommen, dass es sich um einen Fall der Auftragsdatenverarbeitung handelt. Doch die Daten, die von den Kommentaren an Akismet gesendet werden, werden dort mit Daten von anderen Webseiten vermengt. Es ist daher keine reine Auftragsdatenverarbeitung.

2. Übermittlung nach §§ 28 ff BDSG

Bliebe also die normale Datenübermittlung nach BDSG. Diese ist zunächst in § 28 Abs. 1 BDSG geregelt. Dafür müsste aber zunächst einer der drei Fälle vorliegen. Als solches kommt eigentlich nur Nr. 2 in Betracht. Die SPAM Bekämpfung dürfte jedenfalls ab einem gewissen Ausmaß und Bekanntheit des Blogs die Wahrung eines berechtigten Interesses sein. Jedoch ist eine Übermittlung nur dann zulässig wenn keine schutzwürdigen Interessen des Betroffenen vorliegen. Im vorliegenden Fall werden die Daten in die USA übermittelt. Die USA hat kein von der EU anerkanntes Schutzniveau. Daher wird nach § 4b BDSG in diesem Fall der Spieß umgedreht. Es liegen keine schutzwürdigen Interessen des Betroffenen vor, die einer Übermittlung entgegenstehen, wenn eine entsprechendes Datenschutzniveau nachgewiesen wurde.

Dies wäre etwa der Fall, wenn Automattic dem Safe-Harbor beitreten würde.

Sofern ich also mit meiner Beurteilung richtig liege, ist die Übermittlung der Kommentardaten durch das Akismetplug-in in die USA datenschutzrechtlich höchst problematisch. Die Konsequenz wäre übrigens, dass eine Datenschutzbelehrung nicht ausreichen würde, die Übermittlung wäre dann nur noch mit ausdrücklicher Einwilligung möglich.

Ein mulmiges Gefühl war es dann doch, als keine Fehlermeldung mehr kam sondern Safari anfing länger laden. Was würde passieren? Würde es klappen? medien-gerecht in den Orkus reißen?

Es hat geklappt. Aber als halber Kontrollfreak finde ich die Informationen bei und nach dem  Update etwas dürftig. Da könnte mehr kommen.

Die neue Symbolleiste und die generelle Aufarbeitung in WordPress 2.7 finde ich sehr gelungen. Ich bin freue mich auf die endgültige Version und bin gespannt, wie sich WordPress in den nächsten Major-Releases entwickeln wird.

Nun strukturiert sich das Team um, das Projekt wird nun nicht mehr von Einzelpersonen (in Form einer GbR) geführt, sondern von einer neu zu gründenden Inpsyde GmbH (dessen Name so unaussprechlich ist, dass allein deshalb Erfolg zweifelhaft erscheint). Das Team spricht von Veränderung und untragbarer Verantwortung. 

WPD ist in der Vergangenheit schon mit dem Versuch, möglichst viel Profit zu ziehen (mit einem eingeschleusten Werbeplugin), in der Community auf Missfallen gestoßen. Als Folge entstand eine neue, offizielle, deutsche Sprachversion von WordPress. Die Änderung der Rechtsform von einer GbR mag sinnvoll sein, da die persönliche Haftung reduziert wird. Doch die Wahl einer GmbH zeigt, dass WPD künftig kein Communityprojekt mehr sein will, sondern ein profitables Unternehmen.

Ob die Rechnung aufgeht?

Hier läuft WordPress 2.5 jedenfalls ohne größere Probleme. Der neue Tellerand ist zwar gewöhnungsbedürftig, doch schon vor dem Erscheinen der neuen Version wurden auch schon verbesserte Versionen des Admin-Themes veröffentlicht.

Mit dem Update funktioniert nun auch die WYSIWYG-Eingabe am Mac mit Safari. Der Tellerand ist darüberhinaus deutlich konfigurierbarer geworden. So lassen sich die “eingehenden Links” nun frei bearbeiten (auch wenn es mir bislang nicht gelungen ist, die technorati-Links korrekt einblenden zu lassen). Alles in allem ein sehr vielversprechendes Update.

Die deutschsprachige Version von WordPress 2.3 kann hier heruntergeladen werden.