Ich könnte mir ja soetwas von in den Hintern beissen, wenn ich nur könnte.

Gestern wurde massig Spam-eMails über meinen Server verschickt. Mehrere Hundert. Und ich konnte das Einfallstor nicht ausfindig machen. Ich bin die Logfiles des Mail-Daemons durchgegangen und für mich sah es so aus, dass die eMails auf dem lokalen Netwerk-Interface, also localhost, eingereicht werden. Ich ging also davon aus, dass entweder ein lokaler Dienst eine Sicherheitslücke hat oder aber ein Skript von einem Freund, was auf dem Server läuft. Letzteres konnte ich aber in den eMail-Headern nicht entdecken, denn normalweise steht dort drin, über was für ein Skript die Dinger versandt werden. War aber nicht so.

Also deaktivierte ich alle nicht benötigten Programme auf dem Server und löschte die verbleibenden eMails auf dem eMail-Queue. Heute Morgen waren aber wieder alle eMails da. Nur in den Logfiles konnte ich nichts entdecken, woher diese kamen. Bis ich dann endlich mal den Anfang im Log gefunden habe, wo es Anfing, dass die eMails eingekippt wurden. Da konnte ich mich dann auch wieder an etwas erinnern, was ich auch wieder löschen wollte.

Ich habe einen eMail-User mit dem Namen ‚test‘ angelegt. Passwort war natürlich auch ‚test‘.

Ganz dummer Fehler! Wirklich, ganz dumm!

In den heutigen Tagen muss man zurück zu den Wurzeln. Der ganze neumodische Schnickschnack ist überflüssig und kostet unnötige Resourcen. Darum habe ich auch auf meinem Server OpenSSH deinstalliert und nutze ab jetzt wieder telnet. Wer braucht schon verschlüsselte Datenübertragung?

Seit 2003 habe ich meinen eigenen Server. Dazu kam noch der Webserver meines Cousins auf dem sein Motorrad-Zubehör-Shop läuft, sowie ein kleiner VServer. Und eines vernachlässige ich seit 2003 vehement — die tägliche Logfile-Auswertung.

Wenn Fehler auftreten schaue ich schon mal rein um den Fehler zu finden, aber die tägliche Auswertung fand ich bisher ziemlich nervig. Überflüssig sicherlich nicht, aber wenn man jeden Tag immer die gleichen Meldungen sieht, die mir mitteilen, dass ein Programm korrekt lief, dann hat man nach zwei Tagen die Lust verloren. So ist mir über die Jahre sicherlich einiges durchgerutscht oder erst sehr viel später aufgefallen, was ich viel früher hätte stoppen können.

Damit ist nun Schluss, den ich habe Logwatch entdeckt. Logwatch ist ein Perl-Skript, dass die Logfiles automatisch auswertet und dem Admin eine Zusammenfassung der wichtigsten Ereignisse des Servers einmal täglich per eMail zuschickt. Und wenn bestimmte Programme nicht von Haus aus unterstützt werden, kann man Logwatch einfach erweitern. Die Programmiersprache hierfür ist egal.

Ich habe ja einen eigenen Server, der den ganzen Schnickschnack drauf hat, um eben diese (und ein paar Seiten von Freunde) zu generieren. Damit die Konfiguration für meine Freunde und mich etwas einfacher ist, nutze ich Confixx von SWSoft. Bei Confixx kann man über eine Weboberfläche Domainen anlegen, diesen Verzeichnisse zuordnen, etc. pp.. Dieses Confixx erstellt dann — nachdem man alle Eintragungen in der Weboberfläche gemacht hat — alle Konfigurationsdateien für den Webserver usw.

Confixx benötigt auch dringend PHP. Diese Skriptsprache, auf der auch diese Seite beruht. PHP kommt in verschiedenen Ausführungen daher. Einmal als Apache-Modul. Dieses hat den Vorteil, daß es sehr schnell ist, aber den Nachteil, daß jeder Benutzer auf dem Webserver jedem anderen in die Verzeichnisse schauen kann, weil alle PHP-Skripte unter einem einzigen Systemuser (dem des Webservers) ausgeführt werden.

Seit einiger Zeit kann Confixx auch mit suPHP umgehen. Hier ist der Vorteil, daß alle PHP-Skripte unter einem seperaten Systemuser ausgeführt werden, d. h. keiner kann dem anderen in die Karten schauen. Nachteil ist, daß jedesmal wenn eine Seite aufgerufen wird, ein grosser Overhead erzeugt wird, der in der Regel grösser ist, als das Ausführen des PHP-Skripts selbst, d. h. die Seiten werden sehr langsam und der Server ist immer sehr stark ausgelastet.

Der Kompromiss zwischen den beiden o. g. Möglichkeiten stellt fcgid dar (der Nachfolger von fastcgi). Es ist schnell, hat wenig Overhead und alle Skripte werden unter einem seperaten User ausgeführt. Der Nachteil ist, daß Confixx dies von Haus aus nicht unterstützt.

Ich habe mich zumindest daran gesetzt und ein kleines Skript erstellt, welches vor dem confixx_counter-Skript ausgeführt werden muß. Dieses erstellt für alle User die entsprechenden fcgid-Wrapper-Skripte, mit denen die PHP-Skripte ansich dann aufgerufen werden.

Zusätzlich wird eine weitere Apache-Konfigurations-Datei (confixx_special_vhost.php) erstellt, welche am Ende der httpd.conf eingefügt werden muss.

Wenn man soweit ist, trägt man in Confixx unter http-Special noch dies ein

# FCGI
AddHandler fcgid-script .php
AddHandler fcgid-script .php4
AddHandler fcgid-script .php5
AddHandler fcgid-script .phtml
#/suPHP_ConfigPath .*/
# FCGI

und die Sache sollte laufen.

Ich setzte dies nun seit ca. einer Woche ein, und der Server wurde merklich entlastet und die Seiten rauschen sehr viel schneller an.

Das Skript downloaden und auf dem Server ausführen. Wenn Fragen sind, diese in den Kommentaren stellen und ich werde ggfs. diese Ausführung erweitern.

Ich bin nun seit Mittwoch krank und habe nichts besseres zu tun, als Heissgetränke zu mir zu nehmen und an meinem Server zu schrauben.

Spamassassin machte mir schon seit einige Zeit Probleme, doch hatte ich bisher nicht die Lust, der Sache auf den Grund zu gehen. In den Log-Dateien kam immer der Fehler

spamd[13416]: dns: sendto() failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm line 340

und Spamassassin benötigte ewig bis die eMail gescannt war. Ich tippte zu erst darauf, daß die DNS-Auflösung nicht mehr funktionierte, doch das konnte ich definitv ausschliessen.

Das Problem liegt an Spamassassin, bzw. der Perl-Klasse selbst. Es nimmt aus der resolv.conf nur den ersten, eingetragenen DNS-Server und versucht zu diesem eine Verbindung herzustellen. Schlägt dies fehl oder dauert dies zu lange, kommt der o. g. Fehler.

Ich habe nun den ersten DNS-Server Eintrag geändert und nun läuft wieder alles einwandfrei.

Dienstag ist ja mein Zweitserver ausgefallen und kam nach dem Reboot nicht mehr in einen definierten Zustand. Ich habe jetzt ein gcc-Update durchgeführt und mußte deswegen auch alle Pakete auf dem System neu kompilieren. Dies wird bei der Linux-Distribution Gentoo mit einem kleinen Befehl erledigt. Problem war, daß 240 Pakete neu gebaut werden mußten und wenn das Kompilieren bei Paket 229 abbricht, mußte ich den Fehler beheben und das System fing wieder von vorn an, die 240 Pakete zu kompilieren. Darum hat es bis gerade gedauert, daß alle Pakete neu erstellt waren.

Im Moment rennt der Server mit Mühe und Not, der Apache rennt und eMail werden empfangen und versandt. Ich werde nächste Woche den Kernel neu erstellen müssen und hoffen, daß dann der Server nach dem booten wieder hochfährt.

Wenn das durch ist, pack ich die Kiste wieder ein Jahr nicht an …