Wie schütze ich am besten mein Heimnetzwerk davor dass eine Überwachungskamera nach Haus telefoniert ?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • liefert auch nichts.

    ...

    Das verstehe ich nicht denn ich haette irgendwo die .151 IP der Cam erwartet zu sehen

    welche IP-Adresse benutzt Du im Mobile um die Cam via VPN, zu erreichen?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Wie schütze ich am besten mein Heimnetzwerk davor dass eine Überwachungskamera nach Haus telefoniert ?? Schau mal ob du hier fündig wirst!

  • Welche ich zu dem Zeitpunkt des tcpdumps benutz habe weiss ich nicht. Jetzt ist es 46.114.146.24. Die externen IPs die Du im Trace siehst

    Code
    39.96.168.250.32100: UDP, length 4
    47.52.5.251.32100: UDP, length 4
    47.254.33.234.32100: UDP, length 4

    sind die IPs in China.

    Code
    10.8.0.6

    ist die IP die ich im VPN bekomme.

  • Welche ich zu dem Zeitpunkt des tcpdumps benutz habe weiss ich nicht. Jetzt ist es 46.114.146.24.

    Nein, ich meine nicht die externe IP. Es geht um eine IP-Adresse die Du im VPN benutzt, vom Mobil zur Cam.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Es ist

    10.8.0.6

    Ist das nicht eine IP-Adresse aus dem Transfer-Netz des VPN?

    Hat ein Interface der Cam diese IP-Adresse?

    EDIT:

    Du willst vom Mobile aus, die Cam mit der internen IP-Adresse 192.168.0.151 (im VPN-Tunnel bis zum VPN-gateway, weil dort das VPN zu ende ist) erreichen. Dafür brauchst Du im Mobile eine definierte Route zum host 192.168.0.151 mit der VPN-IP-Adresse des Mobile als gateway und dem tun0-Interface (oder gleichwertig vom Mobile) als device.

    BTW: Mit welcher _internen_ IP-Adresse erreichst Du mit z. B. ssh im VPN-Tunnel, _vom Mobile_ aus, die anderen Geräte in deinem Home-(W)LAN? Genau so sollte aus auch für die Cam funktionieren.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    2 Mal editiert, zuletzt von rpi444 (26. Mai 2021 um 09:43)

  • Ist das nicht eine IP-Adresse aus dem Transfer-Netz des VPN?

    Hat ein Interface der Cam diese IP-Adresse?

    10.8.0.6 ist die IP des Mobiles im VPN. Die Cam hat die lokale IP 192.168.0.151.

    Du willst vom Mobile aus, die Cam mit der internen IP-Adresse 192.168.0.151 (im VPN-Tunnel bis zum VPN-gateway, weil dort das VPN zu ende ist) erreichen. Dafür brauchst Du im Mobile eine definierte Route zum host 192.168.0.151 mit der VPN-IP-Adresse des Mobile als gateway und dem tun0-Interface (oder gleichwertig vom Mobile) als device.

    Anbei die Routen die es auf dem VPN Gateway troubadix gibt:

    Code
    framp@troubadix:~# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.0.1     0.0.0.0         UG    202    0        0 eth0
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
    10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

    10.8.0.2 ist die VPN IP des Gateways. Default Gateway ist die 192.168.0.1 welche meine Fritte ist. Die Route zum 192.168.0.0/24 geht vom VPN Gateway zum eth0 raus. D.h. darueber erreiche ich alle meine lokalen Systeme ohne eine dedizierte Route vom Mobile zu den Systemen zu haben. Oder habe ich Deinen folgenden Kommentar

    Dafür brauchst Du im Mobile eine definierte Route zum host 192.168.0.151 mit der VPN-IP-Adresse des Mobile als gateway und dem tun0-Interface (oder gleichwertig vom Mobile) als device.

    falsch verstanden?

    BTW: Mit welcher _internen_ IP-Adresse erreichst Du mit z. B. ssh im VPN-Tunnel, _vom Mobile_ aus, die anderen Geräte in deinem Home-(W)LAN? Genau so sollte aus auch für die Cam funktionieren.

    Ich habe mich mal per VPN wie auch lokal per ssh verbunden und erhalte folgende Ausgabe auf dem Zielsystem:

    Code
    framp@asterix:~ $ w
    14:38:26 up 47 days, 18:50,  2 users,  load average: 0.13, 0.20, 0.25
    USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
    framp    pts/0    10.8.0.6         14:37   41.00s  0.14s  0.14s -bash
    framp    pts/1    192.168.0.106    14:38    1.00s  0.12s  0.03s w

    Dort siehst Du dass ich mit der VPN IP 10.8.0.6 im System bin. Die 192.168.0.106 ist meine lokale Verbindung vom Schlepptop.

    Ich kann von meinem Mobile auch ohne Probleme auf das Web UI der Cam zugreifen. Eben habe ich auch mal eine RTSP Client per VPN und Kinderblocker auf die Cam losgelassen. Auch das funktioniert. D.h. prinzipiell komme ich an die Cam mit Kinderblocker per VPN ran. Nur der Zugriff mit der App die P2P nutzt funktioniert nur wenn ich lokal im Netz bin. Ueber VPN funktioniert es nicht.

    Ich habe mal bei OpenVPN nachgelesen und es gibt dort das Routing mit tun Device und die Ethernet/bridging Methode mit tap Device. Routing nutze ich auch. Kann es sein dass ich Bridging nutzen muss um non IP Traffic zu sehen? Kann eigentlich nicht sein denn wenn ich den Kinderblocker auf der Fritte ausschalte und es funktioniert laeuft ja auch der Traffic ueber einen Router und non IP Traffic wird nicht uebertragen :conf:

  • 10.8.0.6 ist die IP des Mobiles im VPN. .... Nur der Zugriff mit der App die P2P nutzt funktioniert nur wenn ich lokal im Netz bin. Ueber VPN funktioniert es nicht.

    Ich denke wir kommen da nicht weiter, weil wir die Routing-Tabelle aus dem Mobile nicht kennen und auch nicht wissen wie man diese Routing-Tabelle im Mobile, zum testen manuell anpassen/ändern kann.

    Wir kennen auch nicht den Traffic vom Mobil zur Cam via VPN und wissen auch nicht an welchen Schnittstellen unterwegs, wir diesen Traffic zum testen, sniffen können.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ich habe mir schon auf dem GW den gesamten Traffic zur Cam mit Wireshark angesehen und versucht mit dem Traffic der ohne VPN zur Cam laeuft zu vergleichen. Ist leider nicht so uebersichtlich und so fit bin ich mit Netzwerktraffic lesen und verstehen auch nicht. Ich dachte vielleicht ist es ein grundsaetzliches (einfaches) Problem.

    Dafür brauchst Du im Mobile eine definierte Route zum host 192.168.0.151 mit der VPN-IP-Adresse des Mobile als gateway und dem tun0-Interface (oder gleichwertig vom Mobile) als device.

    Ich werde mal am Mobile OpenVPN Client rumspielen. Vielleicht finde ich einen Weg diese Route noch zu definieren. Jedenfalls vielen Dank fuer Deine Hilfe. Im worst Case werde ich einen dedizierten AP aufsetzen und an eine Raspi haengen und per netfilter das nach Hausetelefonieren Blocken. Im Gegensatz zur Kindersicherung die offensichtlich alles blocked kann ich da gezielt Dinge offen lassen. Das ist auch hilfreich um der Cam zu erlauben emails ueber den Port 25 an meinen Provider zu schicken bei Events. Ansonsten muesste ich erst einen RelayMailserver bei mir lokal aufsetzen :-/

  • Im Gegensatz zur Kindersicherung die offensichtlich alles blocked kann ich da gezielt Dinge offen lassen. Das ist auch hilfreich um der Cam zu erlauben emails ueber den Port 25 an meinen Provider zu schicken bei Events.

    An der Stelle der Hinweis: Die Fritzbox beherrscht die Steuerung mittels "Whitelist". D.h. du kannst alles blocken und dann deinen Email-Provider, NTP-Server usw. gezielt im Zugangsprofil für die Kamera freigeben. Für Email-Benachrichtigungen langt das völlig aus.

    Unsere Kamera hat den Videostream auch im Webinterface der Kamera verfügbar. Auf diesen greifen wir mittels Raspberry Pi und Reverse-Proxy (Nginx) zu. Für einen Blick mittels Vpn und Browser reicht uns auch das.

  • Interessant dass man mittlerweile auch Black- und Whitelisten in der Fritte nutzen kann. Ist zwar nicht ganz das was eine Firewall kann aber immerhin sind schon gewisse Dinge blockbar. ich habe jetzt nur den Port 32100 Outbound geblocked ueber den nach Hause telefoniert wird. eMail Versand bei Events geht weiterhin :bravo2: Somit telefoniert die Cam nicht mehr nach Hause und sie kann trotzdem Alerts per eMail schicken :bravo2: . Realtime Alterts gehen nicht per VPN - ist aber nicht so dramatisch.

    Mit einem RTSP Player komme ich leider per VPN nicht an de Livestream. Im Webfrontend gibt es zwar wie bei Dir aber aus irgendeinem Grunde funktioniert das nicht - weder lokal noch per VPN. Da muss ic hnoch weitersuchen warum es nicht geht bzw eine Alternative finden. Scheint so zu sein dass es irgendwie am RTPS liegt denn VLC kann auch nicht ueber VPN Streamen.

    Prince Hast Du darum einen reverse proxy aufgesetzt? Wie hast Du den gegen unbefugten Zugriff gesichert?

  • Hier wurde die Isolierung der Kamera mit Fritzbox-Werkzeugen gelöst:

    - Zugangsprofil für die Kamera mittels Whitelist

    - Fritzbox-IPsec-VPN

    - Myfritz als DynDNS-Dienst

    Bei dem Zusammenspiel der Fritzbox-Dienste lassen sich Geräte mit Zugangsprofil nicht via Fritz-VPN erreichen. Daher das Spiel über Bande mit dem Reverse-Proxy. Der Nginx ist nicht aus dem Internet erreichbar und intern muss der nicht gesichert sein.

    <OT>

    Es gibt Kameramodelle die wollen sich trotz "whitegelistetem" NTP-Server kein Datum und keine Uhrzeit holen. Passen die Angaben des Date-Headers in der Email nicht zur Gegenwart, wird die Mail bei GMX, Gmail & co nicht weitergeleitet. D.h. nach Spannungsfreiheit muss die Kamera-Uhr gestellt werden. Das funktioniert bei dem Modell auch über das Webinterface. Hier kümmert sich nach Netzausfall auch der Raspberry Pi mittels curl-http-request drum.

    Die Kamera hat noch mehr Clock-Bugs, so wird die Timezone beim Date-Header ignoriert und grundsätzlich GMT gesendet.

    </OT>

  • Sehr interessanter Thread! Nur, als Netzwerk-Laie verstehe ich vielfach Bahnhof. Ich möchte irgendwann eine Webcam für unsere Hühnerhütte installieren und möchte mich in dem Zusammenhang mit der Sicherheitsproblematik auseinandersetzen. Zumal insbesondere die von mir implementierte Android-App die Türen der Hütte auch mal von außerhalb des WLAN-Bereichs steuern können soll.

    Dass bei China-Produkten mitgehört wird, ist erschreckend. Der Smarthome-Schrott, auf den offensichtlich so viele abfahren, lässt grüßen. Kann mir jemand Quellen empfehlen, mit welchen ich mir Wissen über die Netzwerk-Thematik aneignen kann ?

    maksimilian

  • Nicht alles was Smarthome heißt ist Schrott!

    Aber bei den allermeisten Kameras hast du Recht, da haben viel "Heimweh" und senden übers eigen WLAN dann Daten an irgendeinen Server in Fernost.

    Oder laufen ohne externe Serververbindung erst gar nicht.

    Da muss man genau nachforschen, den meist wird in den Beschreibungen nichts davon erwähnt.

    Und so eine Serververbindung kann dann sogar Kosten verursachen.

    Ich würde mir eine Outdoor WLAN Kamera besorgen und über einen eigenen Server oder NAS laufen lassen.

    Ich habe z.B. eine Instar IN-2905, ein älteres Modell, das per WLAN mit einem Programm auf der NAS verbunden ist.

    Damit habe ich den Winter über Vögel am Futterhäuschen beobachtet.

    Mittlerweile ist die Cam aber wieder abgerüstet.

    Und die hatte auch kein Heimweh!

    Deshalb würde ich mich da mal bei Namhaften Herstellern von Überwachungskameras umsehen.

    Allerdings sind dass dann meist keine Billigdinger und man muss dreistellig rechnen.

  • Der Grund warum die Kameras oft "nach Hause telefonieren" ist dass man es dem Nutzer einfach machen will. Beim nach Hause funken teilt die Kamera mit über welchen Port sie von Aussen zu erreichen ist damit die Mobile App mit den Informationen einfach auf die Kamera zugreifen kann. Wenn ich bei mir P2P ausschalte muss ich "umständlich" per VPN in mein Heimnetz gehen und einen RTSP Player nutzen um das Kamerabild zu sehen. Die Mobile App funktioniert aber ohne P2P nicht.

    Sprich man muss sich keine teure Kamera kaufen wenn man auf den MobileAppLuxus verzichten kann und P2P ausschaltbar ist. Oder man schaltet in der Dritte sämtlichen INetverkehr aus.

  • Der Grund warum die Kameras oft "nach Hause telefonieren" ist dass man es dem Nutzer einfach machen will.

    ziemlich dummer Grund

    so war das ja auch bei meinem Staubsauger Robi mit der App, vorher funktionierte er ohne App, nach App Aufspielung mit Freigabe auf dem Handy wurde er eingerichtet, ein Firmwareupdate aufgespielt welches bei 80% steckenblieb und ab da war die Verbindung Robi zur Absaugbasis unterbrochen und er funktionierte nicht mehr, es gab auch kein Werksreset am robi oder eine Möglichkeit den zurückzusetzen!

    Sollen die doch ein AP aufmachen wo man alles eingibt ohne das eine Heimtelefoniererei nötig wäre, das wäre besser und noch besser wäre ein Taster Werksreset!

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Der Nachteil der meisten Kamera Apps, ist eben der, dass sie über einen unbekannten Server des Hersteller laufen.

    Damit laufen sie dann meist auch Problemlos.

    Manchmal kann man diese Kameras auch meist auch auf eigene Server Umstellen, die dann im eigenen Netzwerk laufen.

    Allerdings war die Kamera nicht von Außen erreichbar.

    Sprich ich konnte nur im eigenen Netzwerk über die APP Zugriff nehmen.

    Das war aber gewollt, sonst hätte meinen Server von Außen Angreifbarer gemacht.

  • Das ThreadThema bzw eine Loesung des Problems haengt von vielen Dingen ab: Was fuer eine Kamera Du hast, was fuer eine Infrastruktur Du hast, welche HW hast Du bzw was fuer € bist Du bereit zu investieren, in wieweit Du Dich mit Networking auskennst, kennst Du Firewalls ... usw ... usw

    Jetzt alle moeglichen eventuell zutreffenden Themen mit Quellen herauszusuchen ist ineffizient.

    In diesem Thread sind diverse Moegliche Loesungswege z.T. beschrieben und z.T. angerissen. D.h. Du hast genuegend Stichworte die Du zum Suchen im Netz nutzen kannst ;)

    Ihr seid doch alle Profis. Warum schreibt Ihr die App nicht selber ? Muss ja nicht "schön" aussehen.

    Das ist etwas uebertrieben ausgedrueckt :shy: Es gibt hier vermutlich ein paar Profis zum Thema Firewall, Netzwerk, ESP, Elektronik, ... usw .. usw und vielleicht ist auch einer dabei der sich mit Kameras auskennt. Aber um eine gute und sichere Kameraanwendung zu schreiben braucht man Wissen in Kameratechnik, Netzwerktechnik, Verschluesselungstechnik, Elektrotechnik usw usw .... und vor allen Dingen Zeit :!: . Es mag Kamerahersteller geben die aus Kostengruenden einen Werkstudenten dran setzen so eine Anwendung zu schreiben ... und spaeter wundert man sich wenn die Anwendung unsicher ist weil dem Werkstudenten das notwendige detailierte Wissen fehlt und Hacker aus dem Internet solche Kameras uebernehmen. Und selbst Profis kann es passieren dass sie etwas uebersehen :-/

  • Ihr seid doch alle Profis. Warum schreibt Ihr die App nicht selber ? Muss ja nicht "schön" aussehen.

    Die App ist nur ein Teil der ganzen Geschichte. Das größere Problem und vor allem der größere Aufwand liegt in der Firmware der Kamera, denn es ist genau diese, die Tore und Türen nach draußen öffnet, um den Kunden das Leben zu vereinfachen. Du müsstest erstmal die komplette Kamera reverse-engineeren, um dann deine eigene Firmware zu schreiben, die nur filmt und die Aufnahmen irgendwo bei dir im Netzwerk speichert - "mehr nicht". Selbst das ist noch aufwändig und muss für jeden verwendeten Chip anders umgesetzt werden. Da ist es schon einfacher, wenn man sich seine eigene Kamera mit einem Raspberry Pi oder ESP32-Cam bastelt. Ist dann nicht ganz so schön, aber leichter umzusetzen, als etwas fertiges erst komplett zu analysieren und dann dafür etwas neues zu schreiben.

    Kelvin

  • OK, ich ziehe meine provokante Äußerung zurück und muss erkennen, dass die Kameraproblematik recht komplex ist. Bei der Quellen-Nachfrage stecke ich zurück und werde mich dann im konkreten Fall, auch mit Hilfe des Forums, vorhangeln. Zeit ist bei mir als Rentner im Vergleich zu Euch wohl von geringerer Priorität, aber manchmal dauert es auch mir zu lange, bis ich bei Eigenimplementierung (Android-App!) vom Kenntnisstand Null ausgehend ans Ziel gelange.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!