Manuel pratique Comp’Assist · Révision : 2 octobre 2026. Exemples pédagogiques, à adapter. Les fonctions visibles dépendent de la version, des droits et des paquets installés.
Relever heure, composant, version, message et action qui la déclenche. Une erreur PHP peut venir du cœur ou d’un paquet ; elle ne prouve pas une intrusion et n’est pas automatiquement une CVE. Conserver le diagnostic sans publier configuration, jetons ou chemins sensibles. Examiner le journal système, l’état des services et les notes de version du composant.
Ne pas lancer une mise à jour générique FreeBSD ou remplacer manuellement PHP sur pfSense pour satisfaire un scanner : cela peut désynchroniser le produit. Utiliser les canaux et correctifs supportés. L’absence de patch exige parfois une mesure de réduction d’exposition, documentée et testée.
| Outil | Paramètres à choisir | Ce qu’il démontre |
|---|---|---|
| Ping | Destination et adresse source | Réponse ICMP depuis ce chemin, pas santé applicative |
| DNS Lookup | Nom, serveur selon outil | Résolution depuis le pare-feu |
| Test Port | Hôte et port TCP | Établissement TCP, pas contenu métier |
| Traceroute | Destination/source/protocole selon options | Chemin partiellement visible ; certains sauts restent silencieux |
| Packet Capture | Interface, famille, hôte/port, limite | Paquets réellement observés à cet endroit |
| States | Filtre source/destination | Connexions existantes et traductions |
| ARP / NDP | Interface et voisin | Association locale ; une entrée périmée demande investigation |
| Routes | Famille et destination | Prochain saut choisi par routage |
| pfTop / Activity | Filtre et période | Consommation instantanée, à corréler aux logs |
| Tables | Alias/table concerné | Contenu réellement chargé |
Un test lancé depuis pfSense n’a pas forcément la même source ni les mêmes règles qu’un client LAN. Toujours compléter depuis le client concerné. Capturer brièvement et protéger les fichiers obtenus.
Dans Diagnostics → Backup & Restore, choisir la portée nécessaire et protéger l’export. Un export complet peut contenir comptes, clés, certificats et secrets VPN : le stocker chiffré avec accès restreint. Noter version, matériel et paquets. L’historique local aide à revenir sur une modification, mais il disparaît avec une panne du support ; conserver une copie indépendante.
Pour restaurer, vérifier compatibilité, correspondance des interfaces physiques et présence des paquets. Préparer l’accès console. Ne pas importer la configuration d’un autre site en production sans adapter adresses et secrets. Après restauration, vérifier WAN, LAN, DNS, VPN, règles, certificats et notifications ; une connexion Web retrouvée n’est qu’un premier test.
Lire les notes de la version cible, sauvegarder, vérifier espace et accès de secours, puis utiliser System → Update. Distinguer système et paquets additionnels. Prévoir la coupure réseau et les applications qui en dépendent. Après redémarrage, relever la version active et tester les flux publics et privés.
Ne pas lancer cette opération pendant un transfert critique ou un backup dépendant du pare-feu. Une mise à jour de paquet peut modifier sa configuration ; lire ses changements. Conserver les traces d’une erreur avant de la masquer. Le retour arrière peut nécessiter réinstallation d’une version compatible et restauration, pas un simple bouton d’annulation.
Suricata/Snort, s’ils sont utilisés, demandent interfaces, réseaux internes correctement définis, catégories de règles et ressources suffisantes. Commencer par la détection permet de qualifier le bruit avant un blocage. Le chiffrement limite la visibilité du contenu ; compléter avec les journaux des serveurs Web, applications et bases.
Un blocage automatique doit reposer sur un signal et une répétition qualifiés, avec durée, liste d’exclusion limitée et possibilité de déblocage. Une adresse de proxy/CDN peut représenter tous les visiteurs : la bannir sur le WAN peut couper le site entier. Associer IP interne à un alias d’inventaire, mais ne pas inventer une identité personnelle pour une IP externe.
Un limiter peut réduire la latence sous saturation si sa capacité et son sens sont corrects. Mesurer débit soutenu, pertes et délai avant/après ; une valeur trop basse bride inutilement. Ne pas superposer des files complexes sans comprendre la liaison limitante.
La haute disponibilité exige des équipements, réseaux de synchronisation, adresses virtuelles et chemins WAN/LAN conçus pour elle. Synchronisation de configuration et synchronisation d’états ne sont pas la même fonction. Tester basculement et retour dans une fenêtre, sans provoquer deux maîtres concurrents. Ce n’est pas une simple case pour fiabiliser un unique pare-feu.
Conserver cause, changement, ancien/nouvel état, test autorisé, test interdit et sauvegarde finale. Vérifier que les alertes continuent de fonctionner. Une alerte supprimée sans correction prouvée reste un risque, même si le tableau de bord est vert.