[SOLVED] exim4 und acl

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
TomL

Re: exim4 und acl

Beitrag von TomL » 06.05.2017 21:02:36

scientific hat geschrieben:Exim startet für jeden authentifizierten User einen eigenen Prozess bzw. eine eigene SMTP-Session auf.
Innerhalb dieser Session (als 5. Für jedes Mitglied der Familie je eine) gibt es die Variable $authenticated_id, auf die kann ich prüfen lassen.
Ich glaube, wir reden aneinander vorbei. Der am Client-PC angemeldete Linux-User oder Windows-User ist nicht gleichzeitig der am Server (eine andere Maschine) angemeldete Linux-User. Wenn ich mich z.B. auf dem Android anmelde, gibts auch keinen Linux-User. Auf dem Server läuft der MTA-D (exim/postfix) unter root, gestartet von systemd. Auf dem Server kann also gar keine auf den Client-Linux-User bezogene Session geöffnet werden, der entfernte Dovecot-User muss als Linux-User ja noch nicht mal auf dem Linux-Server eingerichtet sein. Wie wird also serverseitig durch Exim die $authenticated_id ermittelt, wenn auf Port 25 von einer anderen Maschine die zu sendende Mail von User Bart reinkommt, der als Absender unerlaubt Homer eingetragen hat? Und wie wird festgestellt, dass das unerlaubt ist, wenn Homer und Bart beide grundsätzlich berechtigt sind?

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: exim4 und acl

Beitrag von scientific » 06.05.2017 22:14:17

TomL hat geschrieben:
scientific hat geschrieben:Exim startet für jeden authentifizierten User einen eigenen Prozess bzw. eine eigene SMTP-Session auf.
Innerhalb dieser Session (als 5. Für jedes Mitglied der Familie je eine) gibt es die Variable $authenticated_id, auf die kann ich prüfen lassen.
Ich glaube, wir reden aneinander vorbei. Der am Client-PC angemeldete Linux-User oder Windows-User ist nicht gleichzeitig der am Server (eine andere Maschine) angemeldete Linux-User. Wenn ich mich z.B. auf dem Android anmelde, gibts auch keinen Linux-User. Auf dem Server läuft der MTA-D (exim/postfix) unter root, gestartet von systemd. Auf dem Server kann also gar keine auf den Client-Linux-User bezogene Session geöffnet werden, der entfernte Dovecot-User muss als Linux-User ja noch nicht mal auf dem Linux-Server eingerichtet sein. Wie wird also serverseitig durch Exim die $authenticated_id ermittelt, wenn auf Port 25 von einer anderen Maschine die zu sendende Mail von User Bart reinkommt, der als Absender unerlaubt Homer eingetragen hat? Und wie wird festgestellt, dass das unerlaubt ist, wenn Homer und Bart beide grundsätzlich berechtigt sind?
Ich glaub in der Tat, dass wir schon länger aneinander vorbeireden.. :)

Die ganze Mailgeschichte kommt ja meines Wissens aus der Unix-Welt. Und das war von Anfang an ein Multiuser-Betriebssystem, wo jeder User an der Maschine einen eigenen Account hatte und sich einloggen musste.

Die Maildir-Konfiguration von dovecot (ich glaub bei cyrus ist es nicht anders) geht auch von einem Maildir im Home des Users aus. Und hier spreche ich von einem User auf der Maschine auf dem der IMAP-Server läuft, nicht von irgendwelchen Clients auf denen Thunderbird, Android oder Windows in Betrieb ist.

Also in der Grundkonfiguration braucht jeder User, der auf dem IMAP-Server ein Postfach hat, einen UNIX-User-Account. Und mit diesem Account ein eigenen HOME, in welches ein Maildir mit den Emails kommt. dieses Maildir kann ganz normale Unix-Filesystem-Unterverzeichnisse haben, die dann auch im IMAP-Client als Unterordner zur INBOX angezeigt werden.

Jetzt kommen wir zum spannenden Teil für dich. IMAP-Server (dovecot) haben auch die Möglichkeit, eigene Datenbanken zu führen, wo virtuelle Useraccounts verwaltet werden. Daher ist in einigen Anleitungen zu Dovecot auch der User "vmail" und mit "mail" oder "dovecot" angeführt. "vmail" bedeutet "Virtuelles Mail". Also ein IMAP-Account ohne UNiX-Useraccount.

Da Mailhoster mit 1000en Kunden und Mailboxen aber nicht 1000e Unix-User auf ihren Maschinen einrichten nutzen diese die Möglichkeit der virtuellen USer. Diese lassen sich einfach mit LDAP, MYSQL oder bei kleinen Mengen auch über einfache Textfiles mit bestimmter Struktur verwalten. Zudem bieten virtuelle User eine Sicherheitsstufe mehr. Denn wenn bei normalen Unix-Usern IMAP-Credentials habe kann ich mich eventuell sogar direkt an der Maschine mit ssh einloggen und dort allerlei Schabernack treiben... Was mir als Mailhoster aber gar nicht recht wäre.

Nun zum Ablauf...

Das SMTP-Protokoll sah ursprünglich keinerlei Authentifizierung vor. POP und IMAP sehr wohl Denn es sollte jeder User nur seine eigenen Emails sehen, aber nicht jene von anderen USern. Und da mit den POP oder IMAP-Credentials auch ein Login an der Maschine auf der Shell möglich war (mutt, mail, und andere commandline-Tools für Mails setzen ja einen Login auf der Shell auf der MAschine voraus) nutzen diese Protokolle auch gleich diese Unix-User für die Authentifikation.

Abliefern von Emails war in der Anfangszeit ja kein großes Problem, da Spam unbekannt war und MIssbrauch ebenfalls.

Das SMTP-Protokoll wurde aber doch recht bald zur Verbreitung von Müll missbraucht, daher ließ man sich z.B. POP vor SMTP einfallen. Der SMTP-Server nahm von einer IP-Adresse nur dann ein Mail entgegen, wenn diese IP-Adresse zuvor eine erfolgreiche POP-Anmeldung erledigt hatte. Man ließ den Client also am POP-Port authentifizieren und der SMTP erfuhr davon und gestattete ein Abliefern der Email.

Das ist aber umständlich und nicht gründlich und sicher genug.

Daher wurde SMTP-Auth erfunden - also das Protokoll erweitert.

Damit eine SMTP-Sitzung (in der auch mehrere Emails abgeliefert werden können) erfolgreich aufgebaut werden kann, muss sich ein User Authentifizieren. Also einloggen. Dazu benötigt er Usernamen und Passwort. Dies kann der UNIX-Username des Accounts am Mailserver sein, oder ein Username der nur in einer Datenbank oder einem einfachen Textfile gespeichert ist.
Der SMTP-Server prüft ob das Passwort das der Client schickt (nachdem es der USer eingegeben hat oder der Keyring bereitgestellt hat) mit jenem in der Datenbank übereinstimmt und setzt die SMTP-Sitzung fort. Dann werden die Emails gesendet und die Sitzung beendet.

In Thunderbird merkst du das daran, dass du dem SMTP-Server-Zugang als Authentifizierungsmethode Plain oder Login mit Username und Passwort angeben musst. Wenn du keine Authentifizierungsmethode wählst, spricht Thunderbird mit dem SMTP-Server einfaches SMTP, kein SMTP-AUTH!!!

Der Username und das Passwort, das in Thunderbird beim SMTP-Server hinterlegt ist, hat mit dem User der auf der Maschine auf der Thunderbird läuft nichts zu tun. Es kann ja auch Windows oder Android sein... Aber bei allen gibst du Username und Passwort an. Eben jenen eines Accounts auf dem Mailserver!

exim setzt dann die Variable $authenticated_id auf genau jenen USernamen, den du bei den Authentifikations-Credentials in Thunderbird angibst. Und gegen genau diese ID lasse ich meine ACL prüfen.

Wenn das Email von localhost (also von einem Daemon) kommt, dann ist $authentificated_id der USername unter dem der Daemon läuft. Das kann root sein, oder Debian-exim oder _apt oder minidlna... je nachdem unter welchem User eben der Prozess läuft, der das email versendet. Von localhost ist auch in der Regel die Authentifikation abgedreht, sonst könnten nämlich die Daemons keine Emails senden.
Das war/ist ein Problem mit meiner ACL, dass Daemons mit der ACL ebenfalls eine Authentifizierung machen müssten - was diese aber nicht können.

TLS oder STARTTLS hat hingegen nichts mit der Authentifizierung zu tun. Aber eine PLAIN oder LOGIN-Authentifizierung übertragen USername und Passwort im Klartext. Daher setzen diese Authentifikationsmethoden eine TLS-gesicherte Verbindung voraus. (Muss in exim konfiguriert werden)

Wenn du aber kein SMTP-AUTH konfiguriert hast, dann kannst du auch nicht gegen eine authentifizierte ID prüfen und damit kann jeder der eine andere Absenderadresse kennt, diese bei seinen Emails einsetzen und so Missbrauch veranstalten und Emails im Namen anderer versenden. Um das zu verhindern, musst du zwingend SMTP-AUTH aktivieren und zwingend aktivieren. Zumindest für nach außen offene Ports.

Wenn man es streng nimmt, kann der IMAP-Server, der SMTP-Server und der Datenspeicher auf dem die Emails dann physisch abgelegt werden und auch eine Datenbank mit den Userinformationen für die virtuellen User auf völlig getrennten Computern in verschiedenen Rechenzentren installiert sein, und es würde immer noch funktionieren. Der Client authentfiziert sich immer nur am IMAP- und bestenfalls auch am SMTP-Server. Und der IMAP und der SMTP-Server müssen nicht einmal miteinander kommunizieren. Für den Admin ist es einfacher, wenn die Credentials von einem Datenspeicher für beide Server kommen. Muss aber nicht sein. Beide Server (exim und dovecot) haben die Möglichkeit gegen pam zu authentifizieren, gegen /etc/passwd und /etc/shadow, gegen eigene Passwort-fIles, gegen einen mysql-server oder gegen ldap. Exim kann die Authentifikation aber auch an cyrus oder dovecot abtreten und nimmt nur ein ok und $authenticated_id entgegen.

Ich hoffe, jetzt ist es ein wenig klarer geworden mit dem UNIX-User und dem Konto unter dem Thunderbird gestartet wurde... :)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: exim4 und acl

Beitrag von TomL » 06.05.2017 23:33:16

Alles., was Du mir erklärt hast, war mir soweit technisch bekannt. Der Grund für das Missverständnis ist mir jetzt aber klar...
scientific hat geschrieben:Die Maildir-Konfiguration von dovecot (ich glaub bei cyrus ist es nicht anders) geht auch von einem Maildir im Home des Users aus. Und hier spreche ich von einem User auf der Maschine auf dem der IMAP-Server läuft, nicht von irgendwelchen Clients auf denen Thunderbird, Android oder Windows in Betrieb ist.
... denn wir hatten die ganze Zeit einen anderen Fokus, eine andere Perspektive auf das Auth-Verfahren gehabt. Du nutzt anscheinend die lokale Anmeldung am Linux-Server, mit dem dortigen Homedir und kennst deshalb den angemeldeten User. Und genau den kenne ich nicht. Für mich war die ganze Zeit über klar, dass meine User das nämlich so nicht nutzen können.

Die Mailordner liegen auch nicht in den Homedirs, sondern zentral auf einer externen Platte, dort aber in userbezogenen Verzeichnissen - auf die der User, wenn er sich lokal am Server anmelden könnte, noch nicht mal Rechte hat. Mein PI hat nämlich keine interne Platte mit installiertem Linux und lokalen Homedirs, sondern nur die 16GB-SD-Card für das Linux, die aber fast komplett von allen Schreibvorgängen ausgenommen ist - das heisst, ausser beim Upgrade wird die nicht beschrieben. Deshalb findet bei mir die Anmeldung immer über virtuelle User statt, genau so wie bei den Internet-Mail-ISP, von beliebigen Clients, von beliebigen OS, übers Internet getunnelt, direkt im LAN, aber immer ohne sich auf dem Server Linux-seitig anmelden zu müssen. Und natürlich gibts ein komplettes Dovecat-Auth, ein ordentliches POP3-Auth, und selbstverständlich ein explizites SMTP-Auth, so das keine "wilden" User senden können.

Aber es gibt eben keine Plausiprüfung, ob der User bei der "benutzerdefinierten Verwendung" einer Absender-Adresse (aus dem Pool aller in Postfix definierten) überhaupt für diese Adresse berechtigt ist. Der User ist gültig und hat sich ordentlich angemeldet, die Absender-Adresse ist gemäß Auth verifiziert und ebenfalls gültig und somit berechtigt, der Relayhost ist gemäß Auth-Tabelle korrekt gesetzt und hat passende Anmeldedaten.... also kann "Bart" einfach als Absender "Homer" eintragen. Die Voraussetzung ist anscheinend, man muss gültige Anmeldedaten haben und eine gültige Absenderadresse kennen, die nicht mir gehört, aber beim gleichen Relayhost bekannt ist.

Ich will morgen mal probieren, ob das nicht sogar auch bei GMX oder Strato möglich ist... in dem ich die GMX-Adresse meines Sohnes als Absender eintrage, aber meine Anmeldedaten für den SMTP verwende.... ich bin mal gespannt, ob das durchgeht.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: exim4 und acl

Beitrag von scientific » 07.05.2017 00:20:22

TomL hat geschrieben:Alles., was Du mir erklärt hast, war mir soweit technisch bekannt. Der Grund für das Missverständnis ist mir jetzt aber klar...
scientific hat geschrieben:Die Maildir-Konfiguration von dovecot (ich glaub bei cyrus ist es nicht anders) geht auch von einem Maildir im Home des Users aus. Und hier spreche ich von einem User auf der Maschine auf dem der IMAP-Server läuft, nicht von irgendwelchen Clients auf denen Thunderbird, Android oder Windows in Betrieb ist.
... denn wir hatten die ganze Zeit einen anderen Fokus, eine andere Perspektive auf das Auth-Verfahren gehabt. Du nutzt anscheinend die lokale Anmeldung am Linux-Server, mit dem dortigen Homedir und kennst deshalb den angemeldeten User. Und genau den kenne ich nicht. Für mich war die ganze Zeit über klar, dass meine User das nämlich so nicht nutzen können.

Die Mailordner liegen auch nicht in den Homedirs, sondern zentral auf einer externen Platte, dort aber in userbezogenen Verzeichnissen - auf die der User, wenn er sich lokal am Server anmelden könnte, noch nicht mal Rechte hat. Mein PI hat nämlich keine interne Platte mit installiertem Linux und lokalen Homedirs, sondern nur die 16GB-SD-Card für das Linux, die aber fast komplett von allen Schreibvorgängen ausgenommen ist - das heisst, ausser beim Upgrade wird die nicht beschrieben. Deshalb findet bei mir die Anmeldung immer über virtuelle User statt, genau so wie bei den Internet-Mail-ISP, von beliebigen Clients, von beliebigen OS, übers Internet getunnelt, direkt im LAN, aber immer ohne sich auf dem Server Linux-seitig anmelden zu müssen. Und natürlich gibts ein komplettes Dovecat-Auth, ein ordentliches POP3-Auth, und selbstverständlich ein explizites SMTP-Auth, so das keine "wilden" User senden können.
Wie geschrieben, in der Grundkonfiguration sind die Maildirs im Home des Users.
Ich habe dovecot anders konfiguriert, sodass die Verzeichnisse für die User in /var/mail/$USER liegen. Und /var/mail könnte natürlich ein Mountpunkt für eine externe Platte sein.

Wenn du ein explizites SMTP-AUTH verwendest, hättest du in exim auch die Variable $authenticated_id gesetzt und könntest danach abfragen. Ich gehe davon aus, dass auch postfix eine solche Variable setzt, wenn ein User authentifiziert ist.

Und ich hab das Gefühl, dir fehlt noch ein Stück. exim ist es ziemlich egal, ob das ein tatsächlicher Unix-User des Mailservers ist, oder ein virtueller User aus einer Datenbank. Wenn sich ein Client authentifiziert, dann als einer dieser User.
TomL hat geschrieben: Aber es gibt eben keine Plausiprüfung, ob der User bei der "benutzerdefinierten Verwendung" einer Absender-Adresse (aus dem Pool aller in Postfix definierten) überhaupt für diese Adresse berechtigt ist. Der User ist gültig und hat sich ordentlich angemeldet, die Absender-Adresse ist gemäß Auth verifiziert und ebenfalls gültig und somit berechtigt, der Relayhost ist gemäß Auth-Tabelle korrekt gesetzt und hat passende Anmeldedaten.... also kann "Bart" einfach als Absender "Homer" eintragen. Die Voraussetzung ist anscheinend, man muss gültige Anmeldedaten haben und eine gültige Absenderadresse kennen, die nicht mir gehört, aber beim gleichen Relayhost bekannt ist.

Ich will morgen mal probieren, ob das nicht sogar auch bei GMX oder Strato möglich ist... in dem ich die GMX-Adresse meines Sohnes als Absender eintrage, aber meine Anmeldedaten für den SMTP verwende.... ich bin mal gespannt, ob das durchgeht.
Und noch was... es authentifiziert sich nicht eine Absenderadresse, sonder ein User. Das ist ein gravierender Unterschied.
Ich weiß, dass bei gmail der Username zum Authentifizieren die Email-Adresse ist. Bei gmx ebenso. Aber die email-Adresse ist in diesen Fällen ident mit dem Authentifizierungsnamen. Aber das muss nicht so sein.

Das bedeutet, du gibst dem Client (Thunderbird) einen Usernamen und nicht eine Emailadresse zum Authentifizieren beim SMTP-Server.

Und deinem SMTP-Server musst du beibringen, dass er zu diesen Usernamen nur bestimmte Absenderadressen zulässt. Das aber nur bei authentifizierten SMTP-Sitzungen. Nichtauthentifizierte Sitzungen dürfen aber nur mehr auf localhost möglich sein. Das zu lösen ist wohl auf einem expliziten Mailserver einfacher, als auf meiner Lösung, wo der Mailserver gleichzeitig auch mein Arbeitsrechner ist...

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: exim4 und acl

Beitrag von TomL » 07.05.2017 11:50:08

Moin scientific
scientific hat geschrieben:Wenn du ein explizites SMTP-AUTH verwendest, hättest du in exim auch die Variable $authenticated_id gesetzt und könntest danach abfragen. Ich gehe davon aus, dass auch postfix eine solche Variable setzt, wenn ein User authentifiziert ist.
Du hörst nicht zu, ich habe das bereits mehrfach gesagt: Postfix macht SMTP-Auth über einen SASL-Password-Check. Das entspricht anscheinend dieser authenticated_id. Das lief bereits schon vom ersten Tag an auf meiner Test-Maschine. "Wilde" (also unberechtigte) Sender von Emails sind gar nicht möglich. Und ich kenne auch den Unterschied zwischen Account-Anmelde-Daten und einer Email-Adresse. Nur orientiere ich mich dabei am etablierten Verfahren der Mail-ISP und verwende deshalb auch die lokale Email-Adresse als Anmelde-Name.
Und ich hab das Gefühl, dir fehlt noch ein Stück. exim ist es ziemlich egal, ob das ein tatsächlicher Unix-User des Mailservers ist, oder ein virtueller User aus einer Datenbank. Wenn sich ein Client authentifiziert, dann als einer dieser User.
Nein, mir fehlt nichts. Du wirst aber feststellen, was Dir noch fehlt, wenn Du Dein Modell auf ein tatsächlich serverbasiertes Konzept ohne synchrone Linux-User-Accounts transportieren willst, wenn es also keine lokale Linux-Benutzererkennung gibt und der Traffic rein via TCP/IP und Ports abläuft, wo Du am Server weder den Linux-User kennst, noch die Art des Clients und der verwendeten Software. Das kann ein Android mit K9-Mail sein, oder ein Windows-PC, oder Linux, ein Thunderbird via Tethering, oder direkt im LAN, oder getunnelt durchs VPN, ein auf dem Linux-Server bekannter User, oder ein unbekannter ganz ohne Server-Zugriff. Das waren nämlich genau die Hürden, wegen derer ich mit exim gescheitert bin. Es war mir deutlich zu kompliziert, das nach meinen Anforderungen einzustellen.
Das bedeutet, du gibst dem Client (Thunderbird) einen Usernamen und nicht eine Emailadresse zum Authentifizieren beim SMTP-Server.
Nein, geb ich nicht - meine Thunderbirds kennen den ISP-SMTP gar nicht, sondern nur ihre Anmeldung an Dovecot/Postfix im LAN. Und beim Senden einer Mail wird über den Relay-SMTP-SASL-Check festgestellt, ob der lokale User überhaupt berechtigt ist, das zu tun. Wie ich sagte, "wilde" Sender sind gesperrt. Da ist eindeutig festgelegt, welche User das dürfen. Aber ganz nebenbei bemerkt, das, was bei mir möglich ist, nämlich dass "Bart" in seiner Mail den benutzerdefinierten Absender "Homer" eintragen kann, geht auch bei GMX und WEB.de. Ich habs gerade getestet. Die Mail kommt mit einem Fake-Absender einwandfrei bei mir an. Es sind die gleichen Rahmenbedingungen.... ich bin als GMX-Kunde mit gültigem Usernamen und Password berechtigt, deren SMTP zu nutzen.... und es wird seitens ISP nicht verhindert, dass ich einen Fake-Absender eintrage. Tja...
Und deinem SMTP-Server musst du beibringen, dass er zu diesen Usernamen nur bestimmte Absenderadressen zulässt.
Dann sag mir mal wie.... wenn anscheinend nicht mal GMX und WEB das machen. Ich kann dem "Usernamen" via SASL-Auth-Check nur erlauben den SMTP-Server zu benutzen und alle anderen sind verboten... aber ich kann ihm keine Vorschriften machen, was seine Mail enthält....und dazu gehört eben auch der Absendername. Solange er als User grundsätzlich berechtigt ist, sich anzumelden und den SMTP zu verwenden, kann er in dieses Feld eintragen, was er will, die Mail geht trotzdem raus. Vesuchs einfach selber, was passiert, wenn Du das OHNE lokale Anmeldung auf der Maschine tust, wo exim und dovecot laufen, sondern mit einem MAIL-ISP-analogen Anmeldeverfahren, und zwar nur über Ports und eine reine TCP/IP-Verbindung.

Nachtrag:
Bei Strato kann ich als Absender auch eintragen, was ich will... sogar 12345@x.de.... genau mit diesem Absender kommt die Mail bei mir an. 8) Also mach ich mir jetzt auch keinen weiteren Kopp darüber. Es kommt nur darauf an, dass ich mit gültigen Anmeldedaten grundsätzlich berechtigt bin, die Services IMAP/POP3/SMPT zu nutzen. Und mal ganz ehrlich... ich habe jetzt echte Zweilfel daran, dass Exim das lösen können soll.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: exim4 und acl

Beitrag von scientific » 07.05.2017 15:10:20

Nun...

$authenticated_id ist eine Servervariable, die exim4 setzt, sobald eine SMTPauthentifizierung erfolgreich gemacht wurde.
Diese Variable steht für diese SMTP-Sitzung dauerhaft zur Verfügung. In Exim!

Ob in dieser Variable der Username aus der Unix-Userdb oder aus einem password-file oder sonstwoher kommt, ist egal.
Du gibst in Thunderbird für den SMTP-Server einen Usernamen an. DAS wird in dieser Variable gespeichert. IN EXIM.

Und da ich meinen Exim voll unter meiner Kontrolle habe, kann ich auch steuern, dass für diesen User, der sich am SMTP-server authentifiziert nur bestimmer Absender im Header zugelassen sind. Anderenfalls wird das Email schon bei der Einlieferung zurückgewiesen.

Was gmx macht, und dass die dort so eine Missbrauchslücke offen haben, ist mir ziemlich powidl. Ein Mailserver unter meiner Kontrolle soll diese Lücke nicht haben...

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: exim4 und acl

Beitrag von TomL » 07.05.2017 18:44:46

scientific hat geschrieben:Was gmx macht, und dass die dort so eine Missbrauchslücke offen haben, ist mir ziemlich powidl. Ein Mailserver unter meiner Kontrolle soll diese Lücke nicht haben...
:mrgreen:

Naja, so groß ist die Lücke also nicht. Ich habe das weiterhin noch mit Web und Strato verifiziert, dort ist es dasselbe. Und ich bin zu dem Schluß gekommen, dass das völlig in Ordnung ist und das die From-Adresse im Header als Security-Feature völlig belanglos ist. Ich habe diese Prüfung bei mir also schleunigst entfernt.

Meines Erachtens gibts nur einen Weg, das System zu härten... und zwar, in dem man es selber mit Telnet und OpenSSL testet. Ich habe mich mit reinen Terminalcommands via OpenSSL bei GMX angemeldet und mehrere Mails gesendet, das gleiche bei Strato, also nur mit CLI-Commands... um die Abläufe und Zusammenhänge sowie die Reaktionen des Servers besser zu verstehen. Ich habe mit From's, mit Usernamen und Veränderungen daran experimentiert, mit Passwörtern, die jeweils beide vor dem Senden mit "base64" geschlüsselt werden müssen. Das A und O sind ohne jeden Zweifel der korrekte Username und das dazugehörige korrekte Passwort, um sich via CLI anzumelden und erfolgreich eine Mail zu senden. Was die Mail beinhaltet, eben auch die From-Adresse, ist völlig irrelevant für die Sicherheit. Ich hab das gleiche natürlich auch mit Telnet versucht. Telnet war natürlich nicht erfolgreich.

Die gleiche Test-Prozedur mit OpenSSL und Telnet habe ich dann auf Postfix "losgelassen". Telnet ging erwartungsgemäß natürlich nicht, weil ich zwingend SSL verlange ... aber ...oh Bullshit... ich konnte mich im Terminal und im eigenen LAN direkt auf dem Port 25 via OpenSSL anmelden und ohne Username und Passwd eine Mail senden. Da habe ich erst mal dumm geguckt, weil nämlich damit offenkundig wurde, dass das in Thunderbird eingetragene SMTPD-SASL-Password gar nicht abgefragt wird. Lediglich mein Sender-Filter (also der Envelope-From) wurde geprüft... und war der From gültig, konnte ich via OpenSSL senden.
Daraufhin habe ich natürlich den Sender-Filter schnell wieder entfernt, weil das ja tatsächlich die schwächste Prüfung überhaupt ist und stattdessen einen echten SASL-Auth implementiert. Damit interessiert mich eine auf dem Server lokale Postfix-Berechtigungsverwaltung überhaupt nicht mehr. Der SMTPD-SASL-Auth ist über einen lokalen Socket zur Dovecot-DB umgesetzt. Wer kein Dovecot-Konto hat, hat damit auch keine SMTPD-Berechtigung. Und jetzt ist es auch nicht mehr via CLI und OpenSSL möglich, eine Mail ohne Anmeldung zu senden. Und das wichtigste... erst jetzt hat das Thunderbird-SMTPD-PWD endlich eine Bedeutung. Es sind jetzt also -so, wie es beim Senden sein muss- zwei Authentifizierungsebenen vorhanden, wobei der Client nur eine bedient, und zwar die über den Thunderbird-Client... zum Relay-SMTP regelt das ja Postfix:

Code: Alles auswählen

+-------+    +----------+    +-------+    +---------+    +--------+  
|Client |--->|SMTPD-SASL|--->|Postfix|--->|SMTP-SASL|--->|Mail-ISP|  
+-------+    |Auth.     |    +-------+    |Auth.    |    +--------+  
             +----------+                 +---------+               
Also... eines muss ich ja nach unseren zweimaligen Gedankenaustausch ganz klar feststellen... auch wenn das manchmal wegen unterschiedlichem Fokus und Perspektiven schwierig war.... ohne diesen Austausch wäre mir das alles nicht gelungen, weil ich als Laie niemals von alleine auf die wichtigen Fragen gekommen wäre und dann vermutlich nie die richigen Anworten gefunden hätte. Für mich war das also sehr erfolgreich. :THX:

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: exim4 und acl

Beitrag von scientific » 07.05.2017 22:40:01

Nun... eine Sicherheitslücke ist es nicht wirklich, da die Integrität des Mailservers damit nicht zerstört werden kann.
Aber ich finde es SEHR bedenklich, wenn andere meine Adresse als Absender im Email verwenden können... Dein Beispiel mit den Simpsons ist das sehr gut gewählt.

Stell dir einmal vor, du bist in der Arbeit in einer unguten Konkurrenzsituation. Es geht um einen Job oder einen großen Auftrag. Und dein Konkurrent schreibt ein kompromittierendes Email an deinen Arbeit- oder Auftraggeber und verwendet deine private gmx-Adresse als Absender... Weil dein Konkurrent ist technisch zumindest auf dem Level, auf dem wir zwei gerade sind und ist neugierig und findet genau diesen Thread... Bei gmx ist man schnell registriert... und ganz ehrlich... welcher Arbeitgeber ist technisch so auf der Höhe, überhaupt Headerzeilen in einem Email zu finden?
Die allermeisten verwenden wohl Outlook. Hast du schon mal probiert in Outlook die Headerzeilen eines Emails anzusehen???
Also das muss man mal finden, und dann muss man noch verstehen, was darin steht und dann braucht man noch ein besseres technisches Verständnis um überhaupt zu glauben, wenn man dem Auftraggeber erklärt, dass dieses Email von jemand anderem versendet wurde...

Für mich ist diese unsere Diskussion wieder ein Grund mehr, von den großen Mailanbietern wegzugehen und ein eigenes Email-Service aufzubauen... nämlich für mich und die Menschen in meinem Umfeld die mir wichtig sind - und die auch ein entsprechendes Sicherheitsbewusstsein haben.

Soviel zum prinzipiellen...

Wo ich allerdings immer noch denke, dass du einen Knopf im Denken hast... :)
Naja, so groß ist die Lücke also nicht. Ich habe das weiterhin noch mit Web und Strato verifiziert, dort ist es dasselbe. Und ich bin zu dem Schluß gekommen, dass das völlig in Ordnung ist und das die From-Adresse im Header als Security-Feature völlig belanglos ist. Ich habe diese Prüfung bei mir also schleunigst entfernt.
Die Geschichte mir dem Absender als "Security-Feature" zu kennzeichnen ist in der Tat übertrieben. Security ist etwas ganz anderes... Es ist lästig bis geschäfts- und rufschädigend, wenn jemand anderer völlig problemlos ein Email mit meinem Absender versenden kann. Aber die Sicherheit eines Computersystems wird damit niemals untergraben. Damit würd ich es nicht als Security-Problem kennzeichnen.

In der Tat ist es aber ein Security-Problem, wenn man sich auf allen möglichen Ports ohne Login per telnet von überall her auf einer Maschine einloggen kann.
Aber das hat nichts mit einer Prüfung auf einen Absender-Header zu tun.

Das ist eine Konfigurationsgeschichte ob TLS, STARTTLS und ob SMTP oder SMTP-AUTH auf welchen Ports zugelassen wird.

Auf localhost (also 127.0.0.1 oder ::1) muss wohl auf Port 25 ein Abliefern von Emails ohne Authentifikation möglich sein, sonst kann niemals ein Daemon ein Email an root oder den Admin-User senden.
Ob Port 25 nur auf localhost oder dem lo lauscht oder auch auf eth0 oder wlan0 macht einen bedeutenden Unterschied.
Dass auf Port 587 ausschließlich STARTTLS oder TLS möglich ist, und nur wenn eine TLS-gesicherte Verbindung aufgebaut ist dann ein PLAIN oder LOGIN-Authentifizierungsvorgang erzwungen wird, ist wohl heute Grundvoraussetzung.
Hier beginnt die Security im Email-Verkehr. Verschlüsselte Verbindung und erzwungene Authentifizierung. Damit ist ziemlich sichergestellt, dass die Authentifikations-Credentials nicht im Klartext übers Internet geschickt werden, und dass nur bekannte Teilnehmer am Mailverkehr teilnehmen können.

Das ist bei mir allerdings immer noch ein kleines spanisches Dorf, wie ich das bombenfest implementiere, sodass ich damit auch ans öffentliche Netz gehen kann.
Am liebsten wäre mir ja eine Client-Zertifikats-Authentifizierung. Aber da muss ich wohl noch ein wenig weiterstudieren, wie ich das auch nachvollziehbar auf einem anderen Rechner implementieren kann.

Und jetzt nochmal zurück zur eigentlichen Geschichte :)

Es sind - wie du korrekt erwähnst - zwei Ebenen beim Mailversand über den eigenen Mailserver von Thunderbird oder auch vom CLI.
Erste Ebene:
Der Client (Thunderbird, openssl, mail, telnet) kontaktiert den SMTP-Server.
Der SMTP-Server agiert als Server und nimmt ein Email entgegen oder rejectet es.
Nimmt er das Email an, kommt es in eine Queue.

Zweite Ebene:
Der SMTP-Server kontaktiert einen Smarthost um das Email weiter zu senden.
Der eigene SMTP-Server hat nun die Rolle eines Clients (so wie Thunderbird, openssl oder andere) und der Smarthost ist ein SMTP-Server in der Rolle eines Servers.
Der eigene SMTP-Server arbeitet die Queue ab und versendet ein Email nach dem anderen an den Smarthost indem er eine SMTP-Sitzung aufbaut (authentifiziert oder nicht) und dann ein Email nach dem anderen sendet. dann wird die SMTP-Sitzung wieder beendet.

Das heißt:
der eigene SMTP-Server in seiner Funktion als Server in der ersten Ebene erzwingt eine Authentifizierung mit Username und Passwort von Thunderbird, openssl oder mail..
Kann sich dieser Client authentifizieren, (dann setzt exim4 die Variable $authenticated_ID) nimmt er in Folge für diesen authentifizierten User Emails entgegen und wirft sie in die Queue.
Hier setzt der selbst unter Kontrolle stehende Security-Prozess an.
Habe ich alle Ports so konfiguriert, dass sie TLS verlangen und ein Login erzwingen, oder kann ich mich auch per telnet ohne Authentifizierung ein Mail versenden?
Ich habe an genau dieser Stelle eine zusätzliche Prüfung eingebaut:
Darf der authentifizierte User diese From-Header überhaupt verwenden? Wenn nein, wird das Email zurückgewiesen. Der Client bekommt eine Fehlermeldung.

Ist das Email in der Queue angelangt muss der Server in seiner Funktion als Client in einer Liste/Datenbank nachsehen, welchen SMTP-Server mit welchen Logindaten er zu dieser Absenderadresse zu verwenden hat, um dieses Email erfolgreich weiterzuleiten.
An dieser Stelle ist eine Prüfung auf einen Login-User völlig sinnlos, denn der kann nicht mehr festgestellt werden. An dieser Stelle kann der Server nur mehr SMTP-Server und Logindaten zur Absenderadresse in Erfahrung bringen.
In dieser zweiten Ebene ist exim oder wohl auch postfix ein ganz normaler Client, so wie Thunderbird oder Evolution auch. Zumindest dem empfangenden SMTP-Server gegenüber.

Und nochmal zu den "Usern" und "Absenderadressen"...
Ob exim oder postfix die Usernamen und Passwörter aus einer eigenen Datenbank bezieht, oder die vom Client gelieferten nur an dovecot weiterleitet und ein ok oder nicht ok zurückbekommt ist völlig unerheblich. Ob die Usernamen real existierende Unix-User am Mailserver sind, oder nur in einem Textfile in /etc/exim4/ hinterlegt sind, ist auch unerheblich.
Fakt ist, dass es einen Usernamen mit einem Passwort gibt, der sich bei exim zu auszuweisen hat, sonst stellt exim gar keine SMTP-Session her.
In dieser SMTP-Session (erste Ebene) gibt es einen authentifizierten Usernamen. Der ist in exim in der Variable $authenticated_id für diese Session abgelegt und kann jederzeit abgefragt werden. So auch in einer ACL (Access Control List) in der Stufe wo in der SMTP-Session der From-Header abgeliefert wird.
An dieser Stelle hat der Server eine From-Adresse und einen authentifizierten Usernamen dieser Session.

Dann muss ich den Server bei exim mittels ACL leiten in einer Datenbank (das kann auch ein Textfile sein) nachzuschlagen, ob er diese Absenderadresse überhaupt hat.
Hat er die Absenderadresse, dann muss er nachschlagen ob der authentifizierte Username diese Absenderadresse verwenden darf. Wenn ja, weiter im Prozess. Wenn nein hat er die Session für dieses Mail mit einer Fehlermeldung zu beenden und das Mail zurückzuweisen.

Ob exim jetzt in einer MYSQL-Datenbank nachschlägt, ob der User existiert und das richtige Passwort gesendet hat, oder in einem Textfile oder ob er dovecot diese Arbeit erledigen lässt und ob das ein Unix-User mit lokalem Konto ist oder ein virtueller User nur aus einer Datenbank, ist für exim völlig unerheblich. Ich erklär das jetzt deswegen zum wiederholten Male so ausführlich, weil ich beim Lesen deiner Antworten das Gefühl nicht loswerde, dass du dich so sehr an lokalen Unix-Usern aufhängst, die du nicht hast und nicht willst...
Und ich werd auch das Gefühl nicht los, dass du in deinen Ausführungen immer wieder zwischen Usern am Mailserver und Usern am Clientrechner und Email-Adressen hin und her springst und diese vermischt und dann wieder trennst... Mir kommts halt so vor.

Und du schreibst auch, dass das SMTPD-PWD in Thunderbird keine Bedeutung gehabt hätte...
Das glaube ich so nicht. Du hast wohl deinen SMTP-Server so konfiguriert, dass er sowohl authentifizierte wie auch nicht authentifizierte SMTP-Sitzungen zulässt. Je nachdem was der Client anfordert.
Exim muss man so konfigurieren, dass er auf Port 587 ausschließlich authentifizierte Sitzungen in einer TLS-gesicherten Verbindung erzwingt. Nicht-authentifizierte darf er gar nicht erst anbieten.
Port 25 ist wieder anders konfiguriert. Auf Port 25 müssen auch nicht-authentifizierte Verbindungen möglich sein. Sonst könnte apt oder ein anderer Prozess niemals ein Email an den Administrator senden. Aber Port 25 sollte dann nur auf lo (127.0.0.1) lauschen und niemals auf einem anderen Netwerk-Interface.
Und wenn du den Mailserver anderen anbietest, dann kannst du diese auch dazu "zwingen" ausschließlich Port 587 mit TLS-Verbindungssicherheit und LOGIN-Authentifizierung zu verwenden. Port 25 wird nämlich gar nicht erreichbar sein... hoffentlich. :)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: exim4 und acl

Beitrag von TomL » 07.05.2017 23:39:05

scientific hat geschrieben:Auf localhost (also 127.0.0.1 oder ::1) muss wohl auf Port 25 ein Abliefern von Emails ohne Authentifikation möglich sein, sonst kann niemals ein Daemon ein Email an root oder den Admin-User senden.
Ja, isses auch, localhost ist erlaubt.... trotz ansonsten erzwungener Anmeldung mit Anmeldenamen und Pwd.
der eigene SMTP-Server in seiner Funktion als Server in der ersten Ebene erzwingt eine Authentifizierung mit Username und Passwort von Thunderbird, openssl oder mail..
Solange Du nicht auf der niedrigen Ebene eines TCP/IP-Connects via OpenSSL bestätigst, dass es auch wirklich so ist, verlässt Du Dich auf erfülltes Wunschdenken. Du kannst einstellen was Du willst, wenn Du die Wirksamkeit bei einem direkten Connect (ohne Frontend) nicht bestätigst, bleibts ein Glückspiel... vielleicht ist es sicher... vielleicht auch nicht.... Reden bringt keine Sicherheit, nur eine konkrete Prüfung. Angefangen ohne Sicherheitsfeatures, dann schrittweise aufgebaut und jede Ebene separat kontrolliert.
Kann sich dieser Client authentifizieren, (dann setzt exim4 die Variable $authenticated_ID) nimmt er in Folge für diesen authentifizierten User Emails entgegen und wirft sie in die Queue.
Tja, ohne konkrete Prüfung bleibts reine Theorie.
Habe ich alle Ports so konfiguriert, dass sie TLS verlangen und ein Login erzwingen, oder kann ich mich auch per telnet ohne Authentifizierung ein Mail versenden?
Wenn TLS erzwungen ist., ist Telnet nicht möglich, aber OpenSSL. Probiers einfach im Terminal, ob auch eine OpenSSL-Anmeldung ohne Login möglich ist, dann weisst Du es genau.
Und ich werd auch das Gefühl nicht los, dass du in deinen Ausführungen immer wieder zwischen Usern am Mailserver und Usern am Clientrechner und Email-Adressen hin und her springst und diese vermischt und dann wieder trennst... Mir kommts halt so vor.
Ja, weil Du nicht zuhörst *lol* Ich habe das schon mehrfach gesagt, der lokal am Client angemeldete Linux-User, Windows-User oder obskure Default-Android-User hat für diese Baustelle absolut nichts mit den auf dem Server vorhandenen Linux-Usern zu tun, und noch weniger mit den Mailserver-Anmeldenamen/Pwd.... und absolut nichts von den obligatorischen Betriebsystem-Usern wird benötigt. Das Mailserver-Geschäft ist komplett und ausschließlich über Anmeldenamen (virtuelle User, bei mir ist es die lokale Email-Adresse) und ein eigenes Mail-Password geregelt. Du brauchst da nicht immer was reindeuten, was es nicht gibt.
Und du schreibst auch, dass das SMTPD-PWD in Thunderbird keine Bedeutung gehabt hätte...
Noch mal... mach einfach die Gegenprobe mit OpenSSL... solange das nicht bestätigt ist, ist alles nur Theorie und Wunschdenken und wenn Du Pech hast, liegt - wie heisst es so schön?- einfach nur opportunistic behavior vor....
Das glaube ich so nicht. Du hast wohl deinen SMTP-Server so konfiguriert, dass er sowohl authentifizierte wie auch nicht authentifizierte SMTP-Sitzungen zulässt. Je nachdem was der Client anfordert.
Nein, ich hatte den Server auf eigene Netze und eine Liste berechtigter Email-Adressen konfiguriert. Jetzt weiss ich aber, dass das Mist ist. Damit war auch eine Verbindung ohne Auth möglich. Jetzt habe ich das auf erzwungene Authentifizierung mit Anmelde-Name (bei mir die lokale Mailadresse) und Password eingestellt. Der Login mit Anmelde-Name und Password ist Zwang.

Man muss das jetzt auch nicht mehr weiter ausrollen....es ist ja alles gesagt.... weiteres Palavern ist dann nur noch Pudding an die Wand nageln. Wenn Du sicher bist, dass alles so ist, wie es sein soll, dann ist alles gut. Ich jedenfalls bin mir jetzt sicher... weil ich das wirklich sehr gründlich außerhalb der Anwndungssoftware kontrolliert habe. Und die Anwendungssoftware kann sich nicht mehr Rechte angeln oder mit Automatismen Secure-Einstellungen umschiffen, als ich auf niedrigstem Level festgestellt habt.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: exim4 und acl

Beitrag von scientific » 08.05.2017 06:38:01

TomL hat geschrieben:
scientific hat geschrieben:Auf localhost (also 127.0.0.1 oder ::1) muss wohl auf Port 25 ein Abliefern von Emails ohne Authentifikation möglich sein, sonst kann niemals ein Daemon ein Email an root oder den Admin-User senden.
Ja, isses auch, localhost ist erlaubt.... trotz ansonsten erzwungener Anmeldung mit Anmeldenamen und Pwd.
Das geht noch zu wenig weit. Welche Ports auf localhost?
TomL hat geschrieben:
der eigene SMTP-Server in seiner Funktion als Server in der ersten Ebene erzwingt eine Authentifizierung mit Username und Passwort von Thunderbird, openssl oder mail..
Solange Du nicht auf der niedrigen Ebene eines TCP/IP-Connects via OpenSSL bestätigst, dass es auch wirklich so ist, verlässt Du Dich auf erfülltes Wunschdenken. Du kannst einstellen was Du willst, wenn Du die Wirksamkeit bei einem direkten Connect (ohne Frontend) nicht bestätigst, bleibts ein Glückspiel... vielleicht ist es sicher... vielleicht auch nicht.... Reden bringt keine Sicherheit, nur eine konkrete Prüfung. Angefangen ohne Sicherheitsfeatures, dann schrittweise aufgebaut und jede Ebene separat kontrolliert.
Natürlich muss man das testen, was man konfiguriert hat.
Aber du musst auch unterscheiden, in welcher Rolle der Mailserver gerade arbeitet. Liefert der Client ein Mail bei "meinem" exim ab, ist exim in der Rolle eines Servers.
Liefert exim beim Smarthost ab, ist exim ein Client.

Ist der Smarthost so konfiguriert, dass Hinz und Kunz dort jeden Mist abliefern können ohne zu sagen wer sie sind, ist das nicht meine Verantwortung (außer dass ich dort ein Emailkonto habe...). Wer ein Mail wie bei meinem exim abliefert kann, definiere ich selbst (und teste es natürlich)
TomL hat geschrieben:
Kann sich dieser Client authentifizieren, (dann setzt exim4 die Variable $authenticated_ID) nimmt er in Folge für diesen authentifizierten User Emails entgegen und wirft sie in die Queue.
Tja, ohne konkrete Prüfung bleibts reine Theorie.
Nein. Das hat jetzt weniger mit Prüfung zu tun, ob ich mit openssl oder telnet überhaupt ein Email abliefern kann, sondern mehr mit einem Studieren der Debug-Logs.
Ich liefere mit openssl oder Thunderbird ein Email und sehe im Log zu, was mein exim macht... Welche Router welche ACL, welche Transports werden wie abgearbeitet.

Und siehe da... $authenticated_id ist entweder der authentifizierte User, oder wenn ich von einer Shell am Mailserver abliefere, der Unixuse mit dem ich DORT eingeloggt bin, und wenn ichs von außerhalb und anonym mache(n kann), ist es leer...

Du hüpfst mir grad zu schnell. $authenticated_id ist eine von vielen Variablen, die exim während der Abarbeitung von Emails setzt und verwendet. Da gibt es Variablen die sich auf eine SMTP-Session beziehen und da gibt es Variablen die sich nur auf ein Email beziehen. $authenticated_id bezieht sich auf die Sesseion. Also vom login am Email-Server bis zum Beenden der Session. Wieviele Emails dazwischen gesendet werden, ist unerheblich. (Meist ist es eh nur eines. es können aber auch mehrere sein!!)
TomL hat geschrieben:
Habe ich alle Ports so konfiguriert, dass sie TLS verlangen und ein Login erzwingen, oder kann ich mich auch per telnet ohne Authentifizierung ein Mail versenden?
Wenn TLS erzwungen ist., ist Telnet nicht möglich, aber OpenSSL. Probiers einfach im Terminal, ob auch eine OpenSSL-Anmeldung ohne Login möglich ist, dann weisst Du es genau.
Eh.
TomL hat geschrieben:
Und ich werd auch das Gefühl nicht los, dass du in deinen Ausführungen immer wieder zwischen Usern am Mailserver und Usern am Clientrechner und Email-Adressen hin und her springst und diese vermischt und dann wieder trennst... Mir kommts halt so vor.
Ja, weil Du nicht zuhörst *lol* Ich habe das schon mehrfach gesagt, der lokal am Client angemeldete Linux-User, Windows-User oder obskure Default-Android-User hat für diese Baustelle absolut nichts mit den auf dem Server vorhandenen Linux-Usern zu tun, und noch weniger mit den Mailserver-Anmeldenamen/Pwd.... und absolut nichts von den obligatorischen Betriebsystem-Usern wird benötigt. Das Mailserver-Geschäft ist komplett und ausschließlich über Anmeldenamen (virtuelle User, bei mir ist es die lokale Email-Adresse) und ein eigenes Mail-Password geregelt. Du brauchst da nicht immer was reindeuten, was es nicht gibt.
Du unterstellst mir dauernd, ich würde den Usernamen und das Passwort, mit dem ich mich auf irgend einem Rechner anmelden kann um Thunderbird oder eine Shell mit telnet starten zu können in meine Überlegungen mit einbeziehen...

NEIN!

Am Mailserver, der ein Linuxrechner ist, kann ich lokale User konfigurieren. Mit adduser, homeverzeichnis erzeugen und allem Pipapo bishin zum ssh-Zugang. Wie auf jedem normalen Linux-Rechner eben.
Und diese normalen Unix-User am Mailserver sind in der Regel auch Email-Empfangsfähig. Die Emailadresse dafür lautet z.B. scientific@mailserver, wenn keine nähere fqdn definiert ist und mailserver (oder mailserver.local) im LAN erreichbar ist.
Um mit SMTP-Auth ein Email versenden zu können würde zu dieser Email-Adresse der Loginname für SMTP-Auth scientific sein und das Passwort jenes mit dem sich scientific auch per ssh am Mailserver einlogt.

Das ist eine Möglichkeit. Und wenn ich von lokalen Usern bisher gesprochen habe, habe ich mich IMMER auf diesen Unix-User am Mailserver bezogen. Die Clientrechner interessieren mich nicht. Und als Clientrechner bezeichne ich einen Linux-, Windows oder Android-Rechner auf dem irgend ein SMTP-fähiger Mailclient läuft, der sich dann mit dem Mailserver verbinden kann.

Und irgendwie beschleicht mich grad wieder das Gefühl, dass du jetzt überhaupt nicht auf die beiden Ebenen, die Rollen als Server und Client, die ich beschrieben habe, die exim (oder postfix) im Zuge des Sendens einer Email einnehmen muss, eingehst.
TomL hat geschrieben:
Und du schreibst auch, dass das SMTPD-PWD in Thunderbird keine Bedeutung gehabt hätte...
Noch mal... mach einfach die Gegenprobe mit OpenSSL... solange das nicht bestätigt ist, ist alles nur Theorie und Wunschdenken und wenn Du Pech hast, liegt - wie heisst es so schön?- einfach nur opportunistic behavior vor....
Wenn du das so siehst... Ich schrieb von den Möglichkeiten, wie du einen Mailserver konfigurieren kannst, nicht wie du es getan hast.
TomL hat geschrieben:
Das glaube ich so nicht. Du hast wohl deinen SMTP-Server so konfiguriert, dass er sowohl authentifizierte wie auch nicht authentifizierte SMTP-Sitzungen zulässt. Je nachdem was der Client anfordert.
Nein, ich hatte den Server auf eigene Netze und eine Liste berechtigter Email-Adressen konfiguriert. Jetzt weiss ich aber, dass das Mist ist. Damit war auch eine Verbindung ohne Auth möglich. Jetzt habe ich das auf erzwungene Authentifizierung mit Anmelde-Name (bei mir die lokale Mailadresse) und Password eingestellt. Der Login mit Anmelde-Name und Password ist Zwang.
Wie willst du einen Server auf eine berechtigte Email-Adresse konfigurieren und dann eine Verbindung ohne Authentifikation ermöglichen?
Damit beim SMTP-Server überhaupt eine Absende-Adresse ankommt, muss VORHER ein Authentifikationsvorgang stattgefunden haben (oder keiner konfiguriert sein).

Das SMTP-Protokoll läuft ja so ab, dass sich auf einer Schnittstellt (lo, eth0, wlan0) ein client meldet. Der Server sagt, ob er sich authentifizieren muss (oder nicht), und dann authentifiziert sich der Client. Ob der Anmeldename nun "Hudriwudir0815" oder "scientific" oder "toml@meintollermailserver.example" ist, hängt von der Datenbank ab, die exim (oder postfix) befragt, welche User sich mit welchem Passwort anmelden dürfen. Ist diese Datenbank /etc/passwd und /etc/shadow, dann ist es ein lokaler Unix-User (lokal=am Mailserver), ist es ein File oder eine mysql-Datenbank, kann es auch ein Username sein, der wie eine Emailadresse AUSSIEHT!!!

Schafft der Client das, meldet der Server OK zurück und ist bereit ein Email entgegenzunehmen.
Dann erst kommt da ein Absender und ein Empfänger und der Inhalt des Mails dran.

Ist das Mail gesendet, können in dieser Session weitere Emails versendet werden. Wieder Absender, Empfänger und Inhalt schicken.
Bei all diesen Emails in dieser einen Session die nur einmal am Anfang eine Authentifikation erfordert hat, gibt es diesen einen Usernamen, der sich authentifiziert hat.
Der Mailserver kann nun bei jeder einzelnen Email prüfen, ob dieser User die jeweils zur Email verwendete Absendeadresse überhaupt verwenden darf.
gmx prüft das nicht. Ich lasse es schon prüfen.

Am Ende wird die Sitzung beendet.

Soll erneut ein Email geschickt werden, muss eine neuerliche Authentifikation stattfinden.

Thunderbird beendet nach jedem Email die Session und muss sich erneut einloggen (Beim Versand!!!)
TomL hat geschrieben: Man muss das jetzt auch nicht mehr weiter ausrollen....es ist ja alles gesagt.... weiteres Palavern ist dann nur noch Pudding an die Wand nageln. Wenn Du sicher bist, dass alles so ist, wie es sein soll, dann ist alles gut. Ich jedenfalls bin mir jetzt sicher... weil ich das wirklich sehr gründlich außerhalb der Anwndungssoftware kontrolliert habe. Und die Anwendungssoftware kann sich nicht mehr Rechte angeln oder mit Automatismen Secure-Einstellungen umschiffen, als ich auf niedrigstem Level festgestellt habt.
Eine Prüfung der Einstellungen ist unumgänglich. Da bin ich voll bei dir.

Und eines muss ich dir auch sagen. Unsere Diskussionen sind durchaus geprägt von "du hörst nicht zu"... Aber beide Threads gaben mir den Anreiz, mich eingehender mit SMTP zu beschäftigen. Und ich hab das Gefühl, erstmalig das halbwegs zu begriffen zu haben, was da überhaupt abrennt. Ich habe noch genauer die Logs studiert um zu verstehen, wann ich wo in den Prozess eingreifen muss, um das zu erreichen, was ich will.
Die Konfiguration von exim ist in der Tat nicht einfach. Die Syntax alles andere als logisch.
Aber ich habs mittlerweile geschafft, in einem Debianpaket Konfigurationsschnipsel so zu bauen und an die richtigen Stellen einzubauen, dass es genügt das Paket zu installieren und in bloß durch das setzen von wenigen Variablen für die Konfig "meine" Erweiterungen zu aktivieren oder auch einfach wieder zu deaktivieren. Genauso wie Debian das exzessiv mit der exim-Konfiguration betreibt. Es fügt sich nahtlos ein. Kommentiere ich die Variable aus, ist das ursprüngliche Verhalten von Debians exim wieder vollkommen hergestellt.

Ich kann so zu Testzwecken (und auch auf Testrechnern) prüfen, ob die Installation und Konfiguration in der Tat so einfach ist, wie ich es mir vorgestellt habe. :)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: exim4 und acl

Beitrag von TomL » 08.05.2017 10:30:20

scientific hat geschrieben:Nein. Das hat jetzt weniger mit Prüfung zu tun, ob ich mit openssl oder telnet überhaupt ein Email abliefern kann, sondern mehr mit einem Studieren der Debug-Logs. Ich liefere mit openssl oder Thunderbird ein Email und sehe im Log zu, was mein exim macht..Welche Router welche ACL, welche Transports werden wie abgearbeitet.
Wir haben halt unterschiedliche Anforderungen... mich interessieren Logs aus dieser Hinsicht überhaupt nicht. Ich will bei unauthorisierter Verwendung einfach nur ein "denied" als Reaktion des Serves, und wenn das kommt, ist für mich alles ok. Und der Datenweg bei authorisierter Verwendung -oder was Postfix macht- ist mir völlig egal.
Du unterstellst mir dauernd, ich würde den Usernamen und das Passwort, mit dem ich mich auf irgend einem Rechner anmelden kann um Thunderbird oder eine Shell mit telnet starten zu können in meine Überlegungen mit einbeziehen...
Um mit SMTP-Auth ein Email versenden zu können würde zu dieser Email-Adresse der Loginname für SMTP-Auth scientific sein und das Passwort jenes mit dem sich scientific auch per ssh am Mailserver einlogt.
Erkennst Du den Widerspruch in diesen beiden Absätzen... ?... bei Dir ist der Mailuser auch der Linuxuser, der sich per SSH anmelden kann. Das ist ein absolutes NoGo für mich.... egal... abhaken...bei mir ist Mailserver-User != Linuxserver-User. Ein Mailserver-User kann niemals ein Homedir haben, geschweige denn einen SSH-Zugriff erlaubt haben.... selbst dann nicht, wenn die Mailuser als Menschen die gleichen sind, die sich via Samba anmelden. Systemisch betrachtet sind auf meinem Server Mailuser eine eigene völlig rechtelose "Gattung".
Und irgendwie beschleicht mich grad wieder das Gefühl, dass du jetzt überhaupt nicht auf die beiden Ebenen, die Rollen als Server und Client, die ich beschrieben habe, die exim (oder postfix) im Zuge des Sendens einer Email einnehmen muss, eingehst.
Ja, weil das so banal und selbstverständlich ist, dass man das überhaupt nicht weiter erörtern muss.... und mal wieder, weil Du wieder nicht aufmerksam liest oder zuhörst. Du brauchst bloß auf meine Strichgrafik etwas höher zu sehen, dann siehst Du, dass ich die unterschiedlichen Rollen sehr wohl jetzt (!) unterscheide. Vorher allerdings nicht, da fehlte der SMTPD-Auth.

Mir bringts jetzt nichts mehr... ich klinke mich jetzt hier aus... ich bedanke mich auf jeden Fall bei Dir, denn ohne dieses Auseinandersetzen mit der Materie und das ich mich mit Deinen Argumenten beschäftigt habe, hätte ich nicht so viel darüber gelernt. Und niemals hätte ich ohne diese Diskussionen formulieren können, was ich überhaupt will. Jetzt weiss ich das alles und kanns auch umsetzen. Danke!

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: exim4 und acl

Beitrag von scientific » 08.05.2017 11:03:14

TomL hat geschrieben:
scientific hat geschrieben:Nein. Das hat jetzt weniger mit Prüfung zu tun, ob ich mit openssl oder telnet überhaupt ein Email abliefern kann, sondern mehr mit einem Studieren der Debug-Logs. Ich liefere mit openssl oder Thunderbird ein Email und sehe im Log zu, was mein exim macht..Welche Router welche ACL, welche Transports werden wie abgearbeitet.
Wir haben halt unterschiedliche Anforderungen... mich interessieren Logs aus dieser Hinsicht überhaupt nicht. Ich will bei unauthorisierter Verwendung einfach nur ein "denied" als Reaktion des Serves, und wenn das kommt, ist für mich alles ok. Und der Datenweg bei authorisierter Verwendung -oder was Postfix macht- ist mir völlig egal.
Wenn ich einen Server konfiguriere, dann interessieren mir die Logs sehr wohl. Und vor allem die Debug-Logs. Ich will ja wissen, was genau mein Server da macht, wenn ich in der Konfiguration etwas ändere/hinzufüge. Und vor allem, warum da jetzt ein deny oder ein accept kommt...
TomL hat geschrieben:
Du unterstellst mir dauernd, ich würde den Usernamen und das Passwort, mit dem ich mich auf irgend einem Rechner anmelden kann um Thunderbird oder eine Shell mit telnet starten zu können in meine Überlegungen mit einbeziehen...
Um mit SMTP-Auth ein Email versenden zu können würde zu dieser Email-Adresse der Loginname für SMTP-Auth scientific sein und das Passwort jenes mit dem sich scientific auch per ssh am Mailserver einlogt.
Erkennst Du den Widerspruch in diesen beiden Absätzen... ?... bei Dir ist der Mailuser auch der Linuxuser, der sich per SSH anmelden kann. Das ist ein absolutes NoGo für mich.... egal... abhaken...bei mir ist Mailserver-User != Linuxserver-User.
Das stimmt doch nicht... Ich hab die Konfiguration mal so, mal anders gefahren. Ich schreibe nur von der Möglichkeit, woher die Information kommt, wer auf dieser Maschine ein Email empfangen darf resp. kann, und wer nicht.

Aber egal... du hast dich jetzt eh ausgeklinkt, und ich hab jetzt offenbar eine Konfiguration hinbekommen, wo es nach meinen Wünschen funktioniert.
Ich muss noch genauer testen, dann setze ich auch den Thread auf gelöst.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

[SOLVED]Re: exim4 und acl

Beitrag von scientific » 08.05.2017 13:40:15

Ich habe jetzt eine Lösung gefunden, die zu funktionieren scheint. Intensivere Tests folgen noch:

Kurze Zusammenfassung:
Bei einer Authentifizierten SMTP-Sitzung wird die Absenderadresse nicht mehr geprüft. TomL hat das mit verschiedenen großen und bekannten Email-Providern auch getestet.
Ich kann mich also bei einem SMTP-Server authentifizieren und dann jede x-beliebige Absenderadresse im Envelope-From-Header eintragen. Das ist zwar kein Sicherheitsproblem, aber es kann schön missbraucht werden um Emails in anderer Namen zu versenden.

Ich habe ein Mailserver-Setup, welches von mehreren Email-Konten bei verschiedenen ISP die Emails einsammelt und pro User in eine Mailbox liefert. Dort sortiert ein Dovecot-IMAP-Server mittels Sievefilter die Emails auf Userwunsch in verschiedene IMAP-Unterordner des einzelnen Users.

Umgekehrt soll es mein Setup ermöglichen, zentral eine Datenbank zu haben, wo verschiedenen Absenderadressen zugehörige SMTP-Server mit entsprechenden Authentifizierungs-Credentials hinterlegt sind. Zusätzlich soll es für jede mögliche Absenderadresse erlaubte smtp-user geben, die diese Email-Adresse verwenden dürfen.
Wenn ein anderer SMTP-User eine dieser Adressen als Envelope-From verwendet, soll die Annahme des Emails verweigert werden. Es soll also nicht wie bei gmx möglich sein, nachdem sich ein SMTP-User authentifiziert hat, dass dieser einen x-beliebigen Absender im Envelope-From-Header verwendet, sondern nur klar definierte "ihm gehörende".

Die Auswahl des Smarthosts samt credentials zur Absenderadresse funktionierte bereits. Das Problem war "nur" Emails abzuweisen die ein authentifizierter SMTP-User mit einer "falschen" Absenderadresse "MAIL FROM:..." geschickt hat.

Dazu ein paar Voraussetzungen:
exim lauscht auf localhost:25 und nimmt Emails auch ohne Authentifizierung entgegen. Sonst können Daemons keine Benachrichtigungen mehr versenden.
exim lauscht auf localhost und an den Netzwerkinterfaces auf Port 587.
Auf diesem Port wird eine TLS-gesicherte Verbindung und SMTP-AUTH zwingend verlangt.
Port 25 nach "außen" wird nicht belauscht.
Der veraltete Port 465 wird nicht bedient.

Code: Alles auswählen

MAIN_LOCAL_INTERFACES = 127.0.0.1.25 : 0.0.0.0.587
TLS wird aktiviert:

Code: Alles auswählen

MAIN_TLS_ENABLE = yes
Die entsprechenden Zertifikate müssen lt. Anleitungen natürlich dazu auch erstellt werden. Ist nicht Thema jetzt.

Die Lösung hier zeigt nur auf, wie die ACL gestaltet werden muss:
Ich habe dazu eine Config-Datei /etc/exim4/conf.d/main/002_localmacros_multiaccount mit folgendem Inhalt angelegt:

Code: Alles auswählen

# Use Multiaccount-Routers and transports, set MULTIACCOUNT
MULTIACCOUNT = true

.ifdef MULTIACCOUNT
# If MULTIACCOUNT is definded, set MAIN_ACL_CHECK_MAIL to use a special ACL for
# Connections on ports other than 25

MAIN_ACL_CHECK_MAIL = ${if ={25}{$interface_port} \
                     {acl_check_mail} {acl_check_mail_multiaccount} }
.endif
Diese besagt: Wenn eine Connection auf Port 25 eingeht, dann verwende die standardmäßig vorhandene ACL "acl_check_mail". Auf allen anderen Ports verwende "acl_check_mail_multiaccount", die so aussieht und manuell erstellt wird:

Code: Alles auswählen

# conf.d/acl/30_exim-config_check_mail_multiaccount
########################################################################
##  ACL for use with Multiaccounts on Multiple Smarthosts             ##
##  ACL reject Emails with not allowed from for $authenticated_id     ##
########################################################################
acl_check_mail_multiaccount:

  deny
    condition = ${if eq {$interface_port}{587}{true}}
    !encrypted = *
    message = Encrypted Connection required on $interface_port

  deny
    !authenticated = *
    message = Authentication requires before MAIL command on port $interface_port


  deny
    message = User $authenticated_id is not in allowed to send with $sender_address as from-envelope
    !condition = ${if forany{<, ${extract{1}{:}{${lookup{$sender_address}wildlsearch{CONFDIR/client.multismarthost_multiaccount.passwd}{$value}fail}}}}\
                   {match{$item}{$authenticated_id}}{yes}{no}}

  accept

Die Datei CONFDIR/client.multismarthost_multiaccount.passwd hat folgendes Format:

Code: Alles auswählen

from.sender@email.tld:commaseparated,list,of,loginusers:smtp.server:portnumber(integer):user.name:verysecretpassword
Separator ist der ":"
Im zweiten Feld kommt dann eine kommaseparierte Liste aller Usernamen (SMTP-AUTH-Usernamen), welche die From-Adresse aus dem ersten Feld verwenden dürfen.
Das 3. Feld ist der SMTP-Server(Smarthost), und das 4. Feld der zu verwendende Port (momentan noch nicht in Verwendung) über den dieses Email mit dieser Absendeadresse versendet wird.

Nun zur ACL:
das erste "deny" prüft ob die Verbindung auf Port 587 stattfindet und ob die Verbindung verschlüsselt ist. Wenn nein, wird das Email abgewiesen und eine Fehlermeldung dass eine verschlüsselte Verbindung notwendig ist ausgegeben.

Das zweite "deny" prüft, ob sich der User authentifiziert hat. Wenn nein, wird das Email abgewiesen und eine passende Fehlermeldung ausgegeben.

Das dritte deny prüft, ob der angemeldete User ($authenticated_id) die verwendete Absenderadresse verwenden darf.
Schlägt diese Prüfung fehl, gibts eine Fehlermeldung und das Email wird zurückgewiesen.
Wenn diese Prüfung ergibt, dass der User darf, geht das deny zum nächsten "acl-word" weiter.

accept wird erreicht, wenn keine der vorderen deny "anschlägt".

Das Email wird akzeptiert und in die Queue eingereiht.

Bei der Prüfung bekomme ich allerdings bei Openssl nach der Eingabe von RCPT TO:empfänger@isp.example folgende Fehlermeldung:

Code: Alles auswählen

RENEGOTIATING
139637096363200:error:140940F5:SSL routines:ssl3_read_bytes:unexpected record:../ssl/record/rec_layer_s3.c:1490:
Ich bin noch am weiterforschen. Denn ein paar Emails konnte ich so schon korrekt verschicken. Und bei unpassendem Usernamen oder nicht verschlüsselter Verbindung auf Port 587 oder ohne Authentifikation kommen die konfigurierten (in der ACL) Fehlermeldungen, so wie es sein soll.
Passen Absender und User zusammen, kommt nach dem "MAIL FROM:..." auch ein OK zurück.

lg scientific

PS: Die jeweils aktuelle Konfiguration ist unter https://github.com/xundeenergie/exim4-multiaccount zu finden.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [SOLVED] exim4 und acl

Beitrag von scientific » 09.05.2017 09:59:14

@TomL

Ich hab mittels openssl auf Port 587 sowohl gmail als auch gmx getestet.
Ich geb irgendeinen Absender beim Kommando MAIL FROM: an.
Gmail sendet das Mail. Ankommen tut es mit meiner gmail-Adresse im Envelope-From
Gmx verweigert die Annahme mit dem Hinweis, dass die Mailbox nicht existiert.

Also prüfen diese beiden Anbieter sehr wohl, bzw. führen ein rewrite aus.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten