Heimnetzwerk sicher machen mit DMZ, VLAN und Firewall

[Mettigel]

Hallo zusammen,

nachdem mir im anderen Thread so viel geholfen wurde mache ich mal einen eigenen Thread zu dem Thema auf. Habe bereits genug OT beigesteuert.

VLAN für IoT hatte ich bereits. Alle Geräte durften unbeschränkt ins Internet, nicht aber in die anderen VLAN.
VLAN für Kamera hatte ich bereits. Dieses VLAN durfte nur von meinem Haupt-VLAN angesprochen werden, kein Internet oder sonstige Verbindungen erlaubt.

Gelernt habe ich, dass PiHole auch über verschiedene VLAN ohne Einschränkungen funktioniert (nicht wie bei doppelten NAT).
Aktuell versuche ich alles DNS-Anfragen außer vom PiHole zu blockieren. Nach meiner Logik müsste die Regel ins WAN OUT, aber dort funktioniert sie nicht. Im LAN IN funktioniert die Regel aber schon. Meine Firewall ist die UDM Pro.

Der Plan war außerdem verschiedene VLAN für IoT mit und ohne Cloudzwang zu erstellen (online und offline VLAN). Da ich nur 4 SSID zur Verfügung habe, habe ich mich gegen diese Lösung entschieden. Ich habe alle Geräte, für welche es keinerlei Grund gibt online zu sein einfach in der Firewall geblockt. Das sollte ausreichend sein. Inwiefern ich noch Geräte ins IoT-VLAN verbanne werde ich die nächsten Tage entscheiden.

Für Airplay gibt es wohl mDNS, welches man zwischen den VLANs erlauben müsste, aber da habe ich mich noch nicht beschäftigt.

 

[Mettigel]

@NSFH: "Wer hat dir denn den Bären aufgebunden, dass VLAN über den Router/Firewall laufen müssen?" --> wenn das nur über den Switch laufen soll, bräuchte man dann nicht einen Layer 3 Switch?

@blurrrr: eine WAN IN Regel verhindert ja nur, dass Antworten von "draußen" rein kommen. Ich hätte vermutet ich muss die Anfragen noch vor dem Verlassen meines Netzes blockieren

 

[blurrrr]

Mein Statement zu der IN-Geschichte bezog sich eher generell auf die typischen SoHo-Router ?

EDIT: Im Grunde genommen dreht es sich auch alles nur um 3 Regeln:

1) Erlaube allen (oder spezifischen) Clients (oder Netzwerken) die Verbindung zum piHole (intern)
2) Erlaube dem piHole die Verbindung zu einem public-DNS (extern)
3) Verbiete allen anderen sämtlichen DNS-Verkehr (extern)

Wenn Du schon Regeln hast, musst Du auch dafür sorgen, dass die neuen Regeln über den alten stehen, z.B.:

1. Alles ausgehende erlauben
2. DNS blockieren

Wird so vermutlich nicht funktionieren, da die Regeln normalerweise von oben nach unten abgearbeitet werden. Erste Regel greift, daher müsste es dann so aussehen:

1. DNS blockieren
2. Alles ausgehende erlauben

Von daher meinte ich vorhin schon, ob da nicht ggf. noch eine alte Regel "drüber" sitzt (die Deine neue eben zunichte macht)

 

[Mettigel]

in meiner Firewall gibt es bei WAN OUT keinerlei Regeln, die automatisch angelegt werden. D.h. es sind ja auch sämtliche Ports nach außen offen.
Bei WAN IN gibt es zwei Standardregeln: allow established/related und drop all.

 

[blurrrr]

WAN IN Regeln besagen:

1) Bereits aufgebaute Verbindungen sind erlaubt (also kurzum: "lass die Antworten auch wieder rein")
2) Alles unangefragte -> schmeiss weg

WAN OUT sollte aber theoretisch was sein, denn irgendeine Regel muss es ja geben, welche den Clients den Ausgang ermöglicht?

https://help.ui.com/hc/en-us/articles/115003173168-UniFi-UDM-USG-Introduction-to-Firewall-Rules#2

• WAN In Applies to IPv4 traffic that enters the WAN (ingress), destined for other networks (default drop).
• WAN Out Applies to IPv4 traffic that exists the WAN (egress), destined for other networks (default accept).

Das erklärt es vielleicht... Ist jetzt nur noch die Frage, ob/wie man dieses Standardverhalten weg bekommt (muss dann halt ggf. durch eine eigene Regel ersetzt werden, wenn manuell erstellte Regeln nicht automatisch "davor" greifen). Ich persönlich verzichte immer gern auf sämtliche Automatismen dabei und erstell lieber ein paar Regeln mehr von Hand.

 

[mb01]

@NSFH: "Wer hat dir denn den Bären aufgebunden, dass VLAN über den Router/Firewall laufen müssen?" --> wenn das nur über den Switch laufen soll, bräuchte man dann nicht einen Layer 3 Switch?

Ja, zumindest wenn der Traffic zwischen VLANs nicht über den Router laufen soll, sondern gleich am Switch "sortiert" werden soll. L3 Switches sind aber wohl eine Extra-Baustelle hinsichtlich Management/Hardware und da sollte man sich überlegen, ob man wirklich so viel an Traffic zwischen VLANs hat, dass das die Verbindungen Router-Switch(es) nennenswert negativ beeinflusst werden.

 

[Benares]

Ich hatte lange beruflich mit Firewall-Regelwerken für Automatisierungsnetze in Industrieanlagen zu tun. Da wurden die OUT-Regeln genauso streng gehandhabt, wie die IN-Regeln.

Klar, im SOHO-Bereich konzentriert man sich meist nur auf die IN-Regeln. Wenn man aber anfängt, auch über OUT-Regeln nachzudenken, sollte man sich m.E. schon etwas mehr Gedanken machen, als nur über die Filterung bestimmter DNS-Auflösungen nachzudenken. Klar wird das ganz schön mühsam, wenn man bedenkt, mit wem so ein "Heimnetz" alles so "quasseln" können sollte ?. Die technische Umsetzbarkeit (möglichst mit den gängigen SOHO-Routern) ist dann nochmal eine ganz andere Frage.

Setzt euch mal hin und überlegt euch, welche OUT-Regeln für so ein typisches "Heimnetz" alle so notwendig wären. Da wird bestimmt eine Menge zusammenkommen. Die Diskussion würde mich auch interessieren

 

[Puppetmaster]

Bei VLANs habe ich immer folgende (Denk)Blockade: alle IoT Geräte im Netz sollen sich ein VLAN teilen. Dabei ist aber z.B. TV oder Raspi, welcher Zugriff auf die DS benötigt (Streaming). Also muss die DS doch auch immer in dieses VLAN. Von aussen möchte ich die DS erreichen. Das bringt mir so doch gar nichts, oder?

 

[blurrrr]

DNS und Proxy wären schon mal 2 Baustellen (alles andere darf nicht raus) ?

@Puppetmaster Die DS muss nicht in dieses VLAN - das läuft dann alles über's Routing über (mitunter diverse) Netze hinweg. Kleines Beispiel (ohne "mehrere" Netze)...:

LAN -> Nur SMB/CIFS (ggf +Mailports, oder was sonst noch so zum "Gebrauch" benutzt wird)
Multimedia -> Streaming-Protokolle + ggf. SMB/CIFS/was auch immer Du da brauchst
Management -> DSM+SSH
Extern -> ReverseProxy -> Syno (im besten Fall natürlich nur via VPN und das am besten auch direkt über die Hardware-Firewall, dann kann man auch direkt Regeln zwischen VPN-Client-Netz/-User und Syno setzen)

Mit vorgeschalteten Firewall-Regeln auf der Hardware-Firewall kommt auch direkt mal weniger Müll an der Syno an, womit diese dann auch wieder entlastet wird.

EDIT: Das mit der Selbstkastration muss man allerdings auch erstmal fleissig üben und man muss sich selbst auch kritisch hinterfragen, denn oftmals gewinnt auch einfach nur die Faulheit (grade die ist eigentlich das Hauptproblem, denn alles andere macht schon einen Haufen Arbeit ).

 

[whitbread]

Jetzt wird es hier ein wenig kompliziert; Ich möchte daher nur zwei Themen aufnehmen:
1. DNS: Richtig ist, dass alle primär den PiHole nutzen sollten. Um Abweichler aufzuspüren hilft entweder eine Blockierungsregel oder alternativ eine NAT-Regel, die sämtlichen UDP-53-Traffic umleitet. Was man damit nicht erfasst sind DoH-Zugriffe - die lassen sich nur durch eine Firewall mit SSL-Interception herausfiltern.
2. Inter-VLAN-Routing: Imho sollte der Switch die VLAN-Segmentierung übernehmen und der Router das Routing zwischen VLANs. Es gibt Geräte, die beides gut können; bei Mikrotik aber nicht - daher meine Sicht.
3. Netzwerksegmentierung: Ja - mit zunehmender Anzahl und Funktionalität im Heimnetz wird die Trennung problematisch; da hilft nur eine weitere NAS bzw. Virtualisierung. Also eine NAS, die von aussen erreichbar sein soll, muss in die DMZ. Geräte die darauf bspw. per DLNA Zugriff benötigen, landen dann im gleichen Netz. Und zack braucht es eine weitere NAS mit den privaten Daten im LAN. Ggf. muss man das Konzept etwas aufweichen und den Zugriff auf einzelne Dienste aus einzelnen VLANs einschränken. Nach den aktuellen Erfahrungen sollte man halt sicherstellen, dass ein administrativer Zugriff auf die NAS (SSH, DSM in jedem Falle) nur aus trusted VLANs möglich ist.

 

[blurrrr]

Definiere "trusted"... denn genau dort fangen die Probleme nämlich schon an... (und nu schieb mir mal keiner den ganzen Rotz auf die IoT-Dinger, die bewegen sich nämlich nicht "sorglos" durch's Netz, das sind immer die User - kurzum: User-Netz -> untrusted ?). Aber bevor wir hier bei Mangement-Netzen und Bastion-Hosts landen... lass ich das einfach mal so stehen ?

Was die Sache mit dem aufbrechen der SSL-Verbindungen angeht... klar, kann man machen... Sollte man aber bei Besuch und Co. tunlichst vermeiden, da sowas dann "theoretisch" schon strafbar ist... ausser man sagt den Leuten vorher, dass die verschlüsselten Verbindungen aufgebrochen werden und man alles mitliest (lässt man sich das sicherheitshalber auch noch unterschreiben). In großen Konzernen übrigens seit Ewigenkeiten Gang und Gebe... unterschreibt man normalerweise auch (irgendwo in diesem Berg von Dokumenten die man unterschreiben muss bei Jobbeginn) ??

EDIT: Viele AV-Lösungen machen das inzwischen übrigens auch schon

 

[whitbread]

Naja - trusted im Sinne von ioBroker, Netradio, TV, bspw. braucht keinen administrativen Zugriff auf die NAS. Das es auch Deinen PC erwischen kann, ist natürlich richtig, aber von einem Gerät muss man ja die Administration machen. Daher bleibt eben der Rat richtig ein Offline-Backup zu haben.

Ich mache derzeit auch keine SSL-Interception und behelfe mir noch mit Listen für DoH-Server, aber die werden massiv zunehmen, da ja auch die Werbeindustrie gemerkt hat, dass man so die DNS-Sperren aushebeln kann. Im lokalen Firefox kann ich das noch konfigurieren, einzelne Apps kann ich aber nicht mehr kontrollieren.
Mein Gastnetzwerk hängt ganz aussen und wird derzeit gar nicht gefiltert, Routing erfolgt aber über Freifunk, so dass ich da auch nix filtern muss. Ich denke aber derzeit tatsächlich über einen DNS-basieriten Familienfilter auch fürs Gastnetzwerk nach, da unsere Gäste zunehmend in ein gewisses Alter kommen.

 

[Mettigel]

Für Geräte, die nichts im Internet verloren haben habe ich jetzt eine Gruppe erstellt. Dadurch ist es einfacher, wenn weitere Geräte hinzukommen.

Es gibt zwei Regeln: Drop all in WAN IN und Drop all in WAN OUT

Sollte man noch weitere Dinge für diese Gruppe beachten? Spielt es eine Rolle, in welchem VLAN diese Geräte sind, wenn sie sowieso nicht ins Internet können?

 

[blurrrr]

IoT knackt PC (oder sonstwas) und holt sich darüber die Internetverbindung? Nur mal so als kleines Beispiel... Grade bei größeren Infektionen (durch mehrere Netze, etc.) "muss" sich das Ding selbst am Leben halten und da sind auch gerne alle Mittel recht, selbst wenn es ein on-the-fly-Routing über mehrere komprimitierte Geräte ist (teils sogar mit mehreren Fallback-Routen, falls mal irgendwo was bereinigt wird).

 

[faxxe]

..... behelfe mir noch mit Listen für DoH-Server,

Hi whitebread,

hast du da eine Bezugsquelle? Würde ich gerne in meinen Mikrotik Router laden

Danke vorab,
faxxe

 

[blurrrr]

Wie wäre es mit: https://dnsprivacy.org oder auch einfach https://de.wikipedia.org/wiki/DNS_over_HTTPS#Öffentliche_DNS-Server ?

 

[Mettigel]

Habe mir mal die Logs angeschaut. Sind diese ALIEN BLOCK das normale Hintergrundrauschen des www? Lt. diversen Google-Ergebnissen kommen diese Anfragen gar nicht bis zur Firewall, sondern werden vorher blockiert. Das waren auf nen halben Tag um die 1.000.

 

[blurrrr]

Jo das ist "ganz normal". Sobald man sich mal "etwas" mit diesem Thema beschäftigt, wird man sehr schnell auf sowas stossen (und Du hast vermutlich nur "eine" öffentliche IP ). Irgendwelche dummen Scans rennen eh im Sekundentakt vor die Firewall und die Dinger von Dir sind wohl eh schon "bekannte" schädliche Hosts, die eh schon instant weggeschmissen werden (weil sie vorher schon auffällig waren und auf entsprechenden Listen gelandet sind).

 

[Mettigel]

Nutzt ihr Geoblocking? Ich habe jetzt mal nur Incoming aus Deutschland erlaubt. Darf ich halt nicht vergessen zu ändern, wenn ich unterwegs bin.

 

[blurrrr]

In Bezug "auf"? Geoblocking "kann" (nicht "muss") schon viele Probleme verursachen... Windows-Updates, AV-Updates, etc. Wenn es rein auf die Syno bezogen ist und man sich selbst eh nur in Deutschland aufhält, dürfte das schon ok sein (wobei die IP-Zuordnungen auch nicht "immer" ganz eindeutig sind). Ansonsten halt die schönere Variante - VPN.

EDIT: Glatt die Antwort auf die eigentliche Frage vergessen... ? Ja, teilweise bzw. nur für bestimmte Systeme, wo sowas auch problemlos funktioniert (Regel: nur Deutschland). Ansonsten sind Russland und China komplett gesperrt.