Server - 1

Wie im Blogartikel SSH Zugang limitieren mit GeoIP und hosts.deny aus 2017 bereits beschrieben, kann der Zugang zu Diensten mithilfe von /etc/hosts.deny eingeschränkt werden.

Das funktioniert für alle Services, die tcpwrap unterstützen.

Da inzwischen die GeoLite Legacy nicht mehr weiter gepflegt wird, sollte nur mehr die aktuelle GeoLite2 von MaxMind verwendet werden. Das erfordert ein angepasstes Skript.

UPDATE: cool, endlich bietet occ, das Kommandozeilen-Werkzeug von Nextcloud, einen Update-Check.

Das macht das Ganze natürlich viel einfacher. Wir brauchen nur einen Cronjob, der als Apache-User (z.B. www-data) ab und an occ ausführt.

Ipsets sind eine ausgesprochen praktische und performante Lösung, um umfangreiche Blacklist mit Iptables zu verwenden.
UFW ist ein Management-Werkzeug für Iptables mit sehr einfachem Kommandozeilen Interface.

An sich unterstützt UFW (Uncomplicated FireWall) keine Ipsets. Trotzdem ist es möglich, beides gemeinsam zu verwenden.
Zwei Bash-Skripte sind dazu nötig.

In diesem Beispiel verwenden wir die DROP von Spamhaus - eine Liste von IP-Ranges, mit denen man am besten keinerlei Kontakt hat.

Die Idee kam mir beim Schreiben des vorherigen Beitrages (dovecot, XBL, hosts.deny).

Da inzwischen auf dem Server auch SSH Passwörter/User im Stundentakt probiert werden, für dessen Distribution aber leider kein funktionierendes Paket für libpam_geoip existiert, möchte ich die Variante hosts.deny mit GeoIP anhand von SSH beschreiben. Die Verwendung für andere Dienste (pop, imap...) kann leicht abgeleitet werden. Verwendet wird die GeoLite Legacy Database.

Ein weiterer Weg, wie die langsamen password-guesser (nicht brute-force, was mit fail2ban besser abwehrbar wäre) bekämpft werden können: mit der XBL von Spamhaus.

Inspiriert wurde ich von diesem Beitrag auf dronebl.org

Ein paar Stichproben am betroffenen Server ergaben, dass die XBL wesentlich besser passt. Die XBL (Exploits Block List) ist eigentlich zur Spambekämpfung gedacht. Da sie allerdings "gecracktes Zeugs aller Art" enthält, sind durchaus auch die Botnetze der Passwort-Probierer mit dabei.

So bequem wie mit Postfix kann man dnsbl in Dovecot leider nicht verwenden. Der Aufwand ist aber immer noch vertretbar.

Lästig: am Server werden Passwörter der IMAP/POP Accounts ausprobiert. Es geht nicht um brute force Attacken, sondern ganz langsames Probieren.

Ein Test, dann eine Weile später ein Test von einer anderen IP, dann eine Weile später wieder von einer anderen IP,... usw.

Bei so was greifen Helferlein wie fail2ban einfach nicht. Andererseits sollte man sich auch nicht allein auf die Stärke der Passwörter verlassen. Zum Glück kann man auch gegen die langsamen password-guesser etwas tun.

Voraussetzung: dovecot verwendet pam als passdb.

Die folgende Beschreibung bezieht sich auf Debian, andere Distributionen haben sicher andere Paketnamen und Pfade.

Spamassassin hat die Blacklist von http://uribl.com/ automatisch aktiviert. Blöd nur, dass es ein Limit für Anfragen pro IP gibt. Manch einer mag sich gewundert haben, dass URIBL_BLOCKED (Anfrage wurde blockiert) immer zutrifft, obwohl der eigene Mailserver doch nur so wenig Traffic hat.
URIBL_BLOCKED ist nur eine Information für Admins, kein eigentliches Ergebnis:

ADMINISTRATOR NOTICE: The query to URIBL was blocked.  See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information.

Warum trifft das oft bzw. immer zu? Die Antwort ist ganz einfach: wenn dein Server bei einem ISP mit viel Traffic steht und du seine Nameserver verwendest, übersteigen deren Anfragen ständig das Limit. Es können ja hunderte, wenn nicht tausende Mailserver im gleichen Netz die selben Nameserver verwenden.

Was tun? Leider ist die entsprechende Dokumentation auf http://wiki.apache.org/spamassassin/CachingNameserver etwas dürftig und angestaubt.

Es gibt mehrere Lösungsansätze:

1. Dein Mailserver hat etwas mehr Traffic und es rentiert ein extra Dienst für Blacklists: rbldnsd (es gibt Debian Pakete aus den default Repos)
2. Dein Mailserver hat wirklich wenig Mailtraffic - dnsmasq (es gibt auch dafür Debian Pakete aus den default Repos)
3. UPDATE - das einfachste ist unbound als eigener Resolver (Debian: apt-get install unbound, resolv.conf anpassen, erledigt)

Ersteres macht für meinen Mailserver keinen Sinn.
Zweiteres ist für diesen Use-Case schlecht dokumentiert, aber bei Weitem die einfachste Lösung.

Und so gehts: