Netzwerksicherheit "RPi_Cam_Web_Interface"

3.

3.

Und nochmal 3.

Wobei imho der VPN Zugang über den Router realisiert werden sollte.

Gruss

Manche Kameras haben ein Webinterface. Es wäre schlecht dieses zu exponieren, da Sicherheitslücken gerade bei diesen billig Dingern immer wieder vorkommen. Am besten VPN für private Nutzung und das über den Router z.B. realisieren.

Wenn man das der Öffentlichkeit zur Verfügung stellen möchte, kann man die Kamera auch die Bilder auf einem Server via FTP hochladen lassen.

Hallo Tuevtl,

Punkt 1 ist nicht das was du willst, daher scheidet es aus.

Punkt 2 wäre möglich, allerdings gibt es dabei viel zu beachten, denn sicher ist das überhaupt nicht. Sicherheit bringt hier TLS in Kombination mit einem schwer erratbaren Usernamen / Passwortschutz. Die Sicherheit muss also erst hergestellt werden. Zum Beispiel bei normaler Basic Authentication, wie sie bei motion verwendet werden kann, hast du noch viele unsichere Faktoren. Der Stream ist nicht verschlüsselt, Benutzername und Passwort sind auch nicht geschützt, sondern nur leicht codiert. Neben Ratespielen kann also auch mitgelesen werden.

Punkt 3 wäre das Beste.

Punkt 4 ist die Alternative mit SSH zu arbeiten. Z.B. ein dynamischer Tunnel und dann im Browser den SOCKS Proxy konfigurieren oder ein direkter Portforwarding-Tunnel zur Weboberfläche. Dafür benötigt man einen SSH-Client auf den Endgeräten.

Quote from FSC830

Wobei imho der VPN Zugang über den Router realisiert werden sollte.

Wenn es doch das "RPI-Cam-Modul" ist, warum sollte dann der VPN-Zugang _über den Router_ realisiert werden?

Warum soll das besser sein, als direkt via PI?

Weil ich davon ausgehe, das der Rest vom LAN ebenfalls durch einen VPN Zugang auf dem Router geschützt ist.

Ist der Router "offen" und VPN "nur" auf dem Pi, dann ist der Rest vom LAN angreifbar. Daher meine Meinung, das der VPN-Zugang auf dem Router sein sollte.

Gruss

Quote from FSC830

Ist der Router "offen" und VPN "nur" auf dem Pi, dann ist der Rest vom LAN angreifbar.

Das verstehe ich jetzt nicht. Warum soll der Router "offen" sein, wenn man eine direkte VPN-Verbindung (durch den Router) zum PI herstellt? Oder was genau meinst Du mit "offen", wenn es um den Router geht?

Mit einem offenen Router meine ich solche Konfigurationen, die z.B über "einfache" Portweiterleitungen Dienste im LAN von außen erreichbar machen.

Ich halte es für besser, immer - egal auf was zugegriffen wird - einen VPN Zugang für das gesamte LAN einzurichten und keine Ports direkt erreichbar zu machen.

Daher würde ich den VPN Zugang immer auf dem Übergang WAN-LAN, also Router bzw. Firewall einrichten und nicht auf einem Server hinter dem Router.

Gruss

Quote from FSC830

Daher würde ich den VPN Zugang immer auf dem Übergang WAN-LAN, also Router ...

OK, ... genau das Gegenteil wie ich es mache. Ich würde z. B. das AVM-VPN (IPsec) nie benutzen. Dafür aber Wireguard (oder OpenVPN) mit einem Gerät am Router.

Na ja, ich rede von VPN, nicht von Kinderkram . Sophos, OpenSense oder pfSense z.B., wobei das AVM VPN besser ist als Portweiterleitungen.

Aber sonst hast Du Recht.

Gruss

Quote from FSC830

Sophos, OpenSense oder pfSense z.B., ...

Aber für ein border device mit diesen OSs, brauchst Du entweder einen "modifizierten" Router oder einen Internetanschluss mit z. B. transparentem Modem, mit dem das border device dann die externe/öffentliche IP-Adresse bekommt. Wenn das nicht der Fall ist (wie hier beim TE), muss man im Router Portweiterleitungen (oder exposed host) konfigurieren.

BTW: Das AVM-VPN kann nicht besser sein, weil die AVM-Firmware m. E. immer eine Schwachstelle ist und bleibt (... im Vergleich zu einem Gerät mit einem OS zu 100% open source)

Quote from rpi444

Wenn das nicht der Fall ist (wie hier beim TE),

Habe ich diesen Thread noch nicht entnehmen können, welcher Anschluss hier vorhanden ist -

Quote from rpi444

Das AVM-VPN kann nicht besser sein, weil die AVM-Firmware m. E. immer eine Schwachstelle ist und bleibt

Ich meinte es so, das ich auch das AVM-VPN anstelle einfacher Portweiterleitungen in der Fritz vorziehen würde, nicht gegenüber openVPN.

Wird aber jetzt zu OT.

Gruss

Quote from FSC830

Habe ich diesen Thread noch nicht entnehmen können, welcher Anschluss hier vorhanden ist -

Kann man aber ableiten aus folgender Formulierung im 1. Beitrag:

Quote

Mir sind folgende Möglichkeiten eingefallen:

Portfreigabe eines ungewöhnlich hohen Ports im Router (z.B. Port 10123), und Portforwarding mit fixer Domain eines Dyn DNS Anbieters (z.B. duckdns.org). Wie hier beschrieben

Die Kamera im heimischen WLan betreiben und von unterwegs über VPN (eigener VPN-Server mit OpenVPN auf Raspberry4) darauf zugreifen.

... und btw., wer das hat was Du beschrieben hast, wird nicht so hier anfragen.

AVM-VPN war gemeint, das ist relativ schwach gegenüber dem VPN einer "echten" Firewall Lösung wie pfSense/Sophos oder F5.

Besser als kein VPN (IMHO), aber eben nicht so gut wie die aufgeführten. AVM kann z.B. nur IKEv1, außerdem war die Fritzbox mit VPN bisher eine chte Spassbremse. An einem VDSL 100 gingen mit VPN selten mehr als 7-8MB/s über die Leitung. Das hat sich mit dem aktuellen FritzOS deutlich gebessert (hören/sagen), ist aber z.B. von einer Netgate mit pfSense noch meilenweit entfernt.

Wer z.B für ein regelmäßiges Backup eine Site-2-Site VPN Verbindung benötigt, für den wäre das nicht die beste Wahl.

Dazu kommt, das es z.B. für Windows nur einen relativ alten Shrewsoft Client gibt. Vom Fritzfernzugang halte ich nichts, den hatte ich mir einmal angesehen und das war so was von schrottig, der war keine 24h im Einsatz. Das ist aber mind. 2 jahre her, aber soweit mir bekannt, hat sich auch nicht viel getan.

Zugegebenermaßen muss man natürlich auch die Kosten gegenüber stellen, eine Fritz ist mit - rund gesagt - 150,--€ für den Otto Normalverbraucher sicherlich ausreichend, aber bei etwas höheren Ansprüchen nicht. Und dann kommen schon mal schnell 300-400,--€ zusammen für eine andere Lösung.

Bei mir läuft z.B, ein DrayTek im reinem Modem Betrieb mit einer Netgate Appliance dahinter.

Gerade gegenwärtig laufen wieder hunderte bzw. (mehr)tausende Angriffe gegen QNAP NAS (klick).

Nun setzte ich mein NAS auch nur als NAS ein, und nicht als Super-Duper-eierlegende Wollmilchsau die von überall in der Welt zugreifbar sein muss.

Und in den vergangenen Jahren hat das NAS noch nie ungebetene Besucher gehabt .

Insofern vertraue ich meiner Firewall Lösung, und den anderen Mitbewohnern habe ich mit dem Vorschlaghammer eingetrichtert, keine Mail/Anhänge von unbekannten Absendern oder Spendern ("I will give you 10 Mio dollars, please send me your account...") zu öffnen .

Gruss

Hallo Tuevtl,

zunächst Portforwarding per se kann nicht unsicher sein. Es gibt Fallstricke wie automatische Portöffnungen oder Exposed Host / Fake DMZ / Schwachstellen im Router aber mit der richtigen Konfiguration kann man auch einen OpenVPN oder Wireguard Server betreiben. (Oder wie nachfolgend den SSH Port forwarden)

Nun also zum Thema SSH:

Einfacher für den Anfang ist es ein Passwort zu benutzen. Das Problem ist, dass es viele ferngesteuerte Rechner gibt, die dann versuchen dein Passwort herauszubekommen, um deinen Rechner auch fernzusteuern. Daher sollte diese Art sich einzuloggen wohlüberlegt (Benutzer / Passwortkombination nicht zu erraten) oder gar nicht erlaubt sein.

Man kann sich auch ohne Passwort einloggen. Das passiert dann automatisch über (Authentication) Keys, wenn du dich verbinden möchtest.

Dann sollte der Server hinterher so konfiguriert werden, dass PasswortLogin nicht möglich ist.

Die Clients generieren dazu mit einem Befehl ein zusammengehörendes Schlüsselpaar zum Einloggen: ssh-keygen ... Hinterher brauchst du noch einen Befehl ssh-copy-id .... Das schiebt einen Key davon auf den Server. Man kann beim Generieren auch eine "Passphrase" benutzen (Passwort für die Keyfile). Im Falle des Keyverlusts bist du erstmal auf der sicheren Seite. Wenn der Laptop in der Bahn aus geht und dann aus Versehen vergessen wird, ist der Key zwar weg, aber das Passwort für die Keyfile ist dem Finder nicht bekannt. Durch die Passphrase muss man zum Verbinden zwar wieder ein Passwort eingeben, aber das ist diesmal für den Key und nicht für den SSH-Server.

Andere Sachen kann man noch konfigurieren, aber das wäre erstmal eine wichtige Grundlage. Wenn das klappt, wird PasswortAuthentication im Server ausgeschaltet.

SSH kann mehr als Rechner fernzusteuern. Es ist möglich einzelne Ports weiterzuleiten. Über das Internet tunnelst du (verschlüsselt) den Zugang zu deinem Webinterface mit einem einfachen SSH Befehl auf dem Laptop:

ssh -p 10356 -L 80:localhost:80 pi@deineipoderdyndnsvomraspberry 

Anschließend kannst im Browser vom Laptop http://localhost eingeben und kommst zu deinem Webinterface. Die Verbindung ist durch den Tunnel verschlüsselt. Der Port ist in dem Beispiel wahllos 10356, weil du den Port am Router verändern wolltest. Der Port 10356 muss dann zum Raspberry Port 22 weitergeleitet werden.

Du kannst auch einen anderen Befehl nehmen ssh -D 12345 -p 10356 pi@deineip und im Browser die Proxykonfiguration für SOCKS5 vornehmen (auf localhost den "D"ynamischen Port 12345, dafür das D). Die Verschlüsselung kommt durch SSH. Dann kannst du im Webbrowser wie im eigenen LAN "192.168.178.1" eingeben und z.B. den Router aufrufen (Beispiel für Fritzbox) und auch deine anderen Server über ihre LAN Adressen erreichen. Du bekommst damit auch die IP von deinem Heimnetzwerk, wenn du im Internet surfst.

Mit "scp" kannst du sogar Dateien übertragen. SSH ist also vielseitig einsetzbar. Es ist eine Alternative um den Fernzugriff zu ermöglichen. Die Einsatzzwecke überschneiden sich zwar teilweise mit einem VPN, sind aber nicht identisch.