NAS eingeschränkt erreichbar machen

[Ghost108]

Guten Morgen!

ich benötige eure Hilfe mit einem Thema, welches mir über den Kopf wächst.
Da die Thematik für mich sehr komplex scheint, habe ich die IST Situation skizziert.



Zusammengefasst:

• Vollständiger Zugriff auf NAS via VPN (Syno Contacts, Syno Calendar, Drive, ...)
  • Zugriff auf NAS (Webstation) über Port 5508 (alle ohne VPN).
    
• Zugriff auf NAS VM (chatwoot container) über Port 443 (alle ohne VPN)
  • Da ich Port 443 nicht für meine NAS öffnen wollte, dachte ich, es wäre sinnvoller eine NAS VM zu erstellen, welche dann via 443 erreicht werden kann. Lt. Synology Support seit das sicherer, da die VM isoliert von der eigentlichen NAS ist (eigene IP, eigene Portfreigaben, ...)

Domains:
Im öffentlichen Bereich nutze ich chat.domain.de und api.domain.de. Grundsätzlich zeigen aber alle domains auf die öffentliche IP meiner Fritzbox.
Auf der NAS habe ich Adguard laufen und nutze hiermit u.a. die DNS Umschreibung.

cloud.domain.de	IP der NAS
calendar.domain.de	IP der NAS
contacts.domain.de	IP der NAS
adguard.domain.de	IP der NAS
homebridge.domain.de	IP der NAS
api.domain.de	IP der NAS
sharepoint.domain.de	IP der NAS VM
chat.domain.de	IP der NAS VM

Meine Clients nutzen intern, wie auch über VPN, AdGuard als DNS Server.

Für alle Domains nutze ich ein LE Zertifikat.
Das Zertifikat ist auf die cloud.domain.de ausgestellt - als alternativer Name habe ich jeweils die anderen domains mit angegeben.
Somit ein Zertifikat für alle aufgelisten Domains.

---

Ab hier erst mal durchatmen

---

Folgende Probleme sind mir dabei schon aufgefallen

Problem 1 (iPhones):
Wenn das iPhone das interne Netz verlässt und dann auf VPN wechselt (geschieht automatisch).
In dem Zeitraum, wo das iPhone nicht mehr im WLAN ist, sondern mobile Daten nutzt (extern) und die VPN Verbindung noch nicht hergestellt wurde (wir reden hier von wenigen Sekunden), nutzt das iPhone nicht Adguard als DNS Server.

Wenn in dem Moment das iPhone mit dem caldav Server synchronisert, passiert folgendes:
Verbindung zum caldav wird hergerstellt über calendar.domain.de (port 443) => diese zeigt auf die öffentliche IP der Fritzbox => Port 443 ist offen für NAS VM => hierhin wir die Verbindung versucht, was scheitert, da der caldav Server auf der NAS und nicht NAS VM läuft.


Problem 2:
Es findet ein externer Zugriff von meiner Webseite auf die Webstation meiner NAS statt (über api.domain.de:5508)
Das funktioniert auch. Allerdings gibt es in seltenen Fälle Probleme, wo ein User in einem Firmennetzwerk hängt, welches Anfragen in Richtung Nicht-Standard-Ports blockiert. 5508 wäre ein solcher Fall. Um diesen Fall auch abzudecken, müsste ich den Zugriff via api.domain.de:443 ermöglichen und somit auch den Port 443 für die NAS öffnen. Dann wiederrum ist meine NAS vollständig erreichbar für extern. Dann könnte man auch den caldav über calendar.domain.de, carddav über contacts.domain.de, usw... ohne VPN erreichen.


Kurz gesagt:
Bin aktuell nicht wirklich glücklich mit der Situation und würde mich sehr freuen, wenn Ihr mich hierbei unterstützen könnte.
Was könnte ich anders machen? Wie würdet Ihr das lösen? usw ...

 

[metalworker]

Beim Problem 1 wirst wohl ni viel machen können, aber ist doch auch nur für den kurzen moment , das sollte nach meinem Verständniss keine Sicherheitslücke sein

Beim Problem 2 wird es kniffliger. Ohne ne VM mit mir eigenen IP wirst dich da wohl entscheiden müssen.
Könntest es nur über einen dedizierten Reverseproxe anstellen.

 

[Ghost108]

Beim Problem 1 wirst wohl ni viel machen können, aber ist doch auch nur für den kurzen moment , das sollte nach meinem Verständniss keine Sicherheitslücke sein

Beim Problem 2 wird es kniffliger. Ohne ne VM mit mir eigenen IP wirst dich da wohl entscheiden müssen.
Könntest es nur über einen dedizierten Reverseproxe anstellen.

Ja Problem 1 ist eher lästig, schatt ein Risko.

 

[Benares]

Warum lässt du nicht den ganzen Verkehr über Port 443 zum NAS laufen und verpointerst alles, was mit "NAS VM" zu tun hat über den Reverse Proxy?

 

[Ghost108]

Weil ich doch dann den Port 443 offen machen müsste für die nas und somit auch die anderen Dienste verfügbar wären. Caldav usw. oder anders gesagt. Ein Angreifer käme dann schon mit 443 bis zur nas.

 

[Thonav]

Verstehe die Panikmache hier gar nicht mehr. Oh Schreck ein "Angreifer" (!) kommt über einen Port bis zur NAS?! Vernünftiges Passwort und Benutzernamen, gepaart mit begrenzte Login-Versuche sollte da schon ausreichend helfen. Auf der anderen Seite mit einem PC auf unbekannten Seiten im Internet zu surfen erachte ich da für bedenklicher...
Aber - just my 50 Cent. Muss also nicht weiter diskutiert werden.

 

[metalworker]

Naja wenn man Dienste laufen hat ist es mehr als nur BN und PW , gibt oft genug sicherheitslücken.

Was ich z.b. Privat und Dienstlich nutze ist eine vernünftige Firewall, da lasse ich schon nen großteil von seltsamen Clients gar nicht erst durch.

 

[Benares]

Weil ich doch dann den Port 443 offen machen müsste

Ja und? Meinst du Port 5508 brächte dir mehr Sicherheit? Und über die Firewall der DS kannst du ja auch auch noch einschränken.

 

[metalworker]

Der Port 5508 wird weniger versucht an zu greifen also der Port 443 ,

also so ganz abwegig ist das nun nicht

 

[Ghost108]

Der Port 5508 wird weniger versucht an zu greifen also der Port 443 ,

also so ganz abwegig ist das nun nicht

ja und nein. natürlich ist ein Angriff auf 443 einfacher, da Standard.
Aber wenn man kurz einen Portscanner nutzt und dir dann gezeigt wird, welche Ports stattdessen offen sind ... auch nicht besser

also ich merke, hierzu hat man sehr viele Unterschiedliche Meinungen.

Die Frage bleibt dennoch offen:
Was würdet ihr machen?

 

[w00dcu11er]

Ich würde wie hier einige erwähnt haben immer über Reverse Proxy lösen wollen - also alles nur über Port 443 - gepaart mit einigen Sicherheitsvorkehrungen wie Blockierungslisten etc.

 

[Benares]

Ich bin einfach der Meinung, dass ein einzelner Port, der zu einem Gerät führt und auf einem renommierten, gut administrierten Web-Server endet, besser zu schützen ist, als (im Extremfall) ein Verhau von Ports, die zu zig Geräten führen auf denen wiederum ein Verhau von Diensten läuft.

Und da ich viele, vor allem Firmen-Netze, kenne, bei denen nur 443 (und vielleicht noch ein paar andere) nach außen hin offen sind (Problem 2), würde ich dafür den 443 als Port nehmen.

 

[Ghost108]

Wenn ich den Port 443 eh für meine NAS öffne, dann brauche ich die NAS VM ja nicht mehr.
Würde es gerne mal skizzieren, wie ich mir das vorstellen würde:




Die Frage die sich mir nun stellt:
Wie würde ich die Syno Firewall dafür einstellen?
ich müsste einstellen können:

• Zugriff intern auf alles (das ist für mich klar)
• Zugriff via chat.domain.de:443 => Zulassen alle
• Zugriff via api.domain.de:443 => Zulassen alle
• Alle anderen Zugriffe / Domains => Verweigern

 

[Ulfhednir]

Der Port 5508 wird weniger versucht an zu greifen also der Port 443 ,

also so ganz abwegig ist das nun nicht

Als erstes läuft der Port-Scanner und darauf wird der Vulnerability-Scanner angesetzt. Das ist eine Scheinsicherheit in die man sich bettet.
Mal so nebenbei: Was ist wohlmöglich als Angriffsziel interessanter?Ein Server, wo auf dem ersten Blick nur ein Webserver liegt (das Internet ist voll von denen) oder ein Server bei dem scheinbar noch weitere Dienste betrieben werden?

Zu dem Thema habe ich mich bereits mehrfach an anderer Stelle bei Ghost108 ausgelassen.
Um auch hier letztmalig darauf einzugehen:

Um diesen Fall auch abzudecken, müsste ich den Zugriff via api.domain.de:443 ermöglichen und somit auch den Port 443 für die NAS öffnen.

Kurz gesagt:
Bin aktuell nicht wirklich glücklich mit der Situation und würde mich sehr freuen, wenn Ihr mich hierbei unterstützen könnte.
Was könnte ich anders machen? Wie würdet Ihr das lösen? usw ...

Ich weiß nicht, warum du 3 Threads benötigst, die sich allesamt mit dem selben Kernproblem beschäftigen. Aber sei's drum.
Wenn du deinen innerlichen Monk ausleben musst, wäre nächst-logische Schritt die api.domain.de ebenfalls innerhalb in der / einer VM zu betreiben. Ansonsten gibt es den weiterhin den klaren Appell an deinen inneren Monk: Hol dir ein externes Hosting rein - ersatzweise eine ordentliche Firewall-Appliance in Kombination mit weiteren Geräten in einer DMZ betreiben. Das habe ich dir allerdings bereits in dem anderen Thread mitgeteilt.
Letztendlich möchtest du doch nicht nur deine Daten schützen, sondern auch die deiner Kunden, oder?

Für mich wäre das keine Alternative. Bei mir läuft alles über den Reverse Proxy (SWAG). Besonders schützenswerte Dienste werden, soweit möglich, zusätzlich mit 2FA (Authelia) geschützt. Wenn man Zeit und Muße findet, können diese weiterhin mit dem integrierten Fail2Ban gehärtet werden.
Bei mir ist zusätzlich eine Unifi-Firewall vorgeschaltet. Die hält mir über den 443-Port etliche Penetration-Attempts vom Hals, die du mit der normalen Synology-Firewall gar nicht abwehren kannst.

 

[ottosykora]

Der Port 5508 wird weniger versucht an zu greifen also der Port 443 ,

also werden die meisten Server der Welt dauernd angegriffen? Und was soll da angegriffen werden?

 

[metalworker]

Als erstes läuft der Port-Scanner und darauf wird der Vulnerability-Scanner angesetzt. Das ist eine Scheinsicherheit in die man sich bettet.
Mal so nebenbei: Was ist wohlmöglich als Angriffsziel interessanter?Ein Server, wo auf dem ersten Blick nur ein Webserver liegt (das Internet ist voll von denen) oder ein Server bei dem scheinbar noch weitere Dienste betrieben werden?

Genau darin liegt der Trick
Eine Ordentliche Firewall vorausgesetzt.
Wenn ein Angriff ( ob es nur eine einfache Brutforce oder ein V Scan ist ) direkt auf einen üblichen Port beginnt.
Dann hat dir Firewall es erstmal schwerer den Angriff zu erkennen.

Versucht aber ein Host einen Portscan zu machen , dann fliegt der direkt bei der Firewall auf die Sperrliste .
Natürlich ist das keine sicherheit im Einzelnen , aber es hält das log etwas freier und es erschwert einen Angreifer wieder den Angriff.

Und genau darum gehts ja.
Dazu kommt , die meisten Automatischen Bot angriffe laufen mit Standard Ports und Zugangsdaten .
Wenn du den Port verbogen hast , dann schützt es dich etwas falls du mal ausversehen nen Standard Account aktiv hast ( sollte natürlich nicht passieren )
Für mich sind solche sachen einfache mit eine Ebene um Angriffe zu erschweren.

 

[Synchrotron]

Du könntest auch Cloudflare davor schalten. Schon die freie Variante bringt z.B. Schutz vor DDOS-Angriffen und einiges mehr.

https://www.cloudflare.com/de-de/

 

[Thonav]

@Ghost108 - wozu brauchst Du eigentlich den externen Zugang zu adguard? Es wird soviel davon geschrieben, möglichst wenig von außen zugänglich zu machen, daher meine Frage...

 

[Ghost108]

Adguard ist extern nur via VPN erreichbar, damit meine Clients auch via VPN den Werbeblocker haben, sowie die DNS Umschreibungen

 

[Ulfhednir]

Eine Ordentliche Firewall vorausgesetzt.
Wenn ein Angriff ( ob es nur eine einfache Brutforce oder ein V Scan ist ) direkt auf einen üblichen Port beginnt.
Dann hat dir Firewall es erstmal schwerer den Angriff zu erkennen.

Für solche Fälle sollte auch eher eine Heuristik greifen.

Dazu kommt , die meisten Automatischen Bot angriffe laufen mit Standard Ports und Zugangsdaten .
Wenn du den Port verbogen hast , dann schützt es dich etwas falls du mal ausversehen nen Standard Account aktiv hast ( sollte natürlich nicht passieren )
Für mich sind solche sachen einfache mit eine Ebene um Angriffe zu erschweren.

Aus der Praxis kann ich dir sagen, dass auch non-standard-Ports gescannt werden. Das ist mit pnscan und Co. überhaupt kein Thema.

Hier wäre mal ein aktuelles Beispiel:
Ein RDP-Scan auf Nicht-Standard-Port. (443:9099(Nginx))

Zuviel zum Thema Scheinsicherheit, wenn man differenzierte Ports verwendet.