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. L’accès se fait par SSH ou via admin > Console, en haut à droite du WebAdmin. Pour SSH, autoriser SSH pour la zone nécessaire sous Administration > Device access > Local service ACL ; la console web nécessite HTTPS au même endroit. Ne pas ouvrir l’accès au-delà de la source d’administration requise.

Lire l’état global avant toute modification :

system system_modules show

Conserver l’intégralité de la sortie, même si un seul module est étudié. Cela permet de voir si un système migré ou précédemment personnalisé s’écarte de la configuration par défaut. La mention loaded prouve uniquement l’état du module, pas que le helper traite un flux donné ou provoque son erreur. Elle ne prouve pas non plus qu’IRC, SIP ou TFTP sont configurés sans ports personnalisés ni autres arguments personnalisés. Avant toute modification, établir explicitement et documenter, pour le module concerné, si la configuration par défaut sans ports personnalisés ni autres arguments personnalisés est confirmée.

Pour IRC, SIP ou TFTP avec des arguments personnalisés, consigner avant le test l’intégralité de la configuration de référence réellement configurée ainsi qu’une procédure prise en charge, confirmée sur le build installé, permettant de la restaurer exactement. Pour SIP, cela inclut le port de signalisation personnalisé exact, issu de la documentation de configuration existante et fiable ; pour IRC et TFTP, cela inclut toutes les valeurs de ports et des autres arguments réellement configurés. L’aide syntaxique seule ne permet pas d’établir la configuration actuelle. Si la configuration de référence est incertaine, si des valeurs manquent ou si la procédure de retour arrière préservant l’état n’est pas confirmée, laisser le helper concerné inchangé. Ne deviner ni les valeurs par défaut ni les commandes de restauration.

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 de commandes à exécuter entièrement. Le simple changement d’état au moyen de ces commandes et le retour arrière par la commande inverse sont réservés à une configuration de référence par défaut préalablement confirmée, sans ports personnalisés ni autres arguments personnalisés. Pour IRC, SIP ou TFTP personnalisés, appliquer exclusivement la procédure de modification et de restauration consignée avant le test et confirmée pour le build installé ; sans cette procédure, ne commencer aucun test.

Avant l’exécution, contrôler la syntaxe sur le build installé avec l’aide intégrée : saisir la commande prévue et utiliser ? pour afficher ses arguments pris en charge. Ne pas envoyer au hasard de variantes incomplètes ; Sophos avertit qu’une commande Device Console incomplète peut bloquer le daemon access_server. 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.

Connaître les limites SIP avant le test

Par défaut, le helper SIP utilise le port UDP 5060. Il traduit les adresses IP locales de l’en-tête SIP en adresses publiques et crée dans le pare-feu une connexion vocale dynamique attendue. Son effet dépasse donc la simple reconnaissance de la signalisation.

Deux limites sont essentielles pour le diagnostic :

• Le helper ne prend en charge les ports média SIP que dans la plage 1024–65535. Si un port média configuré se trouve hors de cette plage, le pare-feu rejette les paquets et l’Event Log indique Invalid Traffic.
• Le helper ne prend pas en charge un message SIP ou SDP réparti sur plusieurs paquets. Cela peut se produire avec SIP sur TCP. Sophos propose une connexion de contrôle SIP en UDP comme contournement ; elle ne convient que si le fournisseur, le PBX ou le SBC la prend en charge.

Un port de signalisation personnalisé et la plage média RTP sont deux valeurs différentes. <custom_port> dans la commande de chargement désigne le port de signalisation SIP réellement utilisé ; il ne permet pas de déduire une plage RTP.

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 l’état consigné auparavant :

• Si le module était précédemment chargé et que la configuration de référence par défaut sans ports personnalisés ni autres arguments personnalisés est confirmée, le recharger avec la commande ... load correspondante.
• Si le module était précédemment déchargé et que la configuration de référence par défaut sans ports personnalisés ni autres arguments personnalisés est confirmée, le décharger à nouveau avec la commande ... unload correspondante. Ici encore, l’état seul ne suffit pas à prouver l’absence d’arguments personnalisés.
• Si SIP était précédemment chargé sur un port de signalisation personnalisé, restaurer exactement cette valeur consignée avec system system_modules sip load ports <previous_custom_port>. Remplacer <previous_custom_port> par la valeur de la configuration de référence, pas par une nouvelle valeur d’exemple. Cette procédure de retour arrière doit elle aussi être confirmée sur le build installé avant le test et restaurer l’intégralité de la configuration consignée.
• Pour IRC ou TFTP avec des ports personnalisés ou d’autres arguments personnalisés, restaurer l’intégralité de la configuration de référence consignée exclusivement au moyen de la procédure de restauration prise en charge et préalablement confirmée pour le build installé, et non par une simple commande inverse de chargement ou de déchargement. Si cette procédure manque, laisser le helper inchangé dès le départ.

Relancer ensuite system system_modules show et répéter le même flux de test. La sortie CLI doit de nouveau correspondre à l’état initial consigné, et le test ne doit pas avoir perturbé davantage le chemin applicatif initial. Pour IRC, SIP ou TFTP personnalisés, comparer également l’intégralité de la configuration de référence, y compris toutes les valeurs d’arguments consignées, au moyen de la procédure de vérification préalablement confirmée ; un état du module conforme ne suffit pas à prouver sa restauration. Un redémarrage ne remplace pas ce retour arrière.

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.

Pour SIP, le symptôme oriente le contrôle suivant : Invalid Traffic accompagné d’une absence de média conduit d’abord au port média configuré et à la plage 1024–65535. Si l’enregistrement TCP échoue ou si de longs messages SIP/SDP sont interrompus, contrôler la limite d’un seul paquet. Si l’état affiché du module est correct mais que le comportement ne change pas, confirmer d’abord le port de signalisation réellement utilisé et le chemin Rule/NAT concerné.

FAQ