Best practices/Standards für Heimnetzwerk

[Oxygen61]

Ich verstehe was du meinst. Das ist halt jetzt die Frage ob du denn die Kommunikation zwischen den beiden Interfaces überhaupt einschränken möchtest, weil darauf kommt es ja am Ende an. Ich für meinen Teil würde z.B. nicht wollen, dass sich die WLAN Geräte mit den LAN Geräten unterhalten können. Deshalb würde ich Regeln formulieren die "spezieller" sind, damit beide das gleiche können, aber sich gegenseitig nicht kennen.
Wenn dir das egal ist, dann hast du doch an dieser Stelle kein Problem! :)

Du musst dir halt nur im klaren sein, was du da eigentlich machst. Du schaltest 64000+ Ports frei, dass heißt 64000+ potentielle Dienste nur weil du nicht weißt, was genau denn erlaubt sein soll.
Mit dem "Sozusagen" keine Firewall mehr haben meinte ich, dass der Sinn einer Firewall stets darin besteht in erster Linie Traffic zu blockieren und nicht zu erlauben. Hebst du am Ende die DENY ANY ANY Regel mit einer "ich erlaube alles Regel" auf, kannst du deine Firewall auch durch nen Router ersetzen.
Das sagt man so, weil man sich damit ja selbst "veräppelt" ;)

Die grundlegenden Basics hatte monstermania schon erläutert.
Bei WLAN Geräten ist das Ruleset etwas "nerviger", weil jede App ihre eigenen Ports benötigt.
Whatsapp zum Beispiel oder irgendwelche Google Push Dienste oder Updates usw. usw.
Das kriegt man nur raus, indem man etwas versucht, merkt das es nicht geht und dann in das Firewall-Log schaut um nachzuschauen, welcher Port denn da angewählt wurde.

Du wirst dir mit dem Neukonfigurieren und immer wieder neu überarbeiten wahrscheinlich nur mehr Stress machen als gehofft.
Das Problem, dass dich Leute Lynchen wollen, weil ihr Programm xyz nicht funktioniert. Damit muss man als Firewall Administrator leben können. Das ist ein sogenanntes "Feature". :P

Was man zusätzlich noch überprüfen/blocken muss sind folgende dinge:

- Zugriff auf das Interface/Weboberfläche der Firewall - gewünscht? Ja?/Nein?
- Port 445 (MS DS) Windows NetBios SMB - blockieren!      
- Port 135 - 139 NetBios Services - blockieren!
- IP-Spoofing verhindern - Regeln dafür formulieren (Darf ein Gerät in ein privates bzw. sein eigenes Netz
  kommunizieren? Ja?/Nein?)

Wichtig! Lieber alles blocken und dann Schritt für Schritt Freischaltungen schreiben als andersherum. :)

Ansonsten: Als Best Practise gilt: Port 80/443 freischalten. Alles andere ist je nach Netzwerkumgebung
                   anzupassen.

[guest15032]

@chemlud

Interfaces am Router sind VIEL zu wertvoll, als dass man sie als "bridged" verschwenden sollte ;-). Dann häng deinen Kram aus der Bridge an EIN Interface mit einem billigen Switch. Und nutz die verschiedenen Interfaces, um Datenverkehre und Geräte sinnvoll aufzutrennen (home office - Eltern - Kinder - Gäste WHATEVER). Aber nicht die Firewall als Switch missbrauchen.

Und was, wenn der Switch voll ist? Dann einen Switch Port frei machen, einen zweiten Switch da dran und am zweiten Switch weiter machen?

Mit "nutz die verschiedenen Interfaces, um Datenverkehre und Geräte sinnvoll aufzutrennen" meinst Du die virtuellen Interfaces in der Firewall und nicht das Hardware Interface (also den Port am Gerät selbst), richtig?

[guest15032]

@Oxygen61

ok, das macht schon alles Sinn, was Du schreibst. :)

Ja, es war jetzt einfach die schnelle Lösung, die "erlaube alles " Regel auf die Bridge anzuwenden.

Wenn ich den AP vom OPT Interface ans LAN Interface hänge (also physisch an den Switch klemmen und der LAN Port mit dem OPT Interface bleibt dann wieder frei) dann würden sich ja LAN und WLAN Geräte so oder so sehen. Um das einzuschränken, würde man also Firewall Regeln für den AP definieren? Oder ist es dann doch praktikabler, den AP am eigenen LAN Port zu lassen und den Bridge Modus zu entfernen und eben die spezielle Kommunikation zwischen LAN und OPT durch die Firewall zu konfigurieren?

Ich bin mir nämlich gerade nicht sicher, ob ich das nicht durcheinander bringe. mit den INterfaces und Geräten und der Kommunikation untereinander.

Also, so einfach gesprochen wie möglich:

Nutze ich besser EINEN physischen LAN Port, an dem durch den Switch ALLE Geräte verteilt sind und arbeite dann mit Firewall Regeln auf EINEM virtuellen Interface (LAN) in der Firewall?

ODER

Nutze ich ZWEI physiche LAN Ports (wie momentan, an einem hängt der Switch, am anderen nur der AP). Und wenn ich  das tue, ist dann die Bridge zwischen den virtuellen Interfaces (LAN und OPT) besser/einfacher oder habe ich auf lange Sicht mehr davon, ZWEI Interfaces getrennt voneinander zu haben, die dann per Firewall miteinander kommunizieren?

Wenn ich richtig verstanden habe, würde ich in jedem Fall damit beginnen, mich durch die Logs der Firewall zu arbeiten und zu schauen, welcher Dienst, welche App, usw. da kommunizieren will und entsprechend würde ich nach und nach eine neue Regel anlegen für diesen einen Kommunikationsweg?

Wichtig! Lieber alles blocken und dann Schritt für Schritt Freischaltungen schreiben als andersherum. :)

Ansonsten: Als Best Practise gilt: Port 80/443 freischalten. Alles andere ist je nach Netzwerkumgebung
                   anzupassen.

Danke!

Gruß
Chris

[Oxygen61]

Dann lieber einen besseren Switch kaufen oder die Switche als Stack laufen lassen.
(Weiß grad nich ob das überhaupt geht bei Nicht-Cisco Switchen.)

Was chemlud meinte war, dass eine physische Trennung der Netzwerksegmente/Subnetze durch deine physisch an der Firewall vorhandenen Interfaces sicherer und zu bevorzugen ist, als eine logische Trennung durch den Einsatz von VLANs.

Wenn man es ganz genau nimmt, sind 3 Interfaces sogar noch zu wenig und man hätte lieber 4 Interfaces nutzen können, falls ein Einsatz einer DMZ für die NAS Server gewünscht ist.
Ergo:
1. Interface: WAN
2. Interface: LAN
3. Interface: OPTional (WLAN)
4. Interface: OPT2 (DMZ)
Ich sags mal so... besser geht immer. ;)

[Oxygen61]

@Oxygen61

Wenn ich den AP vom OPT Interface ans LAN Interface hänge (also physisch an den Switch klemmen und der LAN Port mit dem OPT Interface bleibt dann wieder frei) dann würden sich ja LAN und WLAN Geräte so oder so sehen. Um das einzuschränken, würde man also Firewall Regeln für den AP definieren? Oder ist es dann doch praktikabler, den AP am eigenen LAN Port zu lassen und den Bridge Modus zu entfernen und eben die spezielle Kommunikation zwischen LAN und OPT durch die Firewall zu konfigurieren?

Ich bin mir nämlich gerade nicht sicher, ob ich das nicht durcheinander bringe. mit den INterfaces und Geräten und der Kommunikation untereinander.

Also, so einfach gesprochen wie möglich:

Nutze ich besser EINEN physischen LAN Port, an dem durch den Switch ALLE Geräte verteilt sind und arbeite dann mit Firewall Regeln auf EINEM virtuellen Interface (LAN) in der Firewall?

ODER

Nutze ich ZWEI physiche LAN Ports (wie momentan, an einem hängt der Switch, am anderen nur der AP). Und wenn ich  das tue, ist dann die Bridge zwischen den virtuellen Interfaces (LAN und OPT) besser/einfacher oder habe ich auf lange Sicht mehr davon, ZWEI Interfaces getrennt voneinander zu haben, die dann per Firewall miteinander kommunizieren?

Wer mit wem kommuniziert/kommunizieren darf ist einzig und allein von den Regeln abhängig die du aufstellst.
Zu sagen "die würden dann ja so oder so mit einander kommunizieren dürfen" ist also nicht immer richtig, da als letzte Regel immer die "Verweiger alles" Regel greift.

Nutze ich ZWEI physiche LAN Ports (wie momentan, an einem hängt der Switch, am anderen nur der AP). Und wenn ich  das tue, ist dann die Bridge zwischen den virtuellen Interfaces (LAN und OPT) besser/einfacher oder habe ich auf lange Sicht mehr davon, ZWEI Interfaces getrennt voneinander zu haben, die dann per Firewall miteinander kommunizieren?

Das solltest du machen. Ein physischer Port an der Firewall wo dein Switch ran kommt. (Falls der VLANs unterstützt kannst du sogar über OPNsense zusätzlich noch die Kommunikation der Geräte die am Switch hängen einschränken.) Der zweite Port ist für das WLAN also kommt da der AP ran, mit dem sich dann deine WLAN Geräte verbinden.
Die Interfaces immer von einander trennen. Falls du willst das die sich kennen, kannst du ja immer noch eine Erlauben Regel schreiben, die diese Kommunikation dann erlaubt.
Also zum Beispiel:
Quelle: WLAN Net | Ziel: NAS Server IP/Alias | Allow

Ich weiß, dass klingt anstrengend und zeitintensiv (was es leider auch ich), aber du wolltest ja einen Best Practise, den man einmal aufsetzt und dann laufen lassen kann für die nächsten 10 Jahre :P

Für die Regeln kannst du unter: Firewall > Log Files die angewandten Regeln dir anschauen.
Da siehst du dann ganz schnell, warum das Katzenbild von Whatsapp nicht hochgeladen werden kann. :P

[monstermania]

Nutze ich ZWEI physiche LAN Ports (wie momentan, an einem hängt der Switch, am anderen nur der AP). Und wenn ich  das tue, ist dann die Bridge zwischen den virtuellen Interfaces (LAN und OPT) besser/einfacher oder habe ich auf lange Sicht mehr davon, ZWEI Interfaces getrennt voneinander zu haben, die dann per Firewall miteinander kommunizieren?

Ist m.E. eine gewisse Philosophiefrage.  ;)
Wie Paranoid bin ich in meinem internen Netz!
In meiner Installation läuft z.Zt. ohnehin Alles per WLAN (intern). Und natürlich will ich, dass sich alle Geräte hier auch sehen können. Schließlich will ich auf Dinge wie Miracsat/Chromecast vom Smartphone/Tablet zum Smart TV nicht verzichten.
Demnächst kommt evtl. eine QNAP NAS hinzu (LAN). Natürlich möchte ich dann auch intern (per WLAN) alle Dienste der QNAP nutzen können.
Klar, eine Bridge ist eine potentielle Schwachstelle in der Sicherheit. Ist halt wie fast immer. Einfach = pot. unsicherer. Kommt Jemand in mein internes WLAN, steht Ihm auch gleich uneingeschränkt das (gebridgte) LAN offen.
Aber auch so ist man meilenweit vor Leuten, die Ihre gesamte Homeautomation hinter einem simplen Router betreiben! Besser (sicherer) geht immer ist aber eben auch mit dem entsprechenden Aufwand verbunden.

[guest15032]

Das solltest du machen. Ein physischer Port an der Firewall wo dein Switch ran kommt. (Falls der VLANs unterstützt kannst du sogar über OPNsense zusätzlich noch die Kommunikation der Geräte die am Switch hängen einschränken.) Der zweite Port ist für das WLAN also kommt da der AP ran, mit dem sich dann deine WLAN Geräte verbinden.
Die Interfaces immer von einander trennen. Falls du willst das die sich kennen, kannst du ja immer noch eine Erlauben Regel schreiben, die diese Kommunikation dann erlaubt.
Also zum Beispiel:
Quelle: WLAN Net | Ziel: NAS Server IP/Alias | Allow

Ich weiß, dass klingt anstrengend und zeitintensiv (was es leider auch ich), aber du wolltest ja einen Best Practise, den man einmal aufsetzt und dann laufen lassen kann für die nächsten 10 Jahre :P

Für die Regeln kannst du unter: Firewall > Log Files die angewandten Regeln dir anschauen.
Da siehst du dann ganz schnell, warum das Katzenbild von Whatsapp nicht hochgeladen werden kann. :P

Ok, das klingt alles sehr sinnvoll. Danke. Ich denke, ich werde mich an genau diesem Setup versuchen, wobei ich das Argument von monstermania ja genau so unterschreiben kann, weil das auch mein Gedanke war, ich halte es "einfach" damit und hätte ja trotz Bridge schon einen riesen Vorteil für mein ganzes Heimnetz in Punkto Sicherheit und Config (und mal eben vom Smartphone aus auf das NAS zugreifen bzw. schauen, warum Gerät XY nicht ansprechbar ist, ist für mich da sowas wie Komfort out of the box).

Natürlich soll das umgekehrt nicht heißen, dass ich den Aufwand scheuen möchte. Im Gegenteil. ;)   

Also zur Konfiguration würde das ja bedeuten, dass ich es physisch ja schon genau so habe (Switch an LAN Port2, AP an LAN Port1). Ich müsste jetzt nur die Bridge entfernen, und folgendes würde ich dann konfigurieren:

Das Interface OPT (also der 2. Port) bekommt wie das erste LAN Interface eine statische IP und als Gateway (ebenfalls wie das LAN Interface) die IP des Kabelmodems.

Als statische IP aber natürlich eine aus einem anderen Subnetz. Also würde das dann so aussehen:

LAN Interface: Netz 192.168.1.0 (Bekommt  - bzw. hat schon - eine statische IP, z.B. 192.168.1.1)

OPT Interface: Netz 192.168.2.0 (Bekommt eine statische IP, z.B. 192.168.2.1)

Und jegliche Kommunikation zwischen beiden Netzen wird über Firewall Regeln erlaubt/eingeschränkt.

Richtig soweit?

Gruß
Chris

[guest15032]

Demnächst kommt evtl. eine QNAP NAS hinzu (LAN). Natürlich möchte ich dann auch intern (per WLAN) alle Dienste der QNAP nutzen können.

Aber das wäre doch, mit entsprechenden Firewall Regeln, bei zwei getrennten Subnetzen, doch genau so möglich, oder nicht?

Gruß

[Oxygen61]

Demnächst kommt evtl. eine QNAP NAS hinzu (LAN). Natürlich möchte ich dann auch intern (per WLAN) alle Dienste der QNAP nutzen können.

Aber das wäre doch, mit entsprechenden Firewall Regeln, bei zwei getrennten Subnetzen, doch genau so möglich, oder nicht?

Gruß

Jap wäre es. Bei ihm wäre es halt sozusagen "schon fertig".
Alles was bei seiner Umgebung "einfach so" funktioniert, müsstest du mit einer Rule erlauben.
Du kannst dir das so vorstellen, als hättest du nur noch 2 anstatt 3 NW-Interfaces, weil WLAN und LAN, zwar physisch getrennt wurden mit den Firewall Ports, aber danach zusammengeschlossen wurden.
Beide Wege gehen, ich glaube das is echt abhängig von deiner Paranoia.
Meine ist SEHR hoch... da muss jeder selbst für sich entscheiden,
wo die Sicherheit lieber aufhören sollte um Bequemlichkeit zu bekommen.

[Oxygen61]

Richtig soweit?

Richtig. Sofern du ohne VLANs arbeitest, kannst du ja mal ne "Erlaube alles" Regel auf beiden Seiten schreiben nur um mal zu sehen ob die Kommunikation über das Modem nach draußen schon funktioniert.
Ich bin mir nicht sicher, aber du wirst vielleicht noch eine static route schreiben müssen, wegen dem Gateway.
(System > Routes > All > Add route)
Das musst du mal ausprobieren ob es auch ohne geht.

[guest15032]

Was wäre denn das nächsthöhere Level an Sicherheit, nach den beiden getrennten Interfaces und der Firewall dazwischen?

Mir gehts da ähnlich mit der Paranoia, wobei es eben der schmale Grat ist zwischen Komfort und Sicherheit...

Gruß

[guest15032]

Richtig. Sofern du ohne VLANs arbeitest, kannst du ja mal ne "Erlaube alles" Regel auf beiden Seiten schreiben nur um mal zu sehen ob die Kommunikation über das Modem nach draußen schon funktioniert.
Ich bin mir nicht sicher, aber du wirst vielleicht noch eine static route schreiben müssen, wegen dem Gateway.
(System > Routes > All > Add route)
Das musst du mal ausprobieren ob es auch ohne geht.

Danke, werde ich tun!

Die static route ist dann wofür genau?

[Oxygen61]

1.) Naja, erstmal müsste man testen ob die Regeln denn überhaupt wie erwartet funktionieren.
2.) Dann muss überprüft werden ob die Art wie du auf deine Firewall, bzw. auf deine Geräte zugreifst sicher ist.
3.) Im Fall von SSH keine Möglichkeit gewähren per Benutzername und Passwort durchzukommen, sondern nur mit private Key und public key abgleich.
4.) HTTP bzw. wenn du es dir zutraust HTTPS Proxy in der Firewall aktivieren. Dazu gibt es ganz viele Beiträge bereits im Forum und auch eine Anleitung bei OPNsense
5.) Selber zwar noch nich probiert, aber die ICAP Lösung umsetzen.
6.) Das Monitoring einrichten. Nicht das dir Hardwaretechnisch etwas kaputt geht und du merkst das nicht
7.) Intrusion Detection und Prevention
Siehe: https://docs.opnsense.org/manual/how-tos/ips.html
An der Stelle die Warnung, du wirst in Logs baden gehen müssen und verstehen was da vorsich geht, ansonsten nützt dir Intrusion Detection nichts.
Würde hier aber sagen, dass das neben den Rules das mächtigste Tool einer Firewall is, wenn man weiß wonach man ausschau halten muss.
8.) Automatisiertes Backup einrichten über TFTP (lieber SFTP) oder ähnliches.
Eine Anleitung dazu hatte ich bereits mal geschrieben:
Siehe: https://forum.opnsense.org/index.php?topic=3853.0

Die Möglichkeiten sind endlos. Am Besten du überfliegst mal die Dokumentation.
Dadurch wirst du bestimmt fündig. :)
Siehe: https://docs.opnsense.org/manual.html

EDIT: Jeglicher Komfort ist im Härtefall immer eine Sicherheitslücke, weil Arbeit für dich abgenommen wurde, über die du keine Kontrolle mehr hast. (GUI Oberflächen, schwach formulierte Regeln usw.)

9.) Passwörter mit einem Passwortmanager (z.B. Keepass) verwalten. Diese Passwortdatenbank dann mit einem Hardwareschlüssel absichern. (z.B. Yubico)
Dadurch kannst du dir 40+ stellige OPNsense Weboberflächen Passwörter generieren lassen für den Admin Account, die du dir selber nicht mehr merken musst. Den Passphrase beim private Key kannst du somit auch unglaublich härten, ohne Nachteile. (SSH Schlüssel ablgleich geschieht dann über "Pageant" damit du den 40+ stelligen Passphrase nicht ständig eintippen musst bei jeder SSH session)
10.) Konfigurationsschutz durch einen Hardware USB dongle (Hab für OPNsense dafür noch nichts finden können, aber so könnte man die Konfig in dem Maße absichern, dass Änderungen nur getätigt werden können, wenn der Dongle vorher entfernt wurde von der Firewall.

Vielleicht am Schluss noch der generelle Schutz beim Benutzer durch eine Endpoint Security.
Geht es dann schlussendlich darum den Nutzer zu entmündigen um ihn vor sich selbst zu schützen gibt es ebenfalls genug Möglichkeiten dafür. Dann gehts aber schon in die Enterprise Richtung und hat mit einem SOHO nichts mehr zu tun. :)
Stichworte wären hier Active Directory, dedizierte Server für Device Control Lösungen....

Schöne Grüße
Oxy

[Oxygen61]

Die static route ist dann wofür genau?

Das is die Frage ob du überhaupt eine brauchst, deshalb vorher testen ob es nicht auch schon ohne geht.
Das Problem könnte nämlich sein, dass der Traffic aus OPT oder LAN nicht auf der anderen Seite ankommt, weil als Default Gateway dein Modem eingetragen ist. Durch die Static route kannst du für speziellen Traffic zum Beispiel den Traffic von LAN nach OPT und umgekehrt ein anderes Gateway erzwingen. (Beim Traffic von LAN nach OPT dann halt das Gateway vom OPT Firewall Interface)

[monstermania]

@neOh
https://kowabit.de/der-firewall/
https://kowabit.de/routerzwang/
Ein wie ich finde sehr interessanter und lesenswerter Blog zum Thema Sicherheit, Firewall und Firewall@home