Kameralösungen gibt es wohl wie Sand am Meer und entsprechend vielfältig sind die denkbaren Szenarios. Abgesehen davon, daß nach meiner persönlichen Meinung alle Kameras, die ausschliesslich über eine Cloudlösung oder Software eines Herstellers erreichbar sind, umgehend zurückgeschickt oder in die Tonne gehören, werde ich nicht viel mehr zu Kamera- oder Softwareeigenheiten eingehen. Mit den folgenden Beispielen sollte jeder in der Lage sein sich seine eigene Lösung zu stricken.
Zwei, bzw drei Situation möchte ich hier beschreiben:
– Netzwerkkameras mit Zugriff via Browser und App
– Ein Rechner mit Aufzeichnungssoftware und Netzwerkkameras
– Aufzeichnungsgerät mit Netzwerkzugriff und angeschlossenen Kameras
Keines der hier gezeigten Beispiele stellt direkten Kamerazugriff aus dem Internet dar – der erfolgt später über eine VPN Verbindung. Alles andere gehört wegen mir auch in die Tonne.
Auf irgendeine Smarthomekiki gehe ich hier auch nicht ein, VideoKlingel ist mal easy auch ohne den Kram hier eingerichtet, gerne dann auch im „DMZ“, also zwischen Plasterouter und gateway. Aber darum geht es hier nicht.
Nein, hier geht es um echte Überwachungssysteme, die mit Bedacht und entsprechendem Verantwortungsgefühl eingesetzt werden sollten, sobald sie mehr als den eigenen Körper überwachen und aufzeichnen. Frau, Kind, Mitbewohner und Gast müssen zugestimmt haben und wissen wo und wann die Dinger aufzeichnen wenn man es ganz streng nimmt. Und da sollte dann schonmal ganz klar sein, das keiner unbefugt an diese Daten kommt.
Kameras haben oft geschlossene Systeme, die zwar über einen „admin“ account konfiguriert werden können, was die Dinger aber tatsächlich sonst noch machen weiss oft nur der Hersteller. Updates sind Mangelware, zumindest bei Billigheimern ( obwohl die mitunter auch echt gute Bilder liefern ), und somit stellen Kameras grundsätzlich ein Sicherheitsrisiko dar.
Und wer jetzt bis hierhin gekommen ist, wird gleich aufschreien:
Wie? das war alles?
Nehmen wir also für dieses Kapitel an, das Subnetz cid ist ein reines Kameranetz. Ergo werden wir dieses Netz so rigide wie möglich dicht machen.
Heisst, wir verbieten alles und nehmen als erstes wieder die Erlaubnis zurück vom Subnetz cid aus via HTTP und HTTPS ins Internet zu kommen, ausserdem erlauben wir den E-Mailversand auch erst wieder nach reiflicher Überlegung, den Empfang schalten wir ab.
Die Namensauflösung via gateway wird ebenso entzogen wie der Zugang zu Zeitservern im Internet. Die Kamera hat es mal garnicht zu interessieren wie die anderen Geräte im Netz heissen, und wir können ja weiterhin garagecam aufrufen….
# DNS access zu unserem lokalen Nameserver # DNS(ACCEPT) loc $FW #DNS(ACCEPT) cid $FW # E-Mailversand für loc, cid und $FW (logwatch & co) ausschliesslich verschlüsselt # ACCEPT $FW net tcp 587 ACCEPT loc net tcp 143,465,587,993 #ACCEPT cid net tcp 143,465,587,993 # nicht alle können oder wollen das, deshalb sei es gestattet # ACCEPT loc net udp 123 #ACCEPT cid net udp 123 # und zuguterletzt immer unser INTERNET # $FW braucht das nur für die Updates # HTTPS(ACCEPT) loc net HTTP(ACCEPT) loc net HTTPS(ACCEPT) $FW net HTTP(ACCEPT) $FW net #HTTPS(ACCEPT) cid net #HTTP(ACCEPT) cid net
Jetzt ist Subnetz cid komplett dicht und keine Kamera kann mehr von sich aus irgendwas nach draussen liefern.
Nun nehmen wir an, wir haben 4 Kameras im Netz, die wir mit unserem Browser einzeln aufrufen können wollen und zusätzlich mit einer App auf Tablet oder Smartphone in einer Übersicht alle Kamerastreams gleichzeitig.
Das läuft direkt so wie es ist, wir müssen nichts machen!
Vom Subnetz loc aus haben wir ja vollen Zugriff.
Was ist denn mit den IP-Adressen vom DHCP? Bekommen die die Kameras jetzt auch nicht mehr?
Und überhaupt, wo ist die Regel eigentlich, die fehlt doch komplett!
Sehr gute Frage!
Nein, in der Datei /etc/shorewall/interfaces haben wir den Parameter DHCP gesetzt. DHCP ist damit grundsätzlich für loc und cid erlaubt.
Ob es jetzt aber eine gute Lösung ist, einen DHCP-Server auf der Firewall zu betreiben, darüber kann man jetzt mal nachdenken.
Wer gerne paranoid ist und sich das auch noch leisten kann, der darf eine Firewall auch ganz allein betreiben und alle anderen Dienste auslagern.
Man kann es aber auch voll übertreiben…..echt ey!
Fragestellungen kommen trotzdem auf:
– möchte ich E-Mails bekommen wenn eine Kamera eine Bewegung erkennt?
– soll die Kamera die Bilder an einem zentralen Ort speichern statt jede auf einer SD-Karte?
– wie kommen die Kameras denn an ihre Zeit, wenn ich ihnen nicht meinen eigenen Zeitserver unter 10.0.1.1 eintragen kann?
Damit eine Kamera mir eine E-Mail schicken kann, muss ich sie dafür konfiguriert haben. Also trage ich dafür auch noch eine Regel in die rules Datei ein, analog zum Eintrag für gateway $FW. Auch die Kamera muss nur versenden, brauch nichts empfangen.
Wie kann die Kamera denn speichern? Meistens via FTP. Haben wir einen FTP-Server? Wo steht der?
Machen wir eine Regel dafür, aber spätestens jetzt sollte man sich fragen, warum nicht einen Rechner mit Aufzeichnungssoftware?
Bei einer Kamera ist das ganze Thema hier übertrieben, aber bei vieren stellt sich diese Frage sehr berechtigt.
Und die Zeit? Das können wir „umbiegen“, dazu gibt es am Ende ein eigenes Beispiel, denn diese Frage stellt sich nicht nur für Kameras.
Nehmen wir also an wir haben einen Rechner mit einer Aufzeichnungssoftware und die vier Kameras:
Aufzeichnungssoftware gibt es für alle Systeme in großer Auswahl mit großen Unterschieden in Funktion und Umfang.
Die Grundfunktionen sind aber immer die gleichen:
– Kameras einrichten ( je mehr, desto teuer )
– Kameras bewegen (Pan,Tilt, Zoom – schon seltener)
– Bewegung erkennen (Standard)
– Aufzeichnen (Standard)
– Alarm (eigentlich auch Standard)
Zwei Lösungen kann ich aus eigener Erfahrung empfehlen:
Wer nicht aufs Geld schauen muss, dem darf ich wärmstens einen neuen MacMini und SecuritySpy empfehlen. Ich mache ungerne Werbung und werde jetzt auch ganz bewusst keine Links setzen, aber das ist in meinen Augen die perfekte Lösung.
Wer wie ich einfach eine zuverlässige Lösung braucht die Bewegung erkennt, aufzeichnet und E-Mails verschickt, dem darf ich ZoneMinder ans Herz legen.
Natürlich lauffähig auf einem Debiansystem, unbeschränkt bezüglich Kameraanzahl und Funktionen.
Aber unbequem einzurichten, nichts fürs Auge und überhaupt….meine Kamera habe ich nie geschafft damit zu bewegen. Kurz, es gibt freie Software da habe ich schon gerne mal gespendet, einfach weil es trotzdem richtig gut ist ( ;-)) ich sag nur Debian oder PiHole ), bei Zoneminder hat es lange gedauert bis ich das Zuverlässig auch mal zu schätzen lernte….
Kurz: Wer bis hierhin gekommen ist, wird auch eine Zoneminder Installation, ( natürlich auf einem extra Rechner ) zum laufen bekommen, Spass und Benutzerfreundlich sind aber Fremdworte in der Zoneminderwelt.
Aber, was passiert jetzt mit so einer Konstellation?
Der Rechner mit der Aufzeichnungssoftware kommt natürlich ins Subnetz cid, – 10.0.1.50 vielleicht?
Dafür sollte die Aufzeichnungssoftware mit dem Webbrowser zu erreichen und konfigurierbar sein!
Das geht auch ohne weitere Regeln.
Die Aufzeichnungssoftware wird jetzt den E-Mailversand übernehmen, Kameras scharfschalten usw.
Mehr muss nicht sein.
# E-Mailversand für loc, cid und $FW (logwatch & co) ausschliesslich verschlüsselt
#
ACCEPT $FW net tcp 587
ACCEPT loc net tcp 143,465,587,993
ACCEPT cid:10.0.1.50 net tcp 587
Wir können alle Kameras mit Browser und App erreichen, die Aufzeichnungssoftware mit Browser bedienen und sie kann uns E-Mails schicken.
Die Aufzeichnungssoftware kann voll auf alle Kameras zugreifen.
Reicht.
Was ist der Unterschied zu einem Aufzeichnungsgerät?
Kein grosser, meist habe ich Aufzeichnungsgerät und Kameras zusammengekauft, manchmal geht beides auch nur zusammen.
Die Kameras hängen dann direkt am Aufzeichnungsgerät und sind nicht direkt ansprechbar. Kann ich das Aufzeichnungsgerät über den Browser erreichen ist alles wie oben, wenn nicht….Du ahnst es schon, Tonne.
Hab ich vom Nachbarn um die Ecke erzählt? Da sind sie vor ein paar Jahren des Nachts eingestiegen und haben die tolle Aufzeichnungskiste direkt auch mtgehen lassen, die stand so nett rum.
Was war jetzt mit RTP und alternativen Ports?
RTP (RealTimeProtokoll) ist ein Streamingprotokoll, meist auf udp 554.
Wenn eine Kamera das kann, (die meisten können das, sonst, jo – Tonne) sollte man das benutzen. Streaming sagt es schon, das ist gut optimiert.
Zoneminder kann das, klar oder? Und jeder andere Versuch mit Zoneminder an die Bilder einer Kamera zu kommen hat das Potenzial einen um den Verstand zu bringen.
alternative Ports sind z.B. wenn ich HTTP nicht wie üblich auf tcp 80 bringe, sondern auf tcp 8000, 8080 oder was immer Dir oder dem Kamerahersteller grade einfällt.
Unsere Regeln betrifft das in dieser Konstellation noch nicht. Sollte eine Kamera auf Port 8000 senden, kommen wir auch da ran. Wir müssen es aber wissen, denn:
http://garagecam
fragt auf Port 80
http://garagecam:8000
führt hier zum Ziel.
( seit die Browser Such- und Adressfeld kombiniert haben, ist das http:// zwingend um im lokalen Netz zu surfen. Ein garagecam führt unmittelbar zu einer Websuche und nicht zu einer Anfrage beim Nameserver! )
Nehmen wir noch ein letztes Beispiel:
Du hast eine oder zwei Kameras, möchtest kein eigenes Subnetz dafür, möchtest sie aber trotzdem abschotten.
# deny cams in my home everything
#
DROP loc:10.0.0.79 net ALL
DROP loc:10.0.0.78 net ALL
DROP loc:10.0.0.79 cid ALL
DROP loc:10.0.0.78 cid ALL
Damit dürfen die beiden Kameras 10.0.0.78 und 79 weder ins Internet, noch zu cid. Ihre Zeit bekommen sie trotzdem von $FW gateway.
Im Subnetz loc dürfen sie zwar jetzt rumschnüffeln, können aber nichts mehr „nachhause“ melden.
Von unterwegs kommen wir über VPN weiter an die Kameras.
Wie? Das war alles?
Ja! Für ein reines Kameranetz war das alles.
zurück <