Proxmox vollständig via Wireguard

[meyergru]

Ich weiß nicht, wie weit ein IDS gegen Bedrohungen hilft, die noch gar nicht klassifiziert sind. Die Verbindung zur Hersteller-Cloud mag es sehen, aber nicht notwendigerweise als bösartig erkennen. Und den anschließenden Layer-2-Traffic innerhalb des angegriffenen LANs sieht es ohnehin nicht.

Konkrete Beispiele:

https://www.elastic.co/security-labs/storm-on-the-horizon

https://claroty.com/team82/research/the-problem-with-iot-cloud-connectivity-and-how-it-exposed-all-ovrc-devices-to-hijacking

Bei beiden konnten cloudverbundene Geräte remote übernommen werden. Elastic weist dabei ausdrücklich auf die Gefahr des anschließenden „lateral pivoting“ zu anderen Systemen im LAN hin.

Genau deshalb würde ich ein fremdes LAN grundsätzlich als untrusted betrachten, unabhängig davon, wie vertrauenswürdig dessen Benutzer sind. Mein Verständnis der Threadanfrage ging jedenfalls in diese Richtung und ich werte das noch nicht unbedingt als Paranoia. ;-)

 

[TErxleben]

Ach? Da erkennst du keine leichte Paranoia? Jedes segmentierte Netzwerk setzt auf Layer3. Sonst wird es schwierig, sich zu "verstecken" oder Datenverkehr funktioniert einfach nicht. Layer-2 wirst du inzwischen selbst beim DE-CIX mit der Lupe suchen müssen.

Genau deshalb würde ich ein fremdes LAN grundsätzlich als untrusted betrachten, unabhängig davon, wie vertrauenswürdig dessen Benutzer sind. Mein Verständnis der Threadanfrage ging jedenfalls in diese Richtung und ich werte das noch nicht unbedingt als Paranoia. ;-)

Das ist ja auch Usus. Allerdings geht der TO gedanklich völlig falsch an an die Sache heran.

 

[Johannes S]

Wenn es um ein möglichst einfaches Setup geht installiere den Wireguard ggf. lieber direkt auf dem Host, statt im LXC.

Was ist daran einfach, wenn eine Fehlkonfiguration von wireguard die Netzwerkkonfiguration des Hosts zerschießen kann?

 

[bl1mp]

Was ist daran einfach, wenn eine Fehlkonfiguration von wireguard die Netzwerkkonfiguration des Hosts zerschießen kann?

Weil
- z.B. die Updates automatisch mit installiert werden, statt den LXC einzeln betreuen zu müssen
- Die gesamte Netzwerkkonfiguration, in einer administrativen Domain liegt und im Stress nichts übersehen wird.
- Man sich nicht Gedanken darüber machen muss, ob bei einem Remoteupdate der LXC wieder hoch kommt, mit dem Abhängigkeiten vom Basisimage zum HV Kernel und ich mich dann ausgesperrt habe.
(Der systemd service hat da weniger Abhängigkeiten)

Geht sicherlich auch anders und es gibt für alles Strategien, basierend auf Risikobeurteilungen.
Da muss jeder selber wissen, womit er sich wohl fühlt.

 

[Bu66as]

Bei Host vs. LXC noch ein Punkt: wenn WireGuard im Container läuft, hat der Host selbst gar keine WG-IP, an die sich pveproxy überhaupt binden könnte. Du müsstest den Kram dann per Routing/NAT aus dem LXC zum Host schaufeln, und die LISTEN_IP-Lösung aus dem Link fällt damit flach. Für dein Setup also wg direkt auf den Host, sonst beißt sich das.

Noch ein Problem: LISTEN_IP in /etc/default/pveproxy auf die WG-Adresse zu setzen geht beim Boot schief, wenn wg0 noch nicht oben ist. pveproxy startet dann einfach nicht und du hast keinen Zugang. Entweder ein systemd-Override mit Abhängigkeit auf wg-quick@wg0, oder du legst die IP als /32 auf ein Dummy-Interface, dann ist sie immer da, egal ob der Tunnel steht. Das zweite ist robuster. Lass dir aber einen Weg über die lokale Konsole offen - physischen Zugriff habt ihr ja eh.

 

[Supaman]

Einen Wireguard Server (egal ob nativ, mit OpenWRT oder OPNsene) zu konfigurieren UND das ganze in die PVE Network config einzuarbeiten ist nicht ganz trivial. Man kann alles machen, wenn man die nötigen Kenntnisse hat... das eignet mansich auch nicht mal so eben an, daher wäre ein externer Router der zwischen PVE Host und Familien Netz geschaltet wird die sicherere und einfachere Variante.

 

[Bu66as]

@Supaman, einen WireGuard-Server braucht er dafür gar nicht, der PVE wird ja nur Client. Die Familie hängt schon in seinem Tunnel, also kommt auf den Host eine wg-quick-Config mit einem Peer, Endpoint auf seine Seite und PersistentKeepalive (NAT der Familie sitzt davor). An der PVE-Netzwerkconfig muss dafür genau nichts geändert werden, keine Bridge, kein Eingriff in /etc/network/interfaces, wg0 lebt komplett daneben. Das ist eine Datei und ein systemctl enable --now wg-quick@wg0.

Der zusätzliche Router ist natürlich eine saubere Trennung, aber damit stellst du eine zweite Kiste an einen Standort, an den du nicht drankommst. Wenn die stirbt oder ein Firmware-Update sie zerlegt, telefonierst du mit der Familie. Bei sowas halt ich die Anzahl der Komponenten am Remote-Standort lieber klein.

 

[Supaman]

Ja ist richtig, habe ich verwechselt, ein WG Client reicht. In Verbinduing mit dem zweiten Ziel - abschottung vom restlichen LAN - trotzdem nicht mal so eben zusammen geklimpert. Den Zugriff auf den Router sehe ich unkritisch, es kommt es auf das Produkt an: Unifi oder GL.inet Router haben kostenfreien Cloud Account mit an Bord, solange der Router funktionierendes Internet an WAN anliegen hat, kann man den vollständig per Remote konfigurieren. Die kleinen GLinet Router sind so gross wie eine Zigarettenschachtel, kosten nicht viel und ziehen auch nur paar Watt.

Das wäre dann auch ein Setup, das man als normaler User administrieren kann... nur meine Meinung zu dem Thema... kann darf und soll aber jeder machen wie er mag