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.

 

[Gui_]

So wieder aus Dem Krankenhaus.
Also ich habe es mal mit chat gpt zusammenschreiben lasen.

1. Proxmox-Host und Administrationszugang​

• Proxmox VE und Debian-Sicherheitspakete regelmäßig aktualisieren.
• Sicherheitsupdates zeitnah installieren und Neustarts nach Kernel-Updates einplanen.
• Die Weboberfläche auf Port 8006 nicht direkt aus dem Internet erreichbar machen.
• SSH auf Port 22 nur aus einem Management-Netz oder über ein VPN erlauben.
• Für SSH nach Möglichkeit Schlüssel statt Passwortauthentifizierung verwenden.
• Direkten Root-SSH-Login deaktivieren, sofern ein getesteter alternativer Administrationszugang vorhanden ist.
• Individuelle Benutzerkonten und das Proxmox-Berechtigungssystem verwenden.
• Zwei-Faktor-Authentifizierung für administrative Benutzer aktivieren.
• Nicht benötigte Benutzer, API-Tokens, Dienste und Berechtigungen entfernen.
• Zertifikate, DNS und Systemzeit korrekt konfigurieren.

Wichtig: Vor Änderungen an SSH oder der Firewall eine funktionierende alternative Konsole sicherstellen. Andernfalls kann man sich selbst aussperren.

Dokumentation: https://pve.proxmox.com/pve-docs/

2. Firewall und Netzwerk​

• Proxmox-Firewall bewusst konfigurieren und erst nach Prüfung der Regeln aktivieren.
• Eingehenden Verkehr standardmäßig verweigern und nur benötigte Verbindungen erlauben.
• Die Verwaltungsports ausschließlich für vertrauenswürdige Quellnetze freigeben.
• IPv4- und IPv6-Regeln überprüfen.
• Am Router keine unnötigen Portweiterleitungen auf den Proxmox-Host einrichten.
• UPnP und automatische Portfreigaben deaktivieren, wenn sie nicht benötigt werden.
• Management-, Server-, IoT- und Gastnetze möglichst über VLANs oder geeignete Firewall-Zonen trennen.
• Container nicht pauschal gegenseitigen Zugriff auf alle internen Systeme erlauben.
• Ausgehende Verbindungen bei besonders sensiblen Systemen auf das notwendige Maß beschränken.
• Firewall-Regeln regelmäßig auf veraltete oder zu großzügige Freigaben kontrollieren.

Die Firewall muss auch den Zugriff auf andere interne Systeme berücksichtigen. Ein Dienst, der nicht aus dem Internet erreichbar ist, kann trotzdem aus einem kompromittierten LAN-System angegriffen werden.

Dokumentation: https://github.com/proxmox/pve-docs/blob/master/pve-firewall.adoc

3. LXC-Container und VMs​

• LXC-Container grundsätzlich unprivilegiert betreiben, sofern die Anwendung das zulässt.
• Privilegierte Container und unnötige Host-Mounts vermeiden.
• Keine sensiblen Host-Verzeichnisse oder Docker-Sockets ohne zwingenden Grund in Container durchreichen.
• Nur benötigte Netzwerkinterfaces und Dienste bereitstellen.
• Container-Betriebssysteme und installierte Anwendungen regelmäßig aktualisieren.
• SSH, Webserver und Datenbanken innerhalb der Gäste ebenfalls absichern.
• Öffentlich erreichbare Anwendungen möglichst in einem separaten Netz betreiben.
• Nicht benötigte Kernel-Fähigkeiten und Rechte vermeiden.
• Container-Templates regelmäßig aktualisieren und nur aus vertrauenswürdigen Quellen beziehen.
• Für kritische Anwendungen prüfen, ob eine VM gegenüber einem LXC-Container die passendere Isolation bietet.

Ein unprivilegierter Container ist keine vollständige Sicherheitsgrenze. Die Sicherheit hängt weiterhin von der Host-Konfiguration, den Mounts, den Berechtigungen und der Netzwerktrennung ab.

4. Backups und Wiederherstellung​

• Regelmäßige automatische Backups für VMs und Container einrichten.
• Backups auf einem getrennten System oder einem entsprechend abgesicherten Backup-Ziel speichern.
• Mindestens eine Sicherung gegen Änderungen oder Löschung durch kompromittierte Administrationskonten schützen.
• Backup-Zugangsdaten getrennt von den produktiven Systemen aufbewahren.
• Fehler bei Backup-Jobs und zu wenig Speicherplatz überwachen.
• Wiederherstellung regelmäßig praktisch testen.
• Konfigurationen, Netzpläne und wichtige Zugangsdaten sicher dokumentieren.

Ein erfolgreich abgeschlossener Backup-Job allein beweist nicht, dass sich das System im Notfall zuverlässig wiederherstellen lässt.

5. Protokollierung und Alarmierung​

• Fehlgeschlagene SSH-Anmeldungen und ungewöhnliche Authentifizierungsversuche überwachen.
• System- und Firewall-Protokolle regelmäßig prüfen.
• Benachrichtigungen für Backup-Fehler, Speichermangel und kritische Systemereignisse konfigurieren.
• Die Erreichbarkeit der Monitoring- und Benachrichtigungswege testen.
• Wenn möglich, relevante Protokolle zusätzlich auf einem separaten System speichern.
• Einen Ablauf für den Verdachtsfall definieren: Zugang absichern, Beweise erhalten, betroffene Systeme untersuchen und gegebenenfalls isolieren.

6. Optional: Canary Tokens als zusätzliche Alarmgeber​

Canary Tokens sind absichtlich platzierte digitale Köder. Wird beispielsweise ein spezieller DNS-Name aufgelöst oder eine eindeutige Webadresse aufgerufen, kann eine Benachrichtigung ausgelöst werden.

Projekt und Anleitung: https://docs.canarytokens.org/

Mögliche Einsatzbereiche​

• Einen eindeutigen DNS-Canary-Token für einen vermeintlich sensiblen, aber tatsächlich nicht produktiven Konfigurationshinweis anlegen.
• Einen HTTP-Token als Köder in einer eigens dafür vorgesehenen, nicht produktiven Datei platzieren.
• Einen Köder mit einem Namen wie old-backup-credentials.txt in einem kontrollierten Testverzeichnis ablegen.
• Köderdateien ausschließlich mit erfundenen Zugangsdaten und nicht mit echten Passwörtern, privaten Schlüsseln oder API-Tokens bestücken.
• Jeden Token mit einem eindeutigen Verwendungszweck versehen, damit ein Alarm dem richtigen System zugeordnet werden kann.
• Die Benachrichtigungen an ein überwachtetes E-Mail-Konto oder einen geeigneten Alarmkanal senden.
• Jeden Token nach der Einrichtung kontrolliert auslösen und prüfen, ob der Alarm ankommt.
• Dokumentieren, wer im Alarmfall zuständig ist und welche Schritte folgen.

7. Optional: Tarpit und weitere Täuschungsmaßnahmen​

• Einen Tarpit nur als ergänzende Maßnahme und nicht als primären Schutz verwenden.
• Keine unnötigen offenen Ports ausschließlich für den Tarpit bereitstellen.
• Tarpit-Verbindungen auf Ressourcenverbrauch und mögliche Auswirkungen auf legitime Nutzer überwachen.
• Köderdienste und echte Produktionsdienste klar voneinander trennen.
• Keine produktiven Zugangsdaten oder vertraulichen Daten in Köderdiensten hinterlegen.

Ein Tarpit kann bestimmte automatisierte Zugriffe verlangsamen. Er ersetzt aber weder eine restriktive Firewall noch die Absicherung der tatsächlich erreichbaren Dienste.

8. Abschließender Funktionstest​

• Von einem externen Netz prüfen, dass die Proxmox-Verwaltungsoberfläche nicht direkt erreichbar ist.
• Prüfen, dass SSH nur aus den vorgesehenen Netzen erreichbar ist.
• Erlaubte Anwendungsdienste auf Erreichbarkeit testen.
• Verbindungen zwischen getrennten VLANs und Containern entsprechend der Sicherheitsregeln überprüfen.
• IPv6 und Router-Portfreigaben in die Prüfung einbeziehen.
• Einen Canary Token kontrolliert auslösen und die Alarmierung verifizieren.
• Ein Backup testweise wiederherstellen.
• Alle Ergebnisse und Abweichungen dokumentieren.