Zum Inhalt springen
Bad Ragaz SG, Schweiz

Steffen Broszeit

MSR-Technik · Gebäudeautomation · Schnittstelle OT / IT-Sicherheit

Fokus: OT-Security, IoT-Security, Gebäudeautomation und Systemintegration

Sechs Jahre habe ich Anlagen gebaut, programmiert und in Betrieb genommen, in Spitälern, in der Industrie und im Retail. Jetzt will ich sie absichern.

Profil

Profil: Neugier bringt mich an eine Sache heran. Hartnäckigkeit bringt sie zum Laufen.

Angefangen habe ich als Elektriker. Achtzehn Jahre Installation, von der Lehre bis zur Bauleitung ganzer Objekte. 2020 bin ich in die MSR-Technik gewechselt, ohne je eine SPS programmiert zu haben. Vier Jahre später habe ich Projekte in der Gebäudeautomation geleitet, durchgehend bei laufendem Betrieb: in Spitälern, im Retail und in der Lebensmittelproduktion.

Neues lerne ich am schnellsten an der echten Sache. Mich interessiert nicht nur, dass etwas funktioniert, sondern warum. Deshalb läuft bei mir zu Hause eine eigene Serverumgebung mit eigener Gebäudeautomation, und Geräte baue ich lieber selbst, als sie nur zu kaufen.

Eine Störung ist für mich erst erledigt, wenn ich die Ursache kenne, nicht wenn der Workaround hält. Und fertig ist etwas erst, wenn ich es geprüft habe. Ein Backup gilt bei mir erst als Backup, wenn die Wiederherstellung einmal geklappt hat.

Aus dieser Arbeit ist die Frage entstanden, die mich heute antreibt. Automationsanlagen hängen längst am Netz, gebaut wurden sie dafür nie. Wie sichert man sie ab, ohne den Betrieb zu gefährden? Die Anlagenseite kenne ich von innen. Die IT-Seite erarbeite ich mir seit Jahren in eigenen Projekten.

Was ich suche

Was ich suche: Anlagen und Geräte absichern, die ich von innen kenne

Eine Stelle, in der Anlagenwissen und IT-Sicherheit zusammenkommen.

Schwerpunkt

OT-Security in der Gebäudeautomation

Automationsnetze in Spitälern, Industrie und Publikumsanlagen absichern, ohne dass eine Anlage stehen bleibt. Bestandsaufnahme, Segmentierung, sichere Fernwartung und das Gespräch mit den Leuten, die die Anlagen betreiben.

Sicherheit vernetzter Geräte (IoT)

Mikrocontroller, Funkmodule, smarte Aktoren: Solche Geräte baue und verdrahte ich selbst. Mich interessiert, wie sicher sie sind, von der Schnittstelle auf der Platine bis zur Anbindung an die Cloud.

Gebäudeautomation mit IT-Tiefe

Wo Leitebene, BACnet und Serverumgebung aufeinandertreffen, verstehe ich beide Seiten. Eine Rolle, in der ich Anlagen weiterhin umsetze, aber mit dem Blick auf ihre Sicherheit.

Region: Sarganserland, St. Galler Rheintal, Liechtenstein, Graubünden und Raum Zürich

Verfügbar: ab sofort · Pensum: 80–100 %

Eigene Projekte · seit 2022

Eigene Projekte: Gebaut, in Betrieb genommen, im Alltag bewährt

Was ich in eigenen Projekten umgesetzt habe, mit dem, was dabei schwierig war. Zuerst die Sicherheit der eigenen Umgebung, darunter die Automations- und Softwareprojekte, auf denen sie aufbaut. Ein Klick auf eine Kachel zeigt die Details.

Datenverkehr läuft auf einer Leitung vorbei, eine Kopie davon führt zu einem Bildschirm mit Messkurve, auf der eine Spitze markiert ist
ZeekSuricataIDSLokiGrafana

Passives Netzwerk-Monitoring

Ein Sensor liest den Verkehr zwischen Heimnetz und Router mit, ohne selbst ein einziges Paket zu senden. Zeek beschreibt, was im Netz passiert, Suricata meldet Verdächtiges. Der erste Befund war mein eigener Fehler.

Details
Schema des Monitorings: Der Switch kopiert den Verkehr zwischen Heimnetz und Router auf einen Spiegelport. Dort liest der Sensor mit, ohne eigene Adresse und ohne selbst zu senden. Zeek beschreibt die Verbindungen, Suricata meldet Treffer auf Erkennungsregeln. Ausgewertet wird in Grafana, im Heimnetz und per VPN, nicht öffentlich. Uplink Internet Router Switch Heimnetz Spiegelport · Kopie des Uplinks Zeek Suricata beschreibt meldet Sensor Lauschanschluss ohne Adresse, sendet nichts Loki, Grafana · nicht öffentlich

Die erste Woche mit Suricata

  • 150 731Alarme am ersten vollen Tag, fast alle auf der untersten Stufe
  • ~470Alarme pro Tag im Schnitt nach dem Tuning, keiner auf der höchsten Stufe
  • −99,7 %ohne eine einzige Erkennungsregel abzuschalten
Ausgangslage
Bevor ich das Heimnetz in Zonen aufteile, will ich wissen, wer darin mit wem spricht. Eine Inventarliste sagt, was da sein sollte, der Verkehr zeigt, was tatsächlich passiert. In Automationsanlagen ist das der übliche Einstieg: Auf einer Steuerung installiert man keine Überwachungssoftware, man liest am Netzwerk mit.
Umsetzung
Der Switch kopiert den Verkehr zwischen Heimnetz und Router auf einen Spiegelport. Dort hängt eine eigene Netzwerkkarte des Sensors, ohne Adresse und ohne je ein Paket zu senden. Auf dem Sensor arbeiten zwei Werkzeuge mit getrennten Rollen: Zeek protokolliert jede Verbindung, jede Namensauflösung und jeden verschlüsselten Verbindungsaufbau. Suricata prüft den Verkehr gegen rund 53 000 öffentliche Erkennungsregeln und meldet Treffer. Beide Protokolle landen in Loki und werden in Grafana ausgewertet, erreichbar im Heimnetz und von unterwegs per VPN, aber nicht öffentlich. Eine gemeinsame Kennung pro Verbindung führt von jedem Alarm direkt zur passenden Verbindung. Den öffentlich erreichbaren Dienst sieht der Sensor nur als verschlüsselten Tunnelverkehr. Deshalb schreibt die Rezept-App ihre Anmeldungen, gelungene wie abgewiesene, in dieselbe Auswertung. Die Aufzeichnungen löschen sich nach 30 Tagen selbst: lang genug, um Auffälliges mit dem Normalbetrieb der Vorwochen zu vergleichen, und nicht länger als nötig. Was nicht gespeichert ist, kann auch nicht abfliessen.
Knackpunkt
Ein Sensor, der Pakete verliert, meldet trotzdem nichts Auffälliges. Das Dashboard zeigt deshalb zuerst, ob der Sensor selbst gesund ist. Im Normalbetrieb verwirft Zeek selbst keine Pakete, die Grenze liegt bei der USB-Netzwerkkarte am Spiegelport: Im Mittel geht weniger als ein halbes Prozent verloren, bei grossen Übertragungen wie dem nächtlichen Backup in Spitzen einige Prozent. Als ich den ganzen Server aus der Sicherung zurückgespielt habe, fast mit voller Gigabit-Geschwindigkeit, war der Sensor für die Dauer der Übertragung weitgehend blind. Dazu läuft die Auswertung auf derselben kleinen Maschine wie der Mitschnitt: Eine einzige Abfrage über 16 Stunden hat den Sensor minutenlang Pakete verlieren lassen. Seither ist die Datenbank gedrosselt und steht bei Rechenzeit und Speicher hinter dem Mitschnitt zurück. Die zweite Hürde ist die Alarmflut. Der einzige Alarm der höchsten Stufe war ein Fehlalarm: Eine Regel für Tauschbörsen prüft nur zwei Bytes, und die Gerätesuche des Routers traf sie zufällig. Das Gros der Alarme sind Verbindungsprüfungen, mit denen Videostreams und das VPN ihren Weg durch den Router suchen. 97 % stammen aus nur vier Regeln. Dazu zählt jede Namensabfrage mehrfach, weil die Geräte sie parallel über IPv4 und IPv6 stellen. Die grössten Wellen kamen aber von einzelnen grossen Übertragungen: Ein Videostream und ein Download lösten Regeln für fehlerhafte TCP-Verbindungen zehntausendfach aus. Diese Regeln melden jetzt höchstens einmal pro Minute und Gerätepaar. Beim Tuning schalte ich deshalb keine Regel ab, sondern unterdrücke sie gezielt für die Quelle, die ich erklären kann. Wo das nicht geht, etwa weil ein Handy seine IPv6-Adresse laufend wechselt, grenze ich stattdessen die Richtung ein: Verbindungsprüfungen von innen nach aussen sind Normalbetrieb, von aussen nach innen melden sie weiter. Jede Ausnahme steht mit Anlass und Begründung im Protokoll.
Ergebnis
Was der Sensor bisher gezeigt hat:
  • Der erste Befund war mein eigener Fehler: Eine Integration der Hausautomation fragte den Router mehrmals pro Minute unverschlüsselt ab, mit der Sitzungskennung in der Adresse. Die Integration ist abgeschaltet.
  • Zwei Annahmen des ersten Zonenplans sind gekippt: Der meiste Internetverkehr läuft über IPv6, und viele Geräte finden sich per Multicast, der an jeder Zonengrenze endet. Was daraus folgt, steht bei der Netzsegmentierung.
  • Ein Gerät stand seit jeher in der Adressliste, aber nur unter einem nichtssagenden Namen. Ich vermutete eine LED-Steuerung, sicher war ich nicht: Ausgesteckt meldeten weder ihre App noch die Netzwerkverwaltung einen Ausfall. Eindeutig zugeordnet hat sie erst der Mitschnitt, denn mit dem Stecker verschwand ihr Verkehr.
  • Geräte umgehen die Namensauflösung des Routers. Dieselbe LED-Steuerung fragte fremde DNS-Server, und eine Streaming-App am Fernseher tut es fest verdrahtet, auch nachdem am Gerät der Router eingetragen war. Wer so an der Namensauflösung vorbeifragt, umgeht auch den DNS-Filter am Router. Eine Geräteeinstellung ist keine Kontrolle, das löst erst die Firewall.
  • Ein AV-Receiver hing gleichzeitig per Kabel und per WLAN im Netz und sendete rund zehn Multicast-Meldungen pro Sekunde. Mit abgeschaltetem WLAN ging der Strom um 99 % zurück.
  • Hinter einem Alarm auf eine Domain mit exotischer Endung steckte kein Angriff, sondern ein Werbe-Tracker in einer App des Streaming-Players, der seine Adressen hinter wechselnden Tarnnamen versteckt. Der DNS-Filter am Router hatte ihn schon blockiert, der Alarm hat also gezeigt, dass der Filter greift.
  • Auch die eigenen Werkzeuge telefonieren nach Hause: Loki und Alloy schicken in der Grundeinstellung Nutzungsstatistiken an den Hersteller, und Loki nimmt ohne Anmeldung Daten von überall an. Die Statistik ist abgeschaltet, und Loki nimmt nur noch Verbindungen von freigegebenen Adressen an.
  • Auch eine eigene Annahme hielt der Prüfung nicht stand: Die Aufbewahrung von 30 Tagen stand in der Konfiguration, gelöscht wurde aber nie etwas. Dem schlanken System-Image fehlte das Werkzeug, das alte Protokolle rotiert. Nach rund einem Jahr wäre die Platte voll gewesen, und der Sensor wäre still erblindet. Seit es nachinstalliert ist, greift die Frist. Dasselbe Muster wie bei der Streaming-App: Eine Einstellung beweist nichts, erst die Prüfung der Wirkung.
Nach einer Woche Tuning bleiben von rund 150 000 Alarmen am Tag noch einige hundert übrig. Was jetzt noch meldet, kann ich gezielt anschauen und wo nötig beheben. Nach dem Tausch des Routers sieht der Spiegelport auch den Verkehr zwischen den Zonen und prüft damit die Firewall-Matrix. Zeek versteht übrigens auch Industrieprotokolle wie Modbus und DNP3. Und die Normenreihe IEC 62443 verlangt für Automationsanlagen genau das: laufende Überwachung, ein Inventar der Komponenten und eine Meldung, wenn die Überwachung selbst ausfällt.

Belege aus der Auswertung · ein Klick zeigt das ganze Bild

Grafana-Balkendiagramm der Suricata-Alarme pro Tag vom 26. September bis 2. Oktober: 150'731, 94'179, 1'314, 582, 540, 298 und 467.
Suricata-Alarme pro Tag in der ersten Woche. Die zwei hohen Balken stammen fast ganz aus je einer grossen Übertragung: am 26.09. ein Videostream, am 27.09. der erste grosse Download des neu aufgesetzten Mediaservers. Beide lösten Regeln für fehlerhafte TCP-Verbindungen zehntausendfach aus. Seit diese gedrosselt sind, bleiben 300 bis 600 Alarme am Tag.
Grafana-Balkendiagramm der Suricata-Alarme je halbe Stunde vom 25. September 21 Uhr bis 26. September 13:30. Vor dem Tuning meist mehrere hundert bis über zweitausend Alarme pro halbe Stunde, fast alle auf der untersten Stufe. Eine gestrichelte Linie markiert das Tuning um 12:06, danach bleiben nur noch wenige Balken.
Die ersten Stunden, Alarme je halbe Stunde, fast alle auf der untersten Stufe. Bis 23 Uhr hält eine Videositzung der Hausautomation den Pegel hoch, nachts wird es ruhig, tagsüber melden vor allem die Verbindungsprüfungen von Handy und VPN. Die gestrichelte Linie markiert das Tuning um 12:06. Was danach noch meldet, hat grösstenteils der Abruf dieser Auswertung selbst ausgelöst.
Grafana-Verlauf des Paketverlusts am Sensor im selben Zeitraum. Meist null, einzelne Spitzen um 7 Prozent kurz nach Mitternacht und nach 8 Uhr, eine hohe Spitze bis fast 100 Prozent kurz vor 13 Uhr.
Paketverlust des Sensors im selben Zeitraum. Die kleinen Spitzen sind grosse Downloads, bei denen die USB-Netzwerkkarte nicht ganz mitkommt. Die hohe Spitze kurz vor 13 Uhr habe ich selbst verursacht: Eine Auswertung über 16 Stunden hat die Datenbank so ausgelastet, dass der Sensor minutenlang Pakete verlor. Seither ist sie gedrosselt.
Grafana-Tabelle der häufigsten Suricata-Signaturen, alle Schweregrad 3. An der Spitze drei STUN-Regeln mit je über 6000 Treffern, danach eine Applayer-Regel mit 3602, dann Stream-Meldungen mit je rund 250 und einzelne Hinweise auf DNS über HTTPS und Alibaba-Cloud-Domains.
Die häufigsten Alarme seit dem Start. Vier Regeln machen fast alles aus, alle auf der untersten Stufe. Genau dort setzt das Tuning an.
Ein Schlüssel, dessen Bart unter einer Lupe geprüft wird
AuditSSHVPNZwei-Faktor

Zugangs-Audit und Härtung

Welche Wege führen in mein Netz, auch die, die ich selbst einmal eingerichtet und vergessen habe? Zehn Befunde, zwei davon kritisch. Heute gibt es keine Portfreigabe am Router, und öffentlich ist nur, was von aussen erreichbar sein muss.

Details
Schema des Fernzugriffs: am Router gibt es keine Portfreigabe mehr. Hausautomation und Rezept-App sind über einen ausgehenden, verschlüsselten Tunnel öffentlich erreichbar und haben einen gehärteten Login. Dashboards und Wartungszugänge erreichen nur eigene Geräte über VPN. TLS VPN Internet Eigene Geräte Router Hausautomation Rezept-App Dashboards Wartung per SSH öffentlich · Login gehärtet nur im VPN Port Portfreigabe zurückgebaut

Vorher und nachher

  • 10Befunde, jeder mit Risiko, Massnahme und Restrisiko
  • 2 → 0kritische Zugänge aus dem Internet
  • 94 679Passwortversuche von Bots in einer Woche auf einen meiner Server
Ausgangslage
Hausautomation, Auswertungen, die Rezept-App und die Wartungszugänge der Rechner sollen von unterwegs erreichbar sein, zum Teil für Leute ohne VPN. Ursprünglich lief die Hausautomation über eine Portfreigabe am Router und einen externen Weiterleitungsdienst. Beides habe ich zuerst zurückgebaut. Danach blieb die grössere Frage, welche Wege es sonst noch gibt. Eine Geräteliste beantwortet das nicht. Ich habe deshalb nachgesehen, wer welchen Schlüssel hält und welche Dienste auf Verbindungen warten, und im Mitschnitt des Sensors, welche Verbindungen tatsächlich zustande kommen.
Umsetzung
Erst die Karte aller Zugänge, dann die Massnahmen. Gefunden habe ich unter anderem:
  • Am Hauptrechner ein Fernwartungsprogramm mit Dauerpasswort, seit Januar 2024 aus dem Internet erreichbar, an Router und VPN vorbei. Dazu Reste weiterer Fernwartungsprogramme, Remotedesktop und eine Freigabe, über die alle SSH-Schlüssel offen im Heimnetz lagen.
  • Einen gemieteten Server, auf dem sich root mit Passwort aus dem Internet anmelden konnte. Bots haben das in einer Woche 94 679 Mal versucht.
  • Eine Kette: Die öffentlich erreichbare Hausautomation hatte per Schlüssel eine volle Administrator-Shell auf dem Hauptrechner, und der hielt Schlüssel zu fast allen anderen Systemen. Wer die Hausautomation übernimmt, wäre überall gewesen.
  • Hypervisoren nur mit Passwort und ohne Zweitfaktor, ein VPN ohne Regeln, in dem jedes Gerät jedes andere erreichte, und eine öffentliche Webanwendung, die als root lief.
Die Fernwartungsprogramme sind entfernt, Remotedesktop und Freigaben aus, SSH nimmt überall nur noch Schlüssel. Der Schlüssel der Hausautomation darf den Rechner nur noch herunterfahren, und jedes Ziel hat einen eigenen Schlüssel. Die Weboberflächen der Hypervisoren verlangen zusätzlich einen Zweitfaktor. Der gemietete Server ist für SSH aus dem Internet geschlossen und nur noch über das VPN erreichbar, wo er selbst niemanden erreicht. Im VPN legt eine eigene Regel fest, wer wen erreichen darf. Tests prüfen bei jeder Änderung jedes Gerät als Absender, eine Regel, die sie bricht, lässt sich nicht speichern. Die Rezept-App läuft unter einem eigenen Dienstbenutzer, der nur ihre Daten schreiben darf. Jede Massnahme ist einer Anforderung aus IEC 62443-3-3 oder ISO 27001 zugeordnet, als Vorbild, nicht als Behauptung von Konformität.
Knackpunkt
Eine Massnahme ist erst erledigt, wenn ihre Wirkung geprüft ist. Ein Fernwartungsprogramm, mit dem ich der Familie helfe, darf nur noch ausgehend verbinden. Seinen Dienst hatte ich entfernt, am nächsten Tag war er wieder da: Das Programm richtet ihn bei jedem Start und jedem Update selbst wieder ein, solange eine unscheinbare Einstellung fehlt. Gezeigt hat das erst die Nachkontrolle. Dazu kommt: Öffentlich heisst auffindbar. Das Zertifikat des Tunnels steht in öffentlichen Zertifikatslogs, Scanner müssen den Namen nicht erst raten. Deshalb gilt dort ein gehärteter Login: Zweitfaktor für die Konten in der Hausautomation, lange Zufallspasswörter und eine Sperre gegen Passwort-Raten in der Rezept-App.
Ergebnis
Keine Portfreigabe am Router, und kein Fernwartungsdienst wartet mehr auf Verbindungen von aussen. Zwei Dienste sind öffentlich, beide mit gehärtetem Login, alles andere nur über VPN. Dass der öffentliche Teil gefunden wird, hat sich bestätigt: Im Protokoll der Hausautomation standen fehlgeschlagene Anmeldeversuche eines fremden Geräts, laut Browserkennung von Apple, über den Anonymisierungsdienst von Apple, der die Adresse laufend wechselt. Eine Adresssperre bremst da nur einzelne Anläufe, tragend bleibt der Zweitfaktor. Von den zehn Befunden ist das Restrisiko heute bei acht gering und bei zweien mittel: Einige Schlüssel am Hauptrechner haben noch keine Passphrase, und eine laufende Sicherung des ganzen Servers mit Kopie ausser Haus fehlt noch. Den grössten verbleibenden Hebel, das flache Netz, löst erst die Netzsegmentierung.
In Planung
Vier getrennte Zonen mit Geräten, die nur über eine kontrollierte Stelle in der Mitte miteinander verbunden sind
ZonenVLANFirewallIPv6

Netzsegmentierung

Das Heimnetz in sieben Zonen nach Schutzbedarf aufteilen. Zwischen den Zonen ist alles zu, was nicht ausdrücklich erlaubt ist. Der Plan steht, umgesetzt wird mit dem neuen Router.

Details
Schema der geplanten Segmentierung: sieben Zonen, Verwaltung, Server, öffentlich erreichbare Dienste, Arbeitsgeräte, lokale Geräte ohne Internet, Geräte mit Herstellercloud und Multimedia. Jede Zone ist nur über die Firewall mit den anderen und dem Internet verbunden, dort gilt: zu, ausser ausdrücklich erlaubt. Firewall · zu, ausser ausdrücklich erlaubt Verwaltung Server Öffentlich Arbeitsgeräte Geräte lokal Cloud-Geräte Multimedia Netz und Hosts Hausautomation nach innen: nichts Rechner, Handys kein Internet nur Internet Streaming Internet
Ausgangslage
Heute ist das Netz flach: Server, Hausautomation, Geräte mit Cloudanbindung und die Rechner im Haushalt liegen im selben Segment und können sich gegenseitig erreichen. Ein Gerät, das an der Cloud seines Herstellers hängt, steht damit direkt neben dem Server der Hausautomation.
Plan
Zuerst die Bestandsaufnahme: Ein eigenes Skript liest die Belegung jedes Switch-Ports aus der Netzwerkverwaltung aus und gleicht sie mit der bereits bestehenden Dokumentation ab. Dabei tauchten Geräte auf, die in der Dokumentation fehlten. Auf dieser Grundlage teilt der Entwurf das Netz in sieben Zonen, jede ein eigenes VLAN. Zwischen den Zonen gilt: Standard zu, jede Ausnahme steht einzeln in einer Matrix, wer welche Verbindung aufbauen darf. Beispiele: Die Hausautomation darf ihre Geräte ansprechen, aber nicht in die Verwaltung des Netzes eingreifen, weil sie von aussen erreichbar ist. Unbekannte Gastgeräte kommen nur ins Internet und sonst nirgends hin. Verwaltungszugriff gibt es nur von einem ausgewählten Arbeitsplatz aus und nur mit Zweitfaktor. Das Prinzip ist dasselbe, das die Normenreihe IEC 62443 für Automationsanlagen beschreibt: Zonen nach Schutzbedarf, und Verbindungen zwischen den Zonen, dort Conduits genannt, nur dort, wo sie begründet und festgelegt sind.
Knackpunkt
Vor dem Trennen habe ich hingeschaut, mit dem Sensor aus der Kachel Passives Netzwerk-Monitoring. Er hat zwei Annahmen meines ersten Entwurfs gekippt. Der meiste Internetverkehr läuft über IPv6, eine Matrix nur für IPv4 würde genau ihn nicht erfassen. Und viele Geräte finden sich gegenseitig per Multicast, der an jeder Zonengrenze endet. Ohne gezielte Weiterleitung würde das Handy den Streaming-Player nicht mehr finden. Dazu fielen Geräte auf, die die Namensauflösung des Routers umgehen und eigene DNS-Server fragen. Im Plan sind fremde DNS-Server deshalb für alle Zonen gesperrt.
Stand
Zonenplan, Firewall-Matrix und WLAN-Plan stehen als Entwurf. Umgesetzt wird mit dem Tausch des Routers: zuerst unverändert flach, dann ein Pilot mit einem einzelnen Gerät, die Verwaltungszone zuletzt, weil ein Fehler dort den Zugang zu allem anderen kostet. Die Feinabstimmung der Regeln folgt mit den Daten des Sensors.

Wer darf wen erreichen

Zeile: wer die Verbindung aufbaut. Spalte: das Ziel. Antworten auf eine erlaubte Verbindung kommen automatisch zurück.

vonVerwaltungServerÖffentlichArbeitsgeräteGeräte lokalCloud-GeräteMultimediaInternet
VerwaltungVerwaltung nach Verwaltung: gleiche ZoneVerwaltung nach Server: gesperrtVerwaltung nach Öffentlich: gesperrtVerwaltung nach Arbeitsgeräte: gesperrtVerwaltung nach Geräte lokal: gesperrtVerwaltung nach Cloud-Geräte: gesperrtVerwaltung nach Multimedia: gesperrtVerwaltung nach Internet: erlaubt
Server1Server nach Verwaltung: nur Ausnahme 1Server nach Server: gleiche ZoneServer nach Öffentlich: gesperrt2Server nach Arbeitsgeräte: nur Ausnahme 23Server nach Geräte lokal: nur Ausnahme 34Server nach Cloud-Geräte: nur Ausnahme 45Server nach Multimedia: nur Ausnahme 5Server nach Internet: erlaubt
ÖffentlichÖffentlich nach Verwaltung: gesperrtÖffentlich nach Server: gesperrtÖffentlich nach Öffentlich: gleiche ZoneÖffentlich nach Arbeitsgeräte: gesperrtÖffentlich nach Geräte lokal: gesperrtÖffentlich nach Cloud-Geräte: gesperrtÖffentlich nach Multimedia: gesperrtÖffentlich nach Internet: erlaubt
ArbeitsgeräteArbeitsgeräte nach Verwaltung: gesperrt6Arbeitsgeräte nach Server: nur Ausnahme 67Arbeitsgeräte nach Öffentlich: nur Ausnahme 7Arbeitsgeräte nach Arbeitsgeräte: gleiche ZoneArbeitsgeräte nach Geräte lokal: gesperrtArbeitsgeräte nach Cloud-Geräte: gesperrt8Arbeitsgeräte nach Multimedia: nur Ausnahme 8Arbeitsgeräte nach Internet: erlaubt
Admin-ArbeitsplatzAdmin-Arbeitsplatz nach Verwaltung: erlaubtAdmin-Arbeitsplatz nach Server: erlaubtAdmin-Arbeitsplatz nach Öffentlich: erlaubtAdmin-Arbeitsplatz nach Arbeitsgeräte: gleiche ZoneAdmin-Arbeitsplatz nach Geräte lokal: erlaubtAdmin-Arbeitsplatz nach Cloud-Geräte: erlaubtAdmin-Arbeitsplatz nach Multimedia: erlaubtAdmin-Arbeitsplatz nach Internet: erlaubt
GastgeräteGastgeräte nach Verwaltung: gesperrtGastgeräte nach Server: gesperrtGastgeräte nach Öffentlich: gesperrtGastgeräte nach Arbeitsgeräte: gleiche ZoneGastgeräte nach Geräte lokal: gesperrtGastgeräte nach Cloud-Geräte: gesperrtGastgeräte nach Multimedia: gesperrtGastgeräte nach Internet: erlaubt
Geräte lokalGeräte lokal nach Verwaltung: gesperrtGeräte lokal nach Server: gesperrtGeräte lokal nach Öffentlich: gesperrtGeräte lokal nach Arbeitsgeräte: gesperrtGeräte lokal nach Geräte lokal: gleiche ZoneGeräte lokal nach Cloud-Geräte: gesperrtGeräte lokal nach Multimedia: gesperrtGeräte lokal nach Internet: gesperrt
Cloud-GeräteCloud-Geräte nach Verwaltung: gesperrtCloud-Geräte nach Server: gesperrtCloud-Geräte nach Öffentlich: gesperrtCloud-Geräte nach Arbeitsgeräte: gesperrtCloud-Geräte nach Geräte lokal: gesperrtCloud-Geräte nach Cloud-Geräte: gleiche ZoneCloud-Geräte nach Multimedia: gesperrtCloud-Geräte nach Internet: erlaubt
MultimediaMultimedia nach Verwaltung: gesperrtMultimedia nach Server: gesperrtMultimedia nach Öffentlich: gesperrtMultimedia nach Arbeitsgeräte: gesperrtMultimedia nach Geräte lokal: gesperrtMultimedia nach Cloud-Geräte: gesperrtMultimedia nach Multimedia: gleiche ZoneMultimedia nach Internet: erlaubt
  • erlaubt
  • 1nur die Ausnahme darunter
  • gesperrt
  • gleiche Zone, dort filtert die Firewall nicht
  1. Server → Verwaltung: Lesezugriff auf die Netzwerkverwaltung. Regeln schalten darf die Hausautomation nicht, weil sie von aussen erreichbar ist.
  2. Server → Arbeitsgeräte: Rechner herunterfahren und wecken.
  3. Server → Geräte lokal: Aktoren, Licht und Bedienpanel steuern.
  4. Server → Cloud-Geräte: Kamerabilder abholen und Kameras schwenken.
  5. Server → Multimedia: Zuspieler steuern, Mediacenter herunterfahren und wecken.
  6. Arbeitsgeräte → Server: Hausautomation und Auswertungen öffnen.
  7. Arbeitsgeräte → Öffentlich: die Rezept-App.
  8. Arbeitsgeräte → Multimedia: Streaming und Casting, dazu die Weiterleitung der Gerätesuche über die Zonengrenze.

Admin-Arbeitsplatz und Gastgeräte gehören zur Zone Arbeitsgeräte und werden über ihren Adressbereich unterschieden. Für jeden Verwaltungszugang gilt zusätzlich ein Zweitfaktor am Ziel.

Eine Datenbank, daneben ein geschlossener Kreispfeil mit einem Haken für die geprüfte Wiederherstellung
BackupRestoreProxmoxSQLiteWindows

Überlebe ich einen Verlust?

Drei Fälle: ein ganzer Server, neu aufgesetzt und komplett aus der Sicherung zurückgespielt. Eine Datenbank, deren Wiederherstellung ich getestet habe, bevor etwas passiert ist. Und ein echter Datenverlust, bei dem die Sicherung gefehlt hat.

Details

Neuaufbau: der ganze Server aus der Sicherung

Ausgangslage
Auf dem Betriebs-Host laufen Hausautomation, Messdatenbank, Auswertungen und Rezept-App. Seine Proxmox-Version bekam keine Sicherheitsupdates mehr, ein Teil der Daten lag auf einer SSD von 2011, und eine Sicherung ausserhalb des Hosts gab es nicht. Die Messdaten seit 2024 existierten nur einmal.
Umsetzung
Statt das System an Ort und Stelle zu aktualisieren, habe ich es auf einer anderen SSD neu installiert und dabei gleich die Wiederherstellung geprobt. Vorher habe ich alle virtuellen Maschinen und Container samt Host-Konfiguration auf einen anderen Rechner gesichert, die Hausautomation dafür sauber heruntergefahren und jede der elf Dateien per Prüfsumme kontrolliert. Danach alles auf den neuen Host zurückgespielt. Die alte SSD liegt unverändert in der Schublade, als Weg zurück.
Knackpunkt
Die Sicherung muss vollständig und geprüft an einem anderen Ort liegen, bevor am alten System etwas angefasst wird. Nicht alles steckt in den Sicherungen der Gäste: Was der Host den Containern erlaubt, etwa das Netzwerkgerät für das VPN, steht in seiner eigenen Konfiguration und musste von Hand nachgezogen werden. Und beim Installieren musste die alte SSD ausgebaut sein, weil sich zwei Datenträger mit gleich benannten Speichergruppen gegenseitig ins Gehege kommen.
Ergebnis
Alle fünf Gäste liefen nach dem Zurückspielen, und auch nach einem Kaltstart des Hosts kam alles von selbst wieder hoch. Die Wiederherstellung ist damit nicht nur geplant, sondern einmal vollständig durchgespielt. Offen sind ein regelmässiger Sicherungsjob auf einen zweiten Rechner und eine verschlüsselte Kopie ausser Haus.

Vorsorge: die Datenbank der Rezept-App

Ausgangslage
Die Rezept-App enthält Rezepte und Lebensmittel anderer Nutzer. Die darf ich nicht verlieren.
Umsetzung
Die Datenbank wird täglich im laufenden Betrieb gesichert, über die Sicherungsfunktion von SQLite statt einer Dateikopie. Jede Sicherung wird vor dem Ablegen auf Integrität geprüft, 30 Stände bleiben erhalten, lesbar nur für den Dienst, weil sie Passwort-Hashes enthalten.
Knackpunkt
Eine einfache Kopie der Datenbankdatei hätte die jüngsten Änderungen verpasst, sie stehen noch im Write-Ahead-Log. Beim Zurückspielen muss dieses Log weg, sonst legt es sich beim Start über die zurückgespielte Datenbank.
Ergebnis
Die Wiederherstellung ist mit automatisierten Tests belegt, auch mit einer Sicherung, die während laufender Schreibzugriffe entstanden ist. Offen ist eine zweite Kopie ausserhalb des Servers.

Ernstfall: gelöschte Arbeitsprotokolle

Ausgangslage
Mein KI-Werkzeug zur Softwareentwicklung speichert jede Arbeitssitzung als Protokoll. Darin steht, wie und warum meine Projekte so gebaut sind. Im September waren auf einen Schlag rund drei Viertel dieser Protokolle weg. Das Werkzeug räumt Sitzungen nach 30 Tagen still auf, die Voreinstellung stand nirgends.
Umsetzung
Die gelöschten Protokolle habe ich aus den Schattenkopien von Windows zurückgeholt: geöffnet und herauskopiert, nicht wiederhergestellt, denn das hätte den aktuellen Stand überschrieben. Danach die Aufräumfrist auf zehn Jahre gesetzt und eine tägliche Aufgabe eingerichtet, die alle Protokolle in ein Archiv sichert.
Knackpunkt
Das Archiv spiegelt bewusst nicht. Ein Spiegel hätte die Löschung einfach mitgenommen, und genau davor soll es schützen.
Ergebnis
Aus den Schattenkopien kamen 34 Protokolle zurück. Seither landet jede Sitzung täglich im Archiv, unabhängig davon, was das Werkzeug aufräumt.
Eine Messkurve, die ab einem Punkt eingefroren flach weiterläuft, darüber eine Uhr
DatenqualitätMessdatenHome Assistant

Stimmen die Daten?

Eine Datenquelle kann erreichbar sein und trotzdem veraltete Werte liefern. Die Beschattung prüft deshalb das Alter jeder Messung, bevor sie fährt.

Details
Ausgangslage
Die Beschattung fährt nach Live-Daten einer MeteoSchweiz-Station, die alle zehn Minuten neue Messwerte veröffentlicht. Fällt die Quelle aus, darf die Automation nicht auf alten Zahlen weiterfahren.
Umsetzung
Die Beschattung prüft nicht, ob die Quelle erreichbar ist, sondern wie alt die Messung ist. Ist der Zeitstempel älter als 45 Minuten, fährt die Automatik die Storen nicht mehr zu und öffnet sie auch am Abend nicht von selbst. Ob die Daten frisch sind, zeigt die Bedienseite jederzeit an.
Knackpunkt
Im August stand die Veröffentlichung der Messdaten bei MeteoSchweiz einen Tag lang still, die Quelle antwortete trotzdem normal. Meine Aufbereitung übernimmt bei Lücken den letzten gültigen Wert und hat die Strahlung dadurch eingefroren, auch nachts. Eine Prüfung auf Erreichbarkeit hätte davon nichts bemerkt. Die Prüfung auf das Alter schon: Sie liest den Zeitstempel, den MeteoSchweiz jeder Messung mitgibt, und nicht den Zeitpunkt, an dem der Wert bei mir ankommt. Ein eingefrorener Wert behält so seinen alten Zeitstempel und fällt nach 45 Minuten auf. Die Grenze selbst musste ich nachstellen: Die Werte kommen zwar alle zehn Minuten, aber mit einigen Minuten Verspätung an. Bei 30 Minuten galten deshalb auch frische Daten immer wieder kurz als veraltet, und die Anzeige sprang hin und her. 45 Minuten lassen genug Puffer und erkennen einen echten Ausfall trotzdem nach einer Dreiviertelstunde.
Ergebnis
Erreichbar ist nicht dasselbe wie aktuell. Bevor eine Automation nach einem Messwert fährt, prüfe ich, wie alt er ist. In einer Gebäudeautomation stellt sich dieselbe Frage bei jedem Wert, der über ein Netzwerk kommt.

Beleg aus der Auswertung · ein Klick zeigt das ganze Bild

Grafana-Auswertung vom 12. auf den 13. August 2026: Die Globalstrahlung steigt am Vormittag an und bleibt ab 11:41 Uhr bis zum nächsten Morgen bei 698 Watt pro Quadratmeter stehen. Darunter die Frischeprüfung, die um 12:05 Uhr von frisch auf veraltet wechselt und um 07:51 Uhr wieder auf frisch.
12. auf 13. August 2026: Ab 11:41 Uhr kommt kein neuer Messwert mehr, die Strahlung bleibt die ganze Nacht auf 698 W/m² stehen. Um 12:05 Uhr schlägt die Frischeprüfung an und die Automatik hält an. Um 07:51 Uhr kommen wieder frische Daten.
Automation, Geräte und Software6 weitere Projekte
Fenster mit halb heruntergelassener Jalousie, die Sonne steht rechts oben
Home AssistantYAMLMessdaten

Beschattung nach Sonnenstand

Die Jalousien fahren nach Sonnenstand und gemessener Strahlung, nicht nach Uhrzeit. Wer von Hand eingreift, hat Vorrang.

Details
Schema der Beschattung: die von der Sonne beschienene Fassade ist verschattet, die Schattenseite offen. Daneben die Winkel Elevation und Azimut. Sonnenseite · geschlossen Schattenseite · offen Elevation N Azimut
Ausgangslage
Zeitschaltuhren beschatten zu früh, zu spät oder bei Regen. Im Sommer heizt sich die Wohnung auf, an trüben Tagen fehlt das Licht.
Umsetzung
Für jede Fassade ein Fenster aus Sonnenrichtung, in dem die Sonne tatsächlich auftrifft, samt Berg- und Eigenschatten. Ob Sonne oder Wolken, entscheidet die Globalstrahlung einer MeteoSchweiz-Messstation im 10-Minuten-Takt, mit Hysterese und zusätzlicher Wetterprüfung. Zielpositionen je Raum, gestaffelt nach Aussentemperatur. Schwellenwerte lassen sich per Schieberegler anpassen, ohne Code anzufassen.
Knackpunkt
Die Automation muss erkennen, ob sie selbst oder ein Mensch die Jalousie bewegt hat. Automatische Fahrten tragen deshalb eine eigene Kennung. Wer von Hand fährt, nimmt die Jalousie für den Rest des Tages aus der Automatik. Per Knopfdruck lassen sich einzelne oder alle Jalousien wieder in die Automatik zurücksetzen.
Ergebnis
Seit Sommer 2026 im Alltagsbetrieb. Nach dem ersten Regentag nachgeschärft, seither fährt sie vorhersehbar.

Beispiele aus der Bedienoberfläche · ein Klick zeigt das ganze Bild

Bedienseite der Beschattung mit Sonnenstand je Fassade, gemessener Globalstrahlung, Zustand des Hitzeschutz-Gates und der Liste der von Hand gefahrenen Jalousien
Status und Handübersteuerung
Einstellseite mit Schiebereglern für die Strahlungsschwellen in Watt pro Quadratmeter und die Zielpositionen der einzelnen Jalousien in Prozent
Schwellen und Zielpositionen
Übersichtsseite mit Wettervorhersage, Aussentemperatur und den gemessenen Temperaturen der einzelnen Räume
Wetterlage und Temperaturen
Rahmenleinwand an einer Lattenwand, links und rechts leuchten senkrechte LED-Röhren
Home AssistantWLEDESP32

Heimkino-Steuerung

Licht und Jalousien folgen dem, was auf der Leinwand passiert. Nach dem Film ist alles wieder so wie vorher.

Details
Ausgangslage
Vor jedem Film Licht dimmen und Jalousien schliessen, danach alles wieder zurück. Jedes Mal von Hand.
Umsetzung
Adressierbare LED-Beleuchtung (WLED auf ESP32) und Jalousien reagieren auf den Zustand von Streaming-Player und Mediaserver, also auf Wiedergabe, Pause und Menü. In Pausen läuft eine eigene, gedimmte Lichtszene.
Knackpunkt
Zurück heisst nicht einfach „Licht an“. Eine Sitzungslogik mit Zustands-Flags merkt sich, wie es vor dem Film war, und stellt genau das wieder her. Die Jalousien fahren in ihre Ausgangsposition.
Ergebnis
Im Alltag in Betrieb, die Szenen laufen ohne Eingriff. Offen ist ein sporadischer Kommunikationsfehler zu einem der vier LED-Controller. Der Verdacht liegt auf der Funkverbindung, nicht auf der Automation. Ich lasse den Punkt offen, bis die Ursache feststeht, statt ihn mit einer Wiederholschleife zu überdecken.

Beispiel aus der Bedienoberfläche · ein Klick zeigt das ganze Bild

Heimkino-Ansicht mit drei Lichtgruppen, Lichtszenen, vier Storen mit ihrer aktuellen Stellung und den Zuspielern Home Theater und SHIELD
Licht, Storen und Zuspieler an einem Ort
Ein hochkant hängendes Touch-Panel mit fünf Bedienzeilen, eine Hand tippt eine davon an
ESP32-S3ESPHomeLVGL

Touch-Bedienpanel

Ein Bedienpanel mit Kacheln für Licht, Jalousien und PC, auf einem Board, für das es keine passende Firmware gab.

Details
Ausgangslage
Es gab eine Open-Source-Vorlage, aber für ein anderes, kleineres Display mit anderem Prozessor und anderer Display-Anbindung.
Umsetzung
Vorlage auf die neue Hardware portiert: Display-Treiber (RGB-Parallel statt SPI), Touch-Controller, IO-Expander und Pinbelegung. Die Kacheloberfläche habe ich selbst gestaltet, dazu Bildschirmschoner und Steuerung der Hintergrundbeleuchtung.
Knackpunkt
Nach dem ersten Flashen startete das Board in einer Endlosschleife. Die Ursache war kein Flash-Fehler, sondern die falsche Zielarchitektur in der Konfiguration: Bootloader-Adresse und Prozessorkern passten nicht zum ESP32-S3.
Ergebnis
Das Panel steuert Beleuchtung und Jalousien, weckt den PC per Wake-on-LAN und fährt ihn per SSH herunter.
Ein Host, darüber drei virtuelle Gäste, verbunden über leuchtende Leiterbahnen
Proxmox VELinuxHome AssistantInfluxDBGrafanaZeek

Virtualisierte Serverumgebung

Das Rückgrat aller Projekte: virtuelle Maschinen und Container auf zwei Hosts, einer für den Betrieb, einer als Labor mit Netzwerksensor. Dazu Monitoring und Backups, die sich nachweislich zurückspielen lassen.

Details
Schema der Serverumgebung: ein Proxmox-Host für den Betrieb trägt Home Assistant, InfluxDB, Grafana und die Rezept-App, ein zweiter Proxmox-Host dient als Labor und trägt den Netzwerksensor mit Zeek und Suricata. Der Zugriff von aussen läuft über VPN statt über offene Ports, die Sicherung wurde rückgespielt. HAOS InfluxDB Grafana Rezept- App Sensor mit Zeek Proxmox VE Betrieb Proxmox VE Labor Sicherung geprüft VPN · keine offenen Ports
Ausgangslage
Mehrere Dienste, die zuverlässig laufen, gesichert und aus der Ferne erreichbar sein sollen, ohne das Heimnetz zu öffnen.
Umsetzung
Proxmox VE mit virtuellen Maschinen und LXC-Containern, Fernzugriff per VPN ohne offene Ports am Router. Messdaten laufen in InfluxDB und werden in Grafana ausgewertet. Beide Hosts laufen auf der aktuellen Proxmox-Version. Der Betriebs-Host ist dafür neu aufgesetzt und komplett aus der Sicherung zurückgespielt worden. Der zweite, kleine Host dient als Labor. Er trägt den Netzwerksensor: eine VM mit Zeek und Suricata, die den Verkehr am Spiegelport über eine durchgereichte Netzwerkkarte mitliest. Diese Karte hat keine eigene Adresse, der Sensor ist im Netz also unsichtbar. Was er findet, steht in der Kachel Passives Netzwerk-Monitoring.
Knackpunkt
Der VPN-Dienst startete in unprivilegierten Containern nicht, weil ihm das Netzwerkgerät fehlte. Die Lösung lag nicht im Container, sondern in der Geräteberechtigung auf dem Host. Beim Sensor sah die durchgereichte USB-Netzwerkkarte zuerst gar nichts: Der schlanke Kernel des Cloud-Images bringt keine USB-Unterstützung mit. Erst der vollständige Kernel, und nachdem der alte aus dem Bootmenü entfernt war, brachte den Adapter zum Laufen.
Ergebnis
Hausautomation und Rezept-App sichern ihre Daten automatisch, und die Wiederherstellung des ganzen Hosts ist einmal vollständig durchgespielt, siehe „Überlebe ich einen Verlust?“. Offen ist ein regelmässiger Sicherungsjob für den ganzen Host. Der Arbeitsspeicher der VMs wird dynamisch zugeteilt, der Host hat Reserven.
Die Schüssel aus dem App-Symbol auf einem Handybildschirm
PythonFlaskSQLitePlaywright

Webapplikation für Rezepte und Nährwerte

Aus einer Excel-Tabelle wurde eine Webapplikation für mehrere Nutzer, am PC und auf dem Handy.

Details
Ausgangslage
Die Tabelle rechnete zuverlässig, aber nur an einem Gerät und für eine Person.
Umsetzung
Flask und SQLite im eigenen Container. Anmeldung mit Sperre gegen Passwort-Raten, Zugriff nur über TLS, auf dem Handy als App installierbar (PWA). Lebensmittel per Barcode-Scan aus Open Food Facts, die Nährwertdatenbank des Bundes als Nachschlagewerk, Nutri-Score und ein gemeinsamer Pool zum Teilen von Rezepten. Eigene Lebensmittel lassen sich mit Barcode, Bild und Nährwerten erfassen und über den Pool mit anderen teilen.
Knackpunkt
Damit die App trotz Anmeldung installierbar bleibt, müssen Manifest, Icons und Service Worker am Login vorbei erreichbar sein. Alles andere nicht.
Ergebnis
In Version 1.5 bei einer kleinen Nutzergruppe im Alltag. Vor jedem Update laufen automatisierte Tests im echten Browser, Backups entstehen automatisch und sind auf Wiederherstellung geprüft. Die App aktualisiert sich bei allen Nutzern automatisch, und jeder erfährt, was neu ist.

Beispiele aus der laufenden App · ein Klick zeigt das ganze Bild

Rezeptansicht der App mit Zutatenliste und Nährwerten je Portion
Rezept mit Nährwerten
Detailansicht mit Makroverteilung und der Bewertung von Fett, Zucker und Salz
Nährstoff-Ampel
Lebensmitteldatenbank der App mit Suche, Kategorien und Nährwerten je 100 Gramm
Eigene Lebensmittel
Versionsübersicht der App mit den Änderungen der Version 1.5.0 und dem Anfang von 1.4.0, jede Zeile als Neuerung, Verbesserung oder Hinweis gekennzeichnet
Was sich je Version ändert
Ein Protokollfenster, in dem eine Zeile leuchtet und eine Lücke hat
WindowsEreignisprotokollPowerShell

Fehlersuche am Mediaserver

Ein Mediaserver verlor nach dem Aufwachen dauerhaft die Verbindung zu seinen Clients. Die Ursache: sechs Sekunden ohne Namensauflösung.

Details
Ausgangslage
Die Clients meldeten fehlende Berechtigung. Nur ein Neustart des Dienstes half, Abwarten nie.
Umsetzung
Protokolle von Dienst und Windows nebeneinandergelegt. Belegt: Nach dem Aufwachen aus dem Ruhezustand ist die Namensauflösung rund sechs Sekunden weg. Der Dienst prüft seine Anmeldung genau in diesem Fenster und erholt sich danach nicht mehr.
Knackpunkt
Das naheliegende Ereignis für das Aufwachen wird beim Ruhezustand gar nicht ausgelöst, zuverlässig ist nur ein anderer Eintrag. Und die Energiesparoption der Netzwerkkarte, die zuerst verdächtig aussah, muss bleiben, sonst funktioniert das Wecken übers Netzwerk nicht mehr.
Ergebnis
Eine geplante Aufgabe startet den Dienst zehn Sekunden nach jedem Aufwachen neu. Seit Juli 2026 gelöst. Inzwischen läuft der Rechner unter Linux, weil Windows 10 keine Sicherheitsupdates mehr bekommt. Der Mediaserver ist samt Bibliothek umgezogen, ohne dass ein Film seinen Gesehen-Status verloren hat.
Arbeitsweise

Arbeitsweise: Wie ich an eine Sache herangehe

Ob Lüftungsanlage im Spital oder Container im eigenen Serverschrank, die Grundsätze sind dieselben.

01

Erst verstehen, dann ändern

Mehr dazu

Bevor ich eine bestehende Anlage oder Konfiguration anfasse, lese ich, was da ist und wovon es abhängt. Neue Logik läuft zuerst an einer Stelle, bevor sie überall läuft.

02

Ursache statt Workaround

Mehr dazu

Ich lege Protokolle nebeneinander, stelle eine Vermutung auf und prüfe sie. So lange neu starten oder gleich neu installieren, bis es wieder geht, ist für mich keine Lösung.

03

Prüfen, bevor es jemand anders tut

Mehr dazu

Software geht erst nach automatisierten Tests in Betrieb, ein Backup zählt erst mit erfolgreicher Wiederherstellung. Auch diese Seite lief zuerst lokal und in einer Vorschau, bevor sie online ging.

04

Verfügbarkeit vor Eleganz

Mehr dazu

Sechs Jahre Grossprojekte bei laufendem Betrieb haben mich geprägt. Eine Lösung, die den Betrieb stört, ist keine Lösung, auch wenn sie technisch schöner wäre.

05

So dokumentieren, dass es andere betreiben können

Mehr dazu

Aus der Anlagentechnik gewohnt: erst der Funktionsbeschrieb, dann das Programm. Zur Abnahme gehören Systemdokumentation und Instruktion der Betreiber. Das halte ich in eigenen Projekten genauso.

06

Mit KI, aber mit eigenem Kopf

Mehr dazu

Software entwickle ich mit KI-Unterstützung und liefere lauffähige Systeme. Architektur, Betrieb und Fehlersuche mache ich selbst. Ich entscheide, was gebaut wird, prüfe das Ergebnis und kann erklären, was es tut.

Kenntnisse

Kenntnisse: Womit ich arbeite

Automation / OT

Sehr gute Kenntnisse

  • SPS Saia (PG5)
  • HLK-Regelung
  • Inbetriebnahme
  • Störungsanalyse an Anlagen
  • Anlagendokumentation
  • Instruktion der Betreiber

Gute Kenntnisse

  • Modbus
  • M-Bus
  • MP-Bus
  • BACnet

IT / Infrastruktur

Sehr gute Kenntnisse

  • Proxmox VE (VM, LXC)
  • Backup mit geprüftem Restore
  • YAML-Automatisierung

Gute Kenntnisse

  • Linux (Debian, systemd, SSH)
  • VPN (WireGuard)
  • MQTT
  • ESPHome / ESP32
  • REST-APIs
  • Windows-Administration
  • Git

Grundkenntnisse

  • Netzwerk, Segmentierung, VLAN
  • TLS
  • Monitoring mit InfluxDB und Grafana

In Projekten eingesetzt

Entwicklung

  • Python
  • Flask
  • SQLite
  • HTML, CSS, JavaScript
  • Playwright
  • LVGL

Seit 09/2026 in Arbeit · ICS-Security

  • ISA IC32M, Modul 1
  • CISA ICS Virtual Learning, 100W/210W
  • BSI ICS-Security-Kompendium
  • OPSWAT Academy, ICIP
  • Fortinet Training Institute

Was an diesen Protokollen offen ist. Modbus, M-Bus, MP-Bus und BACnet habe ich sechs Jahre lang in Betrieb genommen. So, wie sie in den Anlagen laufen, bringen sie keine Anmeldung mit: Wer im selben Netz ist, kann Werte lesen und Sollwerte schreiben. Dazu kommen die Fernwartungszugänge von Herstellern und Integratoren. Wie man solche Anlagen trotzdem schützt, beschreibt die Normenreihe IEC 62443, mit Zonen nach Schutzbedarf und kontrollierten Verbindungen dazwischen. Dort will ich hin.

Werdegang

Werdegang: Vom Elektriker zum Projektleiter Gebäudeautomation

  1. 02/2026 – heute

    Berufliche Neuausrichtung Richtung OT-Security

    Vertiefung in Netzwerktechnik, Systemhärtung und Informationssicherheit

    Schwerpunkte
    • Selbststudium ICS-Security, die Kurse stehen bei den Kenntnissen
    • Home-Lab: passiver Netzwerksensor mit Zeek und Suricata, Auswertung in Grafana, Planung der Netzsegmentierung in Zonen
    • Absicherung der eigenen Umgebung: Zugangs-Audit mit Härtung, Fernzugriff ohne Portfreigabe, Backups mit geprüfter Wiederherstellung
  2. 02/2020 – 01/2026

    Lippuner Energie- und Metallbautechnik AG

    Grabs · MSR-Techniker, ab 01/2024 Projektleiter Gebäudeautomation

    Aufgaben und Projekte
    • Steuerungssoftware für HLK-Anlagen auf Saia PG5 und Honeywell: Erstellung, Inbetriebnahme und Optimierung
    • Grossprojekte durchgehend bei laufendem Betrieb, wo ein Anlagenausfall keine Option ist
    • Terminplanung, Koordination mit Planern und Unternehmern, Abnahme und Fertigstellung
    • Systemdokumentation, Instruktion der Betreiber, fachliche Anleitung von Lernenden

    Projekte in: Gesundheitswesen inklusive OP-Bereich · Einkaufs- und Freizeitanlagen mit Energieversorgung angrenzender Grossverbraucher · hygienekritische Lebensmittelproduktion · Industrie-Neubauten

  3. 06/2014 – 01/2020

    Elektro Rhyner AG

    Landquart · Bauleitender Elektroinstallateur EFZ

    Aufgaben und Objekte
    • Stark- und Schwachstrominstallationen in kommerziellen und industriellen Objekten
    • Ganze Objekte eigenverantwortlich, von der Bauleitung über die Organisation bis zur Fertigstellung, im Raum Davos, Arosa und Chur
    • Aktive Mitwirkung an der Ausbildung der Lernenden

    Objekte: Alterszentrum · Hotellerie · Detailhandel · Technologie- und Innovationszentrum

  4. 05/2005 – 05/2014

    Weitere Anstellungen als Elektriker

    Leitender Monteur, Elektroinstallateur und Betriebselektriker in der Schweiz und in Deutschland, unter anderem Leitung von Grossbaustellen im Wohnungsbau und Inbetriebnahme industrieller Gleichrichteranlagen.

    EL. Group Sprecher AG, Klosters · IPA Schweiz GmbH, Diepoldsau · Dünte Elektro, Barsinghausen (DE) · Marmor- und Beton Busse, Rehburg (DE)

  5. 08/2001 – 01/2005

    Friedrich Wilkening Elektroinstallationen

    Bad Rehburg (DE) · Lehre als Elektroinstallateur

Steffen Broszeit neben seinem Motorrad auf einer Passstrasse mit Schnee
Persönlich

Persönlich: Neugierig bleiben, Kopf frei bekommen

Ich mag Technik, und ich traue mich an Dinge heran, die ich noch nicht kenne. Verstehen will ich sie trotzdem, nicht nur benutzen. Genauso wichtig ist mir der Ausgleich zum Beruf. Den finde ich unterwegs auf dem Motorrad, in der Werkstatt und am Wasser. Dort bekomme ich den Kopf frei.

  • Motorrad seit 2001Leidenschaftlich unterwegs, die Wartung mache ich selbst.
  • PC und Gaming seit 1988Mit vier Jahren das erste Mal am Rechner und seither nie ganz davon losgekommen.
  • 3D-Modellierung und DruckWas es nicht zu kaufen gibt, konstruiere und drucke ich selbst.
  • Holzbau in der eigenen WerkstattMöbel und Dekoration baue ich teils selbst.
  • Elektrik und LichtLED-Streifen, Steuerungen, Verkabelung: Als Elektriker mache ich das zu Hause selbst, und zwar gern.
  • Am WasserDie beste Pause: Zeit mit meiner Ehefrau am Wasser.
Kontakt

Kontakt: Lassen Sie uns reden

Sie suchen jemanden, der Anlagen von innen kennt und sie absichern will? Schreiben Sie mir. Lebenslauf und Zeugnisse sende ich Ihnen gerne zu.

kontakt@steffen-broszeit.me