Replicatie Linux web server (database en www folder)

[Gijs007]

Beste medetweakers,

Ik ben van plan om een Linux server te repliceren, op dit moment draait er een Ubuntu 15.04 virtuele machine in Hyper-V met een MariaDB database, Apache 2.4 en PHP 5.6 in FPM/fastcgi.

De bedoeling is dat ik een kopie van de virtuele machine maak en deze op een tweede server laat draaien.
Het is dan de bedoeling dat de database gerepliceerd wordt tussen beide virtuele machines en dat de /var/www directory gerepliceerd wordt tussen beide virtuele machines.

De servers zullen een relatief grootte latency hebben (80-120 ms) aangezien een van de servers in Europa zal staan en de andere in Noord Amerika.
Via Amazon Route 53 zal het verkeer gerouteerd worden naar de dichts bijzijnde locatie (indien die niet down is)

De verbinding tussen de servers loopt via internet, en ik wil dit dan ook graag beveiligd hebben om email adressen en NAW gegevens en dergelijke in de database te beschermen.
Ik heb de volgende opties overwogen:

• openvpn
• SSH tunnel
• SSL (TLS)

1. Mijn vraag is welke optie het veiligst, betrouwbaarst en snelst is (hervatten van verbinding, doorvoer snelheid en latency) voor bovenstaande toepassing, gemak in onderhoud is overigens ook prettig

Ik kan een SSH tunnel opzetten voor het repliceren van de database server en door middel van een applicatie of script kan de /var/www folder gerepliceerd worden.

Een andere mogelijkheid is om de database replicatie via SSL te beveiligen en de SSH tunnel alleen te gebruiken voor de replicatie van de bestanden en folders in /var/www
Het nadeel hiervan is dat er certificaten aanmoeten worden gemaakt die kunnen verlopen en die geld kosten. Niet het geval als ik gebruik maak van: https://letsencrypt.org/

De laatste mogelijkheid is om een VPN op te zetten, bijvoorbeeld door middel van openvpn.
Maar ook hierbij moeten certificaten worden aangemaakt. Daarnaast heb ik geen ervaring met het gebruik van openvpn als "extra" netwerk zonder dat al het verkeer hier over wordt verstuurd.

2. Wat kan ik het beste gebruiken om de bestanden tussen beide virtuele machines gelijk te houden?

3. Eventueel wil ik later nog extra virtuele machines toe kunnen voegen, indien mogelijk ook Windows Servers.

[CAPSLOCK2000]

Je kan SSL-certificaten voor eigen gebruik gewoon zelf aanmaken. Een certificaat kopen is alleen nodig als een willekeurige vreemde de echtheid moet kunnen controleren. Geldigheidsduur is ook niet echt interessant in dit geval, je kan je eigen certificaten 1000 jaar geldig maken (of de leeftijd volledig negeren).

OpenVPN werkt ook zonder certicaten door bv een wachtwoord te gebruiken, voor twee systemen onder eigen beheer is dat een prima oplossing. OpenVPN als "extra" netwerk is totaal niet spannend. Gewoon geen default gateway opgeven en je bent klaar.

Bestanden repliceren gaat het beste met rsync, dat gebruikt zelf SSH om de verbinding te beveiligen.

Ik zou geen SSH-tunnel gebruiken om je database over te synchroniseren omdat het niet makkelijk is om die tunnel automatisch te (her)starten als dat nodig is. Het is niet onmogelijk maar ik zou het niet doen.

Ik zou daar dus OpenVPN gebruiken maar ik zou óók TLS gebruiken. Als er dan een keer iets mis gaat, bv omdat openvpn stuk gaat of je een foutje maakt in de routering, loopt er niet direct unencrypted verkeer via internet.

Beveiliging bouw je in lagen. Hoe meer lagen hoe beter. Waar mogelijk altijd TLS gebruiken, ook als er nog andere beveiligsmiddelen zijn.

[Gijs007]

Maar als ik een private range gebruik voor de adressen van de VPN dan lijkt mij dat het verkeer niet verzonden wordt over het internet als de VPN uitvalt, correct?

Ik heb de zelfde vraag ook op server fault gesteld, https://serverfault.com/q...cating-a-linux-web-server

Daar werd aangeraden om IPSec voor de VPN te gebruiken, wat volgens mij ook sneller is dan openvpn (omdat veel netwerk apparatuur IPSec offloading heeft)

[CAPSLOCK2000]

Gijs007 schreef op donderdag 07 mei 2015 @ 00:17:
Maar als ik een private range gebruik voor de adressen van de VPN dan lijkt mij dat het verkeer niet verzonden wordt over het internet als de VPN uitvalt, correct?

Dat ligt oa aan je router.

Ik heb de zelfde vraag ook op server fault gesteld, https://serverfault.com/q...cating-a-linux-web-server

fijn, dan hebben we dus dubbel werk zitten doen

Daar werd aangeraden om IPSec voor de VPN te gebruiken, wat volgens mij ook sneller is dan openvpn (omdat veel netwerk apparatuur IPSec offloading heeft)

Dat kan ook. Wat jij werkend krijgt. Denk je dat de snelheid een probleem is?

[gertvdijk]

Het nadeel hiervan is dat er certificaten aanmoeten worden gemaakt die kunnen verlopen en die geld kosten. Niet het geval als ik gebruik maak van: https://letsencrypt.org/

Je hoeft helemaal geen publiek trusted certificaten te hebben voor gebruik intern, hoor, voor een VPN. Maak je eigen CA (PKI), bijvoorbeeld met de tool XCA, al moet je wel een beetje verstand hebben van X.509 en wat wel/niet goed is. Die CA geef je op in je OpenVPN config en klaar.

TLS met trusted certificaten doe je alleen voor publieke services, omdat die de authenticiteit van de peer (server) dan via de browser-bundled Root CAs kunnen verifiëren. Voor een interne verbinding geniet het juist de voorkeur om dat niet via een externe partij te doen. Zo heb je alles in de hand en zit je niet met (dure) renewals of het wachten/afhankelijk zijn van een derde partij.

[Gijs007]

CAPSLOCK2000 schreef op donderdag 07 mei 2015 @ 01:53:
[...]

Dat ligt oa aan je router.


[...]

fijn, dan hebben we dus dubbel werk zitten doen


[...]


Dat kan ook. Wat jij werkend krijgt. Denk je dat de snelheid een probleem is?

1. Kan een IP range ook alleen toegelaten worden op een netwerk interface?
2. Nope, want ik wil altijd het probleem van meerdere kanten horen voordat ik een besluit neem
3. Nee, maar efficiënt werken is wel zo verstandig

[Boudewijn]

Je bent dus nu een security oplossing aan het maken terwijl je niet weet waarom je al dan niet een certificaat nodig hebt dat van een officiele CA afkomt. Weet je zeker dat je dit wil?

Ik vind dat eerlijk gezegd best een riskante affaire voor een bedrijf (voor hobby is het prima). Ik ga er gezien je 2 locaties althans vanuit dat je een bedrijf bent.