ja, in dem Fall wäre es wahrscheinlich am Besten das NAS als "unsicher" zu behandeln, die 2 VLANs zu machen und den Rest mit FW-Regeln....TheHille schrieb:Du kannst auch ein zusätzliches Netz für "Server", etc. machen.
Die Frage ist: Behältst du den Überblick und ist es sinnvoll für ein oder zwei Geräte ein eigenes Netz aufzumachen?
Gehe vielleicht eher andersrum vor: Welche Geräte sollen definitiv aus deinem "sauberen" Netz raus?
Segmentiere diese Geräte weg. In deinem Fall eigentlich nur die IoT-Geräte. Aber denke bitte an die Firewall-Regeln...
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Konzept Absicherung NAS ?
- Ersteller lalala987
- Erstellt am
Je nach NAS und Anwendung, kann es auch Sinn machen, ein zweites, virtuelles NAS zu haben.
Was genau sollen die IoT Geräte denn für Zugriff zum NAS bekommen? Wenn sich das in Grenzen hält und das zugrunde liegende Protokoll keine Schwachstellen hat (SMBv1 sollte man bspw nicht mehr verwenden, IoT Geräte die nur dieses können gehören aussortiert), kannst du den Zugriff eigentlich per Firewall erlauben und vom IoT VLAN zum NAS routen lassen. Können die Geräte aber nur SMBv1 und sollen weiter verwendet werden, würd ich ein virtuelles NAS im IoT VLAN betreiben, worauf die IoT Knaller zugreifen können.
Alternativ, wie du bereits gesagt hast, das NAS als unsicher einstufen und komplett ins IoT Netz oder in ne DMZ, aber dann auch keine vertraulichen Daten darauf ablegen
Sonst sendet die Kamera die Steuererklärung nach China 
Gruß
PS: in meinem Fall steht das NAS im LAN. die IoT Kameras stellen einen RTSP Stream bereit und das NAS greift auf den Stream zu. Die Kameras selber können keine Verbindung von sich aus ins LAN aufbauen. Die einzigen erlaubten Routen vom IoT VLAN ins LAN sind für MQTT (Port 1883) und InfluxDB (8086 oder sowas) und dann auch nur für den Server, der die Dienste hosted. Beiden beiden Services sehe ich aber auch kein Risiko
Was genau sollen die IoT Geräte denn für Zugriff zum NAS bekommen? Wenn sich das in Grenzen hält und das zugrunde liegende Protokoll keine Schwachstellen hat (SMBv1 sollte man bspw nicht mehr verwenden, IoT Geräte die nur dieses können gehören aussortiert), kannst du den Zugriff eigentlich per Firewall erlauben und vom IoT VLAN zum NAS routen lassen. Können die Geräte aber nur SMBv1 und sollen weiter verwendet werden, würd ich ein virtuelles NAS im IoT VLAN betreiben, worauf die IoT Knaller zugreifen können.
Alternativ, wie du bereits gesagt hast, das NAS als unsicher einstufen und komplett ins IoT Netz oder in ne DMZ, aber dann auch keine vertraulichen Daten darauf ablegen
Gruß
PS: in meinem Fall steht das NAS im LAN. die IoT Kameras stellen einen RTSP Stream bereit und das NAS greift auf den Stream zu. Die Kameras selber können keine Verbindung von sich aus ins LAN aufbauen. Die einzigen erlaubten Routen vom IoT VLAN ins LAN sind für MQTT (Port 1883) und InfluxDB (8086 oder sowas) und dann auch nur für den Server, der die Dienste hosted. Beiden beiden Services sehe ich aber auch kein Risiko
HA! Das ist wohl die Lösung!spcqike schrieb:IoT Kameras stellen einen RTSP Stream bereit
Denn wie eingangs beschrieben möchte ich gerade die Kameras speziell absichern. und wenn jetzt aber das NAS die Verbindung in das unsichere VLAN aufbaut, kann der Datenstrom auch ins sichere adminLAN zurück fließen.
entscheidend ist es dass die verbindung vom adminLAN intiiert wird. an einen RTSP Stream hatte ich nicht gedacht.
FW-technisch ist das einfach umsetzbar, denke ich
Ergänzung ()
mqtt und influx werde ich wahrscheinlich öffnen müssen, korrekt!
Bei MQTT und InfluxDB kannst du ja aber auch die Quell-IP angeben. Ich denke zwar nicht, dass die Kameras versuchen dort was zu ergattern, aber sicher und sicher. und schwer ist es auch nicht. eine Segmentierung anhand der IP Adresse (192.168.30.1/28 bspw. für Kameras ohne Routen, der Rest für den Rest mit Routen) sollte auch kein Problem darstellen.
MQTT und InfluxDB sind bei mir aktuell nur für diverse Tasmota Geräte, die eigentlich auch bedenkenlos ins LAN könnten. bei einem 172.16.x.x/20 Subnetz sollte das mit IP Adressen auch kein Problem sein. Aber ich halt die dennoch gern getrennt, irgendwie
MQTT und InfluxDB sind bei mir aktuell nur für diverse Tasmota Geräte, die eigentlich auch bedenkenlos ins LAN könnten. bei einem 172.16.x.x/20 Subnetz sollte das mit IP Adressen auch kein Problem sein. Aber ich halt die dennoch gern getrennt, irgendwie
Bei InfluxDB kann man auch entsprechend ein Schreib-Token vergeben. Dann kann der Sensor z.B. schreiben aber nicht lesen. Wenn also jemand den Sensor übernehmen würde, könnte er zwar Müll in die Datenbank schreiben, aber keine vorherigen Daten auslesen.
@spcqike was brüchte man denn so an Hardware für so ne Software Lösung, die auch 1G schafft, oder zumindest mal 100MBit überall hin und gleichzeitig 1G für das primäre Netz. Wobei da würde ja nichts drüber gehen, sondern direkt...
Also ja, stimmt mit 100Mbit/s kommt man schon echt weit. Der Saugroboter etc braucht ja kaum Bandbreite und ob ein Update nun 3 oder 10 Minuten braucht ist auch egal.
Hm.... pfsense wäre da wohl die Wahl der Mittel oder?
Also ja, stimmt mit 100Mbit/s kommt man schon echt weit. Der Saugroboter etc braucht ja kaum Bandbreite und ob ein Update nun 3 oder 10 Minuten braucht ist auch egal.
Hm.... pfsense wäre da wohl die Wahl der Mittel oder?
das kommt ganz auf dein Netzwerk/Layout und deine Anforderungen an.
Ich persönlich habe eine Firewall auf OPNSense Basis. (ein gebrauchter Dell Optiplex 3010 SFF von Ebay... für ~50€ bekommen) Die hat zwar nur 1 NIC, aber dank VLAN (VLAN fähiger Switch und Accesspoints von Ubiquiti) ist das kein Problem. Der verwaltet 4 Netze (1 untagged, 3 VLAN) und bekommt das WAN ebenfalls über ein VLAN von einem Modem (in meinem Fall eine Fritzbox. die war halt vorhanden, wird für das Telefon sowieso benötigt. und leitet alle Anfragen von Außen an die Firewall weiter (exposed Host)). die Firewall bekommt sogar ein /60 IPv6 Präfix von der Fritzbox, sodass jedes (V)LAN IPv6 könnte, wenn ich es denn einstelle.
Klingt kompliziert, aber ist es eigentlich nicht. und da Switch/AP und FB vorhanden waren, kam in meinem Fall nur der 50€ Dell dazu und der ist eben meine eigentliche Firewall aktuell.
günstige/gebrauchte Router mit OpenWRT sollten aber ebenso ausreichen, um 100MBit zwischen mehreren VLANs zu routen. Die können dann meistens auch direkt mehrere WLAN Netze aufspannen.
Ebenso kann man bestimmt eine halbwegs vernünftige Firewall (Ubiquiti ER-X, USG, ...) dafür verwenden, braucht dann aber zusätzlich WLAN. (Außer man nimmt bspw. die UDM mit WLAN)
Man kann auch einen Raspberry (3/4) nehmen. Sei es als vollständige Firewall für das/die Netze (würde ich aber nicht empfehlen, wenn das interne LAN 1G können soll) oder auch nur als Gateway für ein dahinter hängendes IoT LAN (also den Raspberry als Client im LAN, der aber "hinter" sich ein weiteres LAN erstellt)
Wer bereits einen Heimserver zu Hause betreibt (sei es ein NUC, ein x86 NAS oder auch ein "größerer" Server... "Groß" ist ja relativ
) kann auch darauf eine vollwertige Firewall oder auch nur ein weiteres Gateway virtualisieren. Je nach Modell/Größe/Ansprüche und vorhandene Infrastruktur.
oder oder oder ... der Möglichkeiten gibt es sehr viele. Je nachdem kostet es nichts bis >500€
Da ich wie gesagt bereits eine Ubiquiti Infrastruktur hatte (USG, Switch, APs) und ich mit der Leistung und Möglichkeiten der USG nicht zufrieden war (Wireguard, Durchsatz beim VLAN Routing mit aktivem IDS/IPS ...) und ich auf einen 1G Anschluss gewechselt habe, waren die 50€ für den Dell gut investiert
Ich persönlich habe eine Firewall auf OPNSense Basis. (ein gebrauchter Dell Optiplex 3010 SFF von Ebay... für ~50€ bekommen) Die hat zwar nur 1 NIC, aber dank VLAN (VLAN fähiger Switch und Accesspoints von Ubiquiti) ist das kein Problem. Der verwaltet 4 Netze (1 untagged, 3 VLAN) und bekommt das WAN ebenfalls über ein VLAN von einem Modem (in meinem Fall eine Fritzbox. die war halt vorhanden, wird für das Telefon sowieso benötigt. und leitet alle Anfragen von Außen an die Firewall weiter (exposed Host)). die Firewall bekommt sogar ein /60 IPv6 Präfix von der Fritzbox, sodass jedes (V)LAN IPv6 könnte, wenn ich es denn einstelle.
Klingt kompliziert, aber ist es eigentlich nicht. und da Switch/AP und FB vorhanden waren, kam in meinem Fall nur der 50€ Dell dazu und der ist eben meine eigentliche Firewall aktuell.
günstige/gebrauchte Router mit OpenWRT sollten aber ebenso ausreichen, um 100MBit zwischen mehreren VLANs zu routen. Die können dann meistens auch direkt mehrere WLAN Netze aufspannen.
Ebenso kann man bestimmt eine halbwegs vernünftige Firewall (Ubiquiti ER-X, USG, ...) dafür verwenden, braucht dann aber zusätzlich WLAN. (Außer man nimmt bspw. die UDM mit WLAN)
Man kann auch einen Raspberry (3/4) nehmen. Sei es als vollständige Firewall für das/die Netze (würde ich aber nicht empfehlen, wenn das interne LAN 1G können soll) oder auch nur als Gateway für ein dahinter hängendes IoT LAN (also den Raspberry als Client im LAN, der aber "hinter" sich ein weiteres LAN erstellt)
Wer bereits einen Heimserver zu Hause betreibt (sei es ein NUC, ein x86 NAS oder auch ein "größerer" Server... "Groß" ist ja relativ
oder oder oder ... der Möglichkeiten gibt es sehr viele. Je nachdem kostet es nichts bis >500€
Da ich wie gesagt bereits eine Ubiquiti Infrastruktur hatte (USG, Switch, APs) und ich mit der Leistung und Möglichkeiten der USG nicht zufrieden war (Wireguard, Durchsatz beim VLAN Routing mit aktivem IDS/IPS ...) und ich auf einen 1G Anschluss gewechselt habe, waren die 50€ für den Dell gut investiert
wie gesagt, kommt auf den Fall an. Ein ordentliches NAS mit Virtualisierungsmöglichkeit ist da genauso sicher wie eine VM auf einem Server.
in einem einfachen DockerContainer würde ich es ebenfalls nicht laufen lassen, auch wenn es wahrscheinlich ginge. Aber gegen eine echte VM spricht aus meiner Sichts nichts. Auf einem QNAP oder einem TrueNAS ist das definitiv möglich. auf einer Synology Diskstation .... ja da geht auch VM Virtualisierung.... aber da fehlt mir "hinten rum" die CPU Leistung
Außer bei den ganz großen Modellen, aber da steht Kosten/Nutzen im Vergleich zu Standalone Firewalls irgendwie außer Frage. Die sind einfach zu teuer. Wenn so ein Gerät aber bereits vorhanden ist weil man das NAS an sich braucht.... why not?
in einem einfachen DockerContainer würde ich es ebenfalls nicht laufen lassen, auch wenn es wahrscheinlich ginge. Aber gegen eine echte VM spricht aus meiner Sichts nichts. Auf einem QNAP oder einem TrueNAS ist das definitiv möglich. auf einer Synology Diskstation .... ja da geht auch VM Virtualisierung.... aber da fehlt mir "hinten rum" die CPU Leistung
Ähnliche Themen
- Antworten
- 2
- Aufrufe
- 559
U
- Antworten
- 9
- Aufrufe
- 1.299
- Antworten
- 7
- Aufrufe
- 1.763
- Antworten
- 7
- Aufrufe
- 2.507
- Antworten
- 14
- Aufrufe
- 2.013