Ergebnis 1 bis 5 von 5

Proxmox einfache Firewall-Regel setzen

  1. #1 Zitieren
    Held Avatar von Illuminatum
    Registriert seit
    Mar 2007
    Ort
    In BW
    Beiträge
    5.203
    Hallo zusammen,
    kennt sich hier jemand zufällig mit Proxmox aus? Oder iptables allgemein...

    Ich habe in einer virtuellen Umgebung ein Proxmox v5.4-3 aufgesetzt und will nun eine einfache Firewallregel über die GUI in Proxmox setzen: Zugriff auf die GUI nur mit einer Auswahl an IP-Adressen, alles andere darf nicht zugreifen.

    Da ich die virtuelle Umgebung in einer virtuellen Umgebung nutze, hier mal ein kurzer Überblick:
    Die Proxmox-VM [192.168.120.199] ist hinter einer virtuellen Firewall [WAN: 192.168.10.70, LAN: 192.168.120.0/24], der Zugriff erfolgt über Port-Weiterleitung: https://192.168.10.70:8006 (funktioniert auch)

    Ich will nun, dass ausschließlich mein Host-System (192.168.10.15) und eine imaginäre andere IP (192.168.10.200) auf die GUI zugreifen darf. Die virtuelle Firewall bitte ignorieren. Stellt euch vor, die beiden IPs, die zugreifen dürfen, sind öffentliche IPs von Firma A und Firma B, und die Proxmox-Umgebung ist ebenfalls direkt per öffentlicher IP erreichbar (Rechenzentrum).

    Mein erster Schritt war erstmal, mich auszusperren, da ich die Firewall aktiviert habe mit der "default" Regel "drop" :>, also über den Hypervisor auf die VM zugegriffen, Firewall deaktiviert, default Regel auf accept gestellt und Firewall wieder aktiviert: Zugriff auf GUI funktioniert wieder mit aktivierter Firewall.

    Zweiter Schritt war, ein IP-Set anzulegen "Zugriff_ok" mit den gewünschten IPs.

    Dritter Schritt: Firewall-Regel anlegen:

    [Bild: proxmox_firewall1.JPG]

    Und hier komme ich nicht weiter. Was trage ich hier bei den Feldern ein, welche sind überhaupt nötig? Ist "Destination" die IP vom Proxmox? Muss der Port 8006 oder das Protokoll TCP angegeben werden?
    Was trage ich bei Interface ein, die "physikalische" eth0 oder die "virtuelle" bridge vmbr0?

    [Bild: proxmox_firewall2.JPG]

    Kann mir jemand helfen?


    Danke im Voraus!

    MfG
    Illuminatum ist offline

  2. #2 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Definiere mal bitte "Virtuelle Firewall". Meinst du ein NAT?

    Grundsätzlich wenn man mit iptables arbeitet:
    1. Die Reihenfolge der Regeln zählt. Denn die Pakete werden von oben nach unten durch die Regeln geleitet, und die erste die Matcht, greift. Ende. (Zumindest wenn das Ziel ACCEPT, DROP oder REJECT ist, bzw eine andere Tabelle)
    2. Es ist immer hilfreich sich während der initialen Einrichtung einen Cron-Job ein zu richten, der einem alle 20 Minuten die iptables Regeln wieder auf Default zurück setzt. Sonst kann man sich schnell mal selber aussperren. Für den Produktiv-Betrieb schaltet man das natürlich ab. Aber solange man da noch rum tüftelt ist das ein probates Mittel.

    Ich vermute mal, dass du bei Source die IP Adressen deiner validen Hosts eintragen möchtest, bei Destination die IP Adresse auf welchem das Web-Interface läuft und als Destination-Port das des Web-Interfaces.

    Und dann frage ich mich noch, warum man ProxMox in eine VM schmeißt ...

    Was hast du denn mit ProxMox genau vor?
    Lookbehind ist offline

  3. #3 Zitieren
    Held Avatar von Illuminatum
    Registriert seit
    Mar 2007
    Ort
    In BW
    Beiträge
    5.203
    Hi!
    Danke für deine Antwort.

    Ich habe Proxmox in einer virtuellen Umgebung aufgesetzt, weil ich für eine winzige Testumgebung, wo ich nur eine Kleinigkeit testen will, keinen physischen Computer platt machen will. Proxmox (und damit einhergehend Linux, du weißt das bestimmt, wie oft ich mich schon an einem Linux-System versucht habe ) ist für mich ein neues Thema, ich komme aus der Welt von Hyper-V und ESXI, aber in der Firma stellen wir bei unseren Kunden nun vermehrt auf Proxmox um (Thema: Migration von SBS Servern in eine neue AD/Exchangestruktur etc, und um zu den Windows Lizenzkosten nicht noch Lizenzen für den Hypervisor zu kaufen, warum nicht im Zuge dessen auch gleich den Hypervisor ändern?).

    Bei einem anderen Kunden haben wir mithilfe eines externen Dienstleisters die ganze IT-Struktur in ein Rechenzentrum umgestellt und nutzen dort den Proxmox Cluster und ein zweites Rechenzentrum, um eine HA-Lösung anzubieten (es handelt sich dabei um ein Notrufsystem). Und da es sonst eigentlich niemanden gibt, der dieses Wissen mit dem Alarmsystem besitzt, ist dieses Wissen für uns natürlich ziemlich nützlich. Und da bietet es sich an, die anderen Kunden ebenfalls auf Proxmox umzustellen, damit man eben überwiegende überall das gleiche System nutzt.

    Im Speziellen haben wir einen Kunden, der viele verstreute Mitarbeiter deutschlandweit hat. Und die Idee ist, in einem Rechenzentrum eine eigene kleine Struktur aufzubauen, damit alle Daten und Mails zentral liegen. Und in dem Rechenzentrum haben wir 2 öffentliche IPs zur Verfügung, eine wird als Direktzugriff für Proxmox genutzt und die andere ist die öffentliche IP einer virtualisierten OPNsense Firewall. Dahinter befindet sich die Struktur mit AD, Exchange, Fileserver und Remotedekstopserver. Zugriff für die Mitarbeiter natülich mit VPN und darüber RDP BlueKeep lässt grüßen (auch wenn es für Server 2016 eig nicht zutrifft, aber wo eine Lücke ist wird es auch andere geben, das ist ja allgemein bekannt)

    Und damit die Proxmox-Oberfläche nicht einfach so im Netz rumhängt, will ich den Zugriff auf die GUI auf die IP unserer Firma und der Partnerfirma begrenzen. Und da Proxmox ja eben eine integrierte Firewallfunktion hat (was die anderen Virtualisierungslösungen nicht haben), bietet es sich ja an, den Zugriff so einzugrenzen. Das ist im Grunde schon alles.

    Naja, lange Rede, kurzer Sinn. Im Grunde habe ich nun die Regel eigentlich genau so konfiguriert, wie ich im ersten Screenshot dargestellt habe, also lediglich ein ACCEPT für das IPSet. Sonst habe ich nichts angegeben. Natürlich dann die default Regel auf "drop" und siehe da, sobald ich meine IP ändere, komme ich nicht mehr auf die GUI drauf.

    Dazu siehe die cluster.fw:

    Code:
    root@hyper-pve:~# cat /etc/pve/firewall/cluster.fw 
    [OPTIONS]
    
    enable: 1
    policy_in: DROP
    
    [IPSET proxmox-ip] # Proxmox IP
    
    192.168.10.199
    
    [IPSET zugriff_ok] # Erlaubter Zugriff
    
    192.168.10.15 # Temp .15
    192.168.10.200
    
    [RULES]
    
    IN ACCEPT -source +zugriff_ok -log nolog
    Da es wenig Sinn macht, die Proxmox-VM über das NAT irgendwie kontrollieren zu wollen, habe ich der Proxmox-VM eine zweite Netzwerkkarte gegeben als "Netzwerkbrücke" (in proxmox dann vmbr1), dort die "öffentliche IP" 192.168.10.199 eingestellt und damit den Firewallzugriff konfiguriert. Das kommt auch der Produktiv-Umgebung näher

    Sollte das dann so passen? Oder hast du Einwände? Dann gerne mitteilen

    Ansonsten danke nochmal!

    MfG
    Illuminatum ist offline

  4. #4 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Uff!

    Zitat Zitat von Illuminatum Beitrag anzeigen
    Hi!
    Danke für deine Antwort.

    Ich habe Proxmox in einer virtuellen Umgebung aufgesetzt, weil ich für eine winzige Testumgebung, wo ich nur eine Kleinigkeit testen will, keinen physischen Computer platt machen will. Proxmox (und damit einhergehend Linux, du weißt das bestimmt, wie oft ich mich schon an einem Linux-System versucht habe ) ist für mich ein neues Thema, ich komme aus der Welt von Hyper-V und ESXI,
    ...
    Ja, jetzt wo du es sagst, fällts mir wieder ein.
    Tipp: Virtualisierung in Virtualisierung ist manchmal mit merkwürdigen Problemen verbunden. Und selten mit ansatzweise guter Performance. Wenn du Docker oder LXC-Container starten möchtest, kannst du das so machen. Aber wenn es eine richtige Virtualisierung brauchst, würde ich den Hypervisor immer auf Bare-Metal packen. (Ja, VM in VM geht, aber geil ist das nicht.)
    Zitat Zitat von Illuminatum Beitrag anzeigen
    ...
    aber in der Firma stellen wir bei unseren Kunden nun vermehrt auf Proxmox um (Thema: Migration von SBS Servern in eine neue AD/Exchangestruktur etc, und um zu den Windows Lizenzkosten nicht noch Lizenzen für den Hypervisor zu kaufen, warum nicht im Zuge dessen auch gleich den Hypervisor ändern?).
    Hm, hat Proxmox seine Lizenzen geändert? Meines wissens war die frei verfügbare Version arg eingeschränkt und vor allem nicht Cluster-Fähig. Wenn man das haben wollte musste man doch wieder blechen. Also zahlt man doch wieder für den Hypervisor.
    Zitat Zitat von Illuminatum Beitrag anzeigen
    ....
    Und da bietet es sich an, die anderen Kunden ebenfalls auf Proxmox umzustellen, damit man eben überwiegende überall das gleiche System nutzt.
    Hm, ja, nein. Generell ist Vielseitigkeit etwas gutes. Aber ja, es macht wirtschaftlich Sinn, sich nicht in unnötig vielen Systemen zu verzetteln.
    Zitat Zitat von Illuminatum Beitrag anzeigen
    ...
    Im Speziellen haben wir einen Kunden, der viele verstreute Mitarbeiter deutschlandweit hat. Und die Idee ist, in einem Rechenzentrum eine eigene kleine Struktur aufzubauen, damit alle Daten und Mails zentral liegen. Und in dem Rechenzentrum haben wir 2 öffentliche IPs zur Verfügung, eine wird als Direktzugriff für Proxmox genutzt und die andere ist die öffentliche IP einer virtualisierten OPNsense Firewall.
    ...
    Wieviel Hardware habt ihr da in dem Rechenzentrum? Ist das nur eine Maschine? Oder habt ihr da mehr? Gegebenenfalls auch eigene Netzwerk-Infrastruktur?

    Wenn da mehr als 2-3 Server stehen, würd ich die Infrastruktur anders aufziehen. Dazu unten mehr.
    Zitat Zitat von Illuminatum Beitrag anzeigen
    ...
    Und damit die Proxmox-Oberfläche nicht einfach so im Netz rumhängt, will ich den Zugriff auf die GUI auf die IP unserer Firma und der Partnerfirma begrenzen. Und da Proxmox ja eben eine integrierte Firewallfunktion hat (was die anderen Virtualisierungslösungen nicht haben), bietet es sich ja an, den Zugriff so einzugrenzen. Das ist im Grunde schon alles.
    ....
    So weit, so semi sinnvoll. Du hast den Zugriff auf das WebFrontend zwar reglementiert, aber es hängt immer noch im Netz. Ich würds gar nicht direkt im Netz errrichbar machen, sondern nur über einen Zwischenschritt. (Stichwort Jumphost)
    Zitat Zitat von Illuminatum Beitrag anzeigen
    ...
    Naja, lange Rede, kurzer Sinn. Im Grunde habe ich nun die Regel eigentlich genau so konfiguriert, wie ich im ersten Screenshot dargestellt habe, also lediglich ein ACCEPT für das IPSet. Sonst habe ich nichts angegeben. Natürlich dann die default Regel auf "drop" und siehe da, sobald ich meine IP ändere, komme ich nicht mehr auf die GUI drauf.

    Dazu siehe die cluster.fw:

    Code:
    root@hyper-pve:~# cat /etc/pve/firewall/cluster.fw 
    [OPTIONS]
    
    enable: 1
    policy_in: DROP
    
    [IPSET proxmox-ip] # Proxmox IP
    
    192.168.10.199
    
    [IPSET zugriff_ok] # Erlaubter Zugriff
    
    192.168.10.15 # Temp .15
    192.168.10.200
    
    [RULES]
    
    IN ACCEPT -source +zugriff_ok -log nolog
    Da es wenig Sinn macht, die Proxmox-VM über das NAT irgendwie kontrollieren zu wollen, habe ich der Proxmox-VM eine zweite Netzwerkkarte gegeben als "Netzwerkbrücke" (in proxmox dann vmbr1), dort die "öffentliche IP" 192.168.10.199 eingestellt und damit den Firewallzugriff konfiguriert. Das kommt auch der Produktiv-Umgebung näher

    Sollte das dann so passen? Oder hast du Einwände? Dann gerne mitteilen
    ...
    Es passt, bedingt. Du erlaubst damit den Zugriff von den beiden bekannten IPs aus. Allerdings auf allen Ports und für jedes Target.

    Ich würds aber vielleicht anders machen.
    1. Ein internes Netzwerk, welches nur für die Verwaltung des Clusters und die anderen Hardware-Maschinen dient. Davor entweder nen Jumphost, oder eine entsprechende Router-Maschine mit VPN. Idealerweise nimmt man 2 Jumphosts und/oder Router und noch n VRRP oder sowas dazwischen (BGP wird ja wahrscheinlich nicht ganz einfach für euch um zu setzen, wenn ihr schon nur 2 IPs habt), damit du noch deine Systeme verwalten kannst, sollte der Jumphost mal ausfallen. (Single Point of Failur vermeiden). Aus diesem internen Netz ist dann das ProxMox-Interface zu erreichen.
    2. Den externen Zugang dann wie gehabt über einen Router, der an ein separates internes Netz mit Portforwarding auf die VMs verweist. Auch da kann man dann gegebenenfalls für einen redundanten Zugang sorgen.
    Lookbehind ist offline

  5. #5 Zitieren
    Held Avatar von Illuminatum
    Registriert seit
    Mar 2007
    Ort
    In BW
    Beiträge
    5.203
    Hi!
    Zitat Zitat von Lookbehind Beitrag anzeigen
    Aber wenn es eine richtige Virtualisierung brauchst, würde ich den Hypervisor immer auf Bare-Metal packen. (Ja, VM in VM geht, aber geil ist das nicht.)
    Ist klar Aber im dem Fall geht es mir nicht um Performance oder gar Nutzen, sondern lediglich das Testen von Funktionen in der eigentlichen Verwaltungs-Console.
    Zitat Zitat von Lookbehind Beitrag anzeigen
    Hm, hat Proxmox seine Lizenzen geändert? Meines wissens war die frei verfügbare Version arg eingeschränkt und vor allem nicht Cluster-Fähig.
    Proxmox bietet auch in der kostenlosen Variante Clustering an, deswegen haben wir uns für Proxmox und gegen ESXI entschieden.

    Zitat Zitat von Lookbehind Beitrag anzeigen
    Wieviel Hardware habt ihr da in dem Rechenzentrum? Ist das nur eine Maschine? Oder habt ihr da mehr? Gegebenenfalls auch eigene Netzwerk-Infrastruktur?
    In dem speziellen Fall ist es nur ein mieseliger Server. Und wir sind nur die beiden öffentlichen IPs bekannt. Und im nachhinein noch den Proxmox irgendwie hinter die virtuelle Firewall packen...eh, das müsste ich dann wirklich auf einem realen Testsystem testen. Das System ist schon im Produktiv-Einsatz.

    Zitat Zitat von Lookbehind Beitrag anzeigen
    Ich würds aber vielleicht anders machen.
    1. Ein internes Netzwerk, welches nur für die Verwaltung des Clusters und die anderen Hardware-Maschinen dient. Davor entweder nen Jumphost, oder eine entsprechende Router-Maschine mit VPN. Idealerweise nimmt man 2 Jumphosts und/oder Router und noch n VRRP oder sowas dazwischen (BGP wird ja wahrscheinlich nicht ganz einfach für euch um zu setzen, wenn ihr schon nur 2 IPs habt), damit du noch deine Systeme verwalten kannst, sollte der Jumphost mal ausfallen. (Single Point of Failur vermeiden). Aus diesem internen Netz ist dann das ProxMox-Interface zu erreichen.
    2. Den externen Zugang dann wie gehabt über einen Router, der an ein separates internes Netz mit Portforwarding auf die VMs verweist. Auch da kann man dann gegebenenfalls für einen redundanten Zugang sorgen.
    Danke für die Hinweise. So haben wir das tastächlich bei unserem Notruf-Kunden. Im Rechenzentrum 1 haben wir zwei Securepoint Firewalls im HA Cluster, die nodes sind in einem extra Management-Netz und im ganzen Netzwerk gibt es keine einzige any-Regel, jeder Zugriff/Dienst/Port wird explizit gesetzt, im Rechenzentrum 2 eine eigene Securepoint Firewall. Alle Route liegen auf einer...Cluster-Ebene? Mir fällt das richtige Wort nicht ein, wo grundsätzlich jeder überall hin kommunizieren kann (wir haben neben den beiden Rechenzentren auch noch zusätzlich 1 lokaler Standort und 1 off-site Standort). Und auf dieser Ebene liegen die entsprechenden Firewall-Konfigurationen.

    Bei dem Kunden, wofür ich mein Testsystem aufgesetzt habe brauchen wir das alles nicht. Vor kurzem ist prompt mal das jeweilige Rechenzentrum wegen einem Großbrand ausgefallen: dann konnten die Mitarbeiter halt für einen Tag nicht mehr arbeiten
    Und da reicht es im Prinzip auch, wenn man zumindest den Zugriff auf diese Art etwas einschränken kann. Wir haben ja auch noch den VPN vom Router und dann gibt es auch noch Fernwartungstools für die eigentlichen virtuellen Maschinen. Ich müsste nur dem Proxmox-Server in dem LAN-Netz der virtuellen Firewall eine IP geben...dann kann man auch von innen auf den Proxmox zugreifen (wenn ichs jetzt richtig im Kopf habe).

    Danke für den Hinweis!

    MfG
    Illuminatum ist offline

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •