Klartext.

Wohl jeder, der eine einigermaßen gut besuchte Seite betreibt und ab und zu einen Blick in seine Logfile-Statistiken wirft, kennt das Phänomen: Irgendwann kommen die Spammer und hinterlassen in den Logfiles rätselhafte Referer von zwielichtigen Porno-, Casino- und Viagra-Seiten.

Diese Referer sind natürlich allesamt gefälscht. Sie dienen nur einem Zweck: Für die Suchmaschinen sollen möglichst viele Verweise auf die betreffenden Seiten gestreut werden, um deren Page Rank zu heben.

Ähnliches kennen wir bereits zur Genüge aus nicht abgesicherten Gästebüchern oder Foren. Die hektische Einführung des Tags rel="nofollow" hat die Spammer gerade mal gar nicht interessiert – warum auch, es kostet sie ja nichts, ihren Müll weiterhin flächendeckend abzusetzen.

Warum nun diese Verschmutzung von Logfiles? Sie sind doch in der Regel nicht öffentlich einsehbar, wie können sie da der Verbreitung solcher Links dienen?

Die Antwort ist: Keine noch so kleine Gelegenheit wird von den Spammern ausgelassen. Und: Viele Hobby-Webmaster schützen ihre Statistiken leider nicht vor öffentlichem Zugriff. Dadurch können sie von Suchmaschinen erfasst werden.

Zu diesem Übel trägt weiterhin bei, dass für viele Blog- und Portalsysteme Module existieren, die die letzten Referer auflisten. Warum jemand so etwas komplett Überflüssiges installiert, entzieht sich meinem Horizont. Aus Sicht des Spammers sind solche Tools jedoch ein echter Treffer ins Schwarze: Der gefakete Referer ist sofort und ohne weiteres Zutun auf einer öffentlichen Seite sichtbar, hurra!

Was ist also zu tun, um das Übel in den Griff zu bekommen?

• Keine Referer-Module installieren. Sie dienen nur der Selbstverliebtheit und tragen dazu bei, die Seuche Spam weiterzuverbreiten.
• Webstatistiken grundsätzlich vor öffentlichem Zugriff abschotten. Das funktioniert bei Apache-Servern wunderbar mit einer .htaccess-Datei.
• Fake-Referer von vornherein unterbinden. Mittlerweile finden sich einige fertige Blacklists, die man direkt verwenden kann. Beispielsweise können Referer, die den Begriff "poker" oder "prescription" enthalten, komplett geblockt werden. Auch dies geschieht zweckmäßigerweise über die .htaccess-Datei. Eine ausgezeichnete Quelle findet sich hier.

Mit diesen Maßnahmen hat man zumindest für die eigene Seite Ruhe vor dieser Art der Spamverbreitung.

Ryan Thrash, Projektleiter beim ambitionierten MODx CMS, hat eine neue Methode zum Erzeugen von Boxen mit abgerundeten Ecken mit Hilfe von CSS vorgestellt. Sie verzichtet auf die üblicherweise nötige Vielzahl von Bildern und benutzt als Ausgangspunkt ein einziges Bild. Ein sehr interessanter Ansatz!

Seit einigen Jahren gibt es – meist für die Windows-Plattform – fix und fertige Webserver-Pakete zum Herunterladen, die in der Regel eine vorbereitete Zusammenstellung von Apache, PHP, MySQL, Perl und manchmal noch weiteren Komponenten darstellen. Ich selbst habe vor Jahren mit einem solchen (mittlerweile veralteten) Paket namens FoxServ  meine ersten Schritte unternommen. Eine schöne Sache für Einsteiger: Manche solcher Pakete wie z.B. XJ! sind sogar schon speziell für Joomla vorbereitet. Sie ermöglichen es ihnen, sehr schnell und ohne in technische Details einsteigen zu müssen, lokal eine lauffähige Joomla-Seite zu bauen. Das senkt die Einstiegshürde.

Und genau das ist der Knackpunkt, denn das böse Erwachen kommt später. Wer mit einem solchen "Instant-Paket" arbeitet, der kratzt – technisch gesehen – nur an der Oberfläche und entwickelt kein Verständnis für die Zusammenhänge. Dieses Verständnis ist aber spätestens dann nötig, wenn der liebevoll entwickelte Auftritt nun ins Web gestellt werden soll. Ein Joomla-Administrator muss sich zwangsweise mit der grundsätzlichen Funktionsweise der Server-Komponenten auseinandersetzen – oder sich Hilfe holen, weil auf dem Webserver eben nicht das gleiche vorkonfigurierte Paket läuft. Und die diesbezüglichen Hilferufe sehen wir tagtäglich in den Joomla-Foren.

Darüber hinaus gibt es eine weitere spezielle Problematik bei vielen "Instant-Paketen": Die Versionen der verwendeten Komponenten. Oft wird als Werbeargument angeführt, dass das Paket die allerneuesten Versionen von Apache, PHP und MySQL enthält. Das suggeriert höchste Aktualität und beste Leistungsfähigkeit.

Schade nur, dass damit oft auch die neuesten Bugs enthalten sind – und die Kompatibilität zum produktiven Webserver weiter abnimmt. Denn kein Hosting-Provider, der bei klarem Verstand ist, installiert sofort nach Erscheinen die neuesten Versionen – es sei denn, ein akutes Sicherheitsproblem zwingt ihn im Einzelfall dazu. Vielmehr werden Webserver auf Stabilität ausgelegt und verwenden über lange Zeit erprobte Versionen von Apache, PHP und MySQL – die Release-Politik von Debian ist hier ein (vielleicht etwas extremes) Beispiel.

Und damit ergeben sich für den Newbie schwer überwindbare Hürden: Der lokale Datenbankdump von MySQL 4.1 lässt sich auf dem Webserver mit MySQL 4.0 (oder gar noch einer Version 3.23) nicht unfallfrei einspielen. PHP ist auf dem Server anders konfiguriert, und die Seite läuft erst einmal gar nicht. Und so weiter und so weiter.

Nicht, dass ich die fertigen Webserver-Pakete schlechtreden möchte – wenn man weiß, was man tut, kann man sie wunderbar einsetzen. Aber man sollte sehenden Auges herangehen und bereit sein, sich über die Interna zu informieren, wenn der Transfer eines Auftritts ins "richtige" Web bevorsteht.

Persönlich bevorzuge ich die lokale Entwicklung auf einem System, das idealerweise genau identisch aufgebaut ist wie der Zielserver im Web. Betriebssystem, alle Programmversionen, Komponenten und die Verzeichnisstruktur entsprechen genau dem Webserver. So kann man bereits offline durchspielen, ob alles funktioniert, und sich sicher sein, dass das Übertragen später problemlos vonstatten geht. Und für zusätzliche Mobilität habe ich eine weitere Installation mit Apache, PHP und MySQL lauffähig auf einem USB-Stick dabei.