Veröffentlicht am

Seltsame User-Agents aussperren, Search-Bots reinlassen

Vor lauter Bots kann man sich als Webseiten-Betreiber zur Zeit ja kaum noch schützen. Die nervigsten und gefährlichsten sperre ich bei unseren Webprojekten seit gewisser Zeit schon über die Webserver-Konfiguration oder .htaccess Datei aus. Beispielsweise die Kennung „Mozilla/4.0“ oder „Mozilla/5.0“ ohne jegliche weitere Information.

Normale Browser-Kennungen, wie beispielsweise die vom Internet Explorer oder von Firefox, beginnen in der Regel auch mit dieser Kennung, beinhalten dann aber weitere Informationen dahinter in Klammern.

Zugriffe, die in der Browser-Kennung keine weitere Information enthalten, sind in der Regel Angreifer-Tools, die als Ziel haben, Sicherheitslücken zu finden oder Spam-Kommentare zu hinterlassen.

Seit kurzem sind mir aber sehr häufig auch Zugriffe aufgefallen, die vom MSNBot, also dem Suchmaschinen-Spider von Bing, Microsoft’s Suchmaschine, kommen – und die sich auch nur mit „Mozilla/4.0“ identifizieren. Den will ich reinlassen.

Glücklicherweise kann man den MSNBot anhand der IP-Adresse identifizieren.

Also sieht meine mod_rewrite-Rule für die .htaccess so aus:

RewriteEngine On

RewriteCond %{REMOTE_ADDR} !^65.55.
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[1-9]\.[0-9]$ [NC]
RewriteRule ^.*$ - [F,L]

Mit der ersten Rewrite Condition wird festgelegt, dass die folgende Regel nur für Zugriffe von IPs gilt, die NICHT Mit 65.55. anfangen.

Die folgende Condition beschränkt das ganze weiter auf User_Agent-Strings, die die Form „Mozilla/“ gefolgt von einer Versionsnummer in der Form „x.y“ (x und y nur einstellie Ziffern) haben.

Und die Rewrite-Rule am Ende legt fest, dass alle derartigen Zugriffe mit einem Forbidden (HTTP Fehler 403) beantwortet werden sollen.

Veröffentlicht am

Mit der .htaccess gegen Hotlinking von Bildern

Es gibt ein paar unbelehrbare, die der Meinung sind, dass man Dateien – insbesondere Bilder – von anderen Servern einfach so in die eigene Webseite „reinladen“ kann. Ist ja technisch kein Problem – sogar gewollt. Von der rechtlichen Fragestellung mal ganz abgesehen sieht es aber so aus, dass derjenige, der die Dateien auf seinem Webserver liegen hat, den Traffic bezahlen muss, den der verursacht, der die Bilder in seiner Webseite verwendet. Von der Rechenleistung und der Netzwerkbandbreite mal ganz zu schweigen.

Was kann man dagegen tun?

Erstens kann man natürlich denjenigen Kontaktieren, der die Daten verwendet. Der ist oft aber gar nicht aufzuspüren.

An dem Punkt helfen dann technische Maßnahmen. So weit auf dem Webserver mod_rewrite installiert ist reichen zwei einfache Zeilen in der .htaccess.

Da die Problemkinder oft Grafiken sind, gibt es eine wirksame, eigentlich ganz unterhaltsame Option: Statt der angeforderten Grafik verschickt man eine andere, riesig große Grafik in grausamen Farben. Wenn man die einfarbig hält, dann bleibt die Dateigröße auch bei einer hohen Pixelzahl schön klein – in der Regel wesentlich kleiner als die zu ersetzende Datei. Und wenn alles gut läuft, dann will die Ersatzgrafik sowieso niemand sehen, also wird sie auch nicht so oft abgerufen 🙂

Also: Datei hochladen und folgende Zeilen in die .htaccess:

RewriteCond %{HTTP_REFERER} bandbreiteklauer\.com [OR,NC]
RewriteCond %{HTTP_REFERER} beepworld\.de [OR,NC]
RewriteCond %{HTTP_REFERER} facebook\.com [NC]
RewriteRule jpg$ /dont_hotlink.png [L]

Dabei einfach „bandbreiteklauer\.com“, „beepworld\.de“ und „facebook\.com“ durch die Domains der Bösewichte ersetzen. Will man mehr oder weniger Server aussperren, dann einfach weitere Zeilen mit RewriteCond einfügen. Es ist nur wichtig, dass die letzte Zeile am Ende nur [NC], alle anderen aber [OR,NC] enthalten, damit das ganze als ein zusammengehörender Block gehandhabt wird.

Veröffentlicht am

Benchmarking PHP: eAccelerator und andere OpCode Caches

Die Aufgabenstellung: Die Applikationen aus unserem Hause sollen so stabil und leistungsfähig laufen wie möglich. Ein wichtiger Bestandteil der Applikations-Infrastruktur stellen in unserem Bereich die Webserver dar, die PHP-Unterstützung mitbringen müssen.

Bei meinen Versuchen, die bestmögliche, unseren Anforderungen entsprechende Serverkonfiguration zu finden, habe ich ein paar Benchmarks gemacht, die ich hier mit der Welt teilen möchte.

Die Benchmarks

Im ersten Schritt habe ich diverse OpCode Caches und den ZEND Optimizer ausprobiert.

Das Testsystem ist ein DELL PowerEdge R200 Server mit einem Core2Duo E4500 Prozessor und 4GB RAM. Darauf zugegriffen wurde über ein lokales 100 MBit Netzwerk.

Der Server läuft auf Debian Linux (64bit), als Webserver-Software kam Apache 2.2.3 mit PHP 5.2.0 über mod_php zum Einsatz. Allesamt wurden aus den Debian-Paketen installiert.

Für meine Benchmarks habe ich drei verschiedene Scripte verwendet:

  • KCAPTCHA
    Ein Script, das Captcha-Bildchen erzeugt. Dieses Script verwendet zwar relativ viel die GD2 Grafik-Library, wodurch ein großer Teil des Programmablaufs genaugenommen „fix“ ist, weil die Geschwindigkeit von GD2 nicht durch die Optimierungen verändert wird. Das Programm führt aber auch einige Schleifen und Berechnungen in PHP durch, um die Grafik vor der Ausgabe zu verzerren.
  • Viel Code, wenig Ausführung
    Das zweite war ein eigentlich sehr einfaches, selbst geschriebenes Script, das nicht viel mehr gemacht hat, als die Zahlen von 1 bis 100 in einer Schleife auszugeben. Zusätzlich habe ich allerdings (absichtlich sinnloserweise) eine 20 KByte große PHP-Datei includiert, die einige Funktionen enthält, die ich bei meinen Projekten regelmäßig verwende. Damit sollte sich die reine Aufruf-Geschwindigkeit messen lassen, ohne durch eine Script-Laufzeit groß beeinflusst zu werden.
  • WordPress
    Last, but not least, um etwas praxisnäher zu testen: Eine WordPress 2.3-Installation, in die ich mit ein paar Blindtexten gefüllt habe. Als Datenbank kam eine ebenfalls lokal auf dem Server installierte MySQL-Instanz zum Einsatz.

Als Optimierer kamen zum Einsatz:

An den Einstellungen der verschiedenen Optimizer habe ich nichts geändert, also so weit überhaupt möglich immer die Standard-Einstellungen verwendet.

Was ist ein OpCode Cache?

eAccelerator, XCache und APC stellen OpCode Caches dar. Ohne einen solchen wird bei PHP bei jedem Script-Aufruf das entsprechende Script frisch „compiliert“ und dann ausgeführt. Wenn man aber einen OpCode Cache installiert, so werden die compilierten Scripte im Speicher gehalten, so dass sie bei einem weiteren Aufruf aus der Konserve verwendet werden können. Das spart ab dem zweiten Aufruf die Compilierungs-Zeit.

Einige der Caches bringen auch noch einen Optimizer mit.

Was ist ein OpCode Optimizer?

Der ZEND Optimizer dagegen ist ein OpCode Optimizer, der versucht, PHP-Scripte bei der Compilierung zu optimieren, sie also schneller zu machen. Als Beispiel kann man sich beispielsweise eine „kleine Schleife“ vorstellen:

for ($i = 0; $i < 3; $i++) {
echo 'Schleife<br />';
}
echo 'Schleife<br />';
echo 'Schleife<br />';
echo 'Schleife<br />';

Beide Beispiele ergeben das gleiche Resultat. Das obere Beispiel ist als Programmcode vielleicht ein bisschen „hübscher“ anzusehen. Trotzdem ist die untere Variante etwas schneller. Es müssen keine Variablen initialisiert, verglichen und hochgezählt werden, es muss nicht „im Programm zurückgesprungen“ werden. Klarer Geschwindigkeitsgewinn. Noch schneller wäre es als eine einzelne „echo“-Anweisung.

Solche Muster zu erkennen und zu ersetzen ist die Aufgabe eines OpCode Optimizers.

Benchmark 1: KCaptcha

Jetzt aber zu den Testergebnissen. Um die Geschwindigkeit zu überprüfen kam das Tool Apache Benchmark. Mit diesem habe ich von einem anderen Rechner über’s Netzwerk jeweils 10.000 Anfragen an die drei Test-Scripts abgefeuert, jeweils mit 20 parallel laufenden Anfragen.

Zuerst KCAPTCHA:

Die Skala unten gibt an, wie viele Sekunden für die 10.000 Aufrufe benötigt wurden.

Klarer Gewinner hier: Der eAccelerator.

zend + eaccelerator 177,54 Sek.
eaccelerator 177,60 Sek.
xcache 183,39 Sek.
apc 187,46 Sek.
none 190,00 Sek.
zend 225,10 Sek.

Auf den ersten Blick etwas überraschend mag wirken, dass der ZEND Optimizer sowohl auf dem ersten, als auch auf dem letzten Platz zu finden ist – ja sogar langsamer ist, als wenn man ganz auf den Einsatz einer Optimierung verzichtet. Die Lösung: Im Alleingang ohne OpCode Cache braucht der Optimizer mehr Zeit zum Optimieren, als durch die Optimierungen eingespart wird.

Im Gegenzug dazu kann der Optimizer in Kombination mit dem Cache seine Stärke ausspielen: Hier muss nur ein mal optimiert werden. Bei den folgenden 9.999 Aufrufen wird auf den bereits optimierten Code zugegriffen. Bei KCAPTCHA war die Ersparnis aber eher gering, was an der Struktur des Programmcodes liegt. Hier ist einfach nicht viel zu optimieren.

Benchmark 2: Test-Script „viel Code, wenig Ausführung“

Ein ähnliches Bild ergibt sich beim zweiten Testscript:

Hier tritt noch mehr in den Vorschein, dass der ZEND Optimizer die Laufzeit optimiert. Da dieses Script aber nahezu keine „Laufzeit“ hat, sondern nahezu nur aus Compilieren besteht, liegt der ZEND Optimizer auch dieses mal ganz hinten. Wieder ist der eAccelerator der Gewinner:

eaccelerator 2,40 Sek.
apc 2,48 Sek.
xcache 2,51 Sek.
zend + eaccelerator 2,85 Sek.
none 11,60 Sek.
zend 13,80 Sek.

Man sieht aber eindeutig den Vorteil, den ein OpCode Cache mitbringt. Von 11,6 Sekunden auf 2,4 Sekunden sind durchaus spürbar.

Benchmark 3: WordPress

Zum Abschluss noch ein „praxisnäheres“ Beispiel: Im dritten Durchlauf habe ich noch eine WordPress Installation getestet, indem ich 10.000 mal die Startseite aufgerufen habe. Ziel war es, herauszufinden, ob der ZEND Optimizer an dieser Stelle seine Asse ausspielen kann.

Auch dieses mal liegt der ZEND Optimizer ohne OpCode Cache abgeschlagen hinten. Was mich allerdings ein bisschen überrascht hat: Mit eingeschaltetem eAccelerator schnitt er immer noch schlechter ab, als der eAccelerator alleine.

eaccelerator 490,74 Sek.
xcache 501,41 Sek.
apc 501,45 Sek.
zend + eaccelerator 506,40 Sek.
none 873,98 Sek.
zend 928,10 Sek.

Fazit

Was die OpCode Caches angeht kann man eindeutig feststellen, dass es sich sehr lohnt, einen zu installieren. Der eAccelerator hat bei all meinen Tests als Sieger abgeschnitten, aber auch die anderen beiden Kandidaten haben sich nur unwesentlich schlechter geschlagen. Die Geschwindigkeitsgewinne gegenüber „Kein Cache“ sind schwer in Zahlen auszudrücken, da sie von Anwendung zu Anwendung schwanken (abhängig des Verhältnisses „Compilierung“ zu „Laufzeit“). Gerade bei WordPress, der getesteten Anwendung lag sie aber bei spürbaren 78% Leistungssteigerung.

Dagegen muss ich anhand der Ergebnisse meiner Tests von der Installation des ZEND Optimizers abraten, so lange nicht wichtige Gründe dafür vorliegen, warum er laufen muss. Im Normalfall ist er kontraproduktiv und verbraucht mehr Ressourcen als er einspart.

So viel zum ersten Teil meiner Forschungsreise. Im nächsten werde ich die Performance verschiedene Caching-Mechanismen vergleichen.