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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 308346
Url: https://administrator.de/forum/ldap-auth-aus-dmz-308346.html
Ausgedruckt am: 23.12.2024 um 00:12 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 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 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
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
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
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