Hallo,
für das Familiennetzwerk zuhause zerbreche ich mir den Kopf, ob/wie ich hier durch Subnetze mehr Sicherheit ins Spiel bringen kann. Gerne würde mich eure Meinung hierzu interessieren. Stand der Dinge:
1. Gast Netzwerk dass nur nach ins WAN funken darf. Da sind auch die PCs der Kinder drin und deren Handys.
2. LAN Netzwerk mit NAS, Smart TV, Handys, PCs, WLAN-Steckdosen, sowie einem Raspberry sowohl als Heimautomationsserver und DNS-Server. NAS ist auch aus dem WAN erreichbar (SSH + Netxcloud).
Der Vorteil, alles im LAN Netzwerk zu haben ist, dass ich Bilder vom Handy auf dem Smart TV zeigen kann, sowie von allen Geräten (inkl. Smart TV und Handys) jederzeit über SMB auf Bilder und Videos der NAS zugreifen kann. Und mit jedem Handy und PC kann ich durch Zugriff auf den Raspberry Dinge im Haus steuern.
Das NAS und den Raspberry in ein separates Netzwerk zu stecken bringt vermutlich nicht viel, da ich auf die dort laufenden Dienste von allen Geräten aus zugreifen muss? Ich könnte höchstens die Handys (Wlan) und PCs in separaten Netzwerken unterbringen, sehe aber den Sicherheitsgewinn auch nicht so richtig. Bleiben nur die Geräte der Heimautomation, auf die ein direkter Zugriff mit PC/Handy/SmartTV nicht nötig ist.
Was übersehe ich? Ist eben ein ungutes Gefühl. Zu viele Einfallstore von außen, und keine Absicherung.
Muss der NAS direkt aus dem Internet erreichbar sein?
Den per zusätzlicher Authentifizierung (HAProxy) oder VPN abzusichern, würde schon einen großen Gewinn bringen.
Damit hättest du die Tür von Außen schon mal geschlossen.
Hallo, ja muss. Über Nextcloud werden Adressbücher synchronisiert, Bilder innerhalb der weiten Familie verteilt usw... NAS in ein eigenes Netzwerk könnte den Vorteil haben, dass wen das NAS gehackt ist ein weiterer Zugriff auf PCs usw. nicht möglich ist. Das ist aber auch schon alles.
Quote from: meschmesch on November 26, 2021, 11:01:42 AM
Hallo, ja muss. Über Nextcloud werden Adressbücher synchronisiert, Bilder innerhalb der weiten Familie verteilt usw...
Ist ja kein Grund gehen eine zusätzliche Authentifizierung, erhöht ja nicht nur die Sicherheit deines restlichen Netzwerkes, sondern auf der Daten auf deinem NAS.
Gerade bei NAS Geräten hört man ja des öfteren von irgendwelchen Sicherheitslücken, wovon du die meisten einfach nicht aktiv nutzbar machst, wenn das Gerät nicht direkt im Internet hängt.
Quote
NAS in ein eigenes Netzwerk könnte den Vorteil haben, dass wen das NAS gehackt ist ein weiterer Zugriff auf PCs usw. nicht möglich ist. Das ist aber auch schon alles.
Das wäre ein guter Plan. Und für viele Dienste welche per Brodacast arbeiten, sollte der IGMP Proxy funktionieren.
Also NAS in ein eigenes Netzwerk, Heimautomation + DNS Server in ein eigenes Netzwerk, Handys + SmartTV in ein eigenes Netzwerk, PCs in ein eigenes Netzwerk, Gästenetzwerk. ??? ::)
Du kannst am Ende auch für jedes Gerät ein eigenes Netzwerk schaffen :D
Würde ehr
LAN: PC, Handys, SmartTV
Gast: alle Geräte die nur stumpfes Internet brauchen
DMZ: NAS Speicher
DNS Server auf der OPNsense
Trennung in LAN und IoT/SmartTV/sonstiger Müll, bei dem das Betriebssystem nicht deiner Kontrolle unterliegt is m.E. immer sinnvoll.
Ich habe ein eigenes Netz für Windowsschrott und andere Betriebssysteme (kein Android/Apple, die würde ich ehr zu Windows packen, da können sie sich dann gegenseitig "telemetrisieren")
Perfekt, das hilft schon mal. Danke für Euren Input!!!
Ach noch eine Frage, "DNS auf Opnsense". Opnsense kann aber nicht pihole. Ich möchte aber denselben Schutz über Filterlisten wie bei pihole. Von dem her?
AdGuard Home?
Ist installiert. Und tut, allerdings nicht so wie es soll. Ich habe hier (auch) testweise High Availability am Laufen, d.h. das LAN-Interface hat neben seiner normalen statischen Adresse 192.168.2.2 auch eine CARP-Adresse 192.168.2.1. AdGuard tut, wenn ich als Server die 2.2 angebe, jedoch nicht für die 2.1 (obwohl in Adguard als listening interface auch die 2.1 angegeben ist).
dig google.de @192.168.2.1
;; reply from unexpected source: 192.168.2.2#53, expected 192.168.2.1#53
Habt ihr eine Lösung dafür?
Das Problem ist, dass AdGuard die Replies in dem Fall von der falschen Adresse schickt. Da hilft, AG auf 127.0.0.1 und z.B. 53530 laufen zu lassen und Unbound oder BIND dorthin weiterleiten zu lassen.
Oder Du bastelst was mit NAT - Portforwarding für die Requests, Outbound für die Replies.
Ich hab da ein Bug Ticket bei AG aufgemacht, aber das Problem liegt wohl an der Golang-Implementierung für FreeBSD.
Gruß
Patrick
Port Forward von der Carp-Adresse auf die feste LAN-IP hat ausgereicht. Nun tut es. Schlecht ist eben, dass auf der Backup-Firewall die Regel anders aussehen muss (Carp auf die dortige andere feste LAN-IP). Damit scheidet zukünftig ein Sync der Firewall-Regeln aus.
Quote from: meschmesch on November 27, 2021, 12:11:05 PM
Port Forward von der Carp-Adresse auf die feste LAN-IP hat ausgereicht. Nun tut es. Schlecht ist eben, dass auf der Backup-Firewall die Regel anders aussehen muss (Carp auf die dortige andere feste LAN-IP). Damit scheidet zukünftig ein Sync der Firewall-Regeln aus.
Wie wäre es mit Port Forward (oder NginX stream server UDP) auf 127.0.0.1?
Localhost geht nicht?! Muss ich unter Outbound NAT für diesen Fall noch etwas Spezielles einstellen?
Ein weiteres Problem ist, dass z.b. vom Gast interface 176.1 DNS Auf 2.1 nicht funktioniert. Ich habe testweise alle Ports vom Gast Interface auf Lan freigegeben, Ping funktioniert aber DNS funktioniert nicht. Was fehlt?
Du brauchst auch im Gast-Netz so ein Portforwarding und musst dort die entsprechende Adresse der OPNsense als DNS-Server benutzen. Sonst kommen die Antworten wahrscheinlich wieder von der falschen Adresse.
tcpdump hilft ...
PortForwarding von 176.1 auf 176.2 geht (.1 ist die Carp-Adresse, .2 die statische IP). Also DNS auf 176.1 liefert die Antwort von der richtigen IP:
igb2 09:59:26.400790 IP 192.168.176.143.51683 > 192.168.176.1.53: UDP, length 25
igb2 09:59:26.401022 IP 192.168.176.1.53 > 192.168.176.143.51683: UDP, length 52
Localhost geht nicht:
igb2 10:00:25.655542 IP 192.168.176.143.3269 > 192.168.176.1.53: UDP, length 25
igb2 10:00:25.655767 IP 192.168.176.2.53 > 192.168.176.143.3269: UDP, length 52
Da kommt die Antwort von 176.2.
Wie gesagt das ist doof, weil man damit keine Synchronisation der Firewall-Regeln, NAT Regeln zwischen HA-Firewalls machen kann. :-\
Und wenn Du zusätzlich die Antwortpakete mit Outbound NAT zurechtbiegst?
Funktioniert nicht, Outbound-Nat: igb2 Interface, source 176.2/32, NAT address 176.1, Source port 53.
Ergebnis ist, dass in tcpdump keine Antwort mehr auftaucht. Es gibt nur noch den request auf die 176.1, danach Schweigen bezüglich DNS.
Blöd. Aber dann kann ich Dir mit AdGuard an der Stelle nicht helfen. Da wo ich HA habe, habe ich BIND auf 127.0.0.1 und Portforwarding CARP-TCP/UDP:53 --> 127.0.0.1:53. Das funktioniert, da kommen auch die Antworten richtig.
Also bei Dir läuft die DNS-Anfrage von BIND nach AG? Bei mir andersrum, nur eben mit unbound. Damit kann ich über unbound DOT machen.
Nö. Bei mir läuft @work überall nur BIND und kein AdGuard. Wir bauen Websites. Meine Entwickler versichern mir, dass ein Werbeblocker zwar aus ihrer Sicht nett wäre, sie aber dummerweise Werbenetze in die Websites der Kunden einbauen und testen müssen.
BIND kann aber problemlos mit einem Upstream-Server arbeiten, daher mein Vorschlag.
Hier zuhause läuft BIND auf 127.0.0.1. Alle Interfaces, die irgendwas mit Infrastruktur machen, haben ein Portforwarding direkt zum BIND. Im Familien-Surf-and-Play-Netz lauscht der AdGuard direkt auf :53 und der forwarded dann an den BIND.
Ich hab hier privat aber auch keine HA.
Nochmal Kurzfassung: BIND funktioniert bei mir mit HA. BIND kann einen "Forwarder" == Upstream Server. Daher mein Vorschlag, das doch mal so zu testen.
:o Ok, die nachfolgend beschriebene Kette ist etwas übertrieben, aber zum Testen tut's das ;D
- Port Forward Gast Netz ...176.... Port 53 auf 127.0.0.1:53530 - drauf läuft BIND
- Bind hat als DNS Forwarder AG eingetragen, und zwar eine der CARP-Adressen .1
- AG macht Forwarding auf unbound
Ergebnis, es geht, aber laaaangsam. 2,5s Antwortzeit und mehr. Macht keinen Spaß.
Warum hast Du da jetzt noch den Unbound im Spiel? Du hast schon einen Nameserver mit allen Features - Resolver und Authoritative - in BIND, und einen Spam-Blocker in AdGuard Home. Nimm den Unbound doch da raus - ich hab den auch nirgends.
DNS over TLS? Kann eigentlich auch Adguard selbst, stimmt.
tls://1.1.1.1:853 z.B. als Server.
Noch eine Kuriosität. Es gibt bei mir Geräte im LAN, die habe ich für die Kommunikation nach außen gesperrt (China und so...). Allerdings schaffe ich es nicht, DNS-Anfragen an AdGuard zu unterbinden. Selbst wenn ich MAC und IP explizit im LAN-Netz sperre, gehen die DNS-Anfragen an AdGuard durch.
...wobei ich gerade feststelle, dass das mit BIND kein "Problem" mehr darstellt. Weil dann nämlich in AdGuard sämtliche Anfragen als von localhost her stammend erscheinen und überhaupt keine Unterscheidung mehr möglich ist, woher welche Anfrage kam. Also Source Host Auflösung scheidet mit BIND aus?
Kurze Zusammenfassung. Unbound wird nicht verwendet. Und ich habe mich gegen BIND entschieden, da dadurch in AdGuard (AG) alle Anfragen als von localhost zu kommen scheinen. Damit habe ich keinen Überblick mehr, wer was im Netzwerk macht. Da außerdem das Problem ist, dass ich DNS-Anfragen diverser LAN-Geräte warum auch immer nicht verhindern kann, ist die Möglichkeit zumindest in AG gegeben, manuell zu sperren "Nicht zugelassene Clients".
AG hat als DNS-Server und Bootstrap:
tls://1.1.1.1:853
tls://1.0.0.1:853
tls://[2606:4700:4700::1111]:853
tls://[2606:4700:4700::1001]:853Opnsense 1:
- Port-Forward für jedes Interface zum Umschreiben der DNS Anfragen von der CARP-Adresse auf die statische IPv4 Adresse des Interface
- Ein AdGuard-Alias für alle CARP-Adressen und die IPv4 Interface Adressen
- Port Forward für jedes Interface von allen Anfragen, welche nicht vom AdGuard-Alias stammen und nicht an den AdGuard-Alias gerichtet sind, auf die die statische IPv4 Adresse des Interface (damit wird verhindert, dass Clients AdGuard umgehen)
- Entsprechende Firewall-Regeln anlegen
Opnsense 2:
Hier dasselbe, allerdings müssen die IPv4 Interface Adressen ausgetauscht werden gegen die Interfaces von Opnsense 2.
Auf allen Opnsenses bei DHCP jeweils die Interface CARP-Adresse als DNS Server angeben. Unter General-Settings habe ich die jeweilige reale LAN-Interface-Adresse noch zusätzlich als DNS-Server hinterlegt - ansonsten funktionieren DNS-Anfragen z.b. für Updates bei der Firewall nicht, die gerade im Backup-Modus ist.
Danke nochmals an den geduldigen Support :)