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
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
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
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 :'(
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..
Quote from: magicteddy on February 04, 2018, 11:50:29 PM
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.
Quote from: nasq on February 05, 2018, 11:12:19 AM
...
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.
Quote from: Rocky on February 05, 2018, 08:02:17 AM
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
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.
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
> 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. :)
Quote from: JeGr on February 05, 2018, 04:44:59 PM
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.
Nur weil es "üblich" ist, heißt das noch lange nicht, dass es sinnvoll/sicher ist. Meist wird eher umgekehrt ein Schuh draus... ;-)
@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.
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! :-)
Quote from: chemlud on February 06, 2018, 11:14:29 AM
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.
Genau. Dazu, dass das Beurteilungssache ist, muss man nichts mehr hinzufügen. Dass es Ausbrüche aus dem HV schon gab, auch das (wobei es hier um Workstation ging, nicht um Cluster/vcenter - ergo ein wenig hinkender Vergleich). Aber es wird gerade was Servervirtualisierung angeht, kaum noch jemand heute Lust haben, für viele Anwendungsszenarien unnötig Geld liegen zu lassen - und für 3-4 Server Hardware zu kaufen ist genau das. Da genügt meist eben eine/zwei HW Kisten und den Rest virtuell da rauf. Aber da gehts eben mit der Abwägung los. Die stehen ggf. intern oder DMZ, also Kritisch oder nicht kritisch. Aber den schützenden Faktor da auch noch raufzupacken - naja da ist meine Schmerzgrenze ;) Bei anderen liegt die höher oder niedriger. Manches Mal hat man aber gar keine Wahl bspw. Hosting irgendwo, wo es keine vorgeschaltete Firewall o.ä. gibt. Da ist man dann froh, wenn man wenigstens mit dem Clou der vorgeschalteten VM noch ein wenig Sicherheit und Filterung dazu bekommt.
Ansonsten wirds eben immer mehr als ein Lager geben ;)
Quote from: nasq on February 04, 2018, 04:45:49 PM
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
Ich habe meine OPNSense jetzt nach dieser Idee in der VM umkonfiguriert. Geht soweit. Allerdings lässt er kein FTP mehr zu, obwohl ich den FTP-Proxy konfiguriert und an der FW erst mal die LAN to ANY Regel gelassen habe.
Wo kann ich denn einsehen, wo FTP geblockt wird ? Ich finde in keinem Protokoll einen Eintrag :-(
Was ich auch festgestellt habe: In der FW habe ich meinen internen DNS-Server eingetragen, ich sehe am DNS-Server aber nicht, dass die FW Abfragen macht... *grübel
Nachtrag: Es liegt wohl an der Namensauflösung.
Der DNS-Resolver läuft auf der FW, aber der Rechner hinter der FW bekommt keine Namen aufgelöst.
Was habe ich da falsch gemacht ?
Schwer zu sagen ohne dass du was darüber postest, was du wo eingestellt hast. Sicher dass du den DNS Resolver nutzt, nicht den Forwarder? Oder versehentlich beide an hast?
Dann hast du einen Beitrag vorher noch was geschrieben, dass du deinen internen DNS eingetragen hast. Nutzt der Resolver/Forwarder denn externe oder den internen DNS? Erreicht er den und funktioniert?
Ich würde mich erst einmal von vorne nach hinten arbeiten. Wenn du sagst DNS geht nicht: prüfe auf der Sense selbst, ob du DNS Abfragen machen kannst. Dann prüfe den Forwarder oder Resolver - je nachdem - und dann prüfe was am Client als DNS gepusht wird (via DHCP) und ob dieser überhaupt funktioniert (nslookup/host/dig).
Grüße
Danke für die schnelle Antwort.
Das Problem sitzt wieder mal vor dem Rechner.
Ich habe in der Virtualbox den DHCP-Server aktiviert und da kriegt der Linux-Rechner in der VM wohl keinen DNS-Server.
Den habe ich jetzt ausgeschaltet und den DHCP-Server von der Sense eingerichtet.
Das tut aber jetzt auch noch nicht. Der Client hat immer noch die alte IP vom VBox-DHCP *verzweifel
Dann muss der Client die erstmal vergessen, sonst wird er bis Ablauf des Leases noch die der VBox haben, oder? DHCP Release/Renew gemacht? :)
DHCP klappt jetzt von der FW. Aber irgendwas mach ich mit dem DNS noch falsch. Da kriegt der Vlient nichts von der FE geliefert