Automatiser la sauvegarde de la configuration du pare-feu

Automatiser la sauvegarde de la configuration du pare-feu

Après avoir migré vers un cluster OPNsense et affiné sa configuration (Suricata, CrowdSec, DNS, certificats...), la question suivante est simple mais trop souvent négligée : que se passe-t-il si les deux nœuds sont perdus en même temps (vol, incendie, casse matérielle) ? OPNsense conserve un historique de configuration local, mais local ne veut pas dire hors-site. Voici comment sortir la sauvegarde du boîtier lui-même, de façon automatique.

1. Pourquoi l'historique intégré ne suffit pas

OPNsense enregistre automatiquement chaque changement de configuration dans System → Configuration → History, avec possibilité de revenir à une version antérieure en un clic. C'est très utile pour annuler une erreur de manipulation, mais ça ne protège en rien contre la perte physique du boîtier — l'historique disparaît avec lui. Une vraie sauvegarde doit vivre ailleurs.

2. Méthode simple : le plugin os-backup

Le plugin os-backup (System → Firmware → Plugins) automatise l'export vers un stockage distant : Nextcloud/ownCloud, un espace local monté en réseau, ou un dépôt Git privé selon la version. Une fois configuré (Services → Backup), il planifie l'export à intervalle régulier sans script à écrire. Pour qui veut une solution intégrée sans sortir du cadre OPNsense, c'est le point de départ le plus simple.

3. Méthode plus flexible : un script via l'API

Pour intégrer la sauvegarde à une infrastructure existante (transfert vers un NAS spécifique, format de nommage particulier, notification en cas d'échec), un script maison via l'API REST d'OPNsense offre plus de contrôle :

  1. Créer une clé API : System → Access → Users, éditer le compte dédié à la sauvegarde, générer une clé API (couple clé/secret).
  2. Appeler l'endpoint de backup pour récupérer le config.xml courant.
  3. Chiffrer puis transférer le fichier vers un stockage distant.
backup-opnsense.sh
#!/bin/sh
# Sauvegarde chiffrée de la config OPNsense, à exécuter depuis un hôte tiers
# (ou en tâche planifiée OPNsense elle-même, Services → Cron).

OPN_HOST="opnsense.exemple.com"
API_KEY="votre_cle_api"
API_SECRET="votre_secret_api"
GPG_RECIPIENT="backup@exemple.com"
DEST_DIR="/mnt/nas/backups/opnsense"
DATE=$(date +%Y%m%d-%H%M)

# Récupération du config.xml via l'API
curl -s -u "${API_KEY}:${API_SECRET}" \
  "https://${OPN_HOST}/api/core/backup/download/this" \
  -o "/tmp/opnsense-${DATE}.xml"

# Chiffrement avant tout transfert (le fichier contient des secrets)
gpg --yes --recipient "${GPG_RECIPIENT}" --encrypt \
  "/tmp/opnsense-${DATE}.xml"

# Transfert vers le NAS, puis nettoyage du fichier en clair
mv "/tmp/opnsense-${DATE}.xml.gpg" "${DEST_DIR}/"
shred -u "/tmp/opnsense-${DATE}.xml"

# Purge des sauvegardes de plus de 90 jours
find "${DEST_DIR}" -name '*.xml.gpg' -mtime +90 -delete
Point critique : le chiffrement n'est pas optionnel. Le fichier de configuration d'un pare-feu contient potentiellement des secrets en clair ou faiblement protégés : mots de passe locaux, clés pré-partagées VPN, clés API de services tiers. Un export non chiffré qui atterrit sur un NAS mal sécurisé (ou pire, un stockage cloud grand public) transforme une bonne pratique en risque de sécurité. Le chiffrement GPG vers une clé dont vous seul détenez la partie privée règle ce problème simplement.

4. Planifier l'exécution

Le script peut tourner directement depuis OPNsense (Services → Cron, qui permet d'exécuter une commande shell arbitraire selon un calendrier), ou depuis un serveur tiers qui interroge l'API à distance — cette seconde option a l'avantage de ne pas dépendre du pare-feu lui-même pour déclencher sa propre sauvegarde.

Règle des 3-2-1 appliquée à un pare-feu : au moins 3 copies de la configuration, sur 2 supports différents, dont 1 hors site. Concrètement : la copie locale (historique OPNsense), une copie sur le NAS du même site, et une copie répliquée ailleurs (autre site, cloud personnel chiffré) — c'est cette dernière qui protège réellement contre une perte totale du site.

5. Tester la restauration

Une sauvegarde jamais restaurée n'est qu'une hypothèse. Prévoyez, au moins une fois, de restaurer un export sur une instance OPNsense de test (une VM, par exemple) pour vérifier concrètement que le fichier est exploitable et que la procédure de restauration (System → Configuration → Backups → Restore) fonctionne comme attendu — bien avant d'en avoir besoin en urgence.

La sauvegarde qui compte n'est pas celle qui s'exécute sans erreur chaque nuit, mais celle qu'on a déjà restaurée une fois pour de vrai.

Conclusion

Que ce soit via le plugin intégré ou un script sur mesure, l'essentiel est de sortir la configuration du boîtier, de la chiffrer avant tout transfert, et de vérifier ponctuellement qu'elle se restaure correctement. C'est une des mesures les moins coûteuses à mettre en place et l'une des plus regrettées quand elle manque. Si vous voulez être accompagné sur votre stratégie de sauvegarde, n'hésitez pas à me contacter.

R
Raph — Chronoassistance25 ans d'expérience en informatique, cybersécurité et infrastructure.