Möglichst sicherer Zugriff auf NAS ohne VPN

[realklaus]

Firewall fehlt noch. Ich würde auch im internen LAN alles verbieten was nicht benötigt wird, extern sowieso.

Hierzu habe ich noch mal eine Frage. Ich konfiguriere grade die Regeln der Firewall im DMS dieser Kurzanleitung entsprechend:
Die Syno hängt nur über LAN am Router. Sonst gibt es keinen Zugang. D.h. ich erstelle ein neues Profil, das sich nur auf LAN bezieht.
In der ersten Regel erlaube ich der festen IP des stationären Computer im Netzwerk Zugriff auf alle Ports. Hierüber erfolgt die Verwaltung der NAS.
Es folgen weitere Regeln für feste IPs im Netzwerk (mobiltelefone, Notebooks, etc.), die Zugriff auf relevante Ports erhalten (5001, 8801, 443, ...).
Die letzte Regel ist die Geoblocking Regel, die erstmal nur IP's aus D zulässt (Port 443, 5001, 8801, 6690, 38443).
Wenn keine Regel zutrifft, wird der Zugang verweigert.

Reicht die Erlaubnis der Geoblocking Regel nur deutsche IP's zuzulassen mit den entsprechenden Ports, um auch von außerhalb des Netzwerks auf die Syno zu kommen und Syno Drive, Note Station, Calendar, Contacts und Audio Station zu nutzen? Funktioniert die Zertifikat-Aktualisierung über Let's Entcrypt für DDNS dann noch?
Hab ich was wichtiges übersehen?

Danke und Grüße, alex

 

[senderversteller]

Die Regeln in der Firewall werden von „oben nach unten“ abgearbeitet.
Ich habe es aktuell so, dass ich unter „Alle Schnittstellen“ erstmal alle Länder verweigere, die ich überhaupt nicht auf meinem NAS sehen will. Für jedes Land eine eigene Verweigern-Regel. Hab ich mir hier im Forum von einem anderen Mitglied abgeschaut. So kann schon mal nix schief gehen, wenn bei den weiterführenden Zulassen Regeln ein Wurm drin ist.

Unter „LAN1“ habe ich dann die netzinternen IPs, die Zulassen auf alle relevanten Ports. Hier auch vorsichtig/restiktiv sein und nicht Tür und Tor für alles öffnen, was nicht sein muss.
Zuletzt kommen unter LAN1 noch die externen IPs und Ports, denen ich aus dem Internet Zugriff (durch Portforwarsing FRITZ!Box) gewähren will: In meinem Fall nur 443 per Reverse Proxy auf Photos, Contacts, etc. aus Deutschland und 6690 (Drive Server) für eine ganz spezielle
IP-Range von 4 IPs (= Schule, an der meine Frau Lehrerin ist).

Was die Aktualisierung deines LE Zertifikat betrifft kommt es darauf an. Bei Aktualisierung via HTTP Challenge musst du Port 443 und 80 für LE mindestens für USA zulassen. LE gibt aber keine Serverliste an, d.h. es kann auch sein, dass die Zertifikatsverlängerung fehl schlägt, weil LE deinen Webserver nicht erreicht.
Deswegen haben ich auf DNS Challenge und Wildcard Zertifikat umgestellt.

Das DDNS Zertifikat von Synology benötigt glaube ich überhaupt keine offenen Ports.

 

[NSFH]

noch eine kurze Ergänzung dazu:
Das NAS und Router sollte eine feste IP haben.
Erhält eines dieser Geräte eine andere IP kann einem die Firewall wegen nicht zutreffender Regeln schon mal den Zugang versperren.

Vorsicht mit Geoblocking über alle Schnittstellen! 192.168.x.x ist nicht Deutschland spezifisch sondern kann dann auch geblockt werden!
Also D freigeben reicht nicht, man muss auch die eigene IP-Range (oder Teile davon) des LANs freigeben.

Für den Zugriff auf DSM Port 5001 nur den Bereich im LAN freigeben, in dem die eigenen PCs hängen.

Wenn man ein gutes Regelwerk aufstellt sind viele Einstellungen nötig.
Damit das immer transparent und übersichtlich bleibt keine "Eine Regel mit vielen Eintragungen" machen, sondern immer für jeden Dienst oder App eine eigene Regel erstellen.
Das ist auch wichtig, weil die Reihenfolge der Regeln entscheidend sein kann. Nur so lassen sich dann einzelne Einträge an die richtige Position verschieben.

Im Regelwerk gibt es ausnahmslos nur Erlaubnisse, keine Verbote. Verboten wird erst mit dem Haken ganz unten um alle anderen Zugänge zu blocken.

 

[senderversteller]

Das was @NSFH mit 192.168.x.x schreibt ist den privaten Adressbereichen (10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16) zuzurechnen und ist natürlich nicht auf Deutschland bezogen. Dieses Wissen habe ich vorausgesetzt, wenn man an Firewall Regeln rumspielt.
Da es von der IANA festgelegte Bereiche sind, die nicht im Internet geroutet werden, sollte es auch von keiner Geoblock Liste bei Synology erfasst werden… oder habe ich dich da falsch verstanden?

Deswegen hab ich ja geschrieben die netzinternen IP als erste bei der relevanten Schnittstelle (hier LAN1) freizugeben.
Nach meiner Erfahrung macht die Firewall sowieso nichts, womit man sich mit der aktuellen Verbindung selbst aussperren würde. Aber das muss man natürlich nicht auf die Probe stellen

 

[realklaus]

Ich habe es so verstanden, wie @NSFH geschrieben hat, dass in den FW Regeln nicht Verbote geschrieben werden (bspw. alle Länder, die nicht zugreifen sollen, wie Du es schilderst, @senderversteller oder habe ich das missverstanden?), sondern die Ausnahmen von der Regel, dass nichts durchgelassen wird.
Die Ausnahmen werden dann chronologisch sortiert.
D.h. wenn ich die zunächst sage, dass die lokale, feste IP von Rechner 1 auf alle Ports zugreifen darf, dann kommt sie durch, egal was die Regeln danach sagen – oder?
Daher steht die Geoblocking Erlaubnis für D (alles andere wird eben geblockt) am Ende der Regelkette. Und für die IPs aus D sind dann nur die o.g. Ports freigegeben (ja, ich habe den Hinweis von NSFH gelesen, für jeden Dienst, ergo jeden Port eine eigene Regel zu schreiben. Passe ich noch an).
D.h. die lokalen Geräte haben Zugang auf bestimmte Ports und IPs aus D können auf die Ports 443, 5001, 8801, 6690, 38443 zugreifen. Alles andere wird geblockt. Das scheint so weit auch zu funktionieren.
Die lokalen Geräte haben feste IP Adressen

Eine Frage, die noch offen ist: Durch den Reverse Proxy kommt in der Syno doch alles auf Port 443 an und wird dann durch die Syno je nach Subdomain auf die jeweiligen notwendigen Ports weitergeleitet. An welcher Stelle greifen denn nun die FW Regeln? Vor oder hinter den Weiterleitungen des RP?
Ggf. würde es dann doch reichen, für den externen Zugriff nur 443 aus D freizugeben?

Danke für den Austausch und die Anregungen. Ich habe das Gefühl, so langsam etwas besser durchzusehen. alex

 

[NSFH]

Wenn du 443 nur für D zulässt gibts u.a. keine Updates mehr. Nutzt du zB DNS 8.8.8.8 (Google) geht das nicht mehr.
Aber sicher bist du dann ;-)

"d.h. wenn ich die zunächst sage, dass die lokale, feste IP von Rechner 1 auf alle Ports zugreifen darf, dann kommt sie durch, egal was die Regeln danach sagen – oder?"
so isses

Wenn eine Firewall erst hinter offenen Ports (RP) lauschen würde wäre sie sinnlos.

Nur als Anmerkung: Ich nutze in der Syno niemals die globalen Einstellungen der Firewall, sondern sichere jeden Ethernet-Port, wenn ich ihn denn brauche einzeln ab.
Ich konfiguriere meine Netze auch immer so, dass zB ETH1 nur für das interne LAN da ist, wohingegen ETH2 den Zugang ins/aus dem Internet ermöglicht.
Dadurch kann das Regelwerk der Firewall genauer angepasst werden.
Dazu benötigt man aber einen Router, der sowas unterstützt.

 

[metalworker]

Firewall greift vor dem RP .
Was du also dort Blockst kommt gar nicht erst zum RP durch.
Zumindest wenn der RP auf der Synology läuft

 

[realklaus]

OK, ist nachvollziehbar, dass sie vor den offenen Ports, also auch vor dem RP sitzen muss.
Das bedeutet, dass ich für alle Dienste, die ich aktiv aufrufen möchte (Drive, Calendar, Kontakte, C2, Notestation) eigentlich nur die 443 brauche, weil nur der über den RP durchgelassen wird.
Die Ports für das System (Backup, Updates, etc.) kämen noch dazu. Weiß jemand, was an System-Ports verfügbar gemacht werden muss? Das geht mE aus der Port-Liste von Syno nicht so einfach hervor.

 

[realklaus]

Die Idee mit verschiedenen Ethernet-Wegen für intern/extern ist spannend. Ich werde jetzt erstmal die NAS umziehen auf ein neues System (DS923+, dazu mach' ich noch mal nen extra Thema auf) und mich dann mit nem neuen Router beschäftigen. Da kann man dann ja die Möglichkeit mit den verschiedenen Ethernet-Wegen berücksichtigen.

 

[metalworker]

Nur als Anmerkung: Ich nutze in der Syno niemals die globalen Einstellungen der Firewall, sondern sichere jeden Ethernet-Port, wenn ich ihn denn brauche einzeln ab.
Ich konfiguriere meine Netze auch immer so, dass zB ETH1 nur für das interne LAN da ist, wohingegen ETH2 den Zugang ins/aus dem Internet ermöglicht.
Dadurch kann das Regelwerk der Firewall genauer angepasst werden.
Dazu benötigt man aber einen Router, der sowas unterstützt.

Wenn du nen Router / Firewall hast , wo du richtige Regeln hast.

Welchen Vorteil hast da an der Synology mit 2 verschieden Ports ?
Gibt sicher nen Vorteil , aber irgednwie klemmt bei mir da gerade nen Knoten im Kopf.

 

[NSFH]

Die Schizophrenie eines Admins nicht vergessen. ;-)
Warum soll zB auf einem Ethernetport der nach Aussen zeigt Samba laufen?
Wer von Aussen kommt klopft alle Schwachstellen ab, auch wenn sie durch Fw geschützt ist. Wo es nichts zu klopfen gibt muss ich mir auch weniger Gedanken machen.
Diese Trennung greift aber schon vor der Syno in der Firewall des Routers. Hier ist mehr möglich als in der Syno, ich kann nämlich inbound und outbound getrennt konfigurieren.

 

[senderversteller]

Ich habe es so verstanden, wie @NSFH geschrieben hat, dass in den FW Regeln nicht Verbote geschrieben werden (bspw. alle Länder, die nicht zugreifen sollen, wie Du es schilderst, @senderversteller oder habe ich das missverstanden?), sondern die Ausnahmen von der Regel, dass nichts durchgelassen wird.

Natürlich ist es doppelt gemoppelt eine Reihe von Ländern über "Alle Schnittstellen" zu verbieten, denn die Logik der Firewall ist: was nicht zugelassen wird ist verboten. Dann sind sie logischerweise alle Länder verboten, die ich nicht unter LAN1 explizit erlaube.

Ich meinte ja in Post #22 nur, dass bei einer späteren Fehlkonfiguration unter LAN1 (z.B. bei einem Land versehentlich einen Hacken gesetzt, wo ich es nicht wollte) ein solcher Fehler unterdrückt wird.
Beispiel: Demokratische Republik Kongo ist unter "Alle Schnittstellen verboten". Unter LAN1 will ich einen Port für Deutschland aufmachen, aber ich klicke versehentlich Demokratische Republik Kongo an. Ergebnis: Weil DR Kongo vorher verboten wurde, kann das Land in LAN1 nicht danach erlaubt werden.

Aber natürlich, das muss so nicht konfiguriert werden. Ob ich bei dieser Einstellung bleibe, mal sehen... das habe ich von @hblein in diesem Thread mal so gelesen und übernommen.

 

[senderversteller]

Wenn du 443 nur für D zulässt gibts u.a. keine Updates mehr. Nutzt du zB DNS 8.8.8.8 (Google) geht das nicht mehr.
Aber sicher bist du dann ;-)

Kannst du bitte näher erläutern, was du damit meinst? Ich verstehe nicht, was die Firewall Regeln mit Updates (Update von was?) und dem Nameserver von Google zu tun haben.

 

[NSFH]

ganz einfach. Was meinst du wie oder auf welchen Ports sich die Syno updates aus Taiwan zieht oder eine DNS Anfrage der Syno an einen DNS Server ausserhalb von D? Sperrst du 443 oder 53 für das Ausland klappt so einiges nicht mehr.

Warum nutz du verbieten Regeln unter alle Schnittstellen?
Die Firewall erlaubt nur und am Ende wird alles was nicht erlaubt ist pauschal geblockt.
Und genau das ist für einen Laien ein Problem, wenn er die Firewall an verschiedenen Stellen mit Regeln füttert. Es kommt zu ungewollten Überschneidungen was zu nicht nachvollziehbaren Fehlern führt.
Keep ist simple und lege für jede Schnittstelle eigene Regeln fest.

Es gibt übrigens einen ganz einfachen Trick wie man das versehentliche Aussperren verhindern kann.
Die meisten Synos haben 2 ETH Ports und genutzt wird nur einer.
Konfiguriere den ungenutzten Port mit einer IP aus deinem LAN aber verbinde ihn nicht per Kabel mit dem Router.
Damit hast du einen Noteingang der erst funktioniert, wenn du das Kabel einsteckst.

 

[plang.pl]

Man kann unter DSM doch gar keine Regeln für ausgehenden Datenverkehr einstellen?

 

[Tommes]

Hm… arbeitet die Syno Firewall nicht nach dem inbound Prinzip? Also alle Anfragen die rein wollen und nicht dürfen, werden blockiert bzw. verworfen. Alle ausgehenden Anfragen, die „Established“ sind, werden zugelassen. So auch eine Anfrage von innen um ein Update anzustoßen?

 

[senderversteller]

ganz einfach. Was meinst du wie oder auf welchen Ports sich die Syno updates aus Taiwan zieht oder eine DNS Anfrage der Syno an einen DNS Server ausserhalb von D? Sperrst du 443 oder 53 für das Ausland klappt so einiges nicht mehr.

Das was du da schreibst stimmt nicht. Für den Betrieb und die Updates einer Synology DS müssen überhaupt keine Ports ins Internet geöffnet werden. Es soll Leute geben, die ihre DS nach außen mit keinem einzigen Port geöffnet haben, kein Zugriff aus dem Internet möglich, komplett abgeschottet und trotzdem diese ganz normal benutzen können.
Um an deinen PC, Mac, Smartphone, etc. Updates zu ziehen oder dieses normal zu benutzen musst du ja auch keine Ports weiterleiten oder eine Firewall aufmachen... Wie Tommes schreibt: Inbound-Prinzip. Die Firewall Regeln gelten nicht für ausgehenden Traffic.

Warum nutz du verbieten Regeln unter alle Schnittstellen?
Die Firewall erlaubt nur und am Ende wird alles was nicht erlaubt ist pauschal geblockt.
Und genau das ist für einen Laien ein Problem, wenn er die Firewall an verschiedenen Stellen mit Regeln füttert. Es kommt zu ungewollten Überschneidungen was zu nicht nachvollziehbaren Fehlern führt.
Keep ist simple und lege für jede Schnittstelle eigene Regeln fest.

Deswegen habe ich geschrieben, dass das doppelt gemoppelt ist - und ich mir noch nicht sicher bin, ob ich es so lasse. Aktuell halte ich es für eine gute Idee die mir nicht weh tut Aber für den Laien vielleicht verwirrend. Deswegen muss man die Erklärung hinter der Logik lesen.

 

[framp]

Alle ausgehenden Anfragen, die „Established“ sind, werden zugelassen. So auch eine Anfrage von innen um ein Update anzustoßen?

Das ist das Prinzip wie InboundFirewalls von intern umgangen werden. Du installierst eine Webcam, die baut eine Verbindung zu einem Webcamherstellerserver auf, Deine Handyapp connected sich per Webcamherstellerapp zum Herstellerserver, dier korreliert die Verbindungen und final siehst Du Deine Webcam @Home obwohl Du nie einen Inboundport für die Webcam freigegeben hast.

Ich nutze keine FW auf der Syno und mein Router verhindert jeglichen Inbound Trafficaufbau wie wohl sicherlich auch die Syno. Will man wissen was genau geblocked bzw errlaubt wird muss man sich die iptables/netfilter Regeln ansehen.

In dem Kontext habe ich eben festgestellt dass auch ohne enabled SynoFW DOS Regeln aktiv sind:

root@synology:~$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
DOS_PROTECT  all  --  anywhere             anywhere          

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain DOS_PROTECT (1 references)
target     prot opt source               destination        
RETURN     icmp --  anywhere             anywhere             icmp echo-request limit: avg 1000/sec burst 5
DROP       icmp --  anywhere             anywhere             icmp echo-request
RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST
RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 10000/sec burst 100
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
RETURN     icmp --  anywhere             anywhere             icmp echo-request limit: avg 1000/sec burst 5
DROP       icmp --  anywhere             anywhere             icmp echo-request
RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST
RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 10000/sec burst 100
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN

 

[NSFH]

@plang.pl: Wie geschrieben bezieht sich der Outbound der Firewall auf meinen Router.

Ich denke dieses Zitat aus meinem Posting kann man nicht missverstehen: "Diese Trennung greift aber schon vor der Syno in der Firewall des Routers. Hier ist mehr möglich als in der Syno, ich kann nämlich inbound und outbound getrennt konfigurieren."

Das Spielchen mit nur noch D in der Firewall zuzulassen habe ich seinerseits unter DSM ausgetestet.
Von Synology kamen logischer Weise keine Hinweise mehr auf neue DSM oder APP Versionen.
Updates funktionierten nur, wenn neben dem "normalen" IP Zugang zum LAN auch Quickconnect aktiv war, sonst nicht!
Warum das so war dafür hätte man sich mit wireshark den Traffic analysieren müssen. Auf jeden Fall klappte es nicht.