Je surveille mon réseau domestique avec Home Security Assistant

La sécurité des réseaux domestiques est devenue un vrai sujet de préoccupation.

Entre les objets connectés, les assistants vocaux, les caméras IP, les NAS, les smartphones et les équipements domotiques, nos réseaux locaux ressemblent de plus en plus à de petits réseaux d’entreprise.

Et nous n’échapperons pas aux attaques en masse qui sont lancées par les cybercriminels.

Après plusieurs années à faire évoluer mon installation domotique, j’ai voulu ajouter une couche de surveillance réseau passive :

sans impacter les performances ;
sans modifier le trafic ;
et sans transformer le réseau en usine à gaz.

🔍 Pourquoi je surveille mon réseau local ?

La plupart des équipements connectés communiquent constamment avec Internet :

TV connectées ;
assistants vocaux ;
prises domotiques ;
caméras ;
objets IoT ;
applications mobiles ;
etc.

Le problème :

on ne sait pas toujours ce qu’ils envoient ;
ni à qui ;
ni à quelle fréquence.

Une surveillance réseau permet notamment :

de détecter des appareils inconnus ;
d’identifier des comportements suspects ;
de voir quels équipements parlent vers l’extérieur ;
de repérer des scans réseau ;
d’identifier des flux anormaux ;
ou simplement de mieux comprendre son réseau.

🎯 Mon objectif avec cette installation

L’objectif était simple :

observer le trafic réseau ;
détecter les comportements anormaux ;
centraliser les alertes dans Home Assistant ;
tout en restant 100 % local.

Pour cela, j’ai choisi une architecture basée sur :

un switch manageable avec port mirroring ;
un Raspberry Pi dédié à l’analyse réseau ;
et l’intégration Home Security Assistant pour Home Assistant.

Mais je voulais une solution :

passive ;
discrète ;
fiable ;
locale ;
et indépendante du routeur.

Le principe retenu est celui utilisé dans beaucoup d’environnements professionnels.

🌐 Mon architecture réseau

Mon réseau est organisé ainsi :

Internet
    ↓
Freebox (mode bridge)
    ↓
Routeur Synology
    ↓
Switch manageable Zyxel GS1200-5
    ├── autres switchs
    └── port mirror → Raspberry Pi IDS

🪞 Je mets en place du port mirroring

Le switch duplique le trafic réseau d’un port spécifique et l’envoie vers un autre port dédié à l’analyse. On parle généralement de port mirroring, ou de SPAN.

Ainsi :

le Raspberry Pi reçoit une copie des paquets ;
sans être visible sur le réseau ;
sans modifier le trafic ;
et sans devenir un point critique de l’infrastructure.

Et honnêtement, s’il tombe, s’il crame, s’il en a marre de travailler pour moi, cela n’aura aucune conséquence sur l’installation domotique de la maison.

Et pour la bonne santé de mes relations avec le reste de ma petite famille, il ne faut pas que mes bricolages empêchent les lumières de s’allumer ou l’arrosage de se déclencher.

💸 Combien cela m’a coûté ?

La mise en place d’une sonde de sécurité à mon domicile ne devait pas me coûter bien cher, le budget familial ayant bien d’autres priorités.

Ainsi, le seul investissement financier a été l’ajout d’un switch manageable que je détaille juste après. Celui-ci m’a coûté : 17,36 €.

cf. Page dédiée à ce produit avec vendeurs, prix ou promo

J’avais déjà les câbles Ethernet et un vieux Raspberry Pi 3B+ dans un tiroir.

Si vous devez acheter un Raspberry Pi 3B+, vous le trouverez d’occasion aux alentours de 40 €. Je ne prendrais pas moins : le 3B+ me semble être le minimum pour ce type d’usage. Et si vous avez le choix, préférez directement un Raspberry Pi 4.

On arrive donc à un budget global aux alentours de 60 € si vous devez acheter le switch et le Raspberry.

Et si vous remplacez la carte SD par un SSD SATA, inutile de prendre énorme : un modèle de 20 à 32 Go suffit largement. En USB via un petit boîtier, c’est pratique et facile à utiliser.

🧰 Le matériel que j’utilise

🔌 Je choisis le switch manageable Zyxel GS1200-5

J’ai choisi le :

Zyxel GS1200-5 v3

Pourquoi ce modèle :

compact ;
silencieux ;
faible consommation ;
administration web simple ;
support du port mirroring ;
prix vraiment très raisonnable.

C’est un excellent compromis pour un laboratoire domotique ou un réseau résidentiel avancé.

🥧 Je prépare le Raspberry Pi

Le Raspberry Pi servira de sonde réseau.

Le Raspberry :

ne route rien ;
ne filtre rien ;
ne sert pas de firewall ;
il écoute simplement le trafic miroir envoyé par le switch.

Je recommande :

Raspberry Pi 4 avec 4 Go minimum, même si j’ai utilisé un Raspberry Pi 3B+ que j’avais déjà ;
idéalement avec un SSD USB.

Pourquoi éviter la carte SD :

les outils IDS écrivent beaucoup de logs ;
les cartes SD s’usent rapidement.

🧠 Pourquoi je préfère un switch miroir plutôt qu’un firewall IDS ?

Certaines solutions comme :

pfSense ;
OPNsense ;
ou Suricata directement sur le routeur ;

sont très puissantes.

Mais dans mon cas je voulais :

séparer l’analyse du réseau principal ;
éviter toute coupure réseau liée à l’IDS ;
garder une architecture modulaire ;
pouvoir arrêter l’analyse sans impacter Internet.

Le mode passif apporte plusieurs avantages :

aucune latence ;
aucun impact sur le trafic ;
aucune dépendance réseau ;
simplicité ;
sécurité.

Même si le Raspberry plante :

→ le réseau continue de fonctionner normalement.

🔧 Je configure le switch Zyxel GS1200-5

🚀 Je fais la première mise en route du switch

Avant d’intégrer le switch au réseau principal, j’ai commencé par effectuer une configuration initiale en connexion directe avec un ordinateur portable.

Cette méthode permet :

de configurer le switch tranquillement hors production ;
d’éviter tout conflit réseau ;
de sécuriser immédiatement l’accès administrateur ;
et de préparer le port mirroring avant l’intégration au réseau réel.

Après le déballage :

raccordement de l’alimentation ;
connexion du PC portable sur le port 1 du switch ;
désactivation temporaire du Wi-Fi sur l’ordinateur ;
et configuration d’une adresse IP statique sur la carte réseau Ethernet.

Le switch Zyxel utilise par défaut l’adresse :

192.168.1.3

J’ai donc configuré temporairement le PC avec :

Paramètre	Valeur
Adresse IP	192.168.1.50
Masque	24
Passerelle	192.168.1.1

Une fois les deux équipements dans le même sous-réseau, le switch répond immédiatement au ping.

L’administration web ne fonctionne qu’en HTTPS sur les firmwares récents. La connexion s’effectue donc via :

https://192.168.1.3

Le navigateur affiche alors un avertissement de certificat SSL auto-signé, ce qui est parfaitement normal sur ce type d’équipement.

Lors de la première connexion :

le switch demande immédiatement la modification du mot de passe administrateur ;
puis l’accès à l’interface de configuration devient disponible.

J’ai ensuite :

désactivé le client DHCP du switch ;
attribué une adresse IP fixe, facultatif mais j’ai mis 192.168.1.11 ;
et sauvegardé la configuration avant intégration au réseau principal.

Cette étape de préparation permet d’avoir immédiatement :

un switch proprement configuré ;
une adresse d’administration connue ;
et une configuration stable avant la mise en production.

🌐 J’accède au switch sur le réseau local

Le switch est maintenant accessible via HTTPS :

https://192.168.1.11

Je peux rester sur mon ordinateur portable en direct ou le connecter au réseau local. Le switch a maintenant son IP fixe, donc pas de conflit.

🔀 Je configure les ports

Configuration retenue :

Port	Usage
Port 1	Routeur Synology
Port 2	Réseau local
Port 3	Réseau local
Port 4	Réseau local
Port 5	Raspberry Pi IDS

Je prépare une petite étiquette que je collerai sur le switch.

et voici le résultat :

🪞 Je configure le Port Mirroring

Le principe :

copier le trafic du port connecté au routeur ;
vers le port du Raspberry Pi.

Paramètres configurés :

Paramètre	Valeur
Port Mirroring	Enable
Mirror Direction	Both
Mirrored Port	Port 1
Monitor Port	Port 5

Le mode “Both” est important : il permet de voir le trafic entrant ET sortant.

❓ Pourquoi je ne mirror pas tous les ports ?

C’est une question qui revient souvent.

En pratique :

surveiller le port du routeur suffit largement ;
cela permet déjà d’observer tout le trafic Internet ;
sans surcharger inutilement le Raspberry Pi.

Mirrorer tous les ports :

augmente énormément le volume de trafic ;
génère des doublons ;
et peut saturer le système d’analyse.

Pour un réseau domestique, le mirroring du port routeur est largement suffisant.

🏷️ Je laisse les VLAN par défaut

Aucune configuration VLAN particulière n’a été nécessaire, j’ai tout laissé par défaut.

Tous les ports restent :

dans le VLAN 1 ;
en mode untagged.

Pour une installation résidentielle classique, cela fonctionne parfaitement.

⚙️ Je laisse QoS, LAG et IGMP presque par défaut

Les autres fonctions avancées du switch ont été laissées par défaut :

pas de Link Aggregation ;
pas de QoS spécifique ;
IGMP Snooping activé ;
EEE désactivé.

L’objectif est de garder :

un comportement simple ;
stable ;
prévisible.

🥧 J’installe le Raspberry Pi de supervision réseau

Une fois le switch manageable configuré et le port de mirroring opérationnel, il fallait maintenant mettre en place le capteur réseau capable d’analyser le trafic du réseau domestique.

L’objectif n’était pas de bloquer le trafic ni de remplacer le routeur, mais simplement de mettre en place un système de supervision totalement passif capable d’observer ce qu’il se passe sur le réseau local.

L’idée est simple : le switch Zyxel duplique le trafic réseau grâce au port mirroring, puis envoie cette copie vers un Raspberry Pi dédié à l’analyse.

Le Raspberry devient alors une sorte de “caméra de surveillance réseau”, capable d’observer les équipements connectés, les connexions externes, les échanges DNS, les flux TLS, les comportements suspects ou encore certaines attaques connues.

🤔 Pourquoi j’utilise un Raspberry Pi ?

Le Raspberry Pi est parfait pour ce type d’usage :

faible consommation électrique ;
fonctionnement totalement silencieux ;
coût réduit ;
format compact ;
parfait pour fonctionner 24h/24.

J’avais plusieurs modèles disponibles à la maison : Raspberry Pi 3, 3B et 3B+.

Le choix s’est finalement porté sur un Raspberry Pi 3B+ qui offre un bon compromis entre puissance, stabilité et consommation.

💾 Je choisis le stockage

Je voulais éviter les cartes microSD classiques.

Même si elles fonctionnent très bien pour des projets simples, elles supportent mal les écritures intensives sur le long terme, surtout lorsqu’il s’agit de générer des logs réseau en permanence.

J’ai donc choisi d’utiliser :

un SSD SATA 2.5 ;
un adaptateur USB vers SATA ;
Raspberry Pi OS Lite 64 bits.

L’objectif était d’obtenir une installation :

plus fiable ;
plus rapide ;
plus durable ;
et plus stable dans le temps.

🧰 J’installe le système

Le système a été installé avec Raspberry Pi Imager directement sur le SSD.

J’ai choisi :

Raspberry Pi OS Lite 64 bits ;
connexion Wi-Fi préconfigurée ;
SSH activé dès l’installation ;
nom d’hôte personnalisé ;
mise à jour automatique du système après le premier démarrage.

À peine démarré, le Raspberry est immédiatement apparu sur le réseau Wi-Fi domestique.

Une IP fixe lui a ensuite été attribuée depuis le routeur Synology afin de faciliter l’administration à distance.

A ce stade, je fixe l’adresse IP, chacun sa méthode, je le fais sur le routeur Synology mais cela peut se faire sur le Raspberry, à noter qu’à partir d’ici, à chaque fois que j’utiliserai 192.168.1.222, ce sera l’IP du Raspberry.

🩺 Je vérifie que la base système est saine

Avant d’installer Suricata, j’ai préféré vérifier que la base système était saine.

L’idée était simple : avant de transformer le Raspberry en sonde réseau 24h/24, il fallait s’assurer que le système démarrait bien sur le SSD, que l’alimentation était stable, que la température était correcte et que les interfaces réseau étaient dans l’état attendu.

📦 Mise à jour complète du système

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

Après la mise à jour, un redémarrage permet de repartir sur une base propre :

sudo reboot

💽 Je vérifie que le Raspberry démarre bien sur le SSD

lsblk

Résultat attendu :

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

Le point important ici est de voir que la partition racine / est bien montée depuis /dev/sda2.

Cela confirme que le Raspberry démarre bien sur le SSD USB et non sur une carte microSD.

📊 Je vérifie l’espace disque disponible

df -h

Résultat attendu :

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

Dans mon cas, le SSD de 32 Go offre largement assez d’espace pour le système, Suricata et les logs, à condition de mettre en place une rotation automatique des fichiers.

🌐 Je vérifie les interfaces réseau

ip a

Résultat attendu avant branchement du port miroir :

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

Dans cette architecture, le Wi-Fi sert à administrer le Raspberry en SSH.

L’interface Ethernet eth0, elle, sera réservée à la capture du trafic réseau en provenance du port miroir du switch.

🌡️ Je vérifie la température

vcgencmd measure_temp

Résultat obtenu :

temp=40.8'C

Une température autour de 40 à 60 °C est parfaitement correcte pour ce type d’usage.

Le Raspberry pourra donc fonctionner en continu sans problème particulier.

🔌 Je vérifie l’alimentation et le throttling

vcgencmd get_throttled

Résultat attendu :

throttled=0x0

C’est un point très important.

La valeur 0x0 signifie que le Raspberry ne détecte :

ni sous-tension ;
ni limitation de fréquence ;
ni problème d’alimentation.

🧠 Je vérifie que le système est bien en 64 bits

uname -a

Résultat attendu :

aarch64 GNU/Linux

La présence de aarch64 confirme que Raspberry Pi OS Lite 64 bits est bien installé.

🛡️ J’installe Suricata

Une fois le Raspberry entièrement opérationnel, j’ai installé le moteur IDS (Intrusion Detection System) qui va analyser le trafic réseau : Suricata.

Le choix de Suricata s’est imposé assez naturellement :

open source ;
très utilisé dans le monde professionnel ;
analyse avancée des protocoles ;
support des logs JSON ;
compatibilité Home Assistant ;
détection des anomalies réseau ;
empreintes JA3 et JA4 ;
mise à jour automatique des règles.

📦 Installation de Suricata

sudo apt install suricata -y

Une fois l’installation terminée, j’ai vérifié la version ainsi que les fonctionnalités compilées :

suricata --build-info

Résultat attendu :

This is Suricata version 7.x
AF_PACKET support: yes
eBPF support: yes
JA3 support: yes
JA4 support: yes

Cette étape permet de confirmer :

que Suricata est bien installé ;
que le support réseau Linux est actif ;
que les empreintes JA3/JA4 sont disponibles ;
que le moteur fonctionne correctement sur Raspberry Pi.

✅ Je vérifie le service Suricata

sudo systemctl status suricata

Résultat attendu :

Active: active (running)

Le service démarre automatiquement au boot du Raspberry.

📚 J’installe les règles de détection

Par défaut, Suricata ne contient quasiment aucune règle active.

Il faut donc télécharger une base de signatures réseau.

J’ai choisi les règles communautaires Emerging Threats Open.

📦 Installation de suricata-update

sudo apt install suricata-update -y

⬇️ Téléchargement des règles

sudo suricata-update

Résultat attendu :

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

Plus de 50 000 signatures de détection ont alors été installées automatiquement.

🔧 Je configure le réseau du Raspberry

À ce stade, un point extrêmement important devait être traité :

Le Raspberry ne doit jamais communiquer sur le réseau via son interface de capture.

Le port connecté au port miroir du switch doit uniquement écouter le trafic réseau, sans jamais envoyer de paquets.

Pour cela :

aucune adresse IP ne doit être présente sur eth0 ;
aucun DHCP ;
aucune passerelle ;
aucun trafic sortant ;
mode PROMISC obligatoire.

🔎 J’identifie le gestionnaire réseau utilisé

nmcli device status

Résultat obtenu :

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

Cela confirme que le système utilise NetworkManager.

🚫 Je désactive IPv4 et IPv6 sur eth0

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

🔄 Je redémarre la connexion réseau

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

👂 J’active le mode PROMISC en permanence

Le mode promiscuous permet à la carte réseau de recevoir tous les paquets copiés par le switch.

Création d’un service systemd :

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

Contenu du fichier :

[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

▶️ J’active le service

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

✅ Je vérifie l’interface réseau

ip a

Résultat attendu :

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

Très important :

aucune adresse IP ;
aucune ligne inet ;
mode PROMISC actif.

Le Raspberry devient alors une véritable sonde réseau passive.

🔌 Je branche le port miroir

Une fois le Raspberry prêt, le port 5 du switch Zyxel configuré en port miroir a été relié directement au port Ethernet du Raspberry Pi.

À partir de ce moment, le Raspberry commence à recevoir une copie du trafic réseau.

📡 Je fais un premier test de capture réseau

Avant de lancer Suricata, j’ai préféré vérifier que le mirroring fonctionnait réellement.

📦 Installation de tcpdump

sudo apt install tcpdump -y

🧪 Capture de test

sudo tcpdump -i eth0 -nn -c 20

Résultat obtenu :

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

Le trafic réseau a immédiatement commencé à défiler :

requêtes DNS ;
trafic HTTPS ;
communications IoT ;
flux internes ;
ICMP ;
connexions réseau diverses.

Cela confirmait que :

le port miroir Zyxel fonctionnait parfaitement ;
le Raspberry recevait bien une copie du trafic ;
la capture passive était opérationnelle.

⚙️ Je configure Suricata

Le fichier principal de configuration se trouve ici :

/etc/suricata/suricata.yaml

🏠 Je déclare le réseau local

J’ai adapté le réseau local à mon installation :

HOME_NET: "[192.168.1.0/24]"

Cela améliore :

la précision des alertes ;
les performances ;
la détection des flux internes et externes.

🧬 J’active les empreintes JA3 et JA4

Les empreintes JA3/JA4 permettent d’identifier certains comportements TLS de manière très précise.

Activation dans le bloc TLS :

ja3-fingerprints: yes
ja4-fingerprints: yes

✅ Je valide la configuration

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

Résultat attendu :

Configuration provided was successfully loaded

Cette commande est extrêmement utile :

détection des erreurs YAML ;
validation des règles ;
contrôle des chemins ;
vérification globale de la configuration.

🚀 Je démarre Suricata

🔄 Je redémarre le service

sudo systemctl restart suricata

📊 Je vérifie le statut

sudo systemctl status suricata

Résultat attendu :

Active: active (running)

📜 Je valide les logs réseau

Le cœur du système repose sur le fichier JSON généré par Suricata :

/var/log/suricata/eve.json

👀 Visualisation en temps réel

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

En générant un peu de trafic réseau (YouTube, navigation web, objets connectés…), les premiers événements apparaissent immédiatement :

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

Cela confirme que :

Suricata analyse correctement les paquets ;
les protocoles sont décodés ;
les logs JSON sont exploitables ;
la supervision réseau fonctionne réellement.

🗂️ Je mets en place une rotation automatique des logs

Un système de supervision réseau génère énormément de logs.

Il est donc indispensable de mettre en place une rotation automatique afin d’éviter le remplissage du SSD.

⚙️ Configuration logrotate

sudo nano /etc/logrotate.d/suricata

Configuration utilisée :

/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
}

Cette configuration :

conserve 14 jours d’historique ;
compresse les anciens logs ;
évite les erreurs si Suricata redémarre ;
limite fortement l’usure du SSD.

📡 J’exporte les flux réseau vers Home Assistant avec softflowd

Une fois Suricata opérationnel en mode IDS passif, l’objectif suivant était de transmettre des métadonnées réseau vers Home Assistant afin de pouvoir créer des tableaux de bord, des graphiques d’activité et des alertes intelligentes.

Pour cela, j’ai ajouté softflowd, un exporteur NetFlow léger parfaitement adapté à un Raspberry Pi 3B+.

L’idée est simple :

Suricata inspecte les paquets ;
softflowd observe les flux réseau ;
Home Assistant centralise et visualise l’activité.

Cette approche permet d’obtenir une supervision réseau avancée sans transformer le Raspberry en routeur ou en firewall actif.

📦 J’installe softflowd

L’installation est très simple :

sudo apt install softflowd -y

Une fois installé, il fallait identifier quelle interface réseau recevait le trafic miroir du switch Zyxel.

Comme précédemment, la commande suivante permet de vérifier l’état réseau :

ip a

Résultat observé :

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

L’interface eth0 est donc bien :

connectée ;
active ;
en mode PROMISC ;
sans adresse IP.

C’est exactement ce que je recherchais :

eth0 reçoit uniquement le trafic miroir du switch ;
wlan0 sert à administrer le Raspberry et à envoyer les données vers Home Assistant.

🧪 Je fais un premier test manuel

Avant toute automatisation, j’ai lancé softflowd manuellement pour vérifier le fonctionnement :

sudo softflowd -i eth0 -n 192.168.1.222:2055

Le Raspberry ne renvoie quasiment aucun message à l’écran, ce qui est normal.

Le programme se lance directement en arrière-plan.

Pour vérifier que les flux étaient bien exportés vers Home Assistant, j’ai ouvert une seconde session SSH puis lancé :

sudo tcpdump -i wlan0 udp port 2055

Résultat :

IP Suricata.42399 > 192.168.1.222.2055: UDP

Cette ligne confirme plusieurs points importants :

softflowd fonctionne ;
des flux NetFlow sont bien générés ;
Home Assistant reçoit les paquets ;
le routage via le Wi-Fi est correct.

🛠️ Je crée un service systemd dédié

Le service Debian fourni avec softflowd s’est révélé peu fiable dans ce contexte spécifique.

J’ai donc préféré créer mon propre service systemd.

Création du fichier :

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

Configuration utilisée :

[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

Puis activation du service :

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

✅ Je vérifie le bon fonctionnement

Pour confirmer le bon fonctionnement :

sudo systemctl status softflowd-ids

Résultat :

Active: active (running)

softflowd v1.1.1 starting data collection
Exporting flows from eth0 to [192.168.1.222]:2055

À ce stade, l’architecture réseau est totalement opérationnelle :

le switch Zyxel duplique le trafic ;
le Raspberry reçoit la copie des paquets ;
Suricata analyse le trafic ;
softflowd exporte les flux ;
Home Assistant centralise les données.

Le plus intéressant est que cette surveillance reste totalement passive :

aucun impact sur le réseau ;
aucune modification des équipements ;
aucune interruption possible du trafic ;
consommation électrique extrêmement faible.

Le Raspberry devient ainsi une véritable sonde réseau domestique capable d’offrir une visibilité très avancée sur toute l’installation domotique et informatique de la maison.

🏠 J’intègre Home Security Assistant dans Home Assistant

Une fois Suricata opérationnel et les flux NetFlow correctement exportés vers Home Assistant via softflowd, l’étape suivante consistait à exploiter réellement toutes ces données.

L’objectif n’était plus uniquement de capturer du trafic réseau, mais de :

corréler les événements de sécurité ;
identifier les équipements actifs ;
détecter des comportements anormaux ;
visualiser le réseau domestique en temps réel ;
transformer Home Assistant en véritable centre de supervision sécurité.

Pour cela, j’ai installé l’excellente intégration Home Security Assistant réalisée par domo-monster.

Cette intégration permet de centraliser :

les logs Suricata ;
les flux NetFlow ;
les statistiques réseau ;
les événements suspects ;
les détections de vulnérabilités ;
les comportements réseau inhabituels.

Dans mon cas, HACS était déjà installé dans Home Assistant, ce qui simplifie énormément l’installation.

➕ J’ajoute le dépôt personnalisé dans HACS

Dans Home Assistant :

HACS
→ Intégrations
→ ⋮ (menu en haut à droite)
→ Dépôts personnalisés

Ajout du dépôt GitHub :

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

Puis sélection de la catégorie :

Integration

Enfin :

Ajouter

📦 J’installe l’intégration

Une fois le dépôt ajouté :

HACS
→ Intégrations

Recherche de :

Home Security Assistant

Puis installation de la dernière version disponible.

Après le téléchargement, Home Assistant demande un redémarrage complet.

🔌 J’ajoute l’intégration dans Home Assistant

Après redémarrage :

Paramètres
→ Appareils et services
→ Ajouter une intégration

Puis recherche de :

Home Security Assistant

⚙️ Je configure Home Security Assistant

Après l’installation de l’intégration, Home Assistant ouvre automatiquement la fenêtre de configuration de Home Security Assistant.

Cette configuration reste accessible à tout moment :

Paramètres
→ Appareils et services
→ Home Security Assistant
→ Configurer (roue crantée)

La plupart des paramètres proposés peuvent être laissés par défaut.

L’intégration est déjà pensée pour fonctionner efficacement dans un environnement domestique standard.

Dans mon cas, seuls quelques paramètres ont réellement nécessité une attention particulière.

🌐 Hôte d’écoute

0.0.0.0

Cette valeur doit être conservée.

Elle permet à Home Security Assistant d’écouter les flux NetFlow sur toutes les interfaces réseau du serveur Home Assistant.

C’est particulièrement utile lorsque :

Home Assistant possède plusieurs interfaces réseau ;
les flux arrivent depuis un autre équipement ;
la télémétrie est exportée par une sonde IDS distante comme ici avec le Raspberry.

📡 Port d’écoute UDP

Ce port doit correspondre exactement à celui configuré précédemment dans softflowd :

softflowd -i eth0 -n 192.168.1.222:2055

Le port 2055 est un standard très courant pour NetFlow.

🏠 Réseaux internes

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

J’ai volontairement conservé cette configuration par défaut.

Même si mon réseau actuel fonctionne principalement en :

192.168.1.0/24

la configuration par défaut reste plus souple et plus évolutive.

Elle permet notamment :

l’ajout futur de VLANs ;
la séparation des objets IoT ;
la gestion de réseaux invités ;
la compatibilité IPv6 ;
l’évolution future de l’infrastructure.

Dans un environnement domestique moderne, il est généralement préférable de conserver cette configuration étendue.

🕵️ Fenêtre de détection de scan de ports

600 secondes

Cette valeur correspond à :

10 minutes de surveillance glissante ;
une bonne sensibilité de détection ;
une charge raisonnable pour Home Assistant.

L’objectif est d’éviter :

les faux positifs trop agressifs ;
les alertes inutiles ;
la surcharge du moteur d’analyse.

Pour un réseau domestique, la valeur par défaut est très correcte.

🚪 Ports uniques avant alerte de scan

Cette valeur détermine à partir de combien de ports différents un équipement sera considéré comme potentiellement en train de réaliser un scan réseau.

Là encore, la valeur par défaut est adaptée à un usage domestique.

Une valeur trop basse pourrait provoquer énormément de faux positifs avec :

Chromecast ;
Apple TV ;
objets connectés ;
mDNS ;
UPnP ;
découverte automatique réseau.

📈 Seuil de trafic sortant élevé

50000000

Ce paramètre définit le volume de données considéré comme anormalement élevé sur une période donnée.

Dans mon cas, j’ai conservé la valeur par défaut.

L’objectif est principalement de détecter :

un équipement compromis ;
un upload massif inhabituel ;
une exfiltration de données ;
un appareil IoT extrêmement bavard.

📋 Activer le panneau latéral

Option laissée activée.

Cela ajoute directement Home Security Assistant dans la barre latérale de Home Assistant.

C’est extrêmement pratique.

🔐 Droits administrateur pour le panneau latéral

Option également conservée activée.

Cela limite l’accès aux informations réseau sensibles uniquement aux administrateurs Home Assistant.

Dans un environnement multi-utilisateurs, c’est une bonne pratique de sécurité.

🔎 Scanner réseau actif

J’ai laissé le scanner actif activé.

Ce composant permet à Home Security Assistant :

de découvrir les équipements réseau ;
d’identifier les hôtes actifs ;
de corréler les adresses IP ;
d’enrichir les informations réseau.

Cette fonctionnalité complète parfaitement les analyses passives réalisées par Suricata.

⏱️ Intervalle du scan actif

3000 secondes

Cette valeur correspond à environ :

50 minutes

Le scanner actif ne tourne donc pas en permanence.

C’est une excellente chose dans un environnement domestique.

Cela permet :

de limiter la charge réseau ;
d’éviter des scans agressifs ;
de ne pas perturber certains objets IoT sensibles ;
de conserver une approche discrète.

Pour un laboratoire ou un réseau professionnel très dynamique, on pourrait réduire cette valeur.

Mais pour une maison connectée, la valeur par défaut est très raisonnable.

🚪 Ports à scanner

La liste fournie par défaut peut être conservée.

Elle contient les ports les plus courants.

L’objectif du scanner n’est pas d’effectuer un scan exhaustif de sécurité offensive, mais plutôt :

d’identifier les équipements ;
de détecter les services exposés ;
de cartographier le réseau ;
d’alimenter les corrélations de sécurité.

Dans mon cas, je n’ai rien modifié.

🚫 Exceptions du scanner

Ce champ permet d’exclure certaines IP des scans actifs.

Par défaut, il peut rester vide.

Cependant, cette fonctionnalité peut devenir utile pour :

des équipements fragiles ;
certaines imprimantes ;
des objets IoT peu robustes ;
des équipements industriels ;
des appareils très sensibles aux scans réseau.

Dans mon environnement, aucun équipement ne nécessitait d’exclusion.

📛 Activer la résolution DNS inverse

Cette option mérite clairement d’être activée.

Elle permet de transformer des IP peu parlantes en noms d’hôtes beaucoup plus lisibles.

Par exemple, au lieu d’afficher :

192.168.1.42

Home Security Assistant pourra parfois afficher :

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

Cela améliore énormément :

la lisibilité ;
l’analyse des événements ;
l’identification rapide des équipements.

🧠 Flux de renseignement sur les menaces

Les URLs proposées par défaut peuvent être conservées.

Home Security Assistant télécharge automatiquement plusieurs listes de réputation et de blocage provenant de sources reconnues :

Abuse.ch ;
SSLBL ;
AdGuard ;
autres flux communautaires.

Ces flux servent à :

identifier des IP malveillantes ;
repérer des domaines suspects ;
détecter certains comportements connus ;
alimenter les alertes de sécurité.

C’est l’un des aspects les plus intéressants de l’intégration : elle enrichit automatiquement les données réseau collectées localement avec du renseignement externe.

🌍 Proxy DNS

Dans mon cas, cette option est restée désactivée.

Le proxy DNS permettrait à Home Security Assistant :

d’intercepter les requêtes DNS ;
de journaliser les domaines consultés ;
d’appliquer du blocage DNS ;
d’effectuer une analyse plus poussée.

Mais cela implique :

des privilèges réseau plus élevés ;
une architecture plus intrusive ;
une dépendance supplémentaire.

Pour un premier déploiement domestique, j’ai préféré rester simple et stable.

🔢 Port du proxy DNS

Valeur standard du protocole DNS.

Comme le proxy DNS reste désactivé, ce paramètre n’a pas d’impact.

☁️ Résolveurs DNS amont

1.1.1.1

Cloudflare est utilisé ici comme résolveur DNS amont.

Cette valeur peut être remplacée selon les préférences :

Google DNS ;
Quad9 ;
AdGuard DNS ;
Pi-hole ;
Unbound local.

Dans mon cas, j’ai conservé la valeur proposée.

🗃️ Rétention du journal DNS

24 heures

Cette valeur définit combien de temps les journaux DNS restent conservés.

Pour un environnement domestique :

24 heures offrent déjà une bonne visibilité ;
cela limite la consommation mémoire ;
cela évite une accumulation inutile de données.

Une conservation plus longue pourrait être pertinente dans un contexte professionnel ou forensique.

🚫 Sources threat-intel utilisées pour le blocage

Ce champ permet de définir quelles sources de renseignement seront utilisées pour alimenter les mécanismes de blocage.

Dans mon cas, je l’ai laissé vide. Je préfère toujours commencer en mode observateur avant d’automatiser des contre-mesures.

⛔ Catégories DNS bloquées

Ce champ permet de bloquer certaines catégories de domaines :

adultes ;
gambling ;
malwares ;
tracking ;
phishing ;
etc.

Là encore, je l’ai laissé vide pour ce premier déploiement.

Cette fonctionnalité pourra être activée plus tard, une fois le comportement normal du réseau bien compris.

J’utilise déjà Safe Access intégré à mon routeur Synology pour filtrer les équipements utilisés par mes filles.

Il fait cela via une interface graphique très agréable. On verra plus tard si je viens aussi faire du blocage DNS ici.

↪️ Redirections DNS locales

Cette fonctionnalité permet de rediriger certains domaines vers des IP spécifiques.

Par exemple :

monservice.local=192.168.1.10

ou encore :

ads.example.com=0.0.0.0

Dans mon cas, aucune redirection n’était nécessaire. Le champ est donc resté vide.

🦠 Je crée un compte VirusTotal et je récupère ma clé API

VirusTotal permet d’enrichir les informations de sécurité avec des données de réputation sur des IP, domaines, URL ou fichiers suspects.

Pour l’utiliser avec Home Security Assistant, il faut créer un compte gratuit sur :

https://www.virustotal.com

Une fois connecté :

Profil utilisateur
→ API key

VirusTotal indique que la clé API publique est disponible dans le menu du compte utilisateur une fois connecté. Cette clé doit rester privée et ne doit évidemment jamais être publiée dans un article, une capture d’écran ou un dépôt Git.

Dans Home Assistant :

Paramètres
→ Appareils et services
→ Home Security Assistant
→ Configurer

Puis je renseigne le champ :

VirusTotal API Key

J’ai ensuite conservé le budget quotidien proposé :

Pour mon usage domestique, c’est largement suffisant.

L’objectif n’est pas d’interroger VirusTotal en permanence, mais seulement d’enrichir les éléments suspects afin de mieux comprendre ce que Home Security Assistant détecte.

🚨 Je crée un compte AbuseIPDB et je récupère ma clé API

AbuseIPDB complète très bien VirusTotal.

Là où VirusTotal donne une réputation globale, AbuseIPDB est particulièrement utile pour identifier des adresses IP connues pour :

des scans réseau ;
des tentatives de brute force ;
des comportements abusifs ;
des activités malveillantes signalées par la communauté.

Je crée donc un compte gratuit sur :

https://www.abuseipdb.com

Une fois connecté :

Account
→ API
→ Create Key

Je donne un nom à la clé, par exemple :

Home Security Assistant

Puis je copie la clé API générée.

Comme pour VirusTotal, cette clé doit rester strictement privée. AbuseIPDB rappelle d’ailleurs que les clés API ne doivent pas être exposées publiquement.

Dans Home Assistant :

Paramètres
→ Appareils et services
→ Home Security Assistant
→ Configurer

Puis je renseigne le champ :

AbuseIPDB API Key

J’ai conservé le budget quotidien :

Et j’ai laissé le seuil de confiance AbuseIPDB avant interrogation VirusTotal sur une valeur raisonnable.

Le principe est intéressant : si AbuseIPDB considère une IP suffisamment suspecte, Home Security Assistant peut ensuite enrichir l’analyse avec VirusTotal.

Cela évite :

les appels API inutiles ;
la consommation trop rapide des quotas ;
et les enrichissements sur des IP parfaitement banales.

🧠 Pourquoi j’ajoute ces deux services ?

Au départ, Home Security Assistant voit surtout :

des IP ;
des flux ;
des volumes de trafic ;
des comportements réseau.

Avec VirusTotal et AbuseIPDB, ces informations deviennent beaucoup plus lisibles.

Au lieu d’avoir simplement :

IP suspecte : 185.xxx.xxx.xxx

Home Security Assistant peut enrichir l’information avec des éléments de réputation :

IP déjà signalée ;
score de confiance ;
catégorie de menace ;
historique de signalements ;
contexte de sécurité.

Pour une installation domestique, cela permet de mieux comprendre ce que l’on observe, sans pour autant automatiser immédiatement des blocages.

Et c’est exactement l’approche que je préfère :

observer d’abord ;
comprendre ensuite ;
automatiser seulement si c’est vraiment nécessaire.

🎯 Confiance AbuseIPDB avant interrogation VirusTotal

Ce curseur définit à partir de quel score AbuseIPDB une IP sera considérée suffisamment suspecte pour déclencher une interrogation VirusTotal.

Le principe est intelligent :

éviter les appels inutiles ;
réduire la consommation API ;
prioriser les IP réellement suspectes.

🧹 Rétention des IP propres

5 heures

Les IP considérées comme normales sont conservées peu longtemps.

C’est cohérent :

le trafic légitime est extrêmement volumineux ;
il est inutile de le conserver trop longtemps ;
cela économise mémoire et stockage.

⚠️ Rétention des IP suspectes

48 heures

Les IP suspectes restent visibles plus longtemps afin de :

faciliter l’analyse ;
repérer des comportements répétitifs ;
corréler certains événements.

Cette valeur me semble particulièrement pertinente pour un usage domestique.

☠️ Rétention des IP malveillantes

168 heures

Soit :

7 jours

Les IP identifiées comme réellement malveillantes sont conservées beaucoup plus longtemps.

Cela permet :

d’identifier des attaques répétées ;
de suivre certaines tentatives persistantes ;
de conserver un historique exploitable.

Pour un Raspberry Pi domestique, cette valeur reste raisonnable.

🧠 TTL du cache d’enrichissement

1440 minutes

Soit :

24 heures

Ce paramètre évite de réinterroger en permanence les services de renseignement externes.

Cela permet :

de limiter les appels API ;
de réduire la charge ;
de rendre l’intégration plus fluide ;
d’éviter certains blocages liés aux quotas.

Là encore, la valeur par défaut est très bien pensée.

📊 Budget quotidien de requêtes VirusTotal

Ce paramètre limite le nombre de requêtes quotidiennes envoyées à VirusTotal.

📈 Budget quotidien de requêtes AbuseIPDB

Même logique ici. Ce paramètre définit le nombre maximal d’interrogations vers AbuseIPDB.

🗃️ URL de l’API NVD

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

Cette URL pointe vers la base officielle NVD :

National Vulnerability Database

gérée par le NIST américain.

C’est l’une des références mondiales en matière de :

vulnérabilités CVE ;
scores CVSS ;
références de sécurité ;
suivi des failles publiques.

Home Security Assistant peut utiliser cette base afin de :

repérer des produits vulnérables ;
corréler certains équipements ;
mettre en évidence des risques potentiels.

L’URL par défaut est évidemment à conserver.

⏳ TTL du cache NVD

12 heures

Ce paramètre définit à quelle fréquence les informations CVE sont rafraîchies.

Une mise à jour trop fréquente :

augmenterait inutilement le trafic ;
consommerait davantage de ressources ;
n’apporterait pas de réel bénéfice.

La valeur proposée représente un excellent compromis.

📅 Année minimale des CVE

Cette option est particulièrement intéressante.

Elle permet de limiter l’analyse aux vulnérabilités récentes.

Pourquoi est-ce utile ?

Parce que la base CVE contient des dizaines de milliers d’entrées historiques.

Or, dans un environnement domestique :

les vulnérabilités très anciennes sont souvent moins pertinentes ;
les équipements récents sont davantage concernés par les CVE modernes ;
cela réduit fortement le bruit.

La valeur 2020 est donc cohérente :

elle conserve plusieurs années d’historique ;
sans surcharger inutilement le système.

🔍 Mots-clés de recherche NVD

Ce champ contient une liste de produits et services à surveiller dans les bases CVE :

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

Cette liste permet à Home Security Assistant :

d’identifier certaines technologies présentes sur le réseau ;
de rechercher les vulnérabilités associées ;
de faire remonter des alertes contextualisées.

Elle rapproche Home Assistant d’une logique de :

gestion de vulnérabilités ;
inventaire de surface d’attaque ;
cyber-hygiène domestique.

Dans mon cas, j’ai conservé la liste proposée par défaut.

Elle couvre déjà beaucoup de services fréquemment présents dans les laboratoires domestiques et les environnements self-hosted.

📉 Statistiques : afficher les N premières entrées

Le curseur permet de choisir combien d’éléments seront affichés dans les statistiques et tableaux de bord.

Par exemple :

top des IP actives ;
sources suspectes ;
ports les plus utilisés ;
vulnérabilités détectées ;
activités réseau importantes.

La valeur intermédiaire proposée par défaut est très bien équilibrée :

assez d’informations pour être utile ;
sans surcharger l’interface Home Assistant.

✅ Validation finale de la configuration

Une fois cette dernière page validée, Home Security Assistant devient pleinement opérationnel.

Quelques minutes après le démarrage, les premiers indicateurs commencent déjà à apparaître dans Home Assistant.

C’est probablement l’un des moments les plus satisfaisants du projet :

voir enfin le réseau domestique prendre vie sous forme de données de sécurité exploitables.

Après :

la configuration du port miroir ;
l’installation de Suricata ;
la collecte des flux réseau ;
la configuration de softflowd ;
l’intégration dans Home Assistant ;

le système commence enfin à produire une vision cohérente de l’activité réseau domestique.

Voici par exemple les premiers capteurs apparus quelques instants après la mise en route :

HSA Active Devices : nombre d’équipements actifs détectés sur le réseau ;
HSA High Egress Sources : sources générant un volume inhabituellement élevé de trafic sortant ;
HSA NVD Keywords : mots-clés et technologies surveillés dans la base de vulnérabilités NVD ;
HSA Open Findings : alertes et éléments de sécurité actuellement ouverts ;
HSA Scanned Devices : nombre d’équipements analysés par le scanner actif ;
HSA Suspicious Sources : sources réseau considérées comme suspectes selon les règles de détection et les flux de renseignement ;
HSA Total Flows : nombre total de flux réseau observés ;
HSA Vulnerabilities : vulnérabilités détectées ou corrélées à partir des informations collectées.

Dans mon cas, les chiffres ont commencé à grimper très rapidement. Avant d’écrire cette page, j’ai laissé tourner le système toute une nuit :

plus de 150 000 flux réseau détectés ;
plus de 60 équipements actifs ;
des dizaines de vulnérabilités identifiées ;
plusieurs sources considérées comme suspectes.

Et c’est précisément là que le projet devient passionnant.

On réalise soudain à quel point un réseau domestique moderne génère énormément d’activité :

objets connectés ;
assistants vocaux ;
smartphones ;
NAS ;
services cloud ;
TV connectées ;
services de streaming ;
containers ;
automatisations domotiques.

Même dans un environnement personnel, la surface réseau devient rapidement très complexe.

Et c’est justement ce que Home Security Assistant permet enfin de rendre visible.

Je renomme tous les capteurs en leur donnant des titres en français.

👀 Premières impressions après la mise en route

Pour l’instant, les informations qui remontent dans HA sont limitées à des nombres, je suis donc allé dans l’interface de HSA.

Ce qui m’a immédiatement frappé, c’est la quantité d’informations disponibles sans configuration complexe supplémentaire.

Très rapidement, Home Assistant affichait :

les appareils actifs ;
les volumes de trafic ;
les IP suspectes ;
les échanges réseau importants ;
des statistiques de sécurité lisibles ;
des débuts de corrélation de menaces.

Et surtout, tout cela directement intégré dans l’écosystème domotique existant.

C’est probablement ce qui rend ce projet particulièrement intéressant : on apporte des mécanismes de cybersécurité avancés dans un environnement Home Assistant, sans devoir déployer une infrastructure professionnelle lourde et complexe.

Le résultat est à la fois :

pédagogique ;
visuel ;
utile ;
évolutif.

À cette étape, je suis à la fois très heureux et extrêmement curieux de poursuivre la découverte de Home Security Assistant.

Je n’imagine même pas le temps passé par domo-monster pour réaliser ce travail qui, une fois configuré, s’illumine et s’anime presque tout seul.

L’écran Map est vivant, lisible et vraiment impressionnant à observer.

Franchement : bravo.

🎯 Conclusion

Cette architecture apporte une vraie couche de visibilité réseau :

sans complexifier l’installation ;
sans modifier le trafic ;
et sans dépendre du routeur.

Le couple :

switch manageable + port mirroring + Raspberry Pi

constitue une excellente base pour construire un IDS domestique performant et entièrement local.

Et surtout :

l’analyse reste totalement passive ;
ce qui garantit une excellente stabilité du réseau.

Pour un laboratoire domotique avancé ou un réseau résidentiel moderne, c’est une solution particulièrement élégante.

J’ai maintenant largement de quoi m’amuser pendant quelques week-ends… ou quelques nuits d’insomnie 😄

Je ne pensais honnêtement pas que ce RetEx deviendrait aussi long et dense… mais finalement, j’y suis arrivé.

Alors si vous avez lu jusqu’ici : bravo 😅

Je vais m’arrêter à ce stade pour cet article, mais il est très probable que je publie la suite avec d’autres RetEx autour de Home Security Assistant et de son exploitation au quotidien.

Et évidemment, je termine par un énorme remerciement à domo-monster, qui nous apporte ici sur un plateau d’argent le fruit de probablement très nombreuses années d’expérience et d’investissement dans le domaine de la cybersécurité.

Le résultat est vraiment impressionnant.

Question ? Besoin d’aide ?

J’ai posté un message sur le forum de la communaté francophone de Home assistant, n’hésitez pas à l’utiliser pour me questionner ou apporter votre expérience :

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