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

 

[Frank73]

Dann hast Du einen Zweit-Weg z.B. für SSH Zugriff auf die VPS, wenn Wireguard mal streikt.

Über tailscale bin ich auch schon gestolpert, würde es aktuell aber mal außen vor lassen.
Sollte der SSH-Zugriff mal nicht funktionieren (kam in meiner anfänglichen Testphase öfters vor ) komme ich über die VNC-Konsole als Backup noch drauf.

Alternativ nutzt Du einen DynDNS-Dienst. Soweit ich weiss, kann die ufw nicht mit Hostnamen, aber... man könnte ja ggf. ein Script

Da bin ich aktuell dabei mal was mit heißer Nadel testweise zu stricken (nutze den DynDNS der fritzbox). Hetzner hat da ja ausführliche docs was API betrifft und da gibt es auch Möglichkeiten Regeln der Cloudfirewall anzupassen. Wenn das funktioniert würde ich auch die ufw darüber anpassen, sodass in beiden Firewalls nur der Port für den Tunnel über meine öffentlichen IPs meines Providers offen ist (fertiges Script würde ich dann hier veröffentlichen). Zusätzlich habe ich ja in der ufw noch die Bindung an das Interface des Tunnels.

Aber so wie ich euch verstanden habe, wäre dann mein VPS von außen so abgeschottet, dass es schwer wäre darauf zuzugreifen, oder müsste ich noch mehr machen (wobei mehr eigentlich immer geht)?

 

[Barungar]

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.

Da kann man noch etwas (mehr) absichern, Du könntest es auf die IP-Segmente Deines Providers begrenzen.

Dieses "kleine" Befehl, den Deine VPS sofort verstehen sollte, liefert die aktuellen Subnetz-Segment, die Deinem Provider aktuell delegiert sind. Der Output ist dabei ein CIDR-Netz pro Zeile, durch ein weiteres "|" (Pipe) kannst Du das nun an ein kleines Script von Dir selbst weiterleiten, dass die Deine Firewall aktualisiert.

Du musst lediglich die AS-Nummer (die BGP Autonomous System Number), die grüne Zeichenkette, anpassen. Im Beispiel unten, kannst Du natürlich per Copy'n'Paste mal ausprobieren, damit Du auf der Shell siehst, was da rauskommt. Sind die delegierten IPv4-Segemente für den Provider "NetCologne GmbH aus Köln". Das sind öffentliche Informationen, die Du halt "nur hübsch" brauchst, um sie zu verarbeiten. Die Daten ändern sich auch nicht allzu oft, Du kannst das bequem per Cron checken und bei Bedarf updaten.

whois -i origin AS8422 | grep ^route: | awk '{print $2}'

Und falls Du dann doch irgendwann auch IPv6 hinzunehmen willst, das geht nach dem gleichen Prinzip. Einfach in der Firewall auf die IP Segmente Deines Providers eingrenzen.

whois -i origin AS8422 | grep ^route6: | awk '{print $2}'

Das schränkt die Anzahl der zulässigen IPs, die eine Verbindung zu Deiner VPS öffnen können schon ziemlich ein. Es ist allemal besser als "ANY". Aber natürlich deutlich gröber, als wenn Du es auf Deine eigene dezidierte IP einschränkst. Die Frage ist halt, wie viel Aufwand will man treiben. Mit dem Provider - je nachdem welchen man hat - ist es schon auf einen deutlich kleineren Teil des Internets eingegrenzt.

 

[blurrrr]

Dieses "kleine" Befehl, den Deine VPS sofort verstehen sollte

Unter Debian ist whois nicht standardmässig installiert (Ubuntu weiss ich grade nicht), aber lässt sich ja problem nachinstallieren, in den entsprechenden Repos sollte es jedenfalls vorhanden sein. Da es sicherlich ein Cloud-Image ist, wird es "so klein wie sinnvoll möglich" gehalten sein. Ist sicherlich erstmal eine Lösung, problematisch dabei finde ich allerdings, dass die Netze ein normales Handelsgut sind, so dass sich die Bereiche auch ändern können (es fallen welche weg/es kommen neue hinzu), so dass man die Regeln ggf. auch in regelmässigen Abständen erneuern sollte.

Da aber sowieso 2 Firewalls im Spiel sind (Security-Groups der Cloud ("Cloud-Firewall") und UFW auf der VM selbst), könnte man durchaus hingehen und via Security-Groups auf z.B. den ISP beschränken. Auf der VM selbst dann halt noch Key-Auth (+Passwort für den Key, also nicht ohne Passwort, wie man es gern für div. Umgebungen macht (z.B. Server zu Server)) und fail2ban, dann ist das schon ziemlich ordentlich. Kannst natürlich auch noch einen Panzer davor stellen und ein kleines Heer, aber irgendwo sollte man die Kirche vielleicht auch im Dorf lassen Durch die CG wird schon sichergestellt, dass der SSH-Dienst "nur" aus den Netzen des entsprechenden AS erreichbar ist (falls der SSH-Dienst mal ein Sicherheitsproblem haben sollte) und für alles weitere bräuchte man dann eh das Key-File und das dazugehörige Passwort. Erfolglose versuche kann man auch noch weiter eindämmen (fail2ban-Jail anpassen), so dass z.B. nach 1 fehlgeschlagenem Versuch sofort gesperrt wird.

Bzw. um es mal anders zu formulieren: Vor dem "Grundrauschen" im Internet braucht man eigentlich keine Angst zu haben (nichtmals mit "nur" Passwort-Authentifizierung). Oben drauf kommen halt noch die Login-Versuche mit geklauten Credential und dann wird die Luft auch schon ziemlich dünn (von gezielten Angriffen mal abgesehen).

Zusätzlich habe ich ja in der ufw noch die Bindung an das Interface des Tunnels.

Also aus meiner Sicht spricht nichts dagegen, dass z.B. der SSH-Dienst auch auf dem Interface der öffentlichen IP lauscht, denn: Es sitzen 2 Firewalls davor, die den Zugriff schon massiv einschränken. Kannst natürlich noch hingehen und den Port ändern, aber das bringt meiner Meinung nach eher nicht soviel (jut, bei den 0815-Scans auf Port 22 biste dann halt raus).

Ich denke, @Barungar hat es genau richtig formuliert:

Die Frage ist halt, wie viel Aufwand will man treiben.

Möglichkeiten gibt es viele - hier wurden jetzt einige genannt - allein das alles umzusetzen und schon nicht unerheblich, da machen sich andere nichtmals ansatzweise soviel Aufwand mit (z.B. viele Hoster). Mietest Du bei Strato einen VPS mit Plesk, ist da sicherlich auch Port 22 ganz normal erreichbar (und standardmässig Login via User/Passwort). Selbiges gilt für Windows-VPS... i.d.R. einfach ganz normal via User/Passwort + RDP auf die Kiste und los geht's (und Windows hat standardmässig noch nichtmals etwas wie fail2ban).

Wenn Dir die Einschränkung der Erreichbarkeit (z.B. auf ASN) + Key + Passwort dann noch immer nicht ausreicht, kannst Du natürlich auch noch zusätzlich 2MFA nutzen (s. z.B. thomas-krenn.com - SSH-Login mit 2-Faktor-Authentifizierung absichern).

Aber so wie ich euch verstanden habe, wäre dann mein VPS von außen so abgeschottet, dass es schwer wäre darauf zuzugreifen, oder müsste ich noch mehr machen (wobei mehr eigentlich immer geht)?

Die Frage ist, was Du unter "Zugriff" und "schwer" verstehst Ich würde aber mitunter dazu raten nicht "zuviel" zu machen (Kirche im Dorf lassen und so). Ein paar Dinge machen mitunter sicherlich Sinn, gar keine Frage. Grade wenn es um Dinge geht, die sowieso "völlig klar" sind. Als da wäre z.B. (initial) eingehender Traffic aus dem Ausland auf dem SSH-Port. Da weiss man jetzt schon, dass Du das nicht sein wirst und da niemand sonst etwas an der Büchse verloren hat, kann der Traffic auch ungesehen "weg". Anders sieht es aus - bei ASN-Filterung - wenn Du den ISP wechselst. Ist aber durchaus etwas, was sich schnell beheben lässt (sofern man es dann noch auf dem Schirm hat). Bezüglich VPN kann man es auch so handhaben, dass Du Dich bei Dir Zuhause ins VPN einwählst (von unterwegs) und über diesen Tunnel dann bis zur Cloud-VM kommst. Je nachdem, wie man es halt braucht, aber es bleibt dabei:

Die Frage ist halt, wie viel Aufwand will man treiben.

In Bezug auf:

Aber so wie ich euch verstanden habe, wäre dann mein VPS von außen so abgeschottet, dass es schwer wäre darauf zuzugreifen, oder müsste ich noch mehr machen (wobei mehr eigentlich immer geht)?

Würde ich persönlich sagen, dass es so schon vollkommen ausreicht. Zugriff nur durch den VPN-Tunnel, von aussen nichts erreichbar (abgesehen von Wireguard, das könnte man ggf. noch auf die ASN bzw. die entsprechenden Netze einschränken, oder eben auf Deine hinterlegte DynDNS-Adresse) und sollte das VPN mal nicht funktionieren, gibt es noch immer die VM-Konsole beim Anbieter.