fail2ban macht den Server sicherer – speziell ssh und auch dovecot auf DEBIAN STRETCH

Fail2ban dient dazu, ständige Einlogversuche von fremden Rechnern auf den ssh-port zu unterbinden. Auch andere Ports können damit überwacht werden.

Nachdem sogar Fremdlogins auf den imap-port für existierende User auftauchten, stieg die empfundene Handlungsnotwendigkeit.

Beispiel: (Auszug aus /var/log/auth.log)

1
2
3
4
5
6
7
8
9
10
Dec 8 07:31:25 myserver sshd[9656]: Invalid user si from 113.120.16.165 port 51268
Dec 8 07:31:25 myserver sshd[9654]: Invalid user si from 113.120.16.165 port 51264
Dec 8 07:31:25 myserver sshd[9656]: input_userauth_request: invalid user si [preauth]
Dec 8 07:31:25 myserver sshd[9654]: input_userauth_request: invalid user si [preauth]
Dec 8 07:31:26 myserver sshd[9656]: pam_unix(sshd:auth): check pass; user unknown
Dec 8 07:31:26 myserver sshd[9656]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=113.120.16.165
Dec 8 07:31:26 myserver sshd[9654]: pam_unix(sshd:auth): check pass; user unknown
Dec 8 07:31:26 myserver sshd[9654]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=113.120.16.165
Dec 8 07:31:28 myserver sshd[9656]: Failed password for invalid user si from 113.120.16.165 port 51268 ssh2
Dec 8 07:31:28 myserver sshd[9654]: Failed password for invalid user si from 113.120.16.165 port 51264 ssh2

IP 113.120.16.165 startet einen Angriff und versucht sich über ssh einzuloggen.
Das bewirkt folgendes:

fail2ban log:

1
2
3
4
5
2017-12-08 07:31:25,911 fail2ban.filter [14863]: INFO [sshd] Found 113.120.16.165
2017-12-08 07:31:25,912 fail2ban.filter [14863]: INFO [sshd] Found 113.120.16.165
2017-12-08 07:31:26,285 fail2ban.filter [14863]: INFO [sshd] Found 113.120.16.165
2017-12-08 07:31:26,288 fail2ban.filter [14863]: INFO [sshd] Found 113.120.16.165
2017-12-08 07:31:26,828 fail2ban.actions [14863]: NOTICE [sshd] Ban 113.120.16.165

Die IP wird in der Firewall eingetragen und gebannt. Man kontrolliert das etwa mit:

tail -40 /var/log/fail2ban.log

 

Weiter kann man es in der Firewall kontrollieren: Ein „iptables-save“ liefert unter anderem:

-A f2b-sshd -s 113.120.16.165/32 -j REJECT –reject-with icmp-port-unreachable

 

Zu konfigurieren ist unter anderem in der jail.conf

  • findtime = 600 (Zeitfenster für den Zähler Fehlversuche pro IP)
  • maxRetry = 3 (Der Ban erfolgt nach 3 Fehlversuchen)
  • banTime = 3600 (Die IP ist für eine Stunde gebannt)

Der Teil für den sshd war trivial. Problematischer war der Part für den dovecot.

Es fiel auf, dass auf Versuche fremder IPs sich als Mailuser einzuloggen, nichts bewirkten.
Kurzer Check der Sachlage ergab, DEBIAN 9 trägt die Loginversuche aus IMAP (dovecot) in der auth.log ein:

Dec 8 07:07:31 myserver:auth: pam_unix(dovecot:auth): check pass; user unknown
Dec 8 07:07:31 myserver auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=sfsb rhost=130.204.239.232

fail2ban ist aber auf die mail.warn konfiguriert.

Am schnellsten korrigiert man das durch Überschreiben der entsprechenden Konfiguration in der Konfig (jail.local)

# dovecot defaults to logging to the mail syslog facility
# but can be set by syslog_facility in the dovecot configuration.
[dovecot]
# enabled = true
port = pop3,pop3s,imap,imaps,submission,465,993,sieve
#logpath = %(dovecot_log)s
logpath = /var/log/auth.log
backend = %(dovecot_backend)s

Mit dem harten Überschreiben des logpath in der Section für dovecot ist das Problem gelöst:

2017-12-08 10:34:08,015 fail2ban.filter [28202]: INFO [dovecot] Found 218.23.49.154

 


Etwas allgemeiner Ansatz wäre, in der paths-common.conf (in /etc/fail2ban/) folgendes zu überschreiben.

dovecot_log = %(syslog_mail_warn)s

Seiteneffekte sind jedoch unklar, man findet da folgendes vor:

# There is no sensible generic defaults for syslog log targets, thus
# leaving them empty here so that no errors while parsing/interpolating configs
syslog_mail_warn =
syslog_daemon =
syslog_ftp =
syslog_local0 =

Damit würde wohl:
dovecot_log = /var/log/auth.log
auch das Problem lösen.

Weitere Informationen über die Konfigurationsmöglichkeiten von fail2ban-server erhält man mit „man fail2ban-client“.

Googlemail – rejected (Mailserver kann nichts an Google Adressen schicken)

Problem: Google lehnt Mail von neuem DEBIAN Server ab (sendmail)

Nachdem der neue Mailserver mit sendmail auf debian 9 Stretch abgesetzt war, kam diese seltsame Fehlermeldung zurück, wenn man eine Mail an eine google Adresse geschickt hatte:

Return-Path: <MAILER-DAEMON@mail.mydomain.com>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
mail.mydomain.com
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=4.5 tests=BAYES_00,NO_RELAYS,
T_TVD_MIME_NO_HEADERS,URIBL_BLOCKED autolearn=ham autolearn_force=no
version=3.4.1
Received: from localhost (localhost)
by mail.mydomain.com (8.15.2/8.15.2/Debian-8) id v9N9l9ff017607;
Mon, 23 Oct 2017 11:47:09 +0200
Date: Mon, 23 Oct 2017 11:47:09 +0200
From: Mail Delivery Subsystem <MAILER-DAEMON@mail.mydomain.com>
Message-Id: <201710230947.v9N9l9ff017607@mail.mydomain.com>
To: <sender@mymail.de>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=“v9N9l9ff017607.1508752029/mail.mydomain.com“
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

–v9N9l9ff017607.1508752029/mail.mydomain.com

The original message was received at Mon, 23 Oct 2017 11:47:09 +0200
from ip-xx-xxx-xx-xxx.hsi16.unitymediagroup.de [95.223.21.104]

—– The following addresses had permanent fatal errors —–
<testuser@googlemail.com>
(reason: 550-5.7.1 [2a01:4f8:a0:6386::2] Our system has detected that this message does)

—– Transcript of session follows —–
… while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.1 [2a01:4f8:a0:6386::2] Our system has detected that this message does
<<< 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
<<< 550-5.7.1 authentication. Please review
<<< 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information
<<< 550 5.7.1 . z202si3574495wmd.61 – gsmtp
554 5.0.0 Service unavailable

Einen hilfreichen Hinweis finden wir im Text zum Link am Ende der obigen Meldung  hinter der URL (Originaltext siehe weiter unten).

Der Text ist recht allgemein und tangiert mehrere Bereiche. Obwohl man zunächst den Eindruck gewinnen könnte,  liegt es jedoch definitiv nicht am SPF-Datensatz oder der DMARK-Richtlinie, der alte Server hatte das auch nicht.
Jedoch hat der neue Server auch eine aktive  IPv6 Adresse. Und diese soll laut Text (s.u) im Reverse-Lookup konfiguriert sein. Nun, der Reverselookup der IP ist auf die IPv4 Adresse vorkonfiguriert.
Im Sendmail M4 File kann man versuchen, das Versenden über IPv6 zu disablen:

DAEMON_OPTIONS(`Name=IPv4, Family=inet, Port=smtp‘)dnl
dnl  DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Port=smtp‘)dnl

DAEMON_OPTIONS(`Name=IPv4, Family=inet, Addr=192.168.0.2′)
dnl DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Addr=<…your IPv6 IP...>‘)

Das hilt jedoch nicht.

Lösung war eine zusätzliche Konfigurationszeile im M4:

Wenn die IPv4 Adresse W.X.Y.Z lautet, füge diese Zeile hinzu:

CLIENT_OPTIONS(`Family=inet6,Addr=:::ffff:W.X.Y.Z‘)dnl

Danach wie immer aus dem M4 File (/etc/mail/sendmail.mc) das cf File erzeugen (sendmail.cf), sendmail neu starten ->

Danach akzeptierte auch Google die Mails!


Anhang: Google-link in der Fehlermeldung mit Text

https://support.google.com/mail/?p=IPv6AuthError

Authentifizierung und Identifikation

Warum ist es wichtig, Nachrichten zu authentifizieren?

Die Authentifizierung stellt sicher, dass Ihre Nachrichten richtig klassifiziert werden. E-Mails ohne Authentifizierung werden meist abgelehnt oder im Spamordner abgelegt, da es sich dabei mit hoher Wahrscheinlichkeit um gefälschte Phishing-Nachrichten handelt.

Nicht authentifizierte E-Mails mit Anhang werden aus Sicherheitsgründen in der Regel sofort abgelehnt.

Um zu gewährleisten, dass Gmail Sie identifizieren kann, sollten Sie Folgendes beachten:

  • Verwenden Sie zum Senden von Massen-E-Mails eine gleichbleibende IP-Adresse.
  • Speichern Sie gültige Reverse-DNS-Daten für die IP-Adressen, von denen Sie E-Mails senden und die auf Ihre Domain verweisen.
  • Verwenden Sie in jeder gesendeten Massen-E-Mail dieselbe „Von:“-Adresse in der Kopfzeile.

Außerdem empfehlen wir Ihnen Folgendes:

  • Verschlüsseln Sie Nachrichten mit einer DKIM-Signatur. Wir authentifizieren nur Signaturen, die mit mindestens 1.024 Bit verschlüsselt wurden.
  • Veröffentlichen Sie einen SPF-Datensatz.
  • Veröffentlichen Sie eine DMARC-Richtlinie.

Weitere Informationen über die Authentifizierung von E-Mails

Zusätzliche Richtlinien für IPv6

  • Die sendende IP-Adresse muss einen PTR-Eintrag aufweisen, d. h. eine Reverse-DNS der sendenden IP, der mit der IP-Adresse übereinstimmen sollte, die über die Forward-DNS-Abfrage des im PTR-Eintrag genannten Hostnamens ermittelt wird. Andernfalls werden die E-Mails als Spam eingestuft oder möglicherweise sogar zurückgewiesen.
  • Die Domain des Absenders sollte den Anforderungen einer SPF- oder DKIM-Prüfung genügen. Ansonsten kann es vorkommen, dass E-Mails als Spam eingestuft werden.

 

 

Fehlermeldung: sendmail unknown configuration line in sendmail.cf

Nach einer Konfigurationsänderung für sendmail  ( Datei sendmail.mc ) startete der Sendmail nicht mehr an.

Die Meldung lautete:

sendmail[30029]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 97: unknown configuration line „\n“

Die sendmail.cf sah eigentlich harmlos aus:

sendmail.cf - Fehlerhafte Zeile
sendmail.cf – Fehlerhafte Zeile

Wenn man jedoch den Cursor positionierte, fand man das Problem:

Es hatte sich ein Leerzeichen eingeschlichen.
Woher kommt das?

Ein Blick in die m4-Datei zeigte:

Dieses Blank wäre nie aufgefallen, hätte ich nicht auf der Fehlersuche etwas Ordnung reingebracht, die teilweise optionalen DNL  (define newline) Commands  noch nachgetragen.
Erst dann visualisiert sich das Problem:

Ein böser Effekt. Man sieht halt keine Leerzeichen am Zeilenende.
Und ich dachte, moderne  Software stolpert nicht mehr über so etwas.