IT Niedersachsen verwechselt Mailserver ;)

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 🙂

 

Wie dĂ€mlich muß man sein…

Diese Logzeile habe ich grade aus dem Mailserver gezogen:

2018-10-09 10:44:35 SMTP protocol synchronization error (next input sent too soon: pipelining was not advertised): rejected „GET / HTTP/1.1″ H=[107.170.202.125] next input=“Host: mailserver:26\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n“

Ich ĂŒbersetz mal :

GET / HTTP/1.1
Host: mailserver:26
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

Wenn man sich das genau ansieht, wobei „MAILSERVER“ unsere Mailserver IP war, wird man bei HOST das irritierende „:26“ entdecken. Die Portnummer gehört im HTTP Protokoll gar nicht in den „Host:“- Header rein, trotzdem hat dieses miserable Script es angehĂ€ngt. Unser GlĂŒck, so kann man das aufklĂ€ren 🙂

Es handelt sich offenbar um einen Portscanner, der bei „nicht-so-standart“-Ports wie „26“ , einfach mal austestet, ob da nicht ein Webserver zu finden ist. Vielleicht in der Hoffnung da was zu finden, was auf Port 80 nicht zu finden wĂ€re, wer weiß. Auf Port 26 hat unser Mailserver einen Ausweichport, falls der DSL-Router des Kunden mal wieder Port 25 fĂŒr alles außer T-Offline-Mailservern sperrt. Das hat sich in der Vergangenheit extrem gut bewĂ€hrt, weil man im Mailprogramm nur statt Port 25 26 angeben brauchte und schon war diese leidige Routersperre umgangen.

EingefĂŒhrt haben die Routerhersteller das, damit die ganzen gehackten Windows-Pcs nicht stĂ€ndig das Netz mit Spams beglĂŒcken. Das war aber nur bedingt erfolgreich 😉

Wie kam ich jetzt auf dĂ€mlich, achso ja, weil sich der Mailserver natĂŒrlich, wie auf Port 25 auch, sofort als Mailserver outet 🙂 Man muß also nicht erst HTML hinschicken um zu sehen was es ist 😀

eine Weisheit

Wenn man die Scheisse Anderer nicht auslöffeln will,
sollte man den Stein, unter dem sie zu finden ist, nicht umdrehen.

Ein Teaser

Es folgt (vermutlich) bald(tm) ein Beitrag zum Thema Mailserver-TLS und es kommen oft die Worte „WIESO?“ ,“unsicher“,“gebrochen“ und vermutlich „args!“ darin vor. Die Liste der VerdĂ€chtigen beinhaltet das Who-is-Who nationaler und internationaler Konzerne.

hmm

Da ich ja schon frĂŒher ĂŒber TLS geschrieben habe, wĂ€r es dann nicht eigentlich ein Cliffhanger in einer Endlos-Storyline ? 🙂