Category: Wordpress


Emanzipation

Frauen in Spielstätten: Endet die Emanzipation am Automaten? Repräsentative Umfragen haben zu dem erschütternden Ergebnis geführt, daß in Deutschlan das Spielpublikum zu 83 Prozent aus Männern besteht. Die Gründe sind rätselhaft. Eine Lösung dieses Rätsels könnte unserer Branche nützlich sein, um ein riesiges brachliegendes Marktsegment zu erschließen

Schön, dass ich noch einmal lerne, was das Wort „Emanzipation“ für gewisse Zeitgenossen bedeutet: Einfach nur die „Erschließung eines weiteren Marktsegmentes“.

Quelle des Scans: Automatenmarkt, Das Fachmagazin für den erfolgreichen Automatenunternehmer, Jahrgang 1996

Werbeanzeigen

Die alfabetische Sortierung

Wir müssen den alten Römern ja wirklich dankbar für ihr Alfabet sein. Diese zweihalb Handvoll Symbole, die einfach in eine bestimmte, recht willkürliche Reihenfolge gebracht wurden, ermöglichen uns heute eine einfache Anordnung des gesamten Vokabulares in einer eindeutigen Reihenfolge. Man möchte gar nicht darüber nachdenken, wie umständlich die Benutzung eines Telefonbuches oder eines anderen Nachschlagewerkes in China sein wird und wieviel Übung und Mühe das Nachschlagen wohl dort erfordert, wo das logographische Schriftsystem nicht mit diesem kleinen, uns im Alltag wohlvertrauten Vorzug ausgestattet ist.

Aber die alten Römer sprachen leider eine Sprache, die nur wenig verschiedene vokalische Phoneme kannte, und deshalb genügten ihnen beim Schreiben fünf Vokalzeichen: „A“, „E“, „I“, „O“ und „U“. Dort, wo man als späte Nachwirkung der militärischen, wirtschaftlichen und kulturellen Vorherrschaft des imperium romanum das lateinische Alfabet auch für die lokalen Sprachen übernahm, reichte dieser Zeichenvorrat für Vokale oft nicht hin. Die Engländer haben sich beholfen, indem sie unter ausschließlicher Benutzung dieser fünf Zeichen eine irreguläre Orthografie entwickelten, die für jeden Lernenden eine Qual ist (an der niederländischen Sprache kann man übrigens ein Beispiel dafür sehen, dass sich dieses Problem in besserer Weise lösen lässt), die meisten anderen Sprachräume in Europa haben einen Wust von Sonderzeichen entwickelt, um den lokalen Vokalreichtum auf die lateinische Schrift abzubilden.

So auch die Schreiber des Deutschen mit ihren fröhlichen Pünktchen über den Vokalen, den Umlauten.

Für die Verarbeitung textueller Information mit Computern waren diese Sonderzeichen schon immer ein Albtraum. In der Anfangszeit waren solche Zeichen gar nicht im ASCII-Zeichensatz vorgesehen, und beim Schreiben loeste man dieses Problem durch Aufloesung der spezifisch deutschen Zeichen in jene Diphthonge, die urspruenglich einmal zu den heutigen Zeichen gefuehrt haben — ja, das ist lange her. Später wurde zum Glück alles besser, zwar nicht in der deutschen Rechtschreibung, wohl aber in der Verarbeitung deutschen Textes mit einem Computer.

Inzwischen ist beinahe jedes Rechnersystem Unicode-fähig, so dass sich der Zeichenvorrat beinahe sämtlicher Sprachen dieser Welt damit erfassen lässt. Aber etwas vom alten Chaos schimmert immer wieder durch, zum Beispiel auch, wenn WordPress die Links in der Blogroll alfabetisch sortiert und dabei auf die nicht recht nachvollziehbare Idee kommt…

Ein Ü liegt also alphabetisch zwischen A und B...

…dass der deutsche Umlaut „Ü“ weder einem „U“ noch der Entsprechung „UE“ gleichzusetzen ist, sondern in der Reihenfolge zwischen dem „A“ und dem „B“ erscheint.

Ach ja, willkommen in der Blogroll, überlebt! 😉

Übers Bloggen (16): Umzug

Der Umzug von einem privat gehosteten Blog nach WordPress.com ist ein schmerzhafter Umzug. Dies gilt auch denn, wenn die technische Seite eines solchen Umzuges relativ problemlos war. Diese besteht einfach darin, die Beiträge des alten Blogs zu exportieren, das neue Blog bei WordPress.com anzumelden und die Exportdatei dort wieder zu importieren. Der Vorgang braucht zwar angesichts der immensen Textmenge, die sich über zweieinhalb Jahre angesammelt hat, recht viel Zeit, aber er funktioniert trotz der verschiedenen WordPress-Versionen völlig fehlerfrei. Ich hätte Schlimmeres befürchtet. (Erfahrung ist eben die Summe von Misserfolgen.)

Damit sind zwar die alten Texte „gerettet“, haben ihre Stimme im Netz behalten, aber die Freiheiten, die ich in den letzten Jahren zu schätzen gelernt habe, sie sind verloren gegangen. Das fängt bereits in der Präsentation an, ohne sich darauf zu beschränken, denn ich kann jetzt nicht mehr mein eigenes Theme verwenden, sondern muss mit den hier angebotenen Themes vorlieb nehmen. Diese passen nicht gut zu meinem bisherigen Stil eines „hellen dunklen“ Erscheinungsbildes, und ich entschied mich deshalb lieber für einen Bruch, für schlichtes Schwarz auf Weiß. Es sieht für mich kalt und kahl aus, erinnert mich an jene Zeiten, in denen ich noch wohnhaft war und nach einem Umzug vor einer leeren Wohnung voller Kartons saß, um in den weißgetünschten Wänden zu ersticken. Nur, dass das hier ein Dauerzustand bleiben wird. Immerhin konnte ich ein eigenes Bild im Kopfbereich des Blogs setzen, und da entschied ich mich nach längerem Nachdenken für ein Motiv, das mir im letzten Jahr vor das Objektiv geriet: Die Fassade einer Mietskasene im warmen Abendlicht, Balkon an Balkon gleichförmig in Reih und Glied, und ein Bewohner meinte in diesem Umfeld, die Vorzüge seines Deutsch-Seins dadurch zeigen zu müssen, dass er ein kleines Fähnchen im stinkenden Wind wehen ließ. Es ist ein deprimierendes Bild, wie aus einer Emigration, nur, dass hier nicht das Land verlassen wurde. Ebenfalls deprimierend ist es, dass so viele Menschen in der BR Deutschland auf den persönlichen Schaden in ihrem Leben reagieren, indem sie in Symbole flüchten, die ein gesellschaftliches Gefüge repräsentieren, dass ihrem Leben eben diesen Schaden zugefügt hat.

Die umgezogenen Texte sind übrigens ebenfalls beschädigt. Alle internen Links verweisen auf die alten Adressen und funktionieren hier nicht mehr.

Auch ist mir jede Freiheit in den verwendeten Plugins genommen. Hatte ich zuvor eine „dynamische Blogroll“, die auf einen als Plugin eingebetteten RSS-Aggregator aufbaute und zeigte, an welchen Stellen etwas aktuell veröffentlicht wurde, so bleibt mir jetzt nur die Blogroll in Form einer schlichten, alphabetisch sortierten Linkliste. Auch für jene Handvoll Leser, die gern und regelmäßig durch den Aggregator gestöbert hat, ist das schade. Hier kann ich nichts vergleichbares machen, und einen technisch minderwertigen Ersatz will ich gar nicht erst versuchen.

Dass ich jetzt nicht mehr über einen Shell-Zugang auf dem Server verfüge, der meine Texte in das Netz trägt, ist für mich ebenfalls ein Problem. Ich bin es gewohnt, einen regelmäßigen Backup zu automatisieren, um im Falle schwerer Pannen das Schlimmste verhindern zu können, und diese Gewohnheit hat mir schon einmal den Hals gerettet, als ein Cracker mit einem Angriff auf ein harmloses und wenig gelesenes Blog erfolgreich war.

Darüber hinaus fühle ich mich etwas unwohl, weil das Blog nun in fremden Händen liegt. Ich weiß nicht, was die Zukunft aus WordPress.com machen wird, und es kann sein, dass dieses Angebot irgendwann einmal für mich unzumutbare Auflagen haben wird oder mir Kosten verursachen wird, die ich als obdachloser Bettler nicht mehr tragen kann. Immerhin sind Blogs bei WordPress.com schon seit einer erheblichen Zeit werbefrei geblieben, es scheint also so zu sein, dass sich WordPress.com mit seinen kostenpflichten Erweiterungen für kostenlose Blogs gut selbst trägt. Dennoch: Auch hier kann der allgemeine Zusammenbruch der Wirtschaft zum Tragen kommen, und der erste Umzug könnte für mich schnell der Beginn eines virtuellen Nomadenlebens werden, das sich dann endlich an mein nicht-virtuelles Leben angepasst hätte. Das ist keine beruhigende Vorstellung. Aber es ist — wenn es so kommt — nicht zu ändern. Ich habe mich längst daran gewöhnt, als ein Vorübergehender zu leben. Sobald hier das erste gelayerte Werbebanner aufscheint, bin ich weg.

Das Schlimmste nach dem Umzug ist wohl aber, dass es nun Monate dauern wird, bis alte Links auf anderen Websites korrigiert sind. Die Tatsache, dass diese frisch belegte Wohnung in einem Ausland, in dem die Freiheit des mitgeteilten Wortes noch einen Wert hat, bei Google und Konsorten noch nicht bekannt ist, verschlimmert diese Situation zusätzlich, denn die umgezogenen Texte können für eine längere Zeit nicht einfach aufgefunden werden. Diese Situation wird sich wenigstens im Laufe der nächsten Wochen verbessern.

Neben diesen bedrückenden Dingen gibt es da noch die kleinen Ärgernisse. Ich kann keinen Einfluss auf die hier verwendete WordPress-Version nehmen, und natürlich ist es die aktuellste. Diese ist leider — anders als meine von Hand gepflegte, uralte Version im vorherigen Blog — eine Bloatware, eine mit Unmengen von JavaScript realisierte Anwendung, die im Browser laufen soll, die aber auf den schmalbrüstigen und alten Geräten, auf die ich in der Regel zurückgeworfen bin, nur noch zäh zu bedienen ist. Das bedeutet, dass ich mich nur noch sporadisch einloggen werde und meine Veröffentlichungen in der Regel mit einem Blogclient verfasse. Deshalb kann es immer wieder einmal vorkommen, dass ein nicht erkannter Spamkommentar hier für längere Zeit stehen bleibt oder ein falsch erkannter echter Kommentar eines „richtigen“ Lesers im Nichts verschwindet. Beides habe ich früher vermeiden können, es ist mir jetzt nicht mehr möglich.

Um die Kommentare in dieser Situation überschaubar zu halten, ist das Blog im Moment so konfiguriert, dass nur Kommentare zu Texten möglich sind, die nicht älter als 60 Tage sind. Auf der anderen Seite ist die Kommentarfunktion jetzt verbessert. Die Kommentare sind in Threads organisiert, so dass eine direkte Antwort auf einen anderen Kommentar möglich ist. Meine alte Bastelei im Kommentarbereich ist damit unnötig geworden, weil sie durch etwas Besseres ersetzt wurde.

Bleibt nur zu hoffen, dass ich so schnell nicht wieder umziehen werde… 😉

WP-Plugins: Ich höre auf!

Wer häufiger in dieses kleine und weit gehend unbedeutende Blog schaut, weiß, dass es hier alles ohne Werbung, kostenlos und frei (unter Piratenlizenz oder — im Falle der Musik — unter einem ebenfalls recht freien Lizenzmodell, das lediglich die gewerbliche Verwendung der Werke verhindern soll, gibt). Ich halte nichts davon, aus jeder Kommunikation einen sozial optimierten Geschäftsvorgang zu machen.

Zur Freiheit meiner Veröffentlchungen gehört für mich auch eine Haltung, dass ich meine paar eigenen Programmierungen im Rahmen dieses Blogs anderen zur Verfügung stelle, so weit dies problemlos möglich ist. Ich bin der Meinung, dass alle Menschen von einer solchen Haltung des freien Gebens und Nehmens profitieren können. In der Praxis mache ich aus kleineren Programmierungen dann Plugins für WordPress, die ich unter freien Lizenzen zur Verfügung stelle, damit möglichst viele Menschen davon profitieren können, und ich mache mir ferner die (geringe) Mühe, diese Plugins leicht in andere Sprachen übersetzbar zu gestalten und selbst zweisprachig (in deutsch und englisch) zu veröffentlichen, damit sie von größtmöglichem Nutzen sind.

So ist etwa der kleine Besucherzähler in der Seitenleiste…

So sieht dieser Zähler im Moment aus...

…ein WordPress-Widget, das hier jeder herunterladen, an seine eigenen Bedürfnisse anpassen und unter den Bedingungen der GNU/GPLv2 verwenden kann. Ich habe diesen Zähler zu einer Zeit programmiert, in der es zwar jede Menge teils recht aufwändiger Plugins für Statistiken aller Art gab, aber keinen schlichten, einfachen Zähler, der wenig Resourcen benötigt und für den Bloggenden leicht zu verwenden war — und ich hatte dabei auch im Hinterkopfe, dass einige Anbieter unter dem Deckmäntelchen der an sich recht lächerlichen Dienstleistung einer schlichten Besucherzählung SEO-Spamlinks in die Blogs einbetten oder gar ein Blog mit penetranter und gewaltsamer Reklame vergällen. So etwas ist wohl in der Regel unerwünscht, und solchen meines Erachtens schäbigen „Geschäftsmodellen“ wird am wirksamsten begegnet, indem freie Alternativen geschaffen werden, die jeder Bloggende ohne derartige Seiteneffekte verwenden kann.

Dieses sehr kleine Widget habe ich auch in die Plugin-Datenbank von WordPress eingetragen, weil es darin noch nichts Vergleichbares gab. Auf diese Weise lässt sich das Widget von interessierten Bloggern sehr viel leichter finden als etwa mit einer Google-Suche, die doch leider eine Flut derjenigen kommerziellen Angebote hervorspült, die eigentlich mit einem solchen Widget umgangen werden soll. Natürlich wurde es auch häufiger hier heruntergeladen…

So weit, so gut.

Es ist natürlich nicht so, dass jede kleine Programmierung von mir fehlerfrei wäre. Ganz im Gegenteil, es gibt keine Sache, die so einfach ist, dass ich sie nicht falsch machen könnte — und so lange ein Fehler nicht bei mir auftritt, bemerke ich ihn nicht einmal. Dafür finden ihn dann andere Benutzer meines Gestrokels, und bei mir häuften sich im Laufe der Zeit kleine Fehlerberichte für ein Stück Code, das in diesem Blog ganz hervorragend funktioniert. Es herrschte also ein gewisser Handlungsbedarf.

Vor ein paar Tagen habe ich mich „erbarmt“ und den (relativ kleinen) Fehler behoben. Es hat ein bisschen gedauert, weil ich nicht immer (und oft für viele Wochen gar nicht) eine brauchbare Arbeitsumgebung habe, und weil ich anfangs den Hinweisen wenig technikaffiner Menschen nicht entnehmen konnte, an welcher Stelle mein Fehler genau liegt. Nachdem ich den Fehler dann aber doch verstanden hatte, stand er noch für etwa fünf Monate unter vielen anderen Dingen in meiner großen TODO-Liste, und leider waren die anderen Dinge oft ein bisschen drängender — von den üblichen, niemals planbaren Unwägbarkeiten des Lebens, die zusätzlich dazwischen kommen, muss ich hoffentlich keinem Lebenden etwas erzählen. Aber irgendwann komme ich eben auch einmal dazu, das zu tun, was ich mir vorgenommen habe, und jetzt ist der Fehler draußen.

Es ist klar, dass ich die neue Version auch gleich in die Plugin-Datenbank eingetragen habe, damit niemand mehr die fehlerhafte alte Version herunterlädt.

Wenn man eine neue Version für ein halbwegs populäres WordPress-Plugin in diese Plugin-Datenbank bringt, wird darüber im halboffiziellen Blog „Weblog Tools Collection“ berichtet. [Dieses Blog, das Bloggende dazu auffordert, sich mit eingeblendeteter Reklame und eingebetteten Spamlinks für die Suchmaschinen ihr Schreiben „bezahlen zu lassen“, wird von mir bewusst nicht verlinkt.] Die aktuellen Einträge dieses Blogs werden im Dashboard (ich finde dieses Wort immer noch fürchterlich) jedes WordPress-Blogs sichtbar. Das ist durchaus begrüßenswert, da so jeder über Neuentwicklungen und neue Versionen bestehenden Codes informiert wird. Und es ist auch gar nicht überraschend, dass die Veröffentlichung einer neuen Version deshalb zu zwei Tagen mit deutlich erhöhten Zugriffszahlen führt, da sich eben viele Menschen die neue Version herunterladen — gar kein Problem, genau deshalb veröffentliche ich sie ja.

Wenn das alles kein Problem ist, warum erzähle ich das alles in solcher Breite, fragt sich jetzt vielleicht der eine oder andere Leser.

Ganz einfach: In Folge der Veröffentlichung einer neuen Version meines kleinen und recht unwichtigen Widgets hatte ich (bis jetzt) 232 SEO-Spamkommentare, die mir von irgendwelchen Fäkalmaden in dieses bewusst werbefreie Blog gerotzt wurden. Der einzige Zweck dieser „Kommentare“ bestand darin, äußerst fragwürdige Blogimitate und Websites mit teilweise kriminellen Angeboten mit ein paar ausgewählten Schlüsselwörtern für Google und andere Suchmaschinen innerhalb dieses Blogs zu verlinken, um auf Seiten der Suchmaschinen das Ranking zu manipulieren und so dafür zu sorgen, dass diese Drecksseiten in den Ergebnislisten weiter oben positioniert werden.

Auch, wenn ein recht großer Teil dieser Pest automatisch erkannt wird, macht mir so etwas eine immense Arbeit — und die nicht erkannten, teils „liebevoll“ von Hand geschriebenen Schrottkommentare mussten natürlich händisch von mir gelöscht werden. Oder anders gesagt: Ich kam einen ganzen Tag lag nicht vom Rechner weg, weil ich dieser Seuche des modernen Internet in meinem kleinen und größtenteils harmlosen Blog nicht den geringsten Raum zu geben gedenke.

Unter der Bedingung solcher Zustände erachte ich es im Moment nicht mehr als tragbar, weitere Verbesserungen oder spätere Neuentwicklungen an dieser Stelle zu veröffentlichen. Wenn das einfache Veröffentlichen eines kleinen Stücks Codes, das einige Menschen nützlich finden, dazu führt, dass gewisse Verbrecher und zwielichtige Gestalten mein Blog als eine Plattform für ihr verachtenswertes Treiben missbrauchen, denn sehe ich mich völlig außerstande, ein solches kleines Stück Code in Zukunft zu veröffentlichen. Ich habe nämlich auch noch ein richtiges Leben, jenseits des Internet. Und. Die alltägliche SEO-Spam in diesem Blog ist schon schlimm genug.

Deshalb wird es hier in Zukunft niemals mehr ein veröffentlichtes WordPress-Plugin von mir geben — und deshalb werde ich eventuelle Fehlerkorrekturen auch nicht mehr publizieren. Die einzige „Alternative“, die ich im Moment zu dieser Entscheidung sehe, ist eine abgeschaltete Kommentarfunktion. (Die auffallend ähnlich gestrickten Spamkommentare wurden keineswegs nur bei den Einträgen für das Widget hinterlegt, sondern sie wurden am Tage der Veröffentlichung über das ganze Blog gestreut, so dass die Abschaltung der Kommentare für einen einzelnen Beitrag wohl nicht wirksam wäre.) Und das wäre für mich keine Alternative, sondern eine Kastration der Idee des Bloggens — da könnte ich auch gleich aufhören.

Besucherzähler 1.2

Nachdem ich jetzt schon seit Monaten Fehlerberichte erhalte, dass die Version 1.1 meines WP-Widgets Besucherzähler im Zusammenhang mit einigen Themes zu Fehlern führt, habe ich mich mal erbarmt und meinen Fehler (ja, es war einer!) hoffentlich behoben. Die neue Version sollte — so weit ich das absehen kann — keine derartigen Probleme mehr bereiten.

Download-Link: WordPress-Widget Besucherzähler (Version 1.2)

Viel Spaß damit, und wenn noch ein Fehlerchen drin ist, sagt mir bitte Bescheid. (Es kann aber manchmal etwas dauern, weil ich nicht immer einen zum Arbeiten geeigneten Computer zur Verfügung habe.)

Mein früheres WordPress-Theme „Lichternacht“ hat in der Version 1.1 ein Problem mit den neueren WordPress-Versionen gehabt. Wenn man seine Beiträge mit dem WYSIWYG-Editor verfasste und die Bilder über den neuen Bilduploader einfügte, dann wurden die dort angegebenen Bildformatierungen nicht angewendet. Es war also nicht möglich, ein umflossenes Bild auf der linken oder rechten Seite des Textes zu platzieren.

Ich habe diesen Fehler nicht bemerkt, weil ich inzwischen ein anderes Theme verwende und weil ich den Upgrade auf die aktuellen WordPress-Versionen scheue wie der Teufel das Weihwasser — ich bin darauf angewiesen, dass sich mein Blog auch über einen „schmalbrüstigen“ Computer flüssig benutzen lässt, das ist mit den neuen Versionen nicht der Fall — habe ich dieses Problem nicht bemerkt. Nachdem ich von einigen Anwendern des Themes darauf angesprochen wurde, habe ich heute den Fehler analysiert und behoben. Die neue Version steht hier zum freien Download zur Verfügung.

Schnellupgrade

Im Theme hat sich nur eine Datei verändert, die style.css. Für jene, die das Theme bereits verwenden, ist es also möglich, nur diese Datei auszutauschen; deshalb wird sie hier auch zum freien Download gestellt.

Download-Link: Die style.css für den ganz schnellen Upgrade auf Lichternacht 1.2

Viel Spaß damit! 😉

WP-Plugin: Chrome Blocker

Wie bereits versprochen, ist hier mein frisches WordPress-Plugin, um Zugriffe auf ein WordPress-Blog mit dem als Browser getarnten Enteignungsversuch und Schnüffeltool namens „Chrome“ zu unterbinden.

Das Plugin steht zum freien Download und zur freien Benutzung zur Verfügung: Download des WordPress-Plugins ChromeBlocker (Version 1.0)

Das Plugin wurde mit den WordPress-Versionen 2.3.x und 2.5.x getestet, es sollte auch ohne Probleme mit dem aktuellen WordPress 2.6.1 laufen.

Screenshot der FehlerseiteDie Funktion des Plugins ist sehr einfach. Jedes Mal, wenn mit einem Browser auf das Blog zugegriffen wird, dessen User-Agent die Zeichenkette „Chrome“ enthält, wird anstelle der angeforderten Seite des Blogs eine Seite mit einer deutlichen Meldung in deutscher und englischer Sprache ausgegeben. Um meine Meldung und ihr Design zu sehen, einfach einmal auf das kleine Bildchen auf der linken Seite klicken. Im oberen Bereich wird natürlich der eingestellte Titel des Blogs stehen.

Diese Meldung ist einer eigenen Datei namens message.php abgelegt, sie kann leicht mit normalen HTML-Kenntnissen an andere Bedürfnisse angepasst, übersetzt oder in einen anderen Stil gebracht werden.

Die Installation des Plugins ist einfach:

  1. Download des WordPress-Plugins ChromeBlocker (Version 1.0).
  2. Entpacken des ZIP-Archives mit dem jeweiligen Lieblingsprogramm für diesen Zweck
  3. Im Ordner chromeblocker liegt eine Datei message.php, diese kann beliebig angepasst werden, wenn eine andere Meldung gewünscht ist
  4. Den ganzen Ordner chromeblocker in die WordPress-Installation, in das Verzeichnis wp-content/plugins hochladen.
  5. Im WordPress-Dashboard, in der Plugin-Verwaltung das Plugin aktivieren.
  6. Ab sofort sind Leser mit dem Chrome-Browser ausgesperrt, wenn diese nicht ihren User-Agent über einen Proxy verändern lassen. (Das machen eher wenige Menschen, und diesen Menschen ist auch ansonsten ein gewisser Verstand in der Internet-Nutzung zuzutrauen.)

Google is evil

Anatomie eines Angriffes

In den letzten Tagen wurden verschiedene Projekte auf diesem Server — unter anderem auch dieses Blog — massiv durch einen destruktiven Zeitgenossen angegriffen. Zum Glück ist es mir gelungen, diese Angriffe abzuwehren, ferner habe ich die Vorgehensweise des Angreifers an Hand der Logdateien analysieren können. Dies ermöglicht es mir auch, Empfehlungen für andere Blogger auszusprechen, die WordPress verwenden. Der Text wird etwas länger, aber meines Erachtens für viele Menschen interessant. Ich werde versuchen, die technischen Details so gut wie möglich zu erklären, aber natürlich bin ich wegen meiner im Laufe von einigen Jahrzehnten gewachsenen Kompetenz oft ein bisschen blind für die Probleme gewöhnlicher Anwender — meine eigene Anfängerphase ist inzwischen gründlich verdrängt.

Der Schaden

Vor zwei Tagen, am 18. Juli, bekam ich in der sehr vorgerückten Nacht einen recht heftigen Schreck. Zwei der Projekte — es handelt sich ebenfalls um WordPress-Blogs — die auf diesem Server gelagert sind, waren von einem Cracker mit einem völligen Defacement und ein paar dummen Sprüchen in haarsträubend miserablen Englisch „verziert“ worden. Mein Schreck war so groß, dass ich sogar vergaß, einen Screenshot für die spätere Dokumentation anzufertigen. Ja! Sogar meine heitere Stimmung war für eine gute Minute lang ein wenig getrübt. 😉

Auf diesem Server kann ich mich fast beliebig austoben, es handelt sich eigentlich um den manchmal etwas widerspenstigen Streaming-Server eines Webradios, den ich „nebenbei“ administriere, weil es niemand anders gut kann. Deshalb kann ich mich über ssh — das ist eine sichere Verbindung, die das Arbeiten an der Kommandozeile gestattet — am Server anmelden und darauf arbeiten. Genau das war auch nach einer kleinen Schrecksekunde meine erste Tat, um den angerichteten Schaden genau in Augenschein nehmen zu können.

Was ich dort sah, entzückte mich nicht besonders. Die Dateien der beiden stark betroffenen Blogs waren teilweise zerstört, hochgeladene Dateien wurden entfernt und in einem dieser Blogs wurde zusätzlich die gesamte Datenbank gelöscht. Andere Projekte waren weniger betroffen, aber völlig unversehrt war keines.

Die folgenden Erläuterungen sollen anderen WordPress-Anwendern helfen, solche Schäden einzugrenzen oder zu verhindern.

Meine Vorsorge

Nun, ich hatte ein wenig Vorsorge gegen diesen schlimmsten anzunehmenden Unfall eines Website-Betreibers getroffen. Jedes unixoide System kennt einen Dienst namens cron, der es ermöglicht, beliebige Programme automatisch und regelmäßig auszuführen. Wer erfahren möchte, wie man diesen Dienst anwendet, setze einfach ein man crontab an der Kommandozeile ab. Über diesen Dienst lasse ich in jeder Nacht ein kleines Shellskript ausführen, das mir einen Schnappschuss der verwendeten Datenbanken in einem Verzeichnis auf diesem Server ablegt. Dieses Skript sieht übrigens so aus (Pfade, Datenbanknamen, den Namen des Datenbank-Servers und die Passwörter habe ich hier natürlich geändert, aber dennoch sollte jeder dazu fähig sein, sich so ein Skript an die eigenen Bedürfnisse anzupassen):

#!/bin/sh
prefix=/pfad/zum/backup/dir`date +%Y%m%d-%H%M`-
dbs="datenbank_1 datenbank_2 datenbank_3"
for i in $dbs
do
  mysqldump --add-drop-table \
            --comments \
            --compress \
            --create-options \
            --host=mein_hostname \
            --user=datenbank_admin_username \
            --password=datenbank_admin_password \
            --quote-names \
  $i | gzip -c >$prefix$i.sql.gz
done

(Ja, werter Experte, ich weiß, die Optionen für mysqldump kann man auch kürzer schreiben. Aber in solchen Skripten werde ich immer ein bisschen „geschwätzig“, da ich im Zweifelsfall auch unter Stress erkennen muss, was im Skript „abgeht“. Erfahrung ist übrigens die Summe von Misserfolgen, aber das ist ein ganz anderes Thema…)

Wichtiger Hinweis: Natürlich sollte man so ein Skript, in dem ein Passwort für den Zugang auf eine Datenbank hinterlegt ist, so ablegen, dass der Zugriff darauf nicht möglich ist. Es hat für niemanden außer seinen Benutzer lesbar, schreibbar oder ausführbar zu sein. Auch das Ausführen muss für andere User unterbunden werden, sonst könnte ein Angreifer dieses Skript ausführen und sich mit einem ps aux anschauen, wie die Kommandozeile mit dem Passwort aussieht. Und das soll er auf keinen Fall herauskriegen können.

Wegen dieser Vorsorge hatte ich einen Schnappschuss der betroffenen Datenbanken, der weniger als einen Tag alt war. Mit Hilfe dieses Schnappschusses habe ich beim am stärksten betroffenen Projekt auf der Stelle einen Notbetrieb ermöglicht. Dazu habe ich die Datenbank schnell wiederhergestellt, indem ich auf der Kommandozeile…

zcat sicherungsdatei.sql.gz |
mysql datenbank_name -u datenbank_admin_username -p

…absetzte, das Passwort des Datenbank-Admins eingab und im Dashboard des betroffenen und so wiederhergestellten Blogs sämliche User (das Blog wird von mehreren Leuten „befüllt“) auf „Registrierter Leser“ setzte und die Kommentarfunktion abschaltete. Ich wusste ja noch nicht, wie dieser Angriff ausgeführt wurde. Damit hatte zwar niemand mehr Schreiberlaubnis, aber die textuellen Inhalte blieben im Internet verfügbar.

Meine Vorsorge war also Gold wert.

Anmerkung für „blutige Laien“: Wenn man solche Sicherungen mit einem automatischen Verfahren macht, sollte man sich in regelmäßigen Abständen davon überzeugen, dass die Sicherung auch wirklich wie gewünscht abläuft und im Krisenfall brauchbar ist. Die einfachste Methode, dies zu tun, ist der Import des SQL-Dumps (so nennt man einen solchen Schnappschuss) in eine leere und unbenutzte Datenbank. Wenn dies ohne Fehlermeldung läuft, ist alles in Ordnung. Im Idealfall setzt man hierzu einen lokalen MySQL-Server auf seinem Arbeitsrechner auf. Für Linuxer ist das kein Problem, sie installieren einfach das entsprechende Paket ihrer Distribution. Wer Windows oder Mac OS benutzt, ist für den Hausgebrauch mit XAMPP bestens bedient.

Als nächstes schnappte ich mir die Logdatei des Webservers (ein Webserver dokumentiert jeden einzelnen Zugriff in einer fortlaufenden Textdatei) und legte mir eine lokale Kopie für die spätere Analyse an. Dann legte ich mich schlafen.

Ein besonderer Dank geht an M., die mir diese ersten Maßnahmen zur Eingrenzung des Schadens über ihre Telefonleitung und ein Modem (!!!) ermöglichte.

Ein weiterer Teil meiner Vorsorge betrifft das Verzeichnis auf dem Server, in dem WordPress läuft. Ich habe die Dateirechte in meinen Projekten alles in allem recht restriktiv vergeben, so dass die WordPress-Dateien nicht mit den Rechten des Webservers überschrieben werden können. Der Nachteil dieser Vorgehensweise ist es natürlich, dass ich niemals einfach aus dem WordPress-Dashboard eine Datei meines Themes editieren kann; der Vorteil ist jedoch, dass auch ein Angreifer das nicht kann. Mit Ausnahme des Upload-Verzeichnisses kann der Webserver auf alle Dateien nur lesend zugreifen. Auch diese Präventention hat sich im Nachhinein als wichtig erwiesen, sie hat nämlich verhindert, dass dieses Blog ebenfalls zerstört wurde. Aber dazu später etwas mehr…

Erste Gedanken und ein zweiter Schreck

Als ich am nächsten Morgen aufwachte, habe ich einen Kaffee getrunken und mir allerhand Gedanken gemacht. Ich setze hier ja eine etwas ältere WordPress-Version ein, ein 2.3.3 — da können natürlich jede Menge Fehler auf einen Menschen warten, der sie sich zunutze macht, um Teile eines Webservers zu übernehmen. Aber. Ich bin dabei auch sorgsam und habe ein Auge auf alle Sicherheitsmeldungen. WordPress 2.3.3 hat viele kleine Schwächen, aber bislang noch keine, die so arg ist, dass mir der Upgrade zu einer nicht funktionierenden Bloatware wie WP 2.5 erforderlich schien.

Nun hatte ich erhebliche Selbstzweifel wegen dieser Entscheidung. Was. Wohl jedem verständlich sein sollte.

Als ich dann beim ersten Blick auf das im Notbetrieb laufende Projekt feststellen musste, dass die Inhalte durch eine weiße Seite ersetzt wurden, wuchsen meine Selbstzweifel ob dieses Schreckes sogar noch an. Ich musste mir ganz schnell anschauen, was da auf dem Server los war. Aber zunächst verfasste ich einen quicken Hinweis an die Leser dieses Blogs, damit sie einen eventuellen Missbrauch durch einen Cracker richtig einschätzen können.

Eine Randnotiz: Es ist übrigens keine Schande, wenn man „gehackt“ wird, und niemand muss sich dafür schämen. Jeder Rechner, der permanent am Internet hängt, ist immer auch ein Opferrechner, der diversen Angriffsversuchen aller Art ausgesetzt ist. Und manchmal wird aus einem solchen Versuch auch ein erfolgreicher Angriff. In einem solchen Fall halte ich es — gerade, wenn man eine große und treue Lesergemeinschaft hat — für besser, offensiv an die Öffentlichkeit zu treten, bevor manipulierte Inhalte auf der Website einen völlig unerwünschten Eindruck hinterlassen können. Wenn immer es irgend möglich ist, sollte ein stummes Abschalten vermieden werden.

Die Analyse

Danach schaute ich mich wieder über ssh auf dem Server um und analysierte die gesicherten Logdateien. Die Verfahren, die ich bei der Analyse anwandte, sind nicht leicht zu beschreiben und würden einen technischen Laien überfordern. Was aber jeder kann, ist, die Logdatei in einem Texteditor zu öffnen und nach verdächtigen Aktivitäten Ausschau zu halten — die Suchfunktion des Editors kann dabei eine große Hilfe sein.

In meinem Fall stellte ich zwei hoch verdächtige Aktivitäten fest. Zum einen gab es über Stunden hinweg jede Sekunde drei Versuche, sich durch Zugriff auf die Datei wp-login.php in WordPress einzuloggen. Nachdem diese Aktivität aufhörte, wurden nach einer Pause von ca. 15 Minuten verschiedene PHP-Dateien über die Upload-Schnittstelle (die in der Regel zum Einfügen von Bildern verwendet wird) hochgeladen, die anschließend ausgeführt wurden. Hier hat jemand ein schwaches Passwort und ein vorhandenes Problem in der Konfiguration ausgenutzt und einen Webserver nach allen Regeln der Kunst „geowned“…

Die vielen Login-Versuche deuten darauf hin, dass der Angreifer eine Wörterbuch-Attacke gegen das angegriffene Blog gefahren hat. Tatsächlich wurden von mehreren Autoren die Login-Namen als Anzeigenamen sichtbar, so dass nur noch eine Jagd auf ein schlechtes Passwort erforderlich war, die dann irgendwann auch Erfolg hatte.

Natürlich wurden die IP-Adressen anonymisiert, so dass auch eine Strafanzeige fruchtlos bleiben würde. (Zudem finde ich das Einschalten der Ermittler ein bisschen „unsportlich“.)

So weit, so schlecht.

Die erste hochgeladene Datei trug den Namen c99.php, über diese Datei wurde der Rest des Angriffes vorgetragen. Dieses c99.php ist eine recht vollständige, in PHP geschriebene Shell, mit deren Hilfe ein Angreifer ziemlich beliebig im Dateisystem und zusätzlich noch auf einem MySQL-Server rumpfuschen kann. Natürlich läuft diese Shell „nur“ mit den Rechten des Webservers, so dass nicht alles im Dateisystem geht — hier erwiesen sich meine restriktiven Dateirechte als richtig, und jede Schwäche in der Vergabe dieser Rechte wurde vom Angreifer recht erbarmungslos „abgestraft“, indem er über die c99.php weitere Skripten hochlud, die sich kein Mensch auf einen Webserver wünschen kann, und indem er diese Skripten auch ausführte.

Erläuterung für „normale“ Menschen: Eine „Shell“ ist ein Programm, das zum Start anderer Programme verwendet werden kann und seinem Anwender das Dateisystem eines Rechners zur Verfügung stellt. Der Angreifer konnte mit der hochgeladenen Shell auf diesem Server „arbeiten“, was er auch weidlich tat. Und „Skripten“ sind Programme, die in einer so genannten „Skriptsprache“, das ist eine interpretierte Programmiersprache, verfasst sind. Zum Beispiel ist WordPress eine recht komplexe Sammlung von Skripten.

Eines dieser Skripten war eine weitere Shell, die einen Socket öffnete und auf Verbindungen wartete. Über diese Shell hat der Angreifer weitergemacht, ohne Spuren in der Logdatei des Webservers zu hinterlassen — was es mir erschwerte, die Vorgehensweise des Angriffs zu verfolgen. Deshalb habe ich auch die gelegten Hintertürchen beim ersten Versuch nicht vollständig schließen können.

Noch eine Erläuterung: Ein „Socket“ ist ein TCP-Port, auf dem ein Programm wartet, um dort über das Netzwerk — in diesem Fall das Internet — Verbindungen zu akzeptieren und Eingaben zu verarbeiten. In der Regel wird das Programm auch Aktionen ausführen, das tat auch das kurz beschriebene Skript.

Was ich jedoch sicher weiß, ist, dass der Angreifer mithilfe der c99.php die Datenbank des angegriffenen Projektes gezogen hat und unter Umständen immer noch als lokale Kopie vorliegen hat. Hierzu hat er sich zunächst die wp-config.php angeschaut, die ja für den Webserver lesbar sein muss, da WordPress sonst nicht auf die Datenbank zugreifen könnte. Darin stehen unerfreulich klar die Zugangsdaten für die Datenbank, und mit Hilfe dieser Angaben konnte der Angreifer die Datenbank nach Belieben manipulieren.

Wichtige Randnotiz: Die Tatsache, dass sich ein destruktiver Zeitgenosse mit einem bisschen Glück über eine Wörterbuchattacke und einen einfachen Upload die Datenbank eines Blogs abgreifen kann, sollte jedem Blogger klar machen, dass die angegebenen Mailadressen der Kommentatoren in die Hände eines solchen Fieslings geraten können. Wer die Mailadressen seiner Leser nicht einem dahergelaufenen Kriminellen preisgeben möchte, sollte sie auch nicht dauerhaft in der Datenbank speichern. Natürlich funktionieren ohne Speicherung der Mailadressen die Gravatare nicht mehr, aber diese kleinen Bildchen sind wirklich keine unbedingt notwendige Funktion eines Blogs, und es ist mir völlig unverständlich, weshalb dieser gefährliche Anreiz zur unnützen Datenspeicherung zum Bestandteil des Kerns von WordPress 2.5 geworden ist — so etwas gehört meines Erachtens in ein Plugin für jene, die es unbedingt haben müssen. Unter dem Aspekt der Sicherheit gilt die Regel: Weniger ist mehr, und weniger unnütze Funktion ist mehr Sicherheit.

Der Angreifer hat in zäher Handarbeit versucht, weitere Rechte auf diesem Server zu erwerben, da er mit den Rechten des Webservers nicht allzuviel weiteres Unheil anrichten konnte. Zum Glück ist ihm das nicht gelungen. Diese Handarbeit hat ihm Stunden gekostet und war sehr ausdauernd. Das sollte jedem eine Warnung sein, der die Destruktivität mancher Zeitgenossen unterschätzt — als Lohn dieser Mühe wäre nur ein recht unbedeutender gehackter Server übernommen worden, auf dem ein paar recht harmlose und unbedeutende Blogs und ein Internetradio laufen. Sicherheit ist auch bei kleinen und relativ unbekannten Projekten wichtig.

Als der Angreifer die Nutzlosigkeit seines Treibens einsehen musste, hat er aufgegeben. Aber nicht, ohne so viel zu zerstören, wie ihm noch möglich war.

Weitere Klärung des Schadens

Da der Angreifer nur mit den Rechten des Webservers arbeiten konnte, war es relativ einfach, die von ihm angelegten Dateien und damit alle noch vorhandenen Hintertüren aufzuspüren, da sie allesamt dem technischen Benutzer www-data gehörten. Hierzu reichte es aus, die Dateien mit einem einfachen…

find . -user "www-data" | grep -v "upload/"

…an der Kommandozeile aufzuspüren und unschädlich zu machen. Dabei hat sich gezeigt, dass der Angreifer durchaus gute Ideen hatte, auf welche Weise Dateinamen „unverdächtig“ gemacht werden können. Von den gut 60 Dateien, die sich lustig über verschiedene Projekte verteilten, erhielten viele einen Namen, der in einer WordPress-Installation zunächst plausibel wirkt, zum Beispiel wp-find.php, wp-search.php oder wp-text.php. Ein unerfahrener Anwender hätte keine Chance gehabt, diese überall verteilten Hintertüren an ihren Dateinamen zu erkennen, und selbst ich kenne nicht jede Datei in den Tiefen eines WordPress namentlich.

Wer von einem ähnlichen Angriff betroffen ist und nicht auf der Stelle vesteht, was ich mit der Phrase vom „technischen User www-data“ meine, sollte besser seine gesamte WordPress-Installation löschen (natürlich mit Ausnahme der Konfiguration und der wirklich eigenen Uploads) und die Dateien neu aufspielen. In jedem Fall im Upload-Verzeichnis nach verdächtigen Dateien mit der Endung .php, .phtml, .cgi, .pl oder ähnliches suchen und diese Dateien löschen.

Abschließendes

Zunächst bedanke ich mich bei dem teilweise erfolgreichen Angreifer für seine Mühe, mir eine kostenlose Sicherheitsschulung zu geben. 😉 Nach dem Schließen der letzten hinterlegten Hintertür habe ich die ausgenutzten Schwachstellen in den betroffenen Projekten beseitigt, so dass der gleiche Angriff nicht noch einmal möglich ist. Ein wirklich planvoller Mensch, der es darauf anlegt, unentdeckt zu bleiben, hätte über diese Lücken längere Zeit auf diesem Server arbeiten können, ohne dass mir dieser Angriff aufgefallen wäre. Zu meinem Glück strebte der Angreifer nicht danach, eine langfristige Strategie mit Geduld zu verfolgen, es ging ihm „nur“ um Zerstörung.

Natürlich habe ich mir die kleine Mühe gemacht, alle Passwörter zu ändern, die in verschlüsselter Form in der Datenbank enthalten waren. So kann der Angreifer auch mit den spärlichen Informationen, die er sich unterm Nagel gerissen hat, nicht viel anfangen. Die betroffenen Benutzer sind informiert, dass sie gegebenenfalls ihr Passwort auch an anderen Stellen ändern, falls sie dort das gleiche verwenden. Der Angriff war also oberflächlich erfolgreich, immerhin wurde für gut 40 Minuten ein Defacement auf einer Website sichtbar, die nachfolgend noch einmal für ein paar Stündchen verschwand, auch ist die Zerstörung hochgeladener Dateien geglückt; aber diesem „Erfolg“ steht keinerlei ausbeutbare Nachhaltigkeit gegenüber.

Was allerdings einen Menschen bewegt, zehn Stunden Arbeit für ein dermaßen ärmliches und dümmliches „Ergebnis“ zu investieren, gehört einem Seelenleben an, das mir völlig fremd und unverständlich ist. :mrgreen:

Im Folgenden gebe ich noch ein paar Hinweise, wie ein solcher Angriff sicher abgewehrt werden kann.

Wie man einen solchen Angriff abwehrt

Sichere Passwörter verwenden

Der Angreifer hat über eine Wörterbuchattacke Gelegenheit gefunden, sich in das Blog einzuloggen. Jedes Passwort, dass aus einem regulären Wort mit ein paar Ziffern oder Sonderzeichen daran besteht, ist gefährlich. Wenn der Angreifer Autorenrechte erhält, kann er schon eine Datei hochladen, was fürchterliche Konsequenzen haben kann.

Login-Namen nicht anzeigen

WordPress hat die angenehme Eigenschaft, dass der angezeigte Benutzername vom Login-Namen abweichen kann. Wenn man davon Gebrauch macht, muss der Angreifer zwei Wörter erraten, was den Aufwand einer Wörterbuchattacke viel größer macht. Es ist sogar möglich, sein Login genau so kryptisch wie ein Passwort zu wählen, ohne dass diese Maßnahme beim Betrachten des Blogs auch nur erahnt werden kann.

Admin-Account löschen

Nach der Installation eines WordPress-Blogs entsteht ein Account mit dem Login-Namen admin, der volle Verwalter-Rechte im Blog hat. Dieser Account sollte unbedingt gelöscht werden, da dieser Benutzername sehr leicht zu erraten ist. Vor dem Löschen einen normalen Benutzer anlegen, der die erforderlichen administrativen Rechte hat, dann mit diesem Benutzer anmelden und den Standard-Administrator löschen. Das kostet nur eine Minute und kann einem Stunden der Nacharbeit in einem gehackten Blog ersparen.

Restriktive Dateirechte vergeben

Je weniger mit den Rechten des Webservers geschrieben werden kann, desto besser. Nach dem ersten Upload einer Datei wird ein Verzeichnis uploads unter wp-content angelegt, dies ist das einzige Verzeichnis, in dem der Webserver Schreibrechte benötigt. Alle anderen Verzeichnisse sollten auf 755, alle anderen Dateien auf 644 gesetzt werden und nicht dem User gehören, unter dessen Kennung der Webserver läuft. Dieser Funke Prävention hat bei meinem frisch erlebten Angriff viel Schaden verhindert, und alle Schäden tauchten dort auf, wo ich in der Rechtevergabe nachlässig war.

Datenbankerwägungen

Wann immer möglich, sollten sich nicht mehrere Projekte die gleiche Datenbank teilen, um einem erfolgreichen Angreifer nicht allzuviele Informationen preiszugeben. (Das ist in dieser Form nicht bei jedem Hoster möglich.) Für die Datenbank-Anmeldung von WordPress sollte ein eigener Benutzer eingerichtet werden, der nur lokalen Zugriff (Host: localhost) hat, falls die Datenbank auch extern erreichbar ist. In keinem Fall sollte jemals in der Konfigurationsdatei einer Webanwendung so etwas Wichtiges wie das Passwort des Datenbankadministrators stehen, sonst darf man sich nicht über große Schäden wundern.

Immer muss ein regelmäßiges und funktionierendes Backup von der Datenbank gemacht werden, um einen Verlust der Daten zu verhindern. Wie oft ein Backup angelegt wird, ist eine Frage der Änderungshäufigkeit und Aktualität des Blogs; wer nur einmal in der Woche postet, muss nicht jeden Tag ein Backup anlegen. Die Verfahrensweise beim Backup ist eine Frage der eigenen Vorlieben und des Geschmacks, für viele dürfte es ausreichen, regelmäßig einen Dump mit einem Tool wie PHPMyAdmin zu ziehen, andere werden etwas mehr wollen. Aber das Backup muss sein!

Verzeichniserwägungen

Es kann nicht verhindert werden, dass ein erfolgreicher Angreifer mit einem irgendwie ermittelten Login Dateien hochlädt, wenn er sich mit Autorenrechten anmelden kann. Aber es kann oft verhindert werden, dass PHP-Dateien im Upload-Verzeichnis ausgeführt werden. (Ob dieses Überschreiben der Konfiguration für ein bestimmtes Verzeichnis möglich ist, erfährt man bei seinem Hoster.) Hierzu einfach im Upload-Verzeichnis die folgende Datei .htaccess hinterlegen…

php_flag engine off
AddType text/plain .shtml .php .php3 .phtml .phtm .pl .py .cgi

…und schon ist das Ausführen von Dateien im Upload-Verzeichnis deutlich erschwert. Auch diese Maßnahme gewährt natürlich keine absolute Sicherheit, wenn der Webserver fehlerhaft konfiguriert ist und ausführbare Dateien einfach ausführt, denn die Extension spielt in unixoiden Systemen keine Rolle. In der Regel werden jedoch nur Dateien mit den hier angegebenen Extensions beim Zugriff über den Webserver ausgeführt. Diese relativ einfache Maßnahme könnte große Schäden im Ansatz vermeiden.

Ich würde mir übrigens sehr wünschen, dass zukünftige Versionen von WordPress diese Datei beim Erstellen des Upload-Verzeichnisses automatisch anlegen, wenn ein Überschreiben der Konfiguration möglich ist.

Die Tatsache, dass die Dateien im Upload-Verzeichnis bei einem Angriff gelöscht werden können, zeigt, dass ein regelmäßiger Backup dieses Verzeichnisses ebenso eine Notwendigkeit sein kann wie der Backup der Datenbank, da man sonst leicht viele Stunden Nacharbeit nach einem Angriff hat. Hier war ich ein wenig nachlässig, was dazu führt, dass ich gleich noch ein wenig zu tun habe. Auch hier ist die erforderliche Frequenz des Backups davon abhängig, in welchem Maße Bilder und andere Dateien hochgeladen werden. Wer als typischer Fotoblogger jeden Tag ein Foto hochlädt, sollte regelmäßiger die Daten sichern als jemand, der nur hin und wieder eine Datei an einen Blogbeitrag hängt.

Ich hoffe, dass ich mit diesen Hinweisen ein paar Menschen geholfen habe.

Und nein, es war keine spezifische Schwäche von WordPress 2.3.3, die da von einem destruktiven Zeitgenossen ausgebeutet wurde. So weit ich das absehen kann, wäre ein vergleichbarer Angriff auch gegen ein WordPress 2.5 möglich. Auch der aktivierte „safe-mode“ von PHP war keine große Hilfe, sollte aber dennoch Standard sein. Niemand wiege sich in Sicherheit, nur weil er die aktuelle WordPress-Version verwendet!

1984: Wir überwachen zurück!

Wer die Allgegenwart der Kameraüberwachung nicht mehr unwidersprochen hinnehmen mag, erhält jetzt die Gelegenheit, durch eine kollektiv gepflegte Dokumentation dieses Wahnsinnes friedlichen Widerstand zu leisten.

Für die Eselsohr-Werbung dieser Aktion habe ich ein WordPress-Plugin erstellt, indem ich das Eselohr des AK Vorrat kurz bearbeitet habe, um den von Lanu veröffentlichten Code einzufügen. Dieses Plugin habe ich mit den WP-Version 2.3.x und 2.5.x getestet, es scheint fehlerfrei zu sein. Für jene, die nicht an den Quelltexten ihrer WordPress-Themes herumeditieren wollen, ist die Installation eines Plugins so bequem, dass ich meinen Code zum freien Download zur Verfügung stelle.

Download-Link: WordPress-Plugin Page Peel 1984

Installation

  1. ZIP-Archiv mit dem jeweiligen Lieblingsprogramm entpacken…
  2. Den Ordner ppeel1984 in das Verzeichnis /wp-content/plugins des Blogs hochladen…
  3. Das Plugin aktivieren…
  4. …und, das war es wirklich schon.

Eine Demonstration, wie das Ergebnis aussieht, kann man im Nebenprojekt Nachtwächter-Blah dieses Blogs betrachten. Hier möchte ich bis auf Weiteres den Link auf den AK Vorrat belassen, und zwei Eselsohren an der gleichen Stelle würden sich recht eselig überlappen. 😉

Wichtiger als die recht einfache Installation dieses Plugins auf verschiedenen Blogs ist die Teilnahme an diesem Projekt. Für die Dokumentation einer Kamera ist keine Anmeldung und keine Preisgabe persönlicher Daten erforderlich, wer ganz sicher gehen will, kann die Website auch über einen Dienst oder ein Netzwerk zur Anonymisierung verwenden.

Also: Überwacht zurück! 😈

Dringender Hinweis

Ein dringender Hinweis an alle Blogger: Die aktuellen Cracker-Angriffe gegen WordPress gehen weiter. Jetzt gibt es massive Trackback-Spam, die gecrackte Blogs massiv verlinken soll. Die Vorgehensweise der Spammer bringt es mit sich, dass diese Trackbacks von Akismet nicht als Spam erkannt werden, und deshalb erreichen die Spammer ihr Ziel. Eine einfache Abhilfe gegen das Problem wird im verlinkten Text aufgezeigt. Bitte unbedingt die Konfiguration des eigenen Blogs anpassen.

Und ganz wichtig: Die Information verbreiten! ❗

(Der Text auf Unser täglich Spam ist von mir, er darf gern übernommen werden, als wenn er unter der Piratenlizenz veröffentlicht wäre.)

Warnung! WordPress 2.5 erschienen

Aktuelle Ergänzung: Für die Probleme beim Hochladen von Bildern gibt es verschiedene, im englischen Supportforum beschriebene Workarounds. Vielleicht hilft das manchem, der gerade verzweifeln möchte. In jedem Falle können Bilder hochgeladen werden, wenn man den Firefox mit dem aktuellen Flash-Plugin verwendet. Aber überschüttet mich jetzt bitte nicht mit Fragen, wie man das aktuelle Flash-Plugin unter verschiedenen Linux-Distributionen zum Laufen kriegt, wenn das Installationskript eine nicht passende glibc anmeckert und aussteigt, sondert wendet euch damit an das jeweilige Supportforum eurer Distribution. Völlig ohne Gewähr und ohne eigene, umfangreiche Tests weise ich darauf hin, dass es offenbar auch möglich ist, zur vorhergehenden Version von WordPress zu wechseln. Wer das macht, der handelt auf eigene Gefahr und sollte in jedem Fall vorher einen Backup anlegen.

Weitere aktuelle Ergänzung: Die heute veröffentlichte Version „Brubeck“ von bbPress arbeitet nach Aussage im Entwicklerblog auch mit WordPress 2.5 zusammen. Ich habe das noch nicht getestet.

Es war eine schwere Geburt, bei der es sich die Entwickler nicht leicht gemacht haben. Der selbst erzeugte, völlig unnötige Termindruck hat sich nicht bewährt, sondern angesichts der gegenwärtigen Angriffswellen auf WordPress-Blogs eher noch zur Verunsicherung beigetragen. Aber jetzt ist es soweit, und WordPress 2.5 wurde veröffentlicht. (Es gibt bei WordPress Deutschland auch einen Hinweis in deutscher Sprache.)

Ich habe mir eben die Release runtergeladen und in einer lokalen Installation getestet. Meine Meinung zur neuen Benutzerführung habe ich ja schon deutlich genug dargelegt, und zwar hoffentlich so, dass niemand von einem allzu garstigen Urteil abgeschreckt wird.

Natürlich habe ich bei meinem damaligen Test nichts über kleine und größere Fehler geschrieben, das wäre ein unangemessener Maßstab gegenüber einer Vorveröffentlichung, anhand derer ja Fehler gefunden und beseitigt werden sollen. Und. Natürlich sind mir damals schon so einige kleine und größere Fehler aufgefallen.

Nun, jetzt handelt es sich um eine offizielle Veröffentlichung. Im Moment sieht jeder WordPress-Blogger, der sein Dashboard besucht, die gelb hinterlegte Aufforderung „Eine neue WordPress-Version ist verfügbar! Bitte aktualisieren Sie jetzt.“ — an eine solche Veröffentlichung darf man ja wohl einen etwas höheren qualitativen Maßstab anlegen als an eine Beta oder einen RC. Und. Deshalb muss ich eine Warnung aussprechen, bevor jemand allzu blind glaubt, dass er nun endlich eine Version erhält, die problemlos verwendbar ist:

Nicht voreilig auf die aktuelle Version updaten!

So unübersehbar die Aufforderung zur Update in jeder Seite des Dashboards auch sein mag, so gern man sich auch eine aktuelle Version mit vielen beseitigten Fehlern holen möchte:

Vor dem Update nachdenken und in jedem Fall einen Test in einer lokalen Installation machen!

Ich beschreibe jetzt nur die Schwächen, die mir binnen 15 Minuten in der aktuellen Release von WordPress 2.5 aufgefallen sind und die diese Release für mich (und wohl viele andere Blogger auch) zurzeit unbrauchbar machen.

➡ Die neue Medienverwaltung ist mit dem Webbrowser Opera nicht benutzbar. Da praktisch jeder, der mit mir persönlich zu tun hat und mit dem ich gemeinsame Projekte im Internet habe, diesen Browser benutzt, ist es für mich nicht möglich, den Update durchzuführen.

Es ist zwar möglich, eine Datei hochzuladen, aber es ist völlig unmöglich, die hochgeladene Datei mit Opera in einen Post einzufügen. Die Bilder erscheinen zwar in der Liste, aber es nicht möglich, die Details zu einem Bild anzeigen zu lassen; und es ist damit auch nicht möglich, an einen Link für das Bild zu kommen. Die an sich guten Erweiterungen (Medienverwaltung, konfigurierbare Skalierung der Vorschaugröße) nützen gar nichts, wenn in einem solchen Fall nicht einmal ein Weg zur Verfügung gestellt wird, an einen einfachen Link für die hochgeladenen Dateien zu kommen. Da tröstet es denn auch nicht besonders, wenn Matt im WordPress-Blog schreibt, dass er damit schon über tausend Fotos hochgeladen hat — ganz im Gegenteil, man wünscht sich, dass die Entwickler ihr Werk wenigstens einmal mit den populären Browsern ausprobiert hätten. Angesichts der Tatsache, dass etwa acht Prozent meiner Besucher den Opera benutzen und angesichts der Tatsache, dass dieser Browser eine ideale Software für Menschen ist, die einfach nur das haben wollen, was man beim Internet-Explorer nicht kriegt und was man beim Firefox mit vielen Plugins nachrüsten muss, ist das schon etwas schmerzhaft. Ich habe übrigens wesentlich mehr Besucher mit Opera als mit dem Safari, der gewiss gut unterstützt wird…

Kurz gesagt: Wer Opera benutzt, kann die neue WordPress-Version nicht verwenden. Oder er muss eben mit einem anderen Browser bloggen, wenn er dies nicht als übergroße Zumutung empfindet.

➡ Wer ein bbPress-Forum zusammen mit WordPress verwendet und die Benutzertabelle zwischen beiden Anwendungen teilt, wird feststellen, dass dies mit der aktuellen WordPress-Version nicht mehr funktioniert. Da ich zwei Projekte mit zugehörigem bbPress verwende, ist mir bei diesen Projekten der Upgrade nicht einmal dann möglich, wenn ich keine Rücksicht auf Opera-Nutzer nehmen muss.

Kurz gesagt: Wer WordPress und bbPress so benutzt, dass die Benutzerdaten zwischen den beiden Anwendungen geteilt werden, kann die neue WordPress-Version nicht verwenden.

Angesichts der Tatsache, dass bbPress eine Forumssoftware ist, die eigens für das Support-Forum von WordPress entwickelt wurde, ist diese Einschränkung besonders schmerzhaft und unverständlich. Ich halte es für durchaus wahrscheinlich, dass in Kürze eine angepasste bbPress-Version veröffentlicht wird, aber wer darauf nicht gewartet hat, der hat jetzt ein Forum, an dem sich kein registrierter Nutzer mehr anmelden kann.

Ich halte es durchaus für möglich, dass es noch weitere, teilweise schwere Schwächen in der aktuellen Release gibt. Es ist schade, wenn man die Installation einer Release als ein Wagnis betrachten muss, aber genau das ist es im Moment: Ein Risiko für die Funktionsfähigkeit eines stark erweiterten Blogs. Allerdings bin ich mir gewiss, dass die schlimmsten Schwächen in den nächsten Wochen behoben werden und dass es in vier bis acht Wochen eine Release geben wird, die man bedenkenlos empfehlen kann.

Angesichts der möglichen Probleme kann ich nicht deutlich genug empfehlen, vor dem Update einen vollständigen Backup der Datenbank und des laufenden Blogs anzulegen, um im Problemfall mit Leichtigkeit auf den vorherigen Stand zurückgreifen zu können. Wer dazu bereit ist, probiere es ruhig aus — denn abgesehen von einigen ergonomischen Unreifen in der neuen Benutzerführung enthält die neue Version von WordPress durchaus gute Ideen.

WP-Angriffe: An alle Betroffenen!

Dies ist ein Nachtrag zu meinem gestrigen Text zu den gegenwärtigen Angriffen auf WordPress-Blogs. In diesem Nachtrag will ich versuchen, Hinweise zur möglichen weiteren Eingrenzung des Problemes zu geben. Das ist ziemlich trockener, technischer Stoff, der wohl nicht jeden interessieren wird.

Bitte unbedingt auch den entsprechenden Thread im deutschen Support-Forum beachten und dort bei der Eingrenzung des Problemes helfen.

Ich habe die verschiedenen Diskussionen des Problemes natürlich verfolgt. Dabei hat sich vor allem bei „Ja gut, aber…“ herauskristallisiert, dass die Verseuchungen der Blogbeiträge mit Spam in verschiedenen Versionen von WordPress auftreten. Entweder handelt es sich um einen Fehler in WordPress, der schon seit längerer Zeit (seit Version 2.2) „auf seine Chance wartet“, aber erst jetzt richtig so ausgebeutet wird; oder aber — und das ist meine Vermutung — es handelt sich um ein Problem mit einem schlampig programmierten Plugin. Dieser Post ist ein Versuch, das verursachende Plugin zu isolieren; das bedarf allerdings der Mitarbeit betroffener Blogger.

Ein möglicher Verdächtiger für ein Plugin, dass die Probleme über eine XSS-Lücke mit einem gestohlenen Cookie verursachen könnte, hat sich schon gefunden, es könnte sich um das recht populäre Statistik-Plugin „Semmelstatz“ handeln. Dieses Plugin wurde sogar (von Ralf im oben verlinkten Thread) dabei erwischt, wie es im Dashboard einen eingebetteten Frame auf eine externe Seite im Internet darstellen wollte. Das sollte alle Alarmglocken klingeln lassen.

Besonders erschreckend an den gegenwärtigen Attacken ist, dass sich die Angreifer Schreibzugriff auf ein Verzeichnis im Blog verschaffen können, und dass es sich dabei nicht um das reguläre Upload-Verzeichnis handelt. Wer in seinem Verzeichnis wp-content ein Unterverzeichnis mit dem Namen 1 hat, sollte dieses umgehend löschen, wenn er nicht will, dass seine Website von Verbrechern zu gewiss unschönen Zwecken missbraucht wird. (Im Zweifelsfall ist der Betreiber für einen kriminellen Missbrauch seiner Site haftbar; wenn es vor Gericht gehen sollte, hängt alles von der technischen Kompetenz der Richter ab. Diese ist oft erschreckend gering.) Besonders schlimm ist die Vorstellung, dass die Spammer eventuell sogar die gesamte WordPress-Installation überschreiben könnten. Wer sich dagegen schützen will, sollte die Zugriffsrechte auf die PHP-Dateien seines Blogs so restriktiv wie nur möglich setzen. Ich empfehle 644 für die Dateien und 755 für die Verzeichnisse (außer wp-content/uploads), um dem Webserver keine Rechte zum Überschreiben der Installation zu geben. Auch, wer noch nicht betroffen ist, sollte unbedingt über diese einfache Maßnahme zum Schutz nachdenken.

Um die Fehlersuche etwas anzuregen und hoffentlich zu einer weiteren Klärung des Problemes beizutragen, veröffentliche ich hier einmal ein paar Daten, die man eigentlich nicht veröffentlichen sollte. (Keine Sorge, ein Backup der Datenbank läuft bei mir automatisch und regelmäßig durch, und wenn ich doch mit diesem Posting auf eine Bruchlandung hinlege, hat die Bloggosphäre wenigstens einen Grund zur Häme.)

Ich verwende WordPress-Blogs in den verschiedensten Versionen für unterschiedliche Projekte. Keines dieser Blogs ist von den jüngsten Attacken der Spam-Verbrecher betroffen.

Das muss nichts bedeuten, es kann ohne weiteres einfach nur ein Glücksfall sein, der diesen automatisierten und offenbar sehr wirksamen Angriff bislang an mir vorbeigehen ließ — es kann aber auch bedeuten, dass diese Konfiguration sicher genug ist. Da ich zumindest mit diesem Blog vielfach verlinkt bin, ein relativ gutes Ranking bei Google habe und der Angriff automatisiert nach diesen Kriterien erfolgen wird, gehe ich davon aus, dass ich eigentlich betroffen sein müsste.

Besonders interessant auf dem Hintergrund der Attacken dürften die WP-Versionen 2.2.3 und 2.3.3 sein, die zurzeit vielfach im Einsatz sind und beide schon gecrackt wurden. (Etliche Blogger haben den Update auf 2.3 mit gutem Grund vermieden und verwenden immer noch das letzte WP 2.2.x.) Ich werde hier die Versionen und die installierten Plugins von zwei Blogs veröffentlichen, die ich technisch betreue und die nicht von den Attacken betroffen sind. Beide Blogs sind ausgewählt worden, da sie für meine Verhältnisse besonders viele Plugins enthalten. (Ich versuche stets, eine Installation so klein wie möglich zu halten.) Zu einigen Plugins mache ich kurze Anmerkungen. Ferner gibt es auch ein paar Worte zur sonstigen Konfiguration der Blogs.

Konfiguration: Lumières dans la nuit

Es handelt sich um das von mir in der Hauptsache mit Anmerkungen und dunklen Gedanken befüllte Blog. Die Postingfrequenz ist täglich, an manchen Tagen mehrfach täglich. Da ich das Spiegeln meiner Inhalte in der Lizenz sehr ausdrücklich erlaube und da davon auch Gebrauch gemacht wird, kann ich keine sicheren Angaben zur wirklichen Leseranzahl machen. Die direkten Zugriffe auf das Blog sind stark schwankend, liegen aber in normalen Zeiten zwischen 100 und 350 Lesern am Tag.

Es handelt sich um ein WordPress 2.3.3. Das Theme ist ein leicht angepasstes Simplicity ohne besondere Schnörkel (allerdings habe ich es Widget-fähig gemacht und um ein paar kleine Funktionen erweitert).

Im Blog sind folgende Plugins aktiv:

  • Akismet
  • BDP RSS Aggregator
  • CSS Naked Day
  • Dashboard Editor
  • Delete Comment IP
  • Exec-PHP
  • Executable PHP Widget
  • Filosofos Tinfoil Hat Plugin
  • Follow-URL
    enthält einen kleinen Hack von mir
  • Force Word Wrapping
  • Google XML Sitemaps
  • Intypo
  • Jamendo Embedder
  • o42-clean-umlauts
  • Page Peel (AK VDS)
  • pjw-wp-phpmailer-nosender
  • Popularity Contest
  • Search_Hilite
  • Time Zone
  • TinyMCS Advanced
  • Visitor Counter Widget
  • WordPress.com Stats
  • WP-ContactForm
    enthält einen kleinen Hack von mir
  • WP-UserOnline
  • WP-UserOnline Widget
  • WP Grins
  • WP Paypal Donate Widget R2.0

Die folgenden Plugins sind installiert, aber nicht aktiv:

  • !Wartungsmodus (de)
  • BDP RSS Aggregator Widgets

(Das schlichte Blog hier ist also „aufgeblähter“, als macher auf dem ersten Blick denken möchte. Ich halte eben nichts von „fetter“ Gestaltung.)

Wenn ich nicht einfach nur Glück hatte, denn sind die hier gelisteten Plugins unter WP 2.3.3 sicher. Wenn jemandes Blog gecrackt wurde und keine weiteren Plugins als die hier erwähnten verbastelt wurden (auch inaktive Plugins können ein Problem sein), denn bitte einen deutlichen Widerspruch in die Kommentare schreiben.

Konfiguration: White Darkness

Das Blog White Darkness ist eine schnelle Portierung der früheren Homepage nach WordPress. Das Theme habe ich von Grund auf selbst geschrieben, es ist vorsätzlich sehr schlicht. Es handelt sich um die Homepage einer nicht-kommerziellen Künstlergruppe aus Hannover. Die Postingfrequenz ist gering, ungefähr monatlich. Zu den weiteren Anforderungen neben dem leichten Publizieren gehörte ein gut in die Homepage integriertes Forum und eine Galerie, beides wird eher wenig verwendet. Die Leserzahl ist in der Regel gering, kann aber im Umfeld von Veranstaltungen auch auf 80 bis 100 am Tag ansteigen.

Es handelt sich um ein WordPress 2.2.3. Als Forum wird ein bbPress verwendet, die Galerie ist eine Gallery; beides wird auch mit Hilfe von Plugins in WordPress eingebettet.

Besonders bemerkenswert hier: Es ist eine Registrierung von Lesern möglich, die auch zur aktiven Benutzung des Forums erforderlich ist.

Es wurde verschiedentlich an anderen Stellen geäußert, dass solche Registrierungen die Ursache des gegenwärtigen Problemes sein könnten. Ich kriege dort zwar automatische „Spam-Anmeldungen“ von diversen, windigen Pillenhändlern, aber zu einer Veränderung von Beiträgen oder dem Upload von Spam-Dateien ist es dort nicht gekommen. (Die Spam-Anmeldungen sind fast wirkungslos, das Forum wird durch Akismet geschützt und bis heute ist kein einiger Spambeitrag „durchgekommen“. Aber es ist eben eine gewisse Last, weil ich diese Schrottaccounts lieber lösche, statt sie in der Datenbank vorzuhalten.)

Im Blog sind folgende Plugins aktiv:

  • ©Feed
  • Akismet
  • bbPress Integration
  • BBpress Latest Discussions
  • bs-wp-noversion
    Ich bin im Moment eben ein bisschen paranoid… 😉
  • Dashboard Editor
  • Executable PHP Widget
  • Follow-URL
  • Google Analytics
  • Google XML Sitemaps
  • Intypo
  • Nice Dashes
  • o42-clean-umlauts
  • RS Event
    mit größeren persönlichen Anpassungen von mir…
  • Search Hilite
  • Time Zone
  • Visitor Counter Widget
  • Sprücheklopfer
    Ein „Hello Dolly“ mit anderen Texten zur Erheiterung der Coautoren…
  • WordPress.com Stats
  • WP-Sticky
    mit kleineren Hacks von mir
  • WP-UserOnline
  • WP-UserOnline Widget
  • WPG2

Die folgenden Plugins sind installiert, aber nicht aktiv:

  • !Wartungsmodus (de)
  • pjw-wp-phpmailer-nosender
  • Upgrade Preflight Check
    Denn irgendwann muss es ja doch mal sein, und ich mag gewisse Überraschungen nicht…

Wenn ich nicht einfach nur Glück hatte, sind diese Plugins unter WP 2.2.3 sicher. Wenn jemandes Blog gecrackt wurde und keine weiteren Plugins als die hier gelisteten verbaut wurden (auch inaktive Plugins können Probleme bereiten), denn bitte deutlich genug in den Kommentaren widersprechen.

Weitere Anmerkungen

Beide Blogs verwenden keinen JavaScript-Code von Drittanbietern, und ich rate jedem Menschen mit gutem Grund davon ab, auf seiner Site irgendwelchen Unternehmen das Recht einzuräumen, beliebigen Code auszuführen.

Beide Blogs enthalten externen JavaScript-Code für einen auf PPhlogger basierenden Zählerdienst. Dieses wird innerhalb der Blogs nicht sichtbar, es dient nur zur Erstellung einer bequem abrufbaren Zugriffsstatistik, die möglichst „live“ Einblick in das Geschehen gibt. (Daran kann ich etwa eine Attacke von wirklichen Leserzugriffen unterscheiden, die Skripten der Cracker führen kein JavaScript aus.) Die PPhlogger-Installation steht unter meiner Kontrolle.

Beide Blogs enthalten ein bisschen JavaScript-Code zur automatischen Aktualisierung der Anzeige der aktuellen Leserzahl.

Weiteres JavaScript ist nicht „verbastelt“.

Eine spannende Frage

Jetzt bin ich selbst gespannt: Ist es wirklich ein fehlerhaftes Plugin, das zurzeit von den Spammern ausgenutzt wird, oder ist es ein fürchterlicher Fehler im Kern von WordPress?

Dies herauszufinden, geht leider nur gemeinsam.

Wenn Sie gecrackt wurden und nur Plugins hatten, die hier als aktive Plugins gelistet wurden, denn widerspricht das meiner Vermutung, dass es sich um einen Fehler in einem Plugin handelt. Bitte schreiben Sie mir das in die Kommentare!

Wenn Sie gecrackt wurden und andere Plugins hatten, solche, die hier nicht in den Listen stehen, denn erwähnen Sie bitte die anderen Plugins in einem Kommentar und schreiben Sie dazu, dass sie gecrackt wurden. (Sie müssen ihr Blog nicht angeben.) Wenn sich herausstellt, dass alle gecrackten Blogs gewisse Plugins benutzt haben, dann haben wir gemeinsam herausgefunden, wo der Fehler liegen könnte. Wenn nicht, war es den Versuch wert.

Wie gesagt, ich bin selbst gespannt auf das Ergebnis…

(Und wehe, ich werde jetzt gecrackt…)