Hallo Liste,
wie kann ich es unterbinden, das Mail User Agents wie Thunderbird, Outlook und co. Mails auf Port 25 einliefern können ? Diese sollen nur über 465 oder 587 einliefern dürfen.
Grüsse, Markus
Hallo Markus,
On 09 Sep 2016, at 16:15, Markus Gonzalez ml@markus-gonzalez.de wrote:
wie kann ich es unterbinden, das Mail User Agents wie Thunderbird, Outlook und co. Mails auf Port 25 einliefern können ? Diese sollen nur über 465 oder 587 einliefern dürfen.
Naja, solange Port 25 für andere MTAs offen bleiben sollen, hast du da leider nur weniger Möglichkeiten:
a) über Firewall-Regeln die Netze der MUAs auf Port 25 aussperren (z.B. Dialup-Lists in die Firewall einbinden)
b) du könntest deine User zwingen sich mit Client-Zertifikaten zu authentifizieren und dieser Zertifikate nur auf Port 465 bzw. 587/TLS annehmen.
Beides bringt eine ganze Reihe von Problemen und Nachteilen mit sich. Und ehrlich gesagt sehe ich auch die Motivation dahinter nicht. Was ist so schlimm daran, wenn ein MUA seine Mails auf 25 einkippt?
Viele Grüße, Jörn Bredereck
--
****************************** B&W-NetworX GmbH & Co. KG Landstr. 67a 76547 Sinzheim Fon: 07221 996388-8 Fax: 07221 996388-1 http://www.bw-networx.net info@bw-networx.net ----------------------------- AG Mannheim HRA 521208 Pers. haf. Ges.: B&W-NetworX Verwaltungs-GmbH Sitz: 76532 Baden-Baden AG Mannheim HRB Nr.: 202122 Geschäftsführer: Jörn Bredereck Dipl. Ing. Holger Wunsch ******************************
On 09.09.2016 23:35, Jörn Bredereck wrote:
Hallo Markus,
On 09 Sep 2016, at 16:15, Markus Gonzalez ml@markus-gonzalez.de wrote: wie kann ich es unterbinden, das Mail User Agents wie Thunderbird, Outlook und co. Mails auf Port 25 einliefern können ? Diese sollen nur über 465 oder 587 einliefern dürfen.
Naja, solange Port 25 für andere MTAs offen bleiben sollen, hast du da leider nur weniger Möglichkeiten:
a) über Firewall-Regeln die Netze der MUAs auf Port 25 aussperren (z.B. Dialup-Lists in die Firewall einbinden)
b) du könntest deine User zwingen sich mit Client-Zertifikaten zu authentifizieren und dieser Zertifikate nur auf Port 465 bzw. 587/TLS annehmen.
so sollte es auch möglich sein , die SASL-Authentifikation nur auf diesen Ports zuzulassen. Auf Port 25 darf sich also kein MUA amittels SASL/Dovecot authentifizieren und ebenso ohne authentifizierung keine Mails einliefern können.
So wäre mir das am liebsten.
Beides bringt eine ganze Reihe von Problemen und Nachteilen mit sich. Und ehrlich gesagt sehe ich auch die Motivation dahinter nicht. Was ist so schlimm daran, wenn ein MUA seine Mails auf 25 einkippt?
MTA's müssen ohne SSL/TLS Mails einliefern können, dies passiert in aller Regel auf Port 25. Würde ich hier TLS/SSL bzw. STARTTLS - so wie ich es mir von den MUA's wünsche - erzwingen, wäre das vermutlich ebenso bindend für MTA's, oder ?? Deswegen sollten MUA's nur die Ports 465 od. 587 verwenden können, damit ich genau das erzwingen kann.
Ich sehe das derzeit einfach als Sicherheitsrisiko, da ich in meinen Logs sehr häufig Loginversuche mit SASL sehe, die da nicht hingehören.
Viele Grüße, Jörn Bredereck
--
B&W-NetworX GmbH & Co. KG Landstr. 67a 76547 Sinzheim Fon: 07221 996388-8 Fax: 07221 996388-1 http://www.bw-networx.net info@bw-networx.net
AG Mannheim HRA 521208 Pers. haf. Ges.: B&W-NetworX Verwaltungs-GmbH Sitz: 76532 Baden-Baden AG Mannheim HRB Nr.: 202122 Geschäftsführer: Jörn Bredereck Dipl. Ing. Holger Wunsch
Hallo Markus,
Naja, solange Port 25 für andere MTAs offen bleiben sollen, hast du da leider nur weniger Möglichkeiten:
a) über Firewall-Regeln die Netze der MUAs auf Port 25 aussperren (z.B. Dialup-Lists in die Firewall einbinden)
b) du könntest deine User zwingen sich mit Client-Zertifikaten zu authentifizieren und dieser Zertifikate nur auf Port 465 bzw. 587/TLS annehmen.
so sollte es auch möglich sein , die SASL-Authentifikation nur auf diesen Ports zuzulassen. Auf Port 25 darf sich also kein MUA amittels SASL/Dovecot authentifizieren und ebenso ohne authentifizierung keine Mails einliefern können.
richtig, zumindest das Relayen wäre damit nicht mehr möglich. E-Mails für die eigenen Domains könnten damit weiterhin eingeliefert werden.
So wäre mir das am liebsten.
Ok, dann schalte die SASL-Authentifzierung für den SMTPD auf Port 25 aus und schalte ihn in der master.conf explizit nur für den SMTPD auf 465/587 an.
Oder du setzt einfach einen zweiten Postfix auf, der nur für das Relaying da ist. In einem grösseren Setup ist es sowieso empfehlenswert den User-Smarthost vom MX zu trennen. Das macht dann auch den Betrieb von komplett unterschiedlichen Policies viel einfacher, als wenn du einen MTA hast, der beide Rollen übernehmen muss.
Beides bringt eine ganze Reihe von Problemen und Nachteilen mit sich. Und ehrlich gesagt sehe ich auch die Motivation dahinter nicht. Was ist so schlimm daran, wenn ein MUA seine Mails auf 25 einkippt?
MTA's müssen ohne SSL/TLS Mails einliefern können, dies passiert in aller Regel auf Port 25. Würde ich hier TLS/SSL bzw. STARTTLS - so wie ich es mir von den MUA's wünsche - erzwingen, wäre das vermutlich ebenso bindend für MTA's, oder ??
naja, es gibt Leute die sagen, E-Mails von MTAs ohne TLS sollte man sowieso nicht mehr annehmen, aber das muss jeder selbst wissen. Ich für meinen Teil nehme auch noch Mails von MTAs ohne TLS an. Wobei der Anteil an MTAs, die ohne TLS vorbei kommen inzwischen verschwindend gering ist.
Ich sehe das derzeit einfach als Sicherheitsrisiko, da ich in meinen Logs sehr häufig Loginversuche mit SASL sehe, die da nicht hingehören.
Diese Bruteforce-Attacken wirst du aber weiterhin sehen. Dann bruteforcen die Script-Kiddies eben deinen Port 587 und nicht mehr 25. Was hast du dadurch gewonnen?
Wenn du dich gegen geknackte Passwörter schützen willst, helfen nur Client-Zertifikate oder evtl. noch eine Firewall, falls du auf IP-Ebene deine User vom Rest der Welt unterscheiden kannst. In vielen Firmen ist es inzwischen sogar üblich, dass die Laptop-User sich erstmal per VPN ins Unternehmens-Netz einwählen müssen, bevor sie die Mails dann über die LAN-IP-Adresse des Firmen-Mailservers verschicken können. Das ist auch sinnvoll, falls die User hinter irgendwelchen Hotel/Public-Hotspot-WLANs sitzen, die Port 25/587 in der Firewall blocken oder schlimmer noch: den SMTP-Traffic auf einen eigenen SMTP-Proxy umleiten.
Viele Grüße, Jörn Bredereck
--
****************************** B&W-NetworX GmbH & Co. KG Landstr. 67a 76547 Sinzheim Fon: 07221 996388-8 Fax: 07221 996388-1 http://www.bw-networx.net info@bw-networx.net ----------------------------- AG Mannheim HRA 521208 Pers. haf. Ges.: B&W-NetworX Verwaltungs-GmbH Sitz: 76532 Baden-Baden AG Mannheim HRB Nr.: 202122 Geschäftsführer: Jörn Bredereck Dipl. Ing. Holger Wunsch ******************************
Am Samstag, 10. September 2016, 00:28:58 CEST schrieb Markus Gonzalez:
Beides bringt eine ganze Reihe von Problemen und Nachteilen mit sich. Und ehrlich gesagt sehe ich auch die Motivation dahinter nicht. Was ist so schlimm daran, wenn ein MUA seine Mails auf 25 einkippt?
MTA's müssen ohne SSL/TLS Mails einliefern können, dies passiert in aller Regel auf Port 25. Würde ich hier TLS/SSL bzw. STARTTLS - so wie ich es mir von den MUA's wünsche - erzwingen, wäre das vermutlich ebenso bindend für MTA's, oder ?? Deswegen sollten MUA's nur die Ports 465 od. 587 verwenden können, damit ich genau das erzwingen kann.
Nein, das ist getrennt einstellbar. Falls es anders wäre, würden ja all die Setups, wo MUAs auf Port 25 ihre Mails einkippen nicht funktionieren. Und ich denke, derer gibt es Viele.
Die Trennung erfolgt in der Regel über die Reihenfolge bei den Restrictions. So erlaube ich mit "permit_mynetworks" erstmal Mails aus dem eigenen Netzwerk, in meinem Fall nur Localhost, und dann mit "permit_sasl_authenticated" via SASL-authentifizierte Mails. Und dann kommen alle Regeln, um Spam außen vor zu halten. Wichtig ist dabei eben auch "reject_unauth_destination" – denn sonst hättest Du ein offenes Relay. Mit der Option verweigert Postfix alle Mails, für die er nicht zuständig ist (siehe man 5 postconf):
reject_unauth_destination Reject the request unless one of the following is true:
· Postfix is mail forwarder: the resolved RCPT TO domain matches $relay_domains or a subdomain thereof, and con‐ tains no sender-specified routing (user@else‐ where@domain),
· Postfix is the final destination: the resolved RCPT TO domain matches $mydestination, $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, or $vir‐ tual_mailbox_domains, and contains no sender-specified routing (user@elsewhere@domain). The relay_domains_reject_code parameter specifies the response code for rejected requests (default: 554).
D.h. andere MTAs dürfen Mails bei mir ohne SASL abkippen, sofern die für mich sind und keine meiner Spam-Abwehrmaßnahmen auf SMTP-Ebene greift. So funktioniert das bei meinem Servers schon seit 10 Jahren oder so.
Ciao,
participants (3)
-
Jörn Bredereck -
Markus Gonzalez -
Martin Steigerwald