Mathias Bank

Seit ich auf die neue Debian-Version aktuallisiert hatte, gibt es aus mir nicht begreiflichen Gründen immer wieder php5-cgi-Prozesse, die zwar durch fastcgi gestartet wurden, sich jedoch darüber nicht mehr beenden lassen. Dadurch wurde der Speicher immer voller, was dazu führte, dass der Webserver irgendwann tot war.

Die vorläufige Lösung, bis ich mich an die Ursache des Problems machen kann (dazu muss ich mich noch tiefer in fastcgi einarbeiten) sieht so aus, dass ich nach allen php5-cgi-Prozessen suche, die nicht mehr unter fastcgi als Vaterprozess suche (also alle php5-cgi mit ppid=1) und diese kille. Dabei reicht ein einfaches kill nicht mehr, sondern man muss schon die harte Variante fahren (weshalb der Fehler wohl auch in php zu suchen ist). Hier also das shell-Script:


#!/bin/sh

for child in $(ps -o pid,ppid,command -ax | grep php5-cgi | \
awk "{ if (\$2==1) {print \$1}}")
do
echo "Killing child process $child because ppid=1"
kill -s 9 $child
done


Das jetzt stündlich ausführen und der Speicher ist zumindest derzeit kein Problem. Trotzdem natürlich keine schöne Lösung, nur ein vorläufiger Workaround.

Ich weiß nicht, was in letzter Zeit los ist, aber meine Server sind derzeit total überfordert. So sind mir heute zwei Server durch zu viele Anfragen in die Knie gegangen. Diese Speicherproblematik hab ich erst, seitdem ich IspCP einsetze. Der Grund ist banal: PHP wird nun als fastCGI ausgeführt und nicht mehr als Modul. Ist zwar sicherer, braucht aber mehr Ressourcen.

Hab mir jetzt nen neuen Server mit deutlich mehr Prozessorleistung und deutlich mehr Kernspeicher bestellt. Ich hoffe, dass der bald da ist und dass die Einrichtung möglichst schnell funktioniert. Da ich auf jeden Fall virtualisieren werde, kann ich die Einrichtung ja schon mal vorbereiten und das Image nachher einfach drauf spielen.

[Update]
Inzwischen konnte ich das Problem teilweise eingrenzen. Der Apache hatte durch ein Debian-Update die falsche User-Kennung, wodurch er offensichtlich die Anzahl der php5-cgi-Prozesse nicht mehr kontrollieren konnte. Nach dem Korrigieren funktioniert das jetzt zwar, aber ein Benutzer (der von diesem Blog) macht noch Ärger und die php5-cgi-Prozesse sprießen geradezu aus dem Boden. Ich hab keine Ahnung, wie ich das begrenzen kann. Eigentlich sollte laut Config der Apache das tun. Ich weiß aber nicht, warum es hier nicht geht. Für Anregungen wäre ich sehr dankbar.

Nach einem äußerst langen Wochenende läuft inzwischen nahezu alles wieder. Die neue Verwaltungssoftware IspCP Omega kommt bei fast allen Kunden gut an. Bis auf ein paar Hilfestellungen gab es auch keinerlei Probleme und die Kunden haben den Ausfall ausgesprochen gut verkraftet. Die automatische Sicherung aller relevanten Daten hat sich doch ausgezahlt.

Der Serverprovider schaut sich die Hardware nun genauer an, um sicherzugehen, dass es sich nicht um ein Hardware-Problem handelt. Trotzdem schau ich mich jetzt nach einem neuen Server um, diesmal gleich mit mehreren Platten zum Spiegeln. Spätestens in einem Monat will ich den aktuellen Server langsam aber sicher abschalten können. Er war nun lang genug am Netz.

[lang_en]sorry, no english entry[/lang_en]

Das hätte so ein schönes Osterfest werden können, aber ausgerechnet gestern hat es die Festplatte von meinem Server zerhauen. Irgendwie erwischt es mich auch immer an Feiertagen, an denen der Support sehr gut erreichbar ist. Ich hab mir meine Zeit seit gestern um 7 also damit verbracht, den Server neu zu installieren. Dabei kam natürlich die neuste Software drauf. Glücklicherweise haben alle Backups funktioniert (bis auf .htaccess-Dateien war alles da – warum das mit tar nicht automatisch immer dabei ist, ist mir ein Rätsel).

Nach gut 15 Stunden (hab heut vor 6 Uhr angefangen, nachdem ich gestern noch bis 1 am Server gebastelt hab) läuft fast alles wieder. Es gibt ein paar Domains, die noch Fehler haben, aber darum kümmer ich mich erst morgen. Da es sich vorwiegend um eigene Domains handelt, ist das nicht tragisch.

Für den Notizzettel: von allen Kunden eine alternative eMail-Adresse organisieren. Es sind leider nicht alle erreichbar gewesen.

So, für heut hab ich keine Lust mehr!

[lang_de]Bisher hatte ich auf meinem Server den SSH-Port auf dem Standard-Port laufen lassen. In der Vergangenheit haben aber leider die Versuche, per SSH auf den Server zu kommen, extrem zugenommen. Und zwar so stark, dass der Server mittels DoS-Attacke lahmgelegt wurde. Nachdem das jetzt gestern bereits das zweite mal passiert ist, musste ich mir überlegen, wie ich dagegen vorgehen kann. Da die Angreifer immer im Ausland sitzen (bzw. die gehackten Server) kann ich auf juristischem Wege rein gar nichts machen. Also was tue ich:

1. Als erstes hab ich den Port gewechselt. Das war für den Server schonmal eine große Erleichterung, er läuft heute viel flüssiger. Kann ich also für jeden empfehlen!

   Um den Port zu ändern, ist unter Suse in der Datei “/etc/sysconfig/ssh”, unter Debian in der Datei “/etc/default/ssh” folgender Wert für Port 12345 einzutragen:

   SSHD_OPTS="-p 12345"

   Anschließend mittels “rcsshd restart” (Suse) bzw. “/etc/init.d/ssh restart” (Debian) den SSH-Dienst neu starten und fertig. Sicherheitshalber sollte man die aktuelle SSH-Verbindung offen lassen und mittels zweiter Verbindung testen, ob der neue Port funktioniert. Auf keinen Fall die Firewall-Einstellungen vergessen.

2. Als nächstes empfiehlt es sich, auffallende IPs zu sperren. Hierzu gibt es zwei interessante Projekte: Fail2Ban und DenyHosts.
3. Wer jetzt noch lustig ist, kann auf dem Standard-SSH-Port einen Honeypot installieren, um Angreifer zum einen besser verfolgen zu können und zum anderen, um die geplanten Machenschaften zu ermitteln. Hier empfiehlt sich unter anderem Kojoney.

Jetzt bin ich mal gespannt, wie lange diese Änderungen helfen.
[/lang_de]
[lang_en]Until now, I have used SSH with its standard port 22. Of course, I didn’t wait a long time until I’ve received the first hacking attempts. These became more and more and the server was paralyzed yesterday via DoS. That was the second time now. There has to be a reaction. But what can I do:

1. At first, I have changed to port. This was very easy and the server runs really faster today. This is what I have done to use port 12345:

   Edit “/etc/sysconfig/ssh” (Suse) or “/etc/default/ssh” (Debian) and change the entry like this:

   SSHD_OPTS="-p 12345"

   Restart your ssh server with “rcsshd restart” (Suse) or “/etc/init.d/ssh restart” (Debian).

   Don’t forget to make sure, that your new configuration works! Before closing your current ssh client, start a new client and try to connect. You also should remember to edit your firewall configuration.

2. Of course, it is no bad idea to block flashy ip addresses. There are to very interesting projects: Fail2Ban and DenyHosts.
3. If you have fun, you can install a honey pot at your port 22 to see, who is trying to connect and to see, what the hacker wants to do. An interesting project for this is Kojoney.

Let’s see, how long this configuration works.
[/lang_en]