Cam-Events

Mit zuhause eingesetzten IP-Cams Haus, Wohnung, Hof und Eigentum überwachen

Auch das ist mal wieder ein schwieriges Thema... hier allerdings weniger IT-Technisch, dafür umso mehr bezogen auf die Realitäten des Lebensalltags. Natürlich ist dieses Projekt auch hinsichtlich der IT-Technik in einem gewissen Umfang herausfordernd, nur nicht so sehr durch den Schwierigkeitsgrad der technischen Umsetzung, dafür eher mehr durch Logistik und Komplexität ... letztendlich läuft es hier nämlich fast durchweg auf eine Daten-Transport-Logistik hinaus, die ordentlich gesteuert logisch und in definierter Reihenfolge ablaufen muss, so das sich alles zum richtigen Zeitpunkt an seinem richtigen Ort befindet. Aber hinsichtlich unseres Lebensalltags ist eher das Fazit relevant, dass man ab einem gewissen Punkt des erworbenen Wissens auch bei solchen Sicherungsmaßnahmen immer irgendwann vor der Erkenntnis steht, dass man Einbruchsprofis nur mit IP-Cams sowieso nicht abhalten kann. Vielleicht wirken Außen-Kameras bei den eher gering-cleveren Amateuren abschreckend, aber erfahrene Leute wissen ganz sicher damit umzugehen, davon bin ich überzeugt. Mittlerweile und nach mehreren Jahren Betrieb unserer IP-Cams habe ich heute auch gar nicht mehr die Absicht einen Einbruch zu verhindern. Bei uns ist eh nix zu holen - aber ich empfinde es auf Reisen dennoch als sehr beruhigend, wenn ich mich morgens kurz davon überzeugen kann, dass gartenseitige Fenster und Türen nach der Nacht noch völlig intakt sind.

Einmal -daran erinnere ich mich immer wieder- haben wir noch abends aus dem Urlaub nachhause angerufen und unsere etwas betagte Blumengießerin darüber informiert, dass die Terrassen-Rollladen hoch sind. Ihr Schreck war groß „Oh, ich war draußen und habe die Blumen gegossen... habe ich die Rollladen wirklich vergessen?“ ... „jau, haste“. In diesem Fall empfand ich die Cam als sehr hilfreich. Aber auch wenn es wirklich im Fall der Fälle mal gelingen sollte, wegen der SMS-Benachrichtigung frühzeitig die Polizei hinzuziehen, um darüber vielleicht dafür sorgen, dass irgendwelche Amateure aus der Wut heraus, nichts brauchbares mitnehmen zu können, einfach nur unsere Wohnung verwüsten, würde ich im Nachgang sagen, die IP-Camera war hilfreich. Der für mich wichtigste Aspekt ist jedoch unzweifelhaft, falls wirklich einmal ein Einbruch durch Gewaltanwendung an Tür oder Fenster erkennbar ist, sofort jemand aus der Familie hinschicken zu können, der dafür sorgt, dass Eingänge oder Fenster bis zu unserer Rückkehr nicht offen bleiben.

Um ganz am Ende kommt auch noch wieder ein persönlicher Aspekt hinzu, ich habe nämlich durchaus auch ein wenig Spaß an solchen technischen Spielereien, gerade auch und am meisten an der Software-Entwicklung und ich mach's halt, weil ich's kann.

Inhaltsübersicht über die Kapitel dieses Artikels:

> Anforderungsprofil

> Festlegen von Rahmenbedingungen und Beschreibung der Teilprozesse

> systemd-nspawn-Container

> Erstellen der Binaries für telegram-cli

> Installation der benötigten Services

> Einrichten der Services

> Abschluss-Test der neuen Services

> Einrichten der Jobs

> Ein paar Überlegungen zur Sicherheit

> Haftungsausschluss

Anforderungsprofil

Mein heutiges Setup unterscheidet sich vollkommen von der Ausgestaltung meines ersten Cam-Setups, das mittlerweile ca. 8 Jahre zurückliegt. Es sind dabei weniger technische Unterschiede bemerkbar, dafür haben aber die sicherheitsrelevanten Parameter eine deutlich größere Beachtung erfahren. Damals hatte ich mir absolut keine Gedanken über den möglichen Missbrauch von IP-Camera-Daten oder Datenschutz allgemein gemacht. Das lag garantiert zum Teil auch an meiner Sorglosigkeit und meiner Gutgläubigkeit, dass sich niemand für mich interessieren wird ... und vermutlich auch daran, dass digitale Übergriffe im großen Stil, wie man sie heute immer wieder in den Medien liest, wohl eher nicht die Regel waren. Da gab es Viren und Daten-Zerstörung durch Viren, aber die Aspekte staatliche Überwachung, Entmündigung der digitalen Privatsphäre und Enteignung der Verfügungshoheit auf die eigenen Daten durch unsere Gesetzgebung und Staatstrojaner (Danke all dafür!), dann die Daten-Kraken wie Google, Amazon und heute auch Microsoft, dazu spezielle Software in spezieller Hardware (IOT, Alexa, etc.), die darauf ausgerichtet ist, dass alltägliche private Leben kontinuierlich zu beobachten ... das gab es damals in der Form nicht. Deswegen mache ich mir heute deutlich mehr Gedanken über die von mir eingesetzte Hardware. Sicherheit und die Bewahrung meiner Privatsphäre ist eines meiner primären Interessen. Aus diesen Überlegungen sind dann die folgenden Anforderungen für unsere Hausüberwachung entstanden.

Primäre Hardware- und sicherheitstechnische Anforderungen:
➢	Ein Zugriff von außerhalb des lokalen Netzwerks (also aus dem Internet) auf die IP-Cams ist untersagt, um zu verhindern, dass eine Fremdkontrolle der Kameras erfolgen kann (also unter gar keinen Umständen geöffnete Ports im DSL-Router).
➢	Den IP-Cams selber wird der Zugang zum Internet vollständig untersagt, um sicherzustellen, dass sich ein Cam-Interner proprietärer Web-Server nicht über eine Reverse-Connection als unkontrollierbare Schadsoftware im eigenen Netzwerk erweist.
➢	Eine möglicherweise vorhandene WLAN-Funktion muss deaktiviert werden können (was bautechnisch natürlich nur dann möglich ist, wenn eine Netzwerkanbindung via Patchkabel möglich ist, ansonsten ist das ein Ausschlusskriterium).
➢	Die IP-Cams bekommen keine Erlaubnis, selber Nachrichten (z.B. via Email zu versenden)
➢	Die Aufnahmen der IP-Cams dürfen das lokale Netzwerk nicht unverschlüsselt verlassen.
➢	Die IP-Cams müssen über ein Web-Interface/GUI für das Setup verfügen, welches auf beliebigen Endgeräten mit einem normal-üblichen Internet-Browser für das Customizing geöffnet werden kann (Admin-Zugang, adressiert über eine Static-Custom-IP).
➢	Die Cams müssen einen View-Mode auf beliebigen Endgeräten via normal-üblichen Internet-Browser ermöglichen (Client-Zugang).
➢	Der Cams müssen einen View-Mode von beliebigen Betriebssystemen (Windows, Linux, Android) ohne proprietäre Client-Software ermöglichen.
➢	Die IP-Cams müssen über einen integrierten Infrarot-Strahler mit automatischer Umschaltung (IR-Cut-Filter) verfügen.
➢	Die Cams müssen über 2 bis 4 skalierbare und separierbare Area-Settings verfügen und zudem Einstellungen über Sensitive-Settings ermöglichen. Area-Settings sind ausgewählte Teilbereiche im gesamten Bild-Bereich, so dass z.B. explizit eine Tür oder ein Fenster als primärer Alarm-Sektor innerhalb des Gesamt-Bildes deklariert werden können. Das heißt, nur Motion-Detects in den definierten Areas lösen die Alarm-Prozesskette aus. Sensitive-Settings verhindern, dass Regen, Schneefall, Motten, ein Spinnennetz vor dem Objektiv oder eine Katze für Daueralarm sorgt.
➢	Die Cams müssen vollständige Funktionalität auch ohne OEM-Cloud-Verpflichtung ermöglichen (z.B. bei Verwendung einer lokalen Cloud oder eigenem FTP-Server).
➢	Die Anbindung an jegliche andere kommerziell betriebene Cloud, wie z.B. Google-Drive, MS OneDrive, Dropbox, etc., wo private Daten durch Verwendung und Vermarktung die Grundlage deren Geschäftsprozesse zur Gewinnerwirtschaftung darstellen, wird als datenschutz-technische Katastrophe wegen gravierender Missachtung der digitalen Privatsphäre konsequent ausgeschlossen.
➢	Die Cams müssen einen frei einstellbaren FTP-Server verwenden können, auf dem zu speichernde Aufnahmen abgelegt werden.
➢	Die übliche DirectX- und Windows-Explorer-Abhängigkeit chinesischer Billig-IP-Cams ist ein Ausschlusskriterium für eine IP-Cam.
➢	Jegliche zusätzliche proprietäre Pflichtanbindung resp. für den Betrieb notwendige zusätzliche Client-Software ist ebenfalls ein Ausschlusskriterium.
Weitere sekundäre Anforderungen:
➢	Der spätere Betrieb muss wartungsarm und für mich weitestgehend aufwandsneutral erfolgen (ich will mich nicht ständig drum kümmern müssen).
➢	Der Zugriff auf die IP-Cams erfolgt nur LAN-Intern
➢	Sofern ein Zugriff über das Internet notwendig ist, erfolgt dieser über eine OpenVPN-Verbindung (... also trotzdem nur LAN-Intern.)

Jetzt habe ich solche umfassenden Anforderungen formuliert.... welche IP-Cams können das denn alles leisten? Das ist leider nicht so einfach pauschal zu beantworten. Vermutlich wird es auch IP-Kameras aus der chinesischen Billig-Massen-Produktion geben, die diese Anforderungen erfüllen. Ist halt immer ein bisschen auch Glücksache, weil man erst sieht, was die IP-Cam kann, wenn man sie angeschlossen hat. Ich habe jedenfalls keine guten Erfahrungen mit diesem chinesischen Elektronikschrott gemacht, sie zurückgeschickt und würde heute immer davon abraten. Ganz besonders bei den Cams mit der teilweise noch obligatorischen DirectX-Abhängigkeit. Ich habe mich vor einiger Zeit für zwei Instar IN-6001HD und eine IN-9020FHD entschieden, die rückblickend betrachtet alle meine Anforderungen erfüllen. Alle Kameras beobachten während unserer Abwesenheit nur Eingangstüren und Fenster, von innen und von außen. Ich spreche jetzt hier keine Kaufempfehlung aus, und natürlich mache ich auch keine Werbung für Instar... ich sag nur, dass diese IP-Cams sich perfekt in unsere Debian-System-Umgebung eingefügt haben und genau das tun, was ich von ihnen erwarte.

Festlegen von Rahmenbedingungen und Beschreibung der Teilprozesse

Ich halte es immer für eine gute Idee, ein mehr oder weniger kompliziertes Projekt in einzelne Teilschritte zu zerlegen, bei dem ich mich dann mit der Lösung eines jeden Einzelschritts exklusiv befasse, ohne mich dabei von anderen und noch kommenden Belangen oder Problemen ablenken zu lassen. Deswegen werde ich die jeweilige Installation für jeden Teilprozess einzeln beschreiben. Natürlich habe ich zu Beginn schon eine genaue Vorstellung davon, was ganz am Ende dabei rauskommen soll. Und genau dafür gibt es ein kleines Pflichtenheft

» Cam-Daten sollen nur nach einem Motion-Detect innerhalb eines vorgegebenen Areas gespeichert werden

» Aus Gründen des immens hohen Speicherbedarfs sollen keine Streams gespeichert werden

» Es soll pro Motion-Detect-Alarm nur eine vordefinierte Anzahl Bilder als Bildfolge gespeichert werden, z.B. 6 Sekunden lang 1 Bild pro Sekunde)

» Die Speicherung der jpeg-Dateien muss auf meinem lokalen FTP-Server erfolgen

» Es muss berücksichtigt werden, dass im Familien-Normal-Alltag die Familie selber über den ganzen Tag Fehlalarm-Aufnahmen erzeugt

» Weil täglich mehrere tausend Bilder im Familien-Normal-Alltag gespeichert werden, müssen alte Dateien kurzfristig automatisch gelöscht werden

» Wegen des extrem hohen Datenaufkommens für Bildspeicherung soll die Speicherung auf dem FTP-Server nur in einem tmpfs-Speicher (RAM-Disk) erfolgen

» Der FTP-Server soll als 'isolierte Funktion' in einer VM laufen

» Zur Sicherung aktueller Daten muss zyklisch und zeitnah eine Übertragung aktueller Bildaufnahmen nach außerhalb (Web-Space) erfolgen

» Alle nach außen übertragenen Daten werden nur verschlüsselt übertragen

» Wegen des hohen Speicherbedarfs muss auch der Web-Space täglich bereinigt werden

» Für die permanent geschriebenen Logs muss ein Log-Rotate implementiert werden

» Es muss eine einfache Anwender-Schnittstelle für primäre Einstellungen von Client-Seite implementiert werden

» Einstellungen müssen möglichst Client- bzw. OS-neutral ohne explizit entwickelte Software vorgenommen werden können

Bevor es an die tatsächliche Implementierung geht, verschaffen wir uns anhand der folgenden Grafiken einen Überblick darüber, welche Aufgabe jeder Teilprozess quasi als gekapselter Prozess hat. Das bedeutet, jeder Teilprozess erfüllt eine Aufgabe, ohne dass er sich darum kümmert, welche anderen Aufgaben andere Prozesse haben. Natürlich spielt das alles irgendwie ineinander, aber es gibt keine Abhängigkeiten dergestalt, dass ein Prozess abstürzen würde, nur weil ein anderer Prozess nicht arbeitet.

TP 1 = Generate

Im Teilprozess 1 ist eingerichtet, dass die IP-Kameras Bilddaten auf einen per IP-Adresse adressierten FTP-Server in einem je Cam vorgegebenen Zielverzeichnis speichern können. Die Zugangsdaten zum FTP-Server sind in den IP-Cams eingestellt.

Die Cams speichern nach einem motion-detect innerhalb eines oder mehrerer vorgegebenen Areas eine Bildfolge auf einen lokalen FTP-Server. Der FTP-Server ist in einer VM auf unserem lokalen und durchgängig verfügbaren LAN-Server eingerichtet.

Aufgrund des sehr hohen Datenaufkommens mit mehreren 1000 Aufnahmen pro Tag soll die Speicherung der Bilddaten zur Entlastung der SSD nur im Hauptspeicher erfolgen. Die Freigaben für FTP und Samba zur Speicherung der Bilddaten sind in einer 1 GB-Ram-Disk eingerichtet. Alle gespeicherten Aufnahmen sind somit flüchtig und der Speicherplatz ist begrenzt. Diesem Umstand wird in TP 3 Rechnung getragen.

Die Speicherung der Bilddaten erfolgt in je einem eigenen Unterverzeichnis für jede Web-Cam.

Die Entscheidung, die jeweilige IP-Adresse der Web-Cam als Verzeichnisnamen zugrunde zu legen, ist eine willkürliche Entscheidung von mir, mit der Absicht, die Verarbeitungswege offensichtlich zu machen.

Was bedeutet das IP-Netz 10.0.1.0/24? Ganz einfach, das ist eine für meine Dokumentationen verwendete Netzwerk-Adresse. Siehe dazu auch Security und OpenVPN. Gleichbleibende Adressen vereinfachen das Verständnis über das Zusammenwirken dieser 3 Lösungen.

TP 2 = Alarm

Der Teilprozess 2 ist der Alarm-Prozess. Losgelöst vom durch die IP-Cams erzeugten Datenstrom aus TP1 überprüft dieser lokale Job im 5-Minuten Rhythmus den ganzen Tag über und rund um die Uhr in den oberhalb bezeichneten Verzeichnissen, ob in den letzten 5 Minuten neue Bilddateien angelegt wurden. Wenn festgestellt wurde, dass neue Bilddateien vorhanden sind, müssen in diesem Teilprozess 2 primäre Dinge erledigt werden.

1. Weil die Speicherung hier auf einem flüchtigen Speicher erfolgt, und zwar einer RAM-Disk, auf der die Bilder ein Ausschalten des Systems nicht überleben würden, müssen die neuen Bilder der letzten 5 Minuten unverzüglich nach extern gesichert werden. Extern bedeutet hier Web-Space bei meinem Internet-Homepage-Provider. Und gerade auch die Tatsache, dass Bilddateien umgehend nach außerhalb gesichert werden, ermöglicht es überhaupt, die initiale Speicherung hier nur auf einer 1-GB-RAM-Disk durchzuführen. Die Übertragung ist auch deswegen ungemein wichtig, weil ich damit immer von außerhalb Zugriff auf die Daten habe, selbst wenn mein Home-Server durch Sabotage vom Strom getrennt werden würde. Die betroffenen Bilddateien werden zunächst in ein Tar-File gepackt, dann mit GNUPG verschlüsselt und schließlich via FTP-Client versendet. Damit sind sie vor Fremdzugriff absolut sicher aufbewahrt.

Bei jedem versendeten Paket wird zusätzlich eine lokale Paketliste gepflegt, in der der Name des aktuellen Pakets angefügt wird. Die Paketliste ist später wichtig, um darüber nicht mehr benötigte Alt-Pakete zu löschen. Ohne Löschung würde der Web-Space irgendwann wegen der kontinuierlichen Anhäufung von Alt-Daten überlaufen.

2. Als zweites will ich über das von einer IP-Cam festgestellte Motion-Detect-Ereignis eine Benachrichtigung erhalten. Wir sind ja schließlich nicht zuhause, also wer war das?

Ist die Benachrichtigung nicht generell deaktiviert, wird spätestens 5 Minuten nach dem Ereignis eine Benachrichtigung versendet. Hier sind es sogar 2, eine SMS, einmal via Telegram-CLI.

Bei diesem Prozessschritt handelt es sich um eine nachgeschaltete Ereigniserkennung auf Datei-Ebene. Wenn in den letzten 5 Minuten Aufnahmen angelegt wurden, ist irgendwas passiert, die Cams haben auf irgendwas reagiert.

Die Benachrichtigung kann sowohl flexibel generell aktiviert oder deaktiviert werden, als auch via Viertelstunden-Einstellungen über den Tag verteilt zeitweise aktiviert werden.