Spam Angriff auf Mailserver

[alpha9191]

Hallo zusammen,

Ich betreibe seit einigen Jahren einen Mailserver mit Cyrus und Postfix. Die Authentifizierung erfolgt mittels saslauth. E-Mails abrufen über Port 143 (IMAP) und versenden über Port 25 (SMTP) beides mit STARTTLS.
Installiert ist ein Debian Squeeze, folgende Paketversionen sind installiert:

Code: Alles auswählen

root@debian:/etc/shorewall# dpkg -l | egrep 'postfix|sasl|cyrus'
ii  cyrus-admin-2.2                     2.2.13-19+squeeze3           Cyrus mail system - administration tools
ii  cyrus-common-2.2                    2.2.13-19+squeeze3           Cyrus mail system - common files
ii  cyrus-imapd-2.2                     2.2.13-19+squeeze3           Cyrus mail system - IMAP support
ii  libcyrus-imap-perl22                2.2.13-19+squeeze3           Interface to Cyrus imap client imclient library
ii  libsasl2-2                          2.1.23.dfsg1-7               Cyrus SASL - authentication abstraction library
ii  libsasl2-modules                    2.1.23.dfsg1-7               Cyrus SASL - pluggable authentication modules
ii  php-auth-sasl                       1.0.4-1                      Abstraction of various SASL mechanism responses
ii  postfix                             2.9.3-2.1~bpo60+1            High-performance mail transport agent
ii  sasl2-bin                           2.1.23.dfsg1-7               Cyrus SASL - administration programs for SASL users database

Der Server ist nur über Port 143 und 25 von allen IP-Adressen erreichbar, per ssh nur auf meine öffentliche IP beschränkt. Als Firewall setze ich iptables ein.

Folgendes Problem:

Ein Angreifer konnte sich erfolgreich als User "newsletter" auf anmelden:

Code: Alles auswählen

Dec  3 13:54:41 debian postfix/smtpd[20966]: C8CAA3BC009: client=unknown[180.87.196.214], sasl_method=LOGIN, sasl_username=newsletter@

Was mich wunderte, war der direkte Login ohne vorherigen Fehlversuch...
Ok, Passwort geändert, danach kamen einige fehlgeschlagenen Anmeldeversuche, nach einer halben Stunde ca. jedoch wieder ein Login.
Hm... ich dachte mir, dass eventuell irgendwo noch Cache Daten vom Sasl oder noch eine offene Session vorhanden war, die der Angreifer nutzt.
Also alle Dienste beendet (postfix cyrus saslautd), Kennwort neu gesetzt und Server neugestartet, und nach 30 Minuten, waren sie wieder drin...., ohne Fehlversuch vorherigen....

Mir blieb nur den User zu löschen, man sieht nun mit genauen Abständen von ca. 30 Minuten einen fehlgeschlagenen Login-Versuch....

Code: Alles auswählen

Dec  3 15:54:18 debian postfix/smtpd[22603]: warning: unknown[91.143.17.156]: SASL LOGIN authentication failed: authentication failure
Dec  3 16:24:53 debian postfix/smtpd[22745]: warning: unknown[193.85.255.43]: SASL LOGIN authentication failed: authentication failure
Dec  3 17:05:45 debian postfix/smtpd[22813]: warning: unknown[95.9.133.127]: SASL LOGIN authentication failed: authentication failure
Dec  3 17:35:25 debian postfix/smtpd[22878]: warning: cC4C55BC1.dhcp.as2116.net[193.91.197.196]: SASL LOGIN authentication failed: authentication failure

Hier kann es sich doch nur im irgendeine Sicherheitslücke handeln oder? Hat jemand eine Idee was das sein kann? Hier ein Auszug aus meiner main.cf

Code: Alles auswählen

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

myhostname = $HOSTNAME
alias_maps = hash:/etc/aliases

mydomain = $DOMAIN
mydestination = $DESTINATIONS
relay_domains = $RELAY_DOMAIN
#relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

#mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
mailbox_transport = cyrus
mailbox_command = /usr/bin/procmail -t -a $EXTENSION

smtpd_sasl_authenticated_header = yes
message_size_limit = 1024000000

Danke und Gruß zusammen!

[MSfree]

Wenn das wirklich zuverlässig nach 30 Minuten passiert, könnte das auf ein Root-Kit deuten, das sich auf deinen Server geschlichen hat und alle halbe Stunde die sasl-Dateien so manipuliert, daß sich der "newsletter" von aussen anmelden kann.

[heisenberg]

Du könntest mal die Password-DB von Cyrus überwachen mit aktivem newsletter Konto. Wenn das Passwort von innen geändert wird, dann kannst Du Dir sicher sein, dass Du Dir was eingefangen hast.

[alpha9191]

Ich habe den Server mit rkhunter und chkrootkit durchsucht, ohne treffer. Den newsletter Account habe ich inzwischen gelöscht, kann jedoch nochmal schauen was passiert wenn ich ihn erneut anlege...

Was auch ziemlich strange ist, dass als sasl_username hinter der uid ein @-Zeichen ist. Habe selbst versucht mich mit so einem Benutzernamen einzuloggen, was jedoch nicht geklappt hat. Hab das vorher auch noch nie gesehen.

[MSfree]

Ich habe den Server mit rkhunter und chkrootkit durchsucht, ohne treffer.

Was ja erstmal gut ist, aber nicht garantiert, daß trotzdem etwas auf deinem System passiert, das nicht durch die tools aufgedeckt wird. Ich habe hier noch ein simples Skript, das nach Prozessen sucht, die nicht durch ps angezeigt werden und nicht unter /proc auftauchen:

Code: Alles auswählen

#!/bin/bash
# Das Skript testet, ob es Prozesse im System gibt, die ein
# Signal annehmen, aber nicht in /proc aufgelistet werden.
for PID in `seq 1 65535`; do
 if kill -0 ${PID} 2>/dev/null
 then
   if ls /proc/*/task/*/cmdline | grep "/${PID}/cmdline" >/dev/null
   then
     true
   else
     CMD=`cat /proc/${PID}/cmdline`
     echo "PID ${PID} versteckt?! cmdline: '${CMD}'"
   fi
 fi
done

Es wäre auch sinnvoll, nachzuschauen, welche Dateien unter /var/spool/cron/crontabs liegen und deren Inhalt genau zu analysieren (wegen der 30min Geschichte)

[alpha9191]

Hi,
danke für das Skript. Hat leider nichts gefunden. Der Crontab-Ordner ist ebenfalls leer.

[MSfree]

Hi,
danke für das Skript. Hat leider nichts gefunden. Der Crontab-Ordner ist ebenfalls leer.

Es gäbe noch die Möglichkeit, das System insgesamt zu überwachen. Mit dem acct Paket kann man jede Programmausführung protokollieren lassen und später analysieren. Dein 30-Minuten-Problem sollte dann in dem Log auftauchen.

Vorsicht ist bei solchen Werkzeugen allerdings geboten, wenn es um den Datenschutz geht, da wirklich jeder Krümel aufgezeichnet wird, der von den Benutzern fallen gelasssen wird. Wenn, dann sollte man das also nur zeitlich begrenzt einsetzen, betroffene Benutzer vorab informieren und die Logs nach Abschluß der Analyse vernichten.

[alpha9191]

Hallo MSfree,

danke erst mal für deine aktive Unterstützung. Ich werde mich nochmal melden sobald ich die Auswertung habe.

[r4pt0r]

Ist auf dem Server ein Webmailer installiert der Passwortänderung ermöglicht? Ggf gibts dort eine Lücke (XSS, SQLI..).

Ansonsten würde ich bei einem Mailserver _dringend_ ein upgrade auf stable anraten - evtl sogar eine Neuinstallation wenn nicht sicher ausgeschlossen werden kann dass der Server komprommitiert wurde.

[jkoerner]

[...]und versenden über Port 25 (SMTP) beides mit STARTTLS.

TLS über Port 25 finde ich schon „lustig“.

[DeletedUserReAsG]

STARTTLS auf 25 entspricht dem RFC.

[Dimejo]

Die Authentifizierung erfolgt mittels saslauth. E-Mails abrufen über Port 143 (IMAP) und versenden über Port 25 (SMTP) beides mit STARTTLS.

Du bietest die Authentifizierung über STARTTLS zwar an, erzwingst sie aber nicht. Es könnte also sein, dass ein Client ohne Verschlüsselung E-Mails einliefert, und die Authentifzierung somit im Klartext abläuft. Das macht es natürlich leicht Benutzernamen/Passwort mit zu schneiden und selbst zu verwenden.

Der Parameter smtpd_tls_auth_only würde dafür sorgen, dass AUTH erst offeriert wird, nachdem STARTTLS initiiert wurde.