palita.net Blog

Es hat mich immer genervt, dass alle Emails, die von einem Server ausgehen (z.B. Fail2Ban, logwatch etc.) immer in meinem Postfach landen und als ungelesene Emails irgendwann mein Handy zum bimmeln Bringen, dem ich keine Regeln beibringen kann. Die Lösung ist denkbar einfach, wenn sie mir auch erst heute in den Sinn kam: einfach procmail die Arbeit machen lassen, anstelle meines Mailclients.

Procmail ist ein Mailprozessor, der zum serverseitigen Filtern von Emails eingesetzt wird. Um einen Procmail-Filter bei einer QMail-Umgebung (sowohl procmail als auch qmail sind bei Plesk standardmäßig integriert) aufzusetzen, bewegt man sich erst mal ins Verzeichnis des Mailnamen.

Für email@domain.com etwa
cd /var/qmail/mailnames/domain.com/email

In diesem Verzeichnis mit dem bevorzugten Editor (vi / nano / …) eine Datei .procmailrc erstellen, und folgenden Inhalt zur Filterung von Server-Mails erstellen:
# .procmailrc
MAILDIR=/var/qmail/mailnames/domain.com/email/Maildir
DEFAULT=${MAILDIR}

# Filter Servermails
:0:
* ^From.*@NERVIGERSERVER.COM
.VERZEICHNIS/new

Dabei NERVIGERSERVER.COM durch die Domain ersetzen, von dem der Server seine Mails sendet, und VERZEICHNIS durch das IMAP-Verzeichnis, in das die Nachricht verschoben werden soll. /new sollte dabei stehen bleiben.

Jetzt die Datei speichern, und die Datei .qmail im selben Verzeichnis editieren.

Die etwa so aussehende Datei

| true
| /usr/bin/deliverquota ./Maildir


wird jetzt so abgeändert, dass neue Emails nicht mehr an Deliverquota sondern an Procmail gesendet werden. Der Veränderte Inhalt der Datei dazu wäre etwa

| true
#| /usr/bin/deliverquota ./Maildir
| preline /usr/bin/procmail -m .procmailrc

Mehr muss nicht unternommen werden. Man sollte natürlich erst mal Testen ob es funktioniert, bevor man sich darauf verlässt, bevor keine Mails mehr ankommen, unter CentOS 5 und Plesk9 sollte es nach dieser Anleitung gar keine Probleme geben. Bei anderen Systemen sind die Pfade eventuell abweichend.

Procmail kann natürlich noch viel mehr, die manpage von procmailex(5) verrät eigentlich alles.

Manpage online: http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=procmailex

Einen Linux-Server aufsetzen ist nicht immer leicht. Schon alleine bei Samba gibt es immer wieder Schwierigkeiten, mal eben einen PrimaryDomainController aufsetzen und Benutzerrechte anpassen kann schon eine weile Dauern. Abhilfe schafft die auf CentOS basierende Distribution “Clark Connect“ “ClearOS“, die vom Antivirus bis zum Webserver alle gängigen Aufgaben verwalten kann.

Ein PDC ist schnell aufgesetzt und funktioniert problemlos, die Benutzer- und Gruppenverwaltung gestaltet sich sehr simpel.

Weitere Funktionen von ClarkConnect ClearOS:

• Firewall (2 Netzwerkkarten benötigt)
• DHCP-Server (2 Netzwerkkarten benötigt)
• VPN: OpenVPN, IPSec, PPTP
• Proxy, Content-Filter, ACL
• Mailserver mit Antispam & Antivirus
• Groupware
• Apache, PHP & MySQL
• Samba-Server
• FTP-Server
• Printserver
• uvm.

Unter Parallels Desktop und VMWare Server funktioniert bei mir alles einwandfrei, auf einem Test-PC gab es Schwierigkeiten mit dem DHCP-Client, was aber gut an einer defekten Netzwerkkarte gelegen haben kann.

Link: http://www.clarkconnect.com/ http://www.clearfoundation.com/

Viele mögen es kennen – nervige SSH-Loginversuche auf Servern, mehrere tausend am Tag. Aber scheinbar kennen manche kein Ausweg, dabei gibt es so viele Möglichkeiten!

fail2ban:

fail2ban ist ein in der Installation und Benutzung sehr einfaches Tool, geschrieben in Python, um nach fehlerhaften Loginversuchen eine Sperre in iptables einzutragen. Im Daemon-Mode überwacht er Logdateien und kann eine terminierte Sperre eintragen, sodass den Bruteforce-Attacken schonmal gut vorgebeugt ist. Unter Debian / Ubuntu einfach
sudo apt-get install fail2ban
Oder besser: Neueste .deb über die Webseite laden und mit
dpkg -i fail2ban*.deb
installieren.

Unter CentOS auch nicht schwerer: im epel-Repository ist fail2ban enthalten und kann mit
yum --enablerepo epel install fail2ban
installiert werden.

Nach der Installation ist standardmäßig eine Regel für SSH aktiv, einstellen kann man alles unter /etc/fail2ban/jail.conf .

Der Dienst muss noch mit
sudo /etc/init.d/fail2ban start
gestartet werden. Bei einer Sperre wird (sofern jail.conf angepasst wurde) per Email benachrichtigt, außerdem wird es unter /var/log/fail2ban.log geloggt.

/etc/ssh/sshd_config:

eine denkbar einfache, aber auch nicht sehr effektive Methode: SSH-Port ändern. Einfach in der Config “Port 22″ durch einen anderen Port ersetzen – kann aber natürlich durch jeden Portscanner wieder gefunden werden.

Worauf aber unbedingt geachtet werden sollte: Protokoll Version 1 deaktivieren! Version 2 ist wesentlich sicherer. In der Config sollte “Protocol 2,1″ auskommentiert und “Protocol 2″ aktiv sein.

Ebenfalls sehr effektiv: Passwort-Logins deaktivieren und mit Private- und Publickeyverfahren einloggen.

Weblinks:
Main Page – Fail2ban.

Gestern ist mir ein dummer Fehler passiert: auf einem CentOS-Server mit Plesk 9.2 und PHP 5.2.10 vom Remi-Repository habe ich, auch über das Remi-Repository, versehentlich ein PHP-Upgrade gemacht. Die dann vorhandene Version 5.3 ist aber leider total unkompatibel mit Plesk und so einigen Anwendungen. Sporadisch kam einfach mal bei jeden PHP-Skripts nur eine weiße Seite zurück, mit der Fehlermeldung von Apache:

PHP Warning: Unknown: open_basedir restriction in effect. File(/var/www/[...]/index.php) is not within the allowed path(s): (h\xc3\x15\x90+\xe4rr\n) in Unknown on line 0
PHP Fatal error: Unknown: Failed opening required '/var/www/[...]/index.php' (include_path='.:') in Unknown on line 0, referer: http://[...]

Damit konnte man erst mal nicht so viel anfangen, vor allem weil der Fehler nicht immer auftrat.

Die Lösung war einfach: PHP wieder auf PHP5.2.10 Downgraden. Aber ein Downgrade mit yum ist zunächst nicht vorgesehen. Auch das yum-Modul AllowDowngrade war dafür nicht geeignet. So weit auch noch kein Problem: PHP löschen, PHP installieren und 5.3 verbieten, zum Glück ist die 5.2 ja noch im Repository. Ging aber auch nicht: hätte ich PHP gelöscht, wären viele andere Pakete auch gelöscht worden und das alles korrekt und funktionierend wieder herzustellen wäre zu viel Arbeit + zu viel Ausfallzeit.

Also zur gefährlicheren Variante gegriffen: rpm –nodeps. Nicht wirklich zu empfehlen, aber hier ging es leider nicht anders.

Lösung:

-> Gegebenenfalls nachsehen, was von PHP alles in Version 5.3 installiert ist, z.B. mit
yum list installed php* | grep 5.3

PHP-Pakete mit RPM löschen:
rpm -e php-mbstring php-pdo php-cli php-common php-imap php-xml php-mysql php-gd --nodeps

und dann schnell hinterher mit yum nachinstallieren:
yum --enablerepo=remi --exclude=php*5.3* install php php-mbstring php-pdo php-cli php-common php-imap php-xml php-mysql php-gd
service httpd restart

Damit sollten wieder die 5.2er Versionen installiert sein (keine Garantie!!! Kann natürlich auch mächtig schiefgehen!)

Wer ebenfalls das Remi-Repo hat, und auch keine Lust hat auf PHP5.3, kann es in der /etc/yum.conf verbieten:

[main]
cachedir=/var/cache/yum
keepcache=0
[...]
exclude=php*5.3*
# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h
[...]

Viel Erfolg