Code : MO-NET-001 | Version : 1.1 | Date : 26 juin 2026 | Auteur : C. Legrand
¶ MO-NET-001 -- Vérification post-hardening du pare-feu OPNsense
¶ 1. Objet
Ce mode opératoire définit la procédure de vérification à appliquer après chaque intervention de sécurisation sur le pare-feu OPNsense de l'infrastructure BTS SIO. Il couvre les principaux axes de durcissement identifiés lors de l'audit : règles de filtrage, détection d'intrusion, accès d'administration, résolveur DNS et proxy.
Chaque contrôle est accompagné de la commande API ou du chemin d'accès dans l'interface web, du résultat attendu et de la conduite à tenir en cas d'anomalie.
¶ 2. Champ d'application
| Élément | Détail |
|---|---|
| Public | Administrateurs infrastructure BTS SIO |
| Système | Pare-feu OPNsense 26.1.x (10.0.112.1) |
| Protocole | HTTP (HTTPS à activer -- tâche T40) |
| Authentification | Session PHP avec jeton CSRF |
| Durée estimée | 15-20 minutes |
¶ Constats d'audit couverts
| Constat | Tâche | Domaine |
|---|---|---|
| F-SEC-001 | T33 | Suppression règle Open_Bar |
| F-SEC-002 | T33 | Filtrage interfaces optionnelles |
| F-SEC-003/004 | -- | Rulesets et interfaces Suricata IDS |
| F-SEC-005 | T33 | Capture trafic proxy Squid |
| F-SEC-006/007 | T32 | SSH WAN désactivé, verrouillage |
| F-SEC-009 | T34 | Comptes nominatifs et privilèges |
| F-SEC-010/011 | T45 | DNSSEC, journalisation DNS |
| -- | T40 | HTTPS interface administration |
¶ 3. Prérequis
- Accès réseau au pare-feu :
http://10.0.112.1(RJ45 ou VPN WireGuard) - Identifiants administrateur OPNsense (gestionnaire de mots de passe)
- Python 3 avec
requestsoucurl - Connaissance des constats d'audit (références F-SEC-xxx ci-dessus)
Note : L'API OPNsense utilise une session PHP avec jeton CSRF. Se référer au MO-NET-002 (section 4.1) pour la procédure d'authentification.
¶ 4. Procédure de vérification
¶ 4.1 Règles de filtrage -- Open_Bar et interfaces
Étape 1 -- Vérifier la suppression de l'alias Open_Bar (F-SEC-001)
L'alias Open_Bar (valeur 10.0.0.0/16) permettait à l'ensemble du réseau interne de contourner le proxy. Contrôler sa suppression :
Via l'interface web : Pare-feu > Alias. Vérifier qu'aucun alias nommé Open_Bar n'apparaît.
Via l'API :
curl -s -b cookies.txt \
"http://10.0.112.1/api/firewall/alias/searchItem" \
-X POST -H "X-CSRFToken: $CSRF" \
-d '{"searchPhrase":"Open_Bar"}'
Résultat attendu : rowCount: 0. Si l'alias est présent, supprimer la règle associée puis l'alias.
Étape 2 -- Vérifier le filtrage des interfaces optionnelles (F-SEC-002)
Les interfaces opt1 et opt2 avaient une règle PASS any > any. Contrôler que les interfaces inutilisées sont désactivées et les interfaces actives ont des règles restrictives.
¶ 4.2 Détection d'intrusion -- Suricata IDS
Étape 3 -- Vérifier les rulesets activés (F-SEC-003)
L'audit avait révélé zéro des 64 rulesets activés. Contrôler :
curl -s -b cookies.txt \
"http://10.0.112.1/api/ids/settings/listRulesets" \
| python3 -c "
import sys, json
data = json.load(sys.stdin)
enabled = [k for k,v in data.items()
if isinstance(v, dict) and v.get('enabled')=='1']
print(f'Rulesets actifs : {len(enabled)}/64')
"
Résultat attendu : au minimum 32 rulesets actifs (ET Open, abuse.ch Feodo, SSL Fingerprint Blacklist, etc.).
Étape 4 -- Vérifier les interfaces surveillées (F-SEC-004)
Via Services > Détection d'intrusion > Administration : vérifier que WAN et LAN sont sélectionnés dans le champ Interfaces.
Étape 5 -- Vérifier la génération d'alertes
curl -s -b cookies.txt \
-X POST "http://10.0.112.1/api/ids/service/queryAlerts" \
-H "X-CSRFToken: $CSRF" \
-d '{"current":1,"rowCount":5}'
Résultat attendu : le nombre total d'alertes est supérieur à zéro.
¶ 4.3 Accès d'administration -- SSH et comptes
Étape 6 -- Vérifier la désactivation du SSH sur WAN (F-SEC-006)
Via System > Settings > Administration : vérifier que Listen Interfaces est restreint au LAN. Via Pare-feu > Règles > WAN : vérifier qu'aucune règle PASS vers le port 49222 n'est présente.
Étape 7 -- Vérifier les comptes et privilèges (F-SEC-009)
Via Système > Accès > Utilisateurs : vérifier que des comptes nominatifs existent, que root est restreint à la console physique, et que le mot de passe partagé a été remplacé.
¶ 4.4 Résolveur DNS -- Unbound
Étape 8 -- Vérifier DNSSEC et journalisation (F-SEC-010/011)
Via Services > Unbound DNS > General : DNSSEC coché, Log Queries et Log Replies cochés. Onglet DNS over TLS : au moins un résolveur DoT configuré.
curl -s -b cookies.txt \
"http://10.0.112.1/api/unbound/settings/get" \
| python3 -c "
import sys, json
data = json.load(sys.stdin)
g = data.get('unbound',{}).get('general',{})
print(f'DNSSEC : {g.get(\"dnssec\",\"?\")}')
print(f'Log queries : {g.get(\"logqueries\",\"?\")}')
"
¶ 4.5 Proxy Squid
Étape 9 -- Vérifier que le proxy reçoit du trafic (F-SEC-005)
Via Services > Web Proxy > Real Time Logs : des requêtes doivent apparaître si Open_Bar a été supprimé.
¶ 4.6 HTTPS interface d'administration
Étape 10 -- Vérifier l'activation HTTPS (T40)
Via System > Settings > Administration : Protocol = HTTPS, certificat valide, redirection HTTP activée.
Attention : L'activation HTTPS nécessite un accès console physique (mot de passe root SSH inconnu). Ne pas tenter à distance sans accès de secours.
¶ 5. Grille récapitulative
- Alias Open_Bar supprimé
- Règle associée supprimée des règles LAN
- Interfaces opt1/opt2 désactivées ou filtrées
- Suricata actif avec >= 32 rulesets
- Interfaces WAN et LAN surveillées
- Alertes récentes présentes dans eve.json
- SSH WAN désactivé (port 49222 fermé)
- Verrouillage sshlockout configuré
- Comptes nominatifs créés, mot de passe partagé remplacé
- root restreint à la console physique
- HTTPS activé (si T40 réalisée)
- DNSSEC activé
- Journalisation DNS queries/replies activée
- DNS over TLS configuré
- Proxy Squid reçoit du trafic
¶ 6. Dépannage
| Problème | Solution |
|---|---|
| API retourne 403 | Session expirée. Se réauthentifier (cf. MO-NET-002 section 4.1). |
| Suricata 0 rulesets | Règles non téléchargées : POST /api/ids/service/updateRules puis reconfigure. |
| Aucune alerte IDS | Vérifier que LAN est sélectionné dans la config IDS. Redémarrer le service. |
| Proxy sans trafic | Vérifier les règles NAT port forward (80/443 vers 3128). Recréer si alias supprimé. |
| Perte Internet après Open_Bar | Tout le trafic passe par le proxy. Vérifier que Squid est démarré et NAT en place. |
| DNS KO après DNSSEC | Désactiver DNSSEC temporairement. Vérifier la chaîne de résolution. |
| Interface web KO après HTTPS | Console physique, option 12 (Restore web GUI defaults) pour revenir en HTTP. |
Voir aussi
- MO-NET-002 — Mise à jour du firmware OPNsense (maintenir le pare-feu à jour avant ou après les contrôles de hardening)
- MO-NET-003 — Configuration des VLANs sur switches Aruba 1930 (les interfaces vérifiées ici filtrent le trafic issu de ces VLANs)
- MO-NET-004 — Routage inter-VLAN sur OPNsense (création des sous-interfaces VLAN et règles de filtrage associées)
- MO-SEC-001 — Exploitation Wazuh (corrélation des alertes de sécurité complémentaire aux contrôles de hardening)
Références
- ANSSI — Recommandations de sécurité relatives aux pare-feux, R1–R15 (2013)
- ANSSI — Guide d'hygiène informatique, mesures 25–30 (2017)
- OPNsense — Firewall, NAT and Rules (documentation officielle)
- OPNsense — Intrusion Detection (documentation officielle)
- Audit BTS SIO — Constats F-SEC-001 à F-SEC-011 / Recommandations R-008 à R-016