Security Entscheidungen für Veröffentlichungen nach außen
Hallo Kollegen,
ich möchte hier eine Diskussion anstossen, wie Ihr die folgende Aufgabe umsetzen würdet, wo Ihr die Vorteile/Nachteile seht, wie Ihr die Gesamtsicherheit beurteilt:
99% Windows Netzwerk
Vorhandener Zugang zum Internet über Standleitung, eigene IP Range mit festen IPs
Firewall eines bekannten Herstellers an der Außengrenze
DMZ mit verschiedenen Diensten, welche nach außen veröffentlicht sind (DMZ wird durch die erwähnte FW bereitgestellt)
Die Firewall routet Verbindungen nach/von intern aufgrund von NAT Regel/Virtuellen Interfaces/ACLs
Hier ein kleines Schaubild (auf ASCII Basis...)
Internet ----- FW --- Internes Netz ---- Interne LoadBalancer ---- Interne Dienste
|
DMZ 1-----------+------------ DMZ 2
Load Balancer Webservices
Aktuell werden eingehende Verbindungen auf der Firewall angenommen, per PAT an den LoadBalancer in der DMZ weiter gegeben.
Der prüft wiederum, welcher der Dienste in der DMZ 2 Zone grad annahmebereit ist und gibt die Verbindung weiter.
Bei manchen Diensten gehts vom DMZ LoadBalancer an den internen LoadBalancer und von dort zu den Zieldiensten.
Weder die Loadbalancer noch die Firewall führen eine (Pre)Authentifizierung der eingehenden Anrufe durch,
sondern leiten nur weiter (ggf. nach statischer Prüfung auf bekannte Attacken, demnächst weitere Secruitydienste).
Generell nun die Fragen/Ideen hierzu:
Wie ist die Sicherheit der Umgebung aus Sicht von aussen zu beurteilen?
Themen könnten ein mögliches Angreifen/Ausnutzen von internen Diensten sein.
(Durchreichen von Verbindungen ins interne Netz, Authentifizierung erst im internen Netz...)
Daher gibt es verschiedene Ideen:
Authentifizierung auf dem LoadBalancer in der DMZ über eine Bereitstellen eines Portals zur Anmeldung, dort also Authentifizierung,
danach je nach Authentifizierung Bereitstellung Zugänge zu den (in der DMZ und intern) gehosteten Diensten.
Eine MFA Authentifizierung ist zumindest für Dienste, welche eine direkte Anmeldung benötigen, angedacht (OWA, RDS...)
Hier gibt es auch wieder unterschiedliche Möglichkeiten:
RODC in die DMZ, dort nur die Benutzer(PW) hinterlegen (lassen), die sich von extern anmelden
- einer der Vorteile: (erstmal) keine direkte Verbindung von in der DMZ gehosteten Diensten zu internen DC Server nötig
- einer der Nachteile: der RODC bzw. ggf- die in der DMZ gehosteten Systeme brauchen trotzdem immer wieder Zugang zu einem beschreibbaren DC
wg. Computer-Passwortänderungen (sofern diese in der Domäne sein müssen
(sinnvoll z.B. für MS RDS Gateway Systeme, wenn bei der Auth gleich geprüft werden soll, wer sich RDS technisch wohin verbinden darf?)
Gegen diesen RODC könnte auch der LoadBalancer die Authentifizierung vornehmen (LDAPS).
oder
Bezgl. Authentifizierung:
Weiterleiten der Autentifizierungsanfrage direkt an einen DC/Radius im internen Netz ->
Zumindest haben wir damit eine erfolgreiche Authentifizierung bereits in der DMZ erledigt,
bevor es DANN ins interne Netz zu den eigentlichen Diensten geht
Andere Ideen wäre die Nutzung von ADFS, also der DMZ LoadBalancer als ADFS Proxy, Weiterleitung der Anfrage an einen ADFS Verbund (intern? in DMZ?)
Der Verbund hätte keine direkten internen Daten gehostet, die abgegriffen werden könnten.
(im Gegensatz zu einem (vollwertigen) DC, der für die Authentifizierung angefragt wird).
Aktuell werden nur interne Benutzer für die Authentifizierung verwendet; es gibt keine Vertrauensstellungen zu Partnerunternehmen,
keine AzureAD Einbindungen etc.
Hier werden sicherlich Anfragen kommen, Partnerunternehmen anzubinden; wohl eine AD Vertrauensstellung wird kurz-mittelfristig kommen.
Der Rest ist eher Glaskugel.
Ich bin sehr gespannt auf die zahlreichen Meinungen meiner Kollegen - Danke Euch!
Joey
ich möchte hier eine Diskussion anstossen, wie Ihr die folgende Aufgabe umsetzen würdet, wo Ihr die Vorteile/Nachteile seht, wie Ihr die Gesamtsicherheit beurteilt:
99% Windows Netzwerk
Vorhandener Zugang zum Internet über Standleitung, eigene IP Range mit festen IPs
Firewall eines bekannten Herstellers an der Außengrenze
DMZ mit verschiedenen Diensten, welche nach außen veröffentlicht sind (DMZ wird durch die erwähnte FW bereitgestellt)
Die Firewall routet Verbindungen nach/von intern aufgrund von NAT Regel/Virtuellen Interfaces/ACLs
Hier ein kleines Schaubild (auf ASCII Basis...)
Internet ----- FW --- Internes Netz ---- Interne LoadBalancer ---- Interne Dienste
|
DMZ 1-----------+------------ DMZ 2
Load Balancer Webservices
Aktuell werden eingehende Verbindungen auf der Firewall angenommen, per PAT an den LoadBalancer in der DMZ weiter gegeben.
Der prüft wiederum, welcher der Dienste in der DMZ 2 Zone grad annahmebereit ist und gibt die Verbindung weiter.
Bei manchen Diensten gehts vom DMZ LoadBalancer an den internen LoadBalancer und von dort zu den Zieldiensten.
Weder die Loadbalancer noch die Firewall führen eine (Pre)Authentifizierung der eingehenden Anrufe durch,
sondern leiten nur weiter (ggf. nach statischer Prüfung auf bekannte Attacken, demnächst weitere Secruitydienste).
Generell nun die Fragen/Ideen hierzu:
Wie ist die Sicherheit der Umgebung aus Sicht von aussen zu beurteilen?
Themen könnten ein mögliches Angreifen/Ausnutzen von internen Diensten sein.
(Durchreichen von Verbindungen ins interne Netz, Authentifizierung erst im internen Netz...)
Daher gibt es verschiedene Ideen:
Authentifizierung auf dem LoadBalancer in der DMZ über eine Bereitstellen eines Portals zur Anmeldung, dort also Authentifizierung,
danach je nach Authentifizierung Bereitstellung Zugänge zu den (in der DMZ und intern) gehosteten Diensten.
Eine MFA Authentifizierung ist zumindest für Dienste, welche eine direkte Anmeldung benötigen, angedacht (OWA, RDS...)
Hier gibt es auch wieder unterschiedliche Möglichkeiten:
RODC in die DMZ, dort nur die Benutzer(PW) hinterlegen (lassen), die sich von extern anmelden
- einer der Vorteile: (erstmal) keine direkte Verbindung von in der DMZ gehosteten Diensten zu internen DC Server nötig
- einer der Nachteile: der RODC bzw. ggf- die in der DMZ gehosteten Systeme brauchen trotzdem immer wieder Zugang zu einem beschreibbaren DC
wg. Computer-Passwortänderungen (sofern diese in der Domäne sein müssen
(sinnvoll z.B. für MS RDS Gateway Systeme, wenn bei der Auth gleich geprüft werden soll, wer sich RDS technisch wohin verbinden darf?)
Gegen diesen RODC könnte auch der LoadBalancer die Authentifizierung vornehmen (LDAPS).
oder
Bezgl. Authentifizierung:
Weiterleiten der Autentifizierungsanfrage direkt an einen DC/Radius im internen Netz ->
Zumindest haben wir damit eine erfolgreiche Authentifizierung bereits in der DMZ erledigt,
bevor es DANN ins interne Netz zu den eigentlichen Diensten geht
Andere Ideen wäre die Nutzung von ADFS, also der DMZ LoadBalancer als ADFS Proxy, Weiterleitung der Anfrage an einen ADFS Verbund (intern? in DMZ?)
Der Verbund hätte keine direkten internen Daten gehostet, die abgegriffen werden könnten.
(im Gegensatz zu einem (vollwertigen) DC, der für die Authentifizierung angefragt wird).
Aktuell werden nur interne Benutzer für die Authentifizierung verwendet; es gibt keine Vertrauensstellungen zu Partnerunternehmen,
keine AzureAD Einbindungen etc.
Hier werden sicherlich Anfragen kommen, Partnerunternehmen anzubinden; wohl eine AD Vertrauensstellung wird kurz-mittelfristig kommen.
Der Rest ist eher Glaskugel.
Ich bin sehr gespannt auf die zahlreichen Meinungen meiner Kollegen - Danke Euch!
Joey
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 378174
Url: https://administrator.de/forum/security-entscheidungen-fuer-veroeffentlichungen-nach-aussen-378174.html
Ausgedruckt am: 08.05.2025 um 11:05 Uhr
2 Kommentare
Neuester Kommentar
du brauchst Consulting, das sind schon heftig komplexe Fragestellungen. Du kannst auf deine "Wenn, aber, oder sonst, was wäre denn so oder so, und alternativ dies und das" keine geradlinige Antwort erhalten.
Du mußt deine Augen für die Wahrheit öffnen:
1.) das Internet ist böse. Es ist voller automatisierter Hack-Maschinen und voller manuell agierende Hacker
2.) Jedes Netz ist angreifbar solange auch nur irgendein Teil davon eine öffentliche IP Addresse hat und physisch mit dem nichtöffentlichen Netz verbunden ist. ALLLES WIRD ANGEGRIFFEN. Vielleicht nicht heute und vielleicht auch nicht morgen. Aber irgendwann passiert es....
Die interne IT vor dem Internet zu schützen ist also eine niemanls endende Aufgabe, das ist ein Prozeß den du implementieren mußt, der sich auch von diversen Randfaktoren leitet.
Du mußt deine Augen für die Wahrheit öffnen:
1.) das Internet ist böse. Es ist voller automatisierter Hack-Maschinen und voller manuell agierende Hacker
2.) Jedes Netz ist angreifbar solange auch nur irgendein Teil davon eine öffentliche IP Addresse hat und physisch mit dem nichtöffentlichen Netz verbunden ist. ALLLES WIRD ANGEGRIFFEN. Vielleicht nicht heute und vielleicht auch nicht morgen. Aber irgendwann passiert es....
Die interne IT vor dem Internet zu schützen ist also eine niemanls endende Aufgabe, das ist ein Prozeß den du implementieren mußt, der sich auch von diversen Randfaktoren leitet.