Mailserverkonzept mit DMZ und LAN

dovecot
postfix
ldap
mailserver
mail

#1

Hey :slight_smile:
zur Zeit Arbeite ich an einem Mailserverkonzept unter Verwendung von UCS Modulen.

Die bisherige Konfiguration entspricht dem folgendem (ohne UCS):
Der SMTP (Postfix) in der DMZ versendet Mails und empf├Ąngt diese von externen Mailservern. Zudem leitet der SMTP die au├čen empfangenen Mails an den IMAP-/POP3-Server (Dovecot) im Server-LAN weiter, des Weiterem authentifiziert der SMTP die Benutzer via SASL am IMAP-/POP3-Server. Die Benutzer- & Domaindaten liegen in einer MySQL Datenbank welche ├╝ber ein selbst geschriebenes Webinterface administriert wird. Zu guter Letzt wird in der DMZ ein IMAP-/POP3-Relay betrieben, damit die Mails auch au├čerhalb des LANs zur Verf├╝gung stehen. Ein Webmailer ist ebenfalls auf dem IMAP-/POP3-Relayserver implementiert.

Nun soll eine neue L├Âsung mit UCS und LDAP geschaffen werden, wof├╝r ungf├Ąhr folgendes Konzept erstellt wurde.
UCS Server mit Mailserver-Application im Server-LAN welcher den eigentlichen Mailserver darstellt. Dazu ein Postfix (auf UCS-Basis?) welcher als SMTP-Relay dient, um Mails von extern zu empfangen zu k├Ânnen. Versendete Mails sollen ebenfalls ├╝ber das SMTP-Relay versandt werden (auch obwohl der Mailserver im Server-LAN es direkt k├Ânnte). Ebenfalls in der DMZ wird ein Server mit Horde Groupware eingerichtet, welcher den Webmailer ersetzen soll.
Mail Archiv, sowie SPAM- & Virenfilter lasse ich erstmal au├čen vor.

Meine erste Frage, da laut Beschreibung das Horde Groupware System mit den Clientger├Ąten (Evolution, Outlook, Mail, usw.) kommuniezieren kann, w├Ąre der Einsatz eines IMAP-/POP3-Relays ├╝berfl├╝ssig oder wird weiter ein Relayserver ben├Âtigt?

Ist eine SMTP-Relayl├Âsung unter UCS bereits verf├╝gbar oder muss oder ein (sauberer) Memberserver erstellt werden auf welchen Postfix manuel konfiguriert wird?

Und das Wichtigste, sieht UCS ├╝berhaupt eine solche aufgetrennte Konfiguration vor bzw. ist ein ein bestimmtes vorgehen gefordert?

Leider habe ich bisher keine entsprechenden Ans├Ątze finden k├Ânnen und hoffe, dass bereits jemand so eine bzw. eine ├Ąhnliche Konfiguration implementiert hat.

Mit freundlichen Gr├╝├čen


#2

Hallo @Crystallic,
ich baue gerade bei einem Kunden ein sehr ├Ąhnliches Setup mit UCS 4.3 auf:

  • Interner Mail Server (UCS Mail Server App) mit Horde
  • SMTP Relay in der DMZ

Der Interne Mail Server l├Ąuft inzwischen, verwendet aber noch den Mail Server unseres Web-Hosters als Relay. Der n├Ąchste Schritt ist das SMTP-Relay.
Das SMTP Relay in der DMZ w├╝rde ich aus Sicherheitsgr├╝nden immer dazwischen stellen.

Keine direkten Verbindungen von au├čen durch die DMZ nach innen!!!

Befinden sich die Clientger├Ąte im LAN oder Internet?

  • Wenn nur LAN: Ich w├╝rde Horde auch ins LAN stellen.
  • Wenn nur Internet/DMZ: ok
  • Wenn gemischt: Hier ist es eine Abw├Ągung, ob es das Risiko wert ist. W├Ąre es vertretbar einen Horde Intern und einen Extern zu betreiben? Sind dies unterschiedliche Benutzer-Gruppen oder die gleichen?

Mich besch├Ąftigt noch die folgende Frage. Aus Sicherheitsgr├╝nden bevorzuge ich Verbindungen ├╝ber die Firewall zwischen LAN und DMZ, die von innen nach au├čen aufgebaut werden. Daher w├╝rde ich es bevorzugen, wenn der interne Mail-Server die Mails regem├Ą├čig vom externen abruft, statt dass der externe sie via SMTP nach innen weiterleitet.
Gleichzeitig m├Âchte ich, dass der externe Mail-Server nichts ├╝ber die User wei├č. Es soll erst einmal alles f├╝r unsere Domain annehmen. Das sortieren und ggf. ablehnen soll der Interne machen.
Ist das praktikabel?

Viele Gr├╝├če,
J├Ârn


#3

Hey :slight_smile:

Sicherheit steht dei dem Projekt an erste Stelle, weshalb ├╝berhaupt so ein (aufw├Ąndig) aufgetrenntes System implementiert wird.

Clients sollen das Interface von innen und au├čen erreichen k├Ânnen, die meisten Clients werden ├╝ber das Internet eine Verbindung zum System aufbauen. Ein VPN extra f├╝r Mailing sprengt jedoch etwas den Rahmen. Daher die Planung den Horde in die DMZ zu stecken.
Welchen Sicherheitsvorteil soll es haben zwei Horde einzusetzen? Wenn nun einer im LAN und einer in der DMZ stehen w├╝rde, ist dies damit das gleiche Sicherheitsrisiko gegeben, wie nur ein Horde in der DMZ darstellen w├╝rde.

Dies unterst├╝tze ich so, jedoch

w├Ąre damit die Gefahr eines Openrelays oder anderer Spammingmethoden gegeben.


#4

Deswegen habe ich nach den Benutzergruppen gefragt. Falls das unterschiedliche sind k├Ânnte man die Daten noch getrennt halten. Wenn sich die Nutzergruppen intern und extern stark ├╝berlappen bringt es keinen Vorteil.

Vielleicht hilft hier ein Reverse-Proxy weiter. Der nimmt die HTTPS Anfragen in der DMZ entgegen und holt sich die eigentliche Seite dann vom internen Server. Hier k├Ânnte ├╝ber 2-Way-SSL die Sicherheit verbessert werden, so dass nicht jeder beliebige Client sich verbinden kann.
Es sei denn, dass genau das der Anwendungsfall ist.

Openrelay nicht, da ich den Mail-Server entsprechend zu konfigurieren w├╝rde nur f├╝r unsere Domain anzunehmen und Mails f├╝r den Versand von unserer Domain ausschlie├člich vom internen Server angenommen w├╝rden.

Spam an uns zustellen w├╝rde der Interne Mail-Server ├╝ber Spam-Filter unterbinden.

Ich m├Âchte vermeiden, das gesamte LDAP auf den Server in der DMZ zu speigeln, nur damit der Mail Server die User Mail-Adressen kennt. Wenn es da einen datensparsameren Weg gibt gerne.


#5

Hallo,

ab wann kann man von einer DMZ sprechen? Bereits wenn zum Beispiel der Master Server nur intern erreichbar ist und ein Member mit Maildienst und Sonstigem was auch ├Âffentlich erreichbar sein soll, ├Âffentlich ist? Wie kann am besten der Reverse Proxy umgesezt werden, sodass auch ActiveSync, SMTP, HTTP/S und IMAP etc mit ├╝bertragen werden?


#6

So ist es, die internen Clients werden zu sich 90% auch von extern einloggen, Mobil Devices (Notebooks, Smartphones, usw). Die externen Clients werden gr├Â├čteteils auch nur von au├čen eine Verbindung herstellen, jedoch mit nicht immer vorhersehbaren Endger├Ąten.

Von meiner Seite aus m├Âchte ich das SMTP-Relay nicht offen lassen. In anderen Anwendungsf├Ąllen ist es evt. sinnvoll ein solche Konfiguration einzusetzen, jedoch ist hier eine Authentifizierung pflicht, allerdings werde ich diese ├╝ber eine eigene Authentifizierungsmrthode pr├╝fen lassen. Entweder ├╝ber die interne Benutzerverwaltung oder mit Hilfe von MySQL bin mir da nocht nicht ganz sicher, aber denke es wird die letztere Methode werden.

Hier sprechen wir per├Ânlichen Geschm├Ąchern, welche Methode denn nun die bessere istÔÇŽ

Zur├╝ck zu meinen urspr├╝nglichen Fragen:
-Nutze ich besser ein autarkes Debian als SMTP-Relay oder sollte auf Grund der Verwaltbarkeit durch die Dom├Ąne ein UCS Member eingesetzt werden?
-Ben├Âtige ich neben dem Horde Groupware noch ein IMAP-/POP3-Relay f├╝r externe Verbindungen oder kann Horrde diese Aufgabe ├╝bernehmen? (laut Beschreinung vermiutge ich jaÔÇŽ)


#7

Folgendes Setup verstehe ich unter DMZ:

Internet <-Router-> DMZ <-Router/Firewall-> Internes LAN

Das nennt man einen Exposed Bastion Host


#8

Huhu,

Ich rate bei solchen Szenarien dazu, f├╝r die reinen Proxy-/Relayserver kein UCS sondern ein einfaches Debian oder Ubuntu zu verwenden. Hat mehrere Gr├╝nde:

Sicherheit. Eine DMZ betreibt man, um Angriffsfl├Ąche zu minimieren. Ein UCS-System ist aufgrund der vielen Komponenten, die in ihm laufen, eine ganze Stufe komplexer, als ein reines Debian- oder Ubuntu-System. Hinzu kommt, dass ein UCS-System auf verschiedenen Wegen (ssh, Directory Listener, falls Samba installiert ist dann auch damitÔÇŽ) mit seinem DC Master kommunizieren muss. Sprich f├╝r ein UCS-System in der DMZ m├╝ssen deutlich mehr Regeln f├╝r die Firewall erstellt werden, die zwischen der DMZ und dem Intranet vermittelt.

Komplexit├Ąt ist der nat├╝rliche Feind von Sicherheit.

Die Komplexit├Ąt kann es wert sein, wenn es klare Vorteile gibt, die diese rechtfertigen. Bei UCS-Systemen ist der prim├Ąre Vorteil, dass man die zentrale Benutzerverwaltung hat und dass man einfach Apps auf den Systemen installieren kann. Beides ist f├╝r ein Reverse-Proxy- & SMTP-Relaysystem aber komplett irrelevant. Ben├Âtigt man die Benutzerinformationen, so kann man einfach direkte LDAP-Suche gegen den DC Master implementieren, was firewalltechnisch viel einfacher zu handlen ist. Und f├╝r SMTP-Relay ben├Âtigt man diese Informationen noch nicht einmal (mehr dazu unten).

Weiterhin: Konfigurationskomplexit├Ąt. Bei einem Reverse-Proxy-/SMTP-Relay-System m├Âchte man ausschlie├člich diese Funktionalit├Ąt haben, nicht aber z.B. die Univention Management Console. Man muss also bei einem UCS in der DMZ erst mal gegen die Standardkonfiguration ank├Ąmpfen, um mitgelieferte Sachen auszuschalten. Weiterhin muss man dagegen ank├Ąmpfen, dass UCS die Konfigurationen der Dienste ├╝ber Templates managet. Will man bei Postfix aber pl├Âtzlich Sachen anpassen, die die Templates so nicht vorsehen, so muss man die Templates selber anpassen, was man wiederum bei Updates beachten muss.

Also noch mehr Komplexit├Ąt, die man sich mit einem reinen Debian/Ubuntu erspart.

Trivial. Man muss nur Postfix bekannt geben, welche Dom├Ąnen er weiterleiten soll (├╝ber Parameter relay_domains), wohin er diese schicken soll (├╝ber einen Eintrag in einer transport_maps), und dass er unbekannte Empf├Ąnger ablehnt (siehe Address Verification, Option reject_unverified_recipient f├╝r Parameter smtpd_recipient_restrictions).

Was Postfix dann macht, ist:

  1. Einliefernder Client meldet sich, sagt, von wem und an wen die Mail gehen soll.
  2. Postfix h├Ąlt die Verbindung und baut im Hintergrund eine Verbindung zum internen Mailserver auf.
  3. Postfix sagt dem internen Mailserver das, was er in Schritt 1 erfahren hat.
  4. Interner Mailserver sagt, ob er den Empf├Ąnger akzeptiert oder nicht.
  5. Postfix bedankt sich, baut die Verbindung zum internen Mailserver ab.
  6. Anhand des Resultats aus 4. nimmt Postfix die Mail vom externen Client an oder lehnt sie ab.

Postfix in der DMZ braucht nicht mal Zugriff aufs LDAP.

Man kann als Letztes noch daf├╝r sorgen, dass das DMZ-Postfix Mails aus dem LAN ebenfalls akzeptiert und z.B. nach extern weiterleitet. Das geht trivial ├╝ber den Parameter mynetworks.

Bitte nicht. Das bringt kein Mehr an Sicherheit und statt dessen einen Haufen unsch├Âner Mailprobleme.

Variante 1: man nimmt ein Catch-All-Postfach, das man per POP3 abholt. Hier ist ein Problem, dass BCCs nicht als regul├Ąre Mail-Header auftauchen, und der abholende Client (fetchmail) daher diese Information des urspr├╝nglichen Empf├Ąngers nicht mehr zur Verf├╝gung hat. Viele Mail-Provider schreiben daher gl├╝cklicherweise einen zus├Ątzlichen Header wie z.B. X-Orignal-To oder X-Envelope-To mit in die Mail, der den urspr├╝nglichen Empf├Ąnger enth├Ąlt. Man kann dann fetchmail dazu konfigurieren, diesen Header zu nutzen, aber das ist in der initialen Einrichtung halt alles andere als trivial und eine h├Ąufige Quelle f├╝r Mailverlust oder Mailverdoppelung oder ungewollten Bounces, bis man es ordentlich hinbekommen hat.

Problem Nummer 2 sind unbekannte Empf├Ąnger. Hat man ein Catch-All-Postfach, so wird providerseitig nicht ├╝berpr├╝ft, ob es den Empf├Ąnger in der Dom├Ąne wirklich gibt. fetchmail pr├╝ft das auch nicht, sondern leitet die Mail nur an den lokalen Postfix weiter. Der merkt erst: oh, den Empf├Ąnger gibtÔÇÖs nicht, also bounce ich die Mail. Und schon hat man ein anderes Problem: man versendet pl├Âtzlich Bounces an die vermeintlichen Absender. Vermeintlich deshalb, weil Absenderadressen ja beliebig gef├Ąlscht sein k├Ânnen. Und genau diese Technik (gef├Ąlschter Absender, bewusst nicht existierender Empf├Ąnger, und Zielmailserver schickt dann eine Bounce an den gef├Ąlschten Absender) wird oftmals von Spammern benutzt (hei├čt ┬╗backscatter┬ź), was wiederum die Gefahr erh├Âht, dass der eigene Mailserver auf Spam-Blacklisten landet.

Kurz: bei Catch-All-Postf├Ąchern wird die Situation ┬╗Empf├Ąnger existiert nicht┬ź pl├Âtzlich zu meinem Problem, und nicht zum Problem des Absenders.

M├Âchte man providerseitig beides nun umgehen, so kann man auf ein Catch-All-Postfach verzichten und statt dessen f├╝r jeden Empf├Ąnger ein eigenes Postfach einrichten, dazu auch f├╝r jedes Postfach einen Eintrag in der fetchmail-Konfiguration vornehmen, und dann sieht man seine Benutzerliste mit 40 Leuten und geht erst mal einen trinken. Auch keine L├Âsung.

Letzter offensichtlicher Nachteil von Abholung vs. direkter Zustellung: Verz├Âgerung. Ja, Mail ist ein asynchrones Medium, aber durch die Intervalle, in denen Mails abgeholt werden, kommt noch mal mehr Verz├Âgerung hinzu. Der Kunde ist gerade am Telefon und sagt ┬╗ich schicke Ihnen das gerade r├╝ber┬ź, und Sie sagen dannÔÇŽ ┬╗ja cool, wir warten jetzt zehn Minuten, bis unsere Mails wieder abgeholt wurden┬ź?

Sag ┬╗Nein!┬ź zu Abholung per POP3/IMAP.

Das ist das Szenario, das ich oben beschrieben habe; der regul├Ąre Callout-Verifikations-Mechanismus von Postfix.

All das ist kein offenes Relay. Selbst in der Standardkonfiguration ist Postfix kein offenes Relay. Man muss Postfix schon explizit ├╝ber so etwas wie permit in smtpd_ÔÇŽrestrictions dazu konfigurieren, ein offenes Relay zu sein.

Und wenn man w├Ąhrend der Implementation Zweifel hat, dann einfach mit dem Open Relay Test von MXToolBox pr├╝fen.

Gru├č
mosu


#9

@Moritz_Bunkus
Danke f├╝r deine ausf├╝hrliche Erkl├Ąrung. K├Ânntest du auch eine Empfehlung abgeben wie ein Setup bestenfalls auszusehen hat?

Ich w├╝rde jetzt ein Debian 9 mit Postfix als SMTP-Relay in DMZ und ein UCS Mailserver im Server-LAN konfigurieren.
Erste Frage, soll Postfix normal via LMTP an den UCS Mailserver zustellen?
Zweite Frage, soll den Postfix die Nutzer einzeln via LDAP authenfizieren oder nur den UCS Mailserver als sendeberechtigt eintragen und diesen lokal authentifizieren?

Damit sollte das Mailing f├╝r Clients innerhalb des lokalen Netzwerks voll funktionieren, jeztzt fehlt jedoch noch die Implementation des Horde Groupware.
Sollte dieser denn in der DMZ stehen? Dann w├Ąre ja trotzdem ein vollwertiges UCS system in der Dom├Ąne.
Wenn der Horde Groupware Server im Server-LAN plaziert wird, fehlt jedoch die Anbindung von extern.

Mit freundlichen Gr├╝├čen
Crystallic


#10

Huhu,

LMTP ist nur f├╝r lokalen Transport da, also von Postfix zu z.B. Kopano auf dem selben Server. Zwischen zwei Servern wird weiterhin SMTP benutzt.

Authentifizierung von Benutzern am Mailserver in der DMZ wird nur dann ben├Âtigt, wenn es m├Âglich sein soll, dass Benutzer von extern aus (z.B. wenn sie gerade im Hotel sitzen) Mails ├╝ber den Firmenmailserver verschicken k├Ânnen sollen. Dann muss dem Postfix in der DMZ SASL-Authentifizierung beigebracht kriegen. Diese sollte dann sinnvollerweise ├╝ber den saslauthd laufen, und dieser wiederum sollte gegen das LDAP des DC Masters authentifizieren.

Wird das nicht ben├Âtigt, so gen├╝gt es, im DMZ-Mailserver den internen Mailserver als sendeberechtigt einzutragen (die bereits erw├Ąhnten mynetworks). Dann m├╝ssen alle internen Clients den internen Mailserver als SMTP-Server eingetragen haben und nicht direkt den DMZ-Mailserver.

Eine echte Authentifizierung des internen Mailservers am DMZ-Mailserver (also Anmeldung mit Benutzernamen & Passwort) kann man zwar implementieren, halte ich aber f├╝r v├Âllig ├╝berfl├╝ssig. Mir f├Ąllt kein Szenario ein, in dem das einen echten Mehrgewinn an Sicherheit bieten w├╝rde.

HTTP(S)-Reverse-Proxy in der DMZ, entweder mit Apache oder nginx. Das Webinterface direkt in der DMZ aufzusetzen und nur IMAP in Richtung LAN durchzulassen, ist auch eine M├Âglichkeit, erfordert halt mehr Arbeit und bringt ein fragw├╝rdiges Mehr als Sicherheit.

Gru├č
mosu


#11

@Moritz_Bunkus

Danke f├╝r die schnelle Antwort :slight_smile: werde mich jetzt erstmal hinsetzen und die Informationen in Ruhe verarbeiten und das Konzept demantsprechend anpassen.
Melde mich anschlie├čend wieder

Danke und Gr├╝├če