16
LDAP Auth aus DMZ
Hi,
ich würde gern eine Webanwendung in der DMZ an einem LDAP Server (Univention) der im LAN steht authentifizieren.
Möglichkeit 1: RODC (soweit ich bietet Univention dafür eine entsprechende Rolle) in DMZ
Möglichkeit 2: OpenLDAP Proxy in DMZ
Was ist di gängige Lösung für dieses Szenario? Bei einem RODC liegen durch die Replitierung ein teil der Benutzerdaten in der DMZ oder? Fände ich nicht ganz so schön. Bei der Proxy Lösung würde das entfallen.
Für beide Lösungen müssen vermutlich Ports von der DMZ Richtung LAN geöffnet werden oder irre ich mich?
Vielen Dank schon mal für eure Hilfe.
Gruß,
Robert
ich würde gern eine Webanwendung in der DMZ an einem LDAP Server (Univention) der im LAN steht authentifizieren.
Möglichkeit 1: RODC (soweit ich bietet Univention dafür eine entsprechende Rolle) in DMZ
Möglichkeit 2: OpenLDAP Proxy in DMZ
Was ist di gängige Lösung für dieses Szenario? Bei einem RODC liegen durch die Replitierung ein teil der Benutzerdaten in der DMZ oder? Fände ich nicht ganz so schön. Bei der Proxy Lösung würde das entfallen.
Für beide Lösungen müssen vermutlich Ports von der DMZ Richtung LAN geöffnet werden oder irre ich mich?
Vielen Dank schon mal für eure Hilfe.
Gruß,
Robert
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 308346
Url: https://administrator.de/contentid/308346
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
16 Kommentare
Neuester Kommentar
Hi Robert,
da wie du richtig bemerkst dann eh Verbindungen aus der DMZ ins LAN zugelassen werden müssten wäre (falls dein Firewalladmin das erlaubt) die schnellste und mmn sauberste Lösung eine Firewallregel, die das Abfragen von Daten vom LDAP-Server für deinen Webserver erlaubt.
Auf diese Weise kannst du die Daten abfragen, musst sie nicht auf deinem Webserver speichern und bist trotzdem sicher, wenn die Firewallregel entsprechend restriktiv ist (also Verbindung nur zwischen LDAP und deinem Server über Port xyz erlauben).
LG Larmina
da wie du richtig bemerkst dann eh Verbindungen aus der DMZ ins LAN zugelassen werden müssten wäre (falls dein Firewalladmin das erlaubt) die schnellste und mmn sauberste Lösung eine Firewallregel, die das Abfragen von Daten vom LDAP-Server für deinen Webserver erlaubt.
Auf diese Weise kannst du die Daten abfragen, musst sie nicht auf deinem Webserver speichern und bist trotzdem sicher, wenn die Firewallregel entsprechend restriktiv ist (also Verbindung nur zwischen LDAP und deinem Server über Port xyz erlauben).
LG Larmina
Hi Larmina,
danke für deine Antwort. Aktuell geht es nur um einen Webserver. Sollten langfristig aber doch weitere Server hinzu kommen, hätte die Firewall gleich mehrere Löcher
Deshalb war die Idee einen Proxy in die DMZ zu stellen, und nur IP/PORT des Proxy Servers ins LAN zuzulassen. Dadurch würde die Lösung deutlich besser skalieren (hoffe ich zumindest) falls die Anzahl der Server in der DMZ doch mal steigt. Ich war mir nur nicht sicher ob das der "richtige" Ansatz ist, oder ob jemand eine bessere Idee hat.
Gruß,
Robert
danke für deine Antwort. Aktuell geht es nur um einen Webserver. Sollten langfristig aber doch weitere Server hinzu kommen, hätte die Firewall gleich mehrere Löcher
Deshalb war die Idee einen Proxy in die DMZ zu stellen, und nur IP/PORT des Proxy Servers ins LAN zuzulassen. Dadurch würde die Lösung deutlich besser skalieren (hoffe ich zumindest) falls die Anzahl der Server in der DMZ doch mal steigt. Ich war mir nur nicht sicher ob das der "richtige" Ansatz ist, oder ob jemand eine bessere Idee hat.Gruß,
Robert
Hi Robert,
es ist natürlich grundsätzlich keine schlechte Idee die "Löcher" in der Firewall zahlenmäßig möglichst gering zu halten, bei der Proxygeschichte würde ich aber dazu tendieren die entsprechenden Regeln in der Firewall zu schreiben.
Die Gründe sind wie folgt:
- Die Webserver sind in der DMZ ansprechbar, wenn man die Firewallregeln so einstellt, dass nur die Webserver zum LDAP dürfen und zurück ist das ähnlich sicher wie über den LDAP Proxy (also wirklich strikteste Regeln, nur von IP zu IP und über exakt den definierten Port, bei Erweiterung kannst du ja Problemlos eine weitere IP hinzufügen die mit dem LDAP kommunizieren darf)
- Der LDAP Proxy ist eine zusätzliche Fehlerquelle
- Der LDAP Proxy muss aufgesetzt und gewartet werden
- Der LDAP Proxy bräuchte ebenfalls restriktive Firewallregeln, so dass er von außerhalb der DMZ nicht ansprechbar ist
Die beiden letzten Punkte bedeuten mehr Arbeit für in meinen Augen (wenn man die Firewallregeln richtig, sprich restriktiv, macht) ähnliche Sicherheit.
Wie immer gilt natürlich: Webserver mit aktuellen Updates versorgt halten, Informieren ob es neue Sicherheitslücken gibt, gefährliche Dinge runterschmeißen oder garnicht erst drauf spielen (JRE, Flash, usw)
LG Larmina
es ist natürlich grundsätzlich keine schlechte Idee die "Löcher" in der Firewall zahlenmäßig möglichst gering zu halten, bei der Proxygeschichte würde ich aber dazu tendieren die entsprechenden Regeln in der Firewall zu schreiben.
Die Gründe sind wie folgt:
- Die Webserver sind in der DMZ ansprechbar, wenn man die Firewallregeln so einstellt, dass nur die Webserver zum LDAP dürfen und zurück ist das ähnlich sicher wie über den LDAP Proxy (also wirklich strikteste Regeln, nur von IP zu IP und über exakt den definierten Port, bei Erweiterung kannst du ja Problemlos eine weitere IP hinzufügen die mit dem LDAP kommunizieren darf)
- Der LDAP Proxy ist eine zusätzliche Fehlerquelle
- Der LDAP Proxy muss aufgesetzt und gewartet werden
- Der LDAP Proxy bräuchte ebenfalls restriktive Firewallregeln, so dass er von außerhalb der DMZ nicht ansprechbar ist
Die beiden letzten Punkte bedeuten mehr Arbeit für in meinen Augen (wenn man die Firewallregeln richtig, sprich restriktiv, macht) ähnliche Sicherheit.
Wie immer gilt natürlich: Webserver mit aktuellen Updates versorgt halten, Informieren ob es neue Sicherheitslücken gibt, gefährliche Dinge runterschmeißen oder garnicht erst drauf spielen (JRE, Flash, usw)
LG Larmina
Hi,
klingt alles einleuchtend Was passiert wenn eine Anwendung dazu kommt die auf einem root-Server im Internet läuft? Dann müsste ich den LDAP Port für diesen Server aus dem Internet öffnen... Wäre es da nicht geschickter wenn der Server aus dem Internet nur mit dem Proxy in der DMZ spricht und nicht mit dem Server im LAN?
Gruß,
Robert
klingt alles einleuchtend
Was passiert wenn eine Anwendung dazu kommt die auf einem root-Server im Internet läuft? Dann müsste ich den LDAP Port für diesen Server aus dem Internet öffnen... Wäre es da nicht geschickter wenn der Server aus dem Internet nur mit dem Proxy in der DMZ spricht und nicht mit dem Server im LAN?Gruß,
Robert
Hi Robert,
ich würde nie Daten die aus dem Internet kommen ungefiltert ins LAN lassen.
Selbst mit Proxy würde ich Daten von einem Server außerhalb der DMZ nicht annehmen.
Meine Herangehensweise hier wäre auf dem DMZ Webserver eine Authentifizierungsschnittstelle einzurichten.
Du kannst vom externen Server dann auf diese zugreifen, per POST Benutzername und Passwort übermitteln und dann dem externen Server true oder false übermitteln, ohne dass der irgendwelche Daten bekommt.
Wo ich das gerade schreibe, folgendes wäre vielleicht auch was:
- Ein (Web)server in der DMZ auf dem die Schnittstelle läuft (Bei mir wäre es mit PHP), und der nur true oder false zurück gibt. (Im weiteren Auth-Srv genannt).
##Wichtig: Immer zuerst die Variablen prüfen um Injections zu verhindern##
- Die Webserver in der DMZ dürfen nur auf den Auth-Srv zugreifen, und haben keine Verbindung ins LAN
- Der externe Server darf auf den Auth-Srv zugreifen
- Der Auth-Srv kommuniziert mit dem LDAP
Unterschied zu einem Proxy ist hierbei, dass die Daten nicht einfach weitergereicht werden, sondern der Auth-Srv nimmt die Daten an, prüft sie auf gefährliche Befehle (Scriptseitig), prüft sie gegen das LDAP und gibt dann true oder false zurück.
Das könnte man noch mit Accountsperrungen nach x falschen Versuchen oder ähnlichem kombinieren, je nachdem wie gut du bist mit der LDAP Schnittstelle.
Ich hoffe du verstehst worauf ich hinaus will, sonst versuche ich es nochmal umzuformulieren ;)
LG
Larmina
ich würde nie Daten die aus dem Internet kommen ungefiltert ins LAN lassen.
Selbst mit Proxy würde ich Daten von einem Server außerhalb der DMZ nicht annehmen.
Meine Herangehensweise hier wäre auf dem DMZ Webserver eine Authentifizierungsschnittstelle einzurichten.
Du kannst vom externen Server dann auf diese zugreifen, per POST Benutzername und Passwort übermitteln und dann dem externen Server true oder false übermitteln, ohne dass der irgendwelche Daten bekommt.
Wo ich das gerade schreibe, folgendes wäre vielleicht auch was:
- Ein (Web)server in der DMZ auf dem die Schnittstelle läuft (Bei mir wäre es mit PHP), und der nur true oder false zurück gibt. (Im weiteren Auth-Srv genannt).
##Wichtig: Immer zuerst die Variablen prüfen um Injections zu verhindern##
- Die Webserver in der DMZ dürfen nur auf den Auth-Srv zugreifen, und haben keine Verbindung ins LAN
- Der externe Server darf auf den Auth-Srv zugreifen
- Der Auth-Srv kommuniziert mit dem LDAP
Unterschied zu einem Proxy ist hierbei, dass die Daten nicht einfach weitergereicht werden, sondern der Auth-Srv nimmt die Daten an, prüft sie auf gefährliche Befehle (Scriptseitig), prüft sie gegen das LDAP und gibt dann true oder false zurück.
Das könnte man noch mit Accountsperrungen nach x falschen Versuchen oder ähnlichem kombinieren, je nachdem wie gut du bist mit der LDAP Schnittstelle.
Ich hoffe du verstehst worauf ich hinaus will, sonst versuche ich es nochmal umzuformulieren ;)
LG
Larmina
Prinzipiell verstehe ich worauf du hinaus willst Allerdings sind das nicht immer selbst geschrieben Webanwendungen die ich gegen den LDAP authentifizieren möchte. Dadurch ist es nicht so ohne weiteres möglich hier ein "PHP-Gateway" dazwischen zu schalten und dem Benutzername+Kennwort zu übergeben da die LDAP Schnittstellen der Webanwendungen meist fest definiert sind.
Ich wäre aber ehrlich gesagt davon ausgegangen, dass der OpenLDAP Proxy nur "gültige" Anfragen annimmt und nicht einfach blind alles was so auf Port XYZ ankommt an den LDAP im LAN weiterreicht...
Allerdings sind das nicht immer selbst geschrieben Webanwendungen die ich gegen den LDAP authentifizieren möchte. Dadurch ist es nicht so ohne weiteres möglich hier ein "PHP-Gateway" dazwischen zu schalten und dem Benutzername+Kennwort zu übergeben da die LDAP Schnittstellen der Webanwendungen meist fest definiert sind.Ich wäre aber ehrlich gesagt davon ausgegangen, dass der OpenLDAP Proxy nur "gültige" Anfragen annimmt und nicht einfach blind alles was so auf Port XYZ ankommt an den LDAP im LAN weiterreicht...
Zitat von @xoxyss:
Ich wäre aber ehrlich gesagt davon ausgegangen, dass der OpenLDAP Proxy nur "gültige" Anfragen annimmt und nicht einfach blind alles was so auf Port XYZ ankommt an den LDAP im LAN weiterreicht...
Ich wäre aber ehrlich gesagt davon ausgegangen, dass der OpenLDAP Proxy nur "gültige" Anfragen annimmt und nicht einfach blind alles was so auf Port XYZ ankommt an den LDAP im LAN weiterreicht...
Da bin ich mir nicht sicher, da ein Proxy grundsätzlich dafür da ist Anfragen anzunehmen, sich selbst als Anfrager einzusetzen, dann die Antwort entgegenzunehmen und die an den Originalanfragenden zurückzugeben.
Ob der OpenLDAP Proxy auch prüft und inwiefern die Fehlermeldungen verräterisch sind kann ich dir auswendig nicht sagen, auch eine kurze Googlesuche hierzu hat mich nicht nennenswert schlauer gemacht.
LG Larmina
Ich würde den Verzeichnisdienst im LAN nicht per LDAP aus der DMZ ansprechbar machen. Das wäre zu gefährlich, weil LDAP ist viel zu mächtig ist. Die Firewall hilft Dir da gar nichts. Besser wäre es, wenn die Webanwendung(en) per Radius mit dem Univertion-System kommunizieren würde(n).
Gruß
sk
Gruß
sk
HI,
danke für deine Antwort. Auch das ist leider nicht wirklich praktikabel auch wenn ich den Ansatz gut finde. Leider unterstützen sehr wenige Webanwendungen die Authentifizierung per Radius Server. Alle Anwendungen die ich mir angeschaut habe, besitzen eine Authentifizierungsschnittstelle für LDAP aber leider kein Radius. Oder gibts da andere Wege die ich nicht kenne?
Gruß,
Robert
danke für deine Antwort. Auch das ist leider nicht wirklich praktikabel auch wenn ich den Ansatz gut finde. Leider unterstützen sehr wenige Webanwendungen die Authentifizierung per Radius Server. Alle Anwendungen die ich mir angeschaut habe, besitzen eine Authentifizierungsschnittstelle für LDAP aber leider kein Radius. Oder gibts da andere Wege die ich nicht kenne?
Gruß,
Robert
Hi Dani,
danke für den Link. Dort steht:
Bedeutet für mich die AD Daten liegen als Replikation in der DMZ auch wenn nur mit leserechten. Hat der RODS oder der beherrbergende Server einen Bug und der Server wird kompromittiert können unter Umständen AD Daten abgegriffen werden. Daher war meine erste Idee einen Proxy zu benutzen der Anfragen (im Optimalfall validiert) an den Verzeichnisdienst im LAN weiterreicht. Oder habe ich in deinem verlinkten Artikel was über lesen?
Gruß,
Robert
danke für den Link. Dort steht:
Der RODC besitzt ein vollständiges Replikat der Active Directory-Datenbank (samt allen Objekten und Attributen)
Bedeutet für mich die AD Daten liegen als Replikation in der DMZ auch wenn nur mit leserechten. Hat der RODS oder der beherrbergende Server einen Bug und der Server wird kompromittiert können unter Umständen AD Daten abgegriffen werden. Daher war meine erste Idee einen Proxy zu benutzen der Anfragen (im Optimalfall validiert) an den Verzeichnisdienst im LAN weiterreicht. Oder habe ich in deinem verlinkten Artikel was über lesen?
Gruß,
Robert
Okay ich war etwas vorschnell Man kann relativ fein steuern was repliziert werden soll. Ich muss das ganze Thema nochmal durchdenken kann mir jemand vlt. kurz Vor- und Nachteile RODC vs. Proxy gegenüberstellen?
Edit: Hmm also wenn das angefragte Konto auf dem RODC nicht gefunden wird, leitet dieser die Anfrage an den nächsten writable DC weiter. Also auch nichts anderes als ein Proxy. Ich vermute mal, dass für die Kommunikation zwischen RODC und DC ebenfalls Ports geöffnet werden müssen?
Man kann relativ fein steuern was repliziert werden soll. Ich muss das ganze Thema nochmal durchdenken kann mir jemand vlt. kurz Vor- und Nachteile RODC vs. Proxy gegenüberstellen?Edit: Hmm also wenn das angefragte Konto auf dem RODC nicht gefunden wird, leitet dieser die Anfrage an den nächsten writable DC weiter. Also auch nichts anderes als ein Proxy. Ich vermute mal, dass für die Kommunikation zwischen RODC und DC ebenfalls Ports geöffnet werden müssen?
Moin,
ich habe deinen Beitrag nochmals gelesen. Bei dir geht es um eine Anwendung welche in eurer DMZ stehen soll. Bei uns geht um Authentifizierungen über das Internet. Also doch etwas andere Gegebenheiten.
Gruß,
Dani
ich habe deinen Beitrag nochmals gelesen. Bei dir geht es um eine Anwendung welche in eurer DMZ stehen soll. Bei uns geht um Authentifizierungen über das Internet. Also doch etwas andere Gegebenheiten.
ich würde gern eine Webanwendung in der DMZ an einem LDAP Server (Univention) der im LAN steht authentifizieren.
Um welche Anwendung geht es? Was spricht dagegen, dass du die Webanwendung ins LAN stellst und in die DMZ "nu" einen Reverse Proxy bzw. eine Web Application Firewall? Somit verbleibt die Kommunktion zwischen LDAP und Webanwendung im vertrauten Netz.Ich vermute mal, dass für die Kommunikation zwischen RODC und DC ebenfalls Ports geöffnet werden müssen?
Siehe meinen Link, in der Frage der 3. Aufzählungspunkt.Gruß,
Dani
Ich denke das ein Reverse Proxy das LAN nicht so sehr schützt wie einen DMZ. Wir der Webserver kompromittiert (z. B. Durch Code Injektion, was unter Umständen auch durch einen Reverse Proxy hindurch funktioniert) hat der Angreifer theoretisch Zugriff aufs LAN. Wird der Webserver in der DMZ übernommen, kann ich im schlimmsten Fall den Server abschalten und neu aufbauen. Daher bin ich generell dafür einen Server der aus dem Internet erreichbar sein soll im einer DMZ zu platzieren.
Firewall -> Reverse Proxy -> DMZ -> Firewall -> LAN wäre für mich der bessere Aufbau. So muss man nicht den Zugriff auf mehrere Server in der DMZ freigeben sondern nur den Zugriff auf den Reverse Proxy und über den die Zugriffe steuern.
Firewall -> Reverse Proxy -> DMZ -> Firewall -> LAN wäre für mich der bessere Aufbau. So muss man nicht den Zugriff auf mehrere Server in der DMZ freigeben sondern nur den Zugriff auf den Reverse Proxy und über den die Zugriffe steuern.
Moin,
Gruß,
Dani
So muss man nicht den Zugriff auf mehrere Server in der DMZ freigeben sondern nur den Zugriff auf den Reverse Proxy und über den die Zugriffe steuern.
Grundsätzlich sollte in der DMZ alles verboten sein, was nicht benötigt wird. Dazu zählt auch der Zugriff der Server untereinander. Das gleiche gilt meiner Ansicht nach auch fürs LAN. Jeder definiert es anders...Firewall -> Reverse Proxy -> DMZ -> Firewall -> LAN
Bitte auch zwei unterschiedliche Hersteller für die Firewalls nutzen. Wenn du solch ein Wert auf Sicherheit legst. Gruß,
Dani
Da atimme ich dir in allen Punkten zu wie gesagt ich werde das Thema nochmal überdenken. Ich würde mich aber freuen wenn du mich über deine Lösung auf dem laufenden hältst wenn du sie gefunden hast 
wie gesagt ich werde das Thema nochmal überdenken. Ich würde mich aber freuen wenn du mich über deine Lösung auf dem laufenden hältst wenn du sie gefunden hast 
