NAC FR

NAC — contrôle d'accès réseau 🟠

EN | FR | 🟠 AUTH | qui est sur le réseau, dans quelle zone, et pourquoi

À quoi ça sert. Le NAC (Client Guardian, paquet secubox-nac) tient l'inventaire de chaque appareil du réseau local, le place dans une zone appliquée par nftables, déduit son système d'exploitation à partir de preuves, et met en quarantaine ce qui ne doit pas être cru. Un appareil inconnu arrive en quarantaine par défaut.

• Paquet : secubox-nac · panneau /nac/ · API /api/v1/nac/ · configuration /etc/secubox/nac.toml
• Il absorbe les anciens modules mac-guard, device-intel et iot-guard : leurs anciennes adresses redirigent vers /nac/ (301) et leurs anciennes API répondent 410.

---

Zones

Chaque appareil appartient à une zone, portée par un ensemble nftables. Les chaînes tournent à priority filter - 5 : un drop est final, une erreur n'ouvre jamais rien.

Zone	Ensemble	Effet
lan	lan_allowed	aucune restriction
lxc	lxc_zone	aucune restriction (les conteneurs de br-lxc y arrivent seuls)
iot	iot_zone	internet oui ; LAN et conteneurs (RFC 1918) non
guest	guest_zone	internet oui ; LAN et conteneurs non
quarantine	quarantine_zone	rien à travers la box ; vers la box seulement DHCP et DNS
bloqué	blocked	rien n'entre ni ne sort, ni vers la box ni à travers elle

Un déplacement fait par l'administrateur l'emporte toujours ; le classement par interface (br-lxc → lxc, extensible par interface_zones dans [nac]) ne comble que les appareils non placés explicitement.

Comment une décision atteint le pare-feu

L'API tourne sans privilège et n'appelle jamais nft.

1. Bloquer, mettre en quarantaine ou changer de zone écrit l'état voulu dans /var/lib/secubox/nac/nft-desired.json (écriture atomique, verrouillée).
2. secubox-nac-apply.path voit le changement et lance secubox-nac-apply (root, étroit : CAP_NET_ADMIN seul). Il valide chaque MAC et chaque nom d'ensemble, puis charge règles et éléments en une transaction.
3. Au démarrage de nftables (et à chaque redémarrage), la table est reconstruite depuis cet état.

Le statut réel est dans nft-applied.json et repris par /status ; GET /sync_zones redemande l'application.

---

Détection de l'OS — sur preuve uniquement

Le collecteur renseigne quatre champs par appareil, visibles dans le panneau et dans GET /clients et GET /client/{mac} :

Champ	Sens
os	système déduit (iOS 17, Android 13, Windows, OpenWrt (Linux)…) ou vide
os_source	la preuve, obligatoire dès qu'os est renseigné : dhcp-vendor-class:…, user-agent:…, dns:<domaine>, hostname:<nom>, empreinte-nac:openwrt
device_subtype	type fin : smartphone, tablette, télévision, imprimante, streaming, objet connecté…
mac_random	1 si le bit « localement administré » de la MAC est posé (adresses de confidentialité iOS/Android/Windows)

Règles :

• Aucune inférence sans preuve : un OS sans source est refusé.
• Le fabricant (OUI) seul ne donne jamais d'OS ; une MAC aléatoire n'est pas typée par son fabricant.
• La preuve la plus forte l'emporte : classe vendeur DHCP > User-Agent > domaines DNS > nom de l'appareil > empreinte du NAC. Les services mDNS sont aussi compris.
• Une conclusion dont la preuve a disparu est retirée au cycle suivant.

Preuves réellement branchées aujourd'hui : le nom de l'appareil, les domaines DNS de connectivité (lecture seule, dans la base d'ad-guard, jamais un autre domaine), l'empreinte OpenWrt/SecuBox et, depuis la 3.9.0, les types de service Bonjour/mDNS (voir ci-dessous). La classe vendeur DHCP et le User-Agent sont compris par le détecteur mais pas encore alimentés : quand le DHCP est servi par la box internet, le NAC ne voit pas l'option 60, et aucun User-Agent par appareil n'est encore remonté.

Les conteneurs LXC portent un indicateur conteneur ; ?exclure_conteneurs=true les masque.

Noms et services par Bonjour/mDNS

Depuis secubox-nac 3.9.0, une passe avahi-browse mise en cache (120 s) renseigne ce que les baux DHCP ne disent pas :

• le nom d'un appareil sans bail (un bail l'emporte toujours) et le nom annoncé (par exemple une télévision du salon) ;
• des pastilles de services (impression, AirPlay, Chromecast, partage…), renvoyées sous services par GET /clients et recherchables depuis la page ;
• les types de service nourrissent aussi la détection du type fin de l'appareil.

Bonjour absent ou en échec : la découverte continue sans. Depuis la 3.9.1, l'appel utilise avahi-browse -k ; sans cela les types de service étaient traduits en texte et aucun service n'était reconnu.

Conteneurs LXC nommés

Les conteneurs de nos propres modules sont connus par leur nom, même sans DNS ni bail. Un petit service root, secubox-nac-lxc-names (minuterie de 5 minutes), écrit un inventaire conteneurs.json (adresse → nom), car les dossiers des conteneurs sont fermés au compte du NAC ; le NAC l'utilise pour les appareils sans nom. Fichier absent ou illisible : aucun nom, jamais d'erreur.

---

Quarantaine

Cas	Comment
Appareil inconnu	la zone par défaut est quarantine (default_zone de la politique)
Manuelle	Quarantaine dans le panneau, ou POST /quarantine_client
Levée	Lever place l'appareil en lan (POST /unquarantine)
Bannissement	POST /ban_client (ensemble blocked), POST /unban_client le remet en quarantaine
Automatique	quand le moteur d'Actor Intelligence publie la mesure QUARANTINE pour un appareil du LAN (risque ≥ 75, confiance ≥ 80, deux capteurs distincts au moins)

La quarantaine automatique utilise la même zone de quarantaine. Il n'y a pas de libération automatique : un administrateur reconnaît et valide l'appareil. Une même mesure n'isole qu'une fois.

Réglage [nac] (/etc/secubox/secubox.conf)	Défaut	Rôle
quarantaine_auto	auto	auto isole, propose consigne seulement le candidat, off coupe ; toute autre valeur vaut off
quarantaine_protegees	[]	adresses MAC jamais isolées

Jamais isolés : la box, un routeur, un équipement OpenWrt/SecuBox, une MAC protégée, ni un appareil absent depuis plus de 3 h. GET /quarantaine/auto rend le mode et les candidats ; chaque isolement laisse une ligne quarantine_auto dans l'historique de l'appareil et un événement client_quarantined_auto.

---

La page Aurora /nac/

Appareils du réseau — qui est connecté, depuis quand, sur quel système, et ce que le NAC en a décidé.

Bloc	Contenu
Tuiles	appareils, connectés, inconnus, en quarantaine, autorisés, part d'OS identifiés (définition de chaque tuile en infobulle). Depuis la 3.6.1, les tuiles sont des boutons de filtre (Connectés, Inconnus, En quarantaine, Autorisés, OS identifiés ; Appareils remet tout à zéro) et la tuile active suit les listes déroulantes
Cartes d'appareils	recherche (nom, IP, fabricant, OS, service), filtres (état, OS, connecté ou non), tri (dernière vue, nom, IP) ; chaque carte montre le filtre web de l'appareil (profil de filtrage de contenus, requêtes bloquées et classées sur 7 jours, ou « géré par ad-guard », en lecture seule)
Clients réels	depuis la 3.7.0, l'appareil du NAC, ses identités Toolbox et son activité DPI sont réunis sur des preuves (clé d'appareil = condensat de la MAC ; sinon même adresse de tunnel annoncée, signalée comme déduite ; sinon l'identité seule) : camembert global des usages, histogramme des clients actifs par type d'usage, une fiche par client
Conteneurs LXC	les conteneurs du pont br-lxc ont leur propre panneau et ne figurent plus dans la liste des appareils, les tuiles, les répartitions ni les nouveaux appareils ; l'action de quarantaine reste réservée aux appareils
Graphiques	répartition par OS (avec la preuve), par état, zones, nouveaux appareils sur 24 h
Comportement des zones	le comportement réel de chaque zone, tiré des règles nft effectives (voir ci-dessous)
Lecture seule	politique d'admission, historique récent

Actions : affecter un appareil à une zone (LAN, IoT, Invités, Quarantaine), Autoriser, Bloquer, Quarantaine et Lever, chacune avec une confirmation intégrée à la page. L'API fournit la zone NAC, pas un numéro de VLAN, et la page le dit.

Comportement des zones

GET /zone_behaviors (administrateur) rend ce que chaque zone fait réellement : isolement du LAN, DNS et DHCP de la box, quarantaine, bloqué. Rien n'est déclaré qui ne soit appliqué : chaque ligne reprend une règle du fichier nft livré (un test le vérifie). Ce que le NAC ne fait pas (puits DNS de quarantaine, page de parking, zone de repli, Tor ou VPN par zone) est listé à part, marqué indisponible. Tor et VPN existent, mais comme un choix du Toolbox par client (niveaux R0 à R3, tunnel WireGuard), pas comme une propriété d'une zone NAC ; l'analyse (DPI, DNS, Actor Intelligence) observe le trafic quelle que soit la zone. Ajouter ?demo=1 donne une vue de démonstration (un bandeau l'annonce, les actions sont inertes) et ?embed=1 permet d'intégrer la page dans une autre.

Routes principales

Gardes : require_jwt (administrateur) pour agir, accès en lecture pour le statut.

Méthode	Chemin	Rôle
GET	/status, /summary, /stats	état du module et compteurs
GET	/clients, /client/{mac}	inventaire, détail (OS, source, sous-type)
GET	/zones	zones et membres
POST	/add_to_zone, /remove_from_zone	déplacer un appareil
POST	/approve_client, /ban_client, /unban_client	décider
POST	/quarantine_client, /unquarantine	quarantaine et levée
GET/POST	/policy	politique d'admission
GET	/history, /alerts	événements
GET	/quarantaine/auto	mode et candidats de la quarantaine automatique
POST	/scan	scan actif d'un sous-réseau (validé)

---

Voir aussi

• ToolBox — la cabine numérique (quarantaine d'un appareil exposé)
• DNS-Filtrage — ad-guard, dont les preuves DNS nourrissent la détection d'OS
• Device-Categories — taxonomie des appareils
• Admin-Panels-Gallery-FR — le style commun Aurora des panneaux
• Webfilter-FR — le filtre de contenus dont le profil figure sur chaque carte d'appareil
• Architecture — la pile à six modules