Webfilter — filtrage de contenus par catégorie 🟡

EN | FR | 🟡 WALL | paquet secubox-webfilter

À quoi ça sert

Webfilter classe les requêtes DNS de chaque appareil par catégorie (contenu adulte, jeux d'argent, phishing et malware) et, quand l'administrateur le décide, les bloque. C'est un contrôle parental et un filtre de sites dangereux qui agit au niveau du DNS, par Unbound, l'unique moteur DNS de la box. Par défaut il se contente d'observer : rien n'est bloqué tant qu'un profil ne le demande pas.

Capture de démonstration (données fictives). Panneau : /webfilter/ · API : /api/v1/webfilter/ · configuration : /etc/secubox/webfilter.toml. Il est livré dans le profil secubox-lite (voir Modules-by-Profile-FR).

---

Fonctionnement

1. Listes. secubox-webfilter-sync télécharge les listes publiques du catalogue (https seulement, taille plafonnée ; l'ancienne version est gardée si un téléchargement échoue ou est tronqué) et construit un index compact par source. Les listes sont téléchargées à l'exécution, jamais livrées dans le paquet. La synchronisation a lieu toutes les 6 heures et à la demande.
2. Comptage. secubox-webfilter-feed suit le journal d'Unbound, classe chaque nom demandé (le nom ou l'un de ses parents est listé) et compte par jour, appareil, catégorie et domaine sur 30 jours. Les requêtes de la box elle-même sont exclues.
3. Affichage. L'API et le panneau montrent le résultat. La carte d'un appareil du NAC et le panneau Guardian le lisent en lecture seule (voir NAC-FR).

Catégories : adulte, jeux (jeux d'argent), phishing (phishing et malware). Le parking n'a pas de liste publique et est laissé à une phase d'apprentissage ultérieure.

Profils, appareils et exceptions

• Profils : chaque catégorie est en observe ou block, avec des autorisations par domaine. Le profil defaut s'applique à tout appareil non assigné et ne se supprime pas. Deux modèles, enfants et adultes, sont proposés mais jamais appliqués d'office.
• Appareils : la clé est l'adresse MAC (IPv4 et IPv6 ensemble). Un appareil reçoit un profil et des exceptions par catégorie. Les appareils gérés par ad-guard (téléviseurs, streamers) gardent leur filtrage propre et ne sont pas assignables ici (voir DNS-Filtrage).
• Domaines toujours bloqués (bloque, 0.4.0) : un profil et un appareil peuvent chacun porter une liste de domaines refusés quel que soit le mode des catégories, même quand la catégorie qui les liste est en observe pour cet appareil. La liste de l'appareil s'ajoute à celle du profil ; un blocage l'emporte sur une autorisation du même nom ; une autorisation sur un domaine parent ne débloque pas un sous-domaine forcé. La forme canonique est exigée (minuscules, sans schéma ni chemin), 200 domaines au plus. La clé n'est écrite que si elle sert : une configuration sans domaine forcé reste identique à celle d'avant.

Application de la configuration

Les changements sont enregistrés par l'API, puis appliqués par un contrôleur root déclenché par un fichier, jamais par sudo :

1. POST /api/v1/webfilter/appliquer dépose un fichier de demande ; l'unité root secubox-webfilter-apply (déclenchée par une unité .path) lance secubox-webfilter-ctl apply.
2. Le contrôleur valide la configuration comme une entrée hostile, génère le fragment Unbound, vérifie le budget de zones, exécute unbound-checkconf, recharge Unbound et restaure l'ancien fichier octet pour octet en cas d'échec. Un fichier généré identique ne déclenche aucun rechargement.
3. L'estimation (zones, mémoire, durée) est disponible avant d'appliquer. Un rechargement coupe le DNS environ 7 à 10 secondes ; secubox-webfilter-apply.timer applique les changements en attente à 04:00. La synchronisation des listes ne recharge jamais Unbound.
4. Chaque changement effectif (profil, mode d'une catégorie, appareil, application, refus, échec) est écrit dans le journal d'audit.

La mémoire dépend du nombre de configurations effectives distinctes (des appareils de même configuration partagent une vue Unbound), pas du nombre d'appareils.

Correction du profil AppArmor (0.4.1)

Le profil du contrôleur root n'avait pas le droit d'effacer le fichier de demande. Le service d'application échouait, l'unité .path atteignait sa limite de démarrage et « Appliquer maintenant » répondait 409 (« déjà demandée ou en cours »). Le profil l'autorise désormais.

La page Aurora

Depuis la 0.3.0, la page suit le style Aurora : tuiles par catégorie, répartition entre bloqué et observé, appareils les plus filtrés, toutes les actions gardées. Les confirmations de blocage, qui étaient des confirm() ignorés par le navigateur du Hall, sont des confirmations intégrées à la page. La page annonce sa hauteur à l'hôte et accepte ?embed=1 et ?demo=1.

Routes principales

Gardes : require_lecture pour l'état, require_jwt pour le reste.

Méthode	Chemin	Rôle
GET	/health	santé du module (publique)
GET	/etat	catégories, mode global, sources, requêtes classées sur 7 jours, sans nom d'appareil
GET	/stats, /categories/{id}/domaines	décomptes par catégorie et appareil, domaines les plus vus
POST	/sync	demander une synchronisation des listes
GET/POST/DELETE	/profils, /profils/{nom}	profils
GET/POST/DELETE	/appareils, /appareils/{mac}	appareils assignés ou vus récemment
GET/POST	/appliquer	changements en attente, estimation, dernier résultat ; demande d'application

Limites et vie privée

• Un résolveur DoH, un VPN ou une adresse IP directe contournent un filtre DNS ; l'usurpation d'une adresse MAC fait hériter du profil de l'appareil usurpé. Un filtre DNS n'est pas un contrôle d'accès.
• Le décompte « bloqué » peut être surestimé (il ignore les autorisations par domaine et les adresses exclues) ; jamais l'inverse.
• Le décompte par appareil est une donnée de navigation : réservé à l'administrateur, conservé 30 jours, jamais exporté hors de la box. Le filtrage d'un appareil est visible dans le panneau ; aucune surveillance cachée.

Voir aussi

DNS-Filtrage · NAC-FR · Modules-by-Profile-FR · Modules-by-Family-FR · Admin-Panels-Gallery-FR · Aurora-Design-FR · Profils