An die IT der Stadt Braunschweig in Sachen MAILSERVER

Im Gegensatz zum letzten Lokalbeitrag über Lebensmittel bei Aldi Nord, kommt heute ein weniger ekliges Thema dran … Woher weiß man, daß man mit dem Mailserver der Stadt Braunschweig spricht?

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Liebe IT-Verantworlichen der Stadt Braunschweig,

wie wir Euch 2018 schon einmal mitgeteilt haben, sind Eure SSL-Zertifikate im Mailserver nichts wert. Glauben Sie nicht? Bitte schön:

$ openssl s_client --connect mailin02.braunschweig.de:25 -starttls smtp -verify_hostname mailin02.braunschweig.de
CONNECTED(00000003)
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify return:1
---
Certificate chain
0 s:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
i:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = BSSUBCA02
---

Was bedeutet die Ausgabe?

Das jemand ein Zertifikat auf „mailin02.braunschweig.de“ ausgestellt hat und anstatt dies von einer anerkannten Autorität (CA) beglaubigen zu lassen, es mit einem anderen selbst gebauten Zertifikat und dessen Schlüssel unterschrieben hat. Das macht natürlich aus dem ersten Zertifikat mailin02.braunschweig.de auch kein anerkanntes Zertifikat, sondern nur ein weiteres Zert, dem man nicht vertrauen kann.

Das Emails bei der Stadt Braunschweig trotzdem eingehen, liegt einfach daran, daß derartige Fehler sooft vorkommen, daß wer ernsthaft die Autorität eines empfangenden Mailserver prüft, kaum noch Emails rausbekommt. Besser macht die Erkenntnis den Fall natürlich auch nicht, es bleibt ein Setupfehler.

Anders läge der Fall, wenn das Zert mit dem Kürzel BSSUBCA02 selbst von einer bekannten CA verifiziert und beglaubigt wäre. Das kann man aber nicht prüfen, weil das dafür nötige Zert nicht mitgeliefert wird. Pech.

Es bliebt also dabei, diesem Server kann man nicht glauben, daß er wirklich die Stadt Braunschweig repräsentiert.

Weiß hier A nicht, was B tut?

Wer sich mal die Webseite unter Braunschweig.de näher ansieht, findet dort ein Zert für „*.braunschweig.de“, ein sogenanntes Wildcard-Zertifikat. Dies ist für alle beliebigen Domainnamen gültig, auch für „mailin02.braunschweig.de„. Wieso man das dann nicht für den Mailserver nimmt, kann ich nicht beurteilen. Das Wildcard Zert ist nicht eingeschränkt auf das Web ( was gehen würde ), es kann also überall eingesetzt werden.

Basierend auf der Erfahrung mit der Stadt Wolfenbüttel ( gleich hier um die Ecke ), würde ich mich jetzt aus dem Fenster lehnen und behaupten, daß das IT-Managementsystem auf Windowsbasis, daß die Stadt einsetzen wird um deren Firewall und Mailserver zu verwalten, den Admins nur die Innenseite des Netzes anzeigt, aber nicht, was außen wirklich los ist. Ich vermute, intern wird schon seit einiger Zeit ein korrektes Zert angezeigt und das uns gezeigte Mailserverzert ist bloß ein Fragment eines Testsetups von früher.

Das „Root CA 2“ Zert der Stadt Braunschweig, ist scheinbar von 2016 und das „mailin02.braunschweig.de“ von 2017, aber mit einer Gültigkeit von 10 Jahren. Dies ist ein typisches Testsetup, denn normale Zertifikate werden nach 1-2 Jahren getauscht.

Linux am Dienstag – Programm für den 17.8.2021

  • Sprechen wir doch mal über Sicherheitslücken, davon gibt es ja derzeit einige.

Linux am Dienstag – Programm für den 17.8.2021

Bei Linux am Dienstag am 17.8. 2021 geht es ab 19 Uhr u.a. um folgende Themen:

  • Mailserver – Spreche ich mit der Stadt Braunschweig?
  • OpenSSL – Ver- und Entschlüsselung in der Kommandozeile
  • Phising – Wieder neue Masche beim SMS Betrug
  • IT-Peinlichkeiten bei den Sicherheitsbehörden Heute: Police Crime Record Management System 1.0
  • Sicherheitslücken – US Farmindustrie gehackt
  • Kryptowährungen – Halbe Milliarde geklaut.. ähm.. dezentral gesichert

Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Kleine Anmerkung: Die bisherigen Vorträge findet man jetzt unter https://linux-am-dienstag.de/archiv/ .

AT&T Mailserver kann kein TLS

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