Best practices/Standards für Heimnetzwerk

[guest15032]

@Oxygen61,

das ist mal ausführlich, Danke! Ich nehme mir das gerne mal im Laufe der Zeit zur Brust und werde fleißig lesen. Ich bin zwar Software Entwickler, aber im Bereich Netzwerk und Netzwerksicherheit dann doch nur sehr wenig unterwegs gewesen in den letzten Jahren, das war nie so mein Fokus (obwohl ich es extrem spannend finde). Ich kann also mit vielen Begriffen was anfangen, interessant wird es dann - wie jetzt - in der konkreten Anwendung. ^^

Passwordmanager nutze ich seit Jahren und versuche auch immer, die etwas unbedarften Leute dazu zu bewegen. Also die, die überall das gleiche 8 stellige Passworrt mit Namen und Geburtsdatum nutzen. Security Dongles hatte ich auch schon oft im Sinn, wobei sich für mich der Aufwand bisher noch nie gerechtfertigt hat, um so etwas anzuschaffen. Zumal es ja (soweit ich weiß auch in der OPNsense Web GUI) die 2-Faktor Authentifizierung gibt.

Aber beim Punkt SSH und Zugriff habe ich noch eine Frage:

Greift ihr alle generell eher per SSH (mit Public Key Auth.) auf eure Firewall zu? Also, klar, im Arbeitsalltag bin ich auch nur mit meinem Linux unterwegs und die Shell ist mein bester Freund. Aber die Web GUI von OPNsense ist doch ziemlich ordentlich und macht die Config sehr angenehm. Oder ist das nur ne frage der Zeit, bis man die GUI deaktiviert? Ich bin normalerweise kein GUI Freund und alle VM in unserem Netzwerk verwalte ich auch nur per Shell über SSH + Kerberos aber grade die Web GUI bei OPNsense ist für mich ein echtes großes Plus zu vielen anderen Produkten.

Die Sache mit der Static Route ist also (falls ich sie denn benötigen werde) dafür da, dass der Netzwerkverkehr nicht über das Modem (den Standardgateway) geroutet wird. Demnach benötige ich zwei Routen, eine von OPT nach LAN und umgekehrt mit jeweils dem anderen Interface als Gateway?

@monstermania

Vielen Dank für die Links, hab drübergeschaut und es sieht sehr lesensewert aus.

[fabian]

Die Sache mit der Static Route ist also (falls ich sie denn benötigen werde) dafür da, dass der Netzwerkverkehr nicht über das Modem (den Standardgateway) geroutet wird. Demnach benötige ich zwei Routen, eine von OPT nach LAN und umgekehrt mit jeweils dem anderen Interface als Gateway?

Du brauchst zusätzliche Routen, wenn du an irgendeinem Port einen Router anschießt und die Geräte dahinter erreichen willst. Die eigenen Netze der Firewall kennt sie sowieso und daher musst du für diese keine Routen einrichten.


Die Konfiguration von OPNsense lässt sich eigentlich nur über die Weboberfläche machen. Die Shell kommt nur dann ins Spiel, wenn es kein Plugin gibt. SSH ist daher nur für Diagnosezwecke, Monitoring und fortgeschrittene Nutzer gedacht, die sich das Ganze etwas detailreicher konfigurieren oder einen Patch einspielen müssen oder für Entwickler.

MfG

Fabian

[monstermania]

Passwordmanager nutze ich seit Jahren...

Ich finde die üblichen Passwortmanager eher kontraproduktiv. Wenn Jemand das Passwort hackt hat er gleich Zugriff auf alle meine Accounts.
Dieser Ansatz ist m.E. deutlich besser: http://masterpasswordapp.com/
Vor Allem ist jedes eingegebene Passwort 'richtig'. Ein BruteForce-Angriff ist damit eigentlich aussichtslos.

Gruß
Dirk

[Oxygen61]

Passwordmanager nutze ich seit Jahren...

Ich finde die üblichen Passwortmanager eher kontraproduktiv. Wenn Jemand das Passwort hackt hat er gleich Zugriff auf alle meine Accounts.
Dieser Ansatz ist m.E. deutlich besser: http://masterpasswordapp.com/
Vor Allem ist jedes eingegebene Passwort 'richtig'. Ein BruteForce-Angriff ist damit eigentlich aussichtslos.

Man nutzt natürlich ja auch nich nur ein Passwort, sondern kombiniert dass mit einem 2ten Faktor.
Mein zweiter Faktor ist zum Beispiel die Challenge-Response-Authentifizierung per Hardwarekey.
Solange mich niemand überfällt meinen USB Stick UND meinen Hardwarekey klaut und dann versucht sich einzuloggen bin ich sicher. (Und selbst dann müsste er noch die zusätzlichen Zeichen wissen, die ich stets noch eingebe für das Passwort gegen Diebstahl).
Der große Vorteil meiner Meinung nach ist das Auto Type mit "Two-Channel Auto-Type Obfuscation", welches von Keepass genutzt wird um Keyloggern keine Chance zu geben etwas abzufangen.

Ich will deine Variante nicht schlecht reden, kannte ich noch nicht.
Aber für mich hat sich Keepass eben bewährt.

Greift ihr alle generell eher per SSH (mit Public Key Auth.) auf eure Firewall zu?

Nein. Muss auch sagen, dass FreeBSD umständlicher zu verstehen ist als Linux.
OPNsense bemüht sich ja die Konfiguration per GUI sicherer zu machen, im Gegensatz zu pfSense.
Wie Fabian schon meinte nutzt man es eigentlich nur falls man mal troubleshooten muss.
(Selbst fürs Monitoring bietet die GUI bereits genug Möglichkeiten).....
Meine Backup Lösung per TFTP musste ich z.B. mit SSH umsetzen, weil es über die GUI dafür keine Möglichkeit gab.
Im Grunde machst du aber alles per GUI im Idealfall.

[guest15032]

Hi zusammen.

@monstermania

ich halte es da ein wenig wie Oxygen61, ich ich habe eine 2-Faktor Authentifizierung, wo immer es möglich ist.  Und mein Passwortmanager ist mit einem derart langen und kryptischen Passwort gesichert, dass ich sehr sicher sein kann, dass auch mit hohem Rechenaufwand hinreichend viel Zeit vergehen müsste, um es zu knacken. Natürlich ist das wiederum eine Schwachstelle, da es das Einfallstor sein "kann" , wenn man das Passwort aus mir rausquetschen würde, aber solche Staatsgeheimnisse habe ich nun auch nicht, dass sich das lohnen würde. Und der zweite Faktor ist sowieso ein großes Plus in Punkto Sicherheit, das viele Menschen immer noch einfach ignorieren.

Wobei ich deine verlinkte App interessant finde, das Konzept hat natürlich was für sich.


@Oxygen61

Ich werde wohl erst morgen oder Montag dazu kommen, die Interfaces zu trennen und mich dann an das Aufbauen aller Firewall Regeln zu machen. Aber ich habe eine Frage zum generellen Aufbau der Firewall hinsichtlich der Interfaces und dem Datenverkehr untereinander.

Um das ganz grob zu skizzieren:

Modem ------> WAN
                            |
             -------------------------
             |                            |
           (F)                         (F)
             |                             |
          LAN <---- (F) ----> OPT
             |                             |
           (A)                         (B)

 
(F) = Firewall
(A) = Subnetz 1 (z.B. 192.168.1.0)
(B) = Subnetz 2 (z.B. 192.168.2.0)

Kurze Erklärung dazu (meinem bisherigen Verständnis nach):

Von Außen (Kabelmodem) kommt Datenverkehr rein, und zwar über das WAN Interface (ist logisch). Vom WAN Interface geht der Datenverkehr weiter an das LAN und OPT Interface (die sind ja dann nicht mehr in der Bridge, wie es bisher noch ist) . Am LAN Interface sitzt das erste Subnetz (A). Am OPT Interface sitzt das zweite Subnetz (B).

Zwischen den beiden Subnetzen bzw. zwischen den Interfaces ist ebenfalls die Firewall.

Die Firewall trennt beide Interfaces (also beide Subnetze) und die Firewall trennt WAN und LAN/OPT Interface, richtig?

Somit müsste ich doch insgesamt drei Regeln anlegen und zwar jeweils für:

- den Datenverkehr von WAN nach LAN (und zurück)
- den Datenverkehr von WAN nach OPT (und zurück)
- den Datenverkehr zwischen den Interfaces LAN und OPT

Stimmt das soweit?

Ich hänge drei Screenshots an, darauf sind die aktuellen Regelsätze für das WAN, LAN und OPT Interface zu sehen. Kannst Du (könnt ihr) mir erklären, wie die Regelsätze mit dem übereinstimmen, was ich geschrieben habe? Oder genauer gesagt, Du hattest geschrieben, dass am Ende immer ein DENY ALL steht. Das sehe ich hier nirgends. Liegt das daran, dass ich es einfach noch nicht erstellt habe (dann ist es wohl klar  ) oder hat das einen anderen Grund (da ich dachte, initial erstellt OPNsense eine DENY ALL Regel)?

Und wie sehen die Regelsätze aus, die ich dann initial anlegen muss? Muss ich als aller erstes alles blockieren auf allen Protokollen und Ports und dann fange ich an, etwas zuzulassen (das war ja die Idee dahinter) ? Aber dann frage ich mich, warum bei WAN, unter den beiden automatisch angelegten Regeln, steht:

 

No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule.

Wie kann denn dann momentan Datenverkehr fließen, wenn alle Verbindungen am WAN Interface geblockt werden?

Die Regeln aktuell sind noch für die bestehende Bridge (also LAN + OPT), aber das sollte ja keinen Unterschied machen, da es ja nur bedeutet, die Interfaces sind zusammengefasst. Das Prinzip ist das Gleiche, oder?

Ich bin gerade etwas konfus hinsichtlich der Regelsätze, Sorry.

Gruß
Chris

[guest15032]

Hier noch der Screenshot zu den WAN Regeln, das passte von der Größe her nicht mehr in den vorherigen Beitrag.

Gruß

[Oxygen61]

Hey hey,

da Wochenende ist, halt ich mich mal kurz, ich schau dann am Montag nochmal wegen den Regeln.

Grundlegend hatte monstermania ja schon die (Best Practise) Regeln aufgeschrieben, die erstellt werden müssen, damit aus dem privaten LAN/WLAN ins WAN kommuniziert werden kann. Die müssten also beim LAN und WLAN (opt1 - das solltest du mal benennen ) erstellt werden, damit du aus beiden Interfaces nach draußen kommunizieren kannst.

No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule.

Das ist die sogenannte "DENY ANY ANY" Regel. Sie sorgt dafür, dass deine Firewall nach der Installation nicht sofort alles durchlässt. Du musst diese also nicht explizit noch hinschreiben, sie ist sozusagen "hart eingetragen vom Werk aus".

Zum Thema "den Datenverkehr von xxx nach yyy (und zurück) musst du unbedingt wissen, dass es sich bei der OPNsense um eine Stateful Packet Inspection Variante einer Firewall handelt.
(Siehe: https://de.wikipedia.org/wiki/Stateful_Packet_Inspection)
Kurz gefasst bedeutet das, dass du immer nur eine Richtung angibst
und die Antwort dieser Kommunikation nicht extra erlauben musst.

Beispiel: Du möchtest vom LAN ins Internet, dann schreibst du nur im LAN eine Regel,
die dir diese Kommunikation erlaubt.
Die Firewall erstellt eine "Session" und merkt sich diesen "offenen Kanal" automatisch für dich.
Kommt dann z.B. vom Webserver (Google/Twitter usw...) eine Antwort zurück an den Clienten (Laptop/Rechner) zurück, der die Verbindung gestartet hatte,
dann musst du für diese Rückantwort keine extra Regel mehr auf der WAN Seite erstellen.
Auf der WAN Seite schreibst du solange keine PASS/ERLAUBEN Regel, sofern du nicht willst,
dass ein bestimmter Server in deinem internen Netz aus dem Internet erreichbar sein soll.
(Beispiel: NAS-Server/SSH-Server/Webserver).

Wie kann denn dann momentan Datenverkehr fließen, wenn alle Verbindungen am WAN Interface geblockt werden?

Um diese Frage also nochmal genau zu beantworten.
Von außen gestartete Verbindungen werden eben nicht durchgelassen, sondern blockiert.
Der Datenverkehr den du da siehst wird ja immer entweder aus deinem LAN oder deinem WLAN Subnetz gestartet.
Da du hier bereits ALLOW Regeln geschrieben hattest, ist die Kommunikation bereits möglich.
Der Grund dafür ist wie schon anfangs gesagt die Stateful Packet Inspection Funktion der Firewall.

Grob gesagt schreibst du folgende Regeln, siehe Beitrag von monstermania:

Anschließend habe ich dann einige Grundregeln definiert.
- Port 53 -> DNS nur intern
- Port 123 -> NTP nur intern
- Port  443 -> HTTPS
- Port 587 -> SSL-SMTP
- Port 993 -> SSL-IMAP
- Port 995 -> SSL-POP3
- MIT PROXY (Port 80 (HTTP) läuft über den Proxy der OPNSense (transparent).)
- OHNE PROXY (Port 80 --> HTTP)

Damit können alle Clients im Netz die Basics machen.
Weitere Regeln sind dann an das jeweilige Gerät gebunden (Aliase als feste DHCP-Reservierung - Static DHCP).

Zusätzlich musst du noch zwei Regeln formulieren die eine Kommunikation zwischen dem WLAN und dem LAN Interface erlauben.
Also:
ALLOW Datenverkehr von 192.168.1.0 /24 --> 192.168.2.0 /24 --> Ports siehe oben (je nachdem was du halt brauchst)
UND
ALLOW Datenverkehr von 192.168.2.0 /24 --> 192.168.1.0 /24 --> Ports siehe oben (je nachdem was du halt brauchst)
Hier kannst du dann somit die Kommunikation von beiden Seiten aus in das jeweilige andere Subnetz starten.
Wenn du weißt welche Ports du zwischen den Subnetzen erlauben möchtest, dann nimmst du NUR diese.
Wenn du faul bist, erlaubst du jeden Port.
Dann hast du aber zu mindestens schon mal die ALLOW Regel auf die beiden Subnetze beschränkt,
würdest aber 64000+ andere Ports gleich mit erlauben.
Wenn du danach dann noch seelenruhig schlafen kannst, sei es so

Wenn du kein ipv6 benutzt brauchst du es auch nicht freischalten,
bzw. anders gesagt du solltest es dann sogar blockieren oder komplett ausschalten
(Irgendwo in der GUI gab es dafür sogar ein Häkchen.
Floating Rule: DENY ipv6 ALL ALL
Floating Rules greifen auf all deinen Interfaces,
sind also super für allumfassende DENY Regeln die überall gelten sollen.

Schöne Grüße
Oxy

PS: ich sehe schon wieder ALLOW ANY ANY Regeln bei deinen Skizzen.
Da fällt mir nur folgendes ein: https://www.youtube.com/watch?v=NygtPyTIkto
ihhhh weg damit

[fabian]

Wenn du kein ipv6 benutzt brauchst du es auch nicht freischalten,
bzw. anders gesagt du solltest es dann sogar blockieren oder komplett ausschalten
(Irgendwo in der GUI gab es dafür sogar ein Häkchen.
Floating Rule: DENY ipv6 ALL ALL
Floating Rules greifen auf all deinen Interfaces,
sind also super für allumfassende DENY Regeln die überall gelten sollen.

Sorry aber hier bin ich ganz anderer Meinung.
Sämtliche Netze sollten so gestaltet werden, dass sie MIT IPv6 laufen können. Die Regeln unterstützen sowieso IPv4+IPv6 mit wenigen Ausnahmen (z. B. ICMP).
Ich würde ein vollständiges Dual Stack anstreben, damit man mit beiden Protokollen klar kommt.

[Oxygen61]

Sorry aber hier bin ich ganz anderer Meinung.
Sämtliche Netze sollten so gestaltet werden, dass sie MIT IPv6 laufen können. Die Regeln unterstützen sowieso IPv4+IPv6 mit wenigen Ausnahmen (z. B. ICMP).
Ich würde ein vollständiges Dual Stack anstreben, damit man mit beiden Protokollen klar kommt.

Kein Grund sich zu entschuldigen Fabian, das war ja nur meine Sicht auf die Dinge,
aber mir wird nicht ganz klar warum ein vollständiger Dual Stack auf Client Seite überhaupt angestrebt werden soll?
Ich verstehe die Sicht aus Seiten der Webseiten Betreiber voll und ganz.
Aber wenn in meinem eigenen Netz kein einziges Gerät über ipv6 vermittelt,
warum sollte man es dann erlauben?
Einfach auf Grundlage des einfachen Übergangs auf ipv6,
wenn denn dann irgendwann mal ipv4 abgesetzt wird?
Würde mich über ne Erklärung freuen.

[fabian]

Kein Grund sich zu entschuldigen Fabian, das war ja nur meine Sicht auf die Dinge,
aber mir wird nicht ganz klar warum ein vollständiger Dual Stack auf Client Seite überhaupt angestrebt werden soll?
Ich verstehe die Sicht aus Seiten der Webseiten Betreiber voll und ganz.
Aber wenn in meinem eigenen Netz kein einziges Gerät über ipv6 vermittelt,
warum sollte man es dann erlauben?
Einfach auf Grundlage des einfachen Übergangs auf ipv6,
wenn denn dann irgendwann mal ipv4 abgesetzt wird?
Würde mich über ne Erklärung freuen.

Wenn man das Netzwerk mittels SLAAC konfigurieren lässt, und intern schon mal mit IPv6 arbeitet, braucht man Intern nur mehr die IP umstellen (von privat auf öffentlich) und alles läuft so wie es soll weiter die Firewallregeln braucht man nicht angreifen (außer vielleicht ein paar Alias etc.), die Rechner sollten nach einer gewissen Zeit den richtigen Präfix verwenden.

Grundsätzlich haben wir ja das Problem, dass es zu wenige IPv4 Adressen gibt und IPv6 sollte dieses Protokoll seit c.a. 20 Jahren ablösen. IPv6 sollte auf allen Systemen gegenüber IPv4 bevorzugt werden (wenn IPv4 und IPv6 zur Verfügung steht).

Es geht hier also um folgende Dinge:

A: sich nicht daran beteilingen, IPv6 zu verzögern
B: man spart sich später die Arbeit, alles wieder umzustellen
C: man bekommt schon mal mit, welche Geräte man in Zukunft entsorgen darf
D: man braucht kein NAT (zumindest bei öffentlichen Adressen)
E: ist es egal ob man den Proxy intern mit IPv6 oder IPv4 anspricht - nach außen kann der ja immer noch IPv4 benutzen
F: VPN wird einfacher, da sich leichter ein freies Netz finden lässt

[guest15032]

Hi Oxygen,

Grundlegend hatte monstermania ja schon die (Best Practise) Regeln aufgeschrieben, die erstellt werden müssen, damit aus dem privaten LAN/WLAN ins WAN kommuniziert werden kann. Die müssten also beim LAN und WLAN (opt1 - das solltest du mal benennen ) erstellt werden, damit du aus beiden Interfaces nach draußen kommunizieren kannst.

Ist umbenannt.

Das ist die sogenannte "DENY ANY ANY" Regel. Sie sorgt dafür, dass deine Firewall nach der Installation nicht sofort alles durchlässt. Du musst diese also nicht explizit noch hinschreiben, sie ist sozusagen "hart eingetragen vom Werk aus".

Zum Thema "den Datenverkehr von xxx nach yyy (und zurück) musst du unbedingt wissen, dass es sich bei der OPNsense um eine Stateful Packet Inspection Variante einer Firewall handelt.
(Siehe: https://de.wikipedia.org/wiki/Stateful_Packet_Inspection)
Kurz gefasst bedeutet das, dass du immer nur eine Richtung angibst
und die Antwort dieser Kommunikation nicht extra erlauben musst.

Aaahhh.... Vielen Dank für diese Erklärung, das macht auch einiges viel deutlicher! Und außerdem hätte ich mal einfach genauer lesen müssen.... incoming connections!  Natürlich passt das alles, ich hab das völlig überlesen und in Verbindung mit der SPI Erklärung ist das alles auch stimmig.

Um diese Frage also nochmal genau zu beantworten.
Von außen gestartete Verbindungen werden eben nicht durchgelassen, sondern blockiert.
Der Datenverkehr den du da siehst wird ja immer entweder aus deinem LAN oder deinem WLAN Subnetz gestartet.
Da du hier bereits ALLOW Regeln geschrieben hattest, ist die Kommunikation bereits möglich.
Der Grund dafür ist wie schon anfangs gesagt die Stateful Packet Inspection Funktion der Firewall.

Ja, verstehe ich jetzt. Also die Firewall lässt aufgrund der SPI den Datenverkehr über WAN raus, weil ich dafür im LAN oder WLAN eine Regel geschrieben habe. Richtig? Ich dachte davor die ganze Zeit, dass ich jede Regel, die ich für LAN/WLAN schreibe, quasi nochmal für das WAN schreiben muss.

Zusätzlich musst du noch zwei Regeln formulieren die eine Kommunikation zwischen dem WLAN und dem LAN Interface erlauben.
Also:
ALLOW Datenverkehr von 192.168.1.0 /24 --> 192.168.2.0 /24 --> Ports siehe oben (je nachdem was du halt brauchst)
UND
ALLOW Datenverkehr von 192.168.2.0 /24 --> 192.168.1.0 /24 --> Ports siehe oben (je nachdem was du halt brauchst)
Hier kannst du dann somit die Kommunikation von beiden Seiten aus in das jeweilige andere Subnetz starten.
Wenn du weißt welche Ports du zwischen den Subnetzen erlauben möchtest, dann nimmst du NUR diese.
Wenn du faul bist, erlaubst du jeden Port.
Dann hast du aber zu mindestens schon mal die ALLOW Regel auf die beiden Subnetze beschränkt,
würdest aber 64000+ andere Ports gleich mit erlauben.
Wenn du danach dann noch seelenruhig schlafen kannst, sei es so

Ok. Und um mal zu testen, ob ich das richtig verstanden habe: Wenn ich die Kommunikation zwischen den Netzen sogar noch weiter einschränken will und nur die Kommunikation zwischen einzelnen Clients in den Netzen erlauben möchte, dann schreibe ich die Regeln für eine spezielle IP aus jedem Netz, z.B.:

ALLOW 192.168.1.10/24 -> 192.168.2.20/24

Richtig?

Oder noch genauer: Ich möchte, dass ich mit meinem Smartphone meine NAS im LAN erreiche. Also ist es ein ALLOW meiner Smartphone IP im WLAN ins LAN auf die IP meiner NAS auf Port 443?

Ich habe nicht den Anspruch, faul zu sein. Wenn ich es schon mache, dann auch richtig.

PS: ich sehe schon wieder ALLOW ANY ANY Regeln bei deinen Skizzen.

Du meinst in meinen Screenshots? Die sind ja daher, dass ich noch die Bridge an habe und da hatte ich zu Beginn auch die ALLOW ANY Regel geschrieben, weil ich da rumgefriemelt hatte und ich dazu was bei Google gefunden hatte. Aber das Video passt gut (mit Ton zumindest).

Gruß

[Oxygen61]

Es geht hier also um folgende Dinge:

A: sich nicht daran beteilingen, IPv6 zu verzögern
B: man spart sich später die Arbeit, alles wieder umzustellen
C: man bekommt schon mal mit, welche Geräte man in Zukunft entsorgen darf
D: man braucht kein NAT (zumindest bei öffentlichen Adressen)
E: ist es egal ob man den Proxy intern mit IPv6 oder IPv4 anspricht - nach außen kann der ja immer noch IPv4 benutzen
F: VPN wird einfacher, da sich leichter ein freies Netz finden lässt

Vielen Dank für die aufschlussreiche Erklärung.
War mir gar nicht so bewusst gewesen, aber muss auch sagen wie auch,
hatte mit ipv6 ja noch nicht arbeiten müssen.
Mein Problem mit ipv6 ist einfach, dass wie du schon sagtest der Umstieg sich mittlerweile so lange hinzieht, dass ich unterbewusst angefangen hatte nich mehr daran zu glauben, dass ipv6 sich jemals durchsetzt.
Was natürlich zusätzlich auch noch ein Problem zu sein scheint ist, dass alle How-To's und Anleitungen und Dokumentationen auch für OPNsense komplett nur für IPv4 geschrieben wurden.
Man müsste einfach öfters auch mal die IPv6 Alternative anbieten und aufschreiben,
weil ich für meinen Teil halt einfach gar nicht genug über IPv6 weiß, als dass ich OPNsense daran anpassen könnte.
Das liegt natürlich größtenteils an mir.
ich könnte mich ja mehr mit IPv6 beschäftigen, aber das Problem bleibt trotzdem bestehen. 

[Oxygen61]

Ja, verstehe ich jetzt. Also die Firewall lässt aufgrund der SPI den Datenverkehr über WAN raus, weil ich dafür im LAN oder WLAN eine Regel geschrieben habe. Richtig? Ich dachte davor die ganze Zeit, dass ich jede Regel, die ich für LAN/WLAN schreibe, quasi nochmal für das WAN schreiben muss.

Genau so siehts aus. Du schreibst für die internen Netze die allow Regeln,
damit diese dann nach draußen reden dürfen.
Antworten kommen so oder so zurück, aber eine Verbindung starten darf von draußen aus niemand.
Deshalb bleibt bei WAN alles wie es ist.

Ok. Und um mal zu testen, ob ich das richtig verstanden habe: Wenn ich die Kommunikation zwischen den Netzen sogar noch weiter einschränken will und nur die Kommunikation zwischen einzelnen Clients in den Netzen erlauben möchte, dann schreibe ich die Regeln für eine spezielle IP aus jedem Netz, z.B.:

ALLOW 192.168.1.10/24 -> 192.168.2.20/24

Richtig?

Oder noch genauer: Ich möchte, dass ich mit meinem Smartphone meine NAS im LAN erreiche. Also ist es ein ALLOW meiner Smartphone IP im WLAN ins LAN auf die IP meiner NAS auf Port 443?

Genau. Das wär dann wie monstermania das mal erklärt hatte.
Je nachdem wie du die IPs im Netzwerk vergibst musst du hier dann,
im Falle von DHCP Server, zwingend statische IP Adressen vergeben für deine Geräte.
Ansonsten ändert sich die IP und deine Regel greift dann plötzlich nicht mehr.
Bei OPNsense nennt sich das "Mapping".
innerhalb deiner DHCP Einstellungen gibt es ganz unten den Eintrag fürs Mapping. Da einfach mal schauen.
Die vergebenen Adressen kannst du dann noch einem Alias zuordnen innerhalb der OPNsense.
Fängst du dann an spezielle Regeln zu schreiben und schaust sie dir in 2 Jahren nochmal an,
weißt du sofort was Sache is, weil dann sowas steht wie:
ALLOW ne0h's Laptop --> OPNsense LAN Interface --> Port 22 (für ssh)

Achso und nur zur Klarstellung.
Eine Subnetzmaske von /24 bedeutet 254 freie Host Adressen.
Sprichst du über eine spezielle Adresse muss es die Subnetzmaske /32 sein.
Bei einem Routernetz ises die Subnetzmaske /30 (2 freie Host IPs für die Routerinfaces).
Weiteres hier: http://www.elektronik-kompendium.de/sites/net/0907201.htm

Du meinst in meinen Screenshots? Die sind ja daher, dass ich noch die Bridge an habe und da hatte ich zu Beginn auch die ALLOW ANY Regel geschrieben, weil ich da rumgefriemelt hatte und ich dazu was bei Google gefunden hatte. Aber das Video passt gut (mit Ton zumindest).

Ahhhh alles klar. Die Fraggles muss man einfach lieben

Schöne Grüße
Oxy

[guest15032]

HI Oxy,

Genau. Das wär dann wie monstermania das mal erklärt hatte.
Je nachdem wie du die IPs im Netzwerk vergibst musst du hier dann,
im Falle von DHCP Server, zwingend statische IP Adressen vergeben für deine Geräte.
Ansonsten ändert sich die IP und deine Regel greift dann plötzlich nicht mehr.
Bei OPNsense nennt sich das "Mapping".
innerhalb deiner DHCP Einstellungen gibt es ganz unten den Eintrag fürs Mapping. Da einfach mal schauen.
Die vergebenen Adressen kannst du dann noch einem Alias zuordnen innerhalb der OPNsense.
Fängst du dann an spezielle Regeln zu schreiben und schaust sie dir in 2 Jahren nochmal an,
weißt du sofort was Sache is, weil dann sowas steht wie:
ALLOW ne0h's Laptop --> OPNsense LAN Interface --> Port 22 (für ssh)

Jap, macht Sinn. Werde ich bedenken.

Speziell dazu:

Bei OPNsense nennt sich das "Mapping".
innerhalb deiner DHCP Einstellungen gibt es ganz unten den Eintrag fürs Mapping. Da einfach mal schauen.
Die vergebenen Adressen kannst du dann noch einem Alias zuordnen innerhalb der OPNsense.

Das Mapping habe ich gefunden. Und ich vermute, die Aliase, damit ist die Einstellung unter Firewall -> Aliases -> View gemeint, richtig?

Achso und nur zur Klarstellung.
Eine Subnetzmaske von /24 bedeutet 254 freie Host Adressen.
Sprichst du über eine spezielle Adresse muss es die Subnetzmaske /32 sein.
Bei einem Routernetz ises die Subnetzmaske /30 (2 freie Host IPs für die Routerinfaces).
Weiteres hier: http://www.elektronik-kompendium.de/sites/net/0907201.htm

Stimmt, Danke. Das hätte ich definitiv übersehen.

Wobei hier wieder die nächste Frage aufkommt. ^^

monstermania hatte ja die Standard Regeln gepostet, die Du auch angesprochen hast. Hier Frage ich mich (das kann monstermania natürlich auch beantworten, sollte er das früher lesen ), sind seine Regeln auf das Netz bezogen oder auf einzelne Clients?

Meine Überlegung ist gerade, dass es bei ihm wohl für das Netz gilt. Soweit ich mich erinnere, hat monstermania ja eine Bridge und sein LAN und WLAN Interface zusammengefasst. Und der Vorteil für das Netz ist dann ja, dass alle Clients die entsprechend konfigurierten Dienste/Ports nutzen können. Beispiel IMAP über SSL/TLS, wenn er Port 993 für das ganze Netz öffnet, dann kann jeder Client IMAP nutzen. ansonsten müsste man ja für jeden Client eine neue Regel eintragen (wobei das grad ja vöölig unabhängig von der Bridge ist).

Andersrum ist das für gewisse Dienste/Ports ja wieder gefährlich. Z.B. wenn jeder Client dann über Port 443 auf mein NAS zugreifen kann.

Also ist doch der sinnvollste Ansatz, die Regeln so differenziert und atomar wie möglich zu halten aber dabei auch darauf zu achten, welche Dienste und Ports einfach für alle frei sein können.

Ich würde das dann so angehen, dass ich z.B. IMAP über SSL/TLS im WLAN Interface für alle freigebe, also eine Regel für das ganze Subnetz erstelle, sowas wie:

ALLOW   IMAP Port 993 -> WLAN

Vom LAN Interface würde ich keine Regel erstellen, die IMAP erlaubt, somit wäre es also geblockt. Und zwischen den beiden Subnetzen würde ich auch kein IMAP erlauben, da es dafür bei mir keinen Anwendungsfall gibt.

Ah... ich sehe jetzt gerade, nachdem ich das alles hier geschrieben habe, dass monstermania ja dazu geschrieben hatte:

Weitere Regeln sind dann an das jeweilige Gerät gebunden (Aliase als feste DHCP-Reservierung - Static DHCP).

Damit beantworte ich es mir ja doch schon selbst. Es gibt allgemeine Netzregeln und dann auch spezifische Client Regeln.

Gruß
Chris

[monstermania]

@neOh
Die Grundregeln die ich gepostet hab können alle meine Geräte zu Hause nutzen, da Sie auf der Bridge angelegt sind.
Das ist aber auch gewünscht, da ich eh nur wenige Geräte habe (2 Smartphones, Tablet, Laptop und Smart TV). Und ich will zumindest von jedem dieser Geräte aus ins Internet und E-Mails verarbeiten.

Natürlich existieren dann noch spezielle Regeln für Tablet (z.B. ipsec) Laptop (z.B. OpenVPN, FTP, usw.). Die sind aber eben an das jeweilige Gerät und teilweise an eine Zieladresse gebunden (z.b. ipsec nur in die Firma).

Gruß
Dirk