Wohin mit der Firewall ?

[Rocky]

Hallo Forum,

ich taste mich gerade langsam an das Thema Firewall ran.
Sicher wäre die beste Lösung das Netz zu Hause zu segmentieren wie man das üblicherweise so macht.
Davon abgesehen dass die FW hinter der Fritzbox dann auch das Portforwarding schwieriger macht, ist das größte Problem wieder mal der Layer-8: Ich trau mir das ganze auf einen Rusch noch nicht zu.

Jetzt meine Überlegung: Ich integriere die FW erst mal ins bestehende Netz und konfiguriere auf allen Geräten die FW als Gateway und nicht mehr die Fritzbox.
Somit würde der gesamte Traffic über die FW laufen und ich könnte/müsste dann eben über entsprechende Regeln bestimmen wir mit wem wohin darf. Das wäre im Heimnetz noch überschaubar und ich könnte nach und nach die Geräte umstellen und nicht alles auf einmal.

Wo ist mein Denkfehler, bzw. welche Nachteile handle ich mir damit ein ?

Viele Dank für Euere Ideen

[magicteddy]

Moin,

halt, anderer Vorschlag der es Dir vielleicht noch einfacher macht. ;) Ausgehend von folgendem Zustand:

Internet --> Fritte (WAN DHCP / LAN 192.168.178.1) --> Geräte im LAN (192.168.178.0/24)

machst Du daraus:

Internet --> Fritte (WAN DHCP / LAN 192.168.200.1) --> OPNsense (WAN: 192.168.200.2 / LAN: 192.168.178.1) --> Geräte im LAN (192.168.178.0/24)
Eventuell musst Du einige DHCP Leases anpassen / erstellen, aber sonst brauchst Du nix umzukonfigurieren.

Warum werden Portweiterleitungen schwieriger? Du könntest Deine OPNsense einfach als exposed Host in der Fritte eintragen, dann geht alles was die Fritte nicht irgendwie nutzt (Telefonie?) ungefiltert an Deine OPNsense und Du hast nur noch eine zentrale Baustelle fürs Netzwerk.

-teddy

[theq86]

Die Fritz!Box hinter der OPNsense ist zwar machbar aber nicht schön. Aus mindestens 2 Gründen:

- Doppeltes NAT: von Internet ins Fritz Netz und vom Fritz Netz ins OPNsense Netz. Ist zwar meist nicht problematisch aber es gibt Protokolle wie SIP oder IPSec denen schmeckt sowas gar nicht

- WLAN: Die meisten nutzen die Fritz!Box auch als Access Point. WLAN Geräte sind in diesem Setup nicht im LAN Netz. Und umgehen in Richtung Internet die Firewall. Für den Zugriff von WLAN Clients ins LAN sind dann Portfreigaben fällig, eine direkte Verbindung Ende zu Ende ist wegen des zweiten NAT nicht möglich.

Ich würde das ganze einfach mal auf virtueller Basis machen.

- In VirtualBox ein Host-Only Netzwerk einrichten mit IP 192.168.1.2 (das ist die IP deines Rechners im HostOnly Netzwerk)

- VirtualBox installieren, eine OPNsense Instanz aufbauen mit 2 Netzwerkinterfaces
- Netzwerk 1: Bridged auf deine LAN/WLAN Karte
- Netzwerk 2: HostOnly Netzwerk von oben
- OPNsense konfigurierst du WAN-seitig mit Netzwerk 1 und DHCP, LAN-seitig mit fester IP 192.168.1.1

Effekt:
Du hast eine OPNsense, die über die Netzwerkkarte deines Rechners mit Internet gespeist ist. Und du hast ein virtuelles Netzwerk 192.168.1.0/24. Über deinen Rechner erreichst du die Sense mit 192.168.1.1 und dein eigener Rechner hat die 192.168.1.2.

Jetzt kannst du nach Belieben weitere virtuelle Rechner starten in VirtualBox. Gebe ihnen als Netzwerkinterface ienfach das HostOnly Netzwerk und sie werden somit LAN Rechner für deine OPNsense. So kannst du auch nach Belieben testen

[magicteddy]

Moin,

ok, IPSec nutze ich nicht, ich nutze OpenVPN, aber SIP läuft hier absolut stressfrei. WLan über die Fritte abzuwickeln habe ich mir abgewöhnt seit ich die Unifi AP kennengelernt habe. Was ich vorher mit 3 Kisten in frittenqualität mit WLan abgedeckt hatte schafft in meinen Fall auch ein Unifi AP :P Nichtmal unsere beiden Daddelkings beschweren sich über Probleme bei Onlinegames, also hier: DoubleNAT = Null Problemo 8)

-teddy

ps.: Firewall virtualisieren? Zu Testzwecken klar, kein Ding im echten Betrieb? Zur Zeit eher nicht mein Ding siehe Spectre und Meltdown. Ich befürchte da kommt noch mehr auf uns zu  :'(

[Rocky]

Vielen Dank für Euere Hinweise !

@magicteddy: Dein Vorschlag ist eine Weltidee ! Wird gleich notiert *kritzel

Zu Test- und Einarbeitungszwecken habe ich OPNsense im Moment ohnehin in einer VM laufen und werde sie mal nach dem Vorschlag von nasq umkonfigurieren. Muss nur schauen, dass ich es hinbekomme dass OS dann meinen DNS-Server (PiHole) nutzt...
Und dann heißt es: Wir lernen Regeln schreiben..

[theq86]

ps.: Firewall virtualisieren? Zu Testzwecken klar, kein Ding im echten Betrieb? Zur Zeit eher nicht mein Ding siehe Spectre und Meltdown. Ich befürchte da kommt noch mehr auf uns zu  :'(

Gegen virtuelle Applicances ist eigentlich nichts einzuwenden, da auch reale Hardware von Meltdown/Spectre angreifbar ist. Gepatcht werden sollten generell alle Systeme im Livebetrieb. Meltdown ist eingedämmt, Spectre 1 auch. Zumindest wenn die Patches mal alle überall verteilt werden ohne die Systeme zu zerschießen. Spectre 2 soll ja auch irgendwann durch neue Hardware Ende des Jahres gefixed werden (mal sehen ob das so kommt)

Allerdings gibt es für Spectre noch keinen wirksamen Angriff und es ist auch nicht mal einfach so aus dem Internet auszunutzen.

[magicteddy]

...
Allerdings gibt es für Spectre noch keinen wirksamen Angriff und es ist auch nicht mal einfach so aus dem Internet auszunutzen.

Es geht mir nicht um Angriffe aus dem Internet. Hast Du die Firewall auf dem Blech laufen musst Du dort auch einen potenziellen Schädling drauf bekommen. Ohne physischen Zugriff ist das garnicht so einfach. Hast du es aber virtualisiert und laufen auf dem Blech weitere Maschinen dann kannst Du nicht sicher sein das ein Ausbruch aus der VM nicht deine Systeme Kompromittieren kann. Es gibt sicherlich noch weitere Lücken in diese Richtung von denen wir noch nichts ahnen  :'(
Über Wahrscheinlichkeiten brauchen wir uns nicht zu streiten. Ich habe es halt auf einer APU2 am laufen und da läuft nichts anderes, also habe ich für mich das Risiko minimiert.

Muss nur schauen, dass ich es hinbekomme dass OS dann meinen DNS-Server (PiHole) nutzt...

PiHole als VM oder auf nem Raspi? Du musst halt nur dafür sorgen das OS Dein PiHole per IP erreichen kann, wenn echte Hardware dann einfach an den Switch der Fritte klöppeln und in OS als Nameserver eintragen und habe fertich  ;D Wenn als VM dann mit der WAN Seite der OS verheiraten und eintragen und habe fertich.

-teddy

[theq86]

Das Hostsystem auf dem die VMs laufen müsste aber auch erstmal physisch kompromittiert werden.
Wer natürlich die Firewall auf dem selben Host virtualisiert, auf dem er auch Webserver oder andere externe Tools hostet der hat natürlich auch selbst Schuld. Wobei das Ausbrechen aus einer VM an sich nicht trivial ist.

[magicteddy]

Moin,

es braucht nichtmal ein Webserver sein, ich stell mir einfach vor jemand baut seine Surfstation als VM, das Image ist gesichert so kann er die Kiste jederzeit ratzfaz wieder herstellen. Und jetzt nutzt er die Kiste um Raubsoft P0rn oder sonstiges auzuprobieren, soger ein veralteter Browser reicht schon.
Das die Surfstation verseucht wird hat er einkalkuliert aber der Rest ...

-teddy

[JeGr]

> Das Hostsystem auf dem die VMs laufen müsste aber auch erstmal physisch kompromittiert werden.

Nö. Das wurde m.W. auch schon demonstriert, dass es AUS der VM heraus möglich war, den hypervisor zu treffen bzw. in eine andere VM rauszuschlagen, und sei es nur, dass Bruchstücke aus RAM o.ä. gelesen werden.

Da bin ich ganz bei Teddy (das weiß er aber ;)) und stehe da weiter dazu, dass man gern Firewalls in VMs packen kann, aber nicht auf den gleichen Cluster, auf dem dann Cloud(-ähnliche) Sachen laufen. Virtualisierung ist momentan nicht der Grund für Meltdown und Spectre, sondern genau die Hardware. Aber - und das sieht man in den vielen Berichten die sich damit beschäftigen - genau dort bei Cloud Hosting, Shared Hosting, etc. bieten sich den beiden am meisten Angriffsfläche. Und natürlich auf dem Client zu Hause. Da sind die Daten die man abgreifen möchte oder die man kompromittieren will. *sense auf einer dedizierten Hardware? Not so much. Klar mag die HW angreifbar sein, aber die PoCs basieren fast alle auf einem authorized User. Und die Sensen haben allerhöchstens Admins aus einem Management Netz oder LAN die sich drauf einloggen. Angriffsfläche minimal. Sitzt die Kiste jetzt aber als VM irgendwo, dann kann mir vielleicht plötzlich eine andere VM über den HV an die FW VM. Und das Risiko muss man abschätzen, bewerten und einbeziehen. Mag für einige klein/vernachlässigbar sein, für uns ist es das nicht. Daher extra Kisten. :)

[monstermania]

Da bin ich ganz bei Teddy (das weiß er aber ;)) und stehe da weiter dazu, dass man gern Firewalls in VMs packen kann, aber nicht auf den gleichen Cluster, auf dem dann Cloud(-ähnliche) Sachen laufen.

Da kann ich nur 100% zustimmen.
Virtualisierung ist auch bei FW inzwischen absolut üblich. Wir betreiben inzwischen seit 2014 unseren Firmen UTM-HA-Cluster virtuell.
Auf den beiden VM Hosts läuft halt ausschließlich die UTM Software als VM.
Der Grund  dafür ist ganz einfach der Herstellersupport. Der UTM Anbieter supported ausschließlich die eigene Hardware oder eben ein Einsatz seiner Lösung als VM. Eine native Installation auf unserer eigenen HW wäre zwar möglich gewesen, aber eben unsupported.
Von unserem VMWare-Partner weiß ich, dass virtuelle FW inzwischen absolut üblich sind.

[chemlud]

Nur weil es "üblich" ist, heißt das noch lange nicht, dass es sinnvoll/sicher ist. Meist wird eher umgekehrt ein Schuh draus... ;-)

[monstermania]

@chemlud
Mit dem gleichen Totschlag-Argument kannst Du auch gegen den Einsatz von Proxy/AV-Software/Spamfilter/usw. auf einer Firewall argumentieren.  ;)
Früher war eine Firewall wirklich ausschließlich eine Firewall. Aber heute erwartet der Anwender zumeist keine reine Firewall mehr sondern eine UTM. Liegt nunmal in der Natur der Sache, dass jeder zusätzliche Dienst der auf der gleichen Platform läuft ein zusätzliches Risiko mitbringt.

[chemlud]

Das ist eine Risikoabwägung, die jeder für seinen Anwendungsfall abwägen muss. Firmen, Datensicherheit und dieser virtual-Quatsch passen nicht zusammen.

Hat doch im letzten Jahr erst wieder ein Hacker 100.000 Dolar abgeräumt, weil er innerhal von kürzester Zeit aus der VM in den Host gestiegen ist. Finger weg von solchem Unfug. Aber sind ja nicht meine Daten! :-)

[monstermania]

Hat doch im letzten Jahr erst wieder ein Hacker 100.000 Dolar abgeräumt, weil er innerhal von kürzester Zeit aus der VM in den Host gestiegen ist. Finger weg von solchem Unfug. Aber sind ja nicht meine Daten! :-)

Oh, damit hast Du natürlich den Beweis gebracht, dass Virtualisierung per se absolut unsicher ist.  ;D
Falls Jemand es etwas dataillierter wissen möchte: https://www.heise.de/newsticker/meldung/Hacker-brechen-aus-virtueller-Maschine-aus-3658416.html

Aber der Punkt mit der Risikobeurteilung ist absolut richtig. Jedes Unternehmen muss pot. Risiken und Vorteile gegeneinander abwägen. Ob und wie dann eine Entscheidung gefällt wird, sollte man jedoch als Außestehender nicht pauschal negativ beurteilen ohne alle Hintergründe zu kennen.