Die Sicherheit von Heimnetzwerken ist zu einem echten Problem geworden.

Zwischen vernetzten Objekten, Sprachassistenten, IP-Kameras, NAS, Smartphones und Heimautomation ähneln unsere lokalen Netzwerke zunehmend kleinen Unternehmensnetzwerken.

Und wir werden den Massenangriffen von Cyberkriminellen nicht entgehen.

Nach mehreren Jahren der Weiterentwicklung meiner Hausautomationsanlage wollte ich eine passive Netzwerküberwachungsschicht hinzufügen:

• ohne die Leistung zu beeinträchtigen;
• ohne den Verkehr zu verändern;
• und ohne das Netz in eine Gasanlage umzuwandeln.

🔍 Warum überwache ich mein lokales Netzwerk?

Die meisten angeschlossenen Geräte kommunizieren ständig mit dem Internet:

• Smart-TVs;
• Sprachassistenten;
• Steckdosen für Hausautomation;
• Kameras;
• IoT-Objekte;
• mobile Anwendungen;
• usw.

Das Problem:

• es ist nicht immer bekannt, was sie senden;
• an wen auch immer;
• Und auch nicht, wie oft.

Eine Netzüberwachung ermöglicht insbesondere Folgendes:

• unbekannte Geräte zu erkennen;
• verdächtiges Verhalten zu ermitteln;
• zu sehen, welche Geräte nach außen sprechen;
• Erkennung von Netzwerkscans;
• anomale Ströme zu identifizieren;
• Oder einfach nur sein Netzwerk besser zu verstehen.

🎯 Mein Ziel mit dieser Installation

Das Ziel war einfach:

• Beobachtung des Netzverkehrs;
• anomales Verhalten zu erkennen;
• Zentralisierung von Warnmeldungen im Home Assistant;
• während 100 bleiben % Lokal.

Zu diesem Zweck habe ich mich für eine Architektur entschieden, die auf Folgendem beruht:

• ein Managed-Switch mit Mirroring-Port;
• ein Raspberry Pi für die Netzwerkanalyse;
• und Integration des Home Security Assistant für den Home Assistant.

Aber ich wollte eine Lösung:

• passiv;
• diskret;
• zuverlässig;
• örtlich;
• Unabhängig vom Router.

Der gewählte Grundsatz ist derjenige, der in vielen Arbeitsumgebungen verwendet wird.

🌐 Meine Netzwerkarchitektur

Mein Netzwerk ist wie folgt aufgebaut:

Internet ↓ Freebox (Bridge-Modus) ↓ Router Synology ↓ Switch manageable Zyxel GS1200-5 ├── andere Switches └── port mirror → Raspberry Pi IDS

🪞 Ich richte den Mirroring-Hafen ein

Der Switch dupliziert den Netzwerkverkehr eines bestimmten Ports und sendet ihn an einen anderen Port, der für die Analyse vorgesehen ist. Man spricht in der Regel von Hafen Mirroring, oder SPAN.

So gilt:

• der Raspberry Pi erhält eine Kopie der Pakete;
• ohne im Netz sichtbar zu sein;
• ohne den Verkehr zu verändern;
• und ohne zu einem kritischen Punkt der Infrastruktur zu werden.

Und ehrlich gesagt, wenn er fällt, wenn er brennt, wenn er es satt hat, für mich zu arbeiten, hat dies keine Auswirkungen auf die Einrichtung der Hausautomation.

Und für die Gesundheit meiner Beziehungen mit dem Rest meiner kleinen Familie dürfen meine Heimwerker nicht verhindern, dass die Lichter angehen oder das Gießen ausgelöst wird.

💸 Wie viel hat mich das gekostet?

Die Einrichtung einer Sicherheitssonde in meinem Haus sollte mich nicht viel kosten, da das Familienbudget viele andere Prioritäten hat.

Somit war die einzige finanzielle Investition die Hinzufügung eines Managed-Switches, den ich kurz darauf detailliert darlege. Diese hat mich gekostet: 17,36 €.

• vgl. Seite, die diesem Produkt mit Verkäufern, Preisen oder Promo gewidmet ist

Ich hatte bereits Ethernet-Kabel und einen alten Raspberry Pi 3B+ in einer Schublade.

Wenn Sie einen Raspberry Pi 3B+ kaufen müssen, finden Sie ihn gebraucht bei ca. 40 €. Ich würde nicht weniger nehmen: 3B+ scheint mir das Minimum für diese Art der Nutzung zu sein. Und wenn Sie die Wahl haben, bevorzugen Sie direkt einen Raspberry Pi 4.

Wir kommen also auf ein Gesamtbudget von etwa 60 €, wenn Sie den Switch und den Raspberry kaufen müssen.

Und wenn Sie die SD-Karte durch eine SATA-SSD ersetzen, brauchen Sie nicht viel zu nehmen: Ein Modell mit 20 bis 32 GB reicht völlig aus. Über ein kleines USB-Gehäuse ist es bequem und einfach zu bedienen.

🧰 Das von mir verwendete Material

🔌 Ich wähle den Managed Switch Zyxel GS1200-5

Ich habe mich für Folgendes entschieden:

• Zyxel GS1200-5 v3

Warum dieses Modell:

• kompakt;
• Schalldämpfer;
• geringer Verbrauch;
• einfache Webverwaltung;
• Unterstützung des Mirroring-Ports;
• Wirklich sehr vernünftiger Preis.

Dies ist ein ausgezeichneter Kompromiss für ein Heimautomationslabor oder ein fortgeschrittenes Heimnetzwerk.

🥧 Ich bereite den Raspberry Pi vor

Der Raspberry Pi wird als Netzwerksonde dienen.

Der Raspberry:

• fahre nichts;
• filtert nichts;
• dient nicht als Firewall;
• Es hört einfach auf den Mirror-Traffic, der vom Switch gesendet wird.

Ich empfehle:

• Raspberry Pi 4 mit mindestens 4 GB, obwohl ich einen Raspberry Pi 3B+ verwendet habe, den ich bereits hatte;
• Idealerweise mit einer USB-SSD.

Warum SD-Karten vermeiden:

• Die IDS-Tools schreiben viele Logs.
• SD-Karten verschleißen schnell.

🧠 Warum bevorzuge ich einen Mirror-Switch anstelle einer IDS-Firewall?

Einige Lösungen wie:

• pfSense;
• OPNsense;
• oder Suricata direkt auf dem Router;

Sie sind sehr mächtig.

Aber in meinem Fall wollte ich:

• Trennung der Analyse vom Hauptnetz;
• Vermeidung von Netzunterbrechungen im Zusammenhang mit dem IDS;
• Beibehaltung einer modularen Architektur;
• in der Lage sein, die Analyse einzustellen, ohne das Internet zu beeinträchtigen.

Der passive Modus bringt mehrere Vorteile mit sich:

• keine Latenz;
• keine Auswirkungen auf den Verkehr;
• keine Netzabhängigkeit;
• Einfachheit;
• Sicherheit.

Auch wenn Raspberry pflanzt:

Das Netzwerk funktioniert weiterhin normal.

🔧 Ich konfiguriere den Zyxel GS1200-5 Switch

🚀 Ich mache den ersten Start des Switches

Bevor ich den Switch in das Hauptnetzwerk einbaute, begann ich mit einer ersten Konfiguration in direkter Verbindung mit einem Laptop.

Diese Methode ermöglicht:

• Konfiguration des Schalters in Ruhe außerhalb der Produktion;
• Netzwerkkonflikte zu vermeiden;
• den Administratorzugriff unverzüglich zu sichern;
• und den Mirroring-Port vor der tatsächlichen Netzintegration vorzubereiten.

Nach dem Auspacken:

• Anschluss der Stromversorgung;
• Anschluss des Laptops an Port 1 des Switches;
• vorübergehendes Deaktivieren des WLAN auf dem Computer;
• und Konfiguration einer statischen IP-Adresse auf der Ethernet-Netzwerkkarte.

Der Zyxel-Switch verwendet standardmäßig die Adresse:

192.168.1.3

Daher habe ich den PC vorübergehend konfiguriert mit:

Parameter	Wert
IP-Adresse	192.168.1.50
Maske	24
Laufsteg	192.168.1.1

Sobald beide Geräte im selben Subnetz sind, reagiert der Switch sofort auf den Ping.

Web-Administration funktioniert nur über HTTPS auf neueren Firmware-Systemen. Die Verbindung erfolgt also über:

https://192.168.1.3

Der Browser zeigt dann eine Warnung für ein selbstsigniertes SSL-Zertifikat an, was bei dieser Art von Geräten völlig normal ist.

Bei der ersten Verbindung:

• der Switch fordert unverzüglich die Änderung des Administratorkennworts an;
• Anschließend wird der Zugriff auf die Konfigurationsschnittstelle möglich.

Sodann habe ich:

• den DHCP-Client des Switches deaktiviert;
• eine feste IP-Adresse zugewiesen, optional, aber ich habe 192.168.1.11 ;
• und speichert die Konfiguration vor der Integration in das Hauptnetzwerk.

Dieser Vorbereitungsschritt ermöglicht es, sofort Folgendes zu erreichen:

• einen sauber konfigurierten Switch;
• eine bekannte Verwaltungsanschrift;
• und eine stabile Konfiguration vor der Produktion.

🌐 Ich greife auf den lokalen Netzwerk-Switch zu

Der Switch ist nun über HTTPS zugänglich:

https://192.168.1.11

Ich kann auf meinem live-laptop bleiben oder es mit dem lokalen netzwerk verbinden. Der Switch hat jetzt seine feste IP, also kein Konflikt.

🔀 Ich konfiguriere die Ports

Ausgewählte Konfiguration:

Hafen	Verwendung
Hafen 1	Synology-Router
Hafen 2	Lokales Netzwerk
Hafen 3	Lokales Netzwerk
Hafen 4	Lokales Netzwerk
Hafen 5	Raspberry Pi IDS

Ich bereite ein kleines Etikett vor, das ich auf den Switch kleben werde.

Hier das Ergebnis:

🪞 Ich konfiguriere den Port Mirroring

Grundsatz:

• Kopieren des Datenverkehrs von dem mit dem Router verbundenen Port;
• Der Hafen von Raspberry Pi.

Konfigurierte Parameter:

Parameter	Wert
Hafen Mirroring	Enable
Mirror Richtung	Both
Mirrored Port	Hafen 1
Monitor Port	Hafen 5

Der „Both“-Modus ist wichtig: Es ermöglicht die Anzeige des eingehenden und ausgehenden Datenverkehrs.

❓ Warum spiegele ich nicht alle Ports?

Dies ist eine Frage, die häufig auftaucht.

In der Praxis:

• Die Überwachung des Router-Ports reicht weitgehend aus.
• dies ermöglicht bereits die Beobachtung des gesamten Internetverkehrs;
• ohne den Raspberry Pi unnötig zu überlasten.

Mirroring aller Ports:

• erhöht das Verkehrsaufkommen erheblich;
• führt zu Duplikaten;
• und kann das Analysesystem überlasten.

Für ein Heimnetzwerk reicht der Mirroring des Router-Ports weitgehend aus.

🏷✦ Ich lasse die VLANs standardmäßig

Es war keine spezielle VLAN-Konfiguration erforderlich, ich habe alles standardmäßig gelassen.

Alle Häfen bleiben:

• im VLAN 1;
• im Untagged-Modus.

Für eine klassische Wohnanlage funktioniert es perfekt.

⚙✦ Ich lasse QoS, LAG und IGMP fast standardmäßig

Die anderen erweiterten Switch-Funktionen wurden standardmäßig beibehalten:

• keine Link Aggregation;
• kein spezifisches QoS;
• IGMP Snooping aktiviert;
• Elektro- und Elektronikgeräte deaktiviert.

Ziel ist es, Folgendes zu gewährleisten:

• einfaches Verhalten;
• stabil;
• vorhersehbar.

🥧 Ich installiere den Raspberry Pi für die Netzwerküberwachung

Nachdem der Managed Switch eingerichtet und der Mirroring-Port betriebsbereit war, musste nun der Netzwerksensor eingerichtet werden, der in der Lage war, den Datenverkehr des Heimnetzwerks zu analysieren.

Das Ziel bestand nicht darin, den Datenverkehr zu blockieren oder den Router zu ersetzen, sondern lediglich darin, ein völlig passives Überwachungssystem einzurichten, mit dem beobachtet werden kann, was im lokalen Netzwerk passiert.

Die Idee ist einfach: Der Zyxel-Switch dupliziert den Netzwerkverkehr über den Mirroring-Port und sendet diese Kopie an einen Raspberry Pi für die Analyse.

Raspberry wird dann zu einer Art „Netzwerküberwachungskamera“, die in der Lage ist, angeschlossene Geräte, externe Verbindungen, DNS-Austausch, TLS-Feeds, verdächtiges Verhalten oder bestimmte bekannte Angriffe zu beobachten.

🤔 Warum verwende ich einen Raspberry Pi?

Der Raspberry Pi eignet sich perfekt für diese Art der Verwendung:

• geringer Stromverbrauch;
• völlig geräuschloser Betrieb;
• reduzierte Kosten;
• kompaktes Format;
• Perfekt für den 24-Stunden-Betrieb.

Ich hatte mehrere Modelle, die zu Hause verfügbar waren: Raspberry Pi 3, 3B und 3B+.

Die Wahl fiel schließlich auf einen Raspberry Pi 3B+, der einen guten Kompromiss zwischen Leistung, Stabilität und Verbrauch bietet.

💾 Ich wähle die Lagerung

Ich wollte klassische microSD-Karten vermeiden.

Auch wenn sie für einfache Projekte sehr gut funktionieren, können sie auf lange Sicht nicht mit intensiven Schreibvorgängen umgehen, insbesondere wenn es darum geht, ständig Netzwerkprotokolle zu generieren.

Ich habe mich daher dafür entschieden, Folgendes zu verwenden:

• eine SATA 2.5-SSD;
• einen USB-auf-SATA-Adapter;
• Raspberry Pi OS Lite 64-Bit.

Ziel war es, eine Anlage zu erhalten:

• zuverlässiger;
• schneller;
• nachhaltiger;
• und stabiler im Laufe der Zeit.

🧰 Ich installiere das System

Das System wurde mit Raspberry Pi Imager direkt auf der SSD installiert.

Ich habe gewählt:

• Raspberry Pi OS Lite 64-Bit;
• vorkonfigurierte Wi-Fi-Verbindung;
• SSH bei der Installation aktiviert;
• personalisierter Gastgebername;
• Automatische Systemaktualisierung nach dem ersten Start.

Kaum gestartet, erschien der Raspberry sofort im Heim-Wi-Fi-Netzwerk.

Anschließend wurde ihm vom Synology-Router eine feste IP-Adresse zugewiesen, um die Fernverwaltung zu erleichtern.

An dieser Stelle setze ich die IP-Adresse fest, jeder seine Methode, ich tue dies auf dem Synology-Router, aber dies kann auf dem Raspberry erfolgen, wobei zu beachten ist, dass von hier aus jedes Mal, wenn ich 192.168.1.222, es wird die IP des Raspberry sein.

🩺 Ich prüfe, ob die Systembasis gesund ist

Vor der Installation von Suricata habe ich es vorgezogen, zu überprüfen, ob die Systembasis gesund ist.

Die Idee war einfach: Vor der Umwandlung des Raspberry in eine 24-Stunden-Netzwerksonde musste sichergestellt werden, dass das System auf der SSD gut gestartet wurde, die Stromversorgung stabil war, die Temperatur korrekt war und die Netzwerkschnittstellen im erwarteten Zustand waren.

📦 Vollständige Systemaktualisierung

sudo apt update && sudo apt full-upgrade -y

Nach der Aktualisierung ermöglicht ein Neustart einen sauberen Start:

sudo reboot

💽 Ich überprüfe, ob der Raspberry auf der SSD gut startet

lsblk

Erwartetes Ergebnis:

sda ├─sda1 /boot/firmware └─sda2 /

Der wichtige Punkt hier ist zu sehen, dass die Root-Partition / ist seither gut gestiegen /dev/sda2.

Dies bestätigt, dass der Raspberry gut auf der USB-SSD und nicht auf einer microSD-Karte startet.

📊 Ich überprüfe den verfügbaren Speicherplatz

df -h

Erwartetes Ergebnis:

/dev/sda2 29G 3.0G 25G 11% / /dev/sda1 505M 65M 440M 13% /boot/firmware

In meinem Fall bietet die 32-GB-SSD viel Platz für das System, Suricata und Protokolle, sofern eine automatische Dateirotation eingerichtet wird.

🌐 Ich überprüfe die Netzwerkschnittstellen

ip a

Erwartetes Ergebnis vor dem Anschluss des Spiegelanschlusses:

eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> inet 192.168.1.22/24

In dieser Architektur wird Wi-Fi verwendet, um Raspberry über SSH zu verwalten.

Die Ethernet-Schnittstelle eth0, sie ist für die Erfassung des Netzwerkverkehrs vom Mirror-Port des Switches reserviert.

🌡✦ Ich überprüfe die Temperatur

vcgencmd measure_temp

Ergebnis:

temp=40.8'C

Eine Temperatur von etwa 40 bis 60 °C ist für diese Art der Verwendung vollkommen korrekt.

Der Raspberry kann daher ohne besondere Probleme kontinuierlich betrieben werden.

🔌 Ich überprüfe die Ernährung und das Throttling

vcgencmd get_throttled

Erwartetes Ergebnis:

throttled=0x0

Dies ist ein sehr wichtiger Punkt.

Der Wert 0x0 bedeutet, dass der Raspberry Folgendes nicht erkennt:

• keine Unterspannung;
• keine Frequenzbegrenzung;
• kein Problem mit der Ernährung.

🧠 Ich überprüfe, ob das System 64-Bit ist

uname -a

Erwartetes Ergebnis:

aarch64 GNU/Linux

Die Anwesenheit von aarch64 bestätigt, dass Raspberry Pi OS Lite 64-Bit installiert ist.

🛡✦ Ich installiere Suricata

Sobald der Raspberry voll funktionsfähig ist, habe ich das Intrusion Detection System (IDS) installiert, das den Netzwerkverkehr analysieren wird: Suricata.

Die Wahl von Suricata hat sich ganz natürlich durchgesetzt:

• Open Source;
• in der Berufswelt weit verbreitet;
• fortgeschrittene Analyse der Protokolle;
• Unterstützung von JSON-Logs;
• Kompatibilität Home Assistant;
• Erkennung von Netzanomalien;
• Fingerabdrücke JA3 und JA4;
• Automatische Aktualisierung der Regeln.

📦 Installation von Suricata

sudo apt install suricata -y

Nach Abschluss der Installation habe ich die Version und die kompilierten Funktionen überprüft:

suricata --build-info

Erwartetes Ergebnis:

This is Suricata Version 7.x AF_PACKET Unterstützung: yes eBPF-Unterstützung: yes JA3 Unterstützung: yes JA4 Unterstützung: yes

In diesem Schritt wird Folgendes bestätigt:

• Suricata gut aufgestellt ist;
• der Linux-Netzwerksupport aktiv ist;
• die Fingerabdrücke JA3/JA4 verfügbar sind;
• dass der Motor auf dem Raspberry Pi ordnungsgemäß funktioniert.

✅ Ich überprüfe den Suricata-Service

sudo systemctl status suricata

Erwartetes Ergebnis:

Aktiv: Aktiv (Running)

Der Dienst startet automatisch beim Raspberry-Boot.

📚 Ich installiere die Erkennungsregeln

Standardmäßig enthält Suricata fast keine aktiven Regeln.

Daher ist es notwendig, eine Datenbank mit Netzwerksignaturen herunterzuladen.

Ich habe mich für die Gemeinschaftsvorschriften Emerging Threats Open entschieden.

📦 Installation von suricata-update

sudo apt install suricata-update -y

Herunterladen von Regeln

sudo suricata-update

Erwartetes Ergebnis:

Loaded 65950 rules Writing rules to /var/lib/suricata/rules/suricata.rules

Über 50.000 Erkennungssignaturen wurden automatisch installiert.

🔧 Ich richte das Raspberry-Netzwerk ein

Zu diesem Zeitpunkt musste ein äußerst wichtiger Punkt behandelt werden:

Der Raspberry sollte niemals über seine Capture-Schnittstelle über das Netzwerk kommunizieren.

Der Port, der mit dem Mirror-Port des Switches verbunden ist, sollte nur auf Netzwerkverkehr hören, ohne jemals Pakete zu senden.

Hierfür gilt:

• Es darf keine IP-Adresse vorhanden sein eth0 ;
• keine DHCP;
• keine Laufstege;
• kein ausgehender Verkehr;
• Obligatorischer PROMISC-Modus.

🔎 Ich identifiziere den verwendeten Netzbetreiber

nmcli device status

Ergebnis:

eth0 ethernet connected netplan-eth0 wlan0 wifi connected netplan-wlan0

Dies bestätigt, dass das System NetworkManager verwendet.

🚫 Ich deaktiviere IPv4 und IPv6 auf eth0

sudo nmcli connection modify netplan-eth0 ipv4.method disabled sudo nmcli connection modify netplan-eth0 ipv6.method disabled

🔄 Ich starte die Netzwerkverbindung neu

sudo nmcli connection down netplan-eth0 sudo nmcli connection up netplan-eth0

👂 Ich schalte den PROMISC-Modus ständig ein

Der promiscuous-Modus ermöglicht es der Netzwerkkarte, alle vom Switch kopierten Pakete zu empfangen.

Einrichtung eines systemd-Dienstes:

sudo nano /etc/systemd/system/promisc-eth0.service

Inhalt der Datei:

[Unit] Description=Enable promiscuous mode on eth0 After=network.target [Service] Type=oneshot ExecStart=/usr/sbin/ip link set eth0 promisc on [Install] WantedBy=multi-user.target

▶▶ Ich aktiviere den Dienst

sudo systemctl enable promisc-eth0 sudo systemctl start promisc-eth0

✅ Ich überprüfe die Netzwerkschnittstelle

ip a

Erwartetes Ergebnis:

eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP>

Sehr wichtig:

• keine IP-Adresse;
• keine Zeile inet ;
• Modus PROMISC aktiv.

Der Raspberry wird dann zu einer echten passiven Netzwerksonde.

🔌 Ich schließe den Spiegelport an

Sobald der Raspberry bereit war, wurde der Port 5 des Zyxel-Switches, der als Spiegelport konfiguriert wurde, direkt mit dem Ethernet-Port des Raspberry Pi verbunden.

Ab diesem Zeitpunkt erhält der Raspberry eine Kopie des Netzwerkverkehrs.

📡 Ich mache einen ersten Netzwerk-Capture-Test

Bevor ich Suricata startete, habe ich es vorgezogen, zu überprüfen, ob der Mirroring tatsächlich funktioniert.

📦 Installation von tcpdump

sudo apt install tcpdump -y

🧪 Testaufnahme

sudo tcpdump -i eth0 -nn -c 20

Ergebnis:

IP 192.168.1.x > 192.168.1.x UDP, length 70 ICMP echo request HTTPS traffic DNS traffic

Der Netzwerkverkehr begann sofort zu scrollen:

• DNS-Abfragen;
• HTTPS-Verkehr;
• IoT-Kommunikation;
• interne Ströme;
• ICMP;
• verschiedene Netzwerkverbindungen.

Dies bestätigte, dass

• der Zyxel-Spiegelport funktionierte einwandfrei;
• Der Raspberry erhielt eine Kopie des Datenverkehrs.
• Der passive Fang war betriebsbereit.

⚙✦ Ich konfiguriere Suricata

Die Hauptkonfigurationsdatei finden Sie hier:

/etc/suricata/suricata.yaml

🏠 Ich erkläre das lokale Netzwerk

Ich habe das lokale Netz an meine Anlage angepasst:

HOME_NET: "[192.168.1.0/24]"

Dadurch wird Folgendes verbessert:

• die Genauigkeit der Warnmeldungen;
• Leistung;
• Erkennung interner und externer Ströme.

🧬 Ich aktiviere die Fingerabdrücke JA3 und JA4

Mit den Fingerabdrücken JA3/JA4 können bestimmte TLS-Verhalten sehr genau identifiziert werden.

Aktivierung im TLS-Block:

ja3-fingerprints: yes ja4-fingerprints: yes

✅ Ich prüfe die Konfiguration

sudo suricata -T -c /etc/suricata/suricata.yaml

Erwartetes Ergebnis:

Konfiguration provided was successfully loaded

Dieser Befehl ist äußerst nützlich:

• Erkennung von YAML-Fehlern;
• Validierung der Regeln;
• Kontrolle der Wege;
• Gesamtüberprüfung der Konfiguration.

🚀 Ich beginne Suricata

🔄 Ich starte den Dienst neu

sudo systemctl restart suricata

📊 Ich überprüfe den Status

sudo systemctl status suricata

Erwartetes Ergebnis:

Aktiv: Aktiv (Running)

📜 Ich validiere Netzwerkprotokolle

Das Herzstück des Systems ist die von Suricata generierte JSON-Datei:

/var/log/suricata/eve.json

👀 Echtzeit-Visualisierung

sudo tail -f /var/log/suricata/eve.json

Durch die Erzeugung von etwas Netzwerkverkehr (YouTube, Web-Navigation, …-verbundene Objekte) erscheinen die ersten Ereignisse sofort:

"event_type":"flow" "event_type":"dns" "event_type":"tls" "event_type":"http"

Dies bestätigt, dass

• Suricata analysiert die Pakete ordnungsgemäß;
• die Protokolle werden entschlüsselt;
• JSON-Protokolle sind verwertbar;
• Die Netzwerküberwachung funktioniert wirklich.

🗂✦ Ich richte eine automatische Rotation der Logs ein

Ein Netzwerk-Monitoring-System generiert eine Menge Logs.

Daher ist eine automatische Rotation erforderlich, um das Auffüllen der SSD zu vermeiden.

⚙─ Konfiguration logrotate

sudo nano /etc/logrotate.d/suricata

Verwendete Konfiguration:

/var/log/suricata/*.log /var/log/suricata/*.json { daily rotate 14 missingok notifempty compress delaycompress copytruncate sharedscripts postrotate /bin/kill -HUP $(cat /var/run/suricata.pid) 2>/dev/null || true endscript }

Diese Konfiguration:

• bewahrt 14 Tage Geschichte auf;
• komprimiert die alten Logs;
• vermeidet Fehler, wenn Suricata neu gestartet wird;
• schränkt den Verschleiß der SSD stark ein.

📡 Ich exportiere Netzwerkstreams mit softflowd nach Home Assistant

Nachdem Suricata im passiven IDS-Modus betriebsbereit war, bestand das nächste Ziel darin, Netzwerkmetadaten an den Home Assistant zu übermitteln, um Dashboards, Aktivitätsgrafiken und intelligente Warnmeldungen erstellen zu können.

Dazu habe ich hinzugefügt: softflowd, ein leichter NetFlow-Exporteur, der perfekt zu einem Raspberry Pi 3B+ passt.

Die Idee ist einfach:

• Suricata prüft die Pakete;
• softflowd beobachtet die Netzflüsse;
• Home Assistant zentralisiert und visualisiert die Aktivität.

Dieser Ansatz ermöglicht eine erweiterte Netzwerküberwachung, ohne den Raspberry in einen Router oder eine aktive Firewall umzuwandeln.

📦 Ich installiere softflowd

Die Installation ist sehr einfach:

sudo apt install softflowd -y

Nach der Installation musste festgestellt werden, welche Netzwerkschnittstelle den Mirror-Traffic des Zyxel-Switches empfängt.

Wie zuvor kann der Netzwerkstatus mit folgendem Befehl überprüft werden:

ip a

Beobachtetes Ergebnis:

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>

Schnittstelle eth0 ist daher in Ordnung:

• vernetzt;
• aktiv;
• im PROMISC-Modus;
• ohne IP-Adresse.

Genau das habe ich gesucht:

• eth0 empfängt nur den Mirror-Traffic des Switches;
• wlan0 wird verwendet, um den Raspberry zu verwalten und die Daten an den Home Assistant zu senden.

🧪 Ich mache einen ersten manuellen Test

Vor jeder Automatisierung habe ich softflowd manuell gestartet, um zu überprüfen, ob es funktioniert:

sudo softflowd -i eth0 -n 192.168.1.222:2055

Raspberry sendet fast keine Meldungen auf den Bildschirm zurück, was normal ist.

Das Programm startet direkt im Hintergrund.

Um zu überprüfen, ob die Feeds in den Home Assistant exportiert wurden, habe ich eine zweite SSH-Sitzung gestartet:

sudo tcpdump -i wlan0 udp port 2055

Ergebnis:

IP Suricata.42399 > 192.168.1.222.2055: UDP

Diese Linie bestätigt mehrere wichtige Punkte:

• softflowd funktioniert;
• NetFlow-Ströme werden gut generiert;
• Home Assistant erhält die Pakete;
• Das Routing über Wi-Fi ist in Ordnung.

🛠✦ Ich erstelle einen dedizierten systemd-Dienst

Der mit softflowd bereitgestellte Debian-Dienst hat sich in diesem speziellen Kontext als unzuverlässig erwiesen.

Daher habe ich es vorgezogen, meinen eigenen systemd-Dienst einzurichten.

Erstellung der Datei:

sudo nano /etc/systemd/system/softflowd-ids.service

Verwendete Konfiguration:

[Unit] Description=softflowd NetFlow exporter for IDS mirror interface After=network-online.target promisc-eth0.service Wants=network-online.target [Service] Type=simple ExecStart=/usr/sbin/softflowd -d -i eth0 -n 192.168.1.222:2055 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

Anschließend Aktivierung des Dienstes:

sudo systemctl daemon-reload sudo systemctl enable softflowd-ids sudo systemctl restart softflowd-ids

✅ Ich überprüfe den ordnungsgemäßen Betrieb

Zur Bestätigung des ordnungsgemäßen Funktionierens:

sudo systemctl status softflowd-ids

Ergebnis:

Aktiv: active (running) softflowd v1.1.1 starting data collection Exporting flows from eth0 to [192.168.1.222]:2055

Zum jetzigen Zeitpunkt ist die Netzwerkarchitektur voll funktionsfähig:

• der Zyxel-Switch dupliziert den Datenverkehr;
• der Raspberry erhält die Kopie der Pakete;
• Suricata analysiert den Verkehr;
• softflowd exportiert die Feeds;
• Home Assistant zentralisiert die Daten.

Das Interessanteste ist, dass diese Überwachung völlig passiv bleibt:

• keine Auswirkungen auf das Netz;
• keine Änderung der Ausrüstung;
• keine mögliche Verkehrsunterbrechung;
• extrem niedriger Stromverbrauch.

Der Raspberry wird somit zu einer echten Heimnetzwerksonde, die in der Lage ist, eine sehr fortgeschrittene Sichtbarkeit der gesamten Hausautomations- und IT-Installation des Hauses zu bieten.

🏠 Ich integriere Home Security Assistant in Home Assistant

Sobald Suricata in Betrieb war und die NetFlow-Feeds über softflowd ordnungsgemäß in den Home Assistant exportiert wurden, bestand der nächste Schritt darin, alle diese Daten tatsächlich zu nutzen.

Ziel war es nicht mehr nur, Netzwerkverkehr zu erfassen, sondern

• Sicherheitsereignisse korrelieren;
• Identifizierung der aktiven Ausrüstung;
• anomales Verhalten zu erkennen;
• Visualisierung des Heimnetzes in Echtzeit;
• Home Assistant in ein echtes Sicherheitsüberwachungszentrum verwandeln.

Dafür habe ich die hervorragende Integration installiert Home Security Assistent Geführt durch domo-monster.

Durch diese Integration kann Folgendes zentralisiert werden:

• die Suricata-Logs;
• NetFlow-Ströme;
• Netzwerkstatistiken;
• verdächtige Ereignisse;
• Aufdeckung von Schwachstellen;
• Ungewöhnliches Netzwerkverhalten.

In meinem Fall war HACS bereits im Home Assistant installiert, was die Installation erheblich vereinfacht.

➕ Ich füge das benutzerdefinierte Repository in HACS hinzu

Im Home Assistant:

HACS → Integrationen → ⋮ (Menü oben rechts) → Benutzerdefinierte Einzahlungen

Hinzufügen des GitHub-Repositorys:

https://github.com/domo-monster/HomeSecurityAssistant

Anschließend Auswahl der Kategorie:

Integration

Schließlich:

Hinzufügen

📦 Ich installiere die Integration

Sobald die Anzahlung hinzugefügt wurde:

HACS → Integrationen

Suche nach:

Home Security Assistent

Installieren Sie dann die neueste verfügbare Version.

Nach dem Herunterladen fordert Home Assistant einen vollständigen Neustart an.

🔌 Ich füge die Integration in den Home Assistant hinzu

Nach dem Neustart:

Einstellungen → Geräte und Dienste → Integration hinzufügen

Dann Suche nach:

Home Security Assistent

⚙✦ Ich konfiguriere Home Security Assistant

Nach der Installation der Integration öffnet Home Assistant automatisch das Konfigurationsfenster des Home Security Assistant.

Diese Konfiguration ist jederzeit zugänglich:

Einstellungen → Geräte und Dienste → Home Security Assistant → Konfigurieren (Gekerbtes Rad)

Die meisten der vorgeschlagenen Einstellungen können standardmäßig belassen werden.

Integration ist bereits so konzipiert, dass sie in einem normalen häuslichen Umfeld wirksam funktioniert.

In meinem Fall brauchten nur wenige Parameter wirklich besondere Aufmerksamkeit.

🌐 Zuhörer

0.0.0.0

Dieser Wert muss beibehalten werden.

Sie ermöglicht es dem Home Security Assistant, NetFlow-Feeds über alle Netzwerkschnittstellen des Home Assistant-Servers abzuhören.

Dies ist besonders nützlich, wenn:

• Home Assistant verfügt über mehrere Netzwerkschnittstellen;
• die Ströme kommen von einem anderen Gerät;
• Telemetrie wird durch eine entfernte IDS-Sonde wie hier mit dem Raspberry exportiert.

📡 Abhöranschluss UDP

2055

Dieser Port muss genau dem zuvor in softflowd konfigurierten Port entsprechen:

softflowd -i eth0 -n 192.168.1.222:2055

Port 2055 ist ein sehr verbreiteter Standard für NetFlow.

🏠 Interne Netzwerke

192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,fd00::/8,fe80::/10

Diese Standardkonfiguration habe ich freiwillig beibehalten.

Auch wenn mein derzeitiges Netz hauptsächlich funktioniert durch:

192.168.1.0/24

Die Standardkonfiguration bleibt flexibler und skalierbarer.

Sie ermöglicht insbesondere:

• die künftige Hinzufügung von VLANs;
• Trennung von IoT-Objekten;
• Verwaltung von Gastnetzen;
• IPv6-Kompatibilität;
• die künftige Entwicklung der Infrastruktur.

In einer modernen häuslichen Umgebung ist es in der Regel besser, diese erweiterte Konfiguration beizubehalten.

🕵 Port-Scan-Erkennungsfenster

600 Sekunden

Dieser Wert entspricht:

• 10 Minuten rutschige Überwachung;
• gute Detektionsempfindlichkeit;
• eine angemessene Gebühr für Home Assistant.

Ziel ist es, Folgendes zu vermeiden:

• zu aggressive falsch-positive Ergebnisse;
• unnötige Warnmeldungen;
• Überlastung des Analysemotors.

Für ein Heimnetzwerk ist der Standardwert sehr korrekt.

🚪 Einmalige Ports vor Scan-Alarm

100

Dieser Wert bestimmt, ab wie vielen verschiedenen Ports ein Gerät möglicherweise einen Netzwerkscan durchführt.

Auch hier ist der Standardwert für den Heimgebrauch geeignet.

Ein zu niedriger Wert könnte zu einer Vielzahl falsch positiver Ergebnisse führen:

• Chromecast;
• Apple TV;
• vernetzte Objekte;
• mDNS;
• UPnP;
• Automatische Netzwerkerkennung.

📈 Hohe ausgehende Verkehrsschwelle

50000000

Dieser Parameter definiert das Datenvolumen, das über einen bestimmten Zeitraum als ungewöhnlich hoch angesehen wird.

In meinem Fall habe ich den Standardwert beibehalten.

Das Hauptziel besteht darin, Folgendes aufzudecken:

• eine kompromittierte Ausrüstung;
• ungewöhnlicher massiver Upload;
• Exfiltration von Daten;
• Ein extrem gesprächiges IoT-Gerät.

📋 Seitenleiste aktivieren

Option aktiviert.

Dadurch wird der Home Security Assistant direkt in die Home Assistant-Seitenleiste eingefügt.

Dies ist äußerst praktisch.

🔐 Administratorrechte für das Seitenpanel

Option bleibt ebenfalls aktiviert.

Dadurch wird der Zugriff auf sensible Netzwerkinformationen nur auf Home Assistant-Administratoren beschränkt.

In einer Umgebung mit mehreren Nutzern ist dies eine bewährte Sicherheitspraxis.

🔎 Aktiver Netzwerk-Scanner

Ich habe den Scanner aktiviert.

Diese Komponente ermöglicht es dem Home Security Assistant:

• die Netzwerkausrüstung zu entdecken;
• die aktiven Gäste zu identifizieren;
• die IP-Adressen zu korrelieren;
• Bereicherung der Netzwerkinformationen.

Diese Funktion ergänzt perfekt die passiven Analysen von Suricata.

⏱─ Intervall des aktiven Scannens

3000 Sekunden

Dieser Wert entspricht ungefähr:

50 Minuten

Der aktive Scanner läuft also nicht ständig.

Dies ist eine großartige Sache in einem häuslichen Umfeld.

Dies ermöglicht:

• die Netzlast zu begrenzen;
• aggressive Scans zu vermeiden;
• bestimmte sensible IoT-Objekte nicht zu stören;
• einen diskreten Ansatz beizubehalten.

Für ein sehr dynamisches Labor oder professionelles Netzwerk könnte dieser Wert reduziert werden.

Aber für ein vernetztes Haus ist der Standardwert sehr vernünftig.

🚪 Ports zum Scannen

Die Standardliste kann beibehalten werden.

Es enthält die gängigsten Ports.

Ziel des Scanners ist es nicht, einen umfassenden offensiven Sicherheitsscan durchzuführen, sondern vielmehr:

• die Ausrüstung zu identifizieren;
• die exponierten Dienstleistungen aufzudecken;
• Kartierung des Netzes;
• die Sicherheitskorrelationen zu fördern.

In meinem Fall habe ich nichts geändert.

🚫 Ausnahmen vom Scanner

In diesem Feld können bestimmte IP-Adressen von aktiven Scans ausgeschlossen werden.

Standardmäßig kann es leer bleiben.

Diese Funktion kann jedoch nützlich sein für:

• zerbrechliche Ausrüstung;
• bestimmte Drucker;
• IoT-Objekte mit geringer Robustheit;
• industrielle Ausrüstungen;
• Geräte, die sehr empfindlich auf Netzwerkscans reagieren.

In meiner Umgebung erforderte keine Ausrüstung einen Ausschluss.

📛 Reverse DNS-Auflösung aktivieren

Diese Option sollte eindeutig aktiviert werden.

Sie ermöglicht es, wenig aussagekräftige IPs in deutlich lesbarere Hostnamen umzuwandeln.

Anstatt z. B. Folgendes anzuzeigen:

192.168.1.42

Der Home Security Assistant kann manchmal Folgendes anzeigen:

nas.maison.local printer.local apple-tv.local

Dies führt zu einer enormen Verbesserung:

• Lesbarkeit;
• Analyse der Ereignisse;
• schnelle Identifizierung der Ausrüstung.

🧠 Threat Intelligence-Feed

Standardmäßige URLs können beibehalten werden.

Home Security Assistant lädt automatisch mehrere Reputations- und Sperrlisten aus anerkannten Quellen herunter:

• Abuse.ch;
• SSLBL;
• AdGuard;
• sonstige Gemeinschaftsströme.

Diese Ströme dienen folgenden Zwecken:

• böswillige IP-Adressen zu identifizieren;
• Ermittlung verdächtiger Bereiche;
• bestimmte bekannte Verhaltensweisen zu erkennen;
• Sicherheitswarnungen zu unterstützen.

Dies ist einer der interessantesten Aspekte der Integration: Sie bereichert die lokal erhobenen Netzwerkdaten automatisch mit externen Erkenntnissen.

🌍 DNS-Proxy

In meinem Fall blieb diese Option deaktiviert.

Der DNS-Proxy würde es dem Home Security Assistant ermöglichen,

• Abfangen von DNS-Abfragen;
• Protokollierung der konsultierten Bereiche;
• DNS-Blockierung anzuwenden;
• weitere Analysen durchzuführen.

Dies bedeutet jedoch:

• höhere Netzwerkprivilegien;
• eine aufdringlichere Architektur;
• eine zusätzliche Abhängigkeit.

Für den ersten Heimeinsatz habe ich es vorgezogen, einfach und stabil zu bleiben.

🔢 DNS-Proxy-Port

53

Standardwert des DNS-Protokolls.

Da der DNS-Proxy deaktiviert bleibt, hat diese Einstellung keine Auswirkungen.

☁─ Upstream-DNS-Resolver

1.1.1.1

Cloudflare wird hier als Upstream-DNS-Resolver verwendet.

Dieser Wert kann je nach Präferenz ersetzt werden:

• Google DNS;
• Quad9;
• AdGuard DNS;
• Pi-hole;
• Unbound vor Ort.

In meinem Fall habe ich den vorgeschlagenen Wert beibehalten.

🗃─ DNS-Protokollaufbewahrung

24 Stunden

Dieser Wert legt fest, wie lange DNS-Protokolle gespeichert bleiben.

Für eine häusliche Umgebung:

• 24 Stunden bieten bereits eine gute Sichtbarkeit;
• dies schränkt den Speicherverbrauch ein;
• Dadurch wird eine unnötige Anhäufung von Daten vermieden.

Eine längere Aufbewahrung könnte in einem beruflichen oder forensischen Kontext relevant sein.

🚫 Threat-Intel-Quellen, die zum Blockieren verwendet werden

In diesem Feld können Sie festlegen, welche Informationsquellen verwendet werden, um die Blockierungsmechanismen zu unterstützen.

In meinem Fall habe ich ihn leer gelassen. Ich beginne immer lieber im Beobachtermodus, bevor ich Gegenmaßnahmen automatisiere.

⛔ DNS-Kategorien blockiert

In diesem Feld können bestimmte Kategorien von Domänen gesperrt werden:

• Erwachsene;
• Gambling;
• Malware;
• Tracking;
• Phishing;
• usw.

Auch hier habe ich ihn für diesen ersten Einsatz leer gelassen.

Diese Funktion kann später aktiviert werden, sobald das normale Verhalten des Netzwerks verstanden wurde.

Ich verwende bereits Safe Access in meinem Synology-Router, um die von meinen Töchtern verwendeten Geräte zu filtern.

Es tut dies über eine sehr angenehme grafische Oberfläche. Wir werden später sehen, ob ich hier auch DNS-Blockierung mache.

Lokale DNS-Weiterleitungen

Diese Funktion ermöglicht es, bestimmte Domains auf bestimmte IPs umzuleiten.

Zum Beispiel:

monservice.local=192.168.1.10

oder auch:

ads.example.com=0.0.0.0

In meinem Fall war keine Weiterleitung erforderlich. Das Feld blieb also leer.

🦠 Ich erstelle ein VirusTotal-Konto und erhalte meinen API-Schlüssel zurück

Mit VirusTotal können Sicherheitsinformationen mit Reputationsdaten über verdächtige IPs, Domains, URLs oder Dateien angereichert werden.

Um es mit Home Security Assistant zu verwenden, müssen Sie ein kostenloses Konto erstellen auf:

https://www.virustotal.com

Nach dem Einloggen:

Benutzerprofil → API key

VirusTotal gibt an, dass der öffentliche API-Schlüssel nach der Anmeldung im Menü des Benutzerkontos verfügbar ist. Dieser Schlüssel muss privat bleiben und darf natürlich niemals in einem Git-Artikel, -Screenshot oder -Repository veröffentlicht werden.

Im Home Assistant:

Einstellungen → Geräte und Dienste → Home Security Assistant → Konfigurieren

Dann fülle ich das Feld aus:

VirusTotal API Key

Anschließend habe ich das vorgeschlagene Tagesbudget beibehalten:

500

Für meinen häuslichen Gebrauch ist dies bei weitem ausreichend.

Ziel ist es nicht, VirusTotal ständig abzufragen, sondern nur verdächtige Elemente anzureichern, um besser zu verstehen, was Home Security Assistant erkennt.

🚨 Ich erstelle ein AbuseIPDB-Konto und erhalte meinen API-Schlüssel zurück

AbuseIPDB ergänzt VirusTotal sehr gut.

Wo VirusTotal weltweit bekannt ist, ist AbuseIPDB besonders nützlich, um IP-Adressen zu identifizieren, die bekannt sind für:

• Netzwerkscans;
• Brute-Force-Versuche;
• missbräuchliches Verhalten;
• böswillige Aktivitäten, die von der Community gemeldet werden.

Ich erstelle daher ein kostenloses Konto auf:

https://www.abuseipdb.com

Nach dem Einloggen:

Account → API → Create Key

Ich gebe dem Schlüssel einen Namen, z. B.:

Home Security Assistent

Dann kopiere ich den generierten API-Schlüssel.

Wie bei VirusTotal muss dieser Schlüssel streng privat bleiben. AbuseIPDB weist im Übrigen darauf hin, dass API-Schlüssel nicht öffentlich zugänglich gemacht werden sollten.

Im Home Assistant:

Einstellungen → Geräte und Dienste → Home Security Assistant → Konfigurieren

Dann fülle ich das Feld aus:

AbuseIPDB API Key

Ich habe das Tagesbudget beibehalten:

1000

Und ich habe die AbuseIPDB-Vertrauensschwelle vor der Abfrage von VirusTotal auf einem vernünftigen Wert belassen.

Interessant ist der Grundsatz: Ist AbuseIPDB der Ansicht, dass eine IP hinreichend verdächtig ist, kann der Home Security Assistant die Analyse mit VirusTotal ergänzen.

Dadurch wird Folgendes vermieden:

• unnötige API-Aufrufe;
• zu rascher Verbrauch der Quoten;
• und Anreicherungen auf vollkommen banalen IPs.

🧠 Warum füge ich diese beiden Dienste hinzu?

Zu Beginn sieht der Home Security Assistant vor allem:

• IP-Adressen;
• Ströme;
• Verkehrsaufkommen;
• Netzwerkverhalten.

Mit VirusTotal und AbuseIPDB werden diese Informationen viel lesbarer.

Statt nur zu haben:

Verdächtige IP: 185.xxx.xxx.xxx

Home Security Assistant kann die Informationen mit Reputationselementen bereichern:

• bereits gemeldete IP-Adresse;
• Vertrauenswert;
• Bedrohungskategorie;
• Vorgeschichte von Ausschreibungen;
• Sicherheitskontext.

Für eine Hausinstallation ermöglicht dies ein besseres Verständnis dessen, was beobachtet wird, ohne Blockaden sofort zu automatisieren.

Und genau das ist der Ansatz, den ich bevorzuge:

• zunächst zu beachten;
• danach zu verstehen;
• nur automatisieren, wenn dies wirklich erforderlich ist.

🎯 Vertrauen AbuseIPDB vor Abfrage VirusTotal

Dieser Schieberegler legt fest, ab welchem AbuseIPDB-Score eine IP als verdächtig genug angesehen wird, um eine VirusTotal-Abfrage auszulösen.

Das Prinzip ist intelligent:

• unnötige Anrufe vermeiden;
• Verringerung des API-Verbrauchs;
• Wirklich verdächtige IPs priorisieren.

🧹 Eigene IP-Aufbewahrung

5 Stunden

IPs, die als normal angesehen werden, werden für kurze Zeit gespeichert.

Es ist kohärent:

• der rechtmäßige Verkehr ist äußerst umfangreich;
• es ist sinnlos, es zu lange aufzubewahren;
• Dies spart Speicher und Speicher.

⚠ Festnahme verdächtiger IP-Adressen

48 Stunden

Verdächtige IP-Adressen bleiben länger sichtbar, um

• Erleichterung der Analyse;
• Erkennen sich wiederholender Verhaltensweisen;
• bestimmte Ereignisse korrelieren.

Dieser Wert scheint mir für den häuslichen Gebrauch besonders relevant zu sein.

☠─ Schutz vor böswilligen IP-Adressen

168 Stunden

oder:

7 Tage

IPs, die als wirklich bösartig identifiziert wurden, werden viel länger gespeichert.

Dies ermöglicht:

• wiederholte Angriffe zu erkennen;
• bestimmte anhaltende Versuche zu verfolgen;
• eine verwertbare Historie zu bewahren.

Für einen heimischen Raspberry Pi bleibt dieser Wert angemessen.

Anreicherungs-Cache 🧠 TTL

1440 Minuten

oder:

24 Stunden

Diese Einstellung vermeidet das ständige erneute Abfragen externer Nachrichtendienste.

Dies ermöglicht:

• Begrenzung der API-Aufrufe;
• die Belastung zu verringern;
• die Integration reibungsloser zu gestalten;
• bestimmte Blockaden im Zusammenhang mit Zertifikaten zu vermeiden.

Auch hier ist der Standardwert sehr gut durchdacht.

📊 Tägliches Abfragebudget VirusTotal

500

Diese Einstellung begrenzt die Anzahl der täglichen Anfragen, die an VirusTotal gesendet werden.

📈 Tägliches Abfragebudget AbuseIPDB

1000

Gleiche Logik hier. Mit diesem Parameter wird die maximale Anzahl von Abfragen in AbuseIPDB festgelegt.

🗃 URL der NVD-API

https://services.nvd.nist.gov/rest/json/cves/2.0

Diese URL verweist auf die offizielle NVD-Datenbank:

National Vulnerability Database

Verwaltet vom amerikanischen NIST.

Dies ist eine der weltweiten Referenzen in Bezug auf:

• CVE-Schwachstellen;
• CVSS-Werte;
• Sicherheitsreferenzen;
• öffentliche Lücken zu verfolgen.

Home Security Assistant kann diese Datenbank verwenden, um:

• gefährdete Produkte ausfindig zu machen;
• Korrelation bestimmter Ausrüstungen;
• potenzielle Risiken aufzuzeigen.

Die Standard-URL ist selbstverständlich beizubehalten.

⏳ TTL des NVD-Caches

12.00 Uhr

Dieser Parameter legt fest, wie oft CVE-Informationen aktualisiert werden.

Zu häufige Aktualisierungen:

• den Verkehr unnötig erhöhen würde;
• mehr Ressourcen verbrauchen würde;
• keinen wirklichen Nutzen bringen würde.

Der vorgeschlagene Wert stellt einen ausgezeichneten Kompromiss dar.

📅 CVE-Mindestjahr

2020

Diese Option ist besonders interessant.

Sie ermöglicht es, die Analyse auf die jüngsten Schwachstellen zu beschränken.

Warum ist das nützlich?

Weil die CVE-Datenbank Zehntausende historischer Einträge enthält.

In einem häuslichen Umfeld:

• Sehr alte Schwachstellen sind oft weniger relevant.
• neuere Ausrüstungen sind stärker von modernen EVZ betroffen;
• Dies reduziert den Lärm erheblich.

Der Wert für 2020 ist daher kohärent:

• sie weist eine mehrjährige Geschichte auf;
• ohne das System unnötig zu überlasten.

🔍 Suchbegriffe NVD

Dieses Feld enthält eine Liste von Produkten und Dienstleistungen, die in den CVE-Datenbanken überwacht werden sollen:

OpenSSH Android Debug Bridge Apache HTTP Server nginx MySQL MariaDB ...

Diese Liste ermöglicht es dem Home Security Assistant,

• bestimmte im Netz vorhandene Technologien zu identifizieren;
• die damit verbundenen Schwachstellen zu ermitteln;
• um kontextualisierte Warnungen aufzurufen.

Sie bringt Home Assistant einer Logik näher:

• Umgang mit Schwachstellen;
• Bestandsaufnahme der Angriffsfläche;
• Cyber-Hygiene im Haushalt.

In meinem Fall habe ich die Standardliste beibehalten.

Es deckt bereits viele Dienste ab, die häufig in Heimlabors und selbst gehosteten Umgebungen vorhanden sind.

📉 Statistik: Die ersten N Einträge anzeigen

Über den Schieberegler können Sie auswählen, wie viele Elemente in Statistiken und Dashboards angezeigt werden sollen.

Zum Beispiel:

• Top der aktiven IP;
• verdächtige Quellen;
• die am häufigsten genutzten Häfen;
• ermittelte Schwachstellen;
• Wichtige Netzwerkaktivitäten.

Der vorgeschlagene Standard-Zwischenwert ist sehr ausgewogen:

• genügend Informationen, um nützlich zu sein;
• ohne die Home Assistant-Schnittstelle zu überlasten.

✅ Endgültige Konfigurationsvalidierung

Nach der Validierung der letzten Seite wird der Home Security Assistant voll funktionsfähig.

Einige Minuten nach dem Start beginnen die ersten Indikatoren bereits im Home Assistant zu erscheinen.

Dies ist wahrscheinlich einer der befriedigendsten Momente des Projekts:

Endlich wird das Heimnetzwerk in Form von verwertbaren Sicherheitsdaten zum Leben erweckt.

Danach:

• die Konfiguration des Spiegelports;
• die Anlage in Suricata;
• Sammlung von Netzflüssen;
• die Softflowd-Konfiguration;
• Integration in den Home Assistant;

Das System beginnt schließlich, ein kohärentes Bild des Heimnetzbetriebs zu erstellen.

Hier sind zum Beispiel die ersten Sensoren, die kurz nach dem Start auftauchten:

• HSA Active Devices : Anzahl der im Netz erkannten aktiven Geräte;
• HSA High Egress Quellen : Quellen, die ein ungewöhnlich hohes ausgehendes Verkehrsaufkommen erzeugen;
• HSA NVD Keywords : Schlüsselwörter und Technologien, die in der NVD-Schwachstellendatenbank überwacht werden;
• HSA Open Findings : derzeit geöffnete Warnhinweise und Sicherheitsmerkmale;
• HSA Scanned Devices : Anzahl der vom aktiven Scanner analysierten Geräte;
• HSA Suspicious Sources : Netzwerkquellen, die nach den Aufdeckungsregeln und den Nachrichtenströmen als verdächtig gelten;
• HSA Total Flows : Gesamtzahl der beobachteten Netzflüsse;
• HSA Vulnerabilities : Schwachstellen, die anhand der gesammelten Informationen ermittelt oder korreliert wurden.

In meinem Fall begannen die Zahlen sehr schnell zu steigen. Bevor ich diese Seite schrieb, ließ ich das System eine ganze Nacht laufen:

• mehr als 150 000 erkannte Netzwerkströme;
• mehr als 60 aktive Ausrüstungen;
• Dutzende ermittelter Schwachstellen;
• Mehrere Quellen gelten als verdächtig.

Und genau hier wird das Projekt spannend.

Plötzlich wird deutlich, wie viel Aktivität ein modernes Heimnetz erzeugt:

• vernetzte Objekte;
• Sprachassistenten;
• Smartphones;
• NAS;
• Cloud-Dienste;
• Smart-TVs;
• Streaming-Dienste;
• Container;
• Automatisierung der Hausautomation.

Selbst in einer persönlichen Umgebung wird die Netzwerkoberfläche schnell sehr komplex.

Und genau das macht Home Security Assistant endlich sichtbar.

Ich benenne alle Sensoren um, indem ich ihnen Titel auf Französisch gebe.

👀 Erste Eindrücke nach dem Start

Im Moment sind die Informationen, die in HA zurückgehen, auf Zahlen beschränkt, so dass ich zur HSA-Schnittstelle gegangen bin.

Was mich sofort beeindruckte, war die Menge an Informationen, die ohne zusätzliche komplexe Konfiguration verfügbar waren.

Sehr schnell zeigte der Home Assistant:

• aktive Geräte;
• Verkehrsaufkommen;
• verdächtige IP-Adressen;
• umfangreicher Netzwerkaustausch;
• lesbare Sicherheitsstatistiken;
• Beginn der Bedrohungskorrelation.

Und vor allem ist all dies direkt in das bestehende Ökosystem der Hausautomation integriert.

Dies dürfte das Projekt besonders interessant machen: Sie bringen fortschrittliche Cybersicherheitsmechanismen in eine Home Assistant-Umgebung, ohne eine aufwändige und komplexe Unternehmensinfrastruktur bereitstellen zu müssen.

Das Ergebnis ist gleichzeitig:

• pädagogischer Art;
• visuell;
• zweckdienlich;
• evolutionär.

In dieser Phase bin ich sehr glücklich und sehr neugierig, die Entdeckung des Home Security Assistant fortzusetzen.

Ich kann mir nicht einmal vorstellen, wie viel Zeit domo-monster für diese Arbeit aufgewendet hat, die, wenn sie einmal konfiguriert ist, fast von selbst erleuchtet und belebt wird.

Bildschirm Map ist lebendig, lesbar und wirklich beeindruckend zu beobachten.

Ehrlich gesagt: Gut gemacht.

🎯 Schlussfolgerung

Diese Architektur bietet eine echte Ebene der Netzwerktransparenz:

• ohne die Anlage zu verkomplizieren;
• ohne den Verkehr zu verändern;
• Ohne auf den Router angewiesen zu sein.

Das Paar:

• Managed Switch + Mirroring Port + Raspberry Pi

Dies ist eine hervorragende Grundlage für den Aufbau eines leistungsstarken und vollständig lokalen Heim-IDS.

Und vor allem:

• die Analyse bleibt völlig passiv;
• Dies gewährleistet eine hervorragende Stabilität des Netzwerks.

Für ein modernes Heimautomationslabor oder ein modernes Wohnnetz ist dies eine besonders elegante Lösung.

Ich habe jetzt viel Spaß an ein paar …-Wochenenden oder ein paar 😄-Schlaflosigkeitsnächten.

Ich hätte ehrlich gesagt nicht gedacht, dass dieser RetEx so lang und dicht werden würde…, aber am Ende habe ich es geschafft.

Wenn Sie also bisher gelesen haben: Bravo 😅

Ich werde an dieser Stelle mit diesem Artikel aufhören, aber es ist sehr wahrscheinlich, dass ich die Fortsetzung zusammen mit anderen RetEx rund um den Home Security Assistant und seinen täglichen Betrieb veröffentliche.

Zum Schluss noch ein großes Dankeschön an domo-monster, die uns hier auf einem Silbertablett das Ergebnis von wahrscheinlich sehr vielen Jahren Erfahrung und Investitionen im Bereich der Cybersicherheit bringt.

Das Ergebnis ist wirklich beeindruckend.

Frage? Benötigen Sie Hilfe?

Ich habe eine Nachricht im Forum der französischsprachigen Gemeinschaft von Home assistant veröffentlicht, zögern Sie nicht, sie zu nutzen, um mich zu befragen oder Ihre Erfahrungen einzubringen:

• https://forum.hacf.fr/t/article-jai-mis-en-place-une-sonde-de-surveillance-cybersecurite-pour-mon-reseau-domotique/79578