DMZ - Webserver - LDAP - Ports

[Chris-1992]

Dag Tweakers,

Ik heb een portaal dat ik klanten en interne ter beschikking stel voor uploaden van documenten en dergelijke.

Dit portaal staat op een webserver, beschikbaar als website (HTTPS).
Nu de klanten (Externe) hebben een eigen login die beheert worden in een mssql DB dat werkt perfect en maak ik mij geen zorgen over.
Interne gebruiken hun domain login op in te loggen op het portaal (Website).
Waardoor de webserver in (DMZ) op de DC-AD (LAN) moet gaan kijken als de authenticatie klopt.

Voor de LDAP verbinding moeten volgende poorten openstaan vanuit DMZ naar LAN:
UDP 53 (DNS)
TCP 135 (RPC)
TCP 445 (microsoft-ds)
TCP + UDP 389 (LDAP)
TCP 636 (LDAPS)
UDP 123 (NTP)
TCP 88 (Kerberos)

Kort door de bocht:
Geeft dit grote security problemen?



Alvast bedankt!


Groetjes,

[Voor 5% gewijzigd door Chris-1992 op 21-11-2018 11:12]

[CAPSLOCK2000]

Als je het verder maar goed beveiligd dan hoeft het geen probleem te zijn, maar je kan het geen DMZ meer noemen.

Dat is zo iets als een onzinkbare duikboot maken. Dat kan, maar dan noemen we het geen duikboot meer.
Het hele punt van een DMZ is nou juist om geen verbindingen van je DMZ naar je LAN toe te staan. Als je dat soort verbindingen wel toe staat dan is het geen DMZ meer. (Andersom, van LAN naar DMZ, mag wel).

Het voordeel van een DMZ is dat lekker overzichtelijk is en dat maakt het makkelijk te beveiligen. Zonder DMZ kun je nog steeds prima beveiligen maar je zal het wel moeten doen.

Is het niet mogelijk om je LDAP-server in het DMZ te zetten?

[Chris-1992]

@CAPSLOCK2000
Nee dat klopt,
Maar ze horen toch graag DMZ

Nu moesten we een LDAP server in de DMZ zone zetten, dan moet deze in sync blijven met de AD.
Dan nog moeten er poorten open gezet worden van de één naar de andere site?
Tenzij je ze manueel bij houdt natuurlijk.

Of ben ik helemaal verkeerd aan het denken?

Groetjes,

[CAPSLOCK2000]

Ik bedoelde eigenlijk de AD in de DMZ zetten, maar dat is vast makkelijker gezegd dan gedaan Als dat niet kan dan zul je het maar door je firewall heen moeten laten. Over de beveiliging van AD durf ik verder niet zo veel te zeggen. Gebruik voor LDAP in ieder geval TLS.

[MAX3400]

CAPSLOCK2000 schreef op donderdag 22 november 2018 @ 21:43:
Ik bedoelde eigenlijk de AD in de DMZ zetten

RODC'tje is toch zo geregeld

Je hebt wel gelijk; als ik de tekening in de topicstart zie, staat er een dikke groene pijl tussen LAN en DMZ getekend. Een snelle lezer ziet alleen al op basis van de kleur "any any toegestaan".

@Chris-1992 Waar komt de eis NTP vandaan? Tenzij je enorm acute issues ziet met time-skewing of met Kerberos, heb je toch (heel simplistisch gezegd) een gat van 5 minuten wat tussen machines verschil mag hebben?

/edit: ik lees nog eens goed terug maar ik las ergens overheen. "Interne medewerkers" moeten via LAN -> DMZ kunnen authenticeren. En "externe accounts" staan "ergens" in DMZ pre-configured op basis van een MSSQL? Als de DMZ-machine multi-homed kan worden gemaakt (niet altijd aan te raden), vang je je interne medewerkers af op NIC1 en kan je wel volledig authenticeren. De externe accounts vang je af op NIC2 want die komen vanaf de buitenkant binnen.

"Officieel" zou een ontwerp zijn: internet -> firewall A -> DMZ-server -> firewall B -> LAN-server waarbij je firewall B dus volledig dichttimmert / port-triggert / whatever om je security naar LAN te waarborgen. En je firewall A tik je nog verder dicht; alleen port 443 of 8080 open zetten voor de externe logins.

[Voor 38% gewijzigd door MAX3400 op 22-11-2018 21:56]

[Jazzy]

Chris-1992 schreef op woensdag 21 november 2018 @ 10:46:
Kort door de bocht:
Geeft dit grote security problemen?

Kort door de bocht: ja.

Het idee van een DMZ is dat je er vanuit moet gaan dat deze systemen 'gehacked' kunnen worden, ze zijn immers bereikbaar vanaf het internet dus er is een grotere kans dat een aanvaller toegang tot deze machines krijgt. Dan is het vervolgens zaak om er voor te zorgen dat iemand vanaf die kwetsbare server nergens anders bij kan komen, en dus al helemaal geen toegang kan krijgen tot je interne netwerk.

In jouw design kan de aanvaller je hele domain controller benaderen over zo'n beetje alle poorten die hij maar nodig kan hebben. En als dat lukt dat heeft hij toegang tot de database met useraccounts. Dat lijkt me dus niet de bedoeling, dat gaat precies tegen het idee van een DMZ in.

[Frogmen]

Voor de LDAPS authenticatie hoeft toch alleen poort 636 tussen server en lan open te staan? Verder van buiten hoeft alleen poort 80 en 443 open te staan. Volgens mij zet je een beetje teveel open.

[Chris-1992]

@MAX3400 @CAPSLOCK2000
RODC is inderdaad snel opgezet maar deze moet in sync staan met de DC.
Hiervoor is er ook een connectie tussen LAN en DMZ nodig dan?
Wat dan min of meer het zelfde effect heeft dan wat getekend is in de eerste post.

@MAX3400
Als men gaat werken met 2 NICS zitten "externe" users inderdaad op een ander netwerk.
Maar als de "machine" gehackt wordt zoals @Jazzy zegt heeft hij toch toegang tot de LAN.

@Frogmen
UDP 53 (DNS) (Deze is nodig voor een clientservices die in de background draait)
TCP 135 (RPC) (Idem)
TCP 445 (microsoft-ds) (Idem)

TCP 636 (LDAPS)

UDP 123 (NTP) (Deze is inderdaad minder van belang)
TCP 88 (Kerberos) (Singel sign-on wordt gebruikt door de interne)

We gaan nu bekijken als het "Veiliger" is om de RODC op azure te gebruiken.

[Jazzy]

Ik denk dat je beter het volgende kunt doen.

Verplaats de server uit de DMZ terug naar het interne netwerk want met AD authenticatie blijf je tegen het probleem aanlopen dat je veel poorten moet openen van de DMZ naar het interne netwerk. Zet in de DMZ dan een reverse proxy die luistert op poort 443. Daar kun je dan aan intrusion detection doen en bijvoorbeeld filteren op een beperkt aantal virtual directories. De reverse proxy zet het verkeer vervolgens door naar je interne netwerk.

In plaats van die hele lijst aan poorten heb je nu het inkomende verkeer beperkt tot maar één poort die open hoeft.

[ElCondor]

Jazzy schreef op vrijdag 23 november 2018 @ 20:16:
Ik denk dat je beter het volgende kunt doen.

Verplaats de server uit de DMZ terug naar het interne netwerk want met AD authenticatie blijf je tegen het probleem aanlopen dat je veel poorten moet openen van de DMZ naar het interne netwerk. Zet in de DMZ dan een reverse proxy die luistert op poort 443. Daar kun je dan aan intrusion detection doen en bijvoorbeeld filteren op een beperkt aantal virtual directories. De reverse proxy zet het verkeer vervolgens door naar je interne netwerk.

In plaats van die hele lijst aan poorten heb je nu het inkomende verkeer beperkt tot maar één poort die open hoeft.

We have a winner...