Projekt VPS

[Frank73]

Hallo zusammen,

in den letzten Wochen habe ich mir vermehrt Gedanken darüber gemacht was passiert, wenn meine NAS (DS1621+) plötzlich nicht mehr zur Verfügung steht (Hardware-Defekt, Brand usw.) und kurzfristig kein Ersatz zu bekommen ist (NAS, Platten …).
Auf meinem NAS werden aktuell genutzt: ein DNS mit 2 Zonen, docker mit div. Container; auch ein eigenes SSL-Zertifikat wird benutzt, welches über DNS-Challenge alle 60 Tage erneuert wird.

Deshalb habe ich mir überlegt meine wichtigsten produktiven Anwendungen (fast nur Container) auf einen VPS auszulagern. Was viele über eine 2.NAS bei Freunden oder bekannten realisieren, kann ich leider auf Grund fehlender Bereitwilligkeit der in Frage kommenden Personen nicht umsetzen.

Meine Vorstellungen wären hierbei:
Der VPS soll als Teil meines Heimnetzes fungieren, nur mit dem Unterschied, dass er nicht in meinen Räumlichkeiten steht. Absolut kein Zugriff aus dem Internet, sondern nur über einen Tunnel aus meinem Heimnetz heraus.

In diesem Thread würde ich gerne meine Umsetzungen dokumentieren. Verbesserungsvorschläge sind erwünscht.
Wichtig:
Ich bin kein Experte, sondern mehr ein "Bastler" der gerne mal was ausprobiert; wenn es dann noch richtig läuft wird es auch genutzt. Das ganze wird auch nur von wenigen Personen rein privat angewendet.

Was habe ich bisher gemacht:

• Bei einem Hoster einen VPS angemietet und ein Ubuntu 26.04 installiert.
• Einen neuen User angelegt und der Gruppe sudo zugeordnet
• Erstellung eines SSH-Keys
• In der sshd_config „PermitRootLoginNo“ und „PasswordAuthentication“ auf No gesetzt
• Hier war zu beachten, dass im Ordner „/etc/ssh/sshd_config.d“ eine weitere Datei existiert. In dieser die Zeile „PasswordAuthentication“ ebenfalls auf No angepasst
• Anmeldung erfolgt aktuell nur über SSH mit Key und ohne Passwortauthentifizierung für den neu erstellen User
• Im Verzeichnis „etc/sysctl.d“ eine neue conf-Datei angelegt und mit dem Eintrag „net.ipv4.ip_forward=1“ das Forwarding für IPv4 aktiviert (IPv6 lasse ich anfänglich mal außen vor)
• Kleinere Anpassungen wie die Zeitzone, die Anzeige der Uhrzeit auf 24h, Tastaturlayout
• Auf dem VPS wireguard installiert und ein Schlüsselpaar erstellt.
  Da ich bereits Wireguard auf der FB für Laptops und Smartphones nutze ist es nicht mehr möglich neue Schlüsselpaare über die GUI zu importieren, sonst würden die bisherigen überschrieben werden. Weiterhin erstellt die FB kein separates Transfernetz für den Tunnel.
• Auf der FB die entsprechenden Felder der Site to Site Verbindung mit einer neuen Subnetzmakse für den VPS erfasst (192.168.1.0/24) --> FB ist Initiator des Tunnelaufbaus
• Auf dem VPS eine wg.config angelegt und im Interface-Bereich den Key und als Address die 192.168.1.1/24 erfasst.
• Im Peer-Bereich die Keys der FB als auch Allowed-IPs 192.168.2.0/24 eingetragen (Heimnetz)
• WG-Verbindung läuft seit Tagen stabil.

Aktuell bin ich dabei sowohl die Cloud-Firewall als auch auf dem VPS die firewall (ufw) einzurichten. Bei der Cloud-Firewall habe ich nur eine Regel über welche der Port für die Wireguard-Verbindung geöffnet ist, jedoch für any ipv4 und any ipv6, da ich keine statische IP meines Providers habe. Bei der ufw habe ich aktuell 2 Regeln. wireguard, ssh (eingehend von 192.168.2.0/24), der Rest ist denied; dadurch möchte ich nur Zugriff durch den Tunnel erlauben --> funktioniert bisher auch.

Sollten die Experten von euch hier schon Sicherheitslücken bzw. -bedenken haben, bitte um Rückmeldung, sodass ich noch nachbessern kann (ich lese mich dann gerne ein, bin jedoch kein Profi).

Eine direkte Frage hätte ich aber noch zur Cloud-Firewall. Ich könnte jetzt meine einzige Regel mit der öffentlichen IP meines Providers belegen; nach spätestens 180 Tagen gibt es dann eine Neue und der Tunnel kann nicht mehr aufgebaut werden.
Es gibt jedoch die Möglichkeit über die API die IP dieser Regel anzupassen, sobald sich die öffentliche IP der FB ändert.

1. Macht das Sinn diese Möglichkeit zu nutzen, ist dies überflüssig oder gibt es andere Alternativen?
   So wie ich das verstehe, würde dann der Traffic erst gar nicht zum VPS weitergeleitet und direkt "davor" abgewiesen (gäbe mir ein besseres Sicherheitsgefühl).

Sobald der VPS nach bestem Wissen und Gewissen "gesichert" ist, würde ich als nächstes die benötigten Anwendungen installieren. Da wären als erstes docker, portainer und nginx. Ich habe vor, diesen Thread dann weiter zu ergänzen.

Vielen Dank schon mal und noch einen schönen Abend.

 

[Barungar]

Als kleinen Tipp... ich würde zusätzlich noch tailscale einrichten.
Dann hast Du einen Zweit-Weg z.B. für SSH Zugriff auf die VPS, wenn Wireguard mal streikt.

 

[blurrrr]

Könntest ja ggf. einfach nur auf die - bei Dir genutzten - öffentlichen Netze einschränken. Oftmals ist es ja eh ein relativ statischer Bereich + ggf. noch 1-2 weitere Bereiche, so "völlig" random ist es ja i.d.R. nie. Alternativ nutzt Du einen DynDNS-Dienst. Soweit ich weiss, kann die ufw nicht mit Hostnamen, aber... man könnte ja ggf. ein Script via Cron laufen lassen, welches alle 5 Minuten die IP hinter Deiner DynDNS-Adresse prüft und ggf. die Firewall-Regel entsprechend anpasst.

Wenn irgendwas mit der Büchse schief hängt, wirst Du ja vermutlich sowieso via Webinterface vom Anbieter dran müssen (noVNC/Spice/etc.), ich persönlich würde da auf weitere Installationen (z.B. tailscale, wie von @Barungar vorgeschlagen) verzichten. Wichtig wäre halt nur, dass - sofern alles funktioniert - die Regeln entsprechend angepasst werden. Alternativ gäbe es auch noch knockd. Auf der anderen Seite muss man aber auch sagen, dass ein lauschender SSH-Dienst mit Key-Auth jetzt nicht sonderlich unsicher ist. Könntest ggf. auch in Richtung Country-Blocking tendieren (falls Dir das mit den einzelnen Netzen zu umständlich ist), s. dazu z.B. hier https://gist.github.com/jasonruyle/8870296#file-ufw_ban_country-md.

Möglichkeiten gibt es viele, wer es einfach mag, kann natürlich auch zu Lösungen wie tailscale, etc. greifen, ich persönlich bin davon allerdings eher kein Freund - einfach weil eine Dritte Partei involviert ist (auch wenn diese die Daten nicht zu Gesicht bekommt). Von daher würde ich vermutlich eher zu einer offenen Alternative wie headscale greifen (wenn ich sowas denn nutzen würde), würde aber auch wieder einen zusätzlichen öffentlich erreichbaren VPS bedingen (als Control-Instanz). Ist aber eher eine Frage der persönlichen Vorlieben