IoT NoT Isolation

Es gibt 13 Antworten in diesem Thema, welches 3.391 mal aufgerufen wurde. Der letzte Beitrag () ist von thghh.

    Hallo,


    ich will mit meiner neuen Dream Machine meine diversen Smart Home Geräte auf eigene Netzwerke geben.


    Da ich noch ziemlich am Anfang stehe, was das Thema betrifft, wollte ich mich an diese Anleitung halten, da diese die Verständlichste war, die ich gefunden habe:

    Network segregation: IoT vs NoT


    Nun habe ich aber folgende Probleme/Fragen und wäre sehr dankbar wenn mir irgendein Profi da vielleicht weiterhelfen kann:



    Home Assistent Server:

    Der Typ arbeitet mit einem Home Assistent Server:

    Home Assistant
    Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a…
    www.home-assistant.io


    Dafür gibt er im Network den Domainname "iot.local.home.goroot.de" an. soweit ich das verstanden habe:


    Und in der Firewal hat er neben den anderen IoT/NoT Regeln "IoT to MQTT server", wo die SH Geräte sich mit dem Server verbinden.


    Sowas hab ich aber nicht, sondern nur die üblichen Smart Home Sachen:

    • Google Home/Nest
    • Smart Life/Tuya
    • Tado
    • Govee

    Kann diese Anleitung irgendwie so angepasst werde, dass sie für meine Anforderungen funktioniert?


    Firewall: Destination Groups:


    Kann ich bei den neu zu erstellenden Firewallregeln einfach diese neuen Gruppen wie "NTO Port" erstellen? Leider wird in der Anleitung nicht gesagt, was man da genau eingeben soll:



    Firewall: Default Regeln:


    Bei "LAN IN" sind bei mir schon drei Default Regeln drinnen. Kann man die weiterhin drinnen lassen, oder spießen sich die mit den neuen IoT/NoT Regeln?


    Ich danke euch für eure Hilfe! ☺️

    Dein Problem ist eigentlich, dass du was abschreiben möchtest ohne zu wissen wie es funktioniert, das sollte aber dein Ansatz sein, die Firewall lernen zu verstehen.

    Mein Vorredner hat hier ja schon den link zum Wiki genannt.

    Ganz oben in den Regeln deiner Anleitung sind die pauschalen Freigaben, ganz unten sind die pauschalen sperren.

    Brauchst du wirklich eine Trennung zwischen IoT und NoT? Bei deinen „unter 30 Geräten“ wage ich das mal zu bezweifeln, ich würde also alles was smart ist in ein VLAN packen, dann die Geräte und Ports die doch in andere netze sollen zwischen den pauschalen Regeln (in deinem Beispiel der mqtt Server bzw Home Assistant) die Geräte in „lan in“ setzen mit denen es sprechen darf, also mit Port (evtl. Gruppe) und ip (evtl. Gruppe)

    Falls du gar keinen Smarthome Server oder Gateway hast, sondern nur Endgeräte, dann kannst du auch nur die Client Geräte frei geben welche das Gerät steuern sollen.

    Dann macht so ein setup aber nur noch limitiert Sinn. Weil es soll ja dafür sorgen das nur Gateways und Server mit deinen Geräten reden sollen und nicht die einzelne Glühbirne.

    Bei dem ganzen gesperre gibt es auch immer noch Geräte welche generell freie Hand haben wollen und die man komplett frei schalten sollte, das wären zb Beispiel Streaming Geräte wie Lautsprecher oder fernseh streamer , das siehst du dann aber am Gerät wenn es nicht mehr zu steuern ist


    PS default Regeln sind grau hinterlegt und können garnicht gelöscht werden, es macht Sinn die dann auch drin lassen zu wollen

    Zitat von uboot21

    Dein Problem ist eigentlich, dass du was abschreiben möchtest ohne zu wissen wie es funktioniert, das sollte aber dein Ansatz sein, die Firewall lernen zu verstehen.

    Sehe ich auch so aber es ist teilweise auch schwer es zu verstehen.


    Z.B. States>>>Established, Related


    Mal ist es in den Regel angeklickt, mal heisst es es ist egal usw.


    Wo bekommt an die Erklärungen dazu, was diese Einstellungen bewirken?

    Ich habe meine "Freundin" mal nach iptables states suchen lassen und hier sind Deine Antworten:

    Zitat von manpage

    Possible states are INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don't correspond to any known connection, ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions, and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

    Da steht auch noch ganz viel mehr interessantes zum Thema Firewalling.

    Zitat von razor

    Ich habe meine "Freundin" mal nach iptables states suchen lassen und hier sind Deine Antworten:

    Meine Freundin versteht kein Wort und fragt nach einer umgangssprachlichen Erklären auch gerne in unserer lokalen Sprache.

    Zitat von thghh

    Mal ist es in den Regel angeklickt, mal heisst es es ist egal usw.

    Wenn du nix anklickst gelten alle, wenn du nur Established anklickst, gilt nur Established... habe ich dir schonmal irgendwo geschrieben.

    Gruß

    defcon

    Gefällt mir 1

    Ich denke der Auto Modus ist am besten dafür oder?

    Das kann man so nicht pauschalisieren...


    razor hat ja etwas dazu gepostet nachdem seine Freundin ihm geantwortet hat und das muss man dann für seinen eigenen speziellen usecase so umsetzen.

    Gruß

    defcon

    Zitat von thghh

    Wo bekommt an die Erklärungen dazu, was diese Einstellungen bewirken?

    Bei Unifi selber in den Hilfen:

    Intro to Networking - Network Firewall Security
    Overview This is an introductory article on the workings of Stateful and Stateless firewalls. NOTES: Find a…
    help.ui.com

    und hier noch zu den Regeln:

    UniFi - UDM/USG: Introduction to Firewall Rules
    Overview Readers will learn how to view and configure firewall rules on the UDM and USG models. NOTES & REQUIREMENTS: Applicable to the latest firmware…
    help.ui.com



    Als Hilfe von mir: Ich klicke da nie was an !

    Danke 1
    Zitat von thghh

    Ich denke der Auto Modus ist am besten dafür oder?

    Ist so ein bisschen wie der Auto-Pilot-Modus bei Tesla: einfach fahren lassen und hoffen, dass das Auto im richtigen Moment das richtige tut.


    Automatisch und Firewall passt meiner Meinung nach gar nicht zusammen.

    Zitat von uboot21

    Bei Unifi selber in den Hilfen:

    https://help.ui.com/hc/en-us/articles/115006615247

    und hier noch zu den Regeln:

    https://help.ui.com/hc/en-us/a…duction-to-Firewall-Rules

    Richtig, aber ich denke, dass das das nicht löst:

    Zitat von thghh

    Meine Freundin versteht kein Wort und fragt nach einer umgangssprachlichen Erklären auch gerne in unserer lokalen Sprache.

    Oder thghh hat nicht verstanden, wie ich es meinte.

    Ich habe das durchaus gelesen aber ich verstehe nicht was es bedeutet.



    Neben einer Richtung oder einem Netzwerktyp können die Firewall-Regeln auch einen Status verwenden:

    • new Die eingehenden Pakete stammen von einer neuen Verbindung.
    • established Die eingehenden Pakete werden einer bereits bestehenden Verbindung zugeordnet.
    • related Die eingehenden Pakete sind neu , aber einer bereits bestehenden Verbindung zugeordnet.
    • invalid Die eingehenden Pakete stimmen mit keinem der anderen Zustände überein.


    Jede FW Regel ist doch beim Anlegen new und danach bestehend.


    Eventuell kann man das einmal erklären was da genau gemeint ist und was es für Auswirkungen auf die Regel hat.

    Bei einer Firewall geht es immer erst um die Richtung, dabei gehören interne Regeln im Netzwerk immer ins LAN IN und von aussen eintreffende Anfragen immer ins das WAN IN (analog dazu das IPv6 was ich jetzt mal aussen vor lasse)

    Um es einfach zu halten bleibe ich beim WAN IN


    Also ist die Richtung ist eingehend:

    NEW: Es kommt eine neue Anfrage von aussen, irgendeine IP auf einem bestimmten PORT, ist die Anfrage nur von Aussen getriggert dann ist die Verbindung also NEU! -> musst du wissen ob du das wirklich willst

    Established: Also bereits erstellt. Du rufst von innen eine Webseite im Internet auf, DU hast also eine Verbindung hergestellt, damit die Webseite dir auf Port 80 Antworten darf, muss also die Antwort auf der bestehenden Verbindung rein erlaubt sein

    Related: Also zugehörig. Das kommt schon mal vor. Du fragst im Internet auf einer IP und einem Port etwas an, der Dienst möchte dir jetzt antworten, aber nicht auf dem gleichem Port (Established), sondern auf einem anderem Port (Related), das erlaubst oder verbietest du hier.

    Invalid: Wie der Name Schon sagt, sind das "verunglückte" Anfragen ohne jeglichen Bezug, das will man nicht zulassen.


    Vor allen Regeln hat man meist eine Regel die Related/Established erlaubt (siehe WIKI), sonst bekämst du nie eine Antwort wenn du was anfragst.


    Generell: Das sind Sonder Szenarien mit den State, in der Regel ausser acht zu lassen, meist willst du etwas sperren für alle State, also lässt du alle Haken WEG!


    -> Das alles steht aber auch schon in dem Google Suche Ergebnis von Razor

    Danke 1

    Danke das konnte ich nun gut verstehen


    Ich habe eine Frage dazu:


    Established: Also bereits erstellt. Du rufst von innen eine Webseite im Internet auf, DU hast also eine Verbindung hergestellt, damit die Webseite dir auf Port 80 Antworten darf, muss also die Antwort auf der bestehenden Verbindung rein erlaubt sein.


    Gibt es bei diesem Fall einen Zeitfaktor? Also wie lange lässt die FW eine Rückantwort zu?