ScriptBlogger

Unser Saas für Online Terminvereinbarung hat heute ein größerers Update erhalten. Enthalten sind eine Menge Fehlerbehebungen sowie viele kleine und einige große Neuerungen.

So lässt sich der Administrationsbereich nun per Zwei-Faktor-Authentifizierung sichern. Dabei ist aufgefallen, dass die Server-Uhr um eine Minute nachging. Leider macht das die Zwei-Faktor-Authentifizierung unmöglich. Aber zum Glück gibt es Zeit-Server, mit denen man den Server automatisch synchronisieren lassen kann. :-)

Am Anfang der Woche haben wir endlich den Server auf PHP 7 aktualisiert. War höchste Zeit. Jetzt läuft alles noch schneller und sicherer. :-)

Keine Ahnung, ob das normal ist, aber auf dem Managed Server bei Domainfactory kommen sich zeitgleich gestartete Cron-Jobs in die Quere. Einer der beiden Cron-Jobs stößt eine Datenbanksicherung per mysqldump [...] | gzip an und der andere Cron-Job ist ein PHP-Script.

Es stellte sich heraus, dass die Datenbanksicherung nicht vollständig ausgeführt wird, wenn zur gleichen Zeit ein anderer Cron-Job läuft. Hat möglicherweise etwas damit zu tun, dass beide auf die selbe Datenbank zugreifen. Das ist wahrscheinlich eine Sache, die man von vornherein hätte vermeiden sollen. Jetzt sind wir auf jeden Fall schlauer. ;-)

Zugegeben, der Titel ist etwas irreführend. Nicht Twitter allein hat dafür gesorgt, dass unser Server kurzfristig überlastet war. Neben dem Twitterbot haben auch UnwindFetchor, TweetmemeBot, Twisted PageGetter, real-url.org, Voyager und andere den Server überlastet. Wenn zig Anfragen pro Sekunden eingehen, kann das einen virtuellen Server schon aus der Fassung bringen.

Was war passiert. Spammer hatten auf gentleurl.net eine Menge Kurz-URLs generiert und dann über diverse Benutzerkonten auf Twitter gepostet. Jede auf Twitter gepostete URL wird sofort von einer zweistelligen Zahl Bots besucht. Dabei wird ein HEAD Request gemacht, um diverse Informationen zu erhalten. real-url.org ermittelt zum Beispiel die richtige URL, die sich hinter einer Kurz-URL versteckt. Weiß der Fuchs, was die anderen Dienste mit den Informationen anstellen.

Richtig unangenehm ist nur, dass die Bots alle nicht besonders nett sind. Denn statt sicher zu stellen, dass der Server nicht durch die Masse der eigenen Anfragen in die Knie gehen, hämmerten die Bots ohne Unterlass und Pause auf den Server ein. Bei mehreren Tausend URLs, die alle über einen sehr kurzen Zeitraum bei Twitter gepostet wurden, ist das dann nicht mehr lustig.

Abhilfe schaffte dann nur noch, diese Bots auszusperren, Firewall und .htaccess sei Dank.

Am Ende waren es dann rund 55.000 Hits in einem Zeitraum von fünf Stunden. Am "fleißigsten" war der UnwindFetchor mit 33,890 Hits, gefolgt von Twisted PageGetter und Voyager mit jeweils rund 8.000 Hits. Nachdem wir dann die diversen Bots gesperrt haben, kamen dann nochmals knapp 65.000 Zugriffe zusammen, die aber zum Glück ins Leere liefen und keinen Schaden mehr verursachten.

Das Wichtigste gleich vorweg. Strato erlaubt es nicht, Dateien mit der Endung .html als PHP-Dateien parsen zu lassen. Wer PHP-Code in seinen .html-Dateien ausführen möchte, muss die Dateien in .php-Dateien umbenennen.

Problematisch wird das beim Thema Suchmaschinenoptimierung. Einfach mal alle Dateinamen ändern kann sich nachteilig auf das Ranking auswirken.

Die Lösung ist mod_rewrite. Mit einer einfachen Anweisung in der .htaccess werden alle .html-Dateien im Hintergrund in .php-Dateien umgeschrieben:

RewriteEngine on
RewriteRule ^(.*).html$ $1.php

Damit können alle Links zu .html-Dateien gleich bleiben, obwohl alle Dateien in .php-Dateien umbenannt wurden.

Was für ein Mist. Heute fährt wieder jemand einen DOS gegen unseren Kurz-URL-Server. Die Angriffe werden jetzt erst einmal geblockt und der Server ist auch wieder gut erreichbar. Hoffen wir, dass es so bleibt.

Um nachhaltig Änderungen an den Konfigurationsdateien des Web-Servers unter Plesk vornehmen zu können, gibt es eine einfache Lösung, die auch in der Hilfedatenbank von Plesk erwähnt wird.

Individuelle Konfigurationen wie zum Beispiel die Änderung des open_basedir-Pfades oder das Einstellen einer Wildcard-Sub-Domain trägt man in eine vhosts.conf ein, die man im Verzeichnis /conf/ beim jeweiligen virtuellen Host erstellt.

<Directory HTTPD_VHOSTS_D/domain.com/httpsdocs>
    php_admin_value open_basedir /path/to/vhosts/domain.com/httpsdocs:/tmp
</Directory>

Für die Wildcard-Sub-Domain trägt man einfach ein Server-Alias ein:

ServerAlias *.domain.com

Nachdem die Datei vhosts.conf erstellt wurde, muss die Serverkonfiguration neu geschrieben werden. Das passiert mit folgendem Kommando:

~# /usr/local/psa/admin/sbin/websrvmng -a -v

Seit Plesk-Version 10.0:

~# /usr/local/psa/admin/sbin/httpdmng --reconfigure-all

Wir haben jetzt eine Möglichkeit gefunden, den Angreifer zu blocken. Ständiges Wechseln der Proxy-Server wird ihm jetzt nichts mehr nützen. Drücken wir die Daumen, dass die Lösung dauerhaft ist.

Mit der Weiterleitung haben wir den Angreifer nicht lange auf Distanz halten können. Jetzt versuchen wir mal einen neuen Trick. Bei den aktuell von dem Typen verwendeten IP-Adressen blenden wir jetzt folgende Nachricht ein:

Due to heavy load this server is down for the time being.

Mal sehen, ob er sich an der Nase herumführen lässt.

Jetzt haben wir den Angreifer, der in den letzten Tagen massive Zugriffe auf wegwerfemail.de verursacht, überlistet. Vorerst zumindest.

Nachdem wir eine IP-Adresse nach der anderen geblockt haben, fehlt uns langsam die Lust - und vor allem auch die Zeit - das Katz-und-Maus-Spiel weiter mitzumachen. Da der Typ zeitnah mit einer neuen IP-Adresse am Start war, nahmen wir an, dass der schon mal eine Liste an Proxies bereit hat und automatisch den nächsten nimmt, wenn der bisherige nicht mehr funktioniert. So würden wir das zumindest machen.

Die naheliegendste Gegenmaßnahme ist also nicht blocken sondern weiterleiten. Jetzt werden die Zugriffe alle zu example.com weitergeleitet. Die Lösung ist zwar nicht ganz so optimal, da der Web-Server die Zugriffe ja immer noch verarbeiten muss, aber wenigstens muss der Datenbank-Server nicht mehr ran. Und PHP-Dateien müssen auch nicht mehr ausgeführt werden.

Mals sehen, wie lange das etwas bringt.

In den Kommentaren zu DoS-Angriff schreibt jemand:

Klingt für mich eher nach einem Job für grep, sed, sort und uniq als für ein Office-Programm... ;)

Hat natürlich recht. Libre Office Calc ist nicht unbedingt die nächstliegendste Option, um nach IP-Adressen zu suchen, die auf den Server einhämmern. Folgende Anweisung tut es auch (und schneller).

 netstat -plant | grep 46.163.115.119:80 | awk '{print $5}' | sed -e 's/:.*//' | sort | uniq -c | sort 

Es zeigt sich, dass der Typ von gestern munter weitermacht. Blöd nur, dass er damit die Server-Performance in den Keller reißt. Derzeit kommen so um die 35 Anfragen pro Sekunde. Das resultiert in über 13.000 generierten Mail-Adressen auf wegwerfemail.de, die derzeit in der Datenbank zu finden sind. Aufgrund der relativ kurzen Halbwertzeit der Mail-Adressen von 60 Minuten sind normalerweise nur so um die 50 Adressen in der Datenbank.

Warum der Typ es nicht langsamer angehen lässt und - sozusagen - unter dem Radar fliegt, ist mir schleierhaft. Haben andere auch geschafft. Wäre ja nicht das erste Mal, dass jemand per Script die Website fernsteuert. Können sie ja machen, solange der Server erreichbar bleibt.

Da hat jemand seine Scripte nicht unter Kontrolle oder da will uns tatsächlich jemand schaden.

Am Montag hat jemand den Server in die Knie gezwungen, indem er massig Zugriffe auf gentleurl.net generiert hat. Das konnten wir dann mit unterbinden, indem wir die IP-Adresse per .htaccess geblockt haben.

Heute ging es weiter mit wegwerfemail.de mit mehreren IP-Adressen. Das hat dann ein bisschen mehr Arbeit gekostet, die beteiligten IP-Adressen aus den Server-Logs zu fischen. Dank der Filterfunktion von Libre Office Calc und der Sortierfunktion von Notepad++ ging es dann doch recht fix. Es waren dann am Ende 17 IP-Adressen. Seitdem läuft der Server wieder flüssig.

SSI ist ein Scriptprogramm. Das zumindest glaubt der Support von 1&1.

Ein Kunde von uns meldete Probleme mit seiner Website. Beim Aufruf der Seiten wird eine Datei zum Herunterladen angeboten, statt dass sie im Browser angezeigt wird. Ein kurzer Test zeigte, dass SSI (Server Side Includes) nicht mehr funktionierte.

SSI ist Bestandteil des Web-Servers, genau wie PHP oder Perl. Wenn das nicht funktioniert, kann man als Web-Hosting-Kunde nichts machen. Da muss der Web-Server-Betreiber selbst ran.

1&1 zeigt sich leider mal wieder völlig unfähig und antwortet auf die Support-Anfrage folgendermaßen:

Leider können wir ihnen in diesem Rahmen nicht helfen, da die SSI ein Scriptprogramm ist, welches Sie dirtekt in Ihrem WebspaceExplorer (erreichbar über Ihr Control-Center) verwalten und bearbeiten können. Dies ist eine inhaltliche Änderung, zu der 1&1 zur Sicherheit Ihrer Inhalte nicht berechtigt ist. Wir stellen Ihnen gern Programme und Dienstleistungen zur Verfügung. Deren Anwendung und Umsetzung obliegt jedoch allein ihrer Verantwortung.

Statt nach weiteren Informationen zu fragen oder selbst mal auf dem Server nachzusehen, wird die Anfrage gleich abgebügelt.

Nach einigen E-Mails hin und her und Erklärungen unsererseits kommt dann folgende Antwort:

Seit der Umstellung der Serverumgebung sollte die u.g. Direktive folgendermaßen lauten:
AddHandler server-parsed .html .htm .inc

Da stellt sich die Frage, warum über eine so wichtige Änderung auf dem Server nicht per E-Mail informiert wurde. Und wieso ist die Dokumentation bislang nicht angepasst worden? Dann hätten wir das Problem auch selbst lösen können, ohne uns mit dem miesem Support herumschlagen zu müssen?

Diese Angelegenheit ist typisch für 1&1. Es dauert Tage, um ein einfaches Problem zu lösen. Uns wird unterstellt, das Problem läge bei uns. Es ist deutlich, dass der Support von 1&1 unzureichend geschult ist. Wir melden ein Problem mit SSI und der Support antwortet mit "Leider können wir ihnen in diesem Rahmen nicht helfen, da die SSI ein Scriptprogramm ist. [...]". Was für ein Unfug.

Wir testen gerade ein bisschen mit PayPal herum. Nichts dramatisches. Trotzdem hat's PayPal entschärft. ;-)

Durch den Serverwechsel ändern wir gerade die Nameserver-Einstellungen mehrerer Domains. Um herauszufinden, ob die Änderungen auch vom eigenen Nameserver (wir nutzen die von Google) übernommen wurden, ist es nötig, den DNS-Cache auf dem eigenen Rechner zu löschen. Das geht ganz einfach mit folgendem Kommando in der Eingabeaufforderung:

C:\>ipconfig /flushdns

Wenn alles gut läuft, erhält man folgende Antwort:

Der DNS-Auflösungscache wurde geleert.

Es kann sein, dass die Eingabeaufforderung dazu im Administratormodus geöffnet sein muss.

Mit dem Serverwechsel sind wir durch. 25 Domains haben ein neues zu Hause gefunden. 17 Domains davon sind Kurz-URL-Dienste wie zum Beispiel melt.li. 7 Domains gehören zu Wegwerfe-E-Mail-Diensten wie wegwerfemail.de.

Einige Domains mussten allerdings auch gehen. Wir hatten mal vier Domains registriert, die zuvor von deren Besitzern aufgegeben wurden und thematisch in den Bereich PHP-Programmierung fielen. Wir hatten uns davon Traffic erhofft. Die Rechnung ist nicht so ganz aufgegangen, so dass die Domains jetzt gelöscht werden.

Übrig bleibt ein virtueller Server, der bald gelöscht wird. Ein Server, auf dem schon seit Jahren PHP 5.1.4 läuft, ohne dass wir die Möglichkeit hatten, eine aktuellere Version zu installieren. Ein Server, auf dem der Autor vor einigen Wochen aus Versehen einen gesamten virtuellen Host gezippt und auf diese Weise deaktiviert hat. Höchste Zeit also, die Kurve zu kratzen.

Bye, bye 87.230.79.81 :oops: