Proxmox Richtig absichern

[Gui_]

Hi,


ich plane aktuell folgende Struktur:

• Je ein LXC-Container mit Ubuntu
• Einen Tarpit , der über eine Portweiterleitung im Router, aus dem Internet ,erreichbar ist
• Einen VPN-Server, der über eine Portweiterleitung im Router, aus dem Internet ,erreichbar ist

Reicht diese Kombination grundsätzlich als solide Basis aus, oder würdet ihr noch weitere Maßnahmen empfehlen?


Für den administrativen Zugriff habe ich einen separaten Benutzer eingerichtet. Der direkte Root-Login über SSH ist deaktiviert. Für die Authentifizierung nutze ich SSH-Keys: einen regulären Key und einen zweiten als Notfallzugang (RPI).


Für weitere Vorschläge zur Absicherung bin ich offen.


Die Konfiguration des Tarpit-Benutzers sieht aktuell so aus:

[LIST=1]
[*]Benutzer anlegen
[/LIST]

useradd --system
--create-home
--home-dir /opt/sandbox
--shell /usr/sbin/nologin
--user-group
svc-tarpit


[LIST=1]
[*]Keine zusätzlichen Gruppen
[/LIST]

usermod -G "" svc-tarpit


Kontrolle:


id svc-tarpit


Der Benutzer sollte anschließend nur Mitglied seiner eigenen Gruppe sein.


[LIST=1]
[*]Keine sudo-Rechte
[/LIST]

sudo -l -U svc-tarpit


Falls der Benutzer wider Erwarten Mitglied der sudo-Gruppe ist:


gpasswd -d svc-tarpit sudo

 

[Bu66as]

Klingt erstmal solide, aber der wichtigste Punkt steckt schon in deinem Setup drin: solange nur der VPN-Port im Router weitergeleitet ist und weder 8006 noch SSH von außen erreichbar sind, hast du 90% erledigt. Der Tarpit bringt dir dann ehrlich gesagt kaum was, weil von außen ja sowieso niemand an SSH rankommt. Nett zum Rumspielen, aber kein echter Sicherheitsgewinn. Falls du bei der VPN-Software noch flexibel bist: WireGuard, das antwortet auf unauthentifizierte Pakete gar nicht erst und ist von außen praktisch unsichtbar.

Was ich zusätzlich machen würde: PVE-Firewall auf Datacenter-Ebene an, Default-Policy DROP rein, Management-Zugriff nur aus dem VPN-Netz. Container unprivilegiert fahren (ist bei neuen CTs Default, aber prüf das mal für bestehende). Und 2FA für den PVE-Weblogin, TOTP kannst du direkt in der UI pro User setzen. Das kostet fünf Minuten und fängt genau den Fall ab, wo mal ein Passwort abhanden kommt.

Aber der wichtigste Punkt, der häufig fehlt: Backups auf ein zweites Gerät. Das bringt dir im Ernstfall mehr als jede zusätzliche Firewall-Regel.

Was läuft denn in dem Ubuntu-CT? Je nachdem ob da was aus dem Netz erreichbar sein soll, ändert sich die Empfehlung nochmal deutlich.

 

[LnxBil]

Wenn du neben VPN hauptsächlich HTTPS durchlassen willst, mache es über einen Port, der dann in einen Reverse Proxy reingeht. Somit hast du nur einen Port offen und kannst alles über eine Software weiter absichern. Wenn die Dienste dahiner nur für dich sind und z.B. sowas wie HomeAssistant oder PaperlessNG(X) sind, dann könntest du über mTLS nachdenken und es damit nochmal zusätzlich absichern. Beide Apps auf dem Handy (ich weiße es nur vom iPhone, sollte bei Android aber genau so sein) können mit mTLS umgehen und somit zusätzlich zu den normalen Credentials nochmals mittels Zertifikat abgesichert werden. Das könntest du dann auch entsprechend mit PVE verwenden wenn du willst.

 

[Bu66as]

mTLS ist ein guter Punkt, nutz ich für ein paar interne Sachen auch. Bei PVE selbst würd ich aufpassen: die Web-UI hinter einen Reverse Proxy zu hängen macht wegen der WebSockets (noVNC, xterm.js) und dem API-Traffic gern Ärger, und wenn der Proxy mal klemmt kommst du an die Kiste gar nicht mehr ran. Den Mgmt-Zugriff auf 8006 würd ich nur übers VPN lassen, das ist einfach sicherer als jedes Client-Cert davor.

Für die Dienste dahinter passt der Ansatz von @LnxBil aber gut. Aber warum noch einen Port offen, wenn eh ein VPN läuft und die Sachen nur für dich sind? Bei mir ist alles was nur ich brauche hinterm Tunnel, nach außen geht nur das was andere ohne VPN-Client nutzen sollen. Was hast du denn konkret vor, soll da wer anders drauf?

 

[bomarat]

Wie habt ihr den Zugriff auf die PVE-Weboberfläche bei euch konkret gelöst? Läuft 8006 ausschließlich über das VPN, oder habt ihr zusätzlich noch einen Reverse Proxy bzw. eine andere Zugriffskontrolle davor? Ich frage mich gerade, ob sich der zusätzliche Aufwand überhaupt lohnt, wenn der Management-Zugriff ohnehin komplett vom Internet getrennt ist.

 

[Bu66as]

Bei mir läuft 8006 ausschließlich übers VPN, kein Proxy davor. PVE-Firewall auf Datacenter-Ebene mit Default DROP und eine Regel, die 8006 und SSH nur aus dem VPN-Subnetz erlaubt, das wars. Wenn von außen eh nichts ankommt, brauchst du da keinen Reverse Proxy davor. Das bringt nur Ärger mit den WebSockets.

Wichtiger ist mir aber, @bomarat, dass du nen zweiten Weg rein hast, falls das VPN mal klemmt. IPMI/iLO im Netz oder nen Zweittunnel auf nem RPi. Ich hatte mich mal ausgesperrt, weil die VPN-VM nach einem Host-Reboot nicht hochkam. Seitdem läuft der Tunnel auf dem Host, nicht in nem Gast.

 

[Gui_]

Ich bin noch in der Planung Phase. Ich habe einen test lxc aufgesetzt. Vermutlich werde ich die neuste Ubuntu Version nehmen. Allerdings mache ich mir Sorgen. Über die anderen lxc und VMs die sind quasi ungeschützt. Im lockalen lan macht das nichts vorhalten weil ich noch keine potvreigaben eingerichtet. Habe.Tarpit ist ein weiteres Projekt mit portvreigabe. Ich gehe fast nur über die oberfleche in die contener terminals. Manchnal wen ich lust habe gehe ich über ssh rein. Der datei wo ssh schlüsel auf den serverligen hab ich via copu past den schlüssel von mein Desktop pc und vür notfelle den ssh schlüssel meines pis eingefügt den habe ich bisher nur einmal zum testen verwendet. Gibt es eine bewerte checkliste die abarbeiten kann?
Mein Ziel ist hie auch ein copi past Vorlage zusammenstellen. Vür weitere LCDs.

 

[Gui_]

Von 1/2 von Funktionen die ihr vor scheitert habe ich noch nie was gehört da müßte ich erst in der docu schauen.

 

[Bu66as]

Solange keine Portfreigabe drauf zeigt, bleiben die anderen CTs und VMs geschützt, die hängen im LAN und von außen kommt da nix an. Das Problem ist, wenn du einen Port aufmachst. Den Container würd ich dann in ein eigenes Netz hängen (eigene Bridge oder VLAN) und per Firewall dicht zumachen, damit er nicht ins restliche LAN reinkommt. Falls den doch mal jemand aufmacht, hat er dann nur den einen CT und nicht dein halbes Netz.

Eine offizielle Härtungs-Checkliste gibts nicht. Für die Copy-Paste-Vorlage würd ich anders vorgehen: bau einen CT genau so wie du ihn haben willst (User, SSH-Keys, sshd-Config, unattended-upgrades) und konvertier den dann zum Template. Danach klonst du den einfach, statt jedesmal Befehle reinzupasten. Weniger Tippfehler und alle Container sind auf dem gleichen Stand.

@Gui_ welche von den genannten Sachen sagen dir denn nix? Schreib die einfach hin, dann gehen wir die durch. Hat keinen Sinn, wenn du Zeug einbaust, das du nachher nicht debuggen kannst.