Gérer en sécurité les System Modules du Sophos Firewall

Sophos Firewall utilise les System Modules comme helpers de protocole lorsque le pare-feu doit suivre des informations supplémentaires ou tenir compte de connexions dynamiques. SFOS 22 répertorie dns, h323, irc, pptp, sip et tftp. Ces modules sont chargés par défaut.

Un module chargé n’est ni une règle de pare-feu ni une recommandation d’utiliser le protocole concerné. Il ne remplace pas une règle NAT, une route ou une stratégie de sécurité adaptée. À l’inverse, décharger globalement tous les helpers apparemment inutilisés n’est pas une mesure de durcissement pertinente. Le réglage est global et peut modifier de façon inattendue des applications existantes.

⚠️ Règle d’exploitation : Documenter d’abord l’état et le flux défaillant précis. Ne modifier qu’un seul module, répéter le même flux et restaurer l’état initial en l’absence d’amélioration.

Bien distinguer les six modules

Pour sip et h323, le helper est souvent présenté trop vite comme cause ou solution. Le processus complet avec NAT, RTP, timeouts, port SIP personnalisé, Packet Capture et appels de test se trouve dans Résoudre les problèmes VoIP avec SIP et RTP.

Enregistrer l’état initial dans Device Console

Ces commandes s’exécutent dans 4. Device Console, pas dans Advanced Shell. Lire l’état global avant toute modification :

system system_modules show

Conserver toute la sortie, même si un seul module est étudié. Elle indique si un système migré ou anciennement adapté diffère de la valeur par défaut. La mention loaded prouve uniquement l’état du module, pas que le helper traite un flux donné ou provoque son erreur.

Noter aussi les IP source et destination, le port, le protocole, la Rule ID, la NAT ID, l’heure et le test applicatif exact. Sans flux reproductible, l’effet d’une modification globale ne peut pas être évalué. Log Viewer, Policy Test et Packet Capture servent à la validation technique.

Charger ou décharger exactement un module

Les commandes de base suivent le même modèle. Le tableau est une référence, pas un bloc à exécuter entièrement.

Vérifier la syntaxe du build installé avec ? avant exécution. Après une seule modification, relancer system system_modules show, puis répéter le flux applicatif documenté. Éviter toute modification parallèle du NAT, des règles, du routage, des timeouts ou du PBX, car elle rend l’attribution difficile.

Sophos indique explicitement que load et unload pour SIP persistent après un redémarrage. La page SFOS 22 des System Modules ne fournit pas la même précision pour les autres modules. Relire leur état après un redémarrage planifié au lieu de supposer leur persistance.

Ne pas déduire les ports personnalisés d’une syntaxe abrégée incomplète

La page mentionne pour IRC, SIP et TFTP des termes supplémentaires tels que port, portname, default ou show, sans expliquer complètement leur forme exacte. Ces valeurs ne doivent pas être devinées. Device Console affiche la syntaxe du build installé avec ?.

Pour SIP, Sophos publie séparément la commande exacte system system_modules sip load ports <custom_port>. Cette décision appartient à l’analyse VoIP, pas à un test général des helpers. Remplacer le placeholder par le port de signalisation réellement utilisé par le fournisseur ou le PBX.

Vérifier l’effet et le retour arrière

Un test utile va au-delà de la sortie CLI. Après chargement ou déchargement, contrôler l’établissement de la connexion, le trafic dans les deux sens, les Rule et NAT ID, les drops et l’application concernée. Pour SIP ou H.323, tester l’enregistrement, les connexions entrantes et sortantes et les médias bidirectionnels. Pour DNS, vérifier requête et réponse avec le nom attendu. Pour TFTP, vérifier aussi le transfert du fichier.

Si le symptôme reste identique ou si de nouvelles erreurs apparaissent, remettre uniquement le module modifié dans son état précédent. Relancer ensuite system system_modules show et le même flux de test. Un redémarrage ne remplace pas ce rollback.

Si le comportement change mais que la cause reste incertaine, conserver les états avant et après, le build du firmware, les logs et le Packet Capture. Un helper globalement déchargé ne doit pas devenir une solution permanente parce qu’un seul test court semble meilleur.

FAQ