Tag Archives: SMTP

CNR: Hetzner Mailsperre umgehen

Posted on by

Wer eine neue Serverinstanz bei Hetzner aufzieht, der wird bemerken, daß er keine Emails versenden kann.

CNR: Hetzner Mailsperre umgehen

Hetzner sperrt ausgehenden Port 25 Verkehr an deren Firewall. Das ist eine Reaktion auf Menschen, die dort eine VM aus dem Boden stampfen und dann zum Spammen missbrauchen, aber nie vorhatten für die Instanz zu zahlen. Euch trifft das leider auch, außer Ihr habt beim Linux am Dienstag Advanced SSH Training teilgenommen 😀

In diesem Fall ist die Lösung für Euch einfach:

Wir tunneln uns SMTP einfach zu einem anderen Server!

Auf dem ZIELServer, also dem, der die Mails dann am Ende versenden soll, geben wir das ein:

ssh -NCTf -R 127.0.0.2:25:127.0.0.1:25 root@hetzner.vm

Natürlich darf auf dem Hetznerserver kein SMTP laufen, sonst können wir uns dort nicht ungestört auf Port 25 binden.

Wenn Ihr so Mails versendet, dann denkt an den SPF Eintrag, der muß dann nämlich mehr als nur „a mx“ enthalten. Ich empfehle die Methode aber ohnehin nur für Utilityserver. Wollte Ihr dort auch Mails empfangen, dann wirds mit dem Portbinden lustig 😉 Hier wär es dann besser, abhängig von der Mailserversoftware einen Smarthost mit einem nicht-Standart-Port zu benutzen, weil die sind von der Firewallsperre nicht betroffen.

SSH ist hier nur deutlich weniger Aufwand als so ein !=25 Smarthost.

 

AT&T Mailserver kann kein TLS

Posted on by

Hallo,

heute befassen wir uns mal wieder mit dem Thema Mailsicherheit. Heute:

AT&T Mailserver kann kein TLS, nicht mal SSLv3

Ich habe ja bereits einige Mailserver erlebt, die gar kein TLS können, oder nur bereits gebrochene Dialekte sprechen. Meistens sind das Server von Leuten, die nicht in der Telekommunikationsbranche sind. Aber TK Firmen waren da noch nie drunter. Daher hatte mich das hier doch stark verwundert:

2021-03-26 12:55:09 1lPLyv-0002Bo-89 == abuse@att.net R=dnslookup T=remote_smtp defer (-38) H=ff-ip4-mx-vip2.prodigy.net [144.160.159.22]: a TLS session is required, but the server did not offer TLS support

ATT.net aka. AT&T kennen Amis gut. In Comedysendungen wird AT&T immer als Gag eingebaut, weil die im Mobilfunksegment ungefähr so kompetent sind, wie die Deutsche-Pre-Corona-Bahn beim Einhalten Ihres eigenen Fahrplans 🙂 Jetzt könnte man der Liste an AT&T Verfehlungen auch noch Inkompetenz beim Betreiben von Mailserver hinzufügen.

Das mein Mailserver mit seiner Aussage oben richtig liegt, zeigt auch ein Test von CheckTLS.com:

secondstest stage and result
[000.000]Trying TLS on 144.160.159.22[144.160.159.22:25] (-1)
[000.070]Server answered
[000.299]<‑‑220 flpd588.prodigy.net ESMTP Sendmail Inbound 8.15.2/8.15.2; Fri, 26 Mar 2021 06:27:18 -0700
[000.299]We are allowed to connect
[000.299]‑‑>EHLO www12-do.checktls.com
[000.368]<‑‑250-flpd588.prodigy.net Hello www12-do.checktls.com [142.93.73.156], pleased to meet you
250 ENHANCEDSTATUSCODES
[000.369]We can use this server
[000.369]TLS is not an option on this server
[000.369]‑‑>MAIL FROM:<test@checktls.com>
[000.438]<‑‑553 5.3.0 flpd588 DNSBL:RBL 521< 142.93.73.156 >_is_blocked.For assistance forward this error to abuse_rbl@abuse-att.net
[000.439]Cannot proof email address (reason: MAIL FROM rejected)
[000.439]Note: This does not affect the CheckTLS Confidence Factor
[000.439]‑‑>QUIT
[000.508]<‑‑221 2.0.0 flpd588.prodigy.net closing connection

Jetzt ratet mal wieso ich AT&T eine Abusemail schicken mußte…. DOS Angriff aus deren Netzwerk. Zum Glück nur Amateure.

Nachtrag:

Wollt Ihr noch was zu Lachen haben?

2021-03-26 14:46:25 1lPLyv-0002Bo-89 ** abuse@att.net R=dnslookup T=remote_smtp H=ff-ip4-mx-vip1.prodigy.net [144.160.159.21]: SMTP error from remote mail server after MAIL FROM:<XXX@XXXX.XX>: 553 5.3.0 flph832 DNSBL:ATTRBL 521< XX.XX.XX.XX >_is_blocked.For assistance forward this error to abuse_rbl@abuse-att.net

Der Server ist seit mehr als 10 Jahren ohne eine einzige Spamemail am Netz, weil das ein interner Server ohne Kunden von uns ist. 11 Jahre Hackfrei. Der selbe Server konnte dann an die abuse-att.net was senden 😉

Die nutzen vermutlich die gleiche veraltete DNS-Blackliste wie Fefe. Der Vorbesitzer von dem IP Netz hatte da wohl irgendwann mal Spams vermailt. Ein Glück setzen wir so schlecht gewartete Blacklisten nicht ein.

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

IT Niedersachsen verwechselt Mailserver ;)

Posted on by

Aus der Reihe: „Was kann bei SMTP schon schief gehen“ heute die: IT Niedersachsen.

IT Niedersachsen verwechselt Mailserver 😉

Wenn man viel Infrastruktur hat, kann einem das schon mal passieren. Vor einigen Jahren hatte ich mal einen Beitrag über die Stadt Wolfenbüttel im IT Sec Vortrag, weil deren Mailserver komische Zertifikate für SMTP benutzt hatte, die keiner kennen konnte, weil selbst-signiert und für interne Testserver gedacht. Damals hatte deren IT das Problem, es überhaupt zu finden, weil die Microsoftlösung Ihnen einen vom Pferd erzählt hatte 🙂

Vielleicht ist das jetzt so etwas ähnliches:

Wenn man eine Email an eine Adresse schicken will, die von diesem Server bedient wird:

80.228.54.249 „inetmail23.niedersachsen.de“

Dann bekommt man im Exim das hier:

SSL verify error: certificate name mismatch: DN=“/C=DE/ST=Niedersachsen/L=Hannover/O=Land Niedersachsen/OU=IT.Niedersachsen, FG 24a/CN=inetmail14.niedersachsen.de“

Weil das ausgelieferte Zertifikat nicht mit dem Hostnamen übereinstimmt. Vermutlich wurde einfach nur das falsche Zertifikat verteilt. Witzig ist nur, daß es auf beiden Servern passiert ist, denn ein „host inetmail23.niedersachsen.de“ zeigt zwei verschiedene IPs an. Da darf man von einem Deployserverproblem ausgehen, also hat es keiner mit Handarbeit verteilt 🙂