Inspecter les ports non standard avec Sophos Firewall

Sophos Firewall inspecte HTTP, HTTPS, FTP, SMTP/S, POP et IMAP sur leurs ports standard. Lorsqu’une application utilise l’un de ces protocoles sur un autre port, service-param peut étendre l’inspection du protocole à ce port.

La commande n’ouvre pas un port de manière générale. Elle ne crée ni objet de service ni règle de pare-feu et n’active aucune policy web, TLS ou de messagerie. Pour que le trafic soit inspecté, la correspondance de la règle, le port de destination autorisé et le chemin d’inspection responsable doivent être cohérents. Pour les nouvelles règles web, déterminer d’abord si le flux est traité par le DPI Engine ou le Web Proxy.

⚠️ service-param est une affectation globale. Un port supplémentaire ne concerne pas uniquement un hôte ou une règle de pare-feu. Avant la modification, documenter les utilisations existantes du port, les policies concernées et une procédure de retour exécutable.

Choisir d’abord le chemin d’inspection

Un port de destination supplémentaire et l’inspection de ce flux sont deux décisions distinctes. Sous Hosts and services > Services, un objet de service TCP définit le port de destination qui correspond à une règle de pare-feu. Lors de sa création sous Hosts and services > Services > Add, laisser normalement Source port sur 1:65535, car les applications choisissent dynamiquement leur port source. Cet objet n’active pas à lui seul l’inspection du contenu.

Pour le trafic web, service-param n’est généralement pas la première étape dans SFOS 22 :

• Le DPI Engine détecte HTTP et SSL/TLS sur tous les ports. Un portail HTTPS sur TCP 8443 nécessite donc un service correspondant dans la règle de pare-feu, la web policy prévue et les paramètres d’analyse appropriés. Si un déchiffrement est requis, une règle correspondante sous Rules and policies > SSL/TLS inspection rules est également nécessaire. Ces règles détectent TLS sur tout port TCP et évaluent ensemble la source, la destination, l’utilisateur, le service et les critères de sites web.
• Avec Use web proxy instead of DPI engine, le Transparent Web Proxy ne traite que HTTP sur le port 80 et HTTPS sur le port 443. Le trafic HTTP et TLS sur les autres ports reste traité par le DPI Engine. service-param ne permet donc pas d’étendre globalement le proxy transparent à d’autres ports.
• Avec le Direct Web Proxy, le client se connecte au listener configuré sous Web > General settings > Web proxy configuration. Ce chemin de proxy explicite fonctionne indépendamment de la sélection de Use web proxy instead of DPI engine dans une règle de pare-feu.

IPS constitue également un chemin distinct. Intrusion prevention > IPS policies doit être activé globalement, un abonnement Network Protection actif ou une licence d’essai doit être disponible et la policy IPS prévue doit être définie dans la règle de pare-feu correspondante. service-param n’active pas IPS et ne montre pas si une signature a reconnu le flux. Pour le vérifier, corréler Firewall Rule ID et l’événement IPS dans Log Viewer.

service-param reste donc principalement un candidat lorsque le service propre au protocole documenté par Sophos doit traiter un port supplémentaire, par exemple FTP ou un protocole de messagerie. Pour la seule inspection web ou TLS par DPI, configurer plutôt le chemin des règles.

Quand service-param est approprié

La commande convient lorsqu’une application connue utilise réellement HTTP, HTTPS, FTP, SMTP, SMTPS, POP ou IMAP sur un port TCP non standard, que la vérification du chemin d’inspection n’a pas déjà conduit à la solution DPI et que le service propre au protocole doit traiter ce trafic. FTP sur TCP 2121 ou une configuration SMTP convenue sur TCP 2525 en sont des exemples typiques.

Un port TCP ouvert ne prouve pas que le protocole attendu est utilisé. Si un trafic binaire propriétaire circule sur 8443, son affectation à HTTPS peut interrompre des connexions au lieu d’ajouter une protection. Pour le trafic web, vérifier également si le DPI Engine reconnaît déjà le protocole ou si un port de service doit réellement être ajouté au proxy. Pour la messagerie, distinguer SMTP avec STARTTLS de SMTPS avec TLS dès le début de la connexion. Si Mail Protection en mode MTA est utilisé, le trafic suit un autre chemin routé par le MTA.

service-param ne convient pas si une règle de pare-feu doit uniquement autoriser un port de destination supplémentaire. Créer un objet de service TCP approprié sous Hosts and services > Services et l’utiliser dans la règle. Ajouter l’affectation d’inspection uniquement si le proxy ou le service de messagerie responsable doit aussi traiter le port non standard.

Enregistrer l’état initial dans la Device Console

La commande s’exécute sous 4. Device Console. Avant toute modification, la commande suivante affiche les ports de service existants et d’autres valeurs globales :

show service-param

Enregistrer la sortie complète avec le build SFOS, l’heure et la référence du changement. Vérifier en particulier si le port prévu est déjà affecté à un autre service. Ne pas affecter simultanément et sans preuve le même port à HTTP, HTTPS, SMTP et SMTPS.

Sophos documente les noms de service suivants pour SFOS 22 :

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN et IM_YAHOO sont des désignations héritées dans la CLI. Elles ne constituent pas un point de départ pour une nouvelle architecture de messagerie instantanée. Les nouvelles applications sont protégées par les règles de pare-feu, Application Control, TLS Inspection et la détection de protocole réellement prise en charge.

Ajouter un port supplémentaire

La syntaxe de base documentée pour les services pris en charge est la suivante :

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

Pour une connexion SMTP confirmée sur TCP 2525, un pilote contrôlé se présente ainsi :

show service-param
set service-param SMTP add port 2525
show service-param

Cet exemple s’applique à l’inspection par proxy de messagerie transparent en Legacy mode. La règle de pare-feu nécessite également un service autorisant TCP 2525 comme port de destination ; sélectionner SMTP sous Scan email content et configurer une policy de messagerie appropriée. Avant la modification, confirmer que ce port transporte SMTP et s’il utilise STARTTLS. Une connexion TCP ou une livraison de message réussie ne prouve pas à elle seule l’inspection du contenu. En MTA mode, ne pas modifier la règle de pare-feu MTA créée automatiquement pour ce pilote.

Le paramètre fictif portID de la syntaxe Sophos est remplacé par la valeur concrète du port dans la Device Console. N’ajouter le port qu’après confirmation du protocole et du port de destination par un Packet Capture ou par la documentation de l’application.

Ne pas mélanger les options globales avec le test du port

Pour HTTPS, Sophos indique également deny_unknown_proto on|off et invalid-certificate allow|block. SMTPS dispose lui aussi de invalid-certificate allow|block. SMTP offre d’autres options globales pour Failure Notifications, Fast ISP Mode, Notification Port et Strict Protocol Check.

Ces valeurs répondent à un autre besoin que add port et ne sont pas modifiées au cours du même pilote. En particulier, invalid-certificate allow peut tolérer globalement les erreurs de certificat, tandis que deny_unknown_proto et strict-protocol-check modifient le traitement des connexions non conformes. Une connexion réussie après plusieurs modifications simultanées serait difficile à attribuer et pourrait réduire silencieusement la protection.

La syntaxe officielle comprend également :

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Avant l’une de ces modifications globales, évaluer séparément la sortie existante exacte, les expéditeurs ou applications web concernés, l’impact sur la sécurité et les instructions du support. L’article ne présente donc pas ces commandes comme des valeurs par défaut recommandées.

Valider l’effet avec un flux réel

Le test commence avec une seule source pilote et une règle de pare-feu journalisée. Avant et après la modification, utiliser la même destination, le même port et une nouvelle connexion. Dans Log Viewer, Firewall Rule ID, l’action web ou de messagerie et l’heure doivent correspondre au pilote.

Pour HTTPS, vérifier également l’émetteur du certificat, le handshake TLS et l’action Block ou Allow attendue. Si l’analyse antimalware fait partie de l’architecture, exécuter un test EICAR contrôlé exactement sur ce port. EICAR ne confirme que le chemin antivirus normal, pas toutes les fonctions TLS, de policy ou ML. Pour SMTP, SMTPS, POP et IMAP, utiliser un message de test identifiable et le suivre dans Mail Logs, Quarantine et, le cas échéant, Mail Spool.

Un Packet Capture confirme que le client utilise réellement le port de destination prévu. Si seul le Firewall Log indique Allow, rien ne prouve encore que le proxy ou le service de messagerie en aval a inspecté le contenu. Tester les règles Sophos Firewall de manière contrôlée réunit la correspondance des règles, Log Viewer et Packet Capture.

Annuler l’affectation du port

Le retour arrière supprime uniquement du service correct le port ajouté par la modification :

set service-param SMTP delete port 2525
show service-param

Établir ensuite à nouveau le même flux de test. La connectivité doit revenir à l’état initial documenté. Les autorisations temporaires de service du pare-feu, règles pilotes et exceptions sont supprimées séparément ; delete port ne supprime pas ces objets.

Si l’ajout du port échoue, enregistrer l’erreur et show service-param. Les utiliser pour déterminer si le port est déjà considéré comme standard ou affecté à un autre service. Ne pas supprimer aveuglément une entrée existante, car un autre chemin d’inspection peut en dépendre.

Liste de contrôle opérationnelle

• L’application, le protocole et le port de destination réel sont confirmés.
• show service-param et le build SFOS sont enregistrés avant la modification.
• Le service du pare-feu, la correspondance de règle et l’affectation d’inspection sont traités séparément.
• Le port n’est pas déjà affecté à un service incompatible.
• Seul add port change dans le pilote, pas une option globale de certificat ou de protocole.
• Test positif, test négatif, journal d’inspection et Packet Capture sont préparés.
• La commande delete port correspondante et le chemin de retour inchangé sont prêts.

FAQ