Massive Mailprobleme obwohl mailkonto gesperrt

monderka

Debian12, aktuell

Hostname:	server14.onit4u.de
Speicherplatz auf `/home`:	895.28 GiB frei 1800.59 GiB gesamt 813.77 GiB belegt
Installierte pd-admin-Version:	v4.144
Neueste pd-admin-Version:	v4.144
Lizenztyp:	light100
Lizenzdatei gültig bis:	2026-07-29
Limit Domains:	250
Installierte Reihe und Version der Serverumgebung:	4-0.495 (MySQL 5.5.62)
Neueste Version der Serverumgebung:	0.495

Folgende Einlieferungen von diversen IP-Adressen haben wir derzeit, sowohl von Postfächer die existieren, aber bereits gesperrt sind als auch E-Mailadressen auf denen gar kein MX auf dem Server eingerichtet ist.

Received: (qmail 1437107 invoked from network); 1 Jul 2026 09:37:36 -0000
Received: by simscan 1.4.0 ppid: 1419113, pid: 1437098, t: 0.2421s
scanners: clamav: 1.4.4/m:63/d:28047
Received: from unknown (HELO pectsvc1500uikqrzq6wsc0qp) (info@ferienbauernhof-ohr.de@178.219.125.70)
by 0 with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 1 Jul 2026 09:37:36 -0000
Content-Type: multipart/related; boundary="jd8ulu1lgiifqzqx2"
Content-Type: multipart/related; boundary="jd8ulu1lgiifqzqx2"
From: Naomi Murray<info@ferienbauernhof-ohr.de>
From: Naomi Murray<info@ferienbauernhof-ohr.de>
From: Naomi Murray <info@ferienbauernhof-ohr.de>

--jd8ulu1lgiifqzqx2
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

What's the point?, i am short, i need love, let's hang out together, miss y=
ou very much alone, look for me with this nickname - Spicy712, here i am <a=

nf2ln7o">Proceed to this link Please click here</a> You're my safe haven

Delete your e-mail --- <a
qjb165vkq6e8yv#dng670d4awnf2ln7o">here</a>
 
 
Glacier View Enterprises - 8484 Cedar St, Anchorage, AK
 
license mailing 2022-2026

--jd8ulu1lgiifqzqx2--

Ich habe mal betreffende Adressen auf /var/qmail/control/badmailfrom eingetragen, aber irgendwie kommt mir das komisch vor, das das überhaupt geht.
Ein Open-Relay konnte ich aber auch nicht feststellen.

Aber das frisst sich gerade durch alle E-Mailadressen auf dem Server

97395511 (10, R)
Return-path: LawrenceAnsen@metropol-medical-clinic.de
From: Lawrence Ansen@metropol-medical-clinic.de
To: Recipients <LawrenceAnsen@metropol-medical-clinic.de>
Subject: HI
Date: Wed, 01 Jul 2026 02:47:29 -0700
Size: 2479 bytes

97388312 (10, R)
Return-path: LawrenceAnsen@metropol-medical-clinic.de
From: Lawrence Ansen@metropol-medical-clinic.de
To: Recipients <LawrenceAnsen@metropol-medical-clinic.de>
Subject: HI
Date: Wed, 01 Jul 2026 02:45:54 -0700
Size: 2479 bytes

97395442 (10, R)
Return-path: LawrenceAnsen@metropol-medical-clinic.de
From: Lawrence Ansen@metropol-medical-clinic.de
To: Recipients <LawrenceAnsen@metropol-medical-clinic.de>
Subject: HI
Date: Wed, 01 Jul 2026 02:47:27 -0700
Size: 2479 bytes

Hat jemand eine Idee woher das kommt und wie man das sperrt, nachhaltig.

vlg
Manfred

monderka

Ich glaube das seit dem Upgrade von Debian11 auf 12 ein Openrelay entstanden ist

Wie kann man das wieder schließen?

Connection closed by foreign host.
root@debian9-vm01:/home/monderka# telnet server14.onit4u.de 25
Trying 78.46.40.200...
Connected to server14.onit4u.de.
Escape character is '^]'.
220 server14.onit4u.de ESMTP
EHLO test.de
250-server14.onit4u.de
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-PIPELINING
250 8BITMIME
MAIL FROM:<angreifer@example.org>
250 ok
RCPT TO:<opfer@gmail.com>
450 Still greylisted, come back later.
Connection closed by foreign host.
root@debian9-vm01:/home/monderka#

Dein qmail lehnt das Relay nicht ab, sondern der Greylisting-Dienst greift vor der eigentlichen Relay-Prüfung ein.

Das heißt:

✔ MAIL FROM wurde akzeptiert.
✔ RCPT TO wurde noch nicht auf Relay-Berechtigung geprüft.
✔ Greylisting hat die Sitzung mit einem temporären 450 beendet.

Ein 450 ist ein temporärer Fehler. Ein Open-Relay-Test ist damit noch nicht abgeschlossen.

Eisenherz

Ich denke, es könnte mit dem Update zu tun haben, aber eigentlich ist Qmail ja nicht aus den Quellen von Debian, sondern von pd-admin. Du solltest mal genauer in die Logs schauen und ggf. hier posten. Ansonsten ist es ohne Zugriff auf den Server schwierig zu sagen, wo genau das Problem liegt.

tbc233

Einen Zusammenhang mit Debian Update kann ich mir eher schwer vorstellen

Ist das eine pd-admin Installation, deren ursprüngliche Erstinstallation schon länger her ist? Ich erinnere mich nämlich dunkel an einen Bug in dem Service/Run File vor einigen Jahren, wo es zu einem offenen Relay kam weil irgendwie die HOSTNAME Variable falsch oder nicht gesetzt war - irgendwas in diese Richtung. Schau Dir mal Dein /service/qmail-smtpd/run File an und vergleiche mit einem halbwegs aktuellen:

Bash

#!/bin/bash

MAXCONN=$(cat /var/qmail/control/smtpmaxconn 2>/dev/null)
MAXCONNIP=$(cat /var/qmail/control/smtpmaxconnip 2>/dev/null)
MAXCONNC=$(cat /var/qmail/control/smtpmaxconnc 2>/dev/null)
NO_SSLv2v3=$(cat /var/qmail/control/no_sslv2v3 2>/dev/null)

export MAXCONN=${MAXCONN:-450}
export MAXCONNIP=${MAXCONNIP:-50}
export MAXCONNC=${MAXCONNC:-100}

test "${NO_SSLv2v3:-0}" -ne 0 && export NO_SSLv2v3

export DIEMSG="421 TOO MANY CONNECTIONS FROM IP"

QMAILDUID=$(id -u qmaild)
NOFILESGID=$(id -g qmaild)
HOSTNAME=$(hostname -f)

if [ "$HOSTNAME" == "" ]; then
   echo "Kein Hostname gesetzt."
   sleep 30
   exit 11
fi

exec /usr/local/bin/softlimit -m 125000000 \
     /usr/local/bin/tcpserver -x /etc/tcp.smtp.cdb -h -P -R -u $QMAILDUID -g \
     $NOFILESGID -c $MAXCONN -v 0 smtp \
     /var/qmail/bin/qmail-smtpd $HOSTNAME \
     /usr/local/pd-admin2/bin/checksmtppasswd /bin/true 2>&1

Alles anzeigen

tbc233

Ich hab das jetzt auf einem meiner Server probiert. Es kommt tatsächlich zunächst der Greylisting Mechanismus (Einlieferung wird geplantermaßen mit einem temporären Fehler abgebrochen), wenn man keine SMTP-Auth schickt. Ich bin unsicher ob das schon immer so war und man kann vielleicht auch diskutieren ob das elegant ist. Aber wenn man es nach ein paar Minuten dann nochmal probiert, kommt korrekterweise "553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)". Das ist letztendlich das was wichtig ist.

Wie verhält sich bei Dir ein Einlieferungsversuch, wenn Du es nach ein paar Minuten (sodass das Greylisting abgelaufen ist) nochmal mit gleichem Absender und Empfänger (sowie von der gleichen IP aus) probierst?

tbc233

Noch was, die Zeile

Code

Received: from unknown (HELO pectsvc1500uikqrzq6wsc0qp) (info@ferienbauernhof-ohr.de@178.219.125.70)
by 0 with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 1 Jul 2026 09:37:36 -0000

weist eigentlich darauf hin, dass die IP 178.219.125.70 mal so ganz grundsätzlich eine SMTP Authentifizierung mit diesem info User geschafft hat. Gibt es dieses Postfach und ist es ungesperrt? Falls ja, wurden die Zugangsdaten vermutlich kompromittiert. Falls nein, müsste geprüft werden ob es einen Weg gibt, die Authentifizierung zu umgehen.

tbc233

Bei der Gelegenheit, Daniel Bradler , es wäre vielleicht noch einen Ticken sicherer, wenn in den Scripten wie checksmtppasswd prepared Statements genutzt werden

Code

my $query;
my @params;

if ($login =~ /\@/) {
    my ($localpart, $host) = split /\@/m, $login;
    
    $query = "SELECT t1.password, t4.mail_submission, t1.suspended " .
             "FROM pop3 AS t1, vhosts AS t2, domains AS t3, users AS t4 " .
             "WHERE localpart = ? AND t1.vhost = t2.id AND t2.domain = t3.id " .
             "AND t2.name = '' AND t3.name = ? AND t3.owner = t4.id;";
             
    @params = ($localpart, $host);
} else {
    $query = "SELECT t1.password, t4.mail_submission, t1.suspended " .
             "FROM pop3 AS t1, vhosts AS t2, domains AS t3, users AS t4 " .
             "WHERE t1.login = ? AND t1.vhost = t2.id AND t2.domain = t3.id " .
             "AND t3.owner = t4.id;";
             
    @params = ($login);
}

# Statement vorbereiten
my $sth = $dbh->prepare($query) or die "Cannot prepare query: $DBI::errstr";

# Ausführen und die Parameter sicher übergeben
my $rv = $sth->execute(@params) or die "Cannot execute query: $DBI::errstr";

my ($pwc, $mail_submission, $suspended) = $sth->fetchrow_array;
$sth->finish;
$dbh->disconnect if $dbh;

Alles anzeigen

monderka

Vielen Dank für eure Input.
Ich denke das das Postfach auch kompromittiert war. Was mich nur sehr gewundert hat war das es trotz sperren des Postfachs, löschen des Postfachs und Server komplett neu starten nicht aufgehört hat.
Gefühlt habe ich den ganzen Tage die Mailqueue immer wieder bereinigt. Erst mit einer sperrung im qmail-control konnte das ganze in Griff bekommen werden.

Die üblichen open-relay-Tests habe ich auch gemacht, und ich fand keinen open relay der wirklich durch ging.

Das Run-Script ist uptodate. Keine Ahnung wie das so verheerend passieren konnte. Ich beobachte das weiterhin.

Danke nochmal für eure hilfreiche beteiligung.

Daniel Bradler

Eine Passwort-Aenderung allein reicht nicht, es muessen auch bestehende SMTP-Verbindungen beendet werden.

tbc233

Zitat von Daniel Bradler

Eine Passwort-Aenderung allein reicht nicht, es muessen auch bestehende SMTP-Verbindungen beendet werden.

Daran hatte ich auch gedacht, aber monderka hat ja erwähnt dass er die Maschine sogar rebootet hat, allerspätestens da dürften ja keine authentifizierten Sessions mehr offen gewesen sein.

monderka

Ja, das war das eigentlich komische. Weil nach der Passwortänderung nach wie vor sekündlich duzende mails mit qmail-remove -rp aus der Queue genommen wurden habe ich die komplette Maschine rebootet.
Danach hat es aber fast ne halbe stunde nicht aufgehört.

Was habe ich insgesamt gemacht:
- passwort im pdadmin für das betreffende E-mailpostfach geändert
- das postfach komplett gelöscht
- die domain komplett gelöscht mit allen postfächern

Aber da das immer noch nicht geholfen hat, auch trotz reboot habe ich dann die betreffende adresse in badmailfrom eingetragen.
Danach war dann langsam schluss.
seltsam war dann später noch eine weitere Welle mit einer E-Mailadresse von einer Domain die auf dem Server ein Web hat, aber keine Mailadresse und auch kein MX

Ich habe dann alle die das betroffen hat einfach die badmailfrom eingetragen, so konnte das alles erstmal stabilisiert werden.

Gestern und heute war aber nichts großartig verdächtiges mehr zu sehen, außer die normalen Angriffsversuche.

Insgesamt war das einfach komisch und ich kann es nicht genau sagen was die Ursache war.