Mailserver mit Postgrey gegen Spam schützen

Vor einiger Zeit beschrieb ich wie man einen Mailserver unter Ubuntu mittels Postfix und Dovecot aufsetzt. Der dort installierte Server ist, in der Lage Mails zu senden und zu empfangen. Allerdings enthält er keinerlei Maßnahmen zum Schutz vor unerwünschten Mails. An dieser Stelle setzt Postgrey, eine Greylisting Implementierung für Postfix, an. Beim Greylisting werden Mails von einem unbekannten Sender erst einmal mit einem temporären Fehler beantwortet. RFC konforme Mailserver senden die Mail nach einer Verzögerung nochmal. Beim Spamversendern ist dies meist nicht der Fall, womit der Spam nicht im System auftaucht. Die Installation ist dabei relativ einfach:

apt-get install postgrey

Nach der Installation muss die „/etc/postfix/main.cf“ Datei angepasst werden. Der Zeile „smtpd_recipient_restrictions“ wird dabei der Wert „check_policy_service inet:127.0.0.1:10023“ hinzugefügt. Nachdem der Service mittels:

service postfix restart

neugestartet wurde, ist das Greylisting aktiv. In der Logdatei „/var/log/mail.log“ findet man, sobald man eine Mail von einem unbekanntem Sender bekommt folgende Zeile:

Oct 10 10:32:39 service postfix/smtpd[22287]: NOQUEUE: reject: RCPT from mail.example.org[178.19.71.5]: 450 4.2.0 <>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html; from=<mail.example.org> to=<> proto=ESMTP helo=<mail.example.org>

Wenn die Mail erneut empfangen wird und die Greylistingzeit vorbei ist, wird Postgrey die Mail annehmen. Möchte man die Greylistingzeit ändern, so muss die Datei „/etc/default/postgrey“ bearbeitet werden. Für eine Verzögerung von 60 Sekunden könnte das ganze dann wie folgt aussehen:

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60"

Natürlich muss der Service für diese Änderung neugestartet werden.

„root“-Nutzer unter Ubuntu aktivieren

Unter Ubuntu gibt es in einer Stan­dard­in­stal­la­tion kei­nen akti­vier­ten „root“-Nutzer. Das bedeu­tet aller­dings nicht das der Nut­zer nicht vor­han­den ist. Statt­des­sen wird für den „root“-Nutzer ein­fach kein Pass­wort ver­ge­ben, was dazu führt das man ihn nicht nut­zen kann. Möchte man ihn doch nut­zen, so ver­gibt ein­fach ein Passwort:

sudo passwd root

Anschlie­ßend ver­fügt man über einen „root“-Nutzer und kann sich mit die­sem ein­log­gen. Möchte man das ganze wie­der rück­gän­gig machen, so muss die Datei „/etc/shadow“ bear­bei­tet wer­den. Dort wird der Hashwert des Nut­zers „root“ ein­fach durch ein Aus­ru­fe­zei­chen ersetzt. Danach ist der Nut­zer wie­der deak­ti­viert und kann nur mit­tels „sudo“ genutzt werden.

XMPP Server unter Ubuntu aufsetzen

Möchte man Instant Messaging mittels XMPP (früher unter dem Namen Jabber bekannt) nutzen, so kann man natürlich zu einem der vielen Dienste wie GMail, GMX und ähnliches gehen. Damit bekommt man dann neben den Vorteilen auch den Nachteil, das man sich nicht sicher sein kann was mit den eigenen Daten passiert. Eine andere Lösung ist es hier den XMPP Server selbst aufzusetzen. Dazu bietet sich „ejabberd“ an. Mittels:

sudo apt-get install ejabberd

wird das passende Paket installiert. Der Server „ejabberd“ unterstützt dabei die Verwaltung mehrerer Domains, so das eine Serverinstanz die Adressen und bereitstellen kann. Um dies umzusetzen, geht es im ersten Schritt an die Konfiguration. Dazu wird die Datei „/etc/ejabberd/ejabberd.cfg“ mittels „nano“ geöffnet:

nano /etc/ejabberd/ejabberd.cfg

Die Syntax der Datei ist dabei im Gegensatz zu anderen Konfigurationsdateien etwas gewöhnungsbedürftig, da sie auf der Programmiersprache Erlang basiert. Kommentare z.B. werden in dieser Datei mit einem Prozentzeichen eingeleitet. Im ersten Schritt werden die Domain respektive Hostnamen definiert, welche „ejabberd“ verwalten soll. Dazu wird der Punkt „hosts“ gesucht und mit den entsprechenden Domains gefüllt.

{hosts, ["xmpp.example.com", "xmpp.example.org"]}.

Die Serversprache kann man für einen deutschsprachigen Server geändert werden:

{language, "de"}.

Damit werden Nachrichten vom Server in Deutsch anstatt in Englisch ausgegeben. Standardmäßig ist der Server so eingestellt, das niemand außer dem Administrator Nutzer anlegen kann. Natürlich wäre es auch denkbar, einen Server zu betreiben, bei welchem sich jeder registrieren kann. Damit man Nutzer anlegen kann, muss ein Nutzer mit den entsprechenden Rechten definiert werden:

{acl, admin, {user, "seeseekey", "xmpp.example.com"}}.

Damit ist der Nutzer „“ ein Nutzer mit administrativen Rechten. Allerdings muss dieser Nutzer noch erstellt werden:

service ejabberd restart
ejabberdctl register seeseekey xmpp.example.com geheimespasswort

Weitere Nutzer können anschließend über die Weboberfläche angelegt werden. Zu erreichen ist diese dabei unter:

http://xmpp.example.com:5280/admin

Die Zugangsdaten entsprechen dabei denen des administrativen Nutzers.

Weitere Informationen gibt es unter:
https://wiki.archlinux.de/title/Ejabberd

Probleme mit dem SSH Zugang per Schlüssel

Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:

ssh-copy-id -i ~/.ssh/id_rsa.pub

Anschließend kann man sich mittels:

ssh

ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:

ssh -v

Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:

chmod 700 /home/seeseekey/.ssh/
chmod 600 /home/seeseekey/.ssh/authorized_keys

Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:

Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey

In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:

chmod 700 /home/seeseekey/

wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.