Schutz der Website oder des Blog vor massiven Zugriffen durch Crawler oder Angreifer
Heute bekam ich über mein Monitoring-Tool mal wieder eine Mail, dass mein Blog gerade down ist. Bei allen, die das vorhin getroffen hat, möchte ich mich hiermit auch entschuldigen. Aber wieso war mein Blog mal wieder down, wo er doch in letzter Zeit so gut gelaufen ist?
Crawler: Plage oder Segen?
Jeder von uns, der eine Website hat freut sich wohl, wenn den Google Crawler regelmäßig vorbeischaut und dabei möglichst alle neuen schon nach wenigen Minuten in den Index befördert. Da der Google Crawler dabei auch automatisch auf die Performance einer Website achtet um kleine Seiten nicht zu überlasten, fällt es auch nicht weiter auf, wenn er gerade am Werk ist.
Aber leider gibt es nicht nur den Google Crawler sondern mittlerweile eine unüberschaubar große Anzahl davon. Heute hat sich also ein neuer Crawler ans Werk gemacht und meine Website im Turbogang mit Anfragen beschossen. Das ist für den kleinen V-Server dann doch etwas zu viel geworden und er hatte innerhalb kürzester Zeit eine Auslastung von 4500%!
Aber wie kann man sich nun vor solchen Crawlern schützen und möchte man das auch. Wenn man nämlich einen Crawler blockiert, dann kann der Dienst dahinter die Website nicht mehr indizieren und man verliert eventuell neue Nutzer, die auf die eigene Website über diesen Dienst aufmerksam geworden wären. Daher habe ich bei meiner Website nicht kategorisch alle Crawler außer denen der großen Suchmaschinen ausgeschlossen.
Einzelne Crawler sperren
Um Crawler den Zugriff auf die eigene Website zu verweigern setzt man eine Datei mit dem Namen robots.txt ein. Nachdem ich also den Namen des Crawlers über die Logfiles meines Servers rausgefunden hatte, konnte ich ihn zukünftig ausschließen, indem ich folgende Zeilen zur robots.txt Datei hinzugefügt habe:
User-agent: 008 Disallow: /
Das Problem an der Sache ich nur, dass der Crawler diese Änderung nicht sofort bemerkt. Eventuell prüft er die Datei ja nur einmal pro Stunde oder sogar nur einmal am Tag oder in der Woche. Bis er also aufhört die Website mit Anfragen zu überfluten müssen andere Maßnahmen getroffen werden.
Zugriffe von einer IP-Adresse blockieren
Ich musste also nun den Zugriff durch den Crawler anhand seiner IP-Adresse blockieren. Das geht am einfachsten über die Datei .htaccess die sich meistens im Wurzelverzeichnis der Website befindet. Dort habe ich folgende Zeilen eingefügt:
# block potentially harming clients order allow,deny deny from 77.45.136.22 deny from 91.218.229.49 allow from all # END: block potentially harming clients
Ich habe hier in diesem Beispiel zwei IP-Adressen blockiert. Was es mit der zweiten auf sich hat erkläre ich euch gleich. Ihr könnt hier also auch mehrere IP-Adressen blockieren, müsste aber pro Adresse eine Zeile verwenden. Damit verhindert ihr zwar die Anfrage selbst nicht (was auch nicht möglich ist) aber die Anfrage wird hierbei vom Apache-Server direkt zurückgewiesen, ohne dass beispielsweise WordPress etwas davon mitbekommt und anfängt die angeforderte Seite zu generieren. Wenn der Crawler intelligent ist, hört er auch recht bald auf eure Seite zu lesen und schaut sich vielleicht gleich mein eure veränderte robots.txt Datei an.
Hilfe gegen die bösen Jungs da draußen
Leider ist die robots.txt Datei nur eine Bitte an einen Crawler, was sie mit eurer Website tun soll. Er kann diese Information aber natürlich auch einfach ignorieren und eure Website trotzdem auslesen. Dann sollte das Blockieren mittels .htaccess Datei funktionieren, solange es ein Crawler ist, hinter dem keine bösen Absichten stecken. Denn sobald ihr den Crawler blockiert, bekommt er das natürlich mit. Er könnte dann einfach die IP-Adresse wechseln und erneut eure Seite belagern. Damit er das aber nicht so schnell mitbekommt, könnt ihr einen kleinen Trick anwenden. Oft werden solche Crawler von Programmieren eingesetzt, die den gesamten Inhalt eurer Website lesen wollen. Sie prüfen dabei vermutlich auch, ob die Seite erfolgreich angefordert werden konnte (Status Code 200) oder ob es eine erfolgreiche Weiterleitung gab (Status Code 301/302). Wieso also nicht dem Crawler einfach eine Seite zurückliefern, die Inhalt enthält, nicht aber den, den er wollte. Oder ihn einfach auf eine andere Seite weiterleiten.
Ich leite solche Angreifer gerne auf “Das Ende des Internets” um. Das ist eine witzige Seite, die wie eine typische Internet Explorer-Fehlerseite aussieht und andeutet, dass man das Ende des Internet erreicht hat. Um das zu tun fügt ihr einfach folgende Zeilen in eure .htaccess Datei ein:
# rewrite unwanted clients to the end of the internet
RewriteCond %{REMOTE_ADDR} ^77\.45\.136\.22 [OR]
RewriteCond %{REMOTE_ADDR} ^91\.218\.229\.49
RewriteRule ^(.*)$ http://www.weirdity.com/internet/eoti.html [L]
# END: rewrite unwanted clients to the end of the internet
Wenn ihr hier mehrere IP-Adressen angeben möchtet, dann müsst ihr hinter jeder Zeile, außer der letzten, noch [OR] einfügen. Außerdem müssten die Punkte mit einem vorangestellten Backslash markiert werden.
Wenn ihr zuvor schon den vorherigen Code zum Blockieren einer IP-Adresse eingefügt habt, dann müsst ihr diesen auskommentieren (indem ihr vor jede Zeile ein # Zeichen einfügt), damit die Zugriffe nicht mehr blockiert, sondern stattdessen umgeleitet werden.
Der Nutzer des Crawlers merkt im Optimalfall davon nichts. Wenn er sich dann aber im Nachhinein die gecrawlten Seiten ansieht, wird er sich über deren Inhalt wohl sehr ärgern.
Fazit
Ich habe mit den hier beschriebenen schon eingie Angriffe bzw. unbeabsichtigte Überlastungen durch Crawler abwenden können. Auch mein Server läuft gerade wieder mit gemächlichen 5% Auslastung vor sich hin. Diese Maßnahmen schützen einen zwar nicht vor professionellen oder gut organisierten Angriffen, aber gegen die oft genannten “Script-Kiddies” sollten sie ausreichen. Die suchen sich dann einfach eine Website, die sie einfacher angreifen können.
Ach ja und jetzt noch zu der zweite IP-Adresse. Diese stammt wirklich von einem Angreifer. Der wollte aber nicht meinen Server durch viele Anfragen überlasten, sondern viel schlimmer noch, er wollte Schadcode auf meinen Server laden. Dazu hat er versucht die Sicherheitslücke in der TimThumb Funktion auszunutzen, auf die ich auch weiter unten in meinem Artikel Plugins und Sicherheit: Sicherheitslücke in Filedownload Plugin geschlossen kurz eingegangen bin. Aber zum Glück verwende ich kein Plugin oder Theme, das diese Funktion nutzt bzw. eine unsichere Version von TimThumb verwendet.
Server Downtimes und keine Erklärung in Sicht
Am Freitag habe ich auf meinem Server nach Rootkits suchen lassen. Die beiden Skripte dazu stelle ich euch hier demnächst mal kurz vor. Es sah danach alles sehr gut aus. Leider war ich dann eine Weile nicht am Rechner und in dieser Zeit stürzte der Apache-Server aus bisher ungeklärten Gründen ab und war über 3 Stunden nicht erreichbar. Nach Analyse der Logfiles fand ich viele Angriffe, die auf die Sicherheitslücke in der TimThumb hindeutete. Ein Angreifer versuchte bei mir die Funktion im Plugin UberMenu zu attackieren. Es ist aber schon schlimm, dass ein “Premium Theme” eine solche Sicherheitslücke aufweist. Zum Glück setze ich dieses Plugin nicht ein. Ich habe auch ansonsten alle Plugins und Themes gelöscht, die TimThmub einsetzen.
Heute musste ich dann leider feststellen, dass der Server erneut down war. Da das Monitoring über Pingdom mir leider keine Nachricht auf mein Handy schickte, bemerkte ich es erst nach über 7 Stunden! Hiermit möchte ich mich auch bei allen Entschuldigen, die in dieser Zeit vergeblich versucht haben meinen Blog zu erreichen.
Ich weiß leider noch immer nicht, was genau zu den beiden Ausfällen geführt hat. Die einzige größere Änderung der letzten Tage war die Installation des WP Super Cache Plugins. Falls jemand von euch weiß, ob es damit zu Abstürzen des Apache Prozesses kommen kann, dann wäre ich ihm für einen Kommentar sehr dankbar.
Ich werde jetzt meinen Server ein bisschen besser im Auge behalten. Sobald ich den Fehler gefunden habe, werde ich euch natürlich sofort berichten, woran es lag. In diesem Sinne noch ein schönes Wochenende!
Einen Catch-All E-Mail Account in Plesk einrichten
Wie ich schon in verschiedenen anderer Artikel erwähnt habe, läuft dieser Blog auf einem Server mit Plesk. Für meine Domain kann ich zurzeit bei meinem Hoster nur eine einzige E-Mail-Adresse angeben. Da ich aber auch andere Adressen verwenden wollte habe ich mir die E-Mail Funktion von Plesk zunutze gemacht.
Da ich alle E-Mail-Adressen meiner Domain ohnehin auf eine einzige Adresse umleiten lassen möchte, habe ich noch einer Möglichkeit in Plesk gesucht und schließlich auch gefunden. Man kann recht einfach einen sogenannten Catch-All E-Mail-Account einrichten. Die Einstellung ist allerdings etwas versteckt.
AWStats und Webalizer für Plesk aktivieren
Ich nutze auf dem Server, auf dem dieser Blog läuft Plesk. Ich konnte dort bereits vieles aktivieren, aber eine Sache, die einfach nicht funktionieren wollte, war AWStats oder Webalizer. Dabei war es mir eigentlich egal, welchen der beiden Statistiken läuft, ich wollte es einfach nur mal zum Laufen bekommen, selbst wenn es nur allgemeine Daten zum Traffic und den Benutzern beinhaltet.
Statistiken in Plesk aktivieren
Das Ganze in Plesk zu aktivieren ist eigentlich kein allzu großes Problem. Unter “Domain -> Hosting -> Setup” kann man das jeweilige Statistik-Toll recht einfach aktivieren:

Syntax Highlighting im Vim Editor aktivieren
Ab und zu kommt es vor, dass man mal per Konsole eine Datei auf dem Server bearbeiten muss. Dabei wird oft der Vim Editor (“Vi IMproved” eine erweiterte Version des Vi Editors) verwendet. Auch ich verwende den Editor auf zwei Servern und komme einigermaßen damit klar.
Auf einem dieser Server ist aber die Syntax Hervorhebung des Vim Editors deaktiviert. Man kann diese im Vim aktivieren, indem man “:syntax enable” eingibt. Diese Einstellung geht aber nach dem Beenden des Editors wieder verloren. Wer das Syntax Highlighting dauerhaft aktivieren möchte, muss die Datei “vimrc” anpassen. Entweder ihr bearbeitet dabei nur die vimrc Datei in eurem Home-Verzeichnis, oder mit dem Administrator die systemweite vimrc Datei. Diese findet ihr in der Regel unter /etc/vim/vimrc. Dort solltet ihr folgende Zeile finden:
"syntax on
Mit dem doppelten Anführungszeichen zu Beginn der Zeile wird der Befehl auskommentiert. Wenn ihr das doppelte Anführungsuzeichen entfernt und dann die Datei speichert, solltet ihr nach einem erneuten Öffnen der Datei (oder eine anderen Datei mit Quellcode) das Syntax Highlighting sehen können. In der Dokumentation zum Vim Editor findet ihr bestimmt auch einige weitere hilfreiche Tipps.
Ich hoffe der Beitrag konnte euch weiterhelfen. Ich wollte mir schon lange mal das Buch “vi-Editor. Kurz und gut” kaufen um ein bisschen mehr über den Editor zu erfahren. Aber laut Buchbeschreibung handelt nur ein Kapitel vom Vim und da es mein Buchladen nicht hat konnte ich es mir bisher noch nicht ansehen. Aber ich habe es auf meinen Wunschzettel gesetzt. Vielleicht findet sich ja jemand, der es mir schenken möchte
RewriteRule mit Leerzeichen in der Zieladresse
Auf einer Seite die ich betreue wurde ich vor kurzem vor die Aufgabe gestellt eine RewriteRule in der .htaccess zu definieren, die auf eine PDF zeigt, die ein Leerzeichen im Dateinamen enthält. Das war gar nicht so einfach rauszufinden und selbst im sehr guten Forum von modrewrite.de konnte ich keine geeignete Lösung finden.
In URLs werden Leerzeichen einfach mit der Zeichenkette %20 ersetzt, aber das alleine führt noch nicht zum Erfolg. Da das Prozentzeichen ein spezielles Zeichen in Rewrite Rules darstellt muss es mit einem Backslash escaped werden. Eine funktionierende Rewrite Rule mit einem Leerzeichen könnte also wie folgt aussehen:
RewriteEngine on RewriteRule ^kurzer-dateiname.pdf$ dateiname\%20mit\%20Leerzeichen\%20.pdf
Wer also den Dateinamen nicht ändern kann um Leerzeichen zu ersetzen (z.B. durch Unterstriche) kann mit dieser Regel trotzdem einen schöneren/kürzeren Dateinamen über die .htaccess anbieten.
Das war es auch schon. Heute gibt es mal nur einen kurzen Artikel, aber viel mehr gibt es auch nicht dazu zu sagen. Außer vielleicht, dass ihr niemals versuchen solltet ein Leerzeichen in der Zieladresse zu verwenden, da sonst die gesamte .htaccess ungültig wird und der Server einen 500 Fehler für jede Seite zurückliefert.
Ich hoffe der Tipp konnte euch weiterhelfe. Kommentare sind wie immer gern gesehen!
Website oder Blog mit der mod_deflate Komprimierung beschleunigen
Ich wollte schon lange eine Komprimierung aller Dateien auf meinem Server aktivieren, aber alle Versuche die Komprimierung über das Apache Module mod_deflate oder mod_gzip zu aktivieren liefen ins Leere. Ich fand ständig super aufwändige Anleitungen, wie ich mir das selbst kompilieren und dann mit vielen Anpassungen unter Apache zum Laufen bekomme. Ich bin aber immer davor zurückgeschreckt es auch umzusetzen, da ich kein ausgewiesener Linux und Apache Profi bin.
An meinem Geburtstag habe ich dann durch Zufall auf der Suche nach einem anderen Problem gesucht habe unter anderem auf der Website debianroot.de eine super einfache Anleitung gefunden, wie man DEFLATE einfach aktivieren kann.
Anzahl der Backups im Plesk Backup-Manager begrenzen
In meinem Artikel Plesk Backup-Manager auf 1&1 Linux Root Server einrichten habe ich bereits beschrieben was zu tun ist, um das Backup auf einem Server mit Plesk einzurichten. Beim Einsatz dieser Konfiguration bin ich allerdings sehr schnell auf ein folgenschweres Problem gestoßen.
Da ein Backup der Domain mittlerweile eine Größe von über 20GB hat reichen die 250GB des 1&1 Backup FTP-Servers nur für 10 Backups. Sobald dieser Speicherplatz verbraucht ist, werden die Daten auf dem Webserver abgelegt. Das fatale dabei ist, dass dadurch der gesamte Speicherplatz des Servers langsam aber sich aufgebraucht wird. Wenn der Speicherplatz belegt ist führt es im schlimmsten Fall dazu, dass MySQL keine temporären Tabellen mehr erzeugen kann und euer Server ist somit nicht mehr in der Lage die Anfragen zu bearbeiten. Also im Klartext: Euer Server funktioniert im schlimmsten Fall nicht mehr.
Plesk Cronjob für ein PHP-Skript mit Parametern einrichten
Bei vielen Webhosting Paketen gibt es die Möglichkeit einen Cronjob einzurichten. Leider musste ich nach dem Umstieg von einem 1&1 Managed Homepage Server auf einen 1&1 Linux Root Server feststellen, dass diese Option im Control Center nicht mehr verfügbar war. Auch meine Suche nach dem “Crontab” in Plesk war erst einmal erfolglos, da die Funktion an der beschriebenen Stelle nicht zu finden war. Durch Zufall habe ich sie dann doch gefunden.

Mail Versand per SMTP auf 1&1 Linux Root Server einrichten
Ich bin auf einen neues Problem mit dem Standard-Setup der 1&1 Linux Root Server getoßen. Vor dem Umzug auf den Root Server wurde ein 1&1 Managed Homepage Server genutzt. Dieser hat keinen eigenen Mailserver installiert. Der Root Server hingegen verschickt die Mails direkt an den Empfänger und nicht wie der Managed Server über den 1&1 SMTP Server. Doch wieso ist das ein Problem?
Nun, durch das zunehmende Problem von SPAM werden bei den meisten Mailanbeitern alle Mails von Severn abgelehnt, die nicht als vertrauerswürdiger Mailserver in einer Whitelist eingetragen sind. Der eigene Root-Server ist in diesen Listen allerdings fast nie gelistet. Beim Versuch eine Mail an einen Freemailer wie z.B. GMX zu senden resultiert dann in einer Ablehnung seitens GMX. Diese sehen in der Regel wie folgt aus:








