OPNsense Forum

International Forums => German - Deutsch => Topic started by: guest15032 on January 10, 2017, 09:24:27 am

Title: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 10, 2017, 09:24:27 am
Hallo zusammen,

nachdem meine Appliance nun mit OPNsense läuft (https://forum.opnsense.org/index.php?topic=4209.0), habe ich das Setup übernommen, dass in dem Thread besprochen wurde.

Meine Appliance mit OPNsense hängt direkt hinter meinem Kabelmodem und verteilt mittels DHCP die Netzwerkadressen an alle meine Netzgeräte (NAS, Konsole, TV, usw.). Zudem arbeitet mein vorheriger Router nun als Acess Point für WLAN Geräte und auch für die Switche, die daran angeschlossen sind.

Das funktioniert auch alles problemlos und genau wie gewünscht.

Da ich ja noch recht neu im Umfeld Security Appliance und OPNsense bin und mich das Backend de Apliance dementsprechend noch etwas erschlägt, möchte ich gerne mal in die Runde fragen, ob es unter euch, bzw. generell im Aufbau solcher sicherer Heimnetze, irgendwelche Best Practices gibt, die quasi einen einfachen "Standard" bieten?

Es geht mir darum, ein sinnvolles und einfaches, grundlegendes Setup zu haben, an dem ich selbst lernen kann und welches ich dann hinsichtlich meiner Wünsche erweitern kann.

Wichtig sind mir natürlich (wie fast jedem) die Punkte Sicherheit und Performance.

Worauf ist im besonderen zu achten? Gibt es Anfängerfehler, die man einfach vermeiden kann, um sich unnötigen Aufwand zu sparen? Wie definiert ihr, mit der Integration von OPNsense in ein Heimnetzwerk, ein "sicheres" Netz?

Über Ideen, Denkanstöße und Meinungen würde ich mich freuen.

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 10, 2017, 10:29:53 am
Meine Appliance mit OPNsense hängt direkt hinter meinem Kabelmodem und verteilt mittels DHCP die Netzwerkadressen an alle meine Netzgeräte (NAS, Konsole, TV, usw.). Zudem arbeitet mein vorheriger Router nun als Acess Point für WLAN Geräte und auch für die Switche, die daran angeschlossen sind.

Das funktioniert auch alles problemlos und genau wie gewünscht.

Da ich ja noch recht neu im Umfeld Security Appliance und OPNsense bin und mich das Backend de Apliance dementsprechend noch etwas erschlägt, möchte ich gerne mal in die Runde fragen, ob es unter euch, bzw. generell im Aufbau solcher sicherer Heimnetze, irgendwelche Best Practices gibt, die quasi einen einfachen "Standard" bieten?

Es geht mir darum, ein sinnvolles und einfaches, grundlegendes Setup zu haben, an dem ich selbst lernen kann und welches ich dann hinsichtlich meiner Wünsche erweitern kann.

Also dass mit dem Router als WLAN AP und für die Switche verstehe ich nicht. Mach doch einfach eine Zeichnung Deines Netzaufbaus!  ;)

Als m.E. sehr guten Einstieg empfehle ich das Lesen des folgenden Tutorials: https://www.administrator.de/contentid/149915
Insbesondere die weiterführenden Links enthalten viele praktische Beispiele und Denkanstöße, was man mit einer Firewall Alles so machen kann (auch zu Hause).
Was Du davon dann umsetzt, hängt von Deinen persönlichen Anforderungen ab.
Willst Du z.B. auch von extern auf Deine Systeme zugreifen (z.B. NAS)?
Willst Du z.B. deinen Kindern nur einen eingeschränkten Internetzugang zur Verfügung stellen?

Ich habe mit der OPNSense meinen 08/15 Router abgelöst um einfach eine gewisse Kontrolle darüber zu erlangen wohin mein Smart-TV und die anderen Geräte so kommunizieren dürfen.

Ich nutze z.B.:
- Firewall
ausgehend für alle Geräte nur einige Grundregeln erlaubt. Spezielle Geräte haben dann zusätzliche Rechte (z.B. Laptop -> OpenVPN, Tablet -> IPSec).
- Proxy (transparent, http)
Sperrliste von Shalla, Download von bestimmten Dateitypen geblockt, usw.
- DynDNS Dienst
- OpenVPN Server
- WLAN internes Netz
- WLAN Gast (offenes WLAN ohne Restriktionen)
- DMZ (z.Zt. noch nicht genutzt :) )

Klar, dass ist nur ein Bruchteil der Möglichkeiten, die eine OPNSense bietet, aber mir reicht das für mein Heimnetz aus.

Gruß
Dirk

Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 10, 2017, 03:25:46 pm
Eine Firewall, soll an sich ja Kontrolle und Überwachung über dein Netz bringen und ist damit der wichtigste Teil in deinem Netz. Egal was auch immer du für Anforderungen an dein Netz hast, am Ende muss die Firewall mitspielen.

Der allerwichtigste Part einer Firewall sind die Rules. Am Ende der OPNsense steht immer ein DENY ALL,
sodass du durch zusätzliche allow Regeln, "Löcher" in dein Netz bohrst wenn auch gewollt.
Die "Standardsicherheit/Best Practise" von der du sprichst ist am Ende von diesen Rules, den Sicherheitslücken in der OPNsense/FreeBSD und deiner Netzplanung abhängig.

Du musst dir also im Klaren sein:
Wer darf was? (Welches Netz/Welches Endgerät darf in welche Netze und mit welchen Endgeräten kommunizieren?)
Was darf dieser jemand, wenn er was darf? (Welche Protokolle sollen erlaubt werden? Hast du zum Beispiel einen extra Rechner nur für den Zugriff auf die Firewall, dann sollte auch nur dieser eine Rechner auf das LAN Interface über HTTPS zugreifen und auch nur dieser eine Rechner/Netzbereich per SSH sich verbinden (Port 22))

Weitere Denkanstöße:
Zugriff über SSH nicht über Benutzername und Passwort sondern mithilfe von Private und Public Keys.
Dafür kann man Puttygen nutzen und die Umsetzung findest du auch in der Dokumentation von OPNsense.
Ganz wichtig ist am Ende also eine Netzplanung. :)
Bau dir ein schönes Netz zusammen, z.B. mit www.draw.io
Schreibe eine Doku über deine Schritte um in 3 Jahren noch zu verstehen was du mal gemacht hattest. (ihhh eine Doku :P)
Freunde die mal nur fürn Käffchen vorbeikommen aber natürlich ihre Facebook Nachrichten checken wollen mit DEINEM Netz, dürfen natürlich niemals mit deinem internen Netz kommunizieren. Heißt, mithilfe eines Captive Portals ein Gästenetz erschaffen, welches mehr oder weniger eigenständig in deinem internen Netz koexistiert.
Fängt sich dein Kaffee trinkender, Facebook Nachrichten checkender Freund dabei einen Virus ein, infiziert er nicht gleich auch dein ganzes Netz.
Möchtest du Server aufsetzen (Webserver, Mailserver... usw.) die auch von außen erreichbar sein sollen, solltest du dir über den Begriff DMZ den Kopf zerbrechen.

Weitere Denkanstöße findest du auch in der OPNsense Dokumentation:
Es gibt zum Beispiel die Möglichkeit der Einbindung eines ICAP Servers gegen sämtliche Arten von ekligen Insekten :P Würmern, Viren .... usw.
Siehe: https://docs.opnsense.org/manual/antivirus.html
Web Filtering, wovon monstermania sprach kann hier nachgelesen werden: https://docs.opnsense.org/manual/how-tos/proxywebfilter.html

Viel Spaß :)
Fehler machen gehört dazu, nur so lernt man (bzw. nur so lern ich irgendwie leider immer nur) :P

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 11, 2017, 09:39:50 am
Hallo zusammen,

vielen Dank für die Denkanstöße und Verlinkungen.

Zum Router als Acess Point:

Mein Netzwerkaufbau sieht ganz simpel so aus:

[ Kabelmodem ]  -----> [ OPNsense Appliance ] -----> [ Acess Point (ehemals Router) ]

Am AP hängen zwei Switche per LAN, an denen dann weitere Geräte hängen, also:

                                                                 [ AP ]
                                                                     |
                                                                     |
                                                   ----------------------------
                                                  |                                     |
                                         [ Switch 1]                   [ Switch 2]
                                                  |                                     |
                                     ---------------------         ---------------------
                                     |                           |        |                          |
                                NAS1                 NAS2  TV                   Konsole

usw....

Also meine Prioritäten liegen ganz klar in folgenden Punkten:

1. Ich möchte ein intern separiertes Netz für Gäste (wie Du, Oxygen61, das so schön erläutert hast) damit die zwar im Netz surfen können, wenn sie zu Besuch sind, aber dabei definitiv nicht auf mein LAN zugreifen können.

2. Das Gastnetzwerk sowei mein LAN sollen Sicherheit gegen Viren etc. bieten. Gerade, weil die Frau des Hauses öfter Mal durch Ihr handwerkliches Hobby Dateien laden muss, die generell zwar nur PDF Formate sind, aber wir wissen ja, wie schnell das schief gehen kann. 

3. Ich möchte eine Art Intrusion Detection haben, die mich aktiv (z.B. per E-Mail) benachrichtigen soll, wenn neue bzw. unbekannte Geräte das Netzwerk betreten möchten. Zudem ein generelles Monitoring meiner verbundenen Netzwerk Hardware um da einen Überblick zu haben.

4. Die Kontrolle über alle Netzwerkaktivitäten über die Firewall, um zu wissen, welches Gerät was wohin schicken möchte und wer da von Außen anklopft.


Ich hoffe, dass ich mich da durchwühlen kann und einen ersten guten Ansatz finde, ich denke, beginnend mit der Firewall....

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 11, 2017, 11:05:15 am
Sorry,
aber ich versteh das mit dem AP und den dahinter liegenden Switchen einfach nicht!  ???

Die übliche Konfiguration wäre in etwa so:
[ Kabelmodem ]  ----> [ OPNsense (LAN) ] ----> [SWITCH] ----> [ Access Point ]
                                                                                               |
                                                                                               ---->  [ andere Geräte ]

Zum Gäste WLAN :
Die einfachste Lösung ein Gäste-WLAN einzurichten ist wohl einen AP zu nutzen der MultiSSD und vLAN fähig ist. Dann kannst Du mit einem AP sowohl Dein internes WLAN und in einem vLAN Dein Gäste-WLAN betreiben. Das bedingt natürlich auch, dass der verwendete Switch ebenfalls vLAN unterstützt!
Ob man nun ein Captive-Portal für ein Gäste WLAN nutzen muss!? Ich nutze für mein Gäste WLAN jdenfalls keines. Das Gäste-WLAN läuft ganz normal mit WPA2. Meine Freunde/Bekannten bekommen dann einfach das Kennwort und es kann losgehen.
1. Die Anzahl der Leute, die mein Gäste WLAN nutzen dürfen ist sehr überschaubar
2. Die Leute kommen häufiger vorbei

Wichtig war mir die Trennung meines privaten Netzes gegen das Gäste WLAN. Und das Ziel ist auch ohne Captive Portal erreicht.

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 11, 2017, 01:12:46 pm
@ne0h Dein Aufbau erklärt sich mir auch nich so recht. Ich meine das geht sicher so, aber warum tauschst du nich deinen AP mit der Firewall?
Also die Switche an die Firewall und den AP für WLAN am Besten auch an die Firewall und einfach gar keinen "Zwischenrouter" mehr zwischen der Firewall und dem Modem. (Gibt eh nur Schwierigkeiten das dann einzurichten)
Also vielleicht in etwas so:

              [ Kabelmodem ] <-------[ OPNsense ]-------> AP ---------> [ WLAN Geräte mit/ohne Captive Portal ]
                                                               |
                                    int1(WAN)          | Int2(LAN)      opt1 (WLAN)
                                                               |
                                            -------------------------------------------------------
                                            |                                      |                                          |
                                     [ Switch 1]                     [ Switch 2]                           [ Switch 3]
                                            |                                     |                                            |
                               ---------------------         ---------------------                 -----------
                               |                           |        |                               |                |               |
                           NAS1                    NAS2    TV                       Konsole       Laptop      Desktop PC



Je nach Größe der Switche könnte man die Geräte am Switch 3 auch einfach an Switch 2 hängen.
Das WLAN würde ich persönlich physisch per Interface vom LAN trennen. (Formulierung von Regeln werden einfacher und VLAN Hopping schließt sich dann damit aus.)

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 11, 2017, 04:54:17 pm
2. Das Gastnetzwerk sowei mein LAN sollen Sicherheit gegen Viren etc. bieten. Gerade, weil die Frau des Hauses öfter Mal durch Ihr handwerkliches Hobby Dateien laden muss, die generell zwar nur PDF Formate sind, aber wir wissen ja, wie schnell das schief gehen kann. 
Stichworte sind Proxy und ICAP.
Mit dem Proxy kannst Du den Webtraffic filtern (z.B. Sperrlisten). Dateianhänge können dann per ICAP auf Viren/Schadsoftware geprüft werden. Leider gibt es bisher kein ICAP-Plugin für OPNSense (wird es wohl auch nicht geben). Die Empfehlung der OPNSense-Entwickler geht dahin den ICAP-Dienst auf einen eigenen Server auszulagern.
Das bedeutet daher, dass Du Dir hierfür nur selbst eine Lösung bauen kannst!
Die Proxykonfiguration mit der GUI ist recht einfach gehalten. So ist es z.B. nicht möglich bestimmten Geräten/Usern/IP-Adressen eigene Filtergruppen zuzuweisen bzw. solche Filtergruppen überhaupt zu erstellen. Das wäre z.B. ideal um z.B. den Kindern andere Webfiltereinstellungen zuzuweisen als Erwachsenen. Oder z.B. Zeitprofile, dass Kinder nur von 16-20 Uhr ins Internet können. Leider in der OPNSense Alles nicht konfigurierbar (zumindest nicht per GUI)!
Schau es Dir halt mal an und prüfe, ob Dir die Möglichkeiten von OPNSense für Deine Zwecke ausreichen.
Im Bereich Proxy+Virenschutz bietet z.B. pfsense deutlich mehr Möglichkeiten!
 
Quote
3. Ich möchte eine Art Intrusion Detection haben, die mich aktiv (z.B. per E-Mail) benachrichtigen soll, wenn neue bzw. unbekannte Geräte das Netzwerk betreten möchten. Zudem ein generelles Monitoring meiner verbundenen Netzwerk Hardware um da einen Überblick zu haben.
Hmm,
ich glaube hier verstehst Du was falsch. Wenn Jemand von innen auf Dein Netzwerk zugreifen will um Daten abzugreifen, indem er z.B. einen Laptop an einen Switch in Deinem LAN anschließt nutzt die Firewall auch nichts mehr.
Dafür gibt es andere Ansätze (z.B. zentral verwaltete MAC-Filterlisten auf den Switchen/Access-Points). Solche Funktionen bieten die Enterprise Switche von HP/Cisco, usw. So Bald sich eine unbekannte MAC in das Netzwerk schaltet, wir der Port vom Switch sofort deaktiviert und eine Warnung ausgelöst. 
In den Firewalls sind IDS/IPS-Systeme enthalten, die Anhand von Angriffsmustern erkennen, ob Dein Netzwerk evtl. angegriffen wird. Dabei kann dann z.B. auch eine Attacke von innen erkannt werden, wenn z.B. ein Trojaner (BOT) auf einem Rechner im Netzwerk Datenaustausch mit seinem Steuerserver im Internet durchführt. IDS/IPS ist sehr ressourcenhungrig, da im Prinzip jedes gesendete/empfangene Datenpaket analysiert werden muss. Bei entsprechender Bandbreite Deiner Internetanbindung braucht es also entsprechend Rechenleistung. Vor Allem sollte man sich mit der Analyse der anfallenden Daten auch auskennen. Sonst kann man vor lauter "Angriffen" gar nicht mehr schlafen.  ;)
Ich halte IDS/IPS im Unternehmen für wichtig. Bei 100 oder mehr Rechnern kann man einfach nie sicher sein, dass nicht ein User doch irgendwie Dummheiten macht. Nur sitzt da i.d.R. auch ein Admin, der sich damit auskennt und die Daten richtig interpretiert.
Bei 3 oder 4 PC's zu Hause braucht man m.E. nicht unbedingt ein IDS/IPS.
Und Monitoring hat nix mit Firewall zu tun! Für das Monitoring empfehle ich eine Lösung wie Nagios oder Zabbix. Zabbix nutzen wir hier im Unternehmen um unsere Hardware zu überwachen. Sehr schöne Lösung, wobei mir aber nicht einfallen würde, was ich damit zu Hause sollte...  ;D
Quote
4. Die Kontrolle über alle Netzwerkaktivitäten über die Firewall, um zu wissen, welches Gerät was wohin schicken möchte und wer da von Außen anklopft.
Klar, das ist ja der Sinn einer Firewall  ;)
Dazu bietet jede Firewall ein entsprechendes LOG an. GGf. macht der Einsatz eines eigenen Syslog-Servers Sinn, wenn man z.B. auch historische Daten betrachten will.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 09:19:31 am
Guten Morgen,

vielen Dank für Eure Antworten..

Bevor ich auf die anderen Sachen eingehe, habe ich eine Frage zur Struktur meines Netzwerkes, die ich jetzt entsprechend eurer Ideen geändert habe.

Ich hatte darüber nachgedacht und festgestellt, dass es Sinn macht, das Netzwerk so aufzubauen wie ihr es vorgeschlagen habt. Ich habe den Access Point (also den ehemaligen Router) jetzt am ersten LAN Port der Appliance angeschlossen. Außerdem habe ich mich eines der beiden Switche entledigt, da dieser der ältere und mit weniger Ports war. Ich hatte gesehen, dass ich an den neueren Switch alle meine LAN Verbindungen dran bekomme. Das ausmisten war eh schon lange fällig und somit habe ich jetzt also nur noch einen Switch.

Der Aufbau ist also jetzt wie folgt:

                                                        [ Kabelmodem ]
                                                                     |
                                                             (static IP)
                                                                     |
                                                 [ OPNsense Appliance ]
                                                                     |
                                                                     |
                                                 ------------------------------
                                                 |                                      |
                                            (OPT)                  (LAN mit DHCP)
                                                  |                                     |
                                         [ Switch ]          [ WLAN Access Point (alter Router) ]
                                                  |                                     
                                     ------------------------------------------
                                     |                           |                           |
                                NAS1                 NAS2             Konsole, etc.


Soweit so gut.

Bitte verzeiht mir, wenn ich mich auch hier wieder etwas blöd anstelle, aber ich habe dann versucht zu verstehen, in welcher Form der zweite LAN Port (also OPT) arbeiten soll.

Die Doku sagt ja erstmal nur, dass zum Standard LAN Port alle zusätzlichen Ports als OPT Interfaces konfiguriert werden können.  Hier stellt sich mir die erste Frage: Ist "OPT" irgendeine Begrifflichkeit, die man kennen muss (da es mir noch nie im Zusammenhang mit Netzwerktechniken aufgefallen ist) ? Oder ist es schlicht ein eigener Begriff der Appliance, um hervorzuheben, dass es sich um ein weiteres "OPTionales" Interface handelt?

Also, wenn ich das Interface über das Menü hinzufüge, wird dieses dann von OPNsense auch von sich aus als OPT benannt. Dann stellte sich mir die Frage, wie genau konfiguriere ich das Interface nun am besten?

Mit meinem bisherigen Netzwerkverständnis und Trial&Error habe ich gesehen, dass ich das Interface nicht genau wie das LAN Interface konfigurieren kann (sprich im selben Subnetz aber z.B. mit anderer DHCP Range), da ja keine zwei Interfaces im gleichen Subnetz sein können. Das führt ja zu Routing Problemen und auch das Log hat auf das Problem korrekt hingewiesen. Ich könnte auf dem Interface ein zweites Subnetz eröffnen, also z.B. so:

LAN ist: 192.168.1.0

OPT ist: 192.168.2.0

Das funktioniert zwar, da jedes Interface dann in seinem eigenen Subnetz arbeitet. Dann sehe ich aber das andere Subnetz mit allen angeschlossenen Netzwerkgeräten ja nicht vom aktuellen Subnetz aus. Ich kann also vom Subnetz des Access Points nicht auf das andere Subnetz zugreifen. Ist also in dem Fall so nicht gewoillt, ich komme ja nicht mehr an meine NAS, usw.

ich könnte das natürlich alles irgendwie umgehen, indem ich den AP einfach mit an den Switch klemme (ganz unabhängig davon, ob ich grad einen freien Port am Switch habe oder nicht, sonst kommt halt ein zweiter Switch hinter den ersten und da kommt der AP dann dran).

Aber das löst das aktuelle Problem nicht und außerdem möchte ich das zweite Interface ja bewusst nutzen, denn dafür ist es ja da und dann würde ich eben an dieses Interface dann einen neuen Switch anschließen, hinter dem dann weitere Netzwerkgeräte arbeiten, statt das Interface brach liegen zu lassen und am LAN Interface Switch hinter Switch zu schalten.

Also habe ich folgende Lösung (mit etwas Recherche) gefunden:

Ich habe das neue OPT Interface nicht, wie das LAN Interface, mit einer statischen IP oder ähnlichem konfiguriert. Ich habe stattdessen eine Bridge erstellt im Interface Menü (unter dem entsprechenden Unterpunkt). Dort habe ich das LAN und das OPT Interface eingetragen, die Bridge dann benannt und gespeichert.

Danach habe ich eine neue Firewall Regel angelegt. Ich hab für das OPT Interface eingetragen, dass sämtlicher Netzwerkverkehr weitergeleitet werden soll, also mit den Einstellungen: 

Protocol: any
Source: any
Destination: any

Nach anlegen und anwenden der Firewall Regel, funktionierte alles wie ich es mir vorgestellt hatte. Das OPT Interface und das LAN Interface liefen im selben Subnetz, ich konnte meine Netzwerkgeräte, die am Switch am OPT Interface hängen, wieder sehen.

Mir stellt sich jetzt also die wichtige Frage: Ist das so der richtige Weg, um ein zusätzliches Interface im selben Subnetz zu konfigurieren? Oder habe ich es zwar zum Laufen gebracht, aber nicht so, wie es in einer solchen Appliance sein sollte für einen sauberen und fehlerfreien Aufbau?

Im übrigen könnte ich natürlich auch die beiden Ports vertauschen (also Switch und AP umstecken) aber das ist ja das selbe Problem in grün. 

Danke erstmal für Hilfe hierzu.

Grüße
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 09:38:06 am
P.S.:

Ich hatte auch gelesen, dass es Lösungen gibt, bei denen das OPT Interface mit einer statischen IP konfiguriert wird (also genau wie das LAN Interface) und es wird ein Gateway  eingetragen (das dann die IP des LAN Interfaces ist ?). Die Firewall Regel bleibt dann die selbe wie ich sie erstellt habe.

Ist das so praktikabel/besser/schlauer? Wenn ja, wo liegen die großen Unterschiede zur jetzigen Bridge?

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 12, 2017, 09:52:21 am
Na,
das hört sich doch schon ganz gut an!
Ja, mit OPT für 'Optional' liegst Du schon ganz richtig. Außer WAN und LAN ist erstmal jedes weitere NW-Interface erstmal OPT.
Das kannst (und solltest) Du natürlich bei der Konfiguration des Interfaces ändern (z.B. DMZ, WLAN, WLAN_Gast, usw.). Macht die Konfiguration insgesamt einfacher sprechende Namen zu verwenden.
Bei anderen Firewalls werden die NW-Interfaces z.B. mit Farben bezeichnet (WAN=rot, LAN=grün, usw.).

Mit der Bridge liegst Du auch ganz richtig. Wenn Du z.B. LAN und WLAN in Einem zusammen verwalten willst musst Du die NW-Interfaces über eine Bridge verbinden. Alle Einstellungen (DHCP, FW-Regeln, usw.) musst Du jetzt entsprechend auf der Bridge machen. Im Prinzip hast Du jetzt die Funktion, wie Sie jeder übliche WLAN-Router auch bietet.
Die Bridge sollte man auch so benennen, dass sofort klar ist wofür Sie ist.

Für das Gäste-WLAN könntest Du jetzt einfach weitere NW-Schnittstelle in der OPNSense einrichten und daran einen 2. AP hängen.
Wenn Deine Hardware (AP und Switch) MultiSSD/vLAN-fähig ist kannst auch mit einem AP 2 (oder sogar mehr) unterschiedliche WLAN's betreiben.
Theoretisch (und praktisch) kannst Du die vLAN's an einem einzelnen Interface der OPNSense betreiben. Aber dann wird es in der Konfiguration schnell unübersichtlich! Von daher ist es besser die Netze (LAN, WLAN, WLAN_Gast, usw.) in der OPNSense jeweils auf ein eigenes NW-Interface zu führen.

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 12, 2017, 10:01:48 am
Ist das so praktikabel/besser/schlauer? Wenn ja, wo liegen die großen Unterschiede zur jetzigen Bridge?
Kommt darauf an, was Du bezwecken willst! 
Mit einer Bridge sind die Interfaces verbunden. Das bedeutet, Du hast keine Möglichkeit FW-Regeln zwischen den beiden Interfaces einzurichten. Jeglicher Traffic zwischen den Interfaces ist erlaubt!

Mit der anderen Möglichkeit bekommst Du die volle Kontrolle was den Traffic zwischen den Interfaces angeht. Das bedeutet, Du müsstest zunächst mal entsprechende FW-Regeln erstellen, damit überhaupt ein Traffic zwischen den Interfaces möglich ist bzw. wird.
 
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 10:14:51 am
Kannste so machen. Grundsätzlich ist es aber normal, dass jedes NW-Interface "eigenständig" läuft,
also mit einem anderen Subnetz.
Damit diese dann miteinander "reden" können, musst du überprüfen ob du Firewall Regeln geschrieben hast,
die das erlauben, weil Grundsätzlich am Ende immer ein Deny Any Any steht.
Außerdem hättest du vielleicht eine static route schreiben müssen,
dass das OPT Interface, falls es in das LAN Subnetz reden möchte nicht dein WAN Interface als default Gateway nehmen soll, sondern halt logischerweise das LAN Interface.
Dann hätte es wahrscheinlich auch so funktioniert (falls ich nichts vergessen habe).
Das aber nur als kleiner Auszug, weil du ja deine Lösung gefunden hattest.

Wichtig ist aber, dass du deine PERMIT ANY ANY Regel nochmal überprüfst/überdenkst.
Möchtest du wirklich ALLES erlauben?
In diesem Moment hast du nämlich "sozusagen" auf der OPT Seite gar keine Firewall mehr. ;)
Wenn alles erlaubt werden soll, kannst du auch gleich nen normalen Router hinstellen. :)

Die MultiSSID Lösung ist ne schöne Sache, falls du das realisiert bekommst.
So kannst du ein Netz für dich WPA2 verschlüsselt benutzen mit erhöhter Sicherheit/ härteren Einstellungen (Stichwort: striktes Ruleset/Regelwerk).
Die Zweite SSID jedoch mit sehr offenem Ruleset, unverschlüsselt aber mit Captive Portal geschützt nur für die Gäste. (Damit verbindest du dich selber nie und dieses Netz darf NUR ins Internet, nicht jedoch in irgendein anderes Netz innerhalb deiner Netzwerkumgebung. Das musst du mit rules vorher abfangen)
Das Kann man dann ja auch gleich "Gästenetz" nennen oder so.

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 12, 2017, 10:45:16 am
Wichtig ist aber, dass du deine PERMIT ANY ANY Regel nochmal überprüfst/überdenkst.
Möchtest du wirklich ALLES erlauben?
In diesem Moment hast du nämlich "sozusagen" auf der OPT Seite gar keine Firewall mehr. ;)
Wenn alles erlaubt werden soll, kannst du auch gleich nen normalen Router hinstellen. :)

Kann ich so nur unterschreiben!
Ich habe mein LAN/WLAN bei meiner OPNSense auch per Brigde verbunden und habe damit meinen 08/15 O2 Router zu Hause abgelöst.
Anschließend habe ich dann einige Grundregeln auf der Bridge 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
- Port 80 (HTTP) läuft über den Proxy der OPNSense (transparent).

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). So kann ich z.B. SSH auf die Firewall nur von meinem Laptop aus machen und von keinem anderen Gerät im Netz. Für Dienste wie FTP, Ipsec, OpenVPN, gilt das Gleiche.
Die meisten Blocks kommen intern übrigens von meinem Samsung Smart TV. Der versucht ständig über diverse Ports nach Hause zu telefonieren! Genau das war der Grund für mich mir eine Firewall für zu Hause anzuschaffen!
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 11:13:32 am
Hi ihr beiden,

Danke für die vielen wertvollen Infos.

Ich war im Netzwerkbereich die letzten jahre nur sehr rudimentär unterwegs, sprich ich hatte nur Standard Setups für meine Netzwerke zu Hause. Also

Modem -----> Router

fertig.

Da ich mir nun alles von Hand Aufbauen muss (und natürlich auch möchte, ich will ja was lernen)  sind viele Erklärungen gerade noch ein wenig erschlagend für mich. Ich versuche mich da ranzuarbeiten.

Die Infos zum Gästenetzwerk werde ich im Kopf behalten. ich möchte erst Mal das Netzwerk an sich so weit bekommen, dass es meinen Sicherheitsanforderungen genügt und dass ich es dann auch verstanden habe, was ich da konfigurert habe.


Nochmal zur Bridge und den Interfaces. ihr schreibt:

Quote
Mit einer Bridge sind die Interfaces verbunden. Das bedeutet, Du hast keine Möglichkeit FW-Regeln zwischen den beiden Interfaces einzurichten. Jeglicher Traffic zwischen den Interfaces ist erlaubt!

Mit der anderen Möglichkeit bekommst Du die volle Kontrolle was den Traffic zwischen den Interfaces angeht. Das bedeutet, Du müsstest zunächst mal entsprechende FW-Regeln erstellen, damit überhaupt ein Traffic zwischen den Interfaces möglich ist bzw. wird.

und...

Quote
Wichtig ist aber, dass du deine PERMIT ANY ANY Regel nochmal überprüfst/überdenkst.
Möchtest du wirklich ALLES erlauben?
In diesem Moment hast du nämlich "sozusagen" auf der OPT Seite gar keine Firewall mehr. ;)
Wenn alles erlaubt werden soll, kannst du auch gleich nen normalen Router hinstellen.


Zum Verständnis: Ist die Bridge denn nicht die einfachste Lösung, wenn ich beide Interfaces zusammen fassen möchte? Die Interfaces trennen, das würde ich evtl. in einer späteren Config machen, wenn ich mir im Klaren darüber bin, wie die Kommunikation zwischen den Interfaces aussehen soll und wie ich das alles im Detail konfigurieren möchte.

Außerdem frage ich mich gerade, warum das OPT Interface dann in der Bridge "sozusagen" keine Firewall mehr hat, durch meine Regeln? Ich definiere doch die Firewall Regeln auf der Bridge (was ja im Moment auch schon greift, da ich ja Netzwerkverkehr habe), um erst Mal überhaupt Kommunikation zwischen den Interfaces zuzulassen, oder?. Wie würden denn dann eure Regeln aussehen, um einen möglichst einfache und fehlerfreie Kommunikation über die Bridge zuzulassen?

Oder einfacher gesagt: Ich möchte ja mit meinem Notebook und meinem Smartphone möglichst unkompliziert auf meine Netzwerkgeräte zugreifen, also auf meine NAS, usw. Und da ich ja noch am Anfang stehe, ist meine Idee dahinter, dass ich zu Beginn alles erlaube und mich dann nach und nach zu einem Regelsatz hocharbeite, in dem ich gewisse Dienste, Ports, usw. einschränke.

Umgekehrt wäre es natürlich deutlich sicherer (also erst mal nichts zulassen und dann nach und nach aufbohren), aber das würde bedeuten, ich muss erst mal mit einem eingeschränkten Netzwerk leben und ich habe nicht so furchtbar viel Zeit, um das mal eben schnell zu konfigurieren, zumal mir dan wohl die Frau des Hauses direkt aufs Dach steigt. ^^

Stufenweise Regeln anzulegen zur Einschränkung gewisser Kommunikation würde ja auch bedeuten, dass ich irgendwann an dem Punkt bin, an dem ich weiß, was ich erlauben will und was nicht  und dann kann ich die Config ja immer noch umdrehen und von "nichts erlaubt" aus neu starten.

Ansonsten wäre ich sehr dankbar für einen tieferen Einblick in das Zusammenspiel der beiden Interfaces. ;) Ich möchte ja vorerst möglichst geringen Konfigurationsaufwand für mein ganzes Netzwerk, um alles kennen zu lernen. Daher hatte ich das Gefühl, dass LAN und OPT als Bridge auch die einfachste Lösung bietet, damit alle Gerät erst mal miteinander kommunizieren können.


----
EDIT:

Ich habe gerade die Antwort erst gesehen:


Quote
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). So kann ich z.B. SSH auf die Firewall nur von meinem Laptop aus machen und von keinem anderen Gerät im Netz. Für Dienste wie FTP, Ipsec, OpenVPN, gilt das Gleiche.
Die meisten Blocks kommen intern übrigens von meinem Samsung Smart TV. Der versucht ständig über diverse Ports nach Hause zu telefonieren! Genau das war der Grund für mich mir eine Firewall für zu Hause anzuschaffen!

Ok, das hört sich alles stark nach meinen ersten Anferderungen an. Ich möchte das Gleiche erreichen, also z.b. die Kommunikation meines TV und meiner Konsole überwachen bzw. einschränken und die ganzen Standards für meine Netzwerk Clients erlauben. 

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

Das bedeutet, es wird immer die gleiche DHCP Zuweisung für ein festes Gerät gespeichert und somit ist jedes Gerät über den Alias identifizierbar, um darauf die Regeln überhaupt anwenden zu können?
 
Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: chemlud on January 12, 2017, 11:20:18 am
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.

Du kannst ja per Firewallregeln ganz gezielt aus einem Netz in's andere (aber halt vielleicht nur in einer Richtung) Verkehre (welche? SMB? VNC? ....?) erlauben. Nur so bekommst du eine Sicherheitsstruktur in dein Netz. 
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 11:33:54 am
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.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 11:40:22 am
@chemlud

Quote
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?
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 11:49:49 am
@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?

Quote
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 11:53:46 am
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. ;)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 12:14:48 pm
@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.

Quote

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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 12, 2017, 12:24:47 pm
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.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 12:39:48 pm
Quote
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 12:44:53 pm
Quote
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ß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 01:18:10 pm
Quote
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.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 01:26:05 pm

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.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 01:27:27 pm
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ß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 01:28:37 pm
Quote
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?
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 02:11:04 pm
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 12, 2017, 02:13:34 pm

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)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 12, 2017, 02:46:04 pm
@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


Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 12, 2017, 03:27:29 pm
@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. :)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: fabian on January 12, 2017, 03:52:27 pm
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 12, 2017, 05:23:17 pm
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 13, 2017, 09:25:46 am
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.

Quote
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. :)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 14, 2017, 06:26:21 pm
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:

 
Quote
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 14, 2017, 06:27:41 pm
Hier noch der Screenshot zu den WAN Regeln, das passte von der Größe her nicht mehr in den vorherigen Beitrag.

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 14, 2017, 07:17:00 pm
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.

Quote
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).

Quote
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:

Quote
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 :D ;)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: fabian on January 14, 2017, 09:37:36 pm
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.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 14, 2017, 09:47:53 pm
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. :)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: fabian on January 14, 2017, 10:18:00 pm
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 14, 2017, 10:43:48 pm
Hi Oxygen,

Quote
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. :D

Quote
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.

Quote
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.

Quote
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. ;)

Quote
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). :D

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 15, 2017, 01:12:59 am
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. 
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 15, 2017, 01:28:57 am
Quote
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. :)

Quote
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

Quote
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). :D

Ahhhh alles klar. Die Fraggles muss man einfach lieben :D

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 15, 2017, 12:28:08 pm
HI Oxy,

Quote
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:

Quote
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?

Quote
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:

Quote
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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 15, 2017, 12:48:27 pm
@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
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 15, 2017, 01:03:46 pm
Hi Dirk,

Ok Danke. :)

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 15, 2017, 01:05:48 pm
Noch mal zum DHCP Static Mapping:

Benötige ich das Static ARP? Ich müsste das für den DHCP am Interface aktivieren, um es im Mapping nutzen zu können.

Und noch eine Frage zu den Firewall Aliasen:

Als Host trage ich im Alias dann den Hostnamen ein, den ich im DHCP Static Mapping vergeben habe, richtig?

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 15, 2017, 05:09:02 pm
Als Host trage ich im Alias dann den Hostnamen ein, den ich im DHCP Static Mapping vergeben habe, richtig?
Klar, kannst Du so machen. Die Aliases gehen wesentlich weiter und sind nicht auf einen Host beschränkt.
Als Alias lassen lassen sich mehrere Hosts bzw. IP's oder Ports definieren.
Wenn Du also nur einigen Devices eine Verbindung über HTTPS (443) erlauben willst, fasst Du einfach alle Devices in einer Aliasgruppe zusammmen. Und die Firewallregel für HTTPS (443) weist Du dann nur dieser Aliasgruppe zu.

Ist natürlich klar, dass Du zuvor allen Devices eine feste IP-Lease zugewiesen haben musst (DHCP), oder Deine Geräte verwenden alle eine statische IP.

Beispielregel:
Proto      Source      Port   Destination   Port   Gateway   Schedule           Description      
IPv4 UDP           LAPTOPS     *   *              1194 (OpenVPN)   *      OpenVPN 1194 UDP -> any

Mit dieser Regel können nur Devices der Aliasgruppe 'LAPTOPS' per OpenVPN aus dem NW heraus.

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 15, 2017, 10:07:50 pm
Hallo Dirk,

Danke, ich hab dazu auch ein bisschen was gelesen heute.

Ich stocke aber gerade schon an der ersten Firewall Regel.

Ich habe auf meinem WLAN Interface die Deny All All Regel angelegt. Diese steht ja als letzte Regel.

Dann habe ich die "alte" Allow Any Regel deaktiviert und eine eigene neue geschrieben.

Ich wollte ganz simpel HTTP und HTTPS erlauben auf dem WLAN Interface. Also habe ich die Regel angelegt mit folgenden Parametern:

Action: Pass
Interface: WLAN
TCP/IP Version: IPv4
Protocol: TCP
Source: WLAN net
Destination: any
Destination port range: HTTP to HTTPS (sollte ja 80 und 443 sein)

Nach dem Anwenden der Regel, lassen sich Webseiten nicht mehr aufrufen.

Das Firewall Log hilft mir ehrlich gesagt gerade nicht sonderlich weiter, da dort unglaublich viele Logeinträge landen, die meine Gateway IP (also die IP meines Kabelmodems) beinhalten mit den unterschiedlichsten Ports.

Ich bin vielleicht auch einfach zu müde oder sehe den Wald vor lauter Bäumen nicht mehr, aber ich steh grad auf dem Schlauch...

Gruss
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 15, 2017, 11:45:25 pm
Quote
Ich wollte ganz simpel HTTP und HTTPS erlauben auf dem WLAN Interface.
Destination port range: HTTP to HTTPS (sollte ja 80 und 443 sein)

Schreib dafür lieber zwei einzelne Regeln der Übersicht halber.
Ansonsten schreib lieber immer die Subnetze, bzw. die IPs.
Also anstatt "WLAN net" dann lieber das Subnetz z.B. 192.168.1.0 /24
In der Beschreibung kannst du dann ja hinschreiben was du damit meintest z.B.:
WLAN Netz --> Internet --> erlauben

Ich geh mal stark davon aus das du einfach noch keine DNS Regel-Freischaltung geschrieben hast. ;)
Also noch Port 53 (DNS) für UDP und TCP freischalten und nachschauen ob du denn auch überhaupt schon DNS Server eingetragen hast in deiner Firewall.
Das gleiche gilt für NTP. Ebenfalls freischalten und gegebenenfalls in der Firewall einen NTP Server eintragen.

Gibt nichts schlimmeres als zu versuchen im verschlafenen Zustand das "Netzwerken" zu verstehen.
Morgen ist auch noch ein Tag :P

Schöne Grüße
Oxy

Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 16, 2017, 08:59:44 am
@neOh
Hallo Chris,
anbei mal meine FW-Regeln auf meiner Bridge als Anregung für Dich.
Das Source-Netz müsstest Du halt entsprechende Deiner Namenskonvention anpassen. Und ja, ich habe das Regelset auch nur für IPv4 angelegt. ;)
Meine individuellen Regeln hab ich mal ausgeblendet und zu beachten wäre noch, dass der Port 80  bei mir über den transparenten Proxy läuft.
Wenn Du das nicht möchtest, brauchst Du noch eine Regel für Port 80 (analog zur HTTPS-Regel).
Die entsprechenden Regeln für den Proxy werden von der OPNSense automatisch erzeugt, wenn Du den Proxy einrichtest!

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 08:38:21 am
Guten morgen zusammen,

@Dirk,

erst mal vielen Dank für deinen Screenshot. Das wird mir auf jeden Fall weiter helfen! :)

Hab natürlich Fragen dazu. ^^

Zum DNS (und quasi auch NTP):

Warum ist das nur intern? Ich vermute, damit erst mal nur die intern eingetragenen DNS Server verwendet werden, statt anderweitiger, das ist klar. Aber wo ist hier der Vorteil/Unterschied?

Zum DNS stellt sich mir auch die Frage, ob ich die Server noch mal Explizit eintragen muss im OPNsense Backend (so wie es Oxygen schon angedeutet hatte) oder ob es reicht, dass die Server in meinem Modem eingetragen sind? Ich habe im Modem (das ist ne einfache Horizon Box von Unitymedia) zwei DNS Server hinterlegt, einen Public DNS von Google (8.8.4.4.) und einen von DNS.WATCH (https://dns.watch/index).

Bzw. welchen Unterschied macht es überhaupt, ob ich einen DNS Server in der Firewall oder im Modem eintrage? Soweit ich mich erinnere (ich sitze gerade nicht vor der Firewall zu Hause), hatte ich gesehen, dass die Firewall die DNS Server vom Modem übernommen hatte und noch einen Localhost (127.0.0.1) mit eingetragen hatte. Aber da würde ich noch genau nachschauen abends, vielleicht erzähle ich gerade auch Unsinn.

Kann ich denn evtl. sogar die DNS Server nur in die Firewall eintragen und im Modem komplett entfernen?

Dann nur aus reiner Neugier: Du hast ja im Screenshot sichtbar noch ne Menge anderer Interfaces, auf deinen LAN und WLAN Interfaces sind dementsprechend keine Regeln hinterlegt, weil Du ja alles über die Bridge machst, richtig?

Die letze Regel in deinem Screenshot ist die automatische vom Proxy, richtig? Macht es hier Sinn, den Proxy direkt von Beginn an zu aktivieren? Oder ist der Config Aufwand doch erheblicher, so daß ich das lieber nachträglich mache? Imöchte mir das nicht direkt verkomplizieren. ;)

@Oxygen

Quote
Schreib dafür lieber zwei einzelne Regeln der Übersicht halber.
Ansonsten schreib lieber immer die Subnetze, bzw. die IPs.
Also anstatt "WLAN net" dann lieber das Subnetz z.B. 192.168.1.0 /24
In der Beschreibung kannst du dann ja hinschreiben was du damit meintest z.B.:
WLAN Netz --> Internet --> erlauben

Mache ich.

Quote

Ich geh mal stark davon aus das du einfach noch keine DNS Regel-Freischaltung geschrieben hast. ;)
Also noch Port 53 (DNS) für UDP und TCP freischalten und nachschauen ob du denn auch überhaupt schon DNS Server eingetragen hast in deiner Firewall.
Das gleiche gilt für NTP. Ebenfalls freischalten und gegebenenfalls in der Firewall einen NTP Server eintragen.

Jap, hatte ich nicht gemacht. Somit logisch, dass es nicht ging. Danke. ;) Bzgl. DNS habe ich das ja grade weiter oben thematisiert, mir ist der Unterschied noch nicht ganz klar, wo die DNS Server eingetragen sein sollten (Modem, Firewall? Und warum nur lokal?).

Übrigens, habt ihr Empfehlungen für einen guten, schnellen DSN Server? Ich habe in letzter Zeit viel darüber gelesen, dass Googles public DNS Server aktuell Probleme machen (hoher Paketverlust, angeblich irgendwelche Peering Probleme). Die DNS.WATCH Server habe ich seit 2-3 Wochen erst drin und würde behaupten, die sind auch nicht die aller schnellsten aber auch nicht unbedingt langsam, irgendwo im Mittelfeld.


Und letztlich noch etwas zu meinem Firewall Log. Ich hänge euch einen Screenshot an von heute Morgen.  Darauf zu sehen ist ein kleiner Asuzug meines Logs.

Für mich eindeutig sind die Einträge, wenn sich mein Rechner (der hat da die 192.168.1.101) aus dem WLAN heraus zur Firewall (192.168.1.1) verbindet.

Dann gibt es da aber die ganzen Einträge, mit der Source 192.168.192.65 (das ist die statische IP, die ich der Firewall Appliance am WAN Interface zugewiesen habe von meinem Kabelmodem aus, ich habe am Kabelmodem DHCP deaktiviert und die Firewall ist das einzige Gerät am WAN Port).

Source 192.168.192.65 bedeutet ja, Datenverkehr geht von meiner WAN Schnittstelle raus an die jeweilige Destination IP (ich habe mal alle IPs entfernt, die nicht DNS bzw, meine Firewall intern sind). Soweit klar. Darunter sind auch IPs, die zu irgendwelchen Servern in Taiwan gehören. Ich vermute stark (und darum habe ich mir die Firewall ja auch zugelegt), dass da z.B. mein Smart TV fleißig kommuniziert in Richtung Asien. Es findet sich aber auch eine IP, die zu einem Server eines Messengers gehört, usw.

Müsste ich denn, meinem Verständnis nach, im Log nun nicht im Feld "Source" die IP des jeweiligen Gerätes sehen, anstatt der IP, die das WAN Interface hat?  Denn so, ist das doch ein wenig witzlos. Ich will doch wissen, welches Gerät da wohin telefoniert. Und spätestens, wenn ich zwei Geräte habe, die beide z.B. den gleichen Messenger nutzen, dann sehe ich nur, dass am WAN Interface Datenpakete raus gehen, aber von welchem Gerät, weiß ich spätestens dann doch nicht mehr? Oder habe ich hier gerade einen kompletten Denkfehler drin?

Und was genau sagt mir der ankilckbare, orangene Pfeil in der Spalte "Act"? Wenn ich mit der Maus darüber gehe, dann erscheint in der Hover Anzeige der Text "Pass" (Ich habe  auch schon ein orangenes Kreuz dort gesehen, mit dem Text "Dismiss" glaube ich). Ich möchte nicht wild rumklicken und mir die Firewall kaputt konfigurieren, darum habe ich das auch nicht getestet. Könnt ihr mich bitte erleuchten? ^^


Gruß
Chris

 
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 09:13:51 am
Quote
Bzgl. DNS habe ich das ja grade weiter oben thematisiert, mir ist der Unterschied noch nicht ganz klar, wo die DNS Server eingetragen sein sollten (Modem, Firewall? Und warum nur lokal?).
Der Vorteil ist, das du auch hier wieder deine Clients und Geräte in der Hinsicht absicherst, indem du sie dazu zwingst nur den DNS Server zu nehmen den du in der Firewall rein geschrieben hast.

Der Ablauf wäre also folgender Maßen:
[DNS Server] --> {WAN}[Firewall]{LAN} --> [CLIENT]

Erklärung:
Der Client holt sich per DHCP die LAN IP des Firewall Interfaces und trägt diese als seinen DNS ein und fragt die Firewall bei Namensauflösungen.
Die Firewall fragt bei Namensauflösungen dann weiter bei dem Public DNS Server nach.
Der Vorteil hierbei wäre ganz einfach das, wenn der Client manuell einen anderen DNS Server einträgt, z.B. 8.8.8.8, dieser durch die Firewall nicht erlaubt wird. Die Firewall erlaubt ja durch die Regel auf der LAN Seite nur die DNS (53) Abfragen hin zum Interface der Firewall.
Wenn der User sich eine Schadware eingefangen hat, die den DNS Eintrag ändert und so versucht, Anfragen für Google, Twitter usw. auf falsche Webseiten umzuleiten wird dies nicht funktionieren.
Sicher gibt es noch andere Gründe warum das gut ist.
Zu mindestens für mich war das aber immer der plausibelste Grund. :)

Für NTP gilt der Gleiche Gedankengang.

An deiner Stelle würde ich versuchen das Modem so "dumm" zu halten wie nötig
und alles wichtige über die Firewall abwickeln zu lassen.

Quote
Übrigens, habt ihr Empfehlungen für einen guten, schnellen DSN Server?

Ich nutze seit gut einem Jahr jetzt schon OpenDNS, siehe: https://www.opendns.com/
Genauer gesagt hier die DNS Möglichkeiten: https://www.opendns.com/home-internet-security/
Gefühlt VIEEEEL schneller als der Google DNS...
OpenDNS hat ebenfalls Blacklists die dann z.B. dafür Sorgen, dass bestimmte Webseiten einfach nicht aufgelöst werden, wenn diese als gefährlich eingestuft wurden.
Weiterhin hat Cisco jetzt den Hut auf, man kann also davon ausgehen, das die dort Ahnung haben.
Google vertrau ich generell nicht, sodass da die Lösung für mich offensichtlich war.

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 17, 2017, 09:27:34 am
@neOh
Hallo der Oxy hat das im Prinzip ja schon sehr schön zusammen gefasst.
DNS- und NTP-Service für das interne LAN bietet ausschließlich die OPNSense an. Ich sehe den Vorteil in der Minimierung der WAN-Zugriffe und außerdem ist so sichergestellt, dass die Clients nur die DNS-Server nutzen, die ich auch in der OPNSense eingetragen hab!
Dazu mal 2 Links:
Zum Thema DNS-Zensur:
https://www.ccc.de/censorship/dns-howto/
Ich nutze DNS-Server aus diesem Projekt:
https://www.opennicproject.org/

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 09:31:12 am
Edit, hier der Anhang zum Log:
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 09:36:31 am
Hi,

Sorry, hab zu meinem Beitrag noch einen Absatz zum Log angehängt, hoffe das ist nicht durcheinandern gekommen. Darum auch der Anhang mit dem Screenshot im einzelnen Beitrag.

Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 09:36:57 am
Ich nutze DNS-Server aus diesem Projekt:
https://www.opennicproject.org/

Opennic ist auch sehr cool. :)
Siehe dazu: https://prism-break.org/de/projects/opennic/

EDIT:
Hierzu sei auch nochmal gesagt. Es ist völlig egal welchen DNS Server du einträgst, WENN du denn so oder so vorhast am Ende sämtliche Kommunikation über eine VPN Lösung zu versenden.
Ist dir Privatsphäre wichtig und du hast nicht vor VPN in dein Netzwerk mit einzubauen,
dann würde ich dir einen aus dieser Liste hier empfehlen:
https://prism-break.org/de/protocols/dns/
Von OpenNIC hört man nichts schlechtes, von daher würde ich dir da Raten dort dich noch einmal einzulesen. :)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 09:40:40 am
Quote
Erklärung:
Der Client holt sich per DHCP die LAN IP des Firewall Interfaces und trägt diese als seinen DNS ein und fragt die Firewall bei Namensauflösungen.
Die Firewall fragt bei Namensauflösungen dann weiter bei dem Public DNS Server nach.
Der Vorteil hierbei wäre ganz einfach das, wenn der Client manuell einen anderen DNS Server einträgt, z.B. 8.8.8.8, dieser durch die Firewall nicht erlaubt wird. Die Firewall erlaubt ja durch die Regel auf der LAN Seite nur die DNS (53) Abfragen hin zum Interface der Firewall.
Wenn der User sich eine Schadware eingefangen hat, die den DNS Eintrag ändert und so versucht, Anfragen für Google, Twitter usw. auf falsche Webseiten umzuleiten wird dies nicht funktionieren.
Sicher gibt es noch andere Gründe warum das gut ist.
Zu mindestens für mich war das aber immer der plausibelste Grund. :)

Ah, perfekt erklärt, Danke!

Quote
An deiner Stelle würde ich versuchen das Modem so "dumm" zu halten wie nötig
und alles wichtige über die Firewall abwickeln zu lassen.

Guter Hinweis, das heißt, DNS Server im Modem raus.

Quote

Ich nutze seit gut einem Jahr jetzt schon OpenDNS, siehe: https://www.opendns.com/
Genauer gesagt hier die DNS Möglichkeiten: https://www.opendns.com/home-internet-security/
Gefühlt VIEEEEL schneller als der Google DNS...
OpenDNS hat ebenfalls Blacklists die dann z.B. dafür Sorgen, dass bestimmte Webseiten einfach nicht aufgelöst werden, wenn diese als gefährlich eingestuft wurden.
Weiterhin hat Cisco jetzt den Hut auf, man kann also davon ausgehen, das die dort Ahnung haben.
Google vertrau ich generell nicht, sodass da die Lösung für mich offensichtlich war.

Quote
Ich nutze DNS-Server aus diesem Projekt:
https://www.opennicproject.org/

Werde mir beide mal anschauen und testen. :) Danke.

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 09:49:18 am
Quote
Guter Hinweis, das heißt, DNS Server im Modem raus.
Genau. Den DNS trägst du bei OPNsense hier ein:
System > Settings > General

Quote
Werde mir beide mal anschauen und testen. :) Danke.
Hierzu vielleicht auch noch mal mein Nachtrag im Post davor. :)
Der Größte Unterschied ist die Frage der Privatsphäre.
Am Ende bist du aber besser bedient, wenn du keinen Google DNS nimmst,
egal für was du dich schlussendlich entscheidest.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 10:03:57 am
EDIT:

Hier gab es beim Posten des Beitrags grade einen Fehler. Beitrag steht auf der nächsten Seite.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 10:09:52 am
Quote
Genau. Den DNS trägst du bei OPNsense hier ein:
System > Settings > General

Wird gemacht. ;)

Quote

Hierzu vielleicht auch noch mal mein Nachtrag im Post davor. :)
Der Größte Unterschied ist die Frage der Privatsphäre.
Am Ende bist du aber besser bedient, wenn du keinen Google DNS nimmst,
egal für was du dich schlussendlich entscheidest.

Ja, Privatsphäre war schon lange ein Thema, aber wenn man da dann mal tatsächlich ran geht, merkt man erst, was da alles mit rein spielt. ;) Ich werde mal beides testen.  OpenNIC scheint ja auch alle TLDs aufzulösen.

Frage zu OpenDNS, das Du nutzt: Das Anlegen eines Accounts dort ist eher zu Marketingzwecken für Cisco, richtig? ;) Zur Nutzung bedarf es dessen ja nicht und ich kann einfach frei deren DNS IPs eintragen?

Könntest Du noch mal in meinen Beitrag schauen, in den letzten Absatz? Den hatte ich hinzugefügt bezüglich meiner Firewall Logs. Ich glaube, das ist untergegangen. ;) Danke!

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 10:23:34 am
Quote
Ja, Privatsphäre war schon lange ein Thema, aber wenn man da dann mal tatsächlich ran geht, merkt man erst, was da alles mit rein spielt. ;) Ich werde mal beides testen.  OpenNIC scheint ja auch alle TLDs aufzulösen.

Frage zu OpenDNS, das Du nutzt: Das Anlegen eines Accounts dort ist eher zu Marketingzwecken für Cisco, richtig? ;) Zur Nutzung bedarf es dessen ja nicht und ich kann einfach frei deren DNS IPs eintragen?
Was du hier halt miteinander vergleichst ist "Privatsphäre" und "Blacklists durch OpenDNS".
Je nachdem was du da für ein "Profil" dir aussuchst
hast du dann wohl noch die Möglichkeit diese Blacklist für dich zu verfeinern.
Ob das funktioniert und wie sich das bemerkbar macht in der Konfiguration bei OPNsense? Keine Ahnung.
Ich nutze selber nur die beiden "frei verfügbaren" DNS IPs, wofür man sich nicht registrieren muss.

Quote
Könntest Du noch mal in meinen Beitrag schauen, in den letzten Absatz? Den hatte ich hinzugefügt bezüglich meiner Firewall Logs. Ich glaube, das ist untergegangen.
Hatte ich gesehen, aber welche Frage hast du bezüglich der Logs?
Was ich komisch fand war der Port 5222, der bei dir erlaubt wurde.
Ich glaube mich zu erinnern, dass der für Whatsapp oder Google Push war.
Falls du das also brauchst ist alles gut. :)

Bei mir sind noch zusätzlich immer viele NTP Verbindungen und die Zugriffe vom WAN Interface auf den Public DNS Server.
Aber dein Netz is ja auch komplett anders. Wichtig sind die Regeln.
Mit dem Log is es immer schwierig was mit anzufangen.
Da sieht man nur immer ob irgendwelche "merkwürdigen" Ports durchkommen.
Für dich jetzt die Regeln zu formulieren is natürlich schwierig. Die Basics hatte monstermania gepostet.
Zusätzlich sollte man noch Port 445 und 135-139 unter Kontrolle bringen.
Hierfür: https://www.grc.com/port_445.htm
Im Anhang meine beiden Regeln dazu aus dem WLAN Subnetz.

EDIT:
Anmerkung vielleicht noch zur allgemeinen Formulierung von Regeln.
Ganz oben stehen immer die speziellsten Regeln, also zum Beispiel:
Client IP -> Destination IP -> Port 80

Umso ungenauer die Regeln werden, umso weiter unten sollten sie stehen.
Weiterhin versucht man stets erst soviel zu blocken wie möglich ist, bevor man anfängt große Netz und Portbereiche freizuschalten. Das liegt daran, dass  nach dem ersten Match mit einer Regel nicht weiter geschaut wird. Erlaubst du also einen großen Netzbereich und verbietest eine Regel danach innerhalb dieses Bereiches 2 IPs wird diese Regel niemals angewendet, diese beiden IPs also nicht geblockt.

Um das zu verdeutlichen. Meine HTTP und HTTPS Freischaltungen, weil diese als Destination "any" haben, liegen bei mir als letzte Regeln vor.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 10:44:04 am
Quote
Was du hier halt miteinander vergleichst ist "Privatsphäre" und "Blacklists durch OpenDNS".
Je nachdem was du da für ein "Profil" dir aussuchst
hast du dann wohl noch die Möglichkeit diese Blacklist für dich zu verfeinern.
Ob das funktioniert und wie sich das bemerkbar macht in der Konfiguration bei OPNsense? Keine Ahnung.
Ich nutze selber nur die beiden "frei verfügbaren" DNS IPs, wofür man sich nicht registrieren muss.

Ok, glaube das kam falsch rüber, was ich meinte. ;) Mir ging es ausschliesslich um einen alternativen DNS zu Google (das war mein Punkt hinsichtlich Privatsphäre). Die ganzen Blacklist Profile dort wollte ich nicht nutzen.

Quote
Hatte ich gesehen, aber welche Frage hast du bezüglich der Logs?
Was ich komisch fand war der Port 5222, der bei dir erlaubt wurde.
Ich glaube mich zu erinnern, dass der für Whatsapp oder Google Push war.
Falls du das also brauchst ist alles gut. :)

Das war dann doch untergegangen. :D Ich hatte in meinem ersten Beitrag von heute Morgen noch mal editiert und einen Absatz hinzugefügt. ;) Ich poste den hier jetzt nochmal dazu, dann siehst Du meine Fragen zu meinem Log:

----
Kopiert von der Vorseite:

Quote
Und letztlich noch etwas zu meinem Firewall Log. Ich hänge euch einen Screenshot an von heute Morgen.  Darauf zu sehen ist ein kleiner Asuzug meines Logs.

Für mich eindeutig sind die Einträge, wenn sich mein Rechner (der hat da die 192.168.1.101) aus dem WLAN heraus zur Firewall (192.168.1.1) verbindet.

Dann gibt es da aber die ganzen Einträge, mit der Source 192.168.192.65 (das ist die statische IP, die ich der Firewall Appliance am WAN Interface zugewiesen habe von meinem Kabelmodem aus, ich habe am Kabelmodem DHCP deaktiviert und die Firewall ist das einzige Gerät am WAN Port).

Source 192.168.192.65 bedeutet ja, Datenverkehr geht von meiner WAN Schnittstelle raus an die jeweilige Destination IP (ich habe mal alle IPs entfernt, die nicht DNS bzw, meine Firewall intern sind). Soweit klar. Darunter sind auch IPs, die zu irgendwelchen Servern in Taiwan gehören. Ich vermute stark (und darum habe ich mir die Firewall ja auch zugelegt), dass da z.B. mein Smart TV fleißig kommuniziert in Richtung Asien. Es findet sich aber auch eine IP, die zu einem Server eines Messengers gehört, usw.

Müsste ich denn, meinem Verständnis nach, im Log nun nicht im Feld "Source" die IP des jeweiligen Gerätes sehen, anstatt der IP, die das WAN Interface hat?  Denn so, ist das doch ein wenig witzlos. Ich will doch wissen, welches Gerät da wohin telefoniert. Und spätestens, wenn ich zwei Geräte habe, die beide z.B. den gleichen Messenger nutzen, dann sehe ich nur, dass am WAN Interface Datenpakete raus gehen, aber von welchem Gerät, weiß ich spätestens dann doch nicht mehr? Oder habe ich hier gerade einen kompletten Denkfehler drin?

Und was genau sagt mir der ankilckbare, orangene Pfeil in der Spalte "Act"? Wenn ich mit der Maus darüber gehe, dann erscheint in der Hover Anzeige der Text "Pass" (Ich habe  auch schon ein orangenes Kreuz dort gesehen, mit dem Text "Dismiss" glaube ich). Ich möchte nicht wild rumklicken und mir die Firewall kaputt konfigurieren, darum habe ich das auch nicht getestet. Könnt ihr mich bitte erleuchten? ^^

----

Port 5222 ist ein Messenger, ja. :) Aber ich habe ja auch nocht nicht alles geblockt, ich beginne damit erst, darum geht das alles noch durch.

Quote
Zusätzlich sollte man noch Port 445 und 135-139 unter Kontrolle bringen.
Hierfür: https://www.grc.com/port_445.htm
Im Anhang meine beiden Regeln dazu aus dem WLAN Subnetz.

Die werde ich hinzufügen, Danke.

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 10:46:16 am
Quote
Anmerkung vielleicht noch zur allgemeinen Formulierung von Regeln.
Ganz oben stehen immer die speziellsten Regeln, also zum Beispiel:
Client IP -> Destination IP -> Port 80

Umso ungenauer die Regeln werden, umso weiter unten sollten sie stehen.
Weiterhin versucht man stets erst soviel zu blocken wie möglich ist, bevor man anfängt große Netz und Portbereiche freizuschalten. Das liegt daran, dass  nach dem ersten Match mit einer Regel nicht weiter geschaut wird. Erlaubst du also einen großen Netzbereich und verbietest eine Regel danach innerhalb dieses Bereiches 2 IPs wird diese Regel niemals angewendet, diese beiden IPs also nicht geblockt.

Um das zu verdeutlichen. Meine HTTP und HTTPS Freischaltungen, weil diese als Destination "any" haben, liegen bei mir als letzte Regeln vor.

Jau, das hatte ich zuletzt auch so gelesen und verstanden, diese "First Match" Auswertung der Firewall. Danke.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 11:09:08 am
So ganz hinter gestiegen bin ich bei den Logs auch noch nich.
Bei mir sind auch zwei Phänomene die sich nicht erklären lassen.
Wenn ich mit meinem Handy Reddit öffne, sehe ich die Regel für die Verbindung zu den Reddit Servern nich,
sondern nur die Regelanwendung für einen Amazon Server.
Weiterhin erlaube ich vom WLAN Netz den http und https Traffic ins Internet.
laut Log werden die Verbindungen mit der Source "WLAN Netz" zu "öffentliches Netz" alle blockiert.
Ich kann aber trotzdem surfen. Entferne ich die HTTP und/oder HTTPS Regel aber in meinem Regelwerk, is die Verbindung ins Internet nicht mehr möglich.

Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite (Alles müsste daher geblockt werden, auch der Zugriff auf den DNS oder NTP Server). Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

So ganz logisch erscheint mir das Firewall Log auch nich, bist da also nicht allein. :P
Bei Firewall > Diagnostics > pfTop kannst du zumindestens die aufgebauten Verbindungen sehen.
Das sagt zwar nur bedingt etwas über dein Regelwerk aus. Dort kannst du aber sehen, welches Gerät(IP) eine Verbindung mit welchem Server establishen konnte.

Quote
Und was genau sagt mir der ankilckbare, orangene Pfeil in der Spalte "Act"? Wenn ich mit der Maus darüber gehe, dann erscheint in der Hover Anzeige der Text "Pass" (Ich habe  auch schon ein orangenes Kreuz dort gesehen, mit dem Text "Dismiss" glaube ich). Ich möchte nicht wild rumklicken und mir die Firewall kaputt konfigurieren, darum habe ich das auch nicht getestet. Könnt ihr mich bitte erleuchten? ^^
Du bekommst dann ne Meldung von der Webseite welche Regel angewendet wird.
Die Ausgabe ist aber konfus, sodass man damit nichts anfangen kann.
Bei mir kommt zum Beispiel ganz oft dann die Meldung "Default Deny Rule IPv4". ::)
Was mir das nun sagen soll. Wer weiß..  ;)

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 11:23:18 am
Quote
Wenn ich mit meinem Handy Reddit öffne, sehe ich die Regel für die Verbindung zu den Reddit Servern nich,
sondern nur die Regelanwendung für einen Amazon Server.

Das liegt dann aber wahrscheinlich daran, dass Reddit da teils hostet bei AWS (http://www.redditstatus.com/  -> AWS ec2-us-east-1 ) ?

Quote
Weiterhin erlaube ich vom WLAN Netz den http und https Traffic ins Internet.
laut Log werden die Verbindungen mit der Source "WLAN Netz" zu "öffentliches Netz" alle blockiert.
Ich kann aber trotzdem surfen. Entferne ich die HTTP und/oder HTTPS Regel aber in meinem Regelwerk, is die Verbindung ins Internet nicht mehr möglich.

 ??? Ich hatte da diesen "Invert Rule" Haken gesehen, den man setzen kann. Vielleicht ist das zufällig aktiv?

Quote
Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite (Alles müsste daher geblockt werden, auch der Zugriff auf den DNS oder NTP Server). Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

Hmmm, da muss ich gestehen, dass ich das nicht verstehe. Sagtest Du nicht, dass Outbound Traffic erstmal immer erlaubt ist, bis man ihn selbst aktiv blockt (also mit der letzten DENY ANY ANY Regel) ?

Quote
So ganz logisch erscheint mir das Firewall Log auch nich, bist da also nicht allein. :P

Sehr gut.  ;D

Quote
Bei Firewall > Diagnostics > pfTop kannst du zumindestens die aufgebauten Verbindungen sehen.
Das sagt zwar nur bedingt etwas über dein Regelwerk aus. Dort kannst du aber sehen, welches Gerät(IP) eine Verbindung mit welchem Server establishen konnte.

Ok, das ist zumindest ein Anfang. Aber wenn ich Dich richtig verstanden habe, dann ist das "normal", dass die Logs die IP das WAN Interface anzeigen statt die IP des internen Netz Clients?

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 11:36:48 am
Quote
Das liegt dann aber wahrscheinlich daran, dass Reddit da teils hostet bei AWS (http://www.redditstatus.com/  -> AWS ec2-us-east-1 ) ?

Ich krieg dann einmal "ec2-35-161-10-61.us-west-2.compute.amazonaws.com" und "fra15s09-in-f10.1e100.net", welche beide blockiert werden vom WLAN ins Internet.
Erlaubt wird dann outbound Traffic vom WAN auf "fra15s09-in-f3.1e100.net"

Quote
??? Ich hatte da diesen "Invert Rule" Haken gesehen, den man setzen kann. Vielleicht ist das zufällig aktiv?

Nein den hab ich nich gesetzt. Den kannst du zum Beispiel nehmen, wenn du innerhalb eines Subnetzes 2 IPs blockieren willst, den rest aber erlauben möchtest. Normalerweise würde man dann zwei Regeln schreiben. Mit der invert Funktion erlaubst du diese beiden IPs und invertierst dann und bekommst das gleiche Ergebniss mit einer Regel weniger.

Quote
Hmmm, da muss ich gestehen, dass ich das nicht verstehe. Sagtest Du nicht, dass Outbound Traffic erstmal immer erlaubt ist, bis man ihn selbst aktiv blockt (also mit der letzten DENY ANY ANY Regel) ?

Nein. Es müsste genau andersherum sein. Default mäßig wird von der OPNsense immer erst einmal alles blockiert.
Schreibst du keine Pass Regeln wird ALLES blockiert, egal ob inbound oder outbound. Das steht innerhalb der Rules auch ganz unten in der kleinen Schrift:
"Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed). This means that if you use block rules, you'll have to pay attention to the rule order. Everything that isn't explicitly passed is blocked by default."
Das ist die DENY ANY ANY Regel die immer automatisch am Ende ausgeführt wird, falls keine andere Regel greift.

Quote
Ok, das ist zumindest ein Anfang. Aber wenn ich Dich richtig verstanden habe, dann ist das "normal", dass die Logs die IP das WAN Interface anzeigen statt die IP des internen Netz Clients?

Das ist meine Vermutung, weil meine Logs sonst nicht mit meinen Rules übereinstimmen.
Bestätigen kann ich das aber leider nicht.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 12:00:22 pm
Okay also es is wie ich schon vermutet hatte.
Ich versteh zwar nich warum das Firewall Log dann so unnötig undurchsichtig wird, aber ich hatte grade etwas versucht.
Mein Handy verschickt die ganze Zeit SIP-TLS (Port 5061) Anfragen nach draußen.
Die werden laut Log vom WLAN ins Internet blockiert, genauso wie bei HTTP und HTTPS.
Der Unterschied ist, dass es für den Outbound Traffic aus dem WAN Interface auf den Port 5061 im Gegensatz zu HTTP/HTTPS keine Einträge gibt.
Nun hab ich mir mal den Spaß gemacht und Port 5061 freigeschalten.
Siehe da, plötzlich gab es WAN outbound Traffic als "erlaubt" regel für 5061.
Warum im Log für WLAN also erst mal alles blockiert wird und dann auf der WAN Seite alles erlaubt wird,
was ursprünglich im WLAN freigeschaltet wurde.... Mystery.

Zu mindestens wäre das jetzt geklärt :)
Es ist also "normal" ::)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 12:55:27 pm
Quote
Nein. Es müsste genau andersherum sein. Default mäßig wird von der OPNsense immer erst einmal alles blockiert.
Schreibst du keine Pass Regeln wird ALLES blockiert, egal ob inbound oder outbound. Das steht innerhalb der Rules auch ganz unten in der kleinen Schrift:
"Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed). This means that if you use block rules, you'll have to pay attention to the rule order. Everything that isn't explicitly passed is blocked by default."
Das ist die DENY ANY ANY Regel die immer automatisch am Ende ausgeführt wird, falls keine andere Regel greift.

Ok, aber dann bin ich nun doch wieder verwirrter als vorher., bezüglich deiner Aussage mit den Log Meldungen. ^^

Du hattest zu meinen ganzen Fragen der Vortage ja auf den vorherigen Seiten was geschrieben, betreffend der Regeln für die Interfaces. Ich hatte da gefragt, ob ich die Regeln für das WAN Interface schreiben muss oder nur für das LAN und WLAN interface. Erinnerst Du Dich?

Da hattest Du u.A. geschrieben:

Quote
Quote

    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". :)

Quote
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).

Quote
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.

Quote

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. :)


Jetzt hattest Du vorhin aber geschrieben:

Quote
Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite (Alles müsste daher geblockt werden, auch der Zugriff auf den DNS oder NTP Server). Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

Vielleicht tue ich mich einfach nur sehr schwer mit den Begrifflichkeiten gerade. ;) Was genau meinst Du mit den Regeln "auf der WAN Seite" ?

Ich versuche das noch mal auf das für mich einfachste Level runter zu brechen (Sorry wenn ich das nochmal fragen muss, aber ich möchte sicher sein, da nichts falsch zu verstehen um es in Zukunft auch richtig anwenden zu können):

Das Netzwerk sieht bei mir doch so aus...

                           
                                         ( Internet )
                                                 |
                                    WAN Interface
                                                 |
                       ------------- Firewall -------------
                       |                                                 |
          LAN Interface                         WLAN Interface


Die Firewall trennt alle Interfaces.

Die Kommunikation zwischen LAN und WLAN lasse ich komplett außen vor.

Also, im Initialzustand (nach der Installation von OPNsene) ist die Firewall an und blockt ALLE eingehenden UND ausgehenden Verbindungen, richtig?

Wenn ich jetzt vom LAN und WLAN ins Internet kommunizieren möchte, dann schreibe ich doch meine Regeln jeweils nur am LAN und WLAN Interface und nicht am WAN Interface.  Vielleicht ist "am" in diesem Fall auch ein blöder Begriff, ich schreibe die Regeln doch eher "für" das jeweilige Interface. Es gibt ja auch nur eine Firewall mitsamt aller Regeln und nicht mehrere (die GUI in der Ansicht der Regeln für die Interfaces trennt das ja pro Interface auf in diese Tabs, das ist vielleicht ein wenig verwirrend).

 Kannst Du mir hier bitte noch Mal auf die Sprünge helfen, damit ich Dich nicht missverstehe? Wie meinst Du die Aussage

Quote
Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite

Was ist bei Dir die WAN Seite?

Quote
Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

Das ist das was ich meinte und bisher so verstanden hatte, da ja dieser kleine Hinweis Text in der Regelansicht des WAN Interface lautet:

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

Das heißt doch, Outbound geht am WAN immer, wenn nicht explizit geblockt?! Und explizit geblockt ist es doch dann, wenn im LAN und WLAN Interface jeweils ein DENY ALL ALL zum Schluss steht?

Ansonsten, sollte ich jetzt mit allem falsch liegen, würde mir deine Aussage folgendes suggerieren:


                                         ( Internet )
                                                 |
                                         Firewall
                                                 |
                                    WAN Interface
                                                 |
                       ------------- Firewall -------------
                       |                                                 |
          LAN Interface                         WLAN Interface


Also zwischen WAN und Internet steht nochmal die Firewall. Das hatte ich so nicht verstanden, weil ich dann doch die von mir angesprochenen zwei Regeln bräucht, je eine für LAN/WLAN und dann nochmal die gleiche Regel für WAN?! Ich verstehe es so, dass das WAN Interface die Verbindungen entgegen nimmt und dann kommt ja erst die Firewall und schaut sich die Datenpakete, auf Basis der Rulesets, an.


Quote
Nun hab ich mir mal den Spaß gemacht und Port 5061 freigeschalten.
Siehe da, plötzlich gab es WAN outbound Traffic als "erlaubt" regel für 5061.
Warum im Log für WLAN also erst mal alles blockiert wird und dann auf der WAN Seite alles erlaubt wird,
was ursprünglich im WLAN freigeschaltet wurde.... Mystery.

Das heißt, rein auf das Log bezogen, was im LAN/WLAN Interface erlaubt wird, wird nicht im LAN/WLAN Log sichtbar, sondern im WAN Log?  ???

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 02:18:34 pm
oha... ich hätte meine Tests die ich gemacht hatte um das Firewall-Log zu verstehen nicht unbedingt aufschreiben sollen.
Das hat ja jetzt mehr Verwirrung erzeugt als gedacht.
Okay... ich versuche nochmal klar zu machen was ich meinte.
Hoffentlich krieg ich das gut erklärt ohne alles zu verkomplizieren. (so schwer ist es "eigentlich" nich).

Quote
Quote
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". :)

Das war von mir falsch an dieser Stelle. Da hatte ich nur halbherzig gelesen.
Diese DENY ANY ANY Regel existiert und ist auch von OPNsense hart eingetragen, muss demnach von dir nicht extra hinzugefügt werden. Sie ist immer die allerletzte Rule.
Der Text auf der unteren Seite der Rules Seite verdeutlicht das. In diesem heißt es:
Everything that isn't explicitly passed is blocked by default.
Der Text den du meinst, also folgenden: No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule. den haben die OPNsense Entwickler noch zusätzlich dazu geschrieben um es dem User offensichtlicher zu machen, dass ohne Firewall Regeln, möglicherweise bestimmte "erhoffte" Kommunikation noch nicht funktioniert.
Wichtig ist aber: Die Default Regel am Ende des Regelwerks ist automatisch immer DENY ANY ANY

Quote
Jetzt hattest Du vorhin aber geschrieben:
Quote
Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite (Alles müsste daher geblockt werden, auch der Zugriff auf den DNS oder NTP Server). Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.

Das war mein Problem, als ich versuchte die "Logik" hinter dem Firewall Log zu verstehen.
Ich habe jetzt zwar irgendwie verstanden wie anscheinend die Regeln im Log angezeigt werden, aber in Verbindung mit den tatsächlich angelegten Rules verwirrt einen das nur.

--> Ich hoffe ich konnte bis hier die Verwirrung erst einmal irgendwie etwas lösen. Sorry dafür! :)

Quote
Die Firewall trennt alle Interfaces.
Die Kommunikation zwischen LAN und WLAN lasse ich komplett außen vor.
Also, im Initialzustand (nach der Installation von OPNsene) ist die Firewall an und blockt ALLE eingehenden UND ausgehenden Verbindungen, richtig?

Ich habe zwar schon länger meine OPNsense nicht von null neu aufbauen müssen, aber ja, sofern keine "erlauben" Regeln von dir in den unterschiedlichen 3 Interface Tabs angelegt wurden, blockt jedes Interface erst einmal alles.
Es existieren jedoch zwei Ausnahmen:
1.) Ausnahme ist hierbei die Anti Lockout Rule auf der LAN Seite.
Diese wird standardmäßig angelegt, damit man überhaupt auf die Weboberfläche kommt.
2.) Traffic der "von der Firewall" kommt wird auch nicht geblockt egal was für Regeln man auch immer selber erstellt. Mit "von der Firewall" ist dabei der Traffic gemeint der von der Firewall selbst kommt.
Das ist schwer zu erklären, das muss man selber mal gesehen haben.
Die Verbindung zu 37.48.77.141 (mail.opnsense.org) kann man zum Beispiel nicht blockieren, egal was für Regeln man formuliert. Der Traffic entsteht, wenn man nach Updates checked. (Kann man im Firewall Log nachlesen)

Quote
Quote
Weiterhin habe ich keine Pass Regel formuliert auf der WAN Seite
Was ist bei Dir die WAN Seite?
Alle Regeln die beim Interface Tab "WAN" formuliert werden.
Tut mir leid, dass hatte ich wohl unsauber formuliert. :(

Quote
Quote
Outbound Traffic wird aber dennoch immer erlaubt aus dem WAN Interface.
Das ist das was ich meinte und bisher so verstanden hatte.

Die Sache, die einem vielleicht nicht ganz klar sein könnte ist, das theoretisch auch Traffic, am WAN Interface angeschlossen, an der Firewall starten könnte, ähnlich wie bei WLAN und LAN.
In deinem Fall ist die WAN Seite am Modem und das WAN Netz ist sehr klein. Oft hängt am WAN Interface vielleicht auch nur noch ein Router und das wars. Deswegen ist es üblich auf dem WAN Tab in Firewall > Rules > WAN keine Regeln zu formulieren. Man möchte also nicht, dass Das Interface eine Kommunikation startet oder ein Gerät innerhalb des angeschlossenen WAN Netzes eine Kommunikation startet. Ebenfalls möchte man nicht, dass ein potentieller Angreifer vom Internet auf deine WAN Schnittstelle zugreift. Um das alles zu unterbinden, schreibt man gar nichts in das WAN tab rein, denn dort wird nie eine Kommunikation gestartet. Pakete werden nur weitergereicht, denn die Source IP ist ja zum Beispiel die IP von deinem Laptop im LAN Netz gewesen.

--> Ich hoffe ich hab dich bis hier nich schon wieder verwirrt.
Wenn ich mir meinen Text durchlese hab ich bissel Angst dass ichs wieder verkompliziert hab. :D

Ein Paket startet im LAN Netz und die Firewall entscheidet, anhand der im LAN formulierten Regeln, was damit geschehen soll. Wenn es erlaubt wurde, wird das Paket durch das WAN Interface zum Modem weitergeschubst/durchgereicht. Deswegen ist es egal welche Regeln bei  Firewall > Rules > WAN formuliert werden, solange die Pakete im LAN starten.

Ich kann nur hoffen es ist jetzt nicht schlimm geworden mit dem Verständnis. :D

EDIT:
Quote
Das heißt, rein auf das Log bezogen, was im LAN/WLAN Interface erlaubt wird, wird nicht im LAN/WLAN Log sichtbar, sondern im WAN Log????

Ich schau mal ob ich was ausm Log heraus nehmen kann. Dann siehst du was ich meine.
Wie gesagt ich find es merkwürdig.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 02:40:41 pm
Auszug aus meinem Log.
1.) Ich bin mit meinem Handy mit dem WLAN verbunden.
2.) ich öffne reddit von meinem Handy
3.) Ausgabe siehe Log

WLAN Handy IP = Die lokale IP die mir der DHCP Server auf dem WLAN Interface der OPNsense Firewall vergeben hatte.
WAN Int IP = die statisch vergebene IP, die ich dem WAN Interface der Firewall vergab.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 03:23:28 pm
Quote
Diese DENY ANY ANY Regel existiert und ist auch von OPNsense hart eingetragen, muss demnach von dir nicht extra hinzugefügt werden. Sie ist immer die allerletzte Rule.
Der Text auf der unteren Seite der Rules Seite verdeutlicht das. In diesem heißt es:
Everything that isn't explicitly passed is blocked by default.
Der Text den du meinst, also folgenden: No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule. den haben die OPNsense Entwickler noch zusätzlich dazu geschrieben um es dem User offensichtlicher zu machen, dass ohne Firewall Regeln, möglicherweise bestimmte "erhoffte" Kommunikation noch nicht funktioniert.
Wichtig ist aber: Die Default Regel am Ende des Regelwerks ist automatisch immer DENY ANY ANY

Aaahhh... :)

DENY ANY ANY bedeutet dann auf jedem interface:

Blockiere jeden Datenverkehr von jedem Ziel zu jeder Quelle auf jedem Port, also inbound und outbound, nichts geht rein oder raus.

Quote
--> Ich hoffe ich konnte bis hier die Verwirrung erst einmal irgendwie etwas lösen. Sorry dafür! :)

Jap. Wenn ich richtig verstanden habe, dann ist jedes Interface komplett dicht im Werkszustand. Wobei ich mich dann in dem Fall frage, warum diese beiden Standard Regeln für das WAN Interface explizit geschrieben sind, die man auf dem Screenshot sieht, den ich mal gepostet habe zuletzt (Beitrag 35, Seite 3). Also die beiden hier:

 
Ich denke, bei Punkt 2 geht es ja um fehlerhafte/falche Datenpakete.

Aber das fällt doch auch unter die DENY ANY ANY Regel, die hardcoded in der Firewall steht. Wofür sind die beiden Regeln explizit eingetragen und warum nur im WAN Interface?

Quote
2.) Traffic der "von der Firewall" kommt wird auch nicht geblockt egal was für Regeln man auch immer selber erstellt. Mit "von der Firewall" ist dabei der Traffic gemeint der von der Firewall selbst kommt.
Das ist schwer zu erklären, das muss man selber mal gesehen haben.
Die Verbindung zu 37.48.77.141 (mail.opnsense.org) kann man zum Beispiel nicht blockieren, egal was für Regeln man formuliert. Der Traffic entsteht, wenn man nach Updates checked. (Kann man im Firewall Log nachlesen)

Verstehe ich. Da sind dann wahrscheinlich auch irgendwelche Netzwerke/Aliase/etc. hard codiert eingetragen, die immer funktionieren.

Quote
Alle Regeln die beim Interface Tab "WAN" formuliert werden.
Tut mir leid, dass hatte ich wohl unsauber formuliert. :(

Alles gut, habs ja jetzt verstanden. ;)

Wir haben von der gleichen Sache gesprochen, ich bin nur immer sehr penible bei sowas, weil ich aus eigener Erfahrung weiß, wie schnell ein Wortdreher nachher das Verständnis einer Sache komplett ändern kann. Da musste ich hinterher haken, Sorry. :D

Quote
Die Sache, die einem vielleicht nicht ganz klar sein könnte ist, das theoretisch auch Traffic, am WAN Interface angeschlossen, an der Firewall starten könnte, ähnlich wie bei WLAN und LAN.
In deinem Fall ist die WAN Seite am Modem und das WAN Netz ist sehr klein. Oft hängt am WAN Interface vielleicht auch nur noch ein Router und das wars. Deswegen ist es üblich auf dem WAN Tab in Firewall > Rules > WAN keine Regeln zu formulieren. Man möchte also nicht, dass Das Interface eine Kommunikation startet oder ein Gerät innerhalb des angeschlossenen WAN Netzes eine Kommunikation startet. Ebenfalls möchte man nicht, dass ein potentieller Angreifer vom Internet auf deine WAN Schnittstelle zugreift. Um das alles zu unterbinden, schreibt man gar nichts in das WAN tab rein, denn dort wird nie eine Kommunikation gestartet. Pakete werden nur weitergereicht, denn die Source IP ist ja zum Beispiel die IP von deinem Laptop im LAN Netz gewesen.

--> Ich hoffe ich hab dich bis hier nich schon wieder verwirrt.
Wenn ich mir meinen Text durchlese hab ich bissel Angst dass ichs wieder verkompliziert hab. :D

Ein Paket startet im LAN Netz und die Firewall entscheidet, anhand der im LAN formulierten Regeln, was damit geschehen soll. Wenn es erlaubt wurde, wird das Paket durch das WAN Interface zum Modem weitergeschubst/durchgereicht. Deswegen ist es egal welche Regeln bei  Firewall > Rules > WAN formuliert werden, solange die Pakete im LAN starten.

Danke, das ist eine gute Erklärung. Ich hatte es aber auch ausser Acht gelassen, dass am WAN natürlich auch mehr passieren kann, als das "durchreichen" der Datenpakete der anderen Interfaces. Aber das ist ja in meinem Fall dann trotzdem gut gewesen, weil ich somit diesen Teil ausklammern konnte (indem ich am WAN Interface nichts schreiben musste).

Das bedeutet, in deinem WAN Tab in der GUI steht auch keine Regel, ja?

Quote
Ich kann nur hoffen es ist jetzt nicht schlimm geworden mit dem Verständnis. :D

Ne, ist deutlich besser geworden. Danke. :D

Nur eins fuchst mich gerade noch etwas, und zwar meine schematische Darstellung. Die passt ja dann doch nicht.

                                         ( Internet )
                                                 |
                                    WAN Interface
                                                 |
                       ------------- Firewall -------------
                       |                                                 |
          LAN Interface                         WLAN Interface

Dann muss ja zwischen WAN und Internet (oder Kabelmodem, ich habs einfach nur Internet genannt)
 ja doch nochmal die Firewall sitzen. Also:

                                         ( Internet )
                                                 |
                                          Firewall
                                                 |
                                    WAN Interface
                                                 |
                       ------------- Firewall -------------
                       |                                                 |
          LAN Interface                         WLAN Interface


Wenn nicht, wäre mir nicht ganz klar, wie sonst Regeln für das WAN Interface gelten können? ^^



Zu deinem Log:

Kurz gesagt, im Log landet das, was von LAN/WLAN Interface am WAN Interface ankommt und darum steht dort die WAN IP statt der eigentlichen Client IP aus dem Netz (weil das WAN Interface das dann weiterleitet)? Ich finde es immer noch Konfus... Dann dürfte doch eigentlich nie als Source ein anderes Interface außer dem WAN da auftauchen, weil doch im Endeffekt alles über das WAN läuft.  :o

Ich werde da auch mal bei mir testen, das Log komplett leeren und dann eine einzige Verbindung aufbauen und schauen, was geloggt wird.

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 03:52:11 pm
Quote
DENY ANY ANY bedeutet dann auf jedem interface:
Blockiere jeden Datenverkehr von jedem Ziel zu jeder Quelle auf jedem Port, also inbound und outbound, nichts geht rein oder raus.

Genau so siehts aus :)
blockiere -> IPv4+IPv6: alle Transportprotokolle source: alles Port: alles destination: alles Port: alles

Quote
Jap. Wenn ich richtig verstanden habe, dann ist jedes Interface komplett dicht im Werkszustand. Wobei ich mich dann in dem Fall frage, warum diese beiden Standard Regeln für das WAN Interface explizit geschrieben sind, die man auf dem Screenshot sieht, den ich mal gepostet habe zuletzt (Beitrag 35, Seite 3).

Die kann man für jedes Interface festlegen. Block Bogon Networks hab ich zum Beispiel auf jedem Interface aktiviert.
Hier zum einstellen: Interfaces > [WAN] Dort kann man dann Häkchen rein oder raus machen.

Ich hab sie drinne gelassen, falls ich dann doch mal etwas aus meinem internen Netz vom Internet her erreichen möchte. Bevor man da also auf dem WAN Interface (Inbound) einen Port öffnet, damit man auch aus Spanien auf den eigenen internen Webserver zugreifen kann (nur mal als Beispiel), will ich vor der "Erlauben" Regel alles blocken was nicht sicher ist.

In deinem Fall könntest du aber selbst diese beiden Regeln rausnehmen, da du auf der WAN Seite keine Erlauben Regel geschrieben hast. Das ist von dir abhängig. :)

Zum Thema Bogon Netzwerke: "Bogon ist ein Jargonausdruck für ein IP-Datenpaket im öffentlichen Internet, das vorgibt, von einer gültigen Adresse des Internetprotokolls zu stammen, tatsächlich aber noch nicht durch die Internet Assigned Numbers Authority (IANA) oder eine beauftragte Regional Internet Registry (RIR) zugewiesen wurde. Die Gesamtheit nicht zugewiesener Adressen wird bogon space genannt."
Siehe: https://de.wikipedia.org/wiki/Bogon

Quote
Aber das fällt doch auch unter die DENY ANY ANY Regel, die hardcoded in der Firewall steht. Wofür sind die beiden Regeln explizit eingetragen und warum nur im WAN Interface?

Du kannst wenn du Lust hast auch alle privaten Adressbereiche im LAN blockieren. Ob das sinnvoll ist, ist die andere Sache ;-D
Im Grunde sind diese beiden Regeln aber NICHT NUR auf das WAN bezogen.

Quote
Das bedeutet, in deinem WAN Tab in der GUI steht auch keine Regel, ja?

Was in meinem WAN steht häng ich dir mal in den Anhang. Wie gesagt, theoretisch kann die leer sein.
Ich will bloß im Falle nichts vergessen haben oder nachtragen müssen, wenn ich dann mal nen Webserver aufbauen möchte und dann unter Firewall > Rules > WAN auf Port 80 freischalten muss.
Hast du nichts davon vor können deine WAN Interface Rules leer sein.

Quote
Dann muss ja zwischen WAN und Internet (oder Kabelmodem, ich habs einfach nur Internet genannt)
 ja doch nochmal die Firewall sitzen.

Wenn du die Firewall in deinem Gedankengang nicht als Gerät/Server siehst sondern als eine Art Tor, dann ja kann man sich das so gut vorstellen mit der "zweiten Firewall" zwischen Modem und tatsächlicher Firewall.

Quote
Kurz gesagt, im Log landet das, was von LAN/WLAN Interface am WAN Interface ankommt und darum steht dort die WAN IP statt der eigentlichen Client IP aus dem Netz (weil das WAN Interface das dann weiterleitet)? Ich finde es immer noch Konfus... Dann dürfte doch eigentlich nie als Source ein anderes Interface außer dem WAN da auftauchen, weil doch im Endeffekt alles über das WAN läuft.  :o

so habe ich das auch verstanden. Die Sache ist halt ja auch, dass da nie "WAN" steht, sondern stets "WAN(out)". Es ist also (laut meiner Auffassung) nie das WAN Interface sondern nur der Traffic gemeint, der aus dem WAN Interface durchgereicht wurde.
Vielleicht kann man sich das so vorstellen? Leider keine Ahnung. :-/
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 05:20:39 pm
Quote
Was in meinem WAN steht häng ich dir mal in den Anhang. Wie gesagt, theoretisch kann die leer sein.
Ich will bloß im Falle nichts vergessen haben oder nachtragen müssen, wenn ich dann mal nen Webserver aufbauen möchte und dann unter Firewall > Rules > WAN auf Port 80 freischalten muss.
Hast du nichts davon vor können deine WAN Interface Rules leer sein.

Ok, Du hast also die beiden Regeln drin, die ich auch habe und die zwei Regeln für Netzwerke, die Spammern und Hijackern gehören, richtig? Verstehe ich das korrekt, dass Du einfach diese IP Liste gespeichert hast und als Alias darauf verweist und wann immer eine Verbindung outbound zu einer IP aus dieser Liste versucht wird, wird diese "gedropt"?

Quote
Wenn du die Firewall in deinem Gedankengang nicht als Gerät/Server siehst sondern als eine Art Tor, dann ja kann man sich das so gut vorstellen mit der "zweiten Firewall" zwischen Modem und tatsächlicher Firewall.

Genau so war das gemeint. Keine physische Firewall, sondern abstrakt dargestellt, dass die Firewall das WAN Interface ebenfalls schützt.

Quote

so habe ich das auch verstanden. Die Sache ist halt ja auch, dass da nie "WAN" steht, sondern stets "WAN(out)". Es ist also (laut meiner Auffassung) nie das WAN Interface sondern nur der Traffic gemeint, der aus dem WAN Interface durchgereicht wurde.
Vielleicht kann man sich das so vorstellen? Leider keine Ahnung. :-/

Jap. Ich muss mir das auch mal nachher bei mir anschauen, vielleicht steckt da ja noch ne tiefere Logik hinter, oder das ganze ist evtl. konfigurierbar?


Hab (leider) noch weitere Fragen  ;D

Und zwar zu dem transparenten Proxy: Dieser dient ja dem durchreichen von Datenpaketen und der gleichzeitigen Filterung auf "gefährliche" Inhalte. Habe ich es richtig verstanden, dass ich dieses Feature garnicht nutzen kann, da meine Appliance lediglich mit einer 8GB SD Karte läuft (und es Probleme geben wird mit den Disk writes bei einer SD Karte)?

Oder hab ich das falsch verstanden und das gilt nur für den Caching Proxy?

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 17, 2017, 07:28:30 pm
Hi Chris,
grundsätzlich sollte man bei einer SD-Installation eines der Nano-Images verwenden (VGA/seriell).
Die Nano-Images sind speziell für CF-, SD-Karten und minimieren die Schreibzugriffe auf die Karten. Man kann natürlich auch eine Vollinstallation auf SD-Karte machen. Wie lange die SD-Karte dann durchhält???

Den Webbroxy kannst Du unabhängig vom verwendeten Installationsimage der OPNSense benutzen. Das Caching des Proxy kannst Du in der Proxykonfiguration aktivieren/deaktivieren. Beim Nano-Image läuft das Caching dann halt im RAM (RAM-Disk). Siehe dazu hier: https://forum.opnsense.org/index.php?topic=4227.0
Standardmäßig ist das Caching beim Proxy deaktiviert (beim Nano-Image).

Gruß
Dirk



Title: Re: Best practices/Standards für Heimnetzwerk
Post by: fabian on January 17, 2017, 07:58:38 pm
Und zwar zu dem transparenten Proxy: Dieser dient ja dem durchreichen von Datenpaketen und der gleichzeitigen Filterung auf "gefährliche" Inhalte. Habe ich es richtig verstanden, dass ich dieses Feature garnicht nutzen kann, da meine Appliance lediglich mit einer 8GB SD Karte läuft (und es Probleme geben wird mit den Disk writes bei einer SD Karte)?

Oder hab ich das falsch verstanden und das gilt nur für den Caching Proxy?

Für die Analyse muss nichts niedergeschrieben werden, das kann im RAM passieren - wenn genug da ist, git das auch für dien Cache. Ich habe eine Vollinstallation auf einer SD-Karte und diese funktioniert auch sehr gut - man sollte nur nicht zu viele Dienste aktivieren, die häufig auf die Karte schreiben - für solche Dinge muss man dann auf eine RAM-Disk ausweichen.

Wenn die Analyse (zusätzlich) auf einem anderen Host passieren soll, kann dafür ICAP verwendet werden (Virenscanner etc.).
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 08:18:12 pm
Hi Dirk,

Quote
grundsätzlich sollte man bei einer SD-Installation eines der Nano-Images verwenden (VGA/seriell).
Die Nano-Images sind speziell für CF-, SD-Karten und minimieren die Schreibzugriffe auf die Karten. Man kann natürlich auch eine Vollinstallation auf SD-Karte machen. Wie lange die SD-Karte dann durchhält???

Jap, ich habe ein Nano Image installiert.

Quote
Den Webbroxy kannst Du unabhängig vom verwendeten Installationsimage der OPNSense benutzen. Das Caching des Proxy kannst Du in der Proxykonfiguration aktivieren/deaktivieren. Beim Nano-Image läuft das Caching dann halt im RAM (RAM-Disk). Siehe dazu hier: https://forum.opnsense.org/index.php?topic=4227.0
Standardmäßig ist das Caching beim Proxy deaktiviert (beim Nano-Image).

Ok, Danke. Du hast dem Thread nach auch eine Karten Installation laufen? Bist damit insgesamt zufrieden? Ooder hast Du irgendwelche "Bottlenecks", in Punkto Performance, gefunden?

Hi fabian,

Quote
Für die Analyse muss nichts niedergeschrieben werden, das kann im RAM passieren - wenn genug da ist, git das auch für dien Cache. Ich habe eine Vollinstallation auf einer SD-Karte und diese funktioniert auch sehr gut - man sollte nur nicht zu viele Dienste aktivieren, die häufig auf die Karte schreiben - für solche Dinge muss man dann auf eine RAM-Disk ausweichen.

Danke.

Also mein System hat 2GB RAM, davon sind knapp 10% genutzt.  Reicht der Rest für ein gutes Caching?

Wann werden denn eigentlich /tmp und /var genutzt bei der Installation? Die haben bei mir jeweils 1,5GB und sind fast komplett ungenutzt.


Mal was ganz anderes:

Fällt nur mir das auf, dass heute Seitenaufrufe teilweise sehr lange dauern? ich dachte, es hätte was mit dem Netzwerk in der Arbeit zu tun, aber auch zu Hause lahmt alles irgendwie...

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 09:47:30 pm
@ne0h
Weil du vorhin gefragt hattest hier nochmal zur Vollständigkeit meine Antwort.
Diese hijacked Webseiten, werden als .txt Liste voller IPs in die Firewall eingehämmert.
Da gibt es zum einen die DROP Liste von Spamhaus, die "Spammer/Spambots" jedoch ausschließt
und wirklich nur übernommene, Bot-Rechner und gehackte Server usw. blockt.
Die EDROP Liste ist sozusagen noch ein Zusatz für die zurzeit bekannten Spambots.
Diese Listen sollte man täglich updaten.

Alles weitere zur Einrichtung und Tipps dazu findest du hier:
https://docs.opnsense.org/manual/how-tos/edrop.html

In deinem Fall musst du diese Listen also outbound (Destination: diese Listen als Alias)
in deine LAN und WLAN Regeln mit einfließen.
Ggf. noch auf dem WAN Interface inbound (Source: Alias), so wie ich das gemacht hatte.
(Ist aber wie gesagt nur notwendig, wenn du mal vorhast einen Server aus deinem internen Netz öffentlich zugänglich zu machen.)

Zum SD Karten Thema kann ich leider nix beisteuern. :P
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 17, 2017, 10:32:06 pm
@Oxy,

Danke für die Erklärung.

Ich habe jetzt endlich mein Basis Ruleset angelegt, im Prinzip also alles, was ihr empfohlen habt. Ich habe auch mal getestet und bisher scheinen alle Basisdienste zu laufen, alle Websites, Messenger, etc. funktionieren.

Hab die Regeln als Anhang hier dran.

Dazu würde ich gerne wissen:

Was ist denn der Unterschied zwischen den Aliasen "WLAN net" und "WLAN address"?  Ich habe ja direkt mit dem Subnetz gearbeitet, aber bei monstermania hatte ich gesehen, dass da z.B. für das interne DNS von Source Bridge net nach Source Bridge address die Regeln erstellt sind.

Außerdem habe ich jetzt erst mal immer Destination ANY für die Basisdienste eingetragen. Aber würde z.B. bei HTTP/HTTPS als Destination nicht auch WAN (bzw. genauer WAN net/WAN address) sicherer sein? Denn bedeutet das im Moment nicht auch, dass ein WLAN Client über Port 80 oder 443 auch auf mein LAN zugreifen kann (also auf z.B. meine NAS auf Port 443) ?

Ich denke da an sowas:

HTTP/HTTPS -> Source: 192.168.0.1/24 -> Destination: 192.168.192.65/32

192.168.192.65/32 ist ja die statische WAN Interface IP.

Oder wird das nicht funktionieren?

Gibt es auch eine genauere Erklärung für die ganzen Destination Aliase? Z.B. was "This Firewall" genau sein soll?

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 17, 2017, 10:59:48 pm
Ein paar Sachen kann ich vielleicht noch erklären. Den Rest macht dann sicher monstermania morgen. :)
"WLAN Net" ist das WLAN Subnetz was am WLAN Interface der Firewall hängt.
Also (wahrscheinlich) ist WLAN Net in deinem Fall einfach nur dein WLAN Netz 192.168.1.0/24.
WLAN address hingegen ist die IP des WLAN Interfaces an deiner Firewall.
An dieser Stelle hast du sozusagen "Glück",
dass das WLAN Interface logischerweise Teil deines WLAN Subnetzes ist,
weshalb NTP und DNS funktionieren.
Besser wäre es jedoch die Destination auf die WLAN Interface IP zu beschränken...
also: <hier IP eingeben>/32 oder WLAN address.

Ich hatte ja schon mal erklärt, dass die Clients im Netz alle Informationen über NTP, DNS und Gateway von dem DHCP Server kriegen,
welcher auf dem WLAN Interface läuft.
Demnach ist es wie gesagt völlig ausreichend wenn die DNS und NTP Verbindungen "nur" bis zum WLAN Interface reichen für die Clients, denn nur dahin sollen die Clients kommunizieren dürfen um mit dem DNS oder NTP Dienst sprechen zu können.

Wegen deiner WAN Idee:
Die Server die du ansprechen möchtest stehen ja nicht innerhalb deines WAN Subnetzes, dass ist ja sozusagen noch Teil deines privaten Netzes. Das ist anders nicht umsetzbar. Deshalb muss man bevor man diese PERMIT HTTP ANY Rule am Ende setzt vorher überlegen inwieweit man diese einschränken kann, wie z.b. durch diese Spamhaus Listen usw.

Quote
Denn bedeutet das im Moment nicht auch, dass ein WLAN Client über Port 80 oder 443 auch auf mein LAN zugreifen kann (also auf z.B. meine NAS auf Port 443) ?
Genau das bedeutet es. Deshalb blockt man sämtliche Verbindung vom WLAN Netz ins LAN Netz und andersherum und überlegt sich dann, welche Geräte sollen denn miteinander kommunizieren dürfen?
Dann fängst du an z.B. eine Regel zu schreiben die einem bestimmten Gerät aus dem WLAN Netz über 443 die Kommunikation mit dem NAS im LAN Netz erlaubt.
So wie du jetzt die Regeln formuliert hast, hättest du auch bei der Bridge Idee bleiben können. :D
 
Diese Regeln die du da geschrieben hast, kannst du "so" in der Art nur so frei formulieren, weil monstermania keine Trennung zwischen den beiden Interface Subnetzen gemacht hatte.
Bei ihm bedeutet die HTTP Freischaltung nach ANY halt tatsächlich die Freischaltung ins Internet.

Was bedeutet das also:
Du musst noch vor dieser Rule aber sagen:
DENY Source: WLAN Net Destination: LAN Net Prot: ANY
Auf der LAN Seite natürlich andersherum.
Dadurch hast du sichergestellt, dass diese DENY Regel vor der HTTP Freischaltung greift.
Fängst du vor dieser DENY Regel jetzt an spezielle Kommunikationen zwischen deinen beiden Subnetzen zuzulassen,
greifen diese immer zu erst, noch bevor am Ende dann HTTP nach ANY (also auch ins Internet) erlaubt wird.
Also:
Die Reihenfolge ist super wichtig damit du nicht ausersehen zu viel erlaubst.
1) spezielle Regeln -> z.b. Gerät A im WLAN Netz darf mit dem NAS im Lan Netz reden auf Port 443
2) Deny Regel die sämtlichen anderen Traffic vom WLAN Netz ins LAN Netz blockiert
3) andere Block Regeln die sinnvoll sein könnten
4) Dann erst die sehr "offen" formulierte "erlaube HTTP Traffic nach ANY" Regel

Quote
HTTP/HTTPS -> Source: 192.168.0.1/24 -> Destination: 192.168.192.65/32
192.168.192.65/32 ist ja die statische WAN Interface IP.
Oder wird das nicht funktionieren?

Mir hilft es immer wenn ich die regeln laut ausspreche und mir überlege, was ich damit denn überhaupt aussagen will. Was diese Regel nun sagt ist, dass innerhalb des 192.168.0.1/24 Subnetzes über HTTP und HTTPS auf dein WAN Interface zugegriffen werden kann und somit die GUI Einlogg Oberfläche einsehbar ist.
Nicht mehr und nicht weniger. :)

"This Firewall" würd ich auch gern mal wissen, was da dahinter steckt. :-/
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: fabian on January 18, 2017, 06:36:37 am
Danke.

Also mein System hat 2GB RAM, davon sind knapp 10% genutzt.  Reicht der Rest für ein gutes Caching?

Wann werden denn eigentlich /tmp und /var genutzt bei der Installation? Die haben bei mir jeweils 1,5GB und sind fast komplett ungenutzt.

Ich habe bei mir den Cache im RAM - 1/2 GB reicht da für den Betrieb daheim aus und ich habe 4GB. Das Meiste ist auch bei mir frei. Du solltest nur vorsichtig sein, wenn du auch die IDS nutzen willst. Die braucht einiges an RAM.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 18, 2017, 09:30:22 am
Guten morgen,

Quote
"WLAN Net" ist das WLAN Subnetz was am WLAN Interface der Firewall hängt.
Also (wahrscheinlich) ist WLAN Net in deinem Fall einfach nur dein WLAN Netz 192.168.1.0/24.
WLAN address hingegen ist die IP des WLAN Interfaces an deiner Firewall.
An dieser Stelle hast du sozusagen "Glück",
dass das WLAN Interface logischerweise Teil deines WLAN Subnetzes ist,
weshalb NTP und DNS funktionieren.
Besser wäre es jedoch die Destination auf die WLAN Interface IP zu beschränken...
also: <hier IP eingeben>/32 oder WLAN address.

Sowas in der Art dachte ich mir auch schon. Werde das ändern.

Quote
Genau das bedeutet es. Deshalb blockt man sämtliche Verbindung vom WLAN Netz ins LAN Netz und andersherum und überlegt sich dann, welche Geräte sollen denn miteinander kommunizieren dürfen?
Dann fängst du an z.B. eine Regel zu schreiben die einem bestimmten Gerät aus dem WLAN Netz über 443 die Kommunikation mit dem NAS im LAN Netz erlaubt.
So wie du jetzt die Regeln formuliert hast, hättest du auch bei der Bridge Idee bleiben können. :D
 
Diese Regeln die du da geschrieben hast, kannst du "so" in der Art nur so frei formulieren, weil monstermania keine Trennung zwischen den beiden Interface Subnetzen gemacht hatte.
Bei ihm bedeutet die HTTP Freischaltung nach ANY halt tatsächlich die Freischaltung ins Internet.

Was bedeutet das also:
Du musst noch vor dieser Rule aber sagen:
DENY Source: WLAN Net Destination: LAN Net Prot: ANY
Auf der LAN Seite natürlich andersherum.
Dadurch hast du sichergestellt, dass diese DENY Regel vor der HTTP Freischaltung greift.
Fängst du vor dieser DENY Regel jetzt an spezielle Kommunikationen zwischen deinen beiden Subnetzen zuzulassen,
greifen diese immer zu erst, noch bevor am Ende dann HTTP nach ANY (also auch ins Internet) erlaubt wird.
Also:
Die Reihenfolge ist super wichtig damit du nicht ausersehen zu viel erlaubst.
1) spezielle Regeln -> z.b. Gerät A im WLAN Netz darf mit dem NAS im Lan Netz reden auf Port 443
2) Deny Regel die sämtlichen anderen Traffic vom WLAN Netz ins LAN Netz blockiert
3) andere Block Regeln die sinnvoll sein könnten
4) Dann erst die sehr "offen" formulierte "erlaube HTTP Traffic nach ANY" Regel

Mh... Ja, macht Sinn.

Ich formuliere das mal eben in meinen Worten um zu sehen, ob ich das verstanden habe:

Wie ich ja inzwischen weiß ^^, steht am Ende immer die DENY ANY ANY Regel. Also ist damit ja die Kommunikation zwischen den Subnetzen, sofern noch keine andere Regel das vorher aufhebt, blockiert. Jetzt habe ich mit meinem HTTP/HTTPS -> any diese immer greifende DENY ANY ANY Blockierung zwischen den Subnetzen auf Port 80 und 443 aufgehoben, weil ich damit ja sage, jedes Gerät kann aus meinem WLAN Subnetz (Source: WLAN net) in jedes andere Netz (Destination: any) über Port 80/443.

Da ich aber als erstes möchte, dass die WLAN Clients nur ins Internet kommen und nicht in mein LAN Subnetz, muss ich vor der HTTP/HTTPS -> any Regel explizit die Kommunikation von Subnetz zu Subnetz blockieren.

Sprich, vereinfacht sieht das so aus:

1. DENY source:WLAN net -> destination: LAN net -> port: any
2. PASS source:WLAN net -> destination: any -> port: HTTP/HTTPS

Korrekt?


Jetzt kommt der Teil, den ich noch nicht ganz verstehe, der sich aber daraus ja logisch ableiten muss:

Die Firewall evaluiert die Regeln ja nach dem "First Match" Prinzip. Die erste Regel, die zutrifft, wird auch ausgeführt. Das bedeutet also, die Firewall geht die Regeln von oben nach unten durch. Dann trifft sie auf die Regel Nr. 1 und blockiert jegliche Kommunikation (also jeden Port) vom WLAN Subnetz ins LAN Subnetz (das tat sie zwar auch schon vorher, durch die immer letzte DENY ANY ANY Regel aber es geht ja glecih noch weiter).

Darauf folgt dann die Regel Nr. 2, die Firewall lässt die Kommunikation vom WLAN Netz über Port 80 und 443 in ALLE Netze zu (destination: any, damit der Datenverkehr ins Internet durchgelassen werden kann), aber die vorherige Regel wird damit nicht wieder aufgehoben. Korrekt soweit?

Hier nämlich liegt grade mein Denkfehler, ich schaue momentan nur auf die formulierte Regel und habe die Reihenfolgen ausser acht gelassen. Die Firewall "merkt" sich also alles, was sie vorher evaluiert hat und baut das Regelwerk stufenweise darauf auf. Was zuvor blockiert wurde, kann und wird danach nicht durch eine allgemeine Freischaltung aufgehoben.

Hier Frage ich mich aber, warum kann so ein Prozess nicht deutlich einfacher gestaltet werden?

Die DENY ANY ANY Regel am Schluss verbietet doch erst mal alles. Wieso kann man nicht eine einzige Regel schreiben, die ausschließlich den Traffic von WLAN Subnetz ins Internet (destination: internet) erlaubt auf Port 80/443 und fertig? Oder andersrum gefragt, warum gibt es als Destination kein "internet" oder wie auch immer man es nennen würde?

Quote
Everything that isn't explicitly passed is blocked by default.


Man müsste sich doch garnicht erst um das Blockieren daer Subnetze untereinander bemühen, um danach den Traffic auf "any" zu erlauben. Man müsste doch nur noch den Traffic ganz spezifisch erlauben und der Rest wird eh geblockt.

Denke ich hier wieder falsch rum?

Und was ich mich auch noch frage, ist: Wenn ich momentan durch meine Regeln alles  erlaube, wearum kommt dann ein Ping von meinem WLAN Netz am LAN Interface nicht an? Ich habe am LAN Interface momentan noch eine ALLOW ANY ANY Regel, um das schrittweise zu machen und um zu testen,  ob die Kommunikation von WLAN ins LAN problemlos geht (ich will mir das einfacher dadurch machen und erst mal das WLAN sauber konfigurieren und dann das LAN).

Sollte daher ein Ping vom WLAN Subnetz ans LAN Interface nicht schon funktionieren?

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 18, 2017, 09:34:23 am
Quote
Ich habe bei mir den Cache im RAM - 1/2 GB reicht da für den Betrieb daheim aus und ich habe 4GB. Das Meiste ist auch bei mir frei. Du solltest nur vorsichtig sein, wenn du auch die IDS nutzen willst. Die braucht einiges an RAM.

Alles klar. :)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 18, 2017, 01:12:46 pm
Quote
Sprich, vereinfacht sieht das so aus:

1. DENY source:WLAN net -> destination: LAN net -> port: any
2. PASS source:WLAN net -> destination: any -> port: HTTP/HTTPS

Korrekt?

Genau. :) Die Firewall vergleicht Source und Destination IP im ankommenden Paket und sieht das du z.b. auf Port 443 zugreifen möchtest. Dadurch, dass du vor der Destination ANY Regel aber diese durch die Regel davor eingegrenzt hast, würde diese DANN nicht greifen WENN im Destination Feld eine IP aus dem LAN Netz steht.

Quote
Darauf folgt dann die Regel Nr. 2, die Firewall lässt die Kommunikation vom WLAN Netz über Port 80 und 443 in ALLE Netze zu (destination: any, damit der Datenverkehr ins Internet durchgelassen werden kann), aber die vorherige Regel wird damit nicht wieder aufgehoben. Korrekt soweit?

Regeln werden nicht "aufgehoben". Entweder sie "matchen" oder eben nicht. Falls die DENY WLAN Subnetz --> LAN Subnetz nicht matched, weil im Destination Feld keine IP aus dem LAN Netz steht, greift diese auch nicht und die Regel danach, die Destination: ANY Regel erlaubt dann die Verbindung zu jeder anderen IP auf Port 80 oder 443 die du in diesem Moment angewählt hattest.

Quote
...wird danach nicht durch eine allgemeine Freischaltung aufgehoben.

Richtig. Wenn eine Regel gematched hat, ist die Suche vorbei und alle anderen Regeln werden nicht mehr betrachtet.

Quote
Die DENY ANY ANY Regel am Schluss verbietet doch erst mal alles. Wieso kann man nicht eine einzige Regel schreiben, die ausschließlich den Traffic von WLAN Subnetz ins Internet (destination: internet) erlaubt auf Port 80/443 und fertig? Oder andersrum gefragt, warum gibt es als Destination kein "internet" oder wie auch immer man es nennen würde?

Genau das is das Problem. Wie würdest du denn "Internet" definieren? Eine Firewall is doof wie Stulle.... die hat zwei IP (Source und Destination), hat zwei Ports (Source und Destination Port) und weiß ob outbound oder inbound. Anhand dieser Dinge entscheidet sie JA oder NEIN. Deine Aufgabe als Netzwerk Admin ist es nun durch clevere Regelformulierungen der Firewall "Intelligenz" beizubringen.
Besser gesagt.. welche IPs hat denn "Internet"?
Woher soll die Firewall wissen, welche IPs nicht das Internet sein sollen?

Quote
Man müsste sich doch gar nicht erst um das Blockieren der Subnetze untereinander bemühen, um danach den Traffic auf "any" zu erlauben. Man müsste doch nur noch den Traffic ganz spezifisch erlauben und der Rest wird eh geblockt.

Genau... aber das Internet ist eben nicht Spezifisch.. es gibt ja keine "Internet-IP" ;)
Sobald du keine "PERMIT Source:irgendwas --> Destination: ANY" schreibst, brauchst du dir auch weniger Gedanken um das Blocken machen.
Außerdem musst du auch immer davon ausgehen, dass Firewalls in Firmen uuuunzählige IPs/Subnetze und Dienste zu laufen haben. Dementsprechend müssen die Regeln einfach von Hause aus offener formuliert werden um nicht 1000 Regel-Einträge zu haben. Um dann aber trotzdem die Freischaltungen eingrenzen zu können, blockt man so "großflächig" wie es geht... Subnetz zu Subnetz...... Inbound gar kein Traffic usw...

Quote
Sollte daher ein Ping vom WLAN Subnetz ans LAN Interface nicht schon funktionieren?
Wie war nochmal deine Regel formuliert?
Permit -> ICMP -> Source: WLAN Net -> Destination: LAN Net ??
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 19, 2017, 12:35:38 pm
Hi Oxy,

Quote
Richtig. Wenn eine Regel gematched hat, ist die Suche vorbei und alle anderen Regeln werden nicht mehr betrachtet.

Ja, das habe ich im Nachhinein auch so verstanden. Ich hatte einen Denkfehler, ich habe die Daten als "Stream" gesehen (was sie prinzipiell auch sind) und angenommen, dass die Firewall jedes Datenpaket nacheinander durchgeht und die Regeln anwendet und zwar jede Regel die möglich ist.

Es ist aber ja so, dass die Firewall jedes Pakte einzeln betrachtet und ganz stumpf schaut: passt die Regel? Wenn Ja, mach was in der Regel steht. Ende. Wenn Nein, schau in die nächste Regel.

Einfacher gesagt: Ich hatte angenommen, dass jedes Datenpaket den kompletten Regelsatz durchwandert, auch wenn  eine Regel bereits gematcht hat. Blöde Annahme, anders macht es natürlich Sinn.  ;D

Quote
Genau das is das Problem. Wie würdest du denn "Internet" definieren? Eine Firewall is doof wie Stulle.... die hat zwei IP (Source und Destination), hat zwei Ports (Source und Destination Port) und weiß ob outbound oder inbound. Anhand dieser Dinge entscheidet sie JA oder NEIN. Deine Aufgabe als Netzwerk Admin ist es nun durch clevere Regelformulierungen der Firewall "Intelligenz" beizubringen.
Besser gesagt.. welche IPs hat denn "Internet"?
Woher soll die Firewall wissen, welche IPs nicht das Internet sein sollen?

Bei längerem Nachdenken, ist das durchaus etwas, das problematisch ist, ja. Mir ist klar, dass ich nicht der erste bin, der sich solche Fragen stellt und dutzende schlaue Leute haben Firewalls gerade deswegen so implementiert, wie sie heute sind. ;) Aber ich gehe an sowas einfach gerne etwas naiver ran, weil ich so selbst mein Verständnis langsam verbessern kann. Simple Fragen um die Grundlagen zu verstehen.... ;)

Ich habe z.B. gedacht, dass eine Firewall dann an letzter Stelle, also am Interface, an dem es raus ins Internet geht, eine Art Indextabelle (Lookup table) führt, die auf Basis der package inspection und der Details pro Paket entscheiden kann, ist das ein Datenpaket für das interne Netz (IP Bereich, Subnetzmaske, etc.) oder   geht es raus in ein "anderes" Netz. Aber das wird schon seinen Grund haben, warum das nicht geht.

Quote
Genau... aber das Internet ist eben nicht Spezifisch.. es gibt ja keine "Internet-IP" ;)
Sobald du keine "PERMIT Source:irgendwas --> Destination: ANY" schreibst, brauchst du dir auch weniger Gedanken um das Blocken machen.

Jau. Ich werde mir das angewöhnen, so spezifisch wie möglich zu sein bei den Regeldefinitionen und dann (wie Du geschrieben hast), nach unten hin die "lockeren" Regeln zu schieben.

 
Quote
Wie war nochmal deine Regel formuliert?
Permit -> ICMP -> Source: WLAN Net -> Destination: LAN Net ??

Ja, das war blöd. :D Ich hatte mir das gestern Abend noch mal angesehen und dann entsprechend ICMP vom WLAN ins LAN freigegeben. Und siehe da, ich kann pingen. ^^

Ich hatte auch die DNS und NTP Regeln angepasst, und diese auf die IP des WLAN interface gebunden.

Was mir wieder Kopfzerbrechen bereitet, ist mein nächster Task.

Ich möchte meine Sonos Netzwerk Boxen wieder ansprechbar machen. Ich nutze ein Setup, in dem eine "Wireless Bridge" (http://www.sonos.com/de-de/shop/boost.html) sozusagen ein eigenes internes Netz zu den Boxen aufspannt (aber natürlich nutzen die Boxen auch das bereits vorhandene WLAN, das ganze wäre auch ohne die Bridge lauffähig. Die Bridge kann einfach, bei schlechtem WLAN, selbst als Access Point für die Boxen fungieren). Diese Bridge hängt per LAN an meinem LAN Interface, oder um es noch genauer zu formulieren (damit es keine Missverständnisse gibt), am Switch, der wiederum am LAN Port des LAN Interfaces hängt. .

Zuvor war es so, dass ich das Gerät an meinem ehemaligen Router angeschlossen hatte. Als ich vor kurzem die Bridge (hier meine ich die Bridge in der Firewall! Also als ich LAN und WLAN zusammengefasst hatte) noch eingerichtet hatte, war das Gerät sowie die Sonos Boxen - wie auch im alten Zustand mit dem normalen Router - im ganzen Netzwerk sichtbar.

Jetzt muss ich ja dafür sorgen. dass ich zum einen von meinem WLAN Subnetz aus zu der Sonos Bridge kommunizieren kann und zum anderen, dass die Sonos Geräte nach draußen (ins Internet) kommunizieren können, um die Musik zu streamen.

Da ich ja noch  die ALLOW ANY ANY Regel in meinem LAN Subnetz habe (ja, die wird bald raus fliegen, keine Sorge! ;) ), gehe ich davon aus, dass die Sonos Bridge komplett nach außen kommunizieren kann.  Dass ich die Sonos Bridge in meinem WLAN Netzwerk nicht sehen kann, ist klar, da ich hier (https://sonos.custhelp.com/app/answers/detail/a_id/692/~/configuring-your-firewall-to-work-with-sonos) gelesen habe, welche Ports die Sonos Geräte nutzen.

Dort steht, dass ich für den Sonos Controller (also die App auf meinem Smartphone) Port 3500 benötige (unter Android).

Ich hatte also mal testweise an meinem WLAN Interface eine Regel geschrieben:

PASS source: any -> destination: WLAN subnetz -> Port: 3500

Source any würde ich im zweiten Schritt in Seource: LAN subnetz ändern, ich möchte es grade einfach halten.

Auf meinem Smartphone kann ich mit einer App, die meine Netzwerkverbindungen überwacht, sehen, dass mein Smartphone auf Port 3500 "lauscht" und auf eine verbindung wartet. Wenn ich die Sonso Controller App öffne, dann sucht diese ein paar Sekunden lang, findet aber kein Sonos System.

Das wird (hoffentlich) an den ganzen anderen Ports liegen, die ich noch nicht geöffnet habe (und auch nicht alle öffnen will und werde). Aber wie aus dem Link ersichtlich ist, werden z.B. auch die Ports

1900 (UPnP events and device detection)
1901 (UPnP responses)

benötigt.

Kann es sein, dass darin auch der Grund liegt, dass ich die Boxen (die ja, entgegen der Sonos Bridge, die in meinem LAN Subnetz ist) nicht im WLAN sehe? Den die müssten ja da sein, die Boxen haben immer eine Verbindung zu meinem normalen WLAN im Haus.

Außerdem schließen sich daran noch zwei weitere Punkte an:

1. Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben? Denn ich sehe ja aktuell noch keines der anderen Geräte im LAN. Wenn ich z.B. mit einer simplen App das Netzwerk scanne (mit meinem Smartphone) oder z.B. mit nmap von meinem Rechner aus, dann sehe ich ja nur die Geräte im WLAN Subnetz. Klar, wenn ich meinen Rechner per LAN Kabel an den Switch schalten würde, würde ich dort alle Geräte sehen. Aber das möchte ich ja nicht jedes Mal tun, es müsste dafür doch einen Punkt im Interface der Firewall geben, oder?

2. Mache ich mir das Leben nicht erheblich einfacher (so gern ich an der Firewall auch konfiguriere und lerne), wenn ich diese Sonos Bridge einfach vom LAN Switch an den WLAN Access Point stöpsel? Dann wäre das Gerät ja im selben Subnetz und ich hätte erheblich weniger Aufwand, weil ich keine Regeln von LAN Subnetz zu WLAN Subnetz erstellen müsste. Zumal ich überlege, welchen Vorteil ich davon habe, die Sonos Bridge im LAN Subnetz zu lassen? Die jeweiligen Ports kann ich ja aus jedem Subnetz heraus erlauben und auch blocken.

Gibt es hierzu auch eine "Best Practice", warum ich die Sonos Bridge im LAN Subnetz lassen sollte/könnte/müsste?

Für mich hat diese Geschichte so einen kleinen Sonderstatus, was die Einteilung in ein Subnetz betrifft. Denn der Sinn ist ja eben, ein Musikstreaming per Funknetz zu haben. Darum wäre es für mich auch die einzige Ausnahme, was das Anschließen des Gerätes per LAN Kabel am WLAN Access Point betrifft.

Wie seht/scannt/findet ihr denn alle eure Geräte, die in unterschiedlichen Subnetzen unterwegs sind?

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: fabian on January 19, 2017, 03:54:27 pm
1. Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben? Denn ich sehe ja aktuell noch keines der anderen Geräte im LAN. Wenn ich z.B. mit einer simplen App das Netzwerk scanne (mit meinem Smartphone) oder z.B. mit nmap von meinem Rechner aus, dann sehe ich ja nur die Geräte im WLAN Subnetz. Klar, wenn ich meinen Rechner per LAN Kabel an den Switch schalten würde, würde ich dort alle Geräte sehen. Aber das möchte ich ja nicht jedes Mal tun, es müsste dafür doch einen Punkt im Interface der Firewall geben, oder?

Am einfachsten ist es, den ARP- und NDP-Cache der Firewall zu lesen. Dazu muss unter umständen zuerst versucht werden, mit allen Computern eine Verbindung aufzubauen. Alternativ kann man ja auch nmap nmap auf OPNsense starten.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 20, 2017, 08:50:37 am
Quote
Ich habe z.B. gedacht, dass eine Firewall dann an letzter Stelle, also am Interface, an dem es raus ins Internet geht, eine Art Indextabelle (Lookup table) führt, die auf Basis der package inspection und der Details pro Paket entscheiden kann, ist das ein Datenpaket für das interne Netz (IP Bereich, Subnetzmaske, etc.) oder   geht es raus in ein "anderes" Netz. Aber das wird schon seinen Grund haben, warum das nicht geht.

Natürlich geht das. Du musst bloß deine Regeln dementsprechend formulieren...
Die "Lookup Tabelle" ist ja genau dein ausformuliertes Regelwerk.
ANY heißt halt nun mal ALLES...
Nich böse gemeint, aber wenn du selber nicht weißt wie dein Traffic ins interne Subnetz soll, woher soll die Firewall das dann wissen? Wenn du sagst "erlaube alles nach HTTP", kann die Firewall doch nich Gedanken lesen und "erahnen" was du wirklich meintest. :D
Deshalb sind die Formulierungen der Regeln ja auch mit das Schwerste und Wichtigste an einer Firewall. :)

Willst du noch mehr Kontrolle und tatsächlich in JEDES Datenpaket schauen um JEDEN Dateninhalt auszulesen, musst du dir eine Firewall suchen, die ein sogenanntes "Deep Packet Inspection" betreibt.
In der Türkei wird so zurzeit verhindert, dass Leute VPN Server oder Tor Services ansprechen können.
Ziemlich mächtiges Tool, mit der Einschränkung, dass du als Administrator so einer Firewall dann natürlich 24/7 arbeiten musst, um saubere Regeln zu formulieren. ;)
Völlig sinnfrei also für ein Home Netzwerk. :) SPI ist schon das sinnvollste was man zurzeit machen kann.
Weiteres zum Nachlesen hier: http://www.itwissen.info/definition/lexikon/DPI-deep-packet-inspection.html

Quote
Jau. Ich werde mir das angewöhnen, so spezifisch wie möglich zu sein bei den Regeldefinitionen und dann (wie Du geschrieben hast), nach unten hin die "lockeren" Regeln zu schieben.

Genau. Die Chance, dass man dann was übersehen hat ist halt eingegrenzt. :)
Wichtig ist am Ende immer eine Art Testprotokoll zu führen. Du schließt also Geräte an die jeweiligen Subnetze an und versuchst deine eigenen Regeln auszutricksen/zu testen und schaust ob das erwartete Ergebnis rauskommt.
Falls nicht versuchst du deine Regeln so umzuformulieren, dass es passt.
(Diese Stelle hasse ich immer :D)

Zu Sonos kann ich dir leider gar nichts sagen, da ich da keine Erfahrungen mit machen konnte.
Kann dir also nich sagen was man da machen kann oder sogar sollte.
Wegen den Regeln würde ich erst einmal alle hinschreiben, probieren ob alles funktioniert und dann Regel für Regel deaktivieren und schauen, ob es immer noch funktioniert. :)

Quote
Gibt es in der Firewall irgendeine Übersicht über alle Clients, die in einem Subnetz eine Adresse zugewiesen bekommen haben?

Ich bin mal ganz frech und sage "na klar" ;)
Das meintest du wahrscheinlich nicht, aber du kannst dir ja bei "Services > DHCP > Leases" die ausgegebenen IPs anzeigen lassen. Da müssten dann auch deine gemappten Einträge zu sehen sein z.B. :)

Quote
Wie seht/scannt/findet ihr denn alle eure Geräte, die in unterschiedlichen Subnetzen unterwegs sind?

Stichwort: Network Monitoring, bzw. Systembetriebs Überwachung.

Dafür gibt es zich Lösungen die eingesetzt werden um irgendeine Art "Übersicht" zu behalten.
Du könntest einen Syslog Server in dein Netz hängen, der alle Logs sammelt und verarbeitet.
In der Art weißt du zu mindestens etwas über deine Switche, Router und deine OPNsense Firewall.
OPNsense kannst du nämlich hier: "Services > SNMP" so konfigurieren,
dass es Nachrichten für deinen Syslog Server erstellt.

Dann gibt es noch Nagios (sehr wahrscheinlich viel zu umständlich für ein Home Netzwerk), mit welchem du echt ALLES bewerkstelligen kannst, wenns um Überwachung geht.
Eine einfachere Alternative wäre hier: Check_MK | siehe: https://mathias-kettner.de/check_mk.html

In Firmen kommt oft eine CMDB (Configuration Management Database) zum Einsatz:
"Ziele des Configuration Management sind:
Auskunft über alle IT-Komponenten und -Konfigurationen innerhalb des Unternehmens und seiner Services zu geben."

Auch das finde ich völlig sinn frei für ein Home Office, aber "möglich" wäre es. :)

Wie gesagt zum Rest kann ich nich viel sagen. Sorry! :(

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 22, 2017, 12:36:25 pm
Moin zusammen,

Quote
Am einfachsten ist es, den ARP- und NDP-Cache der Firewall zu lesen. Dazu muss unter umständen zuerst versucht werden, mit allen Computern eine Verbindung aufzubauen. Alternativ kann man ja auch nmap nmap auf OPNsense starten.

Quote
Ich bin mal ganz frech und sage "na klar" ;)
Das meintest du wahrscheinlich nicht, aber du kannst dir ja bei "Services > DHCP > Leases" die ausgegebenen IPs anzeigen lassen. Da müssten dann auch deine gemappten Einträge zu sehen sein z.B. :)

Genau das mit den Leases meinte ich. Danke. Die Übersicht habe ich gesucht. Da konnte ich dann auch schnell alle Leases statisch mappen (was natürlich auch über die DHCP Einstellungenen am jeweiligen Interface geht).

Aber nmap direkt auf der OPNsense laufen lassen, ist natürlich auch ne gute Möglichkeit. :)

Quote
Natürlich geht das. Du musst bloß deine Regeln dementsprechend formulieren...
Die "Lookup Tabelle" ist ja genau dein ausformuliertes Regelwerk.
ANY heißt halt nun mal ALLES...
Nich böse gemeint, aber wenn du selber nicht weißt wie dein Traffic ins interne Subnetz soll, woher soll die Firewall das dann wissen? Wenn du sagst "erlaube alles nach HTTP", kann die Firewall doch nich Gedanken lesen und "erahnen" was du wirklich meintest. :D
Deshalb sind die Formulierungen der Regeln ja auch mit das Schwerste und Wichtigste an einer Firewall. :)

Ich meinte das noch etwas anders. ;) Auf einer anderen "Ebene" , ich hab das aus Entwicklersicht gedacht. Aber im Prinzip hast Du natürlich recht. So einfach ist es dann doch nicht.

Quote
Willst du noch mehr Kontrolle und tatsächlich in JEDES Datenpaket schauen um JEDEN Dateninhalt auszulesen, musst du dir eine Firewall suchen, die ein sogenanntes "Deep Packet Inspection" betreibt.
In der Türkei wird so zurzeit verhindert, dass Leute VPN Server oder Tor Services ansprechen können.
Ziemlich mächtiges Tool, mit der Einschränkung, dass du als Administrator so einer Firewall dann natürlich 24/7 arbeiten musst, um saubere Regeln zu formulieren. ;)
Völlig sinnfrei also für ein Home Netzwerk. :) SPI ist schon das sinnvollste was man zurzeit machen kann.

Jap, das ist mir ein bekannter Begriff. Natürlich völliger Overkill, aber spannende Thematik.

Quote
Zu Sonos kann ich dir leider gar nichts sagen, da ich da keine Erfahrungen mit machen konnte.
Kann dir also nich sagen was man da machen kann oder sogar sollte.
Wegen den Regeln würde ich erst einmal alle hinschreiben, probieren ob alles funktioniert und dann Regel für Regel deaktivieren und schauen, ob es immer noch funktioniert. :)

Also, ich habe diese Sonos Bridge jetzt einfach an meinen Access Point gehängt. Der ist dafür ja da und je mehr ich darüber nachgedacht habe, desto mehr Sinn machte es für mich. Das Musiksystem hat für mich nichts in meinem LAN verloren, ich kontrolliere die Boxen nur über Wireless Geräte und außer dem Streaming aus dem Internet soll das ganze nichts anderes machen. Ich streame z.B. keine Musik von einem lokalen Medienserver aus meinem LAN oder ähnliches. Von daher finde ich die Lösung genau richtig.

Nach dem Umstöpseln an den AP waren auch die Sonos Bridge und die  Boxen direkt sichtbar. Ich habe statische Leases vergeben und zu meinem Erstauenen brauchte ich auch keinerlei andere Ports freischalten für das Streaming.  Was mich ein wenig gewundert hat, da ja auf der Supportseite von Sonos die Portlisten stehen, die man freischalten soll.

Ich habe dann einfach mal getestet und festgestellt, dass das System offensichtlich nur Port 80, also HTTP, benötigt. Wenn ich diese Regel deaktiviere, dann kann ich nichts mehr streamen.

Was ich hier aber vermute, ist, dass das Freischalten der ganzen Ports dann nötig ist, wenn man die Boxen standalone betreibt. Ich glaube, dass diese Sonos Bridge "intern", also in ihrem "eigenen" Netz, die Boxen über ihre eigenen Ports ansteuert und nach außen hin scheint die das alles über Port 80 zu kapseln.

Anders kann ich es mir nicht erklären, da ich ja definitv keine Regelfreischaltungen erstellt habe auf dem WLAN Interface. Da besteht der Regelsatz wie auch zuvor, also die Standardports (HTTP, HTTPS, IMAP, etc.) von WLAN  Subnetz -> any. Und die implizite letzte DENY ANY ANY Regel blockt ja alles andere. Von daher wäre es mir ein Rätsel, wie das Streaming sonst funktioniert, wenn das nicht über die Sonos Bridge gekapselt wird.

Ich hänge noch mal meine aktuellen WLAN Interface Regeln an, so wie sie aktuell sind. Fehlt da etwas "grundlegendes", das ich gerade vergesse? Ich meine wirklich nur grundlegende Regeln, die ich grade völlig vergesse/übersehe.

Dazu fallen mir auch noch zwei Fragen ein:

1. Sollte man die Anti Lockout Rule nicht noch spezifischer machen? Die war ja standardmäßig angelegt. Sollte die nicht spezifisch als Source das LAN und WLAN Subnetz haben? 

2. Du, Oxy, hattest doch mal den Hinweis gepostet, dass man die NetBIOS Ports dicht machen sollte bei Windows Maschinen.Da ich dahingehend ja keine Freischaltungen habe, sind die doch durch die letzte DENY ANY ANY Regel dicht. Da sind wir doch wieder bei der Sache, dass alles geblockt wird, was nicht explizit erlaubt ist.

Warum sollte ich da also spezifische Block Regeln schreiben?

Ich überlege auch momentan, ob es jetzt Sinn macht, dass ich im WLAN Subnetz die Kommunikation auf Clients beschränke, oder ob ich die Regeln für das ganze Subnetz erlaube (wie es momentan ja ist)? Wie findet man das eine gute Lösung? Also, wann macht es Sinn, zu sagen, statt:

Source: WLAN Subnetz -> Destination: any -> Port: HTTP/HTTPS

mache ich:

Source: WLAN Client IP -> Destination: any -> Port: HTTP/HTTPS

Feste DHCP Leases habe ich ja, aber ist das paranoid? Oder genau richtig? Klar, der Anwendungsfall, wenn ich hier Gäste habe, die ich in mein WLAN lasse, müsste ich dann immer explizit freischalten. Was logischerweise dazu führt, dass man ein Gästenetz aufspannt.

Quote
Dafür gibt es zich Lösungen die eingesetzt werden um irgendeine Art "Übersicht" zu behalten.
Du könntest einen Syslog Server in dein Netz hängen, der alle Logs sammelt und verarbeitet.
In der Art weißt du zu mindestens etwas über deine Switche, Router und deine OPNsense Firewall.
OPNsense kannst du nämlich hier: "Services > SNMP" so konfigurieren,
dass es Nachrichten für deinen Syslog Server erstellt.

Dann gibt es noch Nagios (sehr wahrscheinlich viel zu umständlich für ein Home Netzwerk), mit welchem du echt ALLES bewerkstelligen kannst, wenns um Überwachung geht.
Eine einfachere Alternative wäre hier: Check_MK | siehe: https://mathias-kettner.de/check_mk.html

In Firmen kommt oft eine CMDB (Configuration Management Database) zum Einsatz:
"Ziele des Configuration Management sind:
Auskunft über alle IT-Komponenten und -Konfigurationen innerhalb des Unternehmens und seiner Services zu geben."
Auch das finde ich völlig sinn frei für ein Home Office, aber "möglich" wäre es.

Jap, Nagios und ein paar kleinere Tools kenne ich aus der Firma, das ist natürlich völlig übertrieben für meinen Fall zu Hause. Wie gesagt, mir reicht ja jetzt erst mal auch, dass ich die Lease Übersicht habe. Und das Monitoring kann ich ja mit z.B. einem nmap bewerkstelligen, zumindest das, was ich damit erreichen möchte. ;)


Bezüglich dem Proxy Thema (https://docs.opnsense.org/manual/proxy.html) noch mal ganz allgemein gefragt:

Nutzt ihr den Proxy?
Und wenn ja, als transparenten Proxy? Oder habt ihr alle Clients zu Hause mit Proxyeinstellungen versehen?
Und nutzt ihr den Proxy fürs Caching (egal ob RAM oder SSD) oder für die Webfilterung anhand von Sperrlisten?  Oder beides zusammen?

Schönen Sonntag zusammen!

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: Oxygen61 on January 22, 2017, 02:59:22 pm
Hey hey,

Quote
Fehlt da etwas "grundlegendes", das ich gerade vergesse?

Das kannst du nur herausfinden, indem du deine Regeln auf die Probe stellst.
Welche Verbindung sollte denn anhand deiner Regeln nicht mehr funktionieren?
Wenns dann doch klappt musst du dir überlegen warum.

Quote
1. Sollte man die Anti Lockout Rule nicht noch spezifischer machen? Die war ja standardmäßig angelegt. Sollte die nicht spezifisch als Source das LAN und WLAN Subnetz haben?

Die Antilockout Regel, also die Regel zum Schutz davor dich selbst auszusperren, hat nur einen Zweck.
Sie soll dafür sorgen, dass du aus deinem Management Subnetz, von welchem du auf die GUI zugreifst, immer Zugriff auf die Weboberfläche hast. Gerade am Anfang beim formulieren der Regeln, kann es schnell passieren, dass man eine Regel schreibt, die dich aussperren würde.
Im Idealfall hast du am Ende diese Regel deaktiviert und mit einer Regel ersetzt, die angemessener erscheint.

Beispiel Regel für das LAN Subnetz:
PASS --> KonfigurationsLaptop (statische IP) --> LAN Interface (WebGUI) --> Port 443 und 22
~ In diesem Fall würde dann nur noch ein Laptop aus deinem LAN Subnetz auf die Weboberfläche zugreifen können und über SSH auf die Shell.

Quote
hattest doch mal den Hinweis gepostet, dass man die NetBIOS Ports dicht machen sollte bei Windows Maschinen.

Genau. Innerhalb deines internen Netzes kann es ja gut und gerne sein, dass man die vielleicht mal braucht. Wichtig ist nur, dass diese nicht ins "äußere Netz / Internet" kommunizieren, was sie im Normalfall sonst machen.
Sind deine Regeln speziell genug formuliert hast du dieses Problem nicht.
In Firmennetzwerken schreibt man diese Regeln trotzdem hin,
einfach nur um sagen zu können: "ich hab sie hingeschrieben".

Quote
Ich überlege auch momentan, ob es jetzt Sinn macht, dass ich im WLAN Subnetz die Kommunikation auf Clients beschränke

Das ist abhängig von deiner Bequemlichkeit, davon abhängig wie oft dein Netzwerk sich ändert und ebenfalls davon abhängig wie groß dein Netz ist. Wenn es eine Regel gibt, die so oder so alle Geräte innerhalb eines Subnetzes benötigen, wäre es ja unsinnig diese eine Regel auf 20 Geräte zu verteilen.

Quote
wenn ich hier Gäste habe, die ich in mein WLAN lasse, müsste ich dann immer explizit freischalten. Was logischerweise dazu führt, dass man ein Gästenetz aufspannt.

Gäste haben in deinem WLAN nichts zu suchen. Die Frage nach Freischaltungen erübrigt sich dann.
Man macht ein Gästenetz auf, gibt ihnen einen Vouchercode und das wars. Das Gästenetz trennst du dann hart von deinen anderen Subnetzen und lässt ihnen da drinne ihren Freiraum für was auch immer.
(Um Quengeleien zu vermeiden)

Zum Thema Proxy hatte sich monstermania ja schon des öfteren zu geäußert.
Das ist abhängig davon, was du am Ende bei deinem Anwendungsfall bezwecken möchtest.
Das ist auch ein sehr OPNsense unspezifisches Thema.
Da gibt es sicher gute Pro/Contra Listen im Internet die dem Thema da kleinlichst auf die Spur gehen.
Mit nem Proxy kann man halt wieder zusätzlich viele "spaßige" Dinge machen um das Leben der Anwender "vielleicht" zu erschweren. Im Gegensatz dazu dient es als Möglichkeit der Überwachung (SSL-Proxy).
Wenn du alleine in deinem Netz bist, würde ich natürlich all das aufbauen, wozu ich Lust und Laune habe.
Mich selber Man-in-the-middle mäßig anzugreifen stört mich ja nicht.
Ob Freunde, WG Kumpels, Eltern oder wer auch immer noch in deinem Netz hängt davon so begeistert sind wage ich zu bezweifeln.

Schöne Grüße
Oxy
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 22, 2017, 04:43:33 pm
Quote
Das kannst du nur herausfinden, indem du deine Regeln auf die Probe stellst.
Welche Verbindung sollte denn anhand deiner Regeln nicht mehr funktionieren?
Wenns dann doch klappt musst du dir überlegen warum.

Klar. ;) Es läuft alles so, wie ich es möchte. Ich dachte eher daran, ob ich was ganz gravierendes falsch ist. Aber ich meine heraus zu hören, dass da nichts "offensichtlich" falsch ist. ^^

Quote
Im Idealfall hast du am Ende diese Regel deaktiviert und mit einer Regel ersetzt, die angemessener erscheint.

Beispiel Regel für das LAN Subnetz:
PASS --> KonfigurationsLaptop (statische IP) --> LAN Interface (WebGUI) --> Port 443
~ In diesem Fall würde dann nur noch ein Laptop aus deinem LAN Subnetz auf die Weboberfläche zugreifen können.

Genau so war das gemeint. Nur noch ein Gerät mit fester IP mit Zugriff auf das Interface.

Quote
Genau. Innerhalb deines internen Netzes kann es ja gut und gerne sein, dass man die vielleicht mal braucht. Wichtig ist nur, dass diese nicht ins "äußere Netz / Internet" kommunizieren, was sie im Normalfall sonst machen.
Sind deine Regeln speziell genug formuliert hast du dieses Problem nicht.

Genau. Mit anderen Worten:

Wenn ich sie intern erlaube, achte ich darauf, sie nicht nach außen kommunizieren lassen. Und so lange ich sie nirgendes erlaube, sind sie sowieso immer geblockt.

Quote
Das ist abhängig von deiner Bequemlichkeit, davon abhängig wie oft dein Netzwerk sich ändert und ebenfalls davon abhängig wie groß dein Netz ist. Wenn es eine Regel gibt, die so oder so alle Geräte innerhalb eines Subnetzes benötigen, wäre es ja unsinnig diese eine Regel auf 20 Geräte zu verteilen.

Stimmt. Der letzte Punkt ist ein guter Hinweis. Da muss man einfach einen guten Mittelweg finden.

Quote
Gäste haben in deinem WLAN nichts zu suchen. Die Frage nach Freischaltungen erübrigt sich dann.
Man macht ein Gästenetz auf, gibt ihnen einen Vouchercode und das wars. Das Gästenetz trennst du dann hart von deinen anderen Subnetzen und lässt ihnen da drinne ihren Freiraum für was auch immer.
(Um Quengeleien zu vermeiden)

Ok, das war ja auch mein Gedanke.

Das würde ich dann machen, wie hier beschrieben:

https://docs.opnsense.org/manual/captiveportal.html
https://docs.opnsense.org/manual/how-tos/guestnet.html

Richtig?

Wenn ja, dann frage ich mich gerade ehrlich gesagt, wie ich denn ein Interface für das Gästeportal hinzufügen soll? Ich habe ja keine Interfaces mehr verfügbar. ^^ Oder ist damit irgendein "virtuelles" Interface gemeint? Ich habe ja nur drei Interfaces zur Verfügung, LAN, WLAN und WAN. Habe ich da was übersehen? :-/

Quote
Mit nem Proxy kann man halt wieder zusätzlich viele "spaßige" Dinge machen um das Leben der Anwender "vielleicht" zu erschweren. Im Gegensatz dazu dient es als Möglichkeit der Überwachung (SSL-Proxy).
Wenn du alleine in deinem Netz bist, würde ich natürlich all das aufbauen, wozu ich Lust und Laune habe.
Mich selber Man-in-the-middle mäßig anzugreifen stört mich ja nicht.
Ob Freunde, WG Kumpels, Eltern oder wer auch immer noch in deinem Netz hängt davon so begeistert sind wage ich zu bezweifeln.

Das stimmt. Ich mache das alles ja "nur" für mich. Und natürlich für die Frau im Hause. Gerade da ist es mir aber wichtig, zwar ein wenig rumspielen zu können um auszuprobieren, was ich tatsächlich brauche und was nicht und andererseits auch z.B. durch die Filterung von gefährlichen Dateien oder durch das Blocken anhand von Blacklists Sicherheit ins Netzwerk zu bekommen.

Das Caching würde ich auch nutzen, wobei das eher ein nice to have ist und nichts, was ich essentiell wichtig finde, da ich mich über die Performance hier nicht beschweren möchte. ;)

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 25, 2017, 03:31:39 pm
Hi,

zum Gästenetzwerk habe ich noch eine Frage:

Ich habe inzwischen einen richtigen Access Point, den ich anstelle des alten Routers (der als AP konfiguriert war) gesetzt habe.

Über den AP kann ich ein Gästenetzwerk aufbauen, welches angeblich laut Hersteller den Zugriff auf das WLAN Subnetz unterbindet. Hier frage ich mich gerade:

Kann ich das Gästenetzwerk noch in irgendeiner Art und Weise von der Firewall aus beeinflussen/sichern? Oder bin ich da einfach dem Vertrauen in den Hersteller ausgesetzt, dass die Software des AP das sauber umsetzt?

Gruß
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 25, 2017, 04:53:13 pm
Hi,
wenn Du mit einem AP 2 WLAN's nutzen willst (intern und Gäste), würde ich das Gäste WLAN per vLAN an die Firewall anbinden. Dann kannst Du selbst auf der Firewall bestimmen welche Möglichkeiten Du Deinen Gästen anbietest (z.B. Captive Portal, WebProxy).

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 26, 2017, 09:07:22 am
Moin Dirk,

da ich sowas noch nie bewerkstelligt habe (und gestern nicht mehr dazu kam), sieht das dann in etwa so aus?

1. Neues WLAN am AP erstellen
2. Für das WLAN einen vLAN Tag konfigurieren
3. in der Firewall ein vLAN mit diesem Tag anlegen
4. Auf WLAN Interface ein neues Subnetz für das Gäste mit diesem vLAN anlegen
5. Fertig

?

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on January 26, 2017, 10:50:27 am
Ich habe bei der OPNSense noch kein vLAN eingerichtet, aber im Prinzip liest sich das Alles so richtig. ;)

Hängt der AP direkt an der Firewall oder hängt noch ein Switch dazwischen?
Ein evtl. Switch dazwischen müßte auch vLAN fähig sein und entsprechend konfiguriert werden! Sprich, Du musst die Ports an dem FW und AP hängen entsprechend zusätzlich zum normalen LAN auch auf das vLAN taggen!
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: guest15032 on January 26, 2017, 12:28:14 pm
Hi,

nein, der AP hängt direkt an der Firewall (am ersten LAN Port). ;)

Aber Danke für den Hinweis, falls ich das mal anders aufbauen sollte.

Gruß
Chris
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: RicAtiC on October 26, 2019, 09:00:04 am
Guten Morgen zusammen,

ich erlaube mir mal, auf diesem etwas älteren Thema "aufzusetzen", weils inhaltlich hier her gehört.

Ich bin gerade dabei mein Netzwerk auf neue Füße zu stellen. Dazu hätte ich an euch die Frage, wie ihr es in euren Netzen macht, was die Trennung angeht.

Wenn ich mal von der "Client" - Seite komme, gibt es folgende Dinge, die da so rumschwirren und ein wenig strukturiert werden sollten:

- Smart TV
- Shield
- Receiver
- Sonos
- TK-Anlage (Fritz via SIP)
- NAS
- Smartphones
- Laptops
- Staubsaugerroboter
-???

Die ersten vier würde ich über ein "Entertainment" VLAN gruppieren. Am liebsten im Nachgang gezielt für die Source-IPs (IP im internen Netz) nur URLs / Ports nach außen freigeben und zwar für jeden Client einzeln.

Bsp. :

192.168.50.3 (SmartTV) - - > URLs + Ports vom Hersteller - - > allow

Hier werde ich mich vermutlich tot administrieren, wie seht ihr das? Und vor allem, wie löst ihr es? Any Any allow und dann eher unerwünschtes blockieren?

Schmeißt ihr das ganze Entertainment Zeug in ein Netz? Zugang dann sowohl per LAN als auch WLAN

Ansonsten würde ich noch ein VLAN anlegen für TK, NAS, Interne Clients, Guest, Default & Smarthome. Wobei der Staubsaugerroboter eine gefühlte Sonderstellung hat und noch mal extra separiert gehört. Habt ihr sowas auch? Dann denk ich mir aber wiederum, mein Smartphone ist auch von einem fernöstlichen Hersteller und schwirrt dann bei den internen Clients rum, was bringts dann überhaupt.

Ihr seht, ich tue mich schwer eine gute Lösung zu finden. Mehr Schutz und Struktur ohne sich tot zu administrieren, das wäre das angestrebte Ziel.

Ich bin unendlich Dankbar für Tips und Erfahrungen.

Gruß
Ric


Gesendet von meinem LYA-L29 mit Tapatalk

Title: Re: Best practices/Standards für Heimnetzwerk
Post by: micneu on October 26, 2019, 05:34:10 pm
Hier mein Netz
(https://uploads.tapatalk-cdn.com/20191026/f5da93771ea2bdd22116cb63ee57c721.jpg)
Ich habe mein Entertainment Kram alles mit in meinem normalen lan, währe mir zu viel Aufwand das nochmal zu unterteilen


Gesendet von iPhone mit Tapatalk Pro
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: RicAtiC on October 27, 2019, 08:24:32 am
Hier mein Netz
(https://uploads.tapatalk-cdn.com/20191026/f5da93771ea2bdd22116cb63ee57c721.jpg)
Ich habe mein Entertainment Kram alles mit in meinem normalen lan, währe mir zu viel Aufwand das nochmal zu unterteilen


Gesendet von iPhone mit Tapatalk Pro
Hi micneu,

danke für Deine Antwort!

Wäre mir wiederum zu "flach", aber administrativ definitiv nachvollziehbar.

Darf ich fragen wie Du VoIP in der FB hinter der OPNSense zum laufen bekommen hast?

Hab mich hieran orientiert :
https://forum.opnsense.org/index.php?topic=4712.0

Die Nummern konnte ich mittlerweile registrieren, aber telefonieren ist noch nicht...

Kannst Du mir mir mal Deine FW-Regeln + Outbound-NAT zeigen?

Tausend Dank vorab!

Gruß Ric
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: micneu on October 27, 2019, 03:12:46 pm
moin, die telefonnummern habe ich direkt in der flitzebogens eingetragen.

(https://uploads.tapatalk-cdn.com/20191027/c86d7eea051107611d06aa70379807e0.jpg)

nur diese eine regel, bei mir läuft das so.



Gesendet von iPad mit Tapatalk Pro
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: monstermania on October 28, 2019, 11:10:10 am
Ihr seht, ich tue mich schwer eine gute Lösung zu finden. Mehr Schutz und Struktur ohne sich tot zu administrieren, das wäre das angestrebte Ziel.
Tja,
ist wie so oft Ansichtssache. Ich bevorzuge zu Hause eine eher flache Struktur.
Ich habe daher nur mein LAN/WLAN und ein Gast-WLAN. Auf Grund des weiblichen Einflusses läuft unser gesamtes Heimnetz ohnehin nur per WLAN.  ;)
Grundsätzlich sind alle Ports nach extern erstmal zu. Dazu kommen dann noch einige IP-Sperrlisten.
Die einzelnen Geräte sind dann per Alias-/Dienstgruppen reglementiert. So habe ich z.B. auf der FW 3 Portgruppen für WhatsApp. Diesen Gruppen sind dann nur die Smartphones zugeordnet. Folglich können auch nur die Smartphones WA nutzen. Ähnliches gibt es dann auch für Laptop, Tablet und Smart-TV.
Damit kann ich dann recht gut steuern, welches Gerät wohin kommunizieren darf bzw. welche Dienste genutzt werden dürfen.
Der Vorteil ist, dass alle Geräte im internen WLAN untereinander vollkommen problemlos funktionieren. Z.B. Streaming vom Tablet/Smartphone/Laptop auf das Smart-TV, usw.
Ein neues Gerät im Netz muss dann natürlich erstmal den einzelnen Gruppen zugeordnet werden, damit z.B. das Internet funktioniert oder Mails abgerufen/versendet werden können.

Das Gast-WLAN kommt natürlich nur ins Internet! Hier habe ich auch den einfachen Weg ohne Captive-Portal gewählt. Sprich unsere Freunde bekommen das WLAN-Kennwort mitgeteilt und können ins Gast-WLAN.
Ist auch kein Problem, da sich um eine sehr überschaubare Anzahl handelt.

Gruß
Dirk
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: RicAtiC on October 31, 2019, 08:32:04 pm
moin, die telefonnummern habe ich direkt in der flitzebogens eingetragen.

(https://uploads.tapatalk-cdn.com/20191027/c86d7eea051107611d06aa70379807e0.jpg)

nur diese eine regel, bei mir läuft das so.



Gesendet von iPad mit Tapatalk Pro
Keinerlei FW-Regeln nach Außen?

Oder erlaubst Du, in dem Subnet in dem sich die Fritzbox, ohnehin "any" nach Außen?

Habe 1&1 und muss die Highport Range aufmachen, damit ich was höre, oder stimmt was noch nicht?
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: RicAtiC on October 31, 2019, 08:32:51 pm
Ihr seht, ich tue mich schwer eine gute Lösung zu finden. Mehr Schutz und Struktur ohne sich tot zu administrieren, das wäre das angestrebte Ziel.
Tja,
ist wie so oft Ansichtssache. Ich bevorzuge zu Hause eine eher flache Struktur.
Ich habe daher nur mein LAN/WLAN und ein Gast-WLAN. Auf Grund des weiblichen Einflusses läuft unser gesamtes Heimnetz ohnehin nur per WLAN.  ;)
Grundsätzlich sind alle Ports nach extern erstmal zu. Dazu kommen dann noch einige IP-Sperrlisten.
Die einzelnen Geräte sind dann per Alias-/Dienstgruppen reglementiert. So habe ich z.B. auf der FW 3 Portgruppen für WhatsApp. Diesen Gruppen sind dann nur die Smartphones zugeordnet. Folglich können auch nur die Smartphones WA nutzen. Ähnliches gibt es dann auch für Laptop, Tablet und Smart-TV.
Damit kann ich dann recht gut steuern, welches Gerät wohin kommunizieren darf bzw. welche Dienste genutzt werden dürfen.
Der Vorteil ist, dass alle Geräte im internen WLAN untereinander vollkommen problemlos funktionieren. Z.B. Streaming vom Tablet/Smartphone/Laptop auf das Smart-TV, usw.
Ein neues Gerät im Netz muss dann natürlich erstmal den einzelnen Gruppen zugeordnet werden, damit z.B. das Internet funktioniert oder Mails abgerufen/versendet werden können.

Das Gast-WLAN kommt natürlich nur ins Internet! Hier habe ich auch den einfachen Weg ohne Captive-Portal gewählt. Sprich unsere Freunde bekommen das WLAN-Kennwort mitgeteilt und können ins Gast-WLAN.
Ist auch kein Problem, da sich um eine sehr überschaubare Anzahl handelt.

Gruß
Dirk

Vielen Dank für Deine Antwort!
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: mike69 on October 31, 2019, 09:37:49 pm
Ihr seht, ich tue mich schwer eine gute Lösung zu finden. Mehr Schutz und Struktur ohne sich tot zu administrieren, das wäre das angestrebte Ziel.
Tja,
ist wie so oft Ansichtssache. Ich bevorzuge zu Hause eine eher flache Struktur.
Ich habe daher nur mein LAN/WLAN und ein Gast-WLAN. Auf Grund des weiblichen Einflusses läuft unser gesamtes Heimnetz ohnehin nur per WLAN.  ;)
Grundsätzlich sind alle Ports nach extern erstmal zu. Dazu kommen dann noch einige IP-Sperrlisten.
Die einzelnen Geräte sind dann per Alias-/Dienstgruppen reglementiert. So habe ich z.B. auf der FW 3 Portgruppen für WhatsApp. Diesen Gruppen sind dann nur die Smartphones zugeordnet. Folglich können auch nur die Smartphones WA nutzen. Ähnliches gibt es dann auch für Laptop, Tablet und Smart-TV.
Damit kann ich dann recht gut steuern, welches Gerät wohin kommunizieren darf bzw. welche Dienste genutzt werden dürfen.
Der Vorteil ist, dass alle Geräte im internen WLAN untereinander vollkommen problemlos funktionieren. Z.B. Streaming vom Tablet/Smartphone/Laptop auf das Smart-TV, usw.
Ein neues Gerät im Netz muss dann natürlich erstmal den einzelnen Gruppen zugeordnet werden, damit z.B. das Internet funktioniert oder Mails abgerufen/versendet werden können.

Das Gast-WLAN kommt natürlich nur ins Internet! Hier habe ich auch den einfachen Weg ohne Captive-Portal gewählt. Sprich unsere Freunde bekommen das WLAN-Kennwort mitgeteilt und können ins Gast-WLAN.
Ist auch kein Problem, da sich um eine sehr überschaubare Anzahl handelt.

Gruß
Dirk

Vielen Dank für Deine Antwort!

Tja, hier wird es laufend mehr. :)

LAN:  Das private Grundnetz
GUESTS:    Für Gäste inkl Captive Portal
VOIP:   Für die Fritze als DECT Basis im Telekom Netz.
SECURITY:  IP-Cams zur Sicherung der Aussenanlagen wie Carport, Garage usw
MEDIA:  Alles was mit Smart TV, Sonos, MusicCast, Kodi, DLNA usw zu tun hat.
GAMING:  Für die Spielkonsolen, ist nicht notwendig, haben aber im LAN nichts zu suchen.
MGMT:  Switches, APs, USV, Host mit installiertem Unifi Controller und Freeradius.  Authentifizierung im WLAN mittels WPA2-Enterprise inkl. VLAN Zuweisung in das richtige Netz.

Das ist der aktuelle Stand. Für Privat bissl oversized, aber wenn es geht, warum nicht.
Zumindest LAN, VOIP und dieses Smart Geraffel inkl. IoT Gelumpe würde ich persönlich trennen.
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: RicAtiC on October 31, 2019, 11:31:17 pm
Ihr seht, ich tue mich schwer eine gute Lösung zu finden. Mehr Schutz und Struktur ohne sich tot zu administrieren, das wäre das angestrebte Ziel.
Tja,
ist wie so oft Ansichtssache. Ich bevorzuge zu Hause eine eher flache Struktur.
Ich habe daher nur mein LAN/WLAN und ein Gast-WLAN. Auf Grund des weiblichen Einflusses läuft unser gesamtes Heimnetz ohnehin nur per WLAN.  ;)
Grundsätzlich sind alle Ports nach extern erstmal zu. Dazu kommen dann noch einige IP-Sperrlisten.
Die einzelnen Geräte sind dann per Alias-/Dienstgruppen reglementiert. So habe ich z.B. auf der FW 3 Portgruppen für WhatsApp. Diesen Gruppen sind dann nur die Smartphones zugeordnet. Folglich können auch nur die Smartphones WA nutzen. Ähnliches gibt es dann auch für Laptop, Tablet und Smart-TV.
Damit kann ich dann recht gut steuern, welches Gerät wohin kommunizieren darf bzw. welche Dienste genutzt werden dürfen.
Der Vorteil ist, dass alle Geräte im internen WLAN untereinander vollkommen problemlos funktionieren. Z.B. Streaming vom Tablet/Smartphone/Laptop auf das Smart-TV, usw.
Ein neues Gerät im Netz muss dann natürlich erstmal den einzelnen Gruppen zugeordnet werden, damit z.B. das Internet funktioniert oder Mails abgerufen/versendet werden können.

Das Gast-WLAN kommt natürlich nur ins Internet! Hier habe ich auch den einfachen Weg ohne Captive-Portal gewählt. Sprich unsere Freunde bekommen das WLAN-Kennwort mitgeteilt und können ins Gast-WLAN.
Ist auch kein Problem, da sich um eine sehr überschaubare Anzahl handelt.

Gruß
Dirk

Vielen Dank für Deine Antwort!

Tja, hier wird es laufend mehr. :)

LAN:  Das private Grundnetz
GUESTS:    Für Gäste inkl Captive Portal
VOIP:   Für die Fritze als DECT Basis im Telekom Netz.
SECURITY:  IP-Cams zur Sicherung der Aussenanlagen wie Carport, Garage usw
MEDIA:  Alles was mit Smart TV, Sonos, MusicCast, Kodi, DLNA usw zu tun hat.
GAMING:  Für die Spielkonsolen, ist nicht notwendig, haben aber im LAN nichts zu suchen.
MGMT:  Switches, APs, USV, Host mit installiertem Unifi Controller und Freeradius.  Authentifizierung im WLAN mittels WPA2-Enterprise inkl. VLAN Zuweisung in das richtige Netz.

Das ist der aktuelle Stand. Für Privat bissl oversized, aber wenn es geht, warum nicht.
Zumindest LAN, VOIP und dieses Smart Geraffel inkl. IoT Gelumpe würde ich persönlich trennen.
Bin da völlig bei Dir.

Danke fürs teilen!

Ich seh das alles auch als Invest in die Zukunft, weniger IT-Equipment wirds definitiv nicht. Je eher man da sicherheitstechnisch vorsorgt, je besser.

Is halt auch Arbeit... :)
Title: Re: Best practices/Standards für Heimnetzwerk
Post by: JeGr on November 28, 2019, 03:37:01 pm
Oh ja, das ist schon einiges an Arbeit. Und ob man sich die zu Hause machen möchte ist auch immer so ein Ding... ;)

Manchmal klappts beim Neubau besser (oder überhaupt mal). Hab das leider noch nicht in Blogform packen können, deshalb hier nur als Rohform aus dem anderen Forum:
https://forum.netgate.com/topic/146555/infotainment-netzwerk-neubau-mit-pfsense-und-unifi

Aber die meisten Punkte die da *sense mäßig anfallen, sind mit beiden Varianten machbar.

Grüße