Proxmox Firewall richtig Einstellen

[RudiP]

Ich habe auf meinem Proxmox eine VM mit HomeAssistant laufen.
Nun habe ich in HomeAssistant gesehen, das da ab und an mal ein Login Versuch einer IP aus Andorra stattgefunden hat.
Ich würde nun gerne die Proxmox Firewall nutzen, um z.B. Andorra komplett auszusperren, eventuell sogar alles aussperren und nur gewisse Geräte zulassen.

Im Rechenzentrum bei Proxmox habe ich die Firewall aktiviert. So wie ich das Verstanden habe, muß die eingeschaltet sein, damit die anderen Firewalls überhaupt arbeiten.
Input Policy: DROP
Output Policy: ACCEPT
Sollte damit nicht eigentlich alles geblockt werden, was von außen rein will ?
Ich habe ansonsten noch keine Regeln definiert. Ich hätte erwartet, das wenn ich an meinem Tablet das WLAN ausschalte und per Mobilfunk in HA rein will, ich dann nicht durch komme.
Die Firewall an der HA VM ist auch aktiviert mit den selben Einstellungen, wie oben.

Anleitungen im Internet habe ich schon versucht, komme damit aber auch nicht wirklich klar.
Kennt jemand ne Anleitung, die erst mal alle Einstellmöglichkeiten vernünftig beschreibt, vorzugsweise auf Deutsch. Bei den englischen Seiten versagt leider zu oft der Übersetzer.
Liege ich mit meiner Vermutung oben richtig ? Firewall eingeschaltet, keine Regeln definiert, dann sollte eigentlich niemand von außerhalb da rein kommen ?

 

[blurrrr]

Wo genau hast Du die Regeln denn gesetzt? Es ist ein Unterschied, ob Du die Default-Regeln setzt (wo dann automatisiert auch Ausnahmen bestehen), oder bei der VM. Für den PVE-Host ist die INPUT-Chain definitiv nicht richtig, das gehört dann in den Firewall-Teil der gewünschten VM.

INPUT = Host eingehend
OUTPUT = Host ausgehend
FORWARD = Weiterleitend (für Pakete, die ein Interface nur durchqueren, aber schlussendlich ein anderes Ziel haben)

Am Beispiel einer davor sitzenden Hardware-Firewall wäre es halt:

INPUT = eingehend zur Firewall
OUTPUT = ausgehend von der Firewall
FORWARD = für die Netze/Hosts hinter der Firewall

Kannst auch mal schauen, was beim Befehl iptables-save auf dem PVE-Host ausgegeben wird.

Betreffend der Firewall-Regeln für die VM/Container kannst Du nochmal einen Blick auf diesen Teil werfen.

Bei den englischen Seiten versagt leider zu oft der Übersetzer.

Die Doku wäre die beste Anlaufstelle und ist leider nur in englischer Sprache verfügbar.

 

[RudiP]

Wo genau hast Du die Regeln denn gesetzt?

ICH habe keine Regeln gesetzt. Das ist die Standard Einstellung, wenn man die Firewall aktiviert.
Ich hatte erst in der HA VM die Firewall aktiviert. Da steht dann der Hinweis, das die Firewall im Rechenzentrum auch aktiviert sein muß, also habe ich die da auch aktiviert.
Und dann steht bei beiden in den Firewall -> Optionen eben
Input Policy: DROP
Output Policy: ACCEPT
Hießt für mich, nix kommt rein (außer die standard freigaben) aber alles kann raus.
Und genau das funktioniert noch nicht

Kannst auch mal schauen, was beim Befehl iptables-save auf dem PVE-Host ausgegeben wird.

Kennst das doch. Gehe ich in der VM auf Konsole, lande ich in der Eingabe von HA. Keine Ahnung, wie ich da auf die OS Ebene kommen soll.

Betreffend der Firewall-Regeln für die VM/Container kannst Du nochmal einen Blick auf diesen Teil werfen.

Schaue ich mir an.

 

[blurrrr]

Den Befehl sollst Du auf dem PVE-Host ausführen

Datacenter Firewall aktivieren, danach nochmal die gewünschten Regeln bei der VM-Firewall setzen (im PVE-Interface bei der VM, nicht in der VM-Shell).

 

[RudiP]

Na sag das doch nem blutigen Anfänger.
Ja, Befehl ausgeführt, aber was er da anzeigt, kann ich mir auch Spaghetti in Tomatensoße ansehen, erkenne ich genauso wenig.

Den Link, den Du mir geschickt hattest, führt auch nur auf die Proxmox Seite mit der Hilfe in englisch. Ja, da kann Chrome diese dann wenigstens ins Deutsche übersetzen, aber so richtig hilfreich war das immer noch nicht.
Die Grundfrage bleibt ja. Wenn ich die Firewall aktiviere, sollte jede ankommende Verbindung geblockt werden.

Das sieht man bei "Rechenzentrum -> Firewall -> Optionen"
Gehe ich in die HA VM auf "Firewall -> Optionen" sehe ich das.

Warum komme ich dann von außen immer noch an HA dran ? Dürfte doch eigentlich nicht mehr.

 

[RudiP]

Jetzt bin ich mir auch Sicher, das die Firewall in Proxmox nicht läuft, weil diese Nacht wieder unser Andorra Freund einbrechen wollte.
HA hats gemerkt, die Proxmox Firewall nicht.
In der VM hatte ich folgende Regel erstellt.

Hatte ich Gedacht, wenn einer mit der IP xxx.xxx.xx.xx und via HTTPS kommt, das die Firewall ihn dann blockt.
Tja, falsch gedacht. Der war diese Nacht wieder da.
Nein, ich habe diese Regel nicht im Rechenzentrum eingegeben. Es muß ja möglich sein, zu sagen, das eine bestimmte IP zwar auf eine gewisse VM darf, aber auf eine andere nicht. Diese IP dann im Rechenzentrum blocken würde die ja für alle VM's blocken.
Hab jetzt mal "Makro: HTTPS" raus genommen und "Protokoll: tcp" eingestellt. Mal schauen, ob es damit klappt.

 

[blurrrr]

Also zum einen ganz "global" unter:

Datacenter | Firewall -> Optionen -> "Firewall" aktivieren ("yes")
Datacenter | Firewall -> sonstige gewünschte Regeln (Default-Ausnahmen lt. Doku greifen sowieso)

Zum anderen spezifisch für die VM:

Datacenter | <PVE-Host> | <VM> | Firewall -> gewünschte Regeln (auch hier greifen schon Default-Ausnahmen)

Hast Du das auch so gemacht?

In der VM hatte ich folgende Regel erstellt.

Das liest sich ja nun wie letzteres (Datacenter|PVE-Host|VM), die Frage ist nur... Ist das Ding auch von aussen via 443/TCP erreichbar? Aber davon ab... willst Du wirklich "nur" HTTPS verbieten? Also bei mir wäre die Regel eher in die Richtung "is mir völlig egal wat wie wo, ob rein, raus, mittendrin oder auch nur dran vorbei, das Ding hat hier nix verloren...", von daher würde ich da auch so wenig wie möglich angeben.

Wie gesagt, wenn etwas nicht wie gewünscht funktioniert, iptables-save in der PVE-Shell eingeben. Was mit noch aufgefallen ist... bzw. was generell ratsam wäre...

Zum einen wählst Du Source aus, da wird dann direkt etwas mit "Type, Name und Comment" gelistet (Spaltenüberschriften. Die Angabe einer IP-Adresse scheint mir dort nicht ganz korrekt zu sein (mag mich aber auch irren). Hatte nun mal a) ein Alias angelegt und b) ein IP-Set (letzteres halte ich in Deinem Fall auch für sinnvoller, da kann man dann immer weiter unerwünschte Hosts reinpacken). Diese tauchen dann auch sofort zur Auswahl in der Firewall-Regel im VM-Kontext auf:



Vielleicht funktioniert es so ja besser... aber so oder so, würde ich "immer" auf der PVE-Shell mittels iptables-save schauen, ob das auch alles passt.

 

[RudiP]

Datacenter | Firewall -> Optionen -> "Firewall" aktivieren ("yes")
Datacenter | Firewall -> sonstige gewünschte Regeln (Default-Ausnahmen lt. Doku greifen sowieso)

Zum anderen spezifisch für die VM:

Datacenter | <PVE-Host> | <VM> | Firewall -> gewünschte Regeln (auch hier greifen schon Default-Ausnahmen)

Hast Du das auch so gemacht?

So hatte ich es anfangs gemacht, einmal komplett neu gestartet. Dann dem Tablet das WLAN genommen, so das er via Mobilfunk zu mir nach Hause telefoniert und dann HA aufgerufen und, schwupps, drin. Was aber eigentlich gar nicht sein dürfte, da ja per DEFAULT alles gesperrt sein sollte, außer Port 8006 und Port 22.
Da das also nicht funktioniert hatte, habe ich dann versucht, mir Regeln weiter zu kommen.

Das liest sich ja nun wie letzteres (Datacenter|PVE-Host|VM), die Frage ist nur... Ist das Ding auch von aussen via 443/TCP erreichbar?

HA auf jeden fall. Zugriff von unterwegs erfolgt via DUCKDNS mit HTTPS, damit also Port 443.
Im Router eine Freigabe 443 extern auf 8123 intern.
Lustig ist, die ist deaktiviert und trotzdem komme ich rein. Ob der über IPv6 kommt ? Mal testen.
IPv6 Freigabe deaktiviert, Tablet wieder auf Mobilfunk. HA App aufgerufen und schwupps, drin.
Irgendwie mogelt sich die HA App an den Freigaben vorbei.
Ok, irgendwas läuft gerade komplett schief. Port 443 habe ich nochmal im Router frei gegeben und die IPv6 zu gemacht.
Dann vom Tablet einen Portscan auf meine externe IP und der sagt, alle Port sind zu.
Egal, schaue ich mir später an. Tut ja an dem Firewall Problem nix.

Aber davon ab... willst Du wirklich "nur" HTTPS verbieten? Also bei mir wäre die Regel eher in die Richtung "is mir völlig egal wat wie wo, ob rein, raus, mittendrin oder auch nur dran vorbei, das Ding hat hier nix verloren...", von daher würde ich da auch so wenig wie möglich angeben.

Wenn Du mir in den Einstellungen der Firewall bei Proxmox ein "Protokoll: ALL" oder "Makro: ALL" zeigen kannst, gerne.
War auch nur einer der Versuche, das System irgendwie dicht zu machen.

Wie gesagt, wenn etwas nicht wie gewünscht funktioniert, iptables-save in der PVE-Shell eingeben. Was mit noch aufgefallen ist... bzw. was generell ratsam wäre...

Wie gesagt. Die Ausgabe dieses Befehl sieht aus wie ein Teller Nudeln mit Tomatensoße.

Zum einen wählst Du Source aus, da wird dann direkt etwas mit "Type, Name und Comment" gelistet (Spaltenüberschriften. Die Angabe einer IP-Adresse scheint mir dort nicht ganz korrekt zu sein (mag mich aber auch irren).

War auch nur ein Versuch. IPListen erschien mir auch besser geeignet, aber ich wollte auch nicht an zu vielen Schrauben drehen, sonst verläuft man sich oder es geht gar nichts mehr.

Vielleicht funktioniert es so ja besser... aber so oder so, würde ich "immer" auf der PVE-Shell mittels iptables-save schauen, ob das auch alles passt.

Ich schick Dir den Output gleich mal als PN, dann darfst Du mir gerne sagen, was er da den anzeigt.

 

[RudiP]

Ok, den Fehler, warum ich trotz fehlender Port Weiterleitung immer noch an HA dran gekommen bin, ist gefunden.
Ich habe aktuell zwei Router. Einer für DSL, der andere am Glasfaser.
Der am DSL, die FritzBox, hatte eigentlich immer die Port Weiterleitungen gemacht. Hab glatt vergessen, das ich die in dem Glasfaser Router auch schon eingerichtet hatte.

 

[RudiP]

So, den Fehler, warum die Firewall nichts blockte, habe ich nun auch gefunden.
In den Einstellungen zur VM auf Hardware -> Netzwerkkarte. In dem auf ploppenden Fenster gibt es einen kleinen unscheinbaren, leicht zu übersehenden Kasten "Firewall". Dort einen Haken gesetzt und schwupps, wurde alles geblockt, so wie ich es laut der Anleitung auch erwartet hatte.
Danach dann bei der Firewall -> Optionen das "Input Policy" auf ACCEPT, also erst mal alles rein lassen, damit MQTT und externe Zugriffe auch wieder gehen.
Dann definiere ich jetzt mal Regeln, die gewisse IP's blocken und hoffe, das dies nun endlich klappt.

 

[blurrrr]

Jut... ist natürlich ein Argument... War mir nicht so, als wäre der Haken sowieso standardmässig bei der Erstellung einer neuen VM aktiviert? So sieht das jedenfalls bei mir aus:



Nach der Erstellung ist bei der NIC dann auch entsprechend der Eintrag "firewall=1" vorhanden.

Aber jut, sei's drum, hauptsache ist ja, dass Du den Übeltäter gefunden und das Problem behoben hast

 

[RudiP]

Übeltäter gefunden, das zumindest die Firewall mal geht.
Aber nun geht sie zu gut.
Im Rechenzentrum (Datacenter) habe ich bei Firewall Optionen "Input policy = ACCEPT" gesetzt, damit die mal alles rein lässt.
Bei der VM Firewall Optionen "Input Policy = ACCEPT"
Aber, HA verliert schlagartig die Verbindung zu einigen Sensoren.
Obwohl Log_Level_ in auf debug steht, wird im Log nichts von einem Block angezeigt.

Schalte ich die Firewall in der VM aus, läuft alles wieder.

(20 Minuten später)
Ok, den Übeltäter auch gefunden.
In der VL bei Firewall -> Optionen gibt es den Eintrag "IP-Filter". Den hatte ich auf JA gesetzt, weil ich dachte, das er damit auch IP's filtert. Hatte ja nicht gedacht, das er dann alles Filtert.

Nach Hinweis unseres nichtswissenden Freundes blurrr habe ich dann auch IPSet eingerichtet und dort die bekennaten IP's des Andorra Hacker Kid eingetragen.
Wenn ich jetzt einen IP Bereich sperren will, sagen wir mal 111.7.96.0 bis 111.7.96.255, ist es dann richtig, das ich beim IPSet einen Eintrag "111.7.96.0/24" mache ?

 

[blurrrr]

Wenn ich jetzt einen IP Bereich sperren will, sagen wir mal 111.7.96.0 bis 111.7.96.255, ist es dann richtig, das ich beim IPSet einen Eintrag "111.7.96.0/24" mache ?

Das sollte soweit korrekt sein, "/24" entspricht dem Block x.x.x.0-255. Ein /16 wäre "x.x.0-255.0-255" und ein /32 wäre eine einzelne IP. Dazwischen gibt es natürlich auch noch Bereiche (Stichwort Subnetting). Faktisch ist es halt so, dass sich - durch die Verschiebung der Bits für den Netzwerk-Anteil - die Subnetze "verdoppeln" oder "halbieren" (irgendwas dazwischen gibt es nicht). Mal als kurzen Abriss am Beispiel eines /24er Netzes:

192.168.0.0/24 (255.255.255.0) = 192.168.0.0 bis 192.168.0.255

192.168.0.0/25 (255.255.255.128) = 192.168.0.0 bis 192.168.0.127

192.168.0.0/23 (255.255.254.0) = 192.168.0.0 bis 192.168.1.255

Der wesentliche Punkt dabei ist, dass Provider i.d.R. mehr als "nur" ein /24er nutzen bzw. ein /24er ggf. auch nur ein Teil eines grösseren Netzes ist. Teilt man z.B. ein /23 in 2 gleichgroße Netze, erhält man dadurch 2x /24 (s. letztes Beispiel, könnte auch aufgeteilt werden in 192.168.0.0/24 + 192.168.1.0/24). Oftmals sind es halt wesentlich grössere Netze, Provider brauchen halt viele IPs.

und dort die bekennaten IP's des Andorra Hacker Kid eingetragen.

Hier wäre es vermutlich ratsam, wenn man mal schaut, wozu die IP eigentlich gehört (Provider) und dort mal schaut, wie das entsprechende Netz generell aussieht. Wir gehen einfach mal davon aus, dass Du von diesem Provider sicherlich keinen Zugriff auf Dein HomeAssistant benötigst und der Provider hat z.B. nur ein großes Netz (ggf. aufgeteilt in viele kleinere) könnte man sich mit dem gemeinsamen grössten Nenner behelfen und z.B. auch ein /20er oder /18er sperren. Je nachdem halt, was genau Du "weg" haben möchtest.

Auf der anderen Seite ist das mit den Netzen immer so eine Sache, da es dafür auch einen ganz normalen Markt gibt. Zum einen haben die wenigsten Provider "ein einziges" großes Netz, welches aufgeteilt wurde, sondern haben im Laufe der Zeit immer weitere Netze dazu gekauft. So entsteht dann ein bunter Haufen aus diversen (nicht zusammengehörigen) Netzen. Bei großen Providern können es hunderte sein. Dazu der Umstand, dass Netze auch gekauft/verkauft werden. Die Netze können also auch die Besitzer wechseln. Das aber nur mal als allgemeine Info am Rande

 

[RudiP]

Gibt es dazu eine einleuchtende Erklärung, warum "/24" 256 IP'S blockiert, ein "/16" aber 65.536 IP's blockiert ?

Mir reicht es erst mal, wenn ich die IP's sperren kann, die mir HA anzeigt, das da mal wieder jemand versucht hat, rein zu kommen.
Klar könnte ich auch gesamt Ansorra aussperren, aber wie Du schon sagtest, wird das auch nicht immer helfen.
Und wenn er dann mit VPN oder gar BOT Netzen kommt, macht es wohl gar keinen Sinn mehr, dann wäre es sicher Sinnvoller, alles zu sperren, außer dem, was man sicher freigeben will.
Nur sehe ich da halt das Problem, das man irgendwann mal irgendwas neues macht, es nicht funktioniert und an die Firewall, die alles blockt, als letztes Denkt.

Ich versuchs erst mal so. Scheint mir bisher so, als wenn er 2, 3 IP Bereiche nutzt. Die kann ich sicher blocken. (Nachdem ich begriffen habe, was Proxmox mit seiner Firewall von mir will.

 

[blurrrr]

Gibt es dazu eine einleuchtende Erklärung, warum "/24" 256 IP'S blockiert, ein "/16" aber 65.536 IP's blockiert ?

Klar, in einem /16er hast Du "256" mal ein /24:

/24 = 1x 256 Adressen (x.x.x.0 bis x.x.x.255) = 256 Adressen
/16 = 256x 256 Adressen (x.x.0.0 bis x.x.255.255) = 65536 Adressen

Ich hatte es vorhin schon geschrieben, da es mir doch ein bisschen "viel" erschien, aber wenn da Klärungsbedarf ist, kein Ding:

Bei der CIDR-Schreibweise ("/24") werden die "Netzwerk"-Bits gezählt (Gegenstück sind die "Host"-Bits, also der Bereich, welcher dann für die Adressen zur Verfügung steht). Das Beispiel /24 aka 255.255.255.0 kennst Du ja schon. Binär geschrieben sieht das nun wie folgt aus:

11111111.11111111.11111111.00000000

Bei der CIDR-Schreibweise werden - wie gesagt - die Netzwerk-Bits gezählt. Zählst Du diese Bits jetzt mal zusammen (3 Oktette mit "1" = 24 Bits). Bleiben 8 Bit (1 Oktett, das letzte) für den Host-Anteil. Nun muss man noch wissen, dass diese Bits in jedem Oktett einer Wertigkeit unterliegen. Diese Zahlen kennst Du auch schon: 128+64+32+16+8+4+2+1. Gezählt werden nur jene, welche auf "1" stehen bzw. zum Netzwerk-Anteil gehören. Zählst Du alle in einem vollen Oktett zusammen, ergibt das "255". Somit ergibt sich:

11111111.11111111.11111111.00000000 = 255.255.255.0 oder /24

Nun kann man die Netzbereiche immer nur "verdoppeln", oder "halbieren". Dies erreicht man, indem man die Bits "verschiebt". Mal 2 Beispiele dazu:

11111111.11111111.11111111.10000000 = 255.255.255.128 oder /25 (=128 Adressen)
11111111.11111111.11111110.00000000 = 255.255.254.0 oder /23 (=512 Adressen)

Üblicherweise wird sowas genutzt, um vorhandene Netzbereiche entsprechend aufzuteilen. Hier nochmal ein paar Beispiele zu den beiden o.g. Beispielen. Ausgangslage ist jeweils "192.168.0.0/24":

Zunächst einmal "halbieren" wir das Netz, wodurch 2 neue Netze entstehen:

192.168.0.0/25 = 192.168.0.0bis 192.168.0.127 (Subnet-Maske = 255.255.255.128)
+
192.168.0.128/25 = 192.168.0.128 bis 192.168.0.255 (Subnet-Maske = 255.255.255.128)

Wenn wir den Netzbereich verdoppeln, dann sieht es wie folgt aus:

192.168.0.0/23 = 192.168.0.0 bis 192.168.1.255 (Subnet-Maske = 255.255.254.0)

Mit einer Fritz!Box geht es eher weniger vernünftig, aber wenn man etwas besseres in Richtung Firewall nutzt, kann man sich so auch kleinere Netz-Segmente gestalten. Ein typisches Beispiel wäre z.B. ein "/30". Für jedes Netz gilt "Anzahl der Adressen abzgl. min. 2" (eigentlich sind es aber i.d.R. abzgl. "3"), warum das so ist, hier als Beispiel eines /30er Subnetzes:

192.168.0.0/30 = 4 Adressen:
.0 = Netz-ID
.1 = Gateway
.2 = Host
.3 = Broadcast

Netz-ID und Broadcast-Adresse sind "immer" vorhanden ("-2"). Ein Netz ohne Gateway ist i.d.R. recht nutzlos, von daher kommt hier nochmal ein "-1" oben drauf. Das ist dann die kleinste sinnvolle Netzgrösse für einen Host samt Gateway. Aus einem /24 könnte man somit 64 mal ein /30 bauen (0-3, 4-7, 8-11, usw.). Sowas kommt aber eigentlich eher bei akutem Platzmangel, oder (teuren) öffentlichen IP-Netzen zum tragen. Will man Zuhause segmentieren, geht man i.d.R. eher hin und "schmeisst" mit den Netzen nur so um sich, denn per Definition (ein typisch genutzter "privater" Netzbereich wäre z.B. 192.168.0.0/16) passen in das exemplarische Netz 256 von den /24er Netzen (192.168.0-255.0-255). Von daher kann der Schuster auch einfach bei seinen Leisten bleiben.

"Sollte" man "jemals" in die Verlegenheit kommen, dass ein /24 nicht mehr ausreicht (ich denke hier speziell an die Smarthome-Fraktion ), kann man das Netz natürlich auch vergrössern. Allerdings erhöht sich auch die Anzahl der Broadcasts (Rufe ins Netz an "alle"), worunter das Netz allgemein schon etwas leiden kann (halt wie eine überfüllte Autobahn). Da würde es dann vermutlich auch mehr Sinn machen, wenn man die Gerätschaften gruppiert und ggf. in eigene Netze steckt - spätestens bei grösseren Problemen/Latenzen sollte man mal darüber nachdenken.

 

[RudiP]

Ja, Verstehe.
bei meiner Frau schreibe ich dann ein 0.0.0.0/1, dann kann sie das Internet nicht mehr leer saugen.

Danke für deine Ausführlichen Erklärungen. Jetzt wird mir manches klarer.
IP Adresse ist 32 Bit und mit dem "/XX" kann ich jedes Bit maskieren bzw. ausblenden.

 

[blurrrr]

bei meiner Frau schreibe ich dann ein 0.0.0.0/1, dann kann sie das Internet nicht mehr leer saugen.

Naja, zumindestens das "halbe", komplett wäre 0.0.0.0/0, 0.0.0.0/1 ist der Bereich von 0.0.0.0 bis 127.255.255.255

IP Adresse ist 32 Bit

Korrekt, etwas anders verhält es sich mit IPv6, da ist der Hintergrund mit der Netzwerk-Maske aber auch der selbe, nur geht es da nicht "nur" bis 32, sondern bis 128, ist also schon ein "bisschen" mehr an Adressen in Summe