Je souhaite obtenir un résumé précis d’une audition récente entre la ministre du numérique et le directeur de l’ANSSI. Cette vidéo, disponible sur le site de l’Assemblée nationale, ne fait l’objet d’aucun compte-rendu écrit officiel. Mon objectif est clair : extraire le contenu pour l’analyser sereinement.

La vidéo est hébergée à cette adresse : vidéo.assemblee-nationale.fr. Je commence donc par inspecter le code source de la page pour identifier le fichier média.

Je localise le fichier source de la vidéo

J’ouvre les outils de développement de mon navigateur en appuyant sur la touche F12. Je fouille le code HTML à la recherche de la balise vidéo. Je trouve rapidement mon bonheur dans une balise <source> pointant vers un flux HLS.

Voici l’URL exacte que j’ai récupérée :

<source src="https://videos-an.vodalys.com/videos/definst/mp4/ida/domain1/2026/10/las2_20261001135205.smil/master.m3u8">

Le fichier source est donc identifié. Je peux maintenant procéder à sa récupération pour le convertir en un fichier MP4 classique, plus facile à manipuler pour la suite de mes tests.

Je récupère et convertis la vidéo avec VLC

J’utilise mon couteau suisse multimédia, VLC Media Player, pour télécharger le flux. Une fois le fichier video.mp4 enregistré sur mon disque dur, je me concentre sur la retranscription.

Je me lance alors dans une quête pour trouver l’outil capable de transcrire un fichier aussi lourd en français.

Je teste les outils de transcription en ligne

Ma vidéo dépasse largement le gigaoctet. Je cherche une solution gratuite ou abordable pour obtenir un texte fidèle. Mon premier réflexe se tourne vers Turboscribe.ai.

Turboscribe.ai : une limite bloquante

Je me rends sur leur tableau de bord. J’ajoute mon fichier et je sélectionne le mode « Baleine » pour une précision maximale. La transcription se lance et la rapidité est au rendez-vous.

Cependant, je me heurte vite à un mur : la version gratuite s’arrête net à 30 minutes d’audio. Mon fichier étant bien plus long, je dois chercher une alternative.

Je contourne la limite de poids avec l’extraction audio

Je me tourne ensuite vers Notta.ai, réputé pour sa qualité sur la langue française. Nouveau problème : mon fichier vidéo est refusé car il dépasse la limite de 1 Go.

Pour résoudre ce souci, je décide d’extraire uniquement la piste audio. Le fichier sera bien plus léger. Je retourne sur VLC pour cette opération technique.

Voici la manipulation que j’effectue pour isoler le son :

1. J’ouvre VLC et je vais dans le menu Média puis Convertir / Enregistrer.
2. J’ajoute mon fichier video.mp4 et je clique sur le bouton de conversion.
3. Dans le profil, je choisis Audio – MP3.
4. Je lance la conversion et j’obtiens un fichier video.mp3 de seulement 177 Mo.

C’est beaucoup plus gérable pour les outils en ligne. Je retourne donc sur Notta.ai avec ce nouveau fichier.

Notta.ai et Vook.ai : des essais infructueux

J’importe mon fichier MP3 sur Notta. L’outil travaille bien, mais lors de la récupération, je constate que seul un extrait de 30 minutes est disponible. L’inscription promise pour débloquer la suite ne fonctionne pas comme attendu : l’option payante revient systématiquement.

Je ne me décourage pas. Je teste Vook.ai en espérant mieux.

J’envoie mon fichier MP3, je laisse tourner… et c’est le même constat. Le service me bloque également à 30 minutes d’écoute.

Mon avis sur la recherche du bon outil

Face à ces limitations successives, je comprends que la gratuité a des plafonds stricts pour les gros fichiers. Je dois maintenant me tourner vers une dernière solution : Scribe.cemea.org.

Je continue mon test avec cet outil pour voir s’il parviendra à traiter l’intégralité de l’audition sans me demander de paiement.

46 minutes après, je reçois le fichier transcription.zip, il fait 630ko et contient 3 fichiers : phrases.txt subtitles.srt timed_phrases.txt

C’est vraiment parfait, j’ai exactement ce que je voulais.

Je peux injecter le fichier phrases.txt dans une IA et travailler tout cela pour résumer, extraire les points clés …

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 :

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 :

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 :

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

2055

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

100

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

53

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é :

500

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 :

1000

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.

Nota : Penser à rendre votre profil privé sinon vous donnez au monde votre ip.

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

500

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

Budget quotidien de requêtes AbuseIPDB

1000

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

2020

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

C’est à dire, des outils malveillants utilisent ils mon réseau (pc, NAS, routeur, HA, …) ??

C’est comme cela que je suis tombé sur GreyNoise, un service vraiment intéressant qui permet de savoir si une adresse IP fait partie du “bruit” d’Internet, c’est-à-dire si elle est observée dans des activités de scan, de sondage ou de trafic malveillant.

GreyNoise décrit justement son approche comme une manière de qualifier le bruit de fond d’Internet et de contextualiser une IP observée.

Et comme souvent avec moi, après quelques tests, je me suis dit : “Tiens, ce serait quand même pratique d’avoir ça directement dans Home Assistant”.

Au départ, je pensais faire quelque chose de très simple avec une requête HTTP classique. Sur le papier, cela semblait trivial. En pratique, la méthode la plus évidente n’a pas fonctionné chez moi comme je l’espérais. J’ai donc changé d’approche et je suis finalement parti sur un capteur en ligne de commande. Dans cet article, je te raconte tout cela pas à pas, comme je l’ai réellement mis en place chez moi, avec les cartes Lovelace pour l’affichage final.

Mon objectif

Mon objectif était simple : intégrer dans Home Assistant un capteur capable d’interroger GreyNoise pour connaître l’état de mon IP publique, puis afficher le résultat dans un dashboard clair et lisible.

L’idée n’était pas de transformer Home Assistant en centre de cybersécurité avancé, mais plutôt d’ajouter un petit indicateur de contexte.

Un coup d’œil rapide devait me permettre de savoir si mon IP était vue comme bénigne, inconnue, ou éventuellement liée à une activité plus suspecte.

GreyNoise expose précisément ce type d’information via son endpoint public de vérification.

Je voulais aussi quelque chose de compréhensible pour un débutant : un capteur, quelques attributs utiles, et de jolies cartes pour rendre tout cela lisible sans avoir à ouvrir un terminal et évidemment sans prendre d’abonnement de quoi que ce soit et sans m’enregistrer non.

GreyNoise, c’est quoi ?

Quand on découvre GreyNoise pour la première fois, on peut se demander à quoi cela sert exactement.

En version très simple, GreyNoise observe en permanence le bruit de fond d’Internet : les scans automatisés, les sondages d’adresses IP, les tentatives de connexion répétitives, tous ces comportements qu’on ne voit pas forcément à l’œil nu mais qui existent en permanence sur le réseau mondial.

GreyNoise présente justement son service comme un moyen de distinguer l’activité de fond du trafic réellement significatif.

L’intérêt de GreyNoise, c’est qu’il permet de contextualiser une adresse IP. En gros, on peut savoir si cette IP est connue comme participant à ce bruit Internet, si elle est considérée comme légitime, ou si elle n’est tout simplement pas connue de leurs systèmes. Leur service public de vérification renvoie ce contexte sous forme de JSON.

Quand j’ai compris cela, j’ai trouvé l’idée excellente pour la maison. On a souvent une box Internet, parfois des redirections de ports, un VPN, des équipements accessibles à distance, et on ne sait pas toujours comment notre IP est “vue” depuis l’extérieur.

Sans être un outil de sécurité complet, GreyNoise donne un indice intéressant.

Les outils gratuits GreyNoise

Ce que j’ai bien aimé, c’est qu’on peut déjà tester des choses gratuitement, sans rentrer tout de suite dans une intégration compliquée.

Le premier outil pratique, c’est leur page de vérification en ligne. On ouvre la page, et elle indique directement comment l’IP publique utilisée pour la navigation est vue par GreyNoise.

• https://check.labs.greynoise.io/

C’est très pratique pour faire un premier test rapide, sans rien installer.

L’autre point très intéressant, c’est qu’il existe une API simple à interroger. Et c’est précisément cette API que j’ai voulu exploiter dans Home Assistant. En ligne de commande, cela revient à faire une requête du type :

curl -s -H "Accept: application/json" https://check.labs.greynoise.io/api/v1/check

Chez moi, la réponse ressemblait à ceci :

{
  "ip": "82.65.xxx.xxx",
  "status": "not_found",
  "classification": null,
  "noise": false,
  "common_business_services": false,
  "trust_level": null,
  "error": "ip not found"
}

Ce format correspond bien au fonctionnement documenté du service public GreyNoise, qui renvoie notamment l’IP, le statut, la classification, l’indicateur noise, l’indicateur common_business_services, le niveau de confiance et un éventuel message d’erreur.

Dit simplement : mon IP n’était pas connue par GreyNoise, ce qui est plutôt rassurant dans ce contexte.

Mon premier essai dans Home Assistant

Comme souvent, j’ai commencé par la solution qui me semblait la plus “propre” : utiliser un capteur REST dans Home Assistant.

Sur le principe, c’était logique. J’avais une URL HTTP qui renvoyait du JSON, donc je me suis dit qu’un capteur REST ferait parfaitement l’affaire. La documentation Home Assistant REST permet justement de définir une ressource HTTP, de lire le JSON avec value_template et de récupérer des champs comme attributs avec json_attributes.

Je pensais récupérer directement l’état et les attributs comme l’IP, la classification ou encore le niveau de confiance.

Sauf que chez moi, cette approche n’a pas fonctionné correctement. Le capteur restait dans un état inexploitable. Plutôt que de perdre du temps à m’acharner sur une méthode qui ne donnait pas un résultat stable dans mon installation, j’ai décidé de basculer sur une autre solution.

Et honnêtement, c’est souvent comme cela que ça se passe en domotique : on part avec une idée, puis on ajuste en fonction du réel.

Pourquoi je suis parti sur command_line

J’ai finalement choisi de m’appuyer sur un capteur en ligne de commande. Ce n’est pas forcément la méthode la plus “élégante” sur le papier, mais dans mon cas elle a été bien plus fiable.

Le principe est simple : Home Assistant exécute une commande curl, récupère la réponse JSON, puis extrait l’état principal et plusieurs attributs. L’intégration command_line de Home Assistant prend justement en charge une commande shell, un value_template et des attributs JSON.

Autrement dit, je suis parti d’un test qui fonctionnait déjà dans mon terminal, puis je l’ai simplement transposé dans Home Assistant.

C’est souvent une bonne stratégie pour les débutants : quand quelque chose marche déjà à la main, il est plus facile de comprendre ensuite ce qui se passe dans Home Assistant.

Configuration dans Home Assistant

Dans mon fichier configuration.yaml, j’ai commencé par inclure un fichier dédié pour mes capteurs en ligne de commande :

command_line: !include command_line.yaml

Ensuite, dans command_line.yaml, j’ai ajouté ce capteur :

- sensor:
    name: "GreyNoise IP Check"
    unique_id: greynoise_ip_check
    icon: mdi:shield-search
    command: 'curl -s -H "Accept: application/json" https://check.labs.greynoise.io/api/v1/check'
    command_timeout: 20
    scan_interval: 100800
    value_template: "{{ value_json['status'] }}"
    json_attributes:
      - ip
      - classification
      - noise
      - common_business_services
      - trust_level
      - error

Je vais détailler cela très simplement :

• command : c’est la commande réellement exécutée par Home Assistant.
• command_timeout : j’autorise ici jusqu’à 20 secondes avant abandon.
• scan_interval : c’est la fréquence d’exécution, en secondes. Ici j’ai choisi 100800 secondes, donc toutes les 28 heures.
• value_template : cela récupère la valeur principale du capteur, ici le champ status du JSON.
• json_attributes : cela permet de stocker d’autres champs utiles comme attributs du capteur.

Pourquoi 28 heures ? Tout simplement parce que je n’avais pas besoin d’interroger GreyNoise toutes les heures. Et je veux éviter 24h car beaucoup de capteurs sont sur 24, donc ce sera 28h aujourd’hui. Ce n’est pas une donnée qui change en permanence chez moi, donc je préfère une exécution espacée.

Ce que le capteur me remonte

Une fois le capteur opérationnel, je récupère un état principal et plusieurs attributs.

L’état principal est le champ status. Chez moi, par exemple, j’obtiens not_found. C’est cette valeur qui devient l’état du capteur dans Home Assistant. Le endpoint public GreyNoise renvoie bien ce champ de statut dans sa réponse JSON.

À côté de cela, j’ai plusieurs attributs utiles :

• ip : l’adresse IP publique détectée.
• classification : la classification éventuelle.
• noise : indique si l’IP est considérée comme faisant partie du bruit Internet.
• common_business_services : indique si l’IP est liée à des services d’entreprise connus.
• trust_level : un indicateur supplémentaire quand il est disponible.
• error : un message d’information, par exemple “ip not found”.

Mes cartes Lovelace

Une fois le capteur créé, je voulais surtout un affichage agréable dans le dashboard. Je me suis donc fait une petite page dédiée avec plusieurs cartes pour tester les rendus.

J’ai utilisé à la fois Mushroom, Button Card et une carte Markdown. Cela m’a permis de comparer un style plus “sobre”, un style plus “visuel”, et un style plus “informatif”.

Carte Mushroom

La première carte que j’ai faite est une carte Mushroom basée sur le capteur réel :

type: custom:mushroom-template-card
entity: sensor.greynoise_ip_check
primary: >
  {% set c = state_attr(entity, 'classification') %}
  {% if c == 'malicious' %}
    GreyNoise : activité malveillante
  {% elif c == 'suspicious' %}
    GreyNoise : activité suspecte
  {% elif c == 'benign' %}
    GreyNoise : service légitime
  {% elif states(entity) in ['not_found', 'unknown', 'unavailable'] %}
    GreyNoise : aucune activité connue
  {% else %}
    GreyNoise : {{ states(entity) }}
  {% endif %}
secondary: >
  {% set ip = state_attr(entity, 'ip') or 'IP inconnue' %}
  {% set classif = state_attr(entity, 'classification') or 'aucune' %}
  {% set noise = state_attr(entity, 'noise') %}
  {% set cbs = state_attr(entity, 'common_business_services') %}
  IP : {{ ip }} • Classification : {{ classif }} • Noise : {{ noise }} •
  Services connus : {{ cbs }}
icon: >
  {% set c = state_attr(entity, 'classification') %}
  {% if c == 'malicious' %}
    mdi:shield-alert
  {% elif c == 'suspicious' %}
    mdi:shield-search
  {% elif c == 'benign' %}
    mdi:shield-check
  {% else %}
    mdi:shield-check-outline
  {% endif %}
icon_color: >
  {% set c = state_attr(entity, 'classification') %}
  {% if c == 'malicious' %}
    red
  {% elif c == 'suspicious' %}
    orange
  {% elif c == 'benign' %}
    teal
  {% else %}
    green
  {% endif %}
multiline_secondary: true
fill_container: true
tap_action:
  action: more-info

J’aime beaucoup cette carte parce qu’elle est facile à lire. En un coup d’œil, je vois un message clair, une icône adaptée et une couleur cohérente.

Cartes fictives

Pour comparer les états visuellement, j’ai aussi créé quelques cartes purement fictives. Cela permet de voir à quoi ressembleraient les différents cas sans attendre qu’ils se produisent réellement.

type: vertical-stack
cards:
  - type: custom:mushroom-template-card
    primary: Fictif - malicious
    secondary: "IP : 45.67.89.10 • malicious • noise: true"
    icon: mdi:shield-alert
    icon_color: red
    multiline_secondary: true

  - type: custom:mushroom-template-card
    primary: Fictif - benign
    secondary: "IP : 1.1.1.1 • benign • noise: false"
    icon: mdi:shield-check
    icon_color: teal
    multiline_secondary: true

  - type: custom:mushroom-template-card
    primary: Fictif - not found
    secondary: "IP : 82.65.100.200 • not_found • noise: false"
    icon: mdi:shield-check-outline
    icon_color: green
    multiline_secondary: true

C’est tout bête, mais très utile quand on construit une interface : on peut choisir le style avant même d’avoir un cas réel.

Carte Button Card

Ensuite, j’ai voulu quelque chose de plus visuel, presque comme une carte d’alerte. J’ai donc utilisé Button Card.

type: custom:button-card
entity: sensor.greynoise_ip_check
name: |
  [[[
    const c = entity?.attributes?.classification;
    if (c === 'malicious') return 'GreyNoise - activité malveillante';
    if (c === 'suspicious') return 'GreyNoise - activité suspecte';
    if (c === 'benign') return 'GreyNoise - service légitime';
    return 'GreyNoise - aucune activité connue';
  ]]]
icon: |
  [[[
    const c = entity?.attributes?.classification;
    if (c === 'malicious') return 'mdi:shield-alert';
    if (c === 'suspicious') return 'mdi:shield-search';
    if (c === 'benign') return 'mdi:shield-check';
    return 'mdi:shield-check-outline';
  ]]]
show_state: true
state_display: |
  [[[
    return entity?.state || 'unknown';
  ]]]
label: |
  [[[
    const ip = entity?.attributes?.ip || 'IP inconnue';
    const c = entity?.attributes?.classification || 'aucune';
    const noise = entity?.attributes?.noise;
    const cbs = entity?.attributes?.common_business_services;
    return `IP ${ip} • ${c} • noise: ${noise} • common business: ${cbs}`;
  ]]]
show_label: true
tap_action:
  action: more-info
styles:
  card:
    - padding: 18px
    - border-radius: 20px
    - color: white
    - background: |
        [[[
          const c = entity?.attributes?.classification;
          if (c === 'malicious') return 'linear-gradient(135deg, #b71c1c 0%, #e53935 100%)';
          if (c === 'suspicious') return 'linear-gradient(135deg, #ef6c00 0%, #ffa726 100%)';
          if (c === 'benign') return 'linear-gradient(135deg, #00695c 0%, #26a69a 100%)';
          return 'linear-gradient(135deg, #2e7d32 0%, #66bb6a 100%)';
        ]]]
  grid:
    - grid-template-areas: "\"i n\" \"i s\" \"l l\""
    - grid-template-columns: 60px 1fr
    - grid-template-rows: min-content min-content min-content
  icon:
    - width: 42px
    - color: white
  name:
    - justify-self: start
    - font-size: 18px
    - font-weight: 700
  state:
    - justify-self: start
    - font-size: 15px
    - font-weight: 500
  label:
    - justify-self: center
    - text-align: center
    - width: 100%
    - font-size: 13px
    - opacity: 0.92

Cette carte est très sympa, surtout quand on veut quelque chose qui attire un peu plus l’œil. J’ai d’ailleurs ajusté la ligne du bas pour qu’elle soit centrée, ce qui améliore vraiment le rendu.

Carte Markdown récapitulative

Enfin, j’ai ajouté une carte Markdown pour afficher toutes les informations de manière lisible :

type: markdown
content: >-
  {% set e = 'sensor.greynoise_ip_check' %}

  ## Rapport complet GreyNoise

  - **État** : {{ states(e) }}

  - **IP** : {{ state_attr(e, 'ip') or 'inconnue' }}

  - **Classification** : {{ state_attr(e, 'classification') or 'aucune' }}

  - **Bruit Internet** : {{ state_attr(e, 'noise') }}

  - **Services connus** : {{ state_attr(e, 'common_business_services') }}

  - **Niveau de confiance** : {{ state_attr(e, 'trust_level') or '--' }}

  - **Message d'information** : {{ state_attr(e, 'error') or 'aucun' }}

  ---

  - **Dernière exécution de la requête** : {{
  relative_time(states[e].last_updated) }}

  - **Horodatage de la dernière exécution** : {{
  as_local(states[e].last_updated).strftime('%d/%m/%Y %H:%M:%S') }}

J’aime bien cette carte parce qu’elle est très claire, surtout pour du diagnostic.

En plus, j’y ai ajouté la notion de temps écoulé depuis la dernière mise à jour, ce qui est pratique pour savoir quand la requête a été réellement exécutée.

Les propriétés last_updated et last_changed sont bien disponibles dans le moteur de templates Home Assistant pour ce type d’usage.

Ce que j’ai retenu de cette intégration

Ce petit projet m’a rappelé quelque chose d’important : en domotique, le plus important n’est pas toujours la méthode théoriquement la plus élégante, mais celle qui fonctionne réellement chez soi de manière fiable.

Au départ, je voulais partir sur du REST. Finalement, c’est le capteur en ligne de commande qui m’a permis d’obtenir un résultat stable, lisible et facile à maintenir. Et franchement, pour un usage domestique, c’est exactement ce que je cherchais.

J’ai aussi réalisé que ce type d’intégration a une vraie valeur pédagogique. On apprend à récupérer du JSON, à créer un capteur Home Assistant, à exploiter des attributs, à mettre en forme un dashboard, et à transformer une information brute en quelque chose de visuel et compréhensible.

Au final, j’ai utilisé la Carte Mushroom dans un petit coin de mon dashboard, d’un coup d’oeil, je verrai si l’icone passe en rouge.

Si le coeur m’en dit, je pourrai ajouter le changement d’état de sensor.greynoise_ip_check dans les déclencheurs d’éventuelles notifications par SMS ou visuelles…

Conclusion

Avec GreyNoise, j’ai ajouté dans Home Assistant une petite brique de contexte réseau que je trouve vraiment intéressante. Ce n’est pas un outil miracle, ni un IDS complet, mais c’est un bon indicateur pour savoir comment mon IP publique est perçue depuis l’extérieur.

J’ai commencé par tester la page de vérification en ligne, puis la requête API en terminal, puis j’ai essayé l’intégration dans Home Assistant. Le capteur REST ne s’étant pas montré concluant dans mon cas, je suis parti sur command_line, et c’est finalement cette méthode qui a fait le job. L’approche décrite est cohérente avec les capacités documentées des intégrations REST et command_line de Home Assistant.

Au final, j’obtiens un capteur simple, quelques attributs utiles, et surtout des cartes Lovelace agréables à lire. Pour moi, c’est exactement le genre d’intégration que j’aime : un sujet un peu technique au départ, mais transformé en quelque chose de concret, visuel et accessible au quotidien.

Pour aller plus loin :

• • https://viz.greynoise.io/
  • https://check.labs.greynoise.io/
  • https://ougier.net/cyber-zombies-votre-routeur-est-il-un-soldat-pour-un-botnet/

J’ai eu quelques soucis de configurations de mes serveurs de messagerie.

Evidemment, pour faire simple, je mélange tout un tas de choses, un Tenant Microsoft, des noms de domaines chez OVH et des hébergements chez Ionos, à un moment, il y a bien un paramètre de configuration qui bloque.

J’ai découvert un site génial qui en quelques secondes vérifie tout pour moi et me dit si les paramètres DNS sont conformes, si les configurations SPF, KDIM, DMARC… sont au point.

Site utilisé

Ce site est mignon, simple et particulièrement puissant.

Principe de fonctionnement

Le site me donne une adresse mail et je fais un mail à cette adresse, tout simplement puis j’appuie sur « Vérifier votre score ».

Résultat

A ce stade, j’ai tout corrigé, les soucis de déclaration de SPF ou l’activation de DMARC.

J’ai au final, 10/10

Mais il me reste un point à améliorer :

Il s’agit de la correspondance entre l’enregistrement du pointeur DNS (Type PTR) et le HELO, le site détecte bien que HELO et rDNS ne sont pas identiques :

Cela semble pouvoir poser des problèmes, par exemple avec la messagerie AOL (il reste encore des dinosaures avec AOL ??) 

J’ai évidemment fait des recherches pour savoir si cela allait poser des soucis ou pas.

Voici la réponse de Microsoft à cette disconcordance entre HELO et rDNS :

• https://learn.microsoft.com/en-us/exchange/troubleshoot/antispam-and-protection/cannot-send-emails-to-external-recipients

Microsoft explique en quelques lignes qu’ils utilisent plusieurs serveurs pour envoyer des mails et que cela semble être le mode de fonctionnement des grandes plateformes, ils n’apportent aucune solution à part contacter le fournisseur de messagerie qui refuserait des mails sur lesquels HELO est différent de rDNS.

Bref, visiblement rien de choquant pour eux, je vais rester ainsi configuré donc.

Dans le contexte de formations aux utilisateurs informatiques, il est crucial de les sensibiliser aux risques liés à l’utilisation de clés USB inconnues.

Pour marquer les esprits, une démonstration pratique est souvent plus efficace qu’un simple discours. C’est pourquoi je souhaite programmer une clé USB capable de simuler des dommages sur un ordinateur, afin de montrer concrètement les dangers encourus.

Nota : A la demande de certains d’entre vous, je vous propose de réaliser pour vous la création de cette fausse clé, vous la trouverez donc toute prête, programmée et opérationnelle dans mon vide-grenier. Evidemment, elle n’est pas dangereuse !! Lisez la suite pour comprendre ce qu’elle fait.

Que sont des Rubber Ducky ?

Les Rubber Ducky sont des clés USB conçues pour simuler un clavier lorsqu’elles sont connectées à un ordinateur. Elles sont souvent utilisées par les pirates informatiques pour effectuer des attaques de type « keystroke injection » (injection de frappe), qui consistent à simuler des frappes de clavier pour exécuter des commandes malveillantes sur un ordinateur cible.

Les Rubber Ducky sont équipées d’un microcontrôleur programmable qui peut stocker des scripts préenregistrés. Lorsqu’elles sont connectées à un ordinateur, elles se comportent comme un clavier USB standard et peuvent envoyer des séquences de touches préenregistrées à une vitesse très élevée, ce qui permet d’exécuter des commandes complexes en quelques secondes seulement.

Les Rubber Ducky sont souvent utilisées pour des tests d’intrusion ou des démonstrations de sécurité informatique, mais elles peuvent également être utilisées à des fins malveillantes, comme le vol de données ou l’installation de logiciels malveillants. Il est donc important de sensibiliser les utilisateurs aux risques liés à l’utilisation de clés USB inconnues et de prendre des mesures de sécurité appropriées pour protéger les ordinateurs contre les attaques de type « keystroke injection ».

Comme expliqué dans le paragraphe précédent, mon objectif est de sensibiliser les utilisateurs d’outils informatiques et leur démontrant la dangerosité d’insérer une clé USB inconnue dans leur ordinateur.

Pourquoi je parle de fausse Rubber Ducky ?

Les Rubber Ducky sont hors de prix et je cherche une solution abordable pour que le plus grand nombre puisse acheter une clé de sensibilisation. Personne ne mettre ces prix :

Quel équipement ai-je choisi ?

Je vais utiliser un équipement beaucoup plus léger car il n’a que 6k de mémoire, mais cela est suffisant, je ne vais pas lancer de script complexe. C’est un Digispark ATTINY85.

Cet équipement est abordable et fonctionnel.

Sa configuration est un peu complexe, il faut utiliser des drivers qui sont détectés comme dangereux, j’ai documenté sa programmation sur un RetEx il y a quelques temps.

Que va faire cette clé quand on la connecte ?

Le principe de cette fausse clé USB c’est d’exécuter un script au moment où on l’insère.

Evidemment les pirates vont installer un programme malveillant ou vont exfiltrer des données et les envoyer par internet. Ce n’est pas ce que je vais faire, je veux quelque chose de graphique et visuel qui symbolise une intrusion, un piratage en cours et des messages à l’écran.

C’est réellement à cette étape qu’il a fallu que je choisisse quelle actions « classiques » allaient être assez spectaculaires pour faire flipper un utilisateur.

Voici ce que j’ai choisi, cette vidéo illustre ce qu’il se passe quand on insère la clé (plus du son qui ne s’entend pas sur cette capture d’écran) :

J’ai réalisé quelques clés, elles sont à votre disposition

Evidemment, rien de commercial dans tout cela. Dans un but pédagogique, je vous invite à réaliser la démonstration auprès de vos enfants, parents, amis, collègues. Après la démonstration, ils n’insèreront plus une clé inconnue dans leur ordinateur.

J’ai fait réaliser par une société qui fait de l’impression 3D un petit boitier pour insérer le Digispark, le protéger et lui donner l’aspect d’une clé USB. Je suis très fier du résultat :

Au bout de la clé, il y a un trou pour l’ajouter à un trousseau de clés par exemple et sur l’autre côté, il y a deux trous qui permettent de laisser passer la lumière de la LED verte et de la LED rouge.

Le Digispark coûte entre 4 et 5€, l’impression 3D, hors frais de contrôle coute entre 1 et 2€ les deux éléments. Une enveloppe papier bulles (0.20€) et un timbre à 1.29€.

Pour ceux qui me l’ont demandé, je peux arriver donc à faire un lot clé USB programmée + envoi payé à 8.50€.

J’en ai réalisé 5, j’en garde 1 donc si vous en voulez une, contactez moi.

Je les place dans le vide grenier, je suis joignable avec le pseudo Sigalou sur HACF, Jeedom community, Discord, mon mail est donné dans le premier paragraphe du vide grenier.

Mon objectif

Dans le contexte de formations aux utilisateurs informatiques, il est crucial de les sensibiliser aux risques liés à l’utilisation de clés USB inconnues.

Pour marquer les esprits, une démonstration pratique est souvent plus efficace qu’un simple discours. C’est pourquoi je souhaite me procurer une clé USB capable de simuler des dommages sur un ordinateur, afin de montrer concrètement les dangers encourus.

Les Rubber Ducky sont des clés USB utilisées par les pirates informatiques, mais leur coût est souvent prohibitif. Je cherche donc une solution plus économique pour créer cet outil de sensibilisation.

En somme, je souhaite trouver une alternative abordable aux Rubber Ducky pour sensibiliser les utilisateurs aux risques liés à l’utilisation de clés USB inconnues, en utilisant une clé USB capable de simuler des dommages sur un ordinateur.

Que sont des Rubber Ducky ?

Les Rubber Ducky sont des clés USB conçues pour simuler un clavier lorsqu’elles sont connectées à un ordinateur. Elles sont souvent utilisées par les pirates informatiques pour effectuer des attaques de type « keystroke injection » (injection de frappe), qui consistent à simuler des frappes de clavier pour exécuter des commandes malveillantes sur un ordinateur cible.

Les Rubber Ducky sont équipées d’un microcontrôleur programmable qui peut stocker des scripts préenregistrés. Lorsqu’elles sont connectées à un ordinateur, elles se comportent comme un clavier USB standard et peuvent envoyer des séquences de touches préenregistrées à une vitesse très élevée, ce qui permet d’exécuter des commandes complexes en quelques secondes seulement.

Les Rubber Ducky sont souvent utilisées pour des tests d’intrusion ou des démonstrations de sécurité informatique, mais elles peuvent également être utilisées à des fins malveillantes, comme le vol de données ou l’installation de logiciels malveillants. Il est donc important de sensibiliser les utilisateurs aux risques liés à l’utilisation de clés USB inconnues et de prendre des mesures de sécurité appropriées pour protéger les ordinateurs contre les attaques de type « keystroke injection ».

Comme expliqué dans le paragraphe précédent, mon objectif est de sensibiliser les utilisateurs d’outils informatiques et leur démontrant la dangerosité d’insérer une clé USB inconnue dans leur ordinateur.

Voici le prix des Rubber Ducky, d’où mon souhait de trouver une solution autre, le prix est éliminatoire pour l’utilité que je vais en avoir.

Je vais utiliser une Digispark Rev. 3 équipé d’une ATTINY85

Je vais utiliser un équipement beaucoup plus léger car il n’a que 6k de mémoire, mais cela est suffisant, je ne vais pas lancer de script complexe.

Cet équipement vaut entre 5 et 7 euros.

Vous pouvez le commander chez les chinois directement en priant que vous aurez la bonne version ou chez Amazon en lot de 3.

Les connecteurs ne me seront pas utiles, je ne vais pas le flasher.

Contraintes de la Digispark ATTINY85

Si on compare une Rubber Ducky et une Digispark, on se rend compte que la première et principale limite se situe au niveau de la capacité de stockage des scripts utilisables.

Le microcontrôleur ATtiny85 dispose de 8 ko de mémoire flash, mais une partie de cette mémoire est utilisée pour stocker le bootloader et le code du programme d’application. En général, la quantité de mémoire disponible pour le stockage de données sur une clé Digispark ATtiny85 est d’environ 6 ko. Pour mon utilisation, cela est suffisant.

Les clés Rubber Ducky disposent de fonctionnalités avancées telles que la possibilité de simuler des périphériques USB autres qu’un clavier, comme une souris ou un disque dur externe. Les clés Digispark ATtiny85 sont plus limitées dans ce domaine et ne peuvent généralement simuler qu’un clavier USB. Cela me convient également.

Je télécharge les pilotes de la Digispark

Je vais procéder à l’installation des pilotes de la Digispark sur mon ordinateur personnel. Bien que cela puisse sembler être une tâche complexe et délicate, il est important de noter que cette manipulation ne doit être effectuée que sur mon propre ordinateur et non sur les ordinateurs ciblés par la simulation de dommages. En effet, une fois la Digispark branchée sur un ordinateur, elle sera reconnue comme un clavier.

Je charge donc les fichiers nécessaires à l’installation des drivers :

• https://github.com/digistump/DigistumpArduino/releases/download/1.6.7/Digistump.Drivers.zip

Une fois téléchargé et décompresser, c’est le fichier qui permettra d’installer les drivers.

Ce driver n’étant pas signé, normalement Windows va bloquer sont installation, il faut donc désactiver temporairement la signature obligatoire des pilotes.

Je désactive la signature obligatoire des pilotes

Je vais désactiver temporairement la signature obligatoire des pilotes sur mon ordinateur. Cette opération ne présente aucun risque et sera automatiquement annulée au prochain redémarrage de l’ordinateur. Cette étape est nécessaire pour permettre l’installation des pilotes de la Digispark, qui n’ont pas été signés numériquement par un éditeur de confiance.

Je vais dans Paramètres puis Récupération pour appuyer sur le bouton Redémarrage maintenant

Puis au redémarrage, choisir Dépannage

puis Options avancées puis Paramètres

Le PC redémarrage et au redémarrage, voici les choix :

Je veux l’option 7 donc j’appuie sur F7.

J’installe les pilotes de la Digispark

Je peux maintenant lancer le fichier Install Drivers.exe

J’installe l’IDE d’Arduino

L’IDE (Integrated Development Environment) d’Arduino est un logiciel open-source qui permet de programmer les cartes Arduino et d’autres cartes compatibles. C’est lui qui va me permettre de saisir le code du script que je souhaite exécuter et le téléverser ensuite dans la clé Digispark.

• https://www.arduino.cc/en/software

Rien de bien compliqué, tout s’installe tout seul.

J’intègre le pack Digispark à l’IDE

Pour piloter la carte Digispark, il est nécessaire d’utiliser le pack Digispark.

Je lance IDE Arduino, puis Fichier puis Préférences.

Je dois compléter l’URL de gestionnaire de cartes supplémentaires

Dans tous les tutos et autres doc que vous trouverez sur internet, il est spécifié ce lien :

• http://digistump.com/package_digistump_index.json

Mais au jour de mes essais, ce lien ne fonctionnait pas, le site digistump étant HS.

Voici le lien que j’ai utilisé :

• https://raw.githubusercontent.com/digistump/arduino-boards-index/master/package_digistump_index.json

Dans Outils, Cartes, Gestionnaire de cartes, taper digistrump puis cliquer sur Installer de Digistump AVR Boards

Puis retourner sélectionner le carte Default dans Outils, Carte, Digistump AVR Boards, puis Digisdpark Default 16.5mhz.

J’installe le clavier QWERTY

Pour ne pas me faire piéger sur l’écriture des commandes à envoyer, j’installe un clavier américain en QWERTY. Ainsi quand je saisirai des commandes à exécuter ou à afficher, je basculerai le clavier en ENG.

Je saisis mon code/script

Voici mon script :

#include <DigiKeyboard.h>

void setup() {
    //pinMode(1, OUTPUT); // LED brille plus si déclarée en output
    digitalWrite(1, HIGH); // Allume la LED rouge (pour signaler que l'execution est en cours)
    DigiKeyboard.delay(3000); // Attendre 3 secondes

    DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Ouvrir une fenêtre d'exécution Windows
    DigiKeyboard.delay(500); 
    DigiKeyboard.print("c;d"); // Écrire "cmd"
    DigiKeyboard.delay(500); 
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"

    DigiKeyboard.delay(500); 
    DigiKeyboard.print("curl 6o ;usic<;p# https.>>uploqdsong<netlify<qpp>;usic<;p#"); // Écrire "curl -o music.mp3 https://uploadsong.netlify.app/music.mp3"
    DigiKeyboard.delay(500); 
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"


    DigiKeyboard.delay(500); 
    DigiKeyboard.print("ipconfig >qll"); // Écrire "ipconfig /all"
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"
    DigiKeyboard.delay(500); 
    DigiKeyboard.print("exit"); // Écrire "exit"
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"

    DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Ouvrir une fenêtre d'exécution Windows
    DigiKeyboard.delay(500); 
    DigiKeyboard.print(";usic<;p#"); // Écrire "music.mp3"
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"
    DigiKeyboard.delay(1000); 

    int color = 1;
    while (color < 5) {
        DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Ouvrir une fenêtre d'exécution Windows
        DigiKeyboard.delay(500); 
        DigiKeyboard.print("c;d"); // Écrire "cmd"
        DigiKeyboard.delay(500); 
        DigiKeyboard.sendKeyStroke(KEY_ENTER);
        DigiKeyboard.delay(1000); 
        switch (color) {
        case 0:
          DigiKeyboard.print("echo off1color )1cls1tree");// Écrire "echo off&color 0&cls&tree"
          break;
        case 1:
          DigiKeyboard.print("echo off1color !1cls1trqcert *<*<*<*"); // Écrire "echo off&color 1&cls&tracert 8.8.8.8"
          break;
        case 2:
          DigiKeyboard.print("echo off1color @1cls1PING google<fr 6n !))");// Écrire "echo off&color 2&cls&ping google.fr -n 100"
          break;
        case 3:
          DigiKeyboard.print("echo off1color #1cls1tree");// Écrire "echo off&color 3&cls&tree"
          break;
        case 4:
          DigiKeyboard.print("echo off1color $1cls1trqcert *<*<*<*");// Écrire "echo off&color 4&cls&tracert 8.8.8.8"
          break;
        }
        DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"
        DigiKeyboard.delay(500); 
        color++;
    }

    DigiKeyboard.delay(1000); 
    DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Ouvrir une fenêtre d'exécution Windows
    DigiKeyboard.delay(500); 
    DigiKeyboard.print("notepqd"); // Écrire "notepad"
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"
    DigiKeyboard.delay(1000); 
    DigiKeyboard.sendKeyStroke(KEY_ENTER);
    DigiKeyboard.print("   Coucou // Ordinqteur pirqt2< Do;;qge "); 
    DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"  
    while (color < 15)
    {
        DigiKeyboard.sendKeyStroke(KEY_ENTER); // Simuler l'appui de la touche "ENTRÉE"  
        DigiKeyboard.print("   Exfiltrqtion des donn2es en cours<<< "); 
        delay(300);
        color++;
    }
    digitalWrite(1, LOW); // Eteindre la Led Rouge
}

void loop() {
}

Je l’ai commenté au maximum.

Je le téléverse dans la clé Digispark

Je ne branche pas la clé, je lance la compilation ainsi que le téléversement avec le bouton avec la flèche vers la droite :

Quand la console affiche plug in device now, je peux insérer la clé Digispark

Le téléversement est extra rapide, soit j’arrive à retirer la clé avant que le script se lance soit je bénéficie du premier lancement du script de la clé…

C’est terminé, la clé est prête.

Ainsi, pour simuler une attaque par injection de frappe, il suffit de glisser la clé dans un port USB.

Bibliographie pour aller plus loin

• https://www.malekal.com/desactiver-signature-numerique-pilotes-windows-10/
• https://www.qqt.fr/documentation/systeme-dexploitation/desactivation-de-la-signature-obligatoire-des-pilotes-sous-windows-8/
• https://www.youtube.com/watch?v=R41pn1j81RU
• https://remiflandrois.fr/2021/08/09/usb-digispark-rubber-ducky/
• https://github.com/CedArctic/DigiSpark-Scripts
• https://redacted.au/creating-a-usb-rubber-ducky-from-a-digispark-attiny-85/

Mon constat

J’ai été contacté plusieurs fois sur mon téléphone portable pour des démarchages professionnels, alors que mes appels sont habituellement filtrés par mon secrétariat et que peu de personnes ont mon numéro de portable professionnel.

Je trouve cela étrange et répétitif. Un soir, vers 18h45, journée terminée mais encore au bureau, je reçois un appel sur mon portable. Le numéro est affiché mais inconnu pour moi. Je décide de répondre et entame une conversation avec l’interlocuteur, qui cherche à me vendre des solutions logicielles dont je n’avais aucun besoin. Il le comprend rapidement, mais avec une sympathie dans la voix, nous plaisantons ensemble un moment. Curieux, je saisis l’occasion pour lui demander comment il a obtenu mon numéro de portable.

Il m’explique qu’il est abonné à une plateforme appelée Kaspr, laquelle fournit un outil en complément au navigateur. Cet outil lui permet d’obtenir l’adresse e-mail et le numéro de téléphone du profil LinkedIn qu’il est en train de consulter.

Je pense d’abord à Casper, mon ami d’enfance, mais ce n’est pas lui ; l’orthographe n’est pas la même.

Je ne connaissais pas Kaspr et je fonce sur leur site pour voir s’il s’est moqué de moi ou pas.

Je tape Kaspr dans Google et voici le résultat :

Donc, il ne m’a pas menti, ce logiciel fournit bien les adresses e-mail et les numéros de téléphone des profils LinkedIn ?! Mais comment est-ce possible ?!

J’avais évidemment la conviction d’avoir correctement sécurisé mon profil ; toutes les options de partage sont désactivées et je n’ai jamais autorisé la diffusion de mon adresse e-mail ou de mon numéro de téléphone professionnel. Je suis un peu contrarié, mais je continue l’exploration.

La promesse est bien là, expliquée sur leur site, les numéros et mails sont bien affichés, dans une petite fenêtre d’un complément au navigateur quand on consulte un profil LinkedIn.

Moi qui n’est pas encore décoléré, je regarde les gros titres des témoignages d’utilisateurs qui se tapent sur le ventre :

Je lis aussi :

Je ne sais pas si cela a le don de m’inquiéter ou de me rassurer, je suis un parmi 500 millions ! ?

Je cherche à savoir ce que sont ces 150 sources ? Après tout, LinkedIn est peut-être le support de la consultation, comment savoir d’où viennent les informations ? LinkedIn ou pas ??

Je cherche, je cherche, c’est bien caché, je trouve ceci :

Je ne peux donc pas déterminer si mes données proviennent directement de LinkedIn ou si un fournisseur « premium » a revendu mes informations.

La véritable force de Kaspr réside dans sa capacité à établir un lien entre mon nom, mon prénom, mon profil LinkedIn et d’autres données qu’ils ont récupérées ailleurs.

Mon article ne porte aucun jugement sur qui que ce soit. Il offrira autant de visibilité à Kaspr pour certains qu’il sensibilisera à la sécurité des données pour d’autres.

Puis-je demander la suppression des informations me concernant ?

Je cherche, je cherche, tout bascule en anglais, les pages dont je parle à partir d’ici sont en anglais.

Dans un coin du site, une option « Opt-Out » et je trouve ce formulaire :

Mais je ne vais pas demander à suppression à ce stade, j’aimerais essayer de comprendre d’où viennent mes données et à qui elles ont été données. (conformément au RGPD)

Puis-je savoir où sont stockées les données me concernant ?

Je fouille leur site, et je trouve :

Je trouve que c’est plutôt pas mal, après, à partir du moment où ils ont mes données, elles vont transiter entre la France et les USA, probablement qu’elles sont même répliquées, je n’en sais trop rien.

Puis-je savoir quelles données le site Kaspr a en sa possession ?

En ligne, impossible de savoir, j’ai passé toutes les pages en revue. La liste de mes droits est bien listée mais pour en savoir plus, je dois les contacter, ce que je vais faire.

Je contacte Kaspr

Je suis la procédure décrite, je les contacte à l’adresse privacy@kaspr.io et leur demande de me transmettre toutes les informations qu’ils détiennent à mon sujet, ainsi que l’utilisation qu’ils ont faite de ces données.

Réponse de Kaspr

A partir de là, tout va se faire en anglais, pas de support francophone.

Kaspr me répond 15 jours calendaire après ma demande et me transmets deux mails :

• Un mail avec un fichier excel contenant mes données, protégé par un mot de passe
• Un second mail avec le mot de passe.

Je trouve que c’est assez gadget mais pourquoi pas.

Je m’empresse d’ouvrir le fichier Excel (avec le fameux mot de passe) et je trouve… mes données LinkedIn.

L’histoire ne dit pas d’où viennent les données, c’est le fichier de synthèse des informations qu’ils ont sur moi :

• First Name
• Last Name
• Linkedin_Url
• Data shared with
• Headline
• Company
• Location
• Email-1
• Phone-1
• Job_Title-1
• Job_CompanyName-1
• Job_Location-1
• Job_Title-2
• Job_CompanyName-2
• Job_Location-2
• Job_Title-3
• Job_CompanyName-3
• Job_Location-3
• Job_Title-4
• Job_CompanyName-4
• Job_Location-4
• Job_Title-…
• Job_CompanyName-…
• Job_Location-…

Chacun des emplois est soigneusement repris sur 3 enregistrements (colonnes)

Ce qui est intéressant et auquel je n’avais pas trop mis d’espoir, c’est d’obtenir la colonne

• Data shared with

En effet, dans cette colonne, j’ai la liste des mails à qui mes coordonnées ont été « vendues ».

Je suis bon pour écrire à tous les mails pour faire valoir mon droit à suppression et à opposition de transmission de mes données. La liste se termine par « Cognism.com », ce n’est pas une adresse mail, c’est un site.

Et voilà, Cognism est le petit frère de Kaspr, je vais devoir les contacter également.

J’ai contacté Cognism, ils sont très réactifs, ils m’ont confirmé qu’ils détenaient les données via Kasper et me confirment la suppression de celles-ci.

Revenons à la réponse de Kasper à ma demande de provenance des données :

Kaspr me répond : « As you can see from the attached, we collect limited business data such as full name, company name and job title from publicly available online sources. You can find more information about Kaspr at the following link: https://kaspr.io/ ». Cela est inexact puisque dans le fichier reçu il y a mon mail et mon numéro de portable professionnel.

Je ne saurais donc pas où mes informations ont été récupérées.

Je demande la suppression de mes informations personnelles

Dans leur message, ils me proposent de demander moi même la suppression via leur formulaire soit par mail, tête de pioche, je leur demande d’effectuer la suppression et de m’en tenir informé.

J+12: J’ai reçu une réponse « We can confirm that your details will be removed from our database within the next 3-7 business days. »

En attendant, je vais sur mon LinkedIn tout vérifier

Je dédie un mail à LinkedIn et je change de mail

Je me fais un petit linkedin@monnomdedomaine.xx et je vais changer le mail. Ce nouveau mail est redirigé vers mon mail habituel, si ce mail réapparait un jour dans une base, je saurai que c’est LinkedIn le fautif. A ce stade, je n’en sais rien, ce peut être un recoupement de plusieurs bases de données.

Je supprime mon numéro de téléphone

Après une multitude de messages m’expliquant que l’on me demande mon numéro par sécurité, que c’est une bonne chose d’en avoir un et que je ne devrais pas le supprimer, après avoir retapé mon mot de passe, récupéré un code sur le mail, j’arrive enfin à supprimer mon numéro de téléphone !!

J’ajoute une identification en deux étapes

Cela ne coute rien, j’en profite, c’est un peu hors sujet, mais autant l’avoir pour sécuriser mon compte.

Qui peut voir mon adresse mail ?

Dans visibilité : 

Je parcours tous les paramètres de configuration

Je n’ai rien relevé de particulier, j’ai parfois activé, parfois désactivé les options de LinkedIn, chacun configure comme il le souhaite en fait.

Ma conclusion

Comme toujours, chacun est responsable de ses propres données et de leur utilisation, et doit en assumer les conséquences.

Concernant LinkedIn, en dehors des incidents passés de fuites de données, rien n’indique qu’ils vendent nos informations. Le rachat de LinkedIn par Microsoft inspire l’espoir d’une meilleure gestion et sécurité, supervisée par leurs meilleurs experts en sécurité.

Il est toujours judicieux de revoir régulièrement les paramètres de confidentialité sur des plateformes comme LinkedIn, où nos données sont stockées. Ces options ne sont pas toujours évidentes, mais elles permettent de limiter la diffusion de nos informations personnelles.

Quant à des entreprises comme Kasper, Waalaxy ou Cognism, leur activité est légale et elles ont le droit de fonctionner. Il est raisonnable de supposer qu’elles sont vigilantes lors de l’acquisition de bases de données, et nous espérons qu’elles ne collectent que des données légitimes et respectent les droits des individus concernés.

Pour éviter d’utiliser un port « standard », donc par sécurité, je voudrais changer le port de Home Assistant.

Par défaut, c’est le port 8123 qui est utilisé. Pour ce RetEx, je vais choisir 8888 comme exemple mais j’ai évidemment utilisé un autre chez moi.

Je modifie le fichier configuration.yaml

De manière très classique, je vais modifier le fichier configuration.yaml, j’ajoute ces deux lignes :

http:
  server_port: 8888

Je relance Home Assistant

Je me connecte avec la nouvelle adresse

Pour me connecter à Home Assistant, je n’utilise plus http://homeassistant.local:8321 mais  :

• http://homeassistant.local:8888

Je teste l’accès externe avec Nabu Casa

Aucun souci, Nabu Casa fonctionne parfaitement, le lien externe vers mon Ha est ok 

Bibliographie

• https://www.wundertech.net/how-to-access-home-assistant-remotely/
• https://rapidlydigital.com/change-default-port-number-in-home-assistant/

Pour vérifier cela, le plus simple, c’est un ping de l’adresse IP.

J’ai une IP fixe Free et je suis une victime potentielle si je me fais repérer. Cela en fonction également des redirections de ports que je vais définir sur mon routeur (si je veux consulter mes caméras ip depuis l’extérieur, accéder à Home Assistant, Jeedom, si j’héberge mon site internet, …)

Je vérifie si mon IP ping depuis l’extérieur

Pour cela, très simple, il suffit d’un site qui fasse un ping, j’ai l’habitude d’utiliser celui-ci, archi-simple :

• https://ping.eu/ping/

Mon IP est inscrite en bleu en haut au milieu, je la recopie dans la case IP adresse, je recopie le code et je clique sur Go.

C’est parfait, 100% des paquets perdus, c’est que le ping n’a pas fonctionné, c’était mon objectif.

Qu’aurais-je dû changer si le ping avait fonctionné ?

C’est la question qui m’a été posée à la suite de ce retour d’expérience.

J’ai une Freebox Révolution Fibre, j’ai donc fait ce RetEx suite à des tests dessus, pour les autres boxs, cf. documentation ou support clients de celles-ci.

Ma Freebox est elle en routeur ou en bridge ?

• La Freebox est en routeur

C’est donc elle qui va répondre au ping.

Le site Free-reseau donne des conseils pour activer le ping sur une Freebox V4 ou V5 ou sur une Freebox Revolution. Il faut donc faire l’inverse de ce qui est expliqué pour désactiver le ping.

Je ne sais pas s’il reste encore des V4 ou V5, mais sur Révolution, il suffit de décocher la case :

• La Freebox est en bridge

C’est ce que j’ai chez moi, la Freebox fait ce qu’elle fait de mieux : être un modem. J’ai confié la gestion de mes équipements à un Routeur Synology. La Freebox fait le lien entre le réseau fibre et mon routeur. Le mode bridge va la transformer, comme son nom l’indique en pont. Elle fera le pont entre internet et mon syno qui alloue les adresses aux éléments de mon réseau.

Dans ce cas, la réponse au ping sera traitée par le routeur, c’est dans sa configuration qu’il faut fouiller.

Bibliographie

• https://www.free-reseau.fr/ma-ligne/_informations.php
• http://hjj.free.fr/FBV6/page130.html
• https://www.grc.com/x/ne.dll?bh0bkyd2
• https://assiste.com/Encyclopedie/Shields_Up.html
• https://apical.xyz/fiches/home_assistant/trouver_l_adresse_ip_de_home_assistant

Afin de sensibilisé les utilisateurs du tenant Microsoft 365 que j’utilise, j’ai cherché comment créer une campagne de Phishing (hameçonnage) pour les « piéger » et déclencher une formation sur ce sujet.

Les messages de prévention et les campagnes d’hygiène numérique ne suffisent pas, il faut un fait concret pour tenter de déclencher une prise de conscience.

Disclaimer

Au risque de me répéter, mon objectif n’est pas de lancer de campagne de publipostage ni de phishing, c’est bien à visée pédagogique.

A noter que les éléments expliqués ci-dessous ne fonctionneront pas si vous n’êtes pas administrateur du Tenant à attaquer puisqu’il faut autoriser l’IP de GoPhish, sans cette autorisation, la campagne de phishing est bloqué par les systèmes de sécurité de Microsoft (Merci !!)

Outils utilisés

• Evidemment, j’utilise le Tenant Microsoft 365 à qui je vais demander d’autoriser l’IP d’envoi de ma campagne ainsi que le fameux 5321.MailFrom (ou expéditeur d’enveloppe).

• GoPhish dans sa version 0.12.1 au jour d’écriture de ce RetEx

• La plateforme AWS d’Amazon et plus spécifiquement les instances EC2

Je crée un compte Amazon AWS 

• https://portal.aws.amazon.com/billing/signup#/start/email

Passer les 5 étapes puis :

Je crée une instance sur EC2

Tout ce que j’explique sur cette partie est totalement gratuite, on peut bénéficier de l’offre 1 an, cela est suffisant pour mon besoin.

Il faut avoir créé un compte sur AWS puis aller sur Amazon EC2

En haut à droite, vérifier qu’on soit bien sur la Région de Europe/Paris

puis

Je télécharge le fichier de clé, attention de bien prendre un fichier ppk et non pem.

Une fois tout installé et lancé, j’ai tout au vert :

Je configure le groupe de sécurité de mon instance

Par mesure de sécurité, j’ai déjà réservé l’accès SSH à ma seule adresse IP via l’assistant de création de l’instance, il faut maintenant que je configure les ports devant être utilisés par GoPhish.

Je vais dans Réseau et sécurité puis Groupes de sécurité, je sélectionne le groupe launch-wizard, règles entrantes, modifier les règles entrantes

J’ajoute une entrée TCP personnalisé avec un numéro de port autre que 3333 qui sera le numéro de port que j’utiliserai pour GoPhish, je mets 8531 par exemple.

J’utilise une Adresse IP Elastic (facultatif)

Pour avoir toujours la même adresse IP, j’utilise cette fonctionnalité.

Attention, les adresses IP élastiques sont payantes lorsqu’elles ne sont pas associées à une instance en cours d’exécution. Cela signifie que si vous réservez une adresse IP élastique mais ne l’utilisez pas, vous serez facturé. Cependant, une fois qu’une adresse IP élastique est associée à une instance en cours d’exécution, vous ne serez pas facturé tant que l’instance est en cours d’exécution et que l’adresse IP est associée à cette instance. Si l’instance est arrêtée ou terminée, vous pouvez toujours être facturé pour l’utilisation de l’adresse IP élastique, à moins que vous ne la dissociiez de l’instance ou que vous la libériez.

J’installe Putty 

Putty va me permettre de me connecter en SSH à mon instance EC2, cela de manière sécurisé avec un jeu de clé (privée/publique).

Il me faut récupérer les paramètres de connexion sur l’instance.

Pour cela, je fais un clic droit sur l’instance, puis « se connecter » / Client SSH.

Je note le DNS public qui m’est donné, il me servira pour le host de Putty

Je lance Putty, j’ajoute le Host :

puis je spécifie le fichier de clé privé créé plus haut :

Pour que ce soit plus simple, j’ajoute le user ubuntu comme Auto-login dans Connection/Data

Je lance la connexion, c’est bon, j’ai la ligne de commande d’Ubuntu.

J’installe GoPhish

Je vais chercher la dernière version qui doit être téléchargée sur le dépôt Github officiel.

Au jour de création de ce RetEx, la dernière version est ici :
https://github.com/gophish/gophish/releases/download/v0.12.1/gophish-v0.12.1-linux-64bit.zip

Sur la ligne de commande d’Ubuntu, je charge le fichier zip et je le décompresse dans opt/ :

wget https://github.com/gophish/gophish/releases/download/v0.12.1/gophish-v0.12.1-linux-64bit.zip
sudo apt install unzip
unzip gophish-v0.12.1-linux-64bit.zip -d ./gophish
rm gophish-v0.12.1-linux-64bit.zip
sudo chmod +x ./gophish/gophish

Je vais devoir configurer l’IP de gophish et son port.
Pour cela, je modifie le fichier config.json

cd gophish
vim config.json

Je remplace 127.0.0.1:3333 par 0.0.0.0:8531 sur la ligne listen_url

Je lance gophish

./gophish

J’obtiens un message d’erreur, probablement une sécurité sur l’écoute du port 80 par un utilisateur non root, j’ai rapidement essayé de corriger cela avec ipfw mais il n’est pas sur ma machine et avec iptables, je n’ai rien eu de plus satisfaisant. C’est plutôt moche et non conseillé, mais comme mon instance Ec2 ne restera pas en prod, je lance un :

sudo ./gophish

C’est bon, mon GoPhish est lancé 

dans le texte de la ligne de commande, je récupère le mot de passe qui m’est donné sur la ligne

Please login with the username admin and the password xxx

Je souhaite utiliser Gophish sans garder ma fenêtre SSH ouverte (facultatif)

J’ajoute ce paragraphe ici pour plus de cohérence mais il peut être exécuté plus tard quand Gophish fonctionnera manuellement.

J’autorise le lancement de Gophish sans être root (sudo)

Pour éviter d’avoir à utiliser une commande sudo pour lancer Gophish, je vais autoriser l’utilisateur ubuntu à interagir sur le port 80 qui est un port privilégié. En effet la commande cap_net_bind_service permet à cet exécutable (gophish) de lier des sockets réseau à des ports dont le numéro est inférieur ou égal à 1024, même s’il n’est pas exécuté en tant qu’utilisateur root.

sudo setcap 'cap_net_bind_service=+ep'  /home/ubuntu/gophish/gophish

Ainsi, à partir de maintenant, inutile de taper sudo pour lancer gophish, la commande peut être :

./gophish

Message d’erreur open gophish_admin.key: permission denied

Si ce message d’erreur apparait, il faut modifier les permissions du fichier gophish_admin.key

Voici les commandes :

cd ~/gophish
ls -l gophish_admin.key
sudo chmod 644 gophish_admin.key
sudo chown ubuntu:ubuntu gophish_admin.key
ls -l gophish_admin.key
./gophish

Je déclare gophish comme un service

Je vais ajouter un fichier gophish.service dans /etc/systemd/system/gophish.service

[Unit]
Description=GoPhish Service
After=network.target

[Service]
ExecStart=/home/ubuntu/gophish/gophish
Type=simple
PIDFile=/var/run/gophish
User=ubuntu
WorkingDirectory=/home/ubuntu/gophish

[Install]
WantedBy=default.target

Pour ne pas avoir à tout taper, j’ai mis cela sur un gist, pour le récupérer directement :

sudo wget https://gist.githubusercontent.com/sigalou/267349eada979e07c99dc5944253169c/raw/e5d8769bb86b40e15ad0c4631629d575e440199a/gophish.service -O /etc/systemd/system/gophish.service

Cela peut être testé par :

sudo systemctl daemon-reload
sudo systemctl enable gophish
sudo systemctl start gophish
sudo systemctl status gophish

Je relance mon instance, c’est bon, Gophish se lance automatiquement.

Je lance GoPhish

De retour dans mon navigateur, je relève l’ip élastique ou ip public de l’instance, je colle cette adresse suivi de :8531 qui est le port définit plus haut

Je vais donc par exemple sur https://13.36.81.72:8531

Ici on utilise donc « admin » et le mot de passe relevé en ligne de commande au moment du lancement. Immédiatement GoPhish demande de changer le mot de passe et on est ainsi connecté sur GoPhish.

J’ajoute un utilisateur « piégeur » sur le Tenant 365

En me connectant en administrateur ayant les droit de gérer les utilisateurs, j’ajoute un nouvel utilisateur.

J’ai choisi d’utiliser un utilisateur que je maquille comme si c’était un compte officiel de microsoft de gestion des comptes.

Je lui ai même mis un joli logo qui fait sérieux.

Evidemment, je lui affecte une licence qui permet d’avoir un compte mail puis je vais dans l’onglet Courrier de cet utilisateur puis logiciels de courrier et je vais cocher au minimum la case SMTP authentifié.

(Facultatif) Pour me simplifier la vie et ne pas à avoir à ajouter cette boite au lettre, j’ai mis un transfert de tous les mails reçus sur cette boite vers mon adresse mail dans Courrier/Transfert des courriers.

Je configure Microsoft Defender pour autoriser GoPhish

Microsoft a tout prévu. Ils ont pensé à proposé sur une licence payante une campagne de phishing pédagogique (licence Defender Plan 2) mais ils ont aussi pensé aux bidouilleurs désargentés en permettant de manuellement autoriser cela.

Je lance Microsoft Defender.

Puis Stratégies et règles

Puis Stratégies de menace / Remise avancée

Et enfin Onglet Simulation d’hameçonnage

Merci Sigalou !!! Il fallait le trouver cet onglet 

Ensuite, il faut configurer le domaine et l’IP.

Le Domaine est l’adresse du domaine qui va envoyer le mail, cela correspond au domaine du SMTP From que je vais spécifier dans GoPhish.

L’IP est l’IP élastique ou public de l’instance.

Je configure le SMTP de GoPhish

De retour dans GoPhish, je vais dans Sending Profiles et je vais créer un profil d’envoi des messages :

Grace au bouton Send Test Email, je peux vérifier que tout fonctionne parfaitement, je reçois un message

A ce stade, c’est déjà une très belle victoire personnelle, j’ai su configurer une machine virtuelle, y installer GoPhish, le configurer, trouver comment ne pas se faire coincer par les sécurités de Microsoft en autorisant cette manipulation et victoire… le mail de test arrive !!! Pour ceux qui découvrent mes RetEx, n’imaginez pas que cela s’est fait le temps d’écrire cette page, c’est des heures de manip (et d’apprentissage).

Je vais récupérer tous les utilisateurs du Tenant Microsoft 365

Deux manières de récupérer les utilisateurs, le plus simple avec l’interface graphique du centre d’administration de M365, sinon cela peut se faire avec une commande powershell.

Je ne vais pas expliquer cette seconde manière de faire, Florian l’a expliquée sur son excellent tuto.

Je prends la formule la plus simple, je vais dans le panneau d’administration puis Utilisateurs actifs puis Exporter les utilisateurs.

L’export se passe bien, je travaille un peu le fichier dans Excel pour supprimer les colonnes inutiles et les lignes qui ne sont pas des utilisateurs. J’ai donc un fichier Excel parfait avec 4 colonnes, je lance un enregistrement en CSV avec une virgule en séparateur pour pouvoir effectuer l’import dans GoPhish.

J’injecte les utilisateurs dans un groupe GoPhish

J’ajoute un nouveau groupe, je lance l’import de mon fichier CSV.

J’ai maintenant un nouveau groupe tout prêt !

Je configure le mail de phishing

Il s’agit du mail que vont recevoir les destinataires de la campagne.

Pour cela, je suis allé demander à Microsoft de m’envoyer un message, j’ai gardé ainsi le format du message. Au final, cela donne :

Je rappelle que c’est à vertu pédagogique, ne me demandez pas le code HTML de la page, je considère que c’est à chacun de faire le travail.

Je configure la page de hameçonnage

Appelée Landing page, cette page de hameçonnage est la page sur laquelle l’utilisateur qu’on souhaite piéger va atterrir quand il cliquera sur le lien qui lui est proposé dans le mail qu’il a reçu.

Je suis allé chercher des modèles pour ne pas réinventer l’eau chaude (merci souleiman)

Voici le meilleur lien qui m’a été utile pour faire la page de connexion M365 la plus réaliste possible.

• https://github.com/brunobotelhobr/My-Gophish-Templates

Je pense bien à la fin de la configuration de la landing page à cocher la récupération de l’email et du mot de passe. J’ai dans l’idée de pouvoir afficher les deux premiers caractères par exemple et le dernier des mots de passe « volés » lors de la formation/sensibilisation des utilisateurs. A noter que les mots de passe récupérés sont donnés en clair, je vais donc déclencher un changement de tous les mots de passe de tous les utilisateurs quelques jours après la campagne de phishing pédagogique.

Quand l’utilisateur clique sur le lien reconnecter ou sur le bouton bleu Se reconnecter, il atterrit sur :

Ne me demandez pas plus le code HTML de cette page.

Je lance la campagne d’hameçonnage

Pour résumer, j’ai créé un groupe d’utilisateurs, un modèle de mail, une page d’hameçonnage, je peux donc aller dans Campagnes pour lancer la campagne.

Quand j’appuie sur Launch Campaign, les mails partent…

Je reviens dans quelques temps donner des nouvelles de la campagne ici…

Bibliographie

• https://www.it-connect.fr/comment-creer-une-campagne-de-phishing-avec-gophish
• https://dazzyddos.github.io/posts/Automating-Phishing-Infrastructure-with-terraform-on-AWS/
• https://clement-bouder.fr/Creer-une-infrastructure-de-phishing/
• https://www.youtube.com/watch?v=Tdpzi8M3Vtw
• https://medium.com/@immure/setting-up-gophish-on-aws-c2f2fd78b7e9