[postfix-users] Erweiterte Konfiguration

[lst_hoe02 at kwsoft.de]

Zitat von Mathias Reineke <paperfeeder at googlemail.com>:

> Guten Tag werte Mailinglisten Benutzer,
>
> ich habe letztendlich zwei relativ einfache Fragen, diesen geht  
> allerdings eine recht lange Erklärung voraus, um die  
> Rahmenbedingungen erschöpfend zu erleutern. Also bitte ich vorab um  
> Entschuldigung für die leicht romanartigen Züge meines Beitrags
>
> Ich bin derzeit damit befasst ein kleines Mailsystem auf meiner  
> Ubuntu-Box einzurichten. Die Box ist im Web unter der beispielhaften  
> Domain "example.de", mit wechselnder IP, zu erreichen. Die erklärten  
> ziele sind dabei:
> 1. Bereitstellung eines IMAP-Postfachs für verschiedene Nutzer, z.B.  
> Füruser1 at example.de  (umgesetzt mit Dovecot)
> 2. Einsammeln der Mails aus verschiedenen Externen Postfächern pro  
> Benutzer (z.b. Von  
> user1myfirstidentity at web.de,mysecondidentity at googlemail.com;  
> umgesetzt mittels Dovecot PostLoginScript und getmail)
> 3. Versenden von Mails über die Externen Postfächer (z.B. User1 kann  
> über die Box als Absendermyfirstidentity at web.de  verwenden, was dazu  
> führt, dass die Mail über User1s Mailaccount bei Web.de geleitet  
> wird; umzusetzen mit Postfix)
> (4.) Versand von @example.de Mails an externe Accounts soll nicht  
> umgesetzt werden (z.b. Vonuser1 at example.de  anuser at de.postfix.org),  
> dazu fehlt mir mindestens eine statische IP
> 5. Erzwungene Verschlüsselung der Verbindungen eines Benutzers zum  
> den Komponenten des Mailsystems (dank verbreiteter Unterstützung von  
> TLS in allen Komponenten ein Leichtes)
>
> Das so beschriebene Setup ist natürlich problemfrei umzusetzen.  
> Jetzt folgt aber der schwierige Teil, nämlich die Randbedingungen zu  
> den oben genannten Zielen:
> 1.a) Asymmetrische Verschlüsselung (PGP) aller Mails im Postfach des  
> Benutzers
> 2.a) Pro Benutzer symmetrisch verschlüsselte Speicherung der  
> Zugangsdaten zu den Externen Postfächern bzw. SMTP Servern
> 3.a) siehe 2.a)
> 5.a) die von den Benutzern zum Mailsystem übertragenen Anmeldedaten  
> müssen in Klartext, oder mindestens in vorhersehbarer Form (bekannte  
> Digest-Methode) vorliegen
>
> Diese Randbedingungen sollen es den Administratoren (ich bin nicht  
> allein, und ich will auch nicht "aus Versehen" die Daten der Nutzer  
> sehen können) und vor allem eventuellen Einbrechern erschweren die  
> Mail- beziehungsweise Zugangsdaten der einzelnen Benutzer  
> einzusehen. Ich schreibe "erschweren", da am Ende ein super user  
> mindestens die Zugangsdaten lesen können wird, dazu aber in den  
> Prozess der Mailzustellung eingreifen muss. Mir ist kein Ansatz  
> eingefallen, die Daten meiner Benutzer noch stärker zu sichern,  
> leider.
>
> Randbedingung 1.a) wird von Dovecot mit pro Benutzer verwalteten PGP  
> Schlüsseln, beim einsortieren der Mails, umgesetzt werden  
> (Evaluierung steht noch aus, zu förderst muss das Relaying an  
> externe SMTP Server funktionieren).
>
> Randbedingung 2.a) basiert erneut auf Dovecot. Dovecot ermöglicht es  
> über Prefetch-Queries das Klartextpasswort der sich gerade  
> angemeldeten Benutzer kurz vorzuhalten und eine über die "Post Login  
> Script" Funktionalität ausgelöste Aktion auszuführen. Somit ist es  
> mir möglich, bei der Anmeldung eines Benutzers, seine mit seinem  
> Box-Passwort verschlüsselten Zugangsdaten zu den externen  
> Postfächern zu holen und zu entschlüsseln, und damit getmail zu  
> füttern. Getmail stellt dann die Mails der externen Postfächer dem  
> Benutzer zu (hier ist ein Ansatzpunkt für einen Einbrecher mit super  
> user Rechten, da dieser das Post Login Script manipulieren kann,  
> oder aber die Nutzerdaten aus dem getmail Prozess auszulesen  
> vermag). Das ganze ist transparent für den Benutzer und funktioniert  
> wunderbar (transparent in dem Sinne, dass der Benutzer eh erst  
> sieht, dass er neue Mails hat, wenn es sich anmeldet, und nicht  
> bemerkt [von einer k
>
> leine Verzögerung abgesehen], dass die Mails erst in diesem Moment  
> eingesammelt werden).
>
> Nun folgen die eigentliche Probleme.
>
> 3. Ist mit Postfix und dessen sender_based_relay_maps sowie  
> sender_restrictions pro Benutzer (ein Benutzer darf nur @example.de  
> und seine externen Adressen als Absender angeben) sehr schön  
> umzusetzen.
>
> Die Schwierigkeit liegt bei der Randbedingung 3.a).
> Ich benötige eine Möglichkeit, im Kontext des Sendens einer Mail  
> über Postfix an das Klartextpasswort des Benutzer heranzukommen, um  
> damit das Ergebnis des sender_based_relay Lookups zu modifizieren  
> (Entschlüsselung der gespeicherten Daten entsprechend 2.a)).
>
> Frage 1: Gibt es ist Postfix eine Möglichkeit das Ergebnis des  
> sender_based_relay Lookups mit dem Klartextpasswort aus der SMTP  
> Anmeldung zu vermischen?
>
> Beim sender_based_relay-ing ergibt sich, in meiner Installation, ein  
> weiteres Problem. Sollte der Postfix die Mail nicht sofort zum  
> Zielserver (beispielsweise dem SMTP vom Web.de) zustellen können,  
> wird er dies später erneut versuchen. Dazu benötigt er dann "später"  
> die Zugangsdaten des Benutzers zum externen Server, befindet sich  
> aber nicht mehr im Kontext der Anmeldung des Benutzers, und hat  
> somit auch nicht mehr dessen Klartextpasswort zur Verfügung. Der  
> Schlüssel, der für die Entschlüsselung der Zugangsdaten benötigt  
> wird, muss bis zum erfolgreichen Zustellen (oder zum letztendlichen  
> Aufgeben der Zustellung) der Mail vorgehalten werden. (Alternativ  
> könnte die Mail in diesem Moment abgelehnt werden.)
>
> Darum
> Frage 2: ist es möglich, Postfix spezielle Informationen in den  
> Envelope einer sich in der "ausgehenden" Queue befindlichen Mail zu  
> schreiben, und diese beim Zustellungsversuch zur Manipulation der  
> Relay-Lookups zu verwenden?
> Mit Envelope meine ich an dieser Stelle den Satz an  
> Verwaltungsdaten, den Postfix für die Zustellung einer Mail  
> verwendet, und der in keinem Fall jemals in einer Mail auftaucht,  
> weder bei erfolgreicher Zustellung noch bei Bounce noch bei  
> Benachrichtigung des Postmasters über unzustellbare Mails.
>
> (An dieser Stelle sei angemerkt, dass dann das Klartextpasswort des  
> Benutzers, oder besser eine Ableitung davon, temporär auf der  
> Festplatte gespeichert würde, was es einem Angreifer mit super user  
> Rechten ermöglichte, dies zu lesen.)
>
>
> Sind jemandem von Ihnen Ansätze bekannt, die zugrunde liegenden  
> Probleme von Frage 1 und Frage 2 zu lösen?
>
>
> Erneut muss ich mich entschuldigen, dass dieser Beitrag recht lang  
> ist, jedoch denke ich, dass dies durch die Komplexität des  
> entstehenden Systems bedingt ist. Ich hoffen meine Ausführungen  
> ermöglichen eine Einordnung und bestenfalls positive Beantwortung  
> meiner Fragen.
>
> Haben Sie vorab schon vielen Dank für die Beschäftigung mit meinen Fragen.
>
> Mit freundlichen Grüszen,
> Mathias Reineke

Hallo,

wahrscheinlich nicht die Antwort die Sie hören wollen aber meiner  
Meinung nach hat ein solches System zu viele Lücken um die Komplexität  
zu rechtfertigen.

- Die e-Mails liegen bei den Orginal Providern unverschlüsselt vor und  
werden von diesen unter Umständen auch ohne Transportsicherheit  
übertragen

- Die Zugangsdaten zu den eigentlichen Providern müssen als Klartext  
den Server passieren, das lässt sich nicht wirklich gegen internen  
Zugriff absichern

- Die Verschlüsselung auf dem Mailserver ist ganz nett, sichert aber  
eigentlich die (hoffentlich) sicherste Stelle zusätzlich ab

Der Aufwand wäre wahrscheinlich besser darin investiert die Benutzer  
in Ende-zu-Ende Verschlüsselung zu beraten und bei der Einrichtung zu  
helfen. Damit sind sämtliche Probleme bezüglich Server  
Sicherheit/Zugriff mit erledigt.

Gruß

Andreas

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 6144 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <http://de.postfix.org/pipermail/postfix-users/attachments/20130625/5d76f33f/attachment.bin>