Opzetten thuisservers. Mail/owncloud/webserver

[nike]

Hoi,
Ik ben de laatste tijd nogal aan het dubben hoe ik de opzet van mijn thuisnetwerk beter kan maken.
Hoe heb ik het nu ingericht:

1xpc met daar op Debian jessie 8.0 en KVM.
Hierop draaien de volgende VM'S:

pfsense:
Deze krijgt direct het ip adres van de kabelmodem (staat in bridge).
Hierop draaid squid,snort,.

Webserver1: Owncloud,FTP server, Interne WWW server (buienradar,stats)
deze website heb ik een proxie gemaakt naar Webserver2.
Domain=www.voorbeeld.nl

Webserver2:Mailserver,Roundcube,postfix, met het subdomain.
Hierop is ook active sync (exchange) z-push mail
SubDomain=mail.voorbeeld.nl

Wat gaat er niet goed:
Als vrienden/familie de mail willen bekijken gaan ze naar mail.voorbeeld.nl
Dat werkt, maar eigelijk gaan ze altijd door de proxie van webserver1 heen.
Ik denk ook niet dat het echt veilig is op deze manier.

Is het raadzaam om hiervoor 1 server te maken waarom alles in zit?
Ik heb nog geprobeert om met reverse proxy te spelen op pfsense, maar ik kreeg dat met httpS niet lekker voor elkaar. nu komt alles wel goed door met SSL labs.

Als mail server was ik ook aan het spelen met mailinabox, het nadeel daarvan is dat je zelf niet veel kan tweaken, na een update is alles weer terug bij af.

Of beter gewoon van scratch af aan beginnen.
Hoe hebben de mede tweakers het ingericht?

[CyBeR]

nike schreef op zondag 21 februari 2016 @ 12:04:
Als vrienden/familie de mail willen bekijken gaan ze naar mail.voorbeeld.nl
Dat werkt, maar eigelijk gaan ze altijd door de proxie van webserver1 heen.
Ik denk ook niet dat het echt veilig is op deze manier.

Iets minder dan 't direct aan 't internet hangen maar daar heb je vermoedelijk de mogelijkheid niet toe.

Is het raadzaam om hiervoor 1 server te maken waarom alles in zit?

Nee. Dit soort dingen scheiden is juist handig. Zowel omdat 't makkelijker opnieuw op te zetten danwel upgraden is, als omdat je de scope van security bugs nu enigszins limiteert. (Een bug in owncloud heeft geen gevolgen voor je mail en vice versa.)

Ik heb nog geprobeert om met reverse proxy te spelen op pfsense, maar ik kreeg dat met httpS niet lekker voor elkaar. nu komt alles wel goed door met SSL labs.

Een reverse proxy is wel het goede idee. Alleen zou ik je aanraden om er HAProxy voor te gebruiken ipv squid. Als je dat op je pfsense kunt krijgen: mooi. Anders kun je daar een extra (kleine) VM voor maken. Dan laat je zowel je owncloud als mailverkeer daardoorheen lopen. HAProxy kan ook goed met TLS overweg.

Als mail server was ik ook aan het spelen met mailinabox, het nadeel daarvan is dat je zelf niet veel kan tweaken, na een update is alles weer terug bij af.

Ik ken die oplossing niet specifiek, maar dat is typisch gezien wel hoe dat werkt ja. Je moet niet tweaken in dat soort systemen omdat ze juist gemaakt zijn om een turn-key oplossing te bieden. Vaak zijn er wel customisation-mogelijkheden overigens die wel bewaard blijven.

Hoe hebben de mede tweakers het ingericht?

Ik heb een SmartOS server in een colo hangen met meer dan genoeg IP-adressen beschimbaar om geen proxies te hoeven gebruiken. En ik scheid ook m'n mail (dovecot) en webmail (roundcube) in aparte containers, met dus elk een eigen IP-adres.

Zie daarover ook dit topic: Tweakers die hun eigen mail hosten?

[nike]

Bedankt voor je toelichting CyBeR, ik ben weer wat wijzer.
Voor mijn situatie inderdaad meerdere VM's aanhouden en via haproxy proberen alles benaderbaar te maken.

[Ultraman]

nike schreef op zondag 21 februari 2016 @ 12:04:
Hoe hebben de mede tweakers het ingericht?

FreeBSD met jails.
Elke dienst zit in eigen jail met een herkenbare naam.

Qua IP adressen heeft elke jail zijn eigen IPv6. IPv4 gaat door middel van NAT en port forward voor de betreffende dienst.

Zo je diensten scheiden geeft overzicht en maakt zoals CyBeR ook al aangaf het makkelijker met het uitvoeren van onderhoud. En mocht er een keer wat mis gaan, dan kan ik altijd een jail plat gooien en het uitzoeken. Dat geldt voor VM onder KVM net zo.

HAproxy kan in jouw geval inderdaad een leuke zijn. Goede tip daar.

[ Voor 5% gewijzigd door Ultraman op 23-02-2016 19:27 ]

[CyBeR]

Ultraman schreef op dinsdag 23 februari 2016 @ 19:27:
[...]
HAproxy kan in jouw geval inderdaad een leuke zijn. Goede tip daar.

Ik gebruik HAProxy tegenwoordig zelfs waar ik op zich geen proxy nodig heb (dwz, dan proxy ik naar localhost). Voornamelijk omdat 't enorme hoeveelheden clients aankan en SSL offloading heel simpel maakt. In veel apps is de goede instellingen krijgen om SSL veilig te maken nog best lastig, terwijl dat in HAproxy uitermate simpel is. Plus, dan hoeft de betreffende service zelf niet als root te draaien.

[nike]

Ik zit me al behoorlijk in te lezen in de HAproxy, maar kom er nog niet hellemaal uit.
De bedoeling is volgens mij dat je 1 fronted en en back server heb voor 1 webserver. en in de fronted stel je je sub domain in naar de backserver...

[CyBeR]

nike schreef op woensdag 24 februari 2016 @ 19:01:
Ik zit me al behoorlijk in te lezen in de HAproxy, maar kom er nog niet hellemaal uit.
De bedoeling is volgens mij dat je 1 fronted en en back server heb voor 1 webserver. en in de fronted stel je je sub domain in naar de backserver...

Frontends en backends zijn concepten binnen HAProxy.

Een frontend is waar HAProxy een poort opent en wacht tot een client een verbinding opzet.

Een backend is waar de data van die client (dwz, de request in http mode) heen geproxiet wordt.

Bijvoorbeeld een uittreksel van een van mijn configs:

frontend webmail-http
        bind *:80
        bind *:443 ssl crt /srv/ssl
        bind :::80
        bind :::443 ssl crt /srv/ssl
        mode http
        default_backend nginx
        log global
        redirect scheme https if !{ ssl_fc }
        capture request header  Host len 63
        http-response set-header Strict-Transport-Security  max-age=31536000

backend nginx
        server local 127.0.0.1:8080 send-proxy

Daarin zeg ik tegen haproxy dat 'ie moet listenen op poorten 80 en 443 (voor IPv4 en IPv6). Vervolgens moet 'ie alle requests die niet via SSL komen redirecten naar https, de Host header in de log knikkeren en een HSTS header naar de client sturen. Verder alle requests doorproxy'en naar nginx die op localhost:8080 draait. (send-proxy houdt in dat er een speciaal protocol gebruikt wordt waardoor nginx weet wat 't client adres is; dat kan alleen als de achterliggende service dat ondersteunt en daarvoor geconfigureerd is.)

Dit is met een enkele backend. Voor een switch tussen backends aan de hand van een header gebruik je een ACL. Je geeft dan meerdere backends op zoals hierboven en een acl in de frontend als volgt:

frontend webmail-http
    (de rest van al die dingen zie boven)
    acl site_1 hdr_dom(host) -i site_1.nl
    acl site_2 hdr_dom(host) -i site_2.nl
    use_backend nginx1 if site_1
    use_backend nginx2 if site_2

Je kunt overigens ook alleen op site_1 selecteren en naar nginx1 sturen, en met default_backend alle andere shit naar nginx2 sturen. De mogelijkheden zijn redelijk eindeloos in dat opzicht.

[nike]

Via mijn router pfsense haproxy geïnstalleerd.
Heb het nu een beetje werken.
Hoofd fronted is www.voorbeeld.nl en ik kan nu ook naar mailvoorbeeld.nl.

Echter nu had ik op mail.voorbeeld.nl wat pagina.s afgeschermd dat je die alleen kan zien als je op het lan netwerk ziet. Als ik nu de logfiles bekijk zie ik dat haproxy intern doorzet naar mail.voorbeeld.nl dus die call komt vanuit intern netwerk. alles lijkt nu vanaf intern netwerk te komen.

Certificaten heb ik nu redelijk werkend maar daar kom ik denk ik wel uit. Certificaten in pfsense gezet in in haproxy geselecteerd. Nog even goed instellen.
Wel lastig als je aparte servers wil met subdomain.

[CyBeR]

nike schreef op vrijdag 04 maart 2016 @ 22:57:
Echter nu had ik op mail.voorbeeld.nl wat pagina.s afgeschermd dat je die alleen kan zien als je op het lan netwerk ziet. Als ik nu de logfiles bekijk zie ik dat haproxy intern doorzet naar mail.voorbeeld.nl dus die call komt vanuit intern netwerk. alles lijkt nu vanaf intern netwerk te komen.

Dat klopt, en dat kun je op twee manieren fixen: 1) je doet die access control in haproxy middels acl's. 2) Je geeft het echte client IP door aan je backend server en laat die daarop filteren.

Dat laatste kun je ook weer op twee manieren doen, afhankelijk van wat de webserver is: je kunt een X-Forwarded-For header doorsturen en daar wat mee doen (Apache kan die gebruiken met een bepaalde module) of je gebruikt het proxy protocol (kan nginx wel wat mee.)

[nike]

Cyber bedankt voor je adviezen.
Ik heb alles werkend via mijn pfsense router.
Hierin draaid haproxy en erachter heb ik 2x webservers met elk hun eigen certificaat.

Via haproxy ssl offload. Bij ssl labs heb ik alle 2 een A+
Tevens heb ik de x-forward-for werkend zodat de echte ip adressen op de webserver komen waarbij ik dan weer de acl's kan maken.

[Yarisken]

Beetje een noop vraag maar waarom doe je ssl ofloading op je proxy en niet op de webservers zelf ? Dan heb je geen decryption nodig en dat scheelt toch in cpu op de proxy ?

[CyBeR]

Yarisken schreef op donderdag 10 maart 2016 @ 23:20:
Beetje een noop vraag maar waarom doe je ssl ofloading op je proxy en niet op de webservers zelf ? Dan heb je geen decryption nodig en dat scheelt toch in cpu op de proxy ?

SSL offloading is voornamelijk fijner omdat:
* je ten eerste minder moeite hoeft te doen om je keys te distribueren; je hebt één (of twee bij failover) centraal punt waar al je certs en keys staan en dus één centraal punt om te beveiligen wat dat betreft.
* je CPU op je web servers dan niet aan 't gebruiken bent voor crypto maar voor je app (terwijl je proxy quasi niks staat te doen; proxy'en is heel simpel werk)
* je minder moeite hoeft te doen om SSL session resumption te ondersteunen (wat een shared cache nodig zou hebben om 't te verdelen over meerdere servers)
* je 't eventueel in hardware kunt doen (met een ssl offloading load balancer apparaat ipv gewoon haproxy op een server)

[Yarisken]

CyBeR schreef op vrijdag 11 maart 2016 @ 00:00:
[...]


SSL offloading is voornamelijk fijner omdat:
* je ten eerste minder moeite hoeft te doen om je keys te distribueren; je hebt één (of twee bij failover) centraal punt waar al je certs en keys staan en dus één centraal punt om te beveiligen wat dat betreft.
* je CPU op je web servers dan niet aan 't gebruiken bent voor crypto maar voor je app (terwijl je proxy quasi niks staat te doen; proxy'en is heel simpel werk)
* je minder moeite hoeft te doen om SSL session resumption te ondersteunen (wat een shared cache nodig zou hebben om 't te verdelen over meerdere servers)
* je 't eventueel in hardware kunt doen (met een ssl offloading load balancer apparaat ipv gewoon haproxy op een server)

Ik begrijp het nu. Ik was wat verward met ssl decryptie. Da's wel cpu intensief omdat je terug de pakketten moet encrypten in één ruk. Offloading is gewoon ssl eraf halen en doorsturen en als het pakket terugkomt ssl terug eropzetten. Thx voor de info. Heel interessant om te bekijken, zeker nu met let's encrypt :-).