1. #1
    Avatar von DotNet
    Registriert seit
    10.06.2015
    Beiträge
    661
    Thanked 316 Times in 185 Posts

    Standard Heimserver in getrenntem Netz hinter WAN Reverse Proxy absichern

    Hallo, ich habe einen kleinen virtuellen Server und möchte diesen als Reverse Proxy für bestimmte Dienste meines Heimservers nutzen. Ein Beispiel: Owncloud läuft auf meinem Server zuhause. Der externe Server soll auf meinen Heimserver zugreifen, und diesen Dienst anbieten: User <--> Externer vServer <--> Heimserver

    Für die Verbindung zwischen externem Server und Heimserver scheint ein VPN geeignet zu sein. Ich denke das sollte auch mit der Geschwindigkeit klappen, sodass die gesamte Verbindung für den User nicht zu langsam wird. Das Problem sehe ich in der Sicherheit: Der Heimserver hat ja einen physischen Netzwerkadapter für mein Heimnetz, plus einen virtuellen Adapter vom VPN-Client. Damit wäre ein Zugriff auf mein Heimnetz theoretisch möglich, wenn z.B. ein Dienst auf dem Heimserver eine Lücke aufweist.

    Wie kann ich das am besten Abschotten? Ich denke um verschiedene Netzwerke werde ich nicht herumkommen um zu verhindern, dass eine Software auf dem Heimserver in mein gesamtes Netzwerk kommt. Die Frage ist nur, wie ich das am sinnvollsten mache, sodass die gewollte Kommunikation noch funktioniert, aber im Falle eines Sicherheitslecks nicht mein gesamtes Netzwerk kompromittiert wird.

    Mein momentaner Gedanke sieht wie folgt aus:
    Wir gehen davon aus, der Heimserver ist in meinem Heimnetzwerk 192.168.178.0/24 und bekommt dort eine IP vom Router. Auf dem Server erstelle ich z.B. mit Docker ein virtuelles Netz 172.0.0.0/24. In diesem Netz befinden sich nur Container, auf die der externe Server zugreifen können soll. Beispielsweise 172.0.0.2 für den Owncloud Server. Im gleichen Netz muss natürlich auch der VPN-Client sein, der vom externen Server eine IP 10.0.0.4 bekommt (10.0.0.0/24 Netz).

    Bildlich wäre der Ablauf folgender:

    Ext. Server <--> VPN-Client Heimserver: 10.0.0.4 <--> Owncloud Container: 172.0.0.2

    Sehe ich es richtig, dass übers VPN vom externen Server damit kein Zugriff auf mein Heimnetz möglich wäre, weil weder VPN-Client noch Owncloud einen Netzwerkadapter im 192.168.178.0/24 Netz haben?
    Wie müssten die Standardgateways konkret aussehen? Das scheint mir der Schlüssel zu sein. Wenn ich beim Owncloud Container mit 172.0.0.2 als Gateway 192.168.178.1 eintrage, dürfte das ganze ja schon nicht mehr funktionieren, weil dann ein Routing in mein Heimnetz stattfinden müsste, oder? (Genau das will ich nicht, die Frage dient nur zum Verständnis, scheint ja doch komplizierter zu sein das Thema).

    Ziel sollte in diesem Beispiel sein: Über den externen Server kommt man auf alle Container/VMs/Was auch immer im 172.0.0.0/24 Netz. Aber man kommt darüber hinaus nicht aufs interne Netzwerk hinter dem Router (192.168.178.0/24). Dies ist mir wichtig, da ich z.B. auch Smart Home Geräte intern betreibe, die nicht direkt übers Internet erreichbar sein sollen.

    Im Krieg gibt es keine Gewinner, nur Verlierer!

  2. #2

    Registriert seit
    10.05.2015
    Beiträge
    22
    Thanked 7 Times in 6 Posts

    Standard AW: Heimserver in getrenntem Netz hinter WAN Reverse Proxy absichern

    Einfacher und sicherer wäre es, beides zuhause laufen zu lassen. Dabei wird der Heimserver mit 2 physischen NICs ausgestattet und ein Type-1 Hypervisor installiert, ich persönliche nutze ESXi 6.5
    Zuvor wurden bereits viele vom Type-2 ausprobiert von Hyper-V bis hin zu Virtual Box, dort ist aber die Netzwerk Performance deutlich geringer, also nichts für den Betrieb in einem "richtigem" Netzwerk. Die sind mehr zum rumspielen.

    Wie dem auch sei, man erstellt nun zwei 2x vSwitch auf dem ESXi Server. Der eine vSwitch kommt an den WAN NIC, welcher mit dem Internet verbunden ist. Der zweite vSwitch wird mit dem internen LAN verbunden. Nun setzt man z.B. eine Firewall Software ein, ich hatte mich für opnsense entschieden, da es deutlich professioneller als gar IPFire ist.

    Mithilfe von opnsense wird nun das WAN Netzwerk gefiltert und der Traffic wird daraufhin ans LAN weitergegeben. Das LAN Netzwerk hat bei opnsense Zugriff auf das WAN. Das WAN allerdings nicht auf das LAN Netzwerk. Genau das ist ja hier auch gewünscht. Daraufhin nicht vergessen das "ESXi Management Netzwork" vom WAN vSwitch zu trennen, ansonsten ist der VM-Hauptserver dort noch erreichbar.



    Ansonsten funktioniert das ganze aber auch mit 2 physikalischen Servern dabei muss die Firewall natürlich 2 NICs haben. Der kleine Server(e.g. firewall) läuft dabei mit z.B. opnsense (ohne vm oder so), nimmt das WAN auf und gibt LAN dann auf einen physikalischen Switch oder gar AP, welcher mit Hauptserver und Geräten verbunden ist.



    Deine Lösung hat die Nachteile das es im Hypervisor des vServer selbst, im darauf laufenden Betriebsystem sowie in der VPN Software zu "bugs" kommen könnte. Desweiteren weiß man leider nie, wie genau die Infrastruktur des Netzwerks vom Hosting Betreiber des vServers aussieht. Man muss da immer auf andere vertrauen. Das finde ich, ist das gefährlichste.

    Mein erster Ansatz hat den Nachteil, das es im Type-1 Hypervisor sowie im Betriebssystem (Firewall) zu "bugs" kommen könnte. Ich finde aber ESXi macht dort einen guten Job. https://esxi-patches.v-front.de/ESXi-6.5.0.html

    Beim zweiten Ansatz gibt es nur noch die einen Nachteil, das es im Betriebsystem der Firewall zu bugs kommen könnte. Dies ist natürlich die kostspieligste, aber auch die sicherste Methode.

Ähnliche Themen

  1. Antworten: 3
    Letzter Beitrag: 14.06.2016, 20:06
  2. IIs 8.5 PHP isolieren und absichern
    Von Gameboy9 im Forum Server-Administration
    Antworten: 0
    Letzter Beitrag: 01.07.2014, 14:38
  3. Webspace absichern
    Von MHRCube im Forum Hosting
    Antworten: 15
    Letzter Beitrag: 21.02.2013, 23:23
  4. [HowTo] Nginx as reverse Proxy
    Von Ta1lor im Forum Server-Administration
    Antworten: 0
    Letzter Beitrag: 04.02.2012, 15:07
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.