Aufbau und Struktur von Firewallregeln

[Frank73]

Hallo zusammen,

aktuell beschäftige ich mich damit, meine Firewall auf der Syno zu aktivieren und mit entsprechenden Regeln zu versehen. Habe auf VMM mit VDSM schon etwas probiert (auch mit IPv6). Bevor ich das aber produktiv einsetzen möchte, wären da noch ein paar Fragen an die Experten.

Was nutze ich auf der Syno:
Aktuell 3 Dockercontainer
DNS-Server der Syno (soll evtl. abgelöst werden durch AdGuard Home [auch über Docker]) in folgender Konstellation: Clients --> DNS-Server Syno --> Fritzbox
Zugriff der PCs / Laptops / Pis (alle mit statischer IP) über SMB
Pakete: HyperBackup, Cloud-Sync, Snapshots ...
Mehr fällt mir im Moment nicht ein

Was möchte ich?
Eine saubere Struktur der Regel um eine bessere Übersicht und eine komfortable Administration zu haben.
Die unterschiedlichen PCs, Laptops ... sollten nur auf die Anwendungen Zugriff bekommen, welche auch benötigt werden (sofern dies sinnvoll ist).

Erste Ideen (in dieser Reihenfolge würde ich auch die Regeln setzen):
Der "Haupt-PC" (Mint) erhält Zugriff auf alles, damit notfalls immer ein Zugriff auf das NAS möglich ist
Die PCs / Laptops der restlichen Familienmitglieder bekommen nur Zugriff auf das Webinterface des DSM und den Zugriff per SMB
Die Pis erhalten nur Zugriff über SMB
Das komplette Heimnetz erhält Zugriff auf den DNS-Server damit alle Geräte ins Internet kommen (Fritzbox verteilt per DHCP die DNS für IPv4 und IPv6)
Der Rest wird alles verboten (Handys und Co haben auf dem NAS nichts zu suchen!?)

Und hier wären auch schon die ersten (und mit Sicherheit nicht die letzten) Fragen:

1) Ist es strukturell besser, für die einzelnen Geräte auch den DNS-Dienst mit aufzunehmen (statt nur SMB und DMS) oder sollte dies über eine separate Regel für alle abgedeckt werden.
2) Wenn 1) = separate Regel, müsste dies dann die 1. Regel sein?
3) Bei der Anwendung DNS gibt es z. B. 2 Einträge einen mit Port 53 und einen mit Port 53535. Was ist an dieser Stelle zu verwenden?
4) Ich meine irgendwo gelesen zu haben, dass bei Nutzung von Docker die IPs 172.... auch über Regeln mit freizugeben sind. Warum, und welche Ports müssen da freigegeben werden?

Weiterhin möchte ich das ganze auch mal (zumindest testweise für IPv6) durchspielen. Ich habe ja das Problem, dass ich keine statiche IPv6 habe und somit (bei Nutzung von Privacy Extension) mit der ULA nicht viel in der Firewall anfangen kann.
Frage noch dazu:
Ist es möglich und sinnvoll statt der ULA die LLA in der Firewall zu verwenden?
In etwa so: Das NAS (ohne PE) hat eine feste ULA und somit kann diese bei den Regeln verwendet werden, während ein Smartphone auf Grund PE einen wechselnden ULA-Identifier hat und somit wird in der Regel die unveränderliche LLA verwendet.

Danke für Ausführungen und ein schönes Restwochenende.

Gruß
Frank

 

[blurrrr]

Hi,

1) Eine Regel, welche mehrere Dinge beinhaltet, kann man durchaus anlegen, das ist dann eben der "Standard" für alle.
2) Nein, die erste Regel ist die "Sperr Dich nicht aus!"-Regel, vgl.:

Der "Haupt-PC" (Mint) erhält Zugriff auf alles, damit notfalls immer ein Zugriff auf das NAS möglich ist

3) Port 53
4) Thema Docker:

Ich meine irgendwo gelesen zu haben, dass bei Nutzung von Docker die IPs 172.... auch über Regeln mit freizugeben sind.

Nö. Ports reichst Du da auch nur "durch" (wie bei einer Portweiterleitung), die Ports bestimmt Du - je nach Anwendung - selbst.

 

[blurrrr]

Da ich grade gesehen habe, dass Du auch noch in einem anderen Forum gepostet hast (etwas andere Thematik)... Schau Dir erstmal den Unterschied zwischen einem "Resolver" und einem "Nameserver" an. Auf der Syno läuft ein "bind9" (klassischer Nameserver). pi-Hole/Adguard sind (meines Wissens nach) lediglich Resolver (welche mitunter den Resolver-Cache manipulieren). Schau einfach mal bei Wikipedia, da werden die Unterschiede zwischen Resolver und Nameserver erklärt: https://de.wikipedia.org/wiki/Domain_Name_System#Komponenten

 

[Frank73]

Danke für die Infos. Da werde ich mich mal die Tage dran machen und die Firewall einrichten.

Zu der anderen Thematik: Mir war nicht bewusst, dass AdGuard ein Resolver ist. Ich dachte, dass dieser auch ein "vollwertiger" DNS-Server darstellt.

 

[Frank73]

Könntest du mir noch bzgl. der Thematik IPv6 aus dem Post #1 deine kurze Einschätzung geben ob das so sinnig und umsetzbar ist?

 

[blurrrr]

Das gleiche gilt z.B. auch für "unbound", steht sogar auf deren Seite...

Unbound is a validating, recursive, caching DNS resolver.

... aber das nur mal so am Rande.

Bzgl. IPv6... Hab da eigentlich eher weniger mit zu tun. Da meine Syno auch als DNS für die meisten Clients im Netz agiert, spreche ich sie diesbezüglich mit einer ULA (fd00) an. Diesen ganzen Privacy-Kram habe ich auch nirgendwo aktiviert. Ansonsten nutze ich IPv6 anderweitig auch eher nur statisch.

Das mit der LLA... da wäre mir nicht bewusst, dass die statisch ist. Deswegen bin ich bei mir in Sachen interner statischer IPv6 auch auf die ULA (fd00) gegangen. Vielleicht schauste nochmal hier rein: https://www.elektronik-kompendium.de/sites/net/2107111.htm. Alternativ - weiss ja nicht, was Du ggf. für Möglichkeiten hast - könnte man eventuell auch schlichtweg getrennte Netze nehmen und die Regeln anhand der Netz-IDs festmachen. So habe ich es zumindestens hier gemacht, hier läuft aber auch noch eine Hardware-Firewall, welche dann div. Netze (via LAN/WLAN) bereitstellt. Regeln für einzelne Geräte gibt es hier "garnicht", sondern immer nur für Netze.

 

[Frank73]

Danke für deine Inputs.

Meine Möglichkeiten sind aktuell sowohl technisch, aber auch fachlich in Teilen noch eingeschränkt, da ich mein Heimnetz nur nebenbei als Hobby betreibe (dennoch technisch wie fachlich sehr interessiert bin). Dennoch macht das Lernen durch solche Foren auch Spass, da man doch schnell und kompetent Hilfe bekommt. Danke mal dafür an alle!!

 

[Barungar]

Die IPv6 LLA taugt dafür nicht. Diese Adresse hat im Prinzip hauptsächlich interne Funktionen im IPv6, sie kann zwar theoretisch auch einen Nutzerdatenverkehr führen, aber dafür ist sie nicht wirklich konzipiert. Vorallem ist die LLA nicht routingfähig, sie gilt also immer nur im jeweils unmittelbaren lokalen Segment.

Wenn Du in Deinem Heimnetz irgendwann die "nächste" Stufe erreichst und verschiedene Subnetze und/oder VLANs verwendest hilft Dir eine LLA absolut nicht mehr weiter. Daher solltest Du auch gar nicht erst damit anfangen, damit großartig etwas zu machen.

Eine Firewall-Regel auf Basis einer LLA bringt Dir an dieser Stelle auch nicht wirklich viel. Zumindest dann nicht, wenn Du damit die ULA der Syno ansprechen willst. Dann nimmt der Rechner nämlich auch seine ULA. Die Firewall würde also eine Absender-ULA und eine Empfänger-ULA sehen... aber keine LLA. Und von der LLA kannst Du nicht auf die ULA schließen.

Diesen ganzen Privacy-Kram habe ich auch nirgendwo aktiviert.

Ich kann da nur genau wie @blurrrr sagen, ich schalte Privacy Extentions grundsätzlich als erstes aus. An meinen Geräte (Notebook, Desktop, Barebones, usw.) ist das eines der ersten Dinge, die ich abschalte.

Eine andere Alternative wäre, dass Du ausschließlich mit DHCPv6 arbeitest und dann dort statische Leases für Deine Clients hinterlegst. Dabei kann DHCPv6 durchaus statische Leases mit dynamischen Prefix. Man definiert das statische Lease dann einfach z.B. als "::1010:2020:3030:4040". Die gesamte IPv6 ergibt sich dann aus dem dynamischen Prefix (das der DHCPv6-Dämon per IA_PD vom Router bekommt) und dem statischen Interface-Teil aus der Lease-Tabelle.

Bei einer "guten IPv6-fähigen Firewall" kannst Du dann auch ein ALIAS definieren, dass ausschließlich aus einem statischen Interface-Teil besteht, der dann dynamisch um das Präfix ergänzt wird, somit gäbe es dann auch eine passende Firewall-Regel.

 

[Barungar]

Das mit dem statischen DHCPv6 kann dann z.B. so aussehen... Das sind Screenshots aus einem "Spiel-System" von mir.

Hier erst einmal das statische Lease. Im Gegensatz zu DHCPv4, wo man das statische Lease auf Basis der MAC definiert, wird beim DHCPv6 das statische Lease auf der Basis der DUID des Clients definiert. Jeder IPv6-Client hat eine eineindeutige DUID, die er beim DHCPv6-Request dem DHCPv6-Server mitteilt.



Wie man oben auf dem Screenshot sieht, wird also der DUID eine IPv6-Adresse "statisch" zugeordnet, die nur auf einem "Interface-Teil" besteht. In diesem Fall ist der Interface-Anteil von der IPv4 des Systems "inspiriert".

Das Ergebnis sieht man dann auch hübsch im "ipconfig" des Clients. Hier in diesem Beispiel sieht man die "statische" IPv6 (per DHCPv6) und die "statische IPv4" (per DHCPv4), sowie noch eine ULA, die per SLAC gebildet wurde und die ebenfalls automatisch erzeugte LLA. Die IPv6 ist dabei aus dem Subnetz "f9".




Der DHCPv6-Server hat sich das vorher per IA_PD das Subnetz xxxx:yyyy:zzzz:f0::/60 beim Router (meiner FritzBox 7583) angeholt; das dokumentiert die FritzBox auch intern, sie muss ja diese Netze auch weiterouten. Sie Screenshot unten "Delegiert".



Das delegierte Subnetz geht dabei von F0 bis FF, dem VLAN in dem sich der Client-Rechner befindet wurde im DHCPv6-Server F9 zugeordnet. Und ja, im IPv4 ist diesem VLAN das Netz "29" zugeordnet, also 172.29.172.0/24.

 

[Frank73]

Vielen Dank für euren Input.

Das mit ULA und LLA habe ich soweit verstanden. Auch das Thema PE sehe ich nicht so eng. Werde das mal an meinen beiden Testrechner deaktivieren und für IPv6 entsprechende Firewall-Regeln erstellen.
Das mit dem DHCPv6 muss ich erst mal auf mich wirken lassen und mich entsprechend in das Thema einlesen. Wenn man erst am Anfang von IPv6 steht ist das teilweise doch noch schwere Kost

 

[Frank73]

Hallo,

auf meinem Mint-Rechner werden nach einigen Versuchen mit IPv6 folgende Netzwerkeinstellungen bei "ip addr" ausgegeben:


Ich verstehe das jetzt so:
1. Adresse: IPv4-Adresse --> statisch --> unendlich gültig
2. Adresee: IPv6 des ISP --> dynamisch vergeben mittels Privacy Extension (temporary) --> für noch 3238 sec. gültig
3. Adresse: IPv6 des ISP --> dynamisch vergeben --> für noch 3238 sec. gültig
4. Adresse: IPv6 ULA --> statisch vergeben --> unendlich gültig
5. Adresse: IPv6 LLA

Wie gesagt sehe ich das mit der PE nicht so eng. Aber wenn ich es richtig deute ändert sich der Host-Anteil der Adressen 2 und 3 durch PE, während die interen ULA (4. Adresse) statisch ist und bleibt, welche ich dann in der Firewall hinterlegen kann.

Ist diese Konfiguration so in Ordnung?

Sollte ich was falsch interpretiert haben, sagt mir Bescheid.

Danke.

 

[Barungar]

Dann musst Du allerdings auch darauf achten, immer nur die ULA zu verwenden, wenn Du "durch" die Firewall willst.
Es wird nicht funktionieren, wenn Du die Regel auf Basis der ULA in der Firewall aktivierst, dann aber über eine GA (2. & 3. Adresse) zugreifst.

Für den Zugriff vom Client auf die Syno hieße das, dass Du entweder sicherstellen musst, dass der intern DNS-Name nur auf die ULA auflöst und keine GA mitliefert. Oder Du müsstest unmittelbar über die ULA selbst, und nicht über den Namen zugreifen.

Wenn der DNS nämlich mehr als einen AAAA-Record hat, und ein AAAA für eine GA und ein AAAA für eine ULA geliefert wird, präferieren die meisten Systeme auf Grund ihrer Konfiguration stets die GA.

Je nach Betriebsystem kann es, wenn Du intern nur einen A und AAAA mit ULA lieferst sogar passieren, dass ausschließlich IPv4 verwendet wird. Windows z.B. präferiert IPv4 über IPv6-ULA. (siehe hier https://forum.heimnetz.de/threads/warum-nutzt-mein-windows-die-ula-nicht-im-lokalen-netz.2977/ )

 

[blurrrr]

Da war @Barungar nu schneller, wollte es auch grade schreiben Da es sich aber um das interne NAS handelt, kann man das NAS dann auch einfach mit seiner statischen ULA ansprechen, so hab ich das hier zumindestens laufen bzw. mit einem internen DNS (ggf. Split-DNS) dann auch einfach über den entsprechenden FQDN (intern halt auf die ULA aufgelöst, extern auf die GA).

 

[Frank73]

Zu meinen DNS-Einstellungen:

Ich nutze aktuell 4 Zonen:

• "domain.tld": Diese habe ich nur, damit ich über den Reverse-Proxy "h**ps" mit einem Zertifikat nutzen kann (bsp.: "vaultwarden.domain.tld"). Diese Domain wurde auch nur für solche Zwecke registriert.
• "intern.domain.tld": Hier sind A- und AAAA-Record hinterlegt.
  Beispiel für das NAS:
  A-Record --> "nas.intern.domain.tld" IP: "192.168.178.20"
  AAAA-Record --> "nas.intern.domain.tld" IP: "fd12.1212.1212.1212.1212.1212:1212.1212"
  Beispiel für PC1:
  A-Record --> "pc1.intern.domain.tld" IP: "192.168.178.30"
  AAAA-Record --> "pc1.intern.domain.tld" IP: "fd12.1212.1212.1212.1313.1313.1313.1313"
• "in-addr.arpa": Hier sind die entsprechenden Einträge für die Reversezone hinterlegt (IPv4)
• "ip6.arpa": Hier sind die entsprechenden Einträge für die Reversezone hinterlegt (IPv6)

Ich denke, dass ich Split-DNS für diese Konfiguration nicht benötige, da keine dieser Adressen von aussen erreichbar sind (und sein müssen) und auch nicht nach aussen kommunizieren müssen. Diese wird nur für den internen h**ps-Zugriff benötigt.

Wenn der DNS nämlich mehr als einen AAAA-Record hat, und ein AAAA für eine GA und ein AAAA für eine ULA geliefert wird

Wann würde ich eine solche Konstellation benötigen?

 

[Barungar]

Die Konstellation, dass ein DNS-Server für einen Host mehrere AAAA-Records hat ist nicht so ungewöhnlich, besonders nicht wenn man GA und ULA gemeinsam in einem Netzwerksegment nutzt.

Bei mir haben z.B. so ziemlich alle Hosts mehr als einen AAAA-Record, eben die GA und die ULA.

 

[Frank73]

Könntest du mal dafür bitte ein praktisches Beispiel/Anwendungsfall nennen?

 

[Barungar]

Was warum ein Host z.B. einen A- und zwei AAAA-Records haben kann? Klar, kann ich Dir einen Beispielfall "konstruieren".

Ich betreibe meinen eigenen DNS-Server.
Zusätzlich habe ich ein NAS, das ist per IPv4 erreichbar (leider immer noch), weil es genau so leider immer noch Geräte gibt, die kein IPv6 können. Daher hat der Host (das NAS) einen A-Record.

Das Netzwerk ist in verschiedene VLANs unterteilt, einige davon sind ganz bewusst rein lokal. Sie verwenden nur ULA, keine GA und auch kein IPv4. Damit diese Geräte das NAS problemlos erreichen können, hat der Host einen AAAA-Record mit der ULA.

Darüberhinaus gibt es den Rest der IPv6-Welt. Diese können das NAS über die GA erreichen, eventuell aber nicht über die ULA - weil diese nicht global geroutet wird. Also hat der Host (das NAS) einen AAAA-Record mit der GA.

 

[Frank73]

Vielen Dank für das Beispiel.

Leider stehe ich immer noch auf dem Schlauch

Ich habe einen internen DNS mit den 4 Zonen und auch nur ein Teilnetz ohne VLAN.

Mein NAS und meine PC haben ja auch eine ULA und GAs (ULA für intern, da nicht routbar, GAs für das Routing in das Internet), sind also nicht rein lokal, da sie sowohl Zugriff auf das Internet haben, als auch für die interen Kommunikation über ULA (per AAAA-Record).

Diese können das NAS über die GA erreichen, eventuell aber nicht über die ULA

Ist das für den Fall, wenn ich Zugriff von außen auf mein Heimnetz erlauben möchte (z. B. wenn ich Dienste der NAS nach außen hin zur Verfüfung stellen möchte)?

Sorry, für die vielleicht blöden Nachfragen.

 

[Barungar]

Ist das für den Fall, wenn ich Zugriff von außen auf mein Heimnetz erlauben möchte (z. B. wenn ich Dienste der NAS nach außen hin zur Verfüfung stellen möchte)?

Korrekt... von außen (oder einem anderen Netzwerk) geht der Zugriff nur über GA, weil ULA immer "site local" sind.

 

[Frank73]

Habe weitere Voraussetzungen geschaffen um die Firewallregeln zu setzen.

Was bisher geschah:

• Auf meinen Linux-Rechnern werden die GAs mittels Privacy-Extensions erstellt und nur die ULA wurde manuell in der GUI des Network-Managers hinzugefügt. Linux ist da so clever und hat dann auch nur eine ULA und 2 GAs (eine davon erstellt mit PE) (siehe Post #11).
• Windows scheint da nicht so intelligent zu sein. Habe über netsh div. Sachen ausprobiert, jedoch ging alles mehr oder weniger in die Hose. Um weiterhin eine zuverlässige Verbindung innerhalb wie ausserhalb des internen Netzes sicherzustellen und IPv6 zu priorisieren habe ich die Standard-IPv6-Einstellungen über netsh angepasst.
  --> "netsh interface ipv6 set prefix ::ffff:0:0/96 2 4" (wie bereits im Forum hier schon beschrieben wurden)
  --> "netsh interface ipv6 set privacy state=disabled store=persistent" (deaktiviert Privacy-Extensions dauerhaft)
  In Windows habe ich somit nur noch 3 IPv6-Adressen: 1xGA (ohne PE), 1xULA und 1xLLA

Damit hoffe ich die Vorraussetzungen im Wesentlichen auch für IPv6 geschaffen zu haben um meine Firewallregeln sowohl mit statischer IPv4 und IPv6 administrieren zu können.