Code : MO-NET-001 | Version : 1.0 | Date : 13 avril 2026 | Auteur : C. Legrand
¶ MO-NET-001 -- Verification post-hardening du pare-feu OPNsense
¶ 1. Objet
Ce mode operatoire definit la procedure de verification a appliquer apres chaque intervention de securisation sur le pare-feu OPNsense de l'infrastructure BTS SIO. Il couvre les principaux axes de durcissement identifies lors de l'audit : regles de filtrage, detection d'intrusion, acces d'administration, resolveur DNS et proxy.
Chaque controle est accompagne de la commande API ou du chemin d'acces dans l'interface web, du resultat attendu et de la conduite a tenir en cas d'anomalie.
¶ 2. Champ d'application
| Element | Detail |
|---|---|
| Public | Administrateurs infrastructure BTS SIO |
| Systeme | Pare-feu OPNsense 26.1.x (10.0.112.1) |
| Protocole | HTTP (HTTPS a activer -- tache T40) |
| Authentification | Session PHP avec jeton CSRF |
| Duree estimee | 15-20 minutes |
¶ Constats d'audit couverts
| Constat | Tache | Domaine |
|---|---|---|
| F-SEC-001 | T33 | Suppression regle 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 desactive, verrouillage |
| F-SEC-009 | T34 | Comptes nominatifs et privileges |
| F-SEC-010/011 | T45 | DNSSEC, journalisation DNS |
| -- | T40 | HTTPS interface administration |
¶ 3. Prerequis
- Acces reseau 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 (references F-SEC-xxx ci-dessus)
Note : L'API OPNsense utilise une session PHP avec jeton CSRF. Se referer au MO-NET-002 (section 4.1) pour la procedure d'authentification.
¶ 4. Procedure de verification
¶ 4.1 Regles de filtrage -- Open_Bar et interfaces
Etape 1 -- Verifier la suppression de l'alias Open_Bar (F-SEC-001)
L'alias Open_Bar (valeur 10.0.0.0/16) permettait a l'ensemble du reseau interne de contourner le proxy. Controler sa suppression :
Via l'interface web : Pare-feu > Alias. Verifier qu'aucun alias nomme Open_Bar n'apparait.
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"}'
Resultat attendu : rowCount: 0. Si l'alias est present, supprimer la regle associee puis l'alias.
Etape 2 -- Verifier le filtrage des interfaces optionnelles (F-SEC-002)
Les interfaces opt1 et opt2 avaient une regle PASS any > any. Controler que les interfaces inutilisees sont desactivees et les interfaces actives ont des regles restrictives.
¶ 4.2 Detection d'intrusion -- Suricata IDS
Etape 3 -- Verifier les rulesets actives (F-SEC-003)
L'audit avait revele zero des 64 rulesets actives. Controler :
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')
"
Resultat attendu : au minimum 32 rulesets actifs (ET Open, abuse.ch Feodo, SSL Fingerprint Blacklist, etc.).
Etape 4 -- Verifier les interfaces surveillees (F-SEC-004)
Via Services > Detection d'intrusion > Administration : verifier que WAN et LAN sont selectionnes dans le champ Interfaces.
Etape 5 -- Verifier la generation 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}'
Resultat attendu : le nombre total d'alertes est superieur a zero.
¶ 4.3 Acces d'administration -- SSH et comptes
Etape 6 -- Verifier la desactivation du SSH sur WAN (F-SEC-006)
Via System > Settings > Administration : verifier que Listen Interfaces est restreint au LAN. Via Pare-feu > Regles > WAN : verifier qu'aucune regle PASS vers le port 49222 n'est presente.
Etape 7 -- Verifier les comptes et privileges (F-SEC-009)
Via Systeme > Acces > Utilisateurs : verifier que des comptes nominatifs existent, que root est restreint a la console physique, et que le mot de passe partage a ete remplace.
¶ 4.4 Resolveur DNS -- Unbound
Etape 8 -- Verifier DNSSEC et journalisation (F-SEC-010/011)
Via Services > Unbound DNS > General : DNSSEC coche, Log Queries et Log Replies coches. Onglet DNS over TLS : au moins un resolveur DoT configure.
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
Etape 9 -- Verifier que le proxy recoit du trafic (F-SEC-005)
Via Services > Web Proxy > Real Time Logs : des requetes doivent apparaitre si Open_Bar a ete supprime.
¶ 4.6 HTTPS interface d'administration
Etape 10 -- Verifier l'activation HTTPS (T40)
Via System > Settings > Administration : Protocol = HTTPS, certificat valide, redirection HTTP activee.
Attention : L'activation HTTPS necessite un acces console physique (mot de passe root SSH inconnu). Ne pas tenter a distance sans acces de secours.
¶ 5. Grille recapitulative
- Alias Open_Bar supprime
- Regle associee supprimee des regles LAN
- Interfaces opt1/opt2 desactivees ou filtrees
- Suricata actif avec >= 32 rulesets
- Interfaces WAN et LAN surveillees
- Alertes recentes presentes dans eve.json
- SSH WAN desactive (port 49222 ferme)
- Verrouillage sshlockout configure
- Comptes nominatifs crees, mot de passe partage remplace
- root restreint a la console physique
- HTTPS active (si T40 realisee)
- DNSSEC active
- Journalisation DNS queries/replies activee
- DNS over TLS configure
- Proxy Squid recoit du trafic
¶ 6. Depannage
| Probleme | Solution |
|---|---|
| API retourne 403 | Session expiree. Se reauthentifier (cf. MO-NET-002 section 4.1). |
| Suricata 0 rulesets | Regles non telechargees : POST /api/ids/service/updateRules puis reconfigure. |
| Aucune alerte IDS | Verifier que LAN est selectionne dans la config IDS. Redemarrer le service. |
| Proxy sans trafic | Verifier les regles NAT port forward (80/443 vers 3128). Recreer si alias supprime. |
| Perte Internet apres Open_Bar | Tout le trafic passe par le proxy. Verifier que Squid est demarre et NAT en place. |
| DNS KO apres DNSSEC | Desactiver DNSSEC temporairement. Verifier la chaine de resolution. |
| Interface web KO apres HTTPS | Console physique, option 12 (Restore web GUI defaults) pour revenir en HTTP. |
Voir aussi
- MO-NET-002 — Mise a jour du firmware OPNsense (maintenir le pare-feu a jour avant ou apres les controles de hardening)
- MO-NET-003 — Configuration des VLANs sur switches Aruba 1930 (les interfaces verifiees ici filtrent le trafic issu de ces VLANs)
- MO-NET-004 — Routage inter-VLAN sur OPNsense (creation des sous-interfaces VLAN et regles de filtrage associees)
- MO-SEC-001 — Exploitation Wazuh (correlation des alertes de securite complementaire aux controles de hardening)
References
- ANSSI — Recommandations de securite relatives aux pare-feux, R1–R15 (2013)
- ANSSI — Guide d'hygiene informatique, mesures 25–30 (2017)
- OPNsense — Firewall, NAT and Rules (documentation officielle)
- OPNsense — Intrusion Detection (documentation officielle)
- Audit BTS SIO — Constats F-SEC-001 a F-SEC-011 / Recommandations R-008 a R-016