"Virtuelles" Intranet

  • Hallo,


    da ich in absehbarer Zeit nicht mehr alleine in meinem Unternehmen arbeiten werde, dachte ich mir ist's mal an der Zeit sich über technisch-organisatorisches Gedanken zu machen.

    Derzeit habe ich von verschiedensten Anbietern Software-Hosting "eingekauft" (u.a. Redmine, Bitbucket-Cloud u.ä.). Ich möchte diese Dienste gerne zukünftig "intern" betreiben.


    Damit wäre gemeint, dass ich diese Dienste (ggf. in Docker-Containern) auf vServern hier bei netcup betreiben möchte. Da das Ganze aber "intern" sein soll, würde ich das gerne in einem VPN (mit DNS?) kapseln. Ich und Andere müssten sich dann zum VPN verbinden und könnten dann diese Dienste nutzen. So stelle ich mir das zumindest vor. Ich glaube das ist relativ umfangreich aber generell nicht soooo kompliziert.


    Mein erster Ansatz war es einige vServer in einem tinc-Netzwerk zu einem "VLAN" zusammenzuschlißen und die Listener der Dienste an diese jeweiligen Interfaces zu binden. Dann habe ich auf einem dieser Nodes zusätzlich OpenVPN mit öffentlichem Zugriff installiert ("Entry-Node") und wollte dann quasi die Pakete eines OpenVPN-Users über diesen Entry-Node in das tinc-Netzwerk routen. Das ist jetzt nicht unbedingt mein Spezialgebiet, hat am Ende auch irgendwie geklappt (musste noch sowas wie MASQUERADE in iptables hinzufügen; hat soweit ich das verstanden habe, etwas mit diesem Entry-Point / NAT zu tun.)


    Bevor ich das jetzt weiter verfolge (mit OpenVPN kenne ich mich nicht sonderlich gut aus) wollte ich mal hier nachfragen ob man das so machen kann? :D

    Oder vielleicht hat jemand (Software-)Tipps, die mich bei meinem Vorhaben weiterbringen könnten. Oder vielleicht auch Anmerkungen warum das keine gute Idee sein könnte.


    Mehr konkret wäre jetzt mein nächster Schritt den OpenVPN Clients beizubringen meinen "internen" DNS-Server zu befragen, um interne Dienste zu finden.


    Danke für deine Zeit und viele Grüße

  • OpenVPN und Tinc wollten bei mir ohne Masq nicht zusammen arbeiten. Daher habe ich mein Crossconnect Netz auch als Tinc ausgelegt.

    So kann man natürlich Dienste betreiben.


    Wenn die Dienste abgesichert sind, dann ist das auch über das öffentliche Internet möglich. Ansonsten gibt es die Möglichkeit eines Proxies (Apache / Nginx) der eine Authentifizierung und TLS Terminierung durchführt. Mit Apache geht es sehr einfach gegen ein LDAP Server zu authentifizieren. Mit Nginx bedarf es da etwas mehr Magie.


    Meine internen Dienste sind dennoch im DNS hinterlegt, sowohl mit Global Unicast als auch RFC1918 Adressen.

    Einige DNS Resolver verweigern aber die Annahme von RFC1918 Adressen von öffentlichen DNS Servern - da musst du dann bei den Routern ein wenig aufpassen.

  • Man könnte es im Prinzip mit 2 vServern, 2x vnic und einem eigenen vlan sauber lösen:


    Server 1: VPN Server

    Server 2: Host für die Services.


    Server 2 bekommt sein Public Interface aus der Config entfernt und ist nur noch per privaten vlan erreichbar. Server 1 dient als VPN Gateway und ermöglicht es den VPN Clients auf die Dienste im privaten vlan zuzugreifen und pusht dazu gewisse Routen an die VPN clients.

  • Server 2 bekommt sein Public Interface aus der Config entfernt und ist nur noch per privaten vlan erreichbar.

    Naja sauber ist etwas anderes. Server 2 müsste dann ja über Server 1 ins Internet, dieser muss dann das NAT übernehmen.

    Schließlich will Server 2 ja auch Updates bekommen und dafür nicht ständig das Interface rauf- und runterfahren müssen.

  • Daher habe ich mein Crossconnect Netz auch als Tinc ausgelegt.

    Ist das "Crossconnect-Netz" jenes, welches die (menschlichen) Nutzer mit den anderen Diensten verbindet?

    Wenn ich das richtig verstehe sind also die Nutzer auch einfach als Nodes ("Clients" im herkömmlichen Sinne sind ja alle) im selben tinc-Network wie die Dienste selbst?

    Wie ist das dann lokal beim Nutzer; der hat quasi eine tinc-Config (feste IP?) und das Network ist normal als Dienst eingerichtet?


    Zitat

    Meine internen Dienste sind dennoch im DNS hinterlegt, sowohl mit Global Unicast als auch RFC1918 Adressen.

    Sprich beispielsweise jira.example.org löst auch öffentlich auf 192.168.29.92 auf?

  • Wir haben das bei uns rein mit OpenVPN gelöst. Es gibt einen Core Router und einen "fetten" Server wo VMs drauf laufen, die User verbinden sich per Site2Site VPN ins Netz. Wer das "volle Programm" will, muss in seinem lokalen DNS noch einen override für *.mysecretbusinessdomain.com auf den DNS der auch via OpenVPN erreichbar ist setzen.


    Einen echten DNS inklusive DNSSEC haben wir dabei bisher nicht. Im Prinzip nutzen wir intern einfach einen eigenen DNS der anders auflöst als die "echten" im Internet. Die Domain die hier benutzt wird gibt es aber wirklich.


    Anschließend sind alle bereitgestellten Dienste bei den Usern ganz normal durch geroutet. Läuft so schon seit zirka zwei Jahren. Die Ausfälle kann ich an einer Hand abzählen.


    In Deinem Fall könnte man die Cross-Server Konnektivität mit Tinc lösen, Tinc lässt man dabei auf Layer 2 mit einem privaten IP Netz reden. Im Tinc Verbund muss es dann einen Router geben der OpenVPN und NAT ins Internet macht.

  • Ist das "Crossconnect-Netz" jenes, welches die (menschlichen) Nutzer mit den anderen Diensten verbindet?

    Nein - das Crossconnect Netz stellt eine Layer3 Verbindung zwischen dem Büro Standort und einem Server her. Alle die im Büro am Netz hängen können über den Router also auf den Server und damit auf das Tinc VLAN zugreifen.

    Wenn ich das richtig verstehe sind also die Nutzer auch einfach als Nodes ("Clients" im herkömmlichen Sinne sind ja alle) im selben tinc-Network wie die Dienste selbst?

    Nein. Das habe ich aus Sicherheitsgründen nicht zugelassen.

    172.20.20.0/24 (Büro Standort) <==> 10.8.0.129/25 (Crossconnect) <==> 172.20.25.0/24 (Tinc VLAN)

    Der Büro Router kennt dann die Route in das Tinc VLAN und kann gleichzeitig als Firewall fungieren.

    Hier L2 zu brücken ist absolut nicht zu empfehlen.


    Der Nutzer bekommt davon aber nichts mit, weil die Verwaltung alles im Netz passiert.

    Die Nutzer direkt in das VPN zu verbinden macht nur unterwegs Sinn, aber nicht wenn alle an einem physikalischem Netz hängen.


    Sprich beispielsweise jira.example.org löst auch öffentlich auf 192.168.29.92 auf?

    Genau.

    https://toolbox.googleapps.com/apps/dig/#A/ => cl1.test.h6g-server.net

  • Als VPN schaue dir auch einmal Softether an. Hier hast du mehr Möglichkeiten was VPN Verbindungen betrifft.

    Weniger Möglichkeiten aber mehr Speed gibts mit Wireguard. Es ist leider noch nicht ganz ausgereift, erfährt aber einen gewissen Hype und wird wohl der Quasistandard in Zukunft. Wenn man ein neues System aufsetzt in dem Geschwindigkeit wichtig ist, sollte man sich das vielleicht mal anschauen. Aber das ist hier ja eigentlich eher Offtopic *sorry*


    Naja sauber ist etwas anderes. Server 2 müsste dann ja über Server 1 ins Internet, dieser muss dann das NAT übernehmen.

    Schließlich will Server 2 ja auch Updates bekommen und dafür nicht ständig das Interface rauf- und runterfahren müssen.

    Das Public Interface kann ja auch da bleiben, solange da nichts lauscht. Dann bekommt der Rechner auch noch Updates. Ich könnte mir aber vorstellen, dass man das NAT sowieso will. Man kann ja auf dem Miniserver1 auch einfach ein fertiges Routersystem (OpenWrt, pfSense o..ä.) nehmen, da ist das ja auch einfach erledigt.

  • Die grundsätzliche Frage, die ich hierbei noch aufwerfen würde ist: Wenn die Daten so vertraulich sind, dass sie durch ein VPN (anstelle/zusätzlich von HTTPS) geschützt werden müssen - möchte man solche Dienste dann nicht lieber intern betreiben? Ich selbst hab mir derweil ein Synology NAS gekauft und über Docker einige Dienste wie z. B. GitLab lokal installiert. Klappt absolut problemfrei, sogar mit HTTPS etc. Vorteil: Ich weiß, wo die Daten liegen. Und dass mir der Speicherplatz absehbar nicht ausgeht :D

  • möchte man solche Dienste dann nicht lieber intern betreiben?

    Vermutlich ja, aber ich habe nunmal kein Büro mit guter Internetanbindung und möchte das ehrlich gesagt nicht im Wohnzimmer stehen haben.

    Wie greifst du denn unterwegs drauf zu?


    In meinem Use-Case ist der Regelfall halt dass wir remote und auch oft an unterschiedlichen Orten arbeiten. Deshalb fand ich den Gedanken das hier bei netcup zu haben, nicht so doof.


    Zitat

    Wenn die Daten so vertraulich sind, dass sie durch ein VPN (anstelle/zusätzlich von HTTPS) geschützt werden müssen

    Naja, das bitbucket wäre wahrscheinlich tatsächlich öffentlich.

    Aber ein Confluence mit Projektdetails oder bitwarden mit Passwörtern / Zugangsdaten würde ich gerne in einem gesichertem Netz haben.

  • Naja sauber ist etwas anderes. Server 2 müsste dann ja über Server 1 ins Internet, dieser muss dann das NAT übernehmen.

    Schließlich will Server 2 ja auch Updates bekommen und dafür nicht ständig das Interface rauf- und runterfahren müssen.

    und daran ist was problematisch? Im Optimalfall läuft auf dem Server 1 dann ein Mirror für die Paketverwaltung der jeweiligen Distribution. Wenn einem die Abschottung von Internen Systemen wichtig ist, muss man so was eben in Kauf nehmen.

  • Zugangsdaten würde ich grundsätzlich(!) nie in einem Wiki speichern. Erst recht nichts, was versioniert wird. Das ist schon oft genug erfolgreich schiefgegangen (z. B. https://gizmodo.com/github-tel…tored-their-pa-1825702783). Für Passwörter empfehle ich Dienste wie LastPass (die bieten auch ein Team-Sharing an), ansonsten mal das hier anschauen: https://www.vaultproject.io/, oder YubiKey verwenden.


    Ich hab zu Hause eine Anbindung mit 50Mbit Down/10Mb Up. Das GitLab ist über HTTPS mit der Welt verbunden. Die Geschwindigkeit reicht, auch von unterwegs, locker aus. Du redest ja auch nicht von 100 Mitarbeitern sondern erstmal von einer einstelligen Anzahl, die dazukommt, würde ich vermuten. Da sollte eine halbwegs zeitgemäße Leitung immernoch reichen.


    Aus meiner Sicht spricht ja auch eigentlich nichts dagegen, das bei NetCup zu hosten. Nur den Stunt mit VPN würde ich mir sparen. Die Frage ist immer, was das schwächste Glied in der Kette ist. Bei einem extern gehosteten Server würde ich erstmal auf den Server wetten und nicht den Übertragungsweg. SSH (ohne VPN) wirst du eh offen haben müssen, falls das VPN mal abschmiert. Ob du dann nun einen VPN aufmachst oder einfach nur noch HTTPS freigibst ist glaube ich von der Sicherheit recht ähnlich zu bewerten, Aufwand bei VPN aber um einiges größer. Dann kannst du bei VPN noch überlegen, ob du Layer2 oder Layer3 VPN haben möchtest.


    * Layer 2: Vorteil: Jeder kann jeden ganz einfach erreichen. Nachteil: Jeder kann jeden ganz einfach erreichen. Dann hast du den Schuh mit Firewalls in jedem Fall im Boot.

    * Layer 3: Zentralisiert(er) als Layer 2. Der Traffic, der durch das VPN geht ist ein bisschen besser kontrollierbar. Zentrale Endstelle (Server) für die Verschlüsselung. Ist bei HTTPS aber genauso.


    Also kurz zusammengefasst:

    Zugangsdaten einfach gar nicht speichern. Und wenn doch, dann verschlüsselt, unversioniert, nicht zentral. User based Accounts (dann brauch man keinen zentralen Passwort-Speicher). 2FA verwenden.

    Dienste (GitLab, Bitbucket, Confluence, ...) hinter ner schicken Firewall, natürlich nur HTTPS. Und bitte auch die Backups irgendwo sicher ablegen (https://virtualizationreview.c…rmy-data-unprotected.aspx).


    VPN kann man machen, macht etwas Arbeit, aber auch innerhalb VPN sollten die Dienste rocksolid laufen. Stell dir einfach vor, du hast nen befallenen Windows-Rechner im Netz, weil deine Buchhaltung natürlich auch im VPN sein muss mit Zugriff aufs Confluence. Sprich: Nur wegen VPN die übrigen Sicherheitsanforderungen nicht absenken.

  • Nur den Stunt mit VPN würde ich mir sparen.

    Das ist jetzt auch das, was ich machen werde. Ich bin nicht der Netzwerk-Spezialist und bevor ich mir da eine Lösung zusammenfrickel', die vielleicht funktioniert, aber den sicherheitstechnischen Aspekt verfehlt bzw. ich diesen gar nicht beurteilen kann, spar ich mir das.


    Zugangsdaten einfach gar nicht speichern. Und wenn doch, dann verschlüsselt, unversioniert, nicht zentral. User based Accounts (dann brauch man keinen zentralen Passwort-Speicher). 2FA verwenden.

    Naja, ist halt in der Praxis oft Utopie ;) Wenn dein Auftraggeber selbst nur einen Wartungszugang zu der Software hat ist es unrealistisch als Sub-Dienstleister Userbased-Accounts zu bekommen. Zum Speichern / Verwalten der Passwörter werde ich wahrscheinlich Bitwarden oder 1password verwenden.


    Ob du dann nun einen VPN aufmachst oder einfach nur noch HTTPS freigibst ist glaube ich von der Sicherheit recht ähnlich zu bewerten, Aufwand bei VPN aber um einiges größer.

    Das verstehe ich nicht ganz. Der Sinn des VPNs wäre aus meiner Sicht, dass man Credentials und/oder ein Zertifikat benötigt, um überhaupt Zugriff auf die Anwendung an sich zu erlangen. Dort müsste man sich dann ja noch einloggen. Klar: 2. Faktor in den Anwendungen kann auch nicht Schaden bzw. sollte wann immer möglich eingesetzt werden. Aber ich finde ein Schutz auf Netzwerkebene ist nochmal eine andere Hausnummer.

    Ich hatte jetzt noch überlegt HTTPS vielleicht mit Client-Zertifikaten einzusetzen. Aber das könnte zu Kompatibilitätsproblemen führen. Mal schauen.


    Danke auf jeden Fall an alle für den Input.

  • Wenn einem die Abschottung wichtig ist, dann kommen solche Geräte hinter eine Firewall auf einem anderen physikalischen Gerät - in einem internen Netzwerk. - Und nicht in ein RZ mit NIC an eine Global Unicast Adresse.

    Sprich: Ein Server der in einem internen vlan hängt und nur über eine interne IP erreichbar ist, also genau das was ich beschrieb. Das VPN Gateway bildet dann nur generell die Brücke um von Extern selber irgendwie dran zu kommen.

  • Sprich: Ein Server der in einem internen vlan hängt und nur über eine interne IP erreichbar ist, also genau das was ich beschrieb. Das VPN Gateway bildet dann nur generell die Brücke um von Extern selber irgendwie dran zu kommen.

    Die vNIC ist aber ja nur im Kernel deaktiviert, also noch vorhanden. Und mit sehr viel Unaufmerksam dann (dank DHCP) auch wieder online.

  • Das verstehe ich nicht ganz. Der Sinn des VPNs wäre aus meiner Sicht, dass man Credentials und/oder ein Zertifikat benötigt, um überhaupt Zugriff auf die Anwendung an sich zu erlangen.

    Soweit richtig. Aber in jedem Netzwerk (auch einem VPN-Netzwerk) können infizierte Geräte rumlaufen. Du verhinderst halt, dass erstmal nicht jeder überhaupt netzwerktechnisch in die Nähe der Kiste kommt (und dann Exploits der Platformen etc. ausnutzen kann). Das brint ohne Frage schon mehr als einfach nix tun. Aber ich gehe halt immer vom schwächsten Punkt aus. Und der ist selten das, was man direkt beleuchtet (Login-Bereich einer Anwendung), sondern meiner Erfahrung und auch der oben genannten Beispiele nach meistens da, wo keiner dran denkt (Storage, infizierte Clients, ...).


    Ich glaube eine perfekte Lösung gibt es - abgesehen von durchgeschnittenen Netzwerkkabeln - nicht. Letztendlich Kosten (finanziell wie zeitlich) und Nutzen abwägen.


    P.S.: Ich darf/durfte schon mit Firmen zusammenarbeiten, die, sagen wir, gegen sich selbst arbeiten: Um ja nicht aus Versehen Daten auf externen Cloudservern zu hosten wird alles mit "files" in der URL oder Domain gesperrt (ja, transparenter, SSL-aufbrechender Proxy...). Lösung: Entwickler macht sein eigenes, nicht weiter gesichertes VPN, damit er auf das Packagerepository von Python kommt (https://files.pythonhosted.org/). Man kann es also auch zu gut meinen und nen Schuss nach hinten setzen.