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!

Danke für das Abonnieren meines Feed!

Related Posts

1. Reboot tut nicht immer gut
2. Langsam arbeitet er wieder
3. Logwatch, die automatische Logauswertung

Danke für das Abonnieren meines Feed!

Related Posts

1. Langsam arbeitet er wieder

Danke für das Abonnieren meines Feed!

Related Posts

1. Reboot tut nicht immer gut
2. Langsam arbeitet er wieder
3. Camino 1.5

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.

Danke für das Abonnieren meines Feed!

Related Posts

1. Spamassassin DNS Probleme

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.

Danke für das Abonnieren meines Feed!

Related Posts

1. VServer bei netFabrik
2. Langsam arbeitet er wieder

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.

Danke für das Abonnieren meines Feed!

Related Posts

1. Langsam arbeitet er wieder
2. Reboot tut nicht immer gut
3. Logwatch, die automatische Logauswertung

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 …

Danke für das Abonnieren meines Feed!

Related Posts

1. Reboot tut nicht immer gut
2. Stirb Langsam 4.0
3. Alles wieder im Lack

Beim letzen Sicherheitsupdate schmiss der Compiler schon bei einigen Paketen Fehler, so daß ich Angst hatte, den Server danach zu rebooten und wollte mich irgendwann — wenn man mal Zeit hat — dem Komplettupdate hingeben.

Hätte ich dies mal früher getan! Gestern konnten keine eMails mehr versandt werden, weil der Mailfilter immer wieder mit nicht nachvollziehbaren Fehlermeldungen ausstieg und ich Dussel ließ mich zu einem Reboot hinreissen. Tja, der Server fuhr zwar hoch, startete aber seine Netzwerkdienste nicht mehr und jetzt bin ich seit gestern Abend dabei, alles neu zu machen und so wie es aussieht, wird das noch einige Tage in Anspruch nehmen — und das, wo ich immer noch nicht wirklich Zeit dafür übrig habe

Danke für das Abonnieren meines Feed!

Related Posts

1. Backup: Nicht immer sicher
2. MySQL 5 möchte nicht mit dem Leopard
3. Spamassassin DNS Probleme

iptables –I INPUT –s zu_sperrende_ip –j DROP

Danke für das Abonnieren meines Feed!

Related Posts

No related posts.

Bisher kann ich mich nicht beklagen!
Pro

• Die Weboberfläche zur Administration ist übersichtlich
• Reverse-DNS Einträge können geädnert werden
• Hostname kann geändert werden
• Confixx-Oberfläche inklusive
• sehr schnell eingerichtet

Contra

• Support ist nur über teure 0900-Nummer erreichbar
• Die bestellte Domain wurde immer noch nicht regestriert

Alles im allem bin ich damit aber zufrieden, da er nämlich das tut, was er soll. Denn auf dem VServer läuft nur mein dritter Nameserver, sowie ein Monitoring mit Nagios für meine beiden (vollwertigen) Server.

Ich hoffe, daß ich auch weiterhin weniger Probleme haben werde!

Danke für das Abonnieren meines Feed!

Related Posts

1. Reboot tut nicht immer gut
2. Logwatch, die automatische Logauswertung
3. Nur ein Test-User