DMZ LAN setup thuis netwerk

[Retonator]

Ik wil een thuis netwerk opzetten met een 2 tal servers die verschillende taken kunnen uitvoeren. 1 server wil ik graag in het LAN hebben en de ander in het DMZ.

Hier volgt een beschrijving van de taken.

1: Een file server die vanaf het LAN bereikbaar is voor alle lan clients. Ik wil hiervoor een ubuntu 16.04 server voor inrichten met HDD's in een zfspool (bovenop LUKS). Het delen op het netwerk wil ik zowel via NFS als SMB doen. Deze interne server kan ook dienst doen als dnsserver. Misschien dat ik de server ook wil inzetten als IDS(snort op een aparte nic). De bedoeling is dat deze server alleen bereikbaar is vanuit mijn LAN. Deze server wil ik gaan draaien op een krachtige pc

2: Een server die taken kan uitvoeren die beschikbaar moeten zijn vanaf het internet. Specifiek moet op deze server een instantie van nextcloud draaien. Voor deze server wil ik een raspberry pi 3 inzetten.

Mijn vraag is nu hoe richt ik mijn netwerk in zodanig dat mijn nextcloud server gebruik kan maken van een fileshare op de LAN server.

Ik heb zelf aan de volgende mogelijkheden gedacht.

1: Firewall van DMZ naar LAN opzetten zodanig dat alleen NFS verkeer van dmz naar lan kan. Ik ben dan echter van mening dat het niet echt meer een server in het DMZ is. Het liefst heb ik helemaal geen toegang van dmz naar lan (behalve established en related verkeer).

2: Ik kan een nfs server draaien op de dmz server zodat deze beschikbaar is binnen mijn lan echter de data staat dan niet op het zfs cluster.

3: Ik zou alle services op 1 server kunnen draaien op mijn lan, dat lijkt mij echter de minst veilige optie.

Qua hardware heb ik een ER-lite en een tp-link 16 poorts managed switch.

Wat is volgens jullie een goede veilige oplossing?

[Verwijderd]

Misschien iets:

Geen DMZ.

Je hebt een managed switch, gebruik VLANS?
1 Server (Die buitenaf bereikbaar moet zijn), zet je in een apart VLAN
De andere server die alleen vanaf de LAN kant bereikbaar moet zijn, doe je in de zelfde VLAN als je LAN.

Of denk ik nou heel moeilijk?

[Retonator]

Verwijderd schreef op woensdag 4 januari 2017 @ 21:14:
Misschien iets:

Geen DMZ.

Je hebt een managed switch, gebruik VLANS?
1 Server (Die buitenaf bereikbaar moet zijn), zet je in een apart VLAN
De andere server die alleen vanaf de LAN kant bereikbaar moet zijn, doe je in de zelfde VLAN als je LAN.

Of denk ik nou heel moeilijk?

2 vlans is eigenlijk het zelfde als 2 subnetten op een andere fysieke poort van de router. Ook al maak ik 2 vlans dan nog zit ik met het probleem dat de server die van buiten af bereikbaar moet zijn wel bij de storage moeten kunnen via NFS op de server in het interne netwerk. En dan moet er dus een firewall rule komen die het DMZ gedeelte toegang geeft tot het LAN gedeelte. Tenzij ik natuurlijk iets mis.

Volgens mij is jou VLAN oplossing ook een DMZ LAN oplossing alleen dan op 1 fysieke switch.

[Verwijderd]

Retonator schreef op woensdag 4 januari 2017 @ 21:20:
[...]
Volgens mij is jou VLAN oplossing ook een DMZ LAN oplossing alleen dan op 1 fysieke switch.

Hehe, als je het zo bekijkt ;P Ja... Maar je hoeft toch alleen de lan server op 1 poort van de switch aan te sluiten, en op deze poort de vlan tagged van de 'dmz' gedeelte van de switch...

[donny007]

Optie 4: Maak een derde subnet aan voor de fileserver, maak dit subnet beperkt toegankelijk vanaf de LAN zijde (sta alleen toe dat verbindingen vanuit de LAN zijde náár de fileserver kunnen worden opgezet, en niet andersom). Laat vanuit de DMZ alleen NFS-verkeer toe naar de fileserver.

Voorbeeld:
LAN: 192.168.1.0/24
DMZ: 10.0.0.0/24 (cloudserver: 10.0.0.10)
Servernet: 172.16.0.0/24 (fileserver: 172.16.0.10)

Pseudo firewall:
192.168.1.0/24 mag verbinding maken met 172.16.0.10 op alle poorten waarop een service draait
10.0.0.10 mag verbinding maken met 172.16.0.10 op de poorten voor NFS
drop verder alles van 10.0.0.0/24 en 172.16.0.0/24

Mocht de cloudserver worden gecompromitteerd dan heeft de aanvaller nog maar beperkte toegang tot de fileserver.

In het onwaarschijnlijke geval dat ook de fileserver wordt gecompromitteerd via de NFS-service kan de aanvaller nog steeds niet (direct) verbindingen opzetten met de LAN-clients. De aanvaller kan op dat moment wel LAN-clients proberen te infecteren die verbinding maken met de fileserver, maar dan praten we al over een zéér gerichte aanval op een niveau waarbij een simpele firewall niet veel gaat helpen.

[Retonator]

donny007 schreef op woensdag 4 januari 2017 @ 22:25:
Optie 4: Maak een derde subnet aan voor de fileserver, maak dit subnet beperkt toegankelijk vanaf de LAN zijde (sta alleen toe dat verbindingen vanuit de LAN zijde náár de fileserver kunnen worden opgezet, en niet andersom). Laat vanuit de DMZ alleen NFS-verkeer toe naar de fileserver.

Voorbeeld:
LAN: 192.168.1.0/24
DMZ: 10.0.0.0/24 (cloudserver: 10.0.0.10)
Servernet: 172.16.0.0/24 (fileserver: 172.16.0.10)

Hele mooie oplossing. Hoe zie je dit voor je op mijn hardware met nog maar 2 poorten voor 3 subnetten? Ik kan natuurlijk 2 vlans trunken

[donny007]

Trunken is een prima oplossing.

Gebruik één poort op de Edgerouter voor alle LAN-clients, en één poort voor de DMZ/fileserver trunk. In theorie kun je dan gewoon (duplex) gigabit snelheden tussen de fileserver en LAN-clients halen.

Ik heb zelf geen ervaring met Ubiquiti routers, advies over de exacte configuratie kan ik je niet geven.

Edit: Zoiets dus:



Uiteraard kun je de adressering geheel naar wens aanpassen...

[ Voor 17% gewijzigd door donny007 op 05-01-2017 00:05 ]

[Retonator]

Bedankt Donny dit ziet er uit als een prima setup.

[Brahiewahiewa]

donny007 schreef op woensdag 4 januari 2017 @ 23:37:
... Zoiets dus:...

Kwenie hoor: nu hanteer je feitelijk twee DMZ's, die je mbv vlan's configureert op één router.
Uit het oogpunt van veiligheid (daar is die DMZ voor bedoeld, neem ik aan) wil je eigenlijk twee devices. Als nu je router lekt, ligt meteen je DMZ én je LAN open

[Frogmen]

Waarom wil je een DMZ als je eigenlijk alleen poort 443 (https naar Nextcloud) open wilt zetten? Gebruik gewoon een simpele port forward naar die server. Anders ga je altijd meer lekken creeeren dan dat je ziet, of je moet een tweede firewall gaan gebruiken maar waarom zou je dat doen?
Je wilt je Nextcloud toegang geven tot je fileserver daar gaat het dus mis. Je bent duidelijk een beginner hou het eerst simpel gewoon een enkele server met je Nextcloud erop en een port forward om deze vanaf internet te bereiken. Zet er ook nog een firewall en IDS op en klaar ben je. Begin eerst een met een simpel OS als ClearOS is gebaseerd op CentOS maar voor een beginner goed te doen en zit goed in elkaar. Rechten structuren zijn anders altijd lastig.

[Retonator]

Frogmen schreef op donderdag 5 januari 2017 @ 10:27:
Waarom wil je een DMZ als je eigenlijk alleen poort 443 (https naar Nextcloud) open wilt zetten? Gebruik gewoon een simpele port forward naar die server.

Dit lijkt me een vrij onveilige oplossing. Daarmee plaats ik de cloud server direct in mijn lan. Mocht er dan een exploit zitten in apache,PHP of nextcloud(meest waarschijnlijk). Dan kun je direct het kan op. Tuurlijk kan je lokaal een firewall opzetten die dit onmogelijk maakt maar dan ben je dus 1 privelage escalation verwijderd van mijn lan.

Ik wil graag met de cloud server bij mij fileserver omdat ik bestanden die ik deel via de cloudserver ook graag overal beschikbaar heb in mijn lan.

Maar misschien is less wel more.

[Frogmen]

En daarmee ben je dus net zo onveilig bezig als met mijn oplossing, uiteindelijk kunnen ze dus bij al je bestanden. Overigens bedenk ook wel dat hoeveel moeite doet een hacker voor wat. Een gevangenis straf riskeren voor je vakantie foto's ! Denk het niet. Moeite en te behalen winst zijn altijd in verhouding. Ik draai al jaren een webserver etc op een volgens jouw zeer gevaarlijke manier maar nooit problemen gehad. Overigens draai je ook IDS voor het tegengaan van dat soort aanvallen.

[Verwijderd]

Optie 3b

Installeer alles op één server maar gevirtualiseerd onder ESXi
Maak verschillende vswitches voor WAN, LAN en DMZ en routeer via een pfSense VM. Al deze software is gratis beschikbaar.

Stop elke zone in een aparte vlan en routeer de netwerken volgens de best practices, bv. 1 poort wordt geforward naar DMZ, DMZ kan niet naar LAN maar LAN kan wel naar DMZ.
Zorg dat je management netwerk/vmkernel niet bereikbaar zijn is de WAN vswitch e.d.

Op die manier ga je slechts één host nodig hebben en hoef je je router niet te overdimensioneren om bv. snort genoeg resources te geven, want dit is nog steeds een single threaded proces. Snort is trouwens een package voor pfSense.

Just my 2 cents.

[ Voor 3% gewijzigd door Verwijderd op 05-01-2017 20:00 ]

[donny007]

Frogmen schreef op donderdag 5 januari 2017 @ 10:27:
Waarom wil je een DMZ als je eigenlijk alleen poort 443 (https naar Nextcloud) open wilt zetten? Gebruik gewoon een simpele port forward naar die server. Anders ga je altijd meer lekken creeeren dan dat je ziet, of je moet een tweede firewall gaan gebruiken maar waarom zou je dat doen?

Je wilt je Nextcloud toegang geven tot je fileserver daar gaat het dus mis. Je bent duidelijk een beginner hou het eerst simpel gewoon een enkele server met je Nextcloud erop en een port forward om deze vanaf internet te bereiken. Zet er ook nog een firewall en IDS op en klaar ben je. Begin eerst een met een simpel OS als ClearOS is gebaseerd op CentOS maar voor een beginner goed te doen en zit goed in elkaar. Rechten structuren zijn anders altijd lastig.

De setup die ik aandroeg heeft daarom ook géén volledige exposed DMZ. "DMZ" is in dit geval alleen de benaming van het subnet waarin hosts worden geplaatst die enige toegang hebben vanaf het internet (en dat kan prima alleen poort 443 zijn).

Het doel van die setup is containment. Mocht een aanvaller de cloudserver volledig in handen weten te krijgen heeft deze zéér beperkte toegang tot het netwerk. Als alles goed is geconfigureerd wordt de toegang beperkt tot wat NFS-shares die voor de cloudserver van toepassing zijn.

In het zéér uitzonderlijke geval dat de aanvaller ondanks de zéér beperkte toegang toch de fileserver over weet te nemen, dan heeft deze nog steeds geen directe toegang tot de LAN-clients.

---

De Edgerouter van TS kan prima dienst doen als firewall tussen de verschillende netwerken, een tweede firewall is niet nodig. Wel is het verstandig om ook op de poorten van de servers firewalling toe te passen.

Met een paar simpele firewallregels kan TS zijn netwerk segmenteren en afschermen voor het gros van de "gelegenheidshackers". TS kan eventueel nog een trigger-regel aan de firewall toevoegen die alle communicatie dropt zodra er één pakketje van de cloudserver richting een "verkeerde" poort gaat.

TS kan ook nóg een stapje verder gaan: de Edgerouter kan ingezet worden als VPN-server om zo een extra authenticatielaag toe te voegen. Natuurlijk moet de CPU in de ERL dat ook maar allemaal aankunnen om een fatsoenlijke snelheden te behalen.

Ook met de VPN-tunnel is het onverstandig om de clients zomaar in het LAN-subnet te dumpen. Mochten de authenticatiegegevens zijn gecompromitteerd moet de toegang nog steeds beperkt zijn tot de cloudserver.

---

Om een IDS goed en effectief te configureren is een studie apart. Alleen op een IDS/IPS oplossing vertrouwen is bovendien erg naïef.

Een IDS/IPS oplossing kan ook nooit effectief werken zonder dat de rest van het netwerk goed is ingericht.

---

Om het simpel te houden kan TS zijn Edgerouter gebruiken. Een hele ESXi-omgeving optuigen lijkt me wat overkill voor deze setup.

[ Voor 4% gewijzigd door donny007 op 05-01-2017 22:45 ]

[Frogmen]

Hmm puur een edgerouter x hiervoor gebruiken kan wel maar zijn firewall capaciteit is niet zo heel erg groot. Uit ervaring bij een bedrijf kan ik zeggen dat deze toch wat snel over de rooie ging (lees hij stopte ermee).
Toch blijft het naar mijn idee onnodig complex want als je Nextcloud server gehackt is kunnen ze bij al je bestanden volgens mij daarmee ook bij je belangrijkste assets in je netwerk. Waarschijnlijk hebben ze op dat moment ook je Edgerouter gehackt want hoe komen ze anders bij je Nextcloud server? Oeps.
Vollgens mij is het hele idee van een DMZ om een scheiding te maken zoals je ook wilt maar deze ook seperaat te beschermen.

[donny007]

Frogmen schreef op vrijdag 6 januari 2017 @ 10:08:
Toch blijft het naar mijn idee onnodig complex want als je Nextcloud server gehackt is kunnen ze bij al je bestanden volgens mij daarmee ook bij je belangrijkste assets in je netwerk.

Dat ligt er maar net aan hoe TS het inricht en waar hij de Nextcloud server voor gaat gebruiken.

Als hij inderdaad heel zijn root deelt zonder extra autorisaties heeft de scheiding weinig zin

Frogmen schreef op vrijdag 6 januari 2017 @ 10:08:
Waarschijnlijk hebben ze op dat moment ook je Edgerouter gehackt want hoe komen ze anders bij je Nextcloud server?

Uiteraard zal TS de managementinterface (en andere servicepoorten) van de Edgerouter alleen beschikbaar moeten maken vanuit zijn LAN.

Mits goed geconfigureerd is de Edgerouter voor de aanvaller een black box waar hij in eerste instantie niets mee kan.

Nextcloud staat open voor de buitenwereld op poort 443. De kans dat een kwetsbaarheid in Nextcloud wordt misbruikt is vele malen groter dan dat de Edgerouter zelf het doelwit wordt.

---

Natuurlijk is het beter om met meerdere firewalls/routers op verschillende niveaus te werken, maar voor een thuisnetwerk is deze scheiding meer dan voldoende.

Zelf heb ik een soortgelijke setup draaien op een Mikrotik uit dezelfde prijsklasse (RB750Gr3), de performance daarvan is prima. Volgens de marketingpraat van Ubiquiti moet de Edgerouter Lite snel genoeg zijn voor deze setup.

[Retonator]

De bedoeling van de cloud server is nooit geweest om alle bestanden te delen. Ik zal selectief wat bestanden delen die handig zijn om ook buiten mijn netwerk te hebben.

Het hacken van nextcloud betekent zeker niet dat de router ook gehackt moet worden een bug in de PHP van nextcloud is genoeg (zie de recent bug in phpmailer).

De dmz setup was altijd bedoeld als segmentatie.

Na wat gesprekken met een collega is er nog een mogelijkheid. Namelijk helemaal niets openzetten naar mijn thuis netwerk, maar bijvoorbeeld een nextcloud instance opzetten op digitalocean en dan een synchronisatie maken die geïnitieerd wordt vanuit mijn thuis server. Op deze manier blijft alles vanaf het internet naar mijn netwerk en local(de edgerouter) helemaal dicht. Misschien 1 portmap voor een ssh verbinding. Wat ook nog kan is een ipsec tunnel aangezien de edgerouter hier hardware offloading voor heeft.

[Frogmen]

Tja dat kan ook, persoonlijk denk dat het risico van inbraak en diefstal van je servers groter is dan van een hack met een nog niet gedichte php kwetsbaarheid in NextCloud. Soms is het ook kansberekenen en kans voor dit soort hacks is niet zo groot. Er zijn tenslotte interessantere doelwitten, uiteindelijk gaat het een hacker ook om winst of exposure (bekendheid in de communitie) en laten we wel zijn beiden haal je niet bij een particulier.
PS waarom zo moeilijk als je een office 365 abbo neemt krijg 1 TB opslag in de cloud die je ook met https kan bereiken. Ben je meteen klaar.

[ Voor 13% gewijzigd door Frogmen op 06-01-2017 14:00 ]

[Retonator]

Frogmen schreef op vrijdag 6 januari 2017 @ 13:58:
PS waarom zo moeilijk als je een office 365 abbo neemt krijg 1 TB opslag in de cloud die je ook met https kan bereiken. Ben je meteen klaar.

Ik ben ook niet bang voor getargete hacks maar meer voor botnet scans etc.

En waarom ik geen office365 neem. Omdat het ook een stukje hobby is. Dus het is ook gewoon leuk om een dergelijke setup op te zetten. Dus het hoeft niet alleen praktisch te zijn.

[Frogmen]

Oke duidelijk, omdat het kan is het allerbeste argument om toch voor de onnodig complexe optie te gaan. Simpelweg omdat het kan en ter lering en vermaak. Of gewoon omdat je een Tweaker bent. Met de Edgerouter kan je dat prima inregelen hiervoor hoef je nog niet eens met Vlans te werken maar gewoon op basis van poorten en forwards. Vervolgens alleen de poort tussen de netwerken openzetten die nodig is, rest in de firewall dicht. Succes