DMZ en de afweging tussen praktisch en veilig

[Verwijderd]

Ik heb een wat algemene vraag. Ik loop regelmatig tegen het probleem op dat data en applicaties waar je via internet wel bij zou willen intern op het LAN staat, en dat je via internet alleen bij servers in de DMZ kan. En andersom is ook wel eens, dat je iets liever in het LAN hebt, maar dat het in de DMZ staat omdat je er via internet bij zou willen.

Small Business Server met Exchange zou ik bijvoorbeeld liever op het LAN willen, maar dan kunnen we niet meer bij de webmail van buitenaf. Wij hebben ook programmeurs, hun code staat in Subversion op het LAN, maar ze willen op zich wel via internet erbij kunnen (thuis werken). Een interne webapplicatie voor CRM staat in het LAN, en is dus via internet weer niet bereikbaar.

En dan kun je via je firewall natuurlijk 'gaatjes prikken' maar op een gegeven moment zou ik toch een beetje het gevoel hebben dat de DMZ niet meer zo geisoleerd is als in beginsel wel de bedoeling was.

Ik vroeg mij af: hoe denken jullie hierover en hoe gaan jullie hiermee om?

Bedankt!

[Seth4Chaos]

Heel simpel: VPN.

Alles wat niet door derde benaderd hoeft te worden zet je in je LAN, wat wel door derde benaderd moet kunnen worden zet je in je DMZ.

Gebruikers die vanaf internet bij LAN zaken moeten kunnen moeten een VPN-verbinding opbouwen. Wij maken gebruik van OpenVPN en IPSec.

[chromeeh]

Verwijderd schreef op woensdag 29 april 2009 @ 10:11:
LAN <> DMZ verhaal.

In je LAN nog wel een puur LAN? Dus de DMZ kan onder geen beding praten met LAN en vice versa?
Want anders is het hele principe van DMZ ook om zeep.

Als ik jou was zou ik eerst eens goed kijken dat het LAN en DMZ echt gescheiden zijn.
Vanaf daar kun je verder kijken.
Hier worden alle DMZ machines ook met een andere kleur patchkabels gepatched, zodat je altijd weet wat een DMZ machine is.

[Sendy]

Ik dacht dat het principe van een DMZ was om diensten aan het LAN en aan het internet aan te bieden. Als een DMZ niet hoeft te communiceren met het LAN dan had je de DMZ beter een apart netwerk kunnen noemen.

[DiedX]

Goede vragen.

• Wat wil je beschermen?
• Waartegen wil je je beschermen?
• Wat is de waarde van datgene waartegen je je wilt beschermen?

En bereid je maar voor op ruzie Ik heb het idee dat je dondersgoed weet wat je wilt, maar dat je op zoek bent naar onderbouwing van je mening. Niet iedereen gaat het eens zijn met je. En om nog een dooddoener er tegenaan te gooien:

"Er is altijd een tradeoff tussen security en bruikbaarheid". cq: de ontwikkelaars moeten over naar (Open)VPN, of moeten gewoon maar op werk werken.

[ Voor 3% gewijzigd door DiedX op 29-04-2009 12:03 . Reden: Opmaak (En typo) ]

[Bl@ckbird]

Sendy schreef op woensdag 29 april 2009 @ 11:10:
Ik dacht dat het principe van een DMZ was om diensten aan het LAN en aan het internet aan te bieden. Als een DMZ niet hoeft te communiceren met het LAN dan had je de DMZ beter een apart netwerk kunnen noemen.

Een demilitarized zone en een stukje netwerk wat qua veiligheids niveau tussen het veilige LAN en het onveilige internet in zit. Het is een veiligheidszone waar bepaalde policies gelden.
Zo zou je bijvoorbeeld ook met meerdere DMZ's / veiligheidszone kunnen werken:
- Internet
- LAN (waar interne users / clients in zitten)
- DMZ voor internet facing servers ( Zoals web-, en mailservers)
- DMZ met interne servers
- Externe VPN users

Zo kan je ook interne servers beschermen tegen interne en externe VPN users.
( Door middel van firewalls en eventueel IPS. )

Wie, wat, waar bij mag kunnen wij niet voor je bepalen.
Zie ook de post hierboven van DiedX.

[DiedX]

Ik zag in mijn eigen tekst een gore typo. Er stond dat programmeurs maar thuis moesten werken. Dat moet werk zijn natuurlijk

Qua SVN: wat is de waarde van je broncode? Wat is de schade als die op straat ligt? In hoeverre gaat de productiviteit als je SVN zo op het internet gooit (in een DMZ?). Hoe sterk is het beveiligd als je dit alleen via (Open)VPN beschikbaar maakt?

Idem voor Exchange? Zelf krijg ik jeuk van Exchange die beschikbaar is via het Internet, wellicht is dat voor jou anders... Heb je de mogelijkheid om Exchange te ontsluiten via een frontend-server, zodat je data van toegang scheidt?

Als ik je zo hoor neig ik sterk ernaar om de zaak plat te slaan: een frontend-server voor Exchange (mits mogelijk!) in een DMZ, en die frontend met SVN in een DMZ prakken. Toegang tot de DMZ van buiten alleen maar mogelijk met (Open)VPN. De codekloppers kunnen makkelijk erbij, mensen kunnen via de VPN bij hun mail, en dat CRM mag je dan ook wel ontsluiten. Let wel: ik ken de situatie niet.

En als ik dan toch aan het jennen ben: je hebt overal een virusscanner en firewall op geinstalleerd staan, en je hebt de laptops van de programmeurs via Whole-Disk-Encryption beschermd tegen verlies? Anders ben je alsnog de sjaak met je super-de-luxe VPN oplossing

[riddles]

Er zijn genoeg hele grote bedrijven die OWA via internet beschikbaar stellen. Dat betekent inderdaad niet dat je je Exchange Server zelf in de DMZ moet zetten. Een reverse proxy is een optie, of een hardware appliance met extra beveiliging. Hetzelfde kan voor SVN gelden.

De tweede vraag is dan hoe je de beveiliging en authenticatie regelt.SSL is natuurlijk net zo veilig (of onveilig) als een VPN. Volstaat wachtwoord authenticate, of wil je meer (token, client certificate)? En vanaf welke machine sta je toegang toe? Alleen vanaf gecontroleerde machines (lees bedrijfseigen) of ook van prive machines / internet cafés?

[Vicarious]

Een collega van mij wist een DMZ altijd wel treffend te verwoorden. Je hebt in feite drie kanten:
- The Good, ofwel je interne netwerk
- The Bad, ofwel het grote boze internet
- The Ugly, ofwel je DMZ

In de ideale situatie kunnen The Good en The Bad nooit rechtstreeks met elkaar communiceren. Daar hebben zij The Ugly als intermediair voor nodig. Wat zet je dus normaal gesproken in je DMZ neer:
- Proxy server voor verkeer van de interne clients naar het internet (bijv. ISA)
- Reverse proxy server om websites zoals OWA e.d. te publiceren
- VPN devices

Om te zorgen dat de DMZ wel met het interne LAN kan communiceren (wel zo praktisch als je Radius wilt authenticeren om maar een voorbeeld te noemen) moet je dus wel enkele (kleine) gaatjes in je firewall prikken. Je staat de specifieke servers op bepaalde specifieke poorten toe vanuit de DMZ naar je LAN toe. Het risico is echter klein, aangezien je je eerst al in de DMZ moet authenticeren. Als dit mislukt heb je al geen toegang, mocht je er toch doorheen weten te hacken zit je alleen nog maar in de DMZ.

[morphje]

Verwijderd schreef op woensdag 29 april 2009 @ 10:11:
Ik heb een wat algemene vraag. Ik loop regelmatig tegen het probleem op dat data en applicaties waar je via internet wel bij zou willen intern op het LAN staat, en dat je via internet alleen bij servers in de DMZ kan. En andersom is ook wel eens, dat je iets liever in het LAN hebt, maar dat het in de DMZ staat omdat je er via internet bij zou willen.

Small Business Server met Exchange zou ik bijvoorbeeld liever op het LAN willen, maar dan kunnen we niet meer bij de webmail van buitenaf. Wij hebben ook programmeurs, hun code staat in Subversion op het LAN, maar ze willen op zich wel via internet erbij kunnen (thuis werken). Een interne webapplicatie voor CRM staat in het LAN, en is dus via internet weer niet bereikbaar.

En dan kun je via je firewall natuurlijk 'gaatjes prikken' maar op een gegeven moment zou ik toch een beetje het gevoel hebben dat de DMZ niet meer zo geisoleerd is als in beginsel wel de bedoeling was.

Ik vroeg mij af: hoe denken jullie hierover en hoe gaan jullie hiermee om?

Bedankt!

Als beheerder van een tig aantal machines en veel te veel poorten open in de firewall kan ik het volgende erover vertellen. Je bent no matter what de sjaak.
Niet openzetten is dodelijk voor je baan, want als jij het niet doet, dan doet de volgende het wel.
Wel openzetten betekend (in een beperkt aantal gevallen) een klein risico.

Je kan je daarintegen wel indekken voor een aantal zaken. Bedenk ten alle tijden wat een DMZ is. Voorbeeld: hoe kan jouw exchange authenticeren zonder de active directory in je netwerk? Hoe kan je VPN appliance bepalen wie toegang heeft zonder een radius (die in je LAN staat). Hoe kan je een CRM/ERP ontsluiten naar het internet, terwijl het ding intern staat (ik ken er maar heel heel weinig die de volledige database mirrort naar een DMZ met extra dure mssql/oracle licenties).

Klassiek tekstboek voorbeeld. De DMZ is een netwerk voor externe en interne gebruikers. Dus de webserver als voorbeeld. Ja lekker is dat, want een webserver heeft geen (althans in hun voorbeeld) info van binnen nodig. Het DMZ is nu vooral (eventueel opgedeeld in meerdere DMZ'en al naar gelang) het domein van doorgeefluiken. Je zet een apparaat tussen een externe en interne firewall in die als politie agent gaan spelen. Voorbeelden hiervan zijn al genoemd: reverse proxy, VPN appliance en webservers met database connecties naar binnen toe.

Beste advies: denk logisch na, denk nog een keer na en voer het uit op een acceptabele veilige bruikbare wijze. Dat doen wij op het werk ook.