Windows domeneserver i DMZ

[enden]

Jeg driver og "krangler" litt om et oppsett med en leverandør. De vil inn med en webserver som skal kommunisere med et par applikasjoner i bakkant, og jeg skal levere en server og legge til rette for dette i forkant. De kommer med to krav jeg ikke klarer å få til å henge sammen. Webserveren (2003 med IIS) skal stå i DMZ og være medlem av domenet.

 

I DMZ-et har den potensielt alle dører vid åpne mot nett. Alle fibre i kroppen min stritter da mot å begynne å åpne porter inn i nettverket for å tillate kobling mot domenet.

 

Alternativet er selvfølgelig også horriblet - å sette serveren i produksjonsnettet og åpne port 80 og potensielt 443 inn til den. Fordelen slik jeg ser det er at det er en langt mindre kontaktflate ut med denne løsningen.

 

Hva maner dere? Hva er verst av å sette en server som er medlem av domenet i DMZ eller å sette en server med IIS på en server i produksjonsnettet?

[Habla Møberg]

Jeg driver og "krangler" litt om et oppsett med en leverandør. De vil inn med en webserver som skal kommunisere med et par applikasjoner i bakkant, og jeg skal levere en server og legge til rette for dette i forkant. De kommer med to krav jeg ikke klarer å få til å henge sammen. Webserveren (2003 med IIS) skal stå i DMZ og være medlem av domenet.

 

I DMZ-et har den potensielt alle dører vid åpne mot nett. Alle fibre i kroppen min stritter da mot å begynne å åpne porter inn i nettverket for å tillate kobling mot domenet.

 

Alternativet er selvfølgelig også horriblet - å sette serveren i produksjonsnettet og åpne port 80 og potensielt 443 inn til den. Fordelen slik jeg ser det er at det er en langt mindre kontaktflate ut med denne løsningen.

 

Hva maner dere? Hva er verst av å sette en server som er medlem av domenet i DMZ eller å sette en server med IIS på en server i produksjonsnettet?

 

Det finner du utmerkede løsninger på technet-sidene til MS. Blant annet har jeg funnet gode løsninger for å sette en exchange front-end server i DMZ. En exhchange front end server trenger også tilgang til diverse tjenester på domenet, så løsningen blir ganske lik. Cluet er at den som skal stå i DMZ må strupes ned og sikres maksimalt, og stenge det men ikke strengt tatt trenger av tjenester, for så å lage en sikker tunnel inn til en av DC-ene på lokalt. Dog er det et relativt komplekst oppsett som tar deg noen timer/dager å sette opp helt riktig. Men så blir det temmelig idiotsikkert også.

Søk på technet-sidene etter "domain", "server", "DMZ" og lignende, så finner du nok svar der :-)

[enden]

Så det du sier er at du gladlig setter en Exchange-server (som har en kopi av AD) i et DMZ?!? Hva tror du skjer hvis den blir tatt? Hvilken info har intrengeren ikke tilgang til da..? Og når vedkommende er lei av å studere kopien av AD, så er alle porter som trengs for å tusle pent og rolig inn på en DC i nettverket vid åpne.

 

Skal du ha en front-end til Exchange på grunn av sikkerhet så bruker du ISA, ikke Exchange...

[Habla Møberg]

Så det du sier er at du gladlig setter en Exchange-server (som har en kopi av AD) i et DMZ?!? Hva tror du skjer hvis den blir tatt? Hvilken info har intrengeren ikke tilgang til da..? Og når vedkommende er lei av å studere kopien av AD, så er alle porter som trengs for å tusle pent og rolig inn på en DC i nettverket vid åpne.

 

Skal du ha en front-end til Exchange på grunn av sikkerhet så bruker du ISA, ikke Exchange...

 

Ditt svar forteller meg at du ikke har satt deg inn i hva som skal til for å gjøre dette på en sikker måte. Sikre løsninger finnes, om en bare gidder å lese seg opp på det. Technet og Exchange-sidene til MS har masse god info, om enn ganske omfattende.

[enden]

Joa, jeg har lest meg opp på det, og alt jeg finner av info sier meg det samme. Man plasserer en server i et usikkert miljø og gir denne tilgang gjennom brannmuren. Når denne serveren blir kompromitert har man åpne kommunikasjonskanaler inn mot domenekontrollere gjennom brannmuren. Du kan jo ikke akkurat nekte for det...

 

Noen andre som har synspunkter?

[Gaute]

Jeg driver og "krangler" litt om et oppsett med en leverandør. De vil inn med en webserver som skal kommunisere med et par applikasjoner i bakkant, og jeg skal levere en server og legge til rette for dette i forkant. De kommer med to krav jeg ikke klarer å få til å henge sammen. Webserveren (2003 med IIS) skal stå i DMZ og være medlem av domenet.

 

I DMZ-et har den potensielt alle dører vid åpne mot nett. Alle fibre i kroppen min stritter da mot å begynne å åpne porter inn i nettverket for å tillate kobling mot domenet.

 

Alternativet er selvfølgelig også horriblet - å sette serveren i produksjonsnettet og åpne port 80 og potensielt 443 inn til den. Fordelen slik jeg ser det er at det er en langt mindre kontaktflate ut med denne løsningen.

 

Hva maner dere? Hva er verst av å sette en server som er medlem av domenet i DMZ eller å sette en server med IIS på en server i produksjonsnettet?

 

 

Mulig denne kan hjelpe litt?

http://www.microsoft.com/windowsserver2003/adam/default.mspx

[lhegdal]

Hvis du struper alle portene til webfrontenden i firewallen din, untatt den/de tjenestene går på. Og så åpner du port for LDAP fra den bestemte IP'en til frontend serveren til en DC internt.

 

Alternativt så får du sette alt internt og publisere det via ISA eller en FW.

 

Uansett hvilken løsning du velger så vil den kunne crackes.

Jeg forstår misnøyen din med å ønske å åpne for AD.

[enden]

Mulig denne kan hjelpe litt?

http://www.microsoft.com/windowsserver2003/adam/default.mspx

Skummet kjapt gjennom, og det er vel på applikasjonslaget - altså programvareleverandørens område? I så fall er vi nok like langt da de er like sta som meg

[CrZy_T]

Kan jeg spørre hvilken leverandør/program dette er?

[enden]

Leverandøren trenger jeg sikkert ikke sverte, men det er en Visma-løsning.

[Justin_Sane]

Så det du sier er at du gladlig setter en Exchange-server (som har en kopi av AD) i et DMZ?!? Hva tror du skjer hvis den blir tatt? Hvilken info har intrengeren ikke tilgang til da..? Og når vedkommende er lei av å studere kopien av AD, så er alle porter som trengs for å tusle pent og rolig inn på en DC i nettverket vid åpne.

 

Skal du ha en front-end til Exchange på grunn av sikkerhet så bruker du ISA, ikke Exchange...

Bare for å kaste meg på bølgen her...

Exchange har ikke kopi av AD, den bruker faktisk ikke "ad" engang. Den bruker GC.

[ilpostino]

enden: sett på løsninger for reverse proxy? regner emd det er noe ala det leverandøren skal sette opp.

[Habla Møberg]

Bare for å kaste meg på bølgen her...

Exchange har ikke kopi av AD, den bruker faktisk ikke "ad" engang. Den bruker GC.

 

Det som jeg synes er morro, og som jeg har jobbet endel med tidligere, er at _om man gidder å lese seg opp_ så finnes det utmerkede løsninger for å minimalisere behovet for kommunikasjon mellom to dc-er (enten det nå er exchange og/eller IIS som er behovet), og du kan gjøre kommunikasjonen så u-standard at det er tilnærmet klin umulig å misbruke. Det tar tid å sette opp, med et noe-over-middels komplisert oppsett av sertifikatserveren på en dc, mye styr med endringer av hvilke porter som skal brukes av de forskjellige tjenestene, lokale kopier av GC som krypteres, etc, men det er mulig, og det ble iallfall for en 4 års tid siden sett på som en "sikker nok" metode, av flere kjente risiko-anlyse-firma. Selvsagt kan ting ha endret seg siden sist, og ikke husker jeg detaljene (fortrengt er vel et bedre ord...), men at det lot seg gjøre, og fungerte stabilt, det vet jeg veldig godt. Et av mine gamle prosjekter på dette, fra 2003, er fremdeles idag i produksjon hos en større bedrift, som har både IIS og exch/OWA tilgjengelig, omtrent slik "enden" er ute etter her.

 

Men som jeg har forstått "enden" her, så er han ikke lysten på en slik løsning, så...

[-Night-]

funker ikke med fler sone netverk hvor du setter servern i en helt eget nettverk vlan eller fysisk spearert så kan du ha den så åpen du vill men ha ip+port på den som skall in til

hovednettverket.

 

Med Sone baser nettverk kan du også gi bruker som trenger det høyere tilgang en andre med kun å endre deres vlan. med dette slipper du å bekymre deg over hva andre kan gjøre med høyretilgang fordi det går kun utover den som bruker den porten i switchen ingen andre.

Endret 9. desember 2008 av Nightmeare

[xcomiii]

Her er oppsettet jeg lagde en gang i en bedrift:

 

2 stk DC servere i et helt eget nett, eget domain og forest, webservere i samme domain.

 

For å nå disse fra LAN, lage enveis trust fra LAN domain til DMZ domain, bruke stub zone, og lage regler på firewall som ikke tillater trafikk inn til DC maskinene, kun member web servers. I en skikkelig firewall er det enkelt å definere.

 

Om noen klarer å hacke webserverne, er ikke det noen krise, da DC'en er beskyttet fra internett, samt at de er i eget forest/domain. Om så DC ene skulle bli hacket, kommer de ikke videre inn pga firewall/trust.

[enden]

Har helt glemt denne tråden. Etter litt om og men hadde visst leverandøren en løsning på lager likevel. Webserveren står standalone i DMZ med kun èn ukurant port åpen til en liten server-komponent med AD-hook på innsiden. Det virker som om de holder denne løsningen skjult så lenge som mulig fordi de synes det er enklere å slippe å sette den opp...

Endret 10. mai 2009 av enden

[ThorB]

Har helt glemt denne tråden. Etter litt om og men hadde visst leverandøren en løsning på lager likevel. Webserveren står standalone i DMZ med kun èn ukurant port åpen til en liten server-komponent med AD-hook på innsiden. Det virker som om de holder denne løsningen skjult så lenge som mulig fordi de synes det er enklere å slippe å sette den opp...

synes dette hørtest kjent ut. er dette en løsning med noe flott som heter ad-adapter?

det er ofte kjipt med all denne integrasjonen av alle systemer. mye brukervennlighet går nok av og til på bekostning av sikkerheten.

[enden]

En ting er brukervennlighet, men når det er snakk om lettvinte snarveier for de som skal sette opp en applikasjon så blir jeg litt forbanna. Leverer et feiende flott lavt tilbud og tar alle snarveier i boka for å legge så lite arbeid i det som mulig og dermed spare timer. Sikkerheten driter de visst i...