Proxmox Richtig absichern

G

Gui_

Member
Jun 12, 2024
49
2
13
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:


Code: 
[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
 
Last edited:
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.
 
  • Like
Reactions: Johannes S
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.
 
  • Like
Reactions: Johannes S
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?
 
  • Like
Reactions: IsThisThingOn and Johannes S
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.
 
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.
 
  • Like
Reactions: IsThisThingOn
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.
 
Last edited:
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.
 
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.
 
  • Like
Reactions: mow, Johannes S and IsThisThingOn

Proxmox VE absichern – Sicherheitskonzept mit VLANs, Pi-hole, Fail2ban und Honeypot​

Hallo zusammen,

ich bin wieder aus dem Krankenhaus.

Das gantz basirt auf dien chat und dieser Playliste.

https://www.youtube.com/watch?v=C5l_Iuic5hs&list=PLhvaM7uJr1PA89sEfrL74abQ4kZGC3Js9

1. Netzwerkaufbau mit zwei VLANs​

Ich möchte zwei getrennte VLANs einrichten. Jedes VLAN soll einen eigenen Pi-hole bekommen, der jeweils DNS und DHCP für sein VLAN bereitstellt.

  • VLAN 10 – vertrauenswürdiges LAN: Administrationsgeräte und ausgewählte vertrauenswürdige Clients.
  • VLAN 20 – getrenntes Netz: Weitere Clients und Dienste, die nicht direkt auf das Verwaltungsnetz zugreifen dürfen.
Für beide VLANs soll jeweils ein eigener Pi-hole als DNS- und DHCP-Server laufen. Die DHCP-Bereiche sollen getrennt sein. Der Router beziehungsweise eine Firewall soll den Verkehr zwischen den VLANs kontrollieren.

Die beiden Pi-holes sollen möglichst unabhängig voneinander konfiguriert werden. Insbesondere möchte ich verhindern, dass Clients aus VLAN 20 auf die Proxmox-Verwaltung oder andere Systeme in VLAN 10 zugreifen können.

Offene Frage: Würdet ihr die Pi-holes als separate LXC-Container oder als VMs betreiben? Wie würdet ihr die DHCP-Dienste bei Ausfall eines Pi-holes absichern?

2. Proxmox-Host absichern​

  • Proxmox VE und alle installierten Pakete regelmäßig aktualisieren.
  • Weboberfläche auf Port 8006 ausschließlich über das Verwaltungsnetz oder VPN erreichbar machen.
  • SSH nicht direkt aus dem Internet erreichbar machen.
  • Proxmox-Firewall und gegebenenfalls eine externe Firewall mit restriktiven Regeln verwenden.
  • Administrative Zugriffe mit Zwei-Faktor-Authentifizierung absichern.
  • Backups auf einem getrennten Ziel speichern und regelmäßig testen.
  • Bei Änderungen an SSH und Firewall einen funktionierenden Notfallzugang sicherstellen.

3. Benutzer- und Rechtekonzept​

Ich möchte die Rechte möglichst restriktiv vergeben:

  • Persönliches Administratorkonto für reguläre Verwaltungsaufgaben.
  • Root nur für tatsächlich notwendige administrative Tätigkeiten.
  • Für jeden Dienst ein eigenes Systemkonto mit minimalen Berechtigungen.
  • Dienste ohne interaktive Anmeldung betreiben, sofern sie keinen Login benötigen.
  • Keine pauschalen Root-Rechte für Dienste oder Container vergeben.
  • Unprivilegierte LXC-Container bevorzugen, sofern der Dienst damit funktioniert.

4. Überwachung und Benachrichtigungen​

Ich möchte erfolgreiche Anmeldungen zuverlässig erkennen und per E-Mail gemeldet bekommen.

Geplant sind:

  • Fail2ban für SSH und gegebenenfalls weitere geeignete Dienste.
  • Überwachung erfolgreicher SSH-Anmeldungen einschließlich Benutzer, Quell-IP und Zeitpunkt.
  • Zusätzliche Überwachung erfolgreicher Anmeldungen an der Proxmox-Weboberfläche und API.
  • Überwachung lokaler Anmeldungen sowie privilegierter Aktionen.
  • Übertragung wichtiger Protokolle an einen separaten Rechner, damit sie bei einer Kompromittierung des Hosts nicht einfach gelöscht werden können.
  • Regelmäßige Testalarme zur Überprüfung des Mailversands.
Dafür möchte ich ein Bash-Skript verwenden, das dauerhaft läuft und bei erfolgreichen Anmeldungen eine E-Mail versendet. Die unterschiedlichen Logquellen sollen dabei passend ausgewertet werden.

5. Honeypot, Tarpit und Canarytokens​

Optional möchte ich eine isolierte Umgebung für die Angriffserkennung einrichten:

  • Separater Honeypot in einer eigenen VM oder einem unprivilegierten LXC.
  • Optional ein SSH-Tarpit, um automatisierte Scans zu erkennen beziehungsweise auszubremsen.
  • Canarytokens in eigens angelegten Köderdateien oder falschen Konfigurationsdateien.
  • Separate Sandbox-Konten ohne sudo-Rechte, produktive Zugangsdaten oder Zugriff auf andere Systeme.
  • Alarmierung bei Zugriff auf die Köder.
  • Strikte Begrenzung des Netzwerkzugriffs und ausgehender Verbindungen.
Die Honeypot-Umgebung soll keinen Zugriff auf die produktiven VLANs oder auf den Proxmox-Host erhalten.

6. Fragen an die Community​


  1. Welche Firewall-Regeln würdet ihr für zwei VLANs mit getrennten Pi-holes empfehlen?
  2. Welche Möglichkeiten eignen sich, um erfolgreiche SSH-, Proxmox-Web- und lokale Logins zentral zu überwachen?

Mir ist wichtig, dass die Lösung nicht nur sicher aussieht, sondern auch im Alltag zuverlässig funktioniert und nach einem Neustart oder Ausfall sauber wieder anläuft.

Vielen Dank für eure Vorschläge und Verbesserungshinweise!
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back