Problem Dynamsiche Webseite

Die Seite an sich beinhaltet Content an dem mehrere Nutzer ab und an Änderungen vornehmen. Die damit verbundenen unregelmäßigen Änderungen sind zeitlich nicht vorhersehbar und es steht auch keine “Last Modified” Information zur Verfügung. Herkömmliches Browser / Proxy Caching fällt als flach da es sonst passieren kann das ein Browser bei gezwungenem Cache den Inhalt nicht mehr aktuell präsentiert, was auf keinen Fall passieren darf.

Lösung, Dynamisches Hash-Etag

Der Content wird nach wie vor in seiner PHP Datei wie eh und je ohne Cache generiert. Jedoch wird statt einer direkten Ausgabe des HTML Codes selbiger als Grundlage für eine CRC Summe genommen. Diese CRC Summe dient als Etag um dem Browser zu ermöglichen eine Änderung zu identifizieren. (Was ist ein Etag ?) Der Vergleich ob wir den Content ausgeben oder nicht liegt jedoch in unserer Serverseiten Hand. Der Client Browser übermittelt via HTTP_IF_NONE_MATCH der ihm bekannten Hash. Wir können nun vergleichen ob unser Content dem des Users entspricht, ist dies der Fall so teilen wir das dem Client mit und beenden die Verbindung ohne weitere Daten zu übertragen. Dadurch beschränkt sich die Übertragung auf die reinen HTTP Header und nicht wie vorher je Seite 250k und mehr.

Das ganze mal von der Code Seite, anhand eines Beispiels, aufgezeigt:

$OUT = "Mein Content";
// Es können auch andere Hash Algos verwendet werden, bei den meisten Benchmarks
// ist md4 allerdings am schnellsten. Da wir hier keine Passwörter o.ä. hashen wollen
// sondern quasi nur eine CRC bilden möchten ist der Algo. nicht so brisant.
$hash = hash("md4",$OUT);
header("Etag: $hash");
header("Cache-Control: private, must-revalidate");
if($_SERVER['HTTP_IF_NONE_MATCH'] AND $_SERVER['HTTP_IF_NONE_MATCH'] == $hash) {
// Browser hat identischen Content bereits lokal
header("HTTP/1.1 304 Not Modified"); // Browser mitteilen das Seite unverändert
header("Connection: Close"); // Keep-Alives unterbinden
exit; // Script beenden.
}
echo $OUT;

Das hier gezeigt Script ist online zum testen des effektes am eigenen Browser unter dieser URL erreichbar.

Insgesamt brachte dieses unterstützte Cachehandling einen enormen Geschwindigkeitsgewinn. Da die zu beschleunigende Seite aus über 2000 DOM Elementen besteht (250K HTML) war es bei langsamen Verbindungen somit “unschön” zu navigieren. Doch auch im kleinerem Umfeld kann dieses manuelle Tag Handling Vorteile haben. Wichtig ist das man sicherstellt das keinerlei Expire header auf die auszuliefernde Seite gesetzt ist. Denn ist dies der Fall wird primär nach Expire gegangen und erst dann anhand des eTag ein Revalidate durchgeführt.

Einleitung

Ein Webbrowser ist in der Regel limitiert eine Maximale Anzahl an Verbindungen pro Host aufzubauen. Bei optimierten Browsern wie Opera oder Firefox ist diese Anzahl bereits relativ hoch bzw. teilweise Dynamisch. Bei älteren Browsern dagegen ist hier oftmals ein Limit auf 4 oder 8 Verbindungen pro Host fest gesetzt. Nun, eine Webseite besteht nicht selten aus hunderten Elementen; jede Grafik, jedes JavaScript jeder Ajax Request ist ein “hit” jeder Hit wiederum verlangt in der Client – Server Kommunikation einen kompletten Handshake.

Eine Typische HTTP Kommunikation ist in Abb 1 zu sehen, grün ist der “Request” vom Webbrowser (client) an den Server und rot ist die vom Server entgegnete Antwort. Wenn man nun annimmt eine Beispiel-Webseite bestünde aus 70 einzelnen Elementen, so wäre dies 70x das selbe Client-Server “geschwätz” was schon einiges an “Kommunikationsaufwand” bedeutet.

In der Realen Welt ist es nicht ungewöhnlich das duzende kleinst Grafiken geladen werden. Mal ein Beispiel an einer einfachen Flagge wie ich sie öfters auf der Seite verwende Dieses de.png ist 129 Bytes klein, allein die nötige Client – Server Kommunikation für diese Flagge umfasst allerdings bereits 1.822 Bytes; Das ist 14x mehr als die Größe der eigentliche Datei selbst.

Vor der eigentlichen Header Übertragung kommen nun noch die üblichen Verzögerungen durch das TCP Protokoll hinzu. Um den Beitrag nicht zu sprengen nur kurz hierzu:

1. Anfrage http://host.name/de.png
2. Namensauflösung host.name
3. Verbindung auf IP Port 80
4. TCP Handshake
5. Anfrage Client –> Server (Abb1 grün)
6. Antwort Server –> Client (Abb1 rot) vorbereiten des Clients auf Datenempfang
7. Eigentlicher Datentransfer Server –> Client
8. Bestätigung
9. Verbindung trennen

Diese Prozedur bei jeder noch so kleinen Grafik kostet eben Zeit. Die meisten Browser oder auch das Betriebsystem greifen hier schon unter die Arme in dem z.B. DNS Caches verwendet werden.

Keep-Alive

Um das ganze nun weiter zu optimieren unterstützen alle modernen Webbrowser so genannte Keep-Alive requests. Diese halten nach Schritt 8 die Verbindung für eine bestimmte Zeitspanne offen und warten sozusagen, auf der selben Leitung, auf weitere Anfragen des Webbrowsers. Somit beschränkt sich die Kommunikation auf das Schema: 1,2,3,4, (5,6,7,8), (5,6,7,8), (5,6,7,8),[…] 9

Da dies für den Webserver aber auch bedeutet Ressourcen an Clients zu “reservieren” ist man als Webmaster hier meist sehr restriktiv. Länge und mehr Keep-Alive Möglichkeiten erhöhen die Gefahr bei viel Ansturm nicht mehr erreichbar für “neue” Clients zu sein. Zudem steigt die Anfälligkeit für einfache DoS Attacken (Denial of Service). In der Antwort des Servers erkennt man in Abb1 die Konfiguration der Keep-Alives in Form von: Keep-Alive: timeout=6,max=32 Der Webserver teilt hier dem Browser mit das er die Verbindung 6 Sekunden offen halten kann und maximal 32 Anfragen pro Verbindung akzeptiert.

Distinct Hosts / Static Domains

Auch wenn die Kommunikation nun auf Schritt 5-8 beschränkt ist bedeutet das noch nicht das wir die am Anfang der Einleitung angesprochenen Header los sind. In unserem Beispiel “de.png” war der Header ja 14x größer als die eigentlichen Daten. Wie man in Abb1 erkennt beinhalten die HTTP Header viele Informationen die ein statischer Content wie ein PNG niemals brauchen wird. So z.B. Cookies, Etags oder andere erweiterte Cache Informationen. Bleiben wir aber mal bei den Cookies, fast jede Webseite nutzt heutzutage Cookies. Ob für Sessions, zur Identifizierung des Nutzers oder für Analytics. Diese Cookies werden bei jedem Request vom Webbrowser alle an den Webserver geschickt damit dieser, bei Bedarf, diese Informationen auswerten kann. Hier sind wir nun an dem Punkt an dem deutlich wird was ich meine; Wozu braucht ein de.PNG alle meine ? In 99% der Fälle eben gar nicht.

Nun kommen die so genannten “Distinct Hosts” oder “Static Domains” ins Spiel. Neben der eigentlichen Domain der Webseite kommen nun noch eine weitere Subdomain ins Spiel. Statische Inhalte wie Grafiken oder sich nicht ändernde JS Daten werden nun nicht mehr von http://www.solariz.de/gfx/ geladen sondern von einer neuen Subdomain: http://static.solariz.de/ diese beinhaltet eigentlich 1:1 das selbe wie der vorherige GFX Ordner. Allerdings wird der Webserver hier auf die Auslieferung von statischem Content optimiert. Bei großen Projekten ist es sinnvoll hier einen weiteren Webserver zu verwenden der sich nur um die Auslieferung des statischen Inhalts zu kümmern hat. Damit ist die “Last” des Traffics hierfür vom Hauptwebserver genommen. In Abb2 sieht man eine Client – Server Kommunikation mit einer optimierten statischen Domain. Diese ist für genau den selben Sinn und Zweck um gut 1KB geschrumpft. Bei unserer Beispiel-Webseite mit 70 Elementen wären dies auch rund 70KB weniger die bei jedem Seitenaufruf transferiert werden müssen.

Oftmals wird für Static Hosts eine sehr abgespeckte Version des Apaches mit minimaler Anzahl an Modulen genutzt. Kein PHP, kein CGI, kein Auth, keine Etag Berechnung. Alles wird auf das nötigste runtergefahren. Somit ist die Kommunikation zwischen Client und Server in der Regel auch schneller.

Doch das waren nicht alle Vorteile, durch die Verwendung einer Subdomains bleiben auch die Cookies außen vor da diese auf der Hauptdomain liegen. Zudem hat der Webbrowser nun die Keep-Alive Range des normalen Hosts für reine HTML Anfragen was die Pageload Zeit beschleunigt.

Zu guter letzt sei noch zu erwähnen das zeitgleich somit 2x soviel Verbindungen aufgebaut werden könnten und das Laden von mehreren Hosts somit Parallel erfolgen kann.

Heute – Der oder das ETag

ETag steht für Entity-Tag, dieses Tag kann ein Bestandteil eines HTTP Headers sein. Das Tag beinhaltet einen Hexadezimalen Wert welcher Auskunft über den Inhalt einer Datei gibt. Das ETag wird bei modernen Browsern zur Cachesteuerung eingesetzt und stellt quasi eine Quersumme einer Datei dar.

Beim ersten anfordern einer Datei teilt der Webserver im HTTP Header das Etag dieser mit, der Browser verarbeitet diese Datei und speichert beim ablegen im lokalem Cache das zugeordnete Etag. Ein Beispielheader des “Erstkontakts” mit eingebettetem Etag ist in Abb.1 zu sehen.

Der Browser nutzt das ETag um die Datei auf dem Webserver mit der lokal im Cache liegenden zu vergleichen, ist das ETag beider Dateien identisch so kann davon ausgegangen werden das sich an der Datei nichts geändert hat und der Cache somit Valide ist – sprich die Datei wird nicht erneut geladen sondern aus dem lokalem Cache geholt. Wird der Inhalt einer Datei modifiziert so ändert sich auch das ETag der Datei und der Webserver sendet in der Regel die Datei neu.

Erhält der Browser in einem HTML Dokument z.B. die Anweisung die Datei bild.jpg zu laden prüft er zuerst ob eine bild.jpg im lokalem Cache liegt. Wenn dies so ist, und lokal ein ETag dazu gespeichert wurde, wird dem Webserver in der Bildanfrage direkt “mitgeteilt” welche Version der Browser lokal gespeichert hat. Dies Geschieht in der Form:

If-None-Match: “877f3628b738c76a54″

Eine Beispiel für einen vom Browser, zur validierung, verschickten Etag ist in Abb.2 zu sehen. Stellt der Webserver nun fest das dieses ETag der bild.jpg identisch mit dem eigenen ist, so wird nur ein “304 Not Modified” entgegnet (Abb.3) anstatt die ganze Datei erneut quer durch das Internet zu senden. Weicht der Etag jedoch ab so wird der Cacheeintrag als nicht valide betrachtet. Die ebenfalls überlieferte If-Modified-Since anfrage darf bei einem nicht passendem Etag vom Webserver nicht berücksichtigt werden. Dies hat daher in der Regel zur Folge das die Datei erneut vom Webserver übertragen wird.

Nach zugehöriger RFC2616 darf der Browser auch direkt mehrere Etags, Kommagetrennt, in einem Header anfragen. Dieses Verhalten habe ich in freier Wildbahn aber noch nicht beobachten können.

unterschiedliche Etag Typen

Ohne nun trocken die RFC zu rezitieren möchte ich nur kurz auf Technische Unterschiede der Etags eingehen, wem das Technische Bla Bla bereits zu viel wird kann diesen Absatz in aller Ruhe überspringen ^^

In der Theorie könnte ein Etag ein zufällig generierter Wert sein, dies ist aber unsinnig da der Wert ja aufzeigen soll ob sich eine Datei verändert hat oder nicht. Daher haben sich im Apache folgende drei Methoden etabliert; Zum einen wäre da die Methode MTime (Last Modified) Information des Dateisystems, nach dieser ändert sich das Etag nur dann wenn die Datei im Filesystem des Servers neu geschrieben wird. (z.B. neue Version via FTP hochgeladen) Eine weitere Möglichkeit ist die Generierung des Tags anhand der Dateigröße, Size. Dies ist jedoch alleinstehend recht uninteressant denn eine exakte Dateigröße kann bei kleinen Änderungen schnell zum Nebeneffekt führen das neue Grafiken im Browser nicht angezeigt werden. Die dritte Möglichkeit ist die INode der Datei im Filesystem. Ohne nun in Dateisystemfunktionen abzutauchen; (Da schreiben andere Menschen ganze Bücher von) Die Inode ist platt gesagt die Hausnummer einer Datei im Dateisystem. Diese ist alleine wie auch die Size nicht tauglich als Etag. Anders als bei “Size” gibt es hier sogar noch einen weiteren Nachteil, verwendet man über mehrere Server verteilte Dateisysteme (Stichwort CDN) so ist die Inode von Webserver zu Webserver unterschiedlich.

Eine wesentlich Ressourcen intensivere Möglichkeit wäre z.B. bei dynamischem PHP Content einen Etag manuell anhand eines selbst generierten Hashwertes des Contents zu generieren.

Neben den eigentlichen Typen gibt es noch die Unterscheidung in starke und schwache Etags, diese Mitteilung sendet ebenfalls der Webserver beim Erstkontakt. Ein starker Etag darf eigentlich nur dann verwendet werden wenn man sagen kann das alle Daten die diesen Etag verwenden dann auch absolut identisch sind (Bit-für-Bit). Nutzt man z.B. nur eine der oben aufgeführten Methoden so müsste dies als schwacher Etag gekennzeichnet werden denn in der Theorie können ja duzende Dateien auf dem Webserver z.B. die exakte MTime haben. Ein schwacher tag wird durch ein vorangestelltes W/ gekennzeichnet.

Beispiel:           ETag: W/”877f3628b738c76a54″

Verwendung im Apache

Im Apache Webserver ist die Verwendung des ETags anhand der FileETag Direktive möglich, als Parameter werden die im vorherigem Absatz beschriebenen Methoden akzeptiert. Je nach Hostkonfiguration ist das Etag per Default nicht eingeschalten, hat man Zugriff auf seine Apache Config so kann man dies manuell durch den Eintrag:

FileETag All

in der httpd.conf nachholen. Wird es vom Hoster nicht untersagt kann die Direktive auch direkt in der .htaccess mit selben Befehl gesetzt werden. Ist beides nicht möglich oder führt zu einem “Serverfehler 500” so fragt man am besten beim Hoster nach ob dies für den eigenen Virtuellen Host eingeschaltet werden könnte.

Unsinnige Verwendung des Etags

Nicht immer ist es sinnvoll ein Etag auch zu verwenden, bei statischen Inhalten die sich niemals ändern werden ist ein Etag unnötiger Kommunikationsaufwand. Vielleicht ist schon mal aufgefallen das einige Große Webseiten ihre statischen Inhalte wie Bilder von einer anderen Subdomain liefern, dies hat unter anderem den Vorteil das man hier die Header global für die Subdomain einstellen kann. Nehmen wir an man betreibt eine Newsseite die pro Tag mehrere Artikel veröffentlicht, in den Artikel sind passende Bilder vorhanden die das beschriebene dokumentieren. In der Regel ändern diese Bilder sich nicht sondern werden bei Veröffentlichung des Beitrages online gestellt und verbleiben unverändert dort. Hier nun den Browser und Webserver jedes mal eine Etag Validierung durchführen zu lassen ist unsinnig da man davon ausgehen kann das die Bilder sich nicht verändern. Um dies zu vermeiden setzt man auf das Bilderverzeichnis, oder Subd
omain, FileETag None. Statt des tags verwendet man nur den max-age Header mit einer sehr hohen Angabe. (Angabe in Sekunden z.B. 31536000 für ein Jahr) Aber dazu mal in einem anderem Posting mehr ;)

Um dem angesprochenem Problem, mit Etags bei über mehrere Servern verteilten Seiten, Herr zu werden ist es Sinnvoll dem Apache mitzuteilen das er die Inode Methode nicht berücksichtigen soll. Der passende Aufruf wäre: FileETag MTime Size
Damit wird der Etag nur aus Modified Time und Dateigröße gebildet.

Besseres Etag Handling in PHP

Ok, letzter Absatz ;) Endspurt. Verfügt man über eine in PHP geschriebene Webseite so kann man den Etag bei z.B. Contentseiten oder Stylesheets selbst ausgeben. In Contentseiten nimmt man einfach den darzustellenden Inhalt und generiert daraus einen md5 diesen Hash übergibt man per Funktion in den HTTP Header:  header(‘ETag: “’.md5($content).’”’);

Möchte man das ganze weiter führen so könnte man einen Wrapper via mod_rewrite für JS und CSS Daten auf dem Webserver bauen, dieser würde dann die CSS Files dynamisch anhand ihres Inhaltes mit einem Sicherem Etag versehen. Bei unserem Hostingprojekt 3Q für kleine-mittelständische Unternehmen handhaben wir dies erfolgreich um die Clientperformance zu steigern und Probleme mit nicht mehr validen Caches zu verhindern. Wichtig beim setzen des Etags über PHP ist natürlich das dann das komplette Handling, also auch das auswerten der “If-None-Match” Header über PHP erfolgen muss. Wie genau würde hier nun den sowieso schon sehr gedehnten Rahmen sprengen, bei Interesse komme ich darauf gerne mal in einem gesondertem Posting zurück.

Weiterführende Links / Quellen

• RFC2616 ETag response-header specification,
• Apache Direktive FileETag
• ETag in lighttpd
• Weiterführende Lektüre “Concerning Etags and Datestamps” von Lars R. Clausen als PDF Download

“Script Injections” oder auch XSS “Cross Site Scripting” genannt, sind ja nichts unbekanntes mehr, in meinem htaccess Artikel habe ich ja bereits darüber geschrieben. Um das ganze Thema etwas weiter aufzugreifen habe ich mich mal etwas weiter damit beschäftigt. Im Bot-Trap.de Forum (Sollte sich jeder Webmaster mit Spamproblemem auf der Seite übrigens mal ansehen) gab es in einem Beitrag unnötige Arbeit… bereits seit geraumer Zeit einige Diskussionen zum Thema Sicherheit und seit kurzem auch das Thema Injections. Auf der Suche im Web nach einer Liste mit Statistiken über meist verbreite Injection Versuche bin ich leider nicht fündig geworden.

Nach einem hin und her habe ich dann meine .htaccess Regeln zum Blocken von GET und POST Injections angepasst um nicht nur einfach ein Forbidden zu liefern, sondern den “möglichen Angreifer” direkt zu protokollieren. Das Scipt reagiert auf eine angepassten .htacces Eintrag:

#  mod_rewrite
RewriteEngine On
# Log injection trys through Query String
RewriteCond %{REQUEST_METHOD} =GET [OR]
RewriteCond %{REQUEST_METHOD} =POST [OR]
RewriteCond %{REQUEST_METHOD} =HEAD
RewriteCond %{QUERY_STRING} !injectlog\.php [NC]
RewriteCond %{QUERY_STRING} (ftps?|https?):// [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC]
RewriteRule .* /injectlog.php [L,QSA]

Hier wird anstatt den Verdächtigen einen Block vor die Nase zu setzen die Anfrage 1:1 an injectlog.php weitergeleitet, dieses Script ist natürlich mit der ersten Version erst mal ein Proof of Concept. Es besteht die Möglichkeit a) die Angriffe lokal zu protokolieren, dieses Protokoll beinhaltet Uhrzeit & Datum, IP des Angreifers, Requestmethode (GET/POST), Aufgerufene Datei, den Query String und den User Agent (Browser)

Zu dem Lokalem Logfile gibt es noch, der eigentlichen Idee entsprechend, die Möglichkeit das ganze in eine Datenbank zu submitten. Wie gesagt, erstmal proof of concept, die DB wird später natürlich öffentlich verfügbar sein da diese Daten ja doch für den ein oder anderen Webentwickler recht interessant sein können. Aus dem Grund der Öffentlichkeit werden auch nicht alle Daten übermittelt, in späteren Script Versionen könnte man das optional einstellbar gestalten. Derzeit wird bei einem Submit in die Datenbank nur die Version des Scripts, Request Methode, Aufgerufene Datei, Query String und der User Agent übermittelt.

Die Installation ist simpel, einfach die injectlog.php in das root dir der Webseite kopieren und die obige htaccess Anweisung in die eigene .htaccess Datei einfügen.

Der Quelltext

Das Projekt ist nun auf einer Extra Seite ausgegliedert, weitere Informationen gibt es unter abwehr.solariz.de

…wird sich der ein oder andere – zu recht- fragen. Nun unter “Hotlinking” versteht man das fremde verlinken von Inhalten, in diesem Fall eben Bildern. Das Web besteht heutzutage zu großen teilen aus Bilder und Videos oder besser gesagt Multimedialen Inhalten. Diese treiben natürlich auch den Traffic in die Höhe. Wenn man nicht den Luxus hat auf Traffic kein Auge werfen zu müssen so kann es sich schnell bemerkbar machen wenn die eigenen Bilder bei der Google Bildersuche hoch gerankt werden. Dies bedeutet jede Menge Traffic ohne wirklich an der Seite interessierte Personen mit zu bringen.

Aber auch bei Seitenbetreibern die nicht nach “Traffic == Geld” gehen kann es unerwünscht sein wenn Fremde Webseiten sich mit den eigenen Bildern oder schlimmer Videos schmücken. Dies gilt es hier nun mit einfachen Mitteln zu unterbinden.

Der Apache dein Freund und Helfer

Wie so viele im World Wide Web setze ich auch auf den Apache als Webserver. Daher beschränke ich das Tutorial darauf.
Nun wie in der ersten Grafik zu sehen ist es ja immer der User Browser der die Daten bei unserem Webserver anfordert, nicht die fremde Webseite selbst. Daher ist es ein falscher Lösungsansatz die IP der fremden Seite zu blocken. Dies bringt uns in diesem Vorhaben nicht zum Ziel. Die Fremdseite stellt unser Bild oder unseren Multimedia Inhalt also z.B. via normalem IMG tag da. Also  Der “Trick” ist nun einfach den vom Browser übermittelten Referer auszulesen und diesen auszuwerten. Im normalfall sollte dieser entweder a) leer sein oder b) die Domain unserer eigenen Seite enthalten. Alles andere wären unerwünschte Anforderungen. Klar ist dies nicht die ultimative Sicherheit da einige Software Produkte die sich “Internet Security Lösungen” schimpfen eine Funktion haben den Referer zu filtern. Dies hilft aber dem Betreiber der fremden Webseite nichts da er in der Regel nicht davon ausgehen kann das alle seine Besucher solch eine Software verwenden.

Wie in Bild #2 zu sehen ist, übernimmt unser Webserver hier nun die Filterarbeit. Wenn ein “Fremder” verweis erkannt wird haben wir nun die Möglichkeit diesen einfach zu unterbinden oder alternativ einfach etwas anderes zurück zu liefern. Entscheiden wir uns für zweites würde der Besucher der fremden Seite anstatt des schönen Fotos nun nur noch ein Bild mit der Aufschrift “Dieser Aufruf ist nicht gestattet, besuchen sie MeineSeite.de” Blöd für den Betreiber. Nun bleibt ihm nur die Möglichkeit das Bild zu kopieren und auf seinem Webserver zu packen womit er sofern ich dies nicht ausdrücklich erlaube allerdings eine schwerwiegende Copyright Verletzung eingeht.

Nun gibt es aber jedoch auch gute Hotlinker im Internet die man gewähren lassen möchte, dies sind z.B. Seiten eines Kollegen oder eine weitere Homepage von einem selbst oder auch Image Indexer wie z.B. Google Bildersuche. Dies müssen wir dann als Ausnahme genehmigen.

Als einfaches Beispiel für oben genanntes lässt sich eine Hotlink Protection wie folgt erzeugen. Man fügt im Verzeichnis in dem auf der eigenen Webseite die Bilder liegen eine .htaccess datei ein und ergänzt diese mit der Anweisung:

### HOTLINK PROTECTION
RewriteEngine on
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?wwcl. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?wcg-europe. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?planetlan-gmbh. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?dcmm. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?nuxnux. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?solariz. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?planetlan. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?maxga. [NC]
RewriteCond %{HTTP_REFERER} !^http://([^.]+.)?localhost [NC]
RewriteCond %{HTTP_REFERER} !google. [NC]
RewriteCond %{HTTP_REFERER} !search?q=cache [NC]
RewriteCond %{REQUEST_URI} !^/stophotlink.gif$
RewriteRule .(gif|jpg|png)$ /stophotlink.gif [NC,L]

Wie man sieht sind  hier 11 Seiten als Ausnahme definiert. Alles andere wird umgeleitet auf die Datei stophotlink.gif

Viel Spaß damit.