Diskstation gehackt

blurrrr

Benutzer
Mitglied seit
23. Januar 2012
Beiträge
3.709
Punkte für Reaktionen
302
Punkte
143
Dann ist vermutlich "vernünftig" (und zukunftssicher) neu kaufen die beste Option. Gegen "in kleinem Rahmen ausprobieren" spricht dabei sicherlich nichts. :)
 

takeiteasy

Benutzer
Mitglied seit
13. Mai 2011
Beiträge
30
Punkte für Reaktionen
4
Punkte
8
Wenn du utm home auf einem Gerät betreibst, welches nur dafür verwendet wird spricht dagegen gar nichts.

Habe da ganz vergessen auf Ubiqiti einzugehen. Die sind im Prinzip nicht schlecht, mein Aber dazu: Die haben alle kein vollständiges BIOS und man ist gezwungen eine Art Server (es geht auch der eigene PC) laufen zu lassen, mit dem die Komponenten verwaltet werden müssen. Das hat zwar den Vorteil der zentralen Verwaltung, aber den Riesennachteil, dass die Möglichkeiten der Peripherie im standalone markant eingeschränkt sind.
Natürlich kann man die einzelnen Geräte von Ubiquiti Standalone betreiben, aber wie du geschrieben hast sehr eingeschränkt. Nimmt man den Cloudkey (die Hardwareversion) dazu, hat man plötzlich enorm viele Einstellmöglichkeiten und Funktionen. Man kann dann sehr vieles konfigurieren und auch absichern. Es ist halt nicht ganz billig und man sollte technisch ein wenig interessiert sein, bei all den Konfigurationsmöglichkeiten.

lg
TakeIt
 

Mettigel

Benutzer
Mitglied seit
30. März 2013
Beiträge
253
Punkte für Reaktionen
8
Punkte
18
Warum muss das NAS an den Router um VLAN nutzen zu können? Wenn dein Switch das nicht kann brauchst du dir darüber keine Gedanken machen.
Falls die Frage auf mich bezogen war: der Switch routet ja nicht zwischen den VLAN, wenn also PC und NAS in unterschiedlichen VLAN sind muss sämtlicher Verkehr über den Router (welcher auch die Firewall ist).

Was ich mir gerade überlegt habe:
aktuell habe ich sehr viele Geräte im "normalen" LAN, also PC, NAS, Drucker, Medienplayer, Handys. Alle diese Geräte haben meinen Raspberry mit Pihole als DNS eingetragen. Somit kann ich schön sehen, welches Geräte wohin plaudern möchte und kann das auch unterbinden. Wenn ich jetzt aus diesem LAN vier unterschiedliche VLANs mache geht das nicht mehr. Bzw. wenn ich den Port 54 immer auf den Raspberry weiterleite sehe ich nur, dass das Gateway VLAN x auf bestimmte Adressen zugreifen will. Ich sehe aber nicht mehr, wer genau der Übeltäter ist.
Genauso im Protokoll-Center in der NAS. Ich sehe nicht welche IP gerade verbunden ist, sondern lediglich die IP des Gateways vom jeweiligen VLAN. Tippt jemand falsche Zugangsdaten ein, wird das Gateway geblockt, d.h. alle Geräte aus diesem Netzwerk können nicht mehr zugreifen.

Ist das so korrekt?
 

blurrrr

Benutzer
Mitglied seit
23. Januar 2012
Beiträge
3.709
Punkte für Reaktionen
302
Punkte
143
Knapp daneben ist auch vorbei -> 53 🤪

"Weitergeleitet" wird da übrigens "nix" - wir reden hier nicht von Portweiterleitungen, sondern durch die Firewall wird einfach nur "erlaubt", dass die Clients den Raspi via Port 53 kontaktieren dürfen und solange Du da kein NAT zwischen hast, sieht man sehr wohl, wer der Übeltäter ist ;)

Und btw: Wenn Du intern noch NAT laufen hast, machst Du eindeutig etwas verkehrt 😇
 
  • Like
Reaktionen: Mettigel

Mettigel

Benutzer
Mitglied seit
30. März 2013
Beiträge
253
Punkte für Reaktionen
8
Punkte
18
kommt davon, wenn man zu faul ist kurz zu googlen!!!

ok, ich hatte eine Zeit lang zwei Router hintereinander, da wurde immer die IP des Gateways angezeigt. Ich bin jetzt einfach davon ausgegangen, dass das bei der Firewall genauso ist, getestet habe ich das nie.
Jetzt spricht ja nichts mehr gegen die "vielen" VLANs. Ich könnte ja sogar das ganze SmartHome Zeug über PiHole laufen lassen.

An dieser Stelle: Vielen Dank für die vielen Tipps und die Unterstützung und Entschuldigung für so viel Off-topic!

PS: ich habe diese Woche Urlaub, wir haben Lockdown und ihr habt mir sehr viele Ideen in den Kopf gesetzt. Hoffentlich blocke ich nicht zu viel Internet während dem Testen, Sonst gehen mir hier ein paar Personen an die Gurgel :ROFLMAO:
 
  • Like
Reaktionen: blurrrr

Synchrotron

Benutzer
Mitglied seit
13. Juli 2019
Beiträge
1.894
Punkte für Reaktionen
201
Punkte
89
Hinweis zum PiHole: Man sieht, wer da alles „gesprächig“ ist. Jedenfalls dann, wenn eine DNS-Auflösung benötigt wird, d.h. Die Serveradresse ist als Internetadresse angegeben. Was man nicht sieht, ist Traffic, der direkt an eine (feste) IP-Adresse adressiert wird. Der benötigt keine DNS-Auflösung und schlüpft am PiHole vorbei. Das kommt bei dem IoT-Krempel durchaus vor.

Wer diesen Traffic auch sehen will, benötigt andere Tools.
 

Mettigel

Benutzer
Mitglied seit
30. März 2013
Beiträge
253
Punkte für Reaktionen
8
Punkte
18
Ja, da hast du natürlich Recht.
Was, wenn die IoT-Geräte auch feste DNS eingetragen haben? Diese würden sich doch dann auch an meinem PiHole vorbeischummeln!?! Bei den meisten IoT habe ich gar keine Möglichkeit den DNS zu kontrollieren.

Aktuell ist verdächtig wenig Verkehr vorhanden, was mich sehr verwundert. Nur der Wechselrichter schickt fleißig die Erträge an die Cloud...
 

blurrrr

Benutzer
Mitglied seit
23. Januar 2012
Beiträge
3.709
Punkte für Reaktionen
302
Punkte
143
Und wieder nix verstanden... 🤪

"Wozu" ist die Firewall nochmal gleich da? Achja, richtig, da war ja was: Um zu bestimmen, wer wie wohin darf! (endlich mal ein sinnvoller Einsatz für fett, unterstrichen und kursiv 😂) Was macht man dann, wenn man möchte, dass alle Clients einen bestimmten DNS-Server abfragen "müssen"? Jou! Man unterbindet einfach sämtliche DNS-Anfragen nach aussen (abgesehen vom internen DNS-Server) und forciert die Clients somit, den internen DNS-Server nutzen zu müssen (weil ansonsten keine DNS-Auflösung mehr möglich ist).

Kurzum: Alle Clients dürfen via Port 53 an den internen DNS-Server, "raus" mit Ziel-Port 53 darf aber nur der interne DNS-Server. Problem gelöst.

Umgehen kann man sowas natürlich wiederum mit statischen Einträgen in der hosts-Datei des Clients... 🤪

Bei den meisten IoT habe ich gar keine Möglichkeit den DNS zu kontrollieren.

Die meisten IoT-Dinger nutzen DHCP, darüber kannst Du auch (wie wohl bisher auch) den DNS-Server an die Clients verteilen. Nutzen die Dinger was ganz eigenes und lassen sich nicht umkonfigurieren, haben die im Netz sowieso nix verloren...
 
  • Like
Reaktionen: Michael336

Mettigel

Benutzer
Mitglied seit
30. März 2013
Beiträge
253
Punkte für Reaktionen
8
Punkte
18
🤕
ok, wie macht man das am einfachsten?
Meine Idee:
1. Regel mit Erlauben WAN OUT IP-PiHole Port 54 53
2. Regel mit Block WAN OUT IP-Any Port 53
 
  • Like
Reaktionen: blurrrr

Mettigel

Benutzer
Mitglied seit
30. März 2013
Beiträge
253
Punkte für Reaktionen
8
Punkte
18
ich schaffe es nicht, eine funktionierende Regel in WAN OUT zu erstellen.

In LAN IN funktioniert es hingegen. Hier müsste ich aber für jedes VLAN eine eigene Regel erstellen. Aufwand wär gering, aber verstehen tue ich es nicht.

Die Anfragen kommen vom Client in LAN IN rein und gehen bei WAN OUT raus. Es sollte doch egal sein, wo an dieser Stelle ich Port 53 blockiere.
 

blurrrr

Benutzer
Mitglied seit
23. Januar 2012
Beiträge
3.709
Punkte für Reaktionen
302
Punkte
143
"Gruppieren" geht nicht? Also die lokalen Netze, dass man eine Regel auf eine Gruppe anwenden kann? Kann es vllt sein, dass ggf. bei "OUT" ggf. eine Regel darüber ist, die generell alles raus lässt?

EDIT: https://www.scoutdns.com/how-to-limit-dns-bypass-on-unifi-gateway/ ;)
EDIT2: Mach vllt mal einen eigenen Thread dafür auf, das nimmt hier langsam echt Überhand 😇
 
Zuletzt bearbeitet:

NSFH

Benutzer
Mitglied seit
09. November 2016
Beiträge
2.996
Punkte für Reaktionen
79
Punkte
94
Wer hat dir denn den Bären aufgebunden, dass VLAN über den Router/Firewall laufen müssen?
Im Gegenteil, wenn dein Switch kein VLAN kann wirst du kaum ein funktionierendes LAN aufbauen können. Der Router ist dann nur die Komponente, wo vermutlich die meisten VLANs zusammenlaufen.
WAN Out ist übrigens gar nicht trivial, denn ein Eingangsport ist nicht zwangsläufig auch ein Outport. Da die meisten Programme nicht angeben welche Ports noch verwendet werden hilft nur den Nw-Verkehr für dieses Programm zu beobachten und dann kann dann diese Ports explizit der Anwendung und idealerweise auch einer IP zuweisen.
Deshalb findet man diese Funktion in keiner Fritz, da ist alles von 1-65000 out offen.
 

blurrrr

Benutzer
Mitglied seit
23. Januar 2012
Beiträge
3.709
Punkte für Reaktionen
302
Punkte
143
Deshalb findet man diese Funktion in keiner Fritz, da ist alles von 1-65000 out offen.

Deswegen auch reine IN-Regeln bei den meisten SoHo-Routern (ausser bei Multi-WAN) :)

EDIT: "IN" auf's WAN bezogen (bzw. dann in Kombi mit der Portweiterleitung)
EDIT2: Wobei die Regel dann auch auch auf ANY gilt (also alles von extern), wie z.B. bei so einer typischen Fritzbox oder dergleichen...
 

Mettigel

Benutzer
Mitglied seit
30. März 2013
Beiträge
253
Punkte für Reaktionen
8
Punkte
18
bin mal blurrrr Hinweis gefolgt und mache hier weiter: Thread
 

whitbread

Benutzer
Mitglied seit
24. Januar 2012
Beiträge
1.231
Punkte für Reaktionen
18
Punkte
58
Wo hast du beispielsweise deinen Drucker/Scanner? LAN oder VLAN, eigentlich muss der ja nicht ins Internet...
Ich habe inzwischen (leider) ein recht grosses WLAN-Segment, in dem auch der Drucker steht, sonst finden den die ios-Geräte nicht. Der Drucker darf dafür aber nicht ins Internet.
Da stehen dann auch die Netzradios, appleTV und der Receiver und eben auch meine (Haupt)-Syno, da sonst DLNA ein Krampf wird. Daran sieht man - so ganz trivial ist das Ganze in der Realität eben doch nicht. Ich hätte theoretisch zwar noch die Möglichkeit, die Zugriffe untereinander zu filtern, da ich (fast) jedes Gerät in einem eigenen VLAN habe und dann in einer Bridge zusammenführe - derzeit noch ungefiltert.
In Sachen Performance mache ich es so, dass ich für den Normalbetrieb über den Router gehe (~80MB/s), für Photo, Video und VM's gehe ich direkt über den Switch und zusätzlich über eine Direktverbindung PC-NAS und komme so kombiniert auf ca. 330MB/s.
 
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten, denn dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit einem hohen technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive oder Themen fremde Werbung. Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.