Configurer et tester le contrôle des applications sur Sophos Firewall

Application Control identifie le trafic applicatif qu’il est impossible de distinguer de manière pertinente à partir des seuls ports. Sophos Firewall peut ainsi autoriser ou bloquer de façon ciblée les outils de contrôle à distance, les applications de tunneling, les services de streaming ou le stockage dans le cloud, par exemple. La détection est consignée par l’intermédiaire de la règle de pare-feu associée ; un Application Filter ne possède pas sa propre action Log.

Le principe est simple : créez le filtre sous Applications > Application filter, attribuez-le sous Rules and policies > Firewall rules à la règle effectivement appliquée, puis vérifiez la Rule ID, l’application et l’action avec un vrai client. Une Filter Policy simplement enregistrée ne modifie aucun trafic.

Définir les prérequis et l’objectif

Application Control fait partie de la Web Protection Subscription. Vérifiez l’état de la licence sous Administration > Licensing. Avant la configuration, déterminez également :

• la zone d’utilisateurs ou le segment réseau concernés, ainsi que leurs chemins IPv4/IPv6 ;
• l’application ou le groupe à surveiller ou à bloquer dans un premier temps ;
• la règle de pare-feu qui traite actuellement ce trafic ;
• un client de test, une requête de test reproductible et le résultat attendu ;
• l’Application Filter actuellement attribué, la position de la règle et l’association NAT existante, qui serviront d’état de référence pour le retour arrière.

Contrôlez les mises à jour des signatures sous Backup & firmware > Pattern updates. Elles s’effectuent automatiquement par défaut ; si nécessaire, Update pattern now met à jour toutes les définitions de patterns, à l’exception des patterns de firmware pour AP et RED. Les états Ready to install, Downloading, Success et Failed facilitent le diagnostic. Les signatures d’applications restent disponibles même sans licence IPS active, tandis que les signatures IPS nécessitent une licence adéquate et l’activation d’IPS.

Activez Log firewall traffic pour la règle de test. La journalisation est gérée par la règle de pare-feu, et non par l’Application Filter. Pour commencer par une simple observation, utilisez donc un filtre qui autorise le trafic et analysez les applications détectées avant de définir certaines d’entre elles sur Deny.

Si votre objectif réel est de hiérarchiser le trafic ou de limiter la bande passante, complétez le filtre en suivant Configurer l’Application Traffic Shaping sur Sophos Firewall. Les routes SD-WAN basées sur les applications utilisent en revanche un Application Object ; la procédure est décrite dans Configurer une route SD-WAN avec basculement de passerelle sur Sophos Firewall.

Planifier et créer l’Application Filter

Sous Applications > Application list, vous pouvez vérifier si Sophos dispose d’une signature dédiée et connaître la catégorie ou le niveau de risque auquel elle est actuellement associée. Pour le filtre Name, les opérateurs contains, is, is not et does not contain sont disponibles. La présence d’une application dans le catalogue ne prouve pas encore qu’elle sera identifiée sur votre réseau ; le test avec un client permettra de le vérifier ultérieurement.

Une sélection fixe d’applications individuelles offre un comportement prévisible. À l’inverse, les critères tels que Risk, Category ou Classification, ce dernier étant réservé aux applications cloud, restent dynamiques : les signatures nouvelles ou reclassées pourront elles aussi correspondre à l’avenir. Ces règles doivent avoir un Owner désigné et faire l’objet d’une révision documentée après toute modification des patterns ou des classifications.

Le chemin complet permettant de créer une Policy et sa règle est le suivant :

Applications > Application filter > Add
Applications > Application filter > Edit policy > Add

1. Sous Add, attribuez un nom explicite, par exemple Block_File_Transfer_Pilot.
2. Choisissez un Template. Pour un blocage ciblé, Allow All constitue un point de départ facile à comprendre ; ne partez pas du principe que toute nouvelle Policy vide adopte automatiquement ce comportement.
3. Enregistrez la Policy, ouvrez-la de nouveau, puis créez une règle de filtrage avec Add.
4. Utilisez Select Individual Application ou, avec Select All, affinez les résultats selon Application, Category, Risk, Characteristics, Technology, Classification ou Smart Filter.
5. Définissez Action sur Allow ou Deny.
6. Sous Schedule, choisissez par exemple All the time ou attribuez un calendrier adapté.
7. Enregistrez d’abord la règle de filtrage, puis la Policy.

SFOS fournit notamment les Templates Allow All, Deny All, Block filter avoidance apps, Block generally unwanted apps, Block high risk (Risk Level 4 and 5) apps, Block peer to peer (P2P) networking apps et Block very high risk (Risk Level 5) apps. Un Template est un point de départ, et non une configuration standard prête à l’emploi. Avant toute attribution à grande échelle, comparez en particulier les règles fondées sur Risk et Category aux applications nécessaires sur votre propre réseau.

Les règles soumises à des contraintes horaires nécessitent un Schedule approprié. Pour savoir comment le créer et le vérifier par rapport à l’heure du pare-feu et aux règles de repli, consultez Configurer des calendriers pour les règles et les Policies sur Sophos Firewall.

Exemple : bloquer les transferts de fichiers effectués dans un navigateur

L’exemple officiel laisse les autres applications de transfert de fichiers inchangées et cible uniquement les transferts effectués dans un navigateur :

1. Créez la Policy Block_File_Transfer_Pilot à partir de Allow All, puis ouvrez-la de nouveau.
2. Créez une règle avec Add > Select All.
3. Sélectionnez Category: File Transfer, Characteristics: Transfer files et Technology: Browser Based.
4. Définissez Action: Deny et Schedule: All the time.
5. Enregistrez la règle de filtrage et la Policy.

Cette sélection peut également affecter des opérations légitimes d’envoi de fichiers, de collaboration ou de sauvegarde. Le client pilote doit donc tester à la fois un transfert à bloquer et un service professionnel explicitement autorisé dans le même périmètre.

Attribuer le filtre à la bonne règle de pare-feu

Application Control ne prend effet qu’au sein d’une règle de pare-feu. Pour créer une règle, le chemin actuel est le suivant :

Rules and policies > Firewall rules
> IPv4 ou IPv6
> Add firewall rule
> New firewall rule
> Other security features
> Identify and control applications (App control)

Pour une règle existante, ouvrez directement Other security features et sélectionnez l’Application Filter préparé. Laissez Log firewall traffic activé pendant le pilote et la recette.

La règle doit réellement correspondre aux paramètres Source Zone, Source Network, Destination Zone, Destination Network et Services du client de test, ainsi qu’à Match known users, le cas échéant. Les règles de pare-feu sont évaluées de haut en bas ; la première correspondance met fin à la recherche. Une règle plus générale placée au-dessus est donc plus souvent en cause que l’Application Filter lui-même.

Pour une nouvelle règle Internet, le chemin NAT doit lui aussi être correct. Dans les exemples Sophos, Create linked NAT rule peut générer une règle MASQ. Dans un environnement existant, ne créez pas une seconde règle NAT par précaution : vérifiez plutôt la règle SNAT/MASQ déjà active et notez sa NAT Rule ID.

IPv4 et IPv6 possèdent des chemins de règles distincts. Si le client utilise les deux protocoles, testez-les tous les deux ou limitez délibérément le pilote à l’un d’eux. Les principes de base sont expliqués dans Comprendre et configurer en toute sécurité les règles de Sophos Firewall.

Prouver le fonctionnement avec Live Connections et Log Viewer

Un test fiable répond à trois questions distinctes : quelle règle traite le flux, quelle application SFOS identifie-t-il et quelle action exécute-t-il ?

1. Notez le client de test, l’adresse IP source, l’utilisateur, l’heure et la destination.
2. Dans les options de la règle pilote, exécutez éventuellement Reset data transfer count afin de faciliter l’attribution des nouveaux octets.
3. Lancez la requête de test et examinez la connexion encore ouverte sous Current activities > Live connections.
4. Comparez-y Application, Source IP, Username, Interfaces, les ports source et de destination, Firewall Rule ID et NAT Rule ID avec le chemin prévu.
5. Ouvrez le Log viewer en haut à droite de WebAdmin, puis filtrez les événements selon l’adresse IP source, l’utilisateur, la destination, la Rule ID et l’application.
6. Effectuez un test de blocage attendu et une requête de contrôle autorisée à partir du même périmètre.

Une détection refusée par l’Application Filter apparaît sous Content Filtering > Application > Denied. Le trafic autorisé et identifié figure dans le journal du pare-feu sous Firewall > Firewall Rule > Allowed. Pour la recette, consignez au minimum Firewall Rule ID, Application Filter, l’application, la catégorie, le risque, l’action, l’utilisateur, la source et la destination.

Les sessions du pare-feu n’apparaissent souvent qu’au moment du Connection Destroy event, lorsque SFOS ferme la connexion. Une session de navigation ou de streaming encore ouverte peut donc déjà être visible sous Live connections, alors que son entrée finale n’est pas encore présente dans le journal du pare-feu. Les connexions SSL/TLS sont journalisées après l’établissement de la poignée de main et lors de leur fermeture.

Sous Reports > Dashboards > Traffic dashboard > Allowed policies, vous pouvez également contrôler les données transférées par les règles d’autorisation. Ce rapport ne remplace toutefois pas le test concret de la Rule ID et de l’application.

Avec Syslog ou un SIEM, les noms de champs varient selon le format de sortie. Le Central Reporting Format utilise notamment fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier et status. Dans le Device Standard Format (Legacy), les champs correspondants s’appellent par exemple application_filter_policy, application_name, application_category, application_risk et appresolvedby. Les champs app_resolved_by et appresolvedby distinguent notamment Signature, Proxy et Synchronized Application Control (EAC).

Les événements techniques liés aux Application Filters et à DPI sont consignés dans ips.log ; sig_upgrade.log et sigmigration.log facilitent le diagnostic des mises à jour de signatures. La correspondance entre services et journaux est décrite dans Dépannage de Sophos Firewall : services et journaux. Packet Capture peut confirmer les adresses IP, les ports, l’interface et le chemin des paquets, mais ne prouve pas la classification de l’application. La démarche de diagnostic combinée est présentée dans Tester une règle Sophos Firewall avec Log Viewer, Policy Test et Packet Capture.

Tenir compte de HTTPS, de QUIC et des exceptions Web

SFOS identifie de nombreuses applications fondées sur des signatures même sans déchiffrement complet. Toutefois, les Micro Apps basées sur des URL, comme les transferts de fichiers dans Dropbox ou Gmail, ont besoin de l’URL déchiffrée lorsque le trafic est chiffré. Dans le chemin DPI, cela nécessite une règle adaptée sous Rules and policies > SSL/TLS inspection rules. Scan HTTP and decrypted HTTPS active l’analyse antimalware du trafic HTTPS déjà déchiffré, mais n’active pas elle-même le déchiffrement.

Dans le chemin du proxy Web, Decrypt HTTPS during web proxy filtering assure le déchiffrement. La présence d’une Web Policy ne prouve ni que HTTPS est déchiffré, ni que la même règle DPI s’applique. Le déploiement contrôlé est décrit dans Déployer correctement l’inspection TLS sur Sophos Firewall.

Block QUIC protocol rejette, dans le périmètre de la règle de pare-feu, les paquets UDP sortants à destination des ports 80 et 443, afin que les clients se rabattent sur un chemin TCP pouvant être inspecté. SFOS sélectionne cette option par défaut dès qu’une Web Policy est choisie ou que Scan HTTP and decrypted HTTPS est activé. Le filtre Web ne peut pas analyser QUIC ; cela ne signifie toutefois pas que QUIC contourne tous les autres contrôles du pare-feu. Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall décrit les tests positif et négatif.

En cas de détection inattendue, vérifiez également Web > Exceptions. Une Web Exception peut ignorer le déchiffrement, l’analyse antimalware et l’analyse de contenu, ainsi que les contrôles de Policy ; selon les options sélectionnées, elle s’applique aux chemins DPI et proxy. Une exception trop large peut donc supprimer le contexte applicatif attendu.

Dans le cas d’un trafic passant par le proxy Web, une entrée Allowed dans le journal du pare-feu ne prouve pas automatiquement que l’accès de l’utilisateur a été autorisé : le pare-feu peut d’abord transmettre la connexion au proxy, avant que le Web Filter ne la consigne comme Blocked. Dans ce cas, examinez conjointement les journaux du pare-feu et du Web.

Classifier les applications cloud

Sous Applications > Cloud applications, SFOS affiche uniquement le trafic autorisé et les applications pour lesquelles du trafic existe. La vue peut être filtrée selon la date, Classification, Category et le nombre d’octets transférés ; Expand ouvre les détails. L’absence d’une entrée n’exclut donc pas une tentative bloquée.

Les nouvelles applications cloud portent initialement la Classification new. Après vérification, attribuez-leur sanctioned, unsanctioned ou tolerated avec Classify. La nouvelle Classification s’applique au nouveau trafic, mais elle ne l’autorise ni ne le bloque à elle seule. Seul un Application Filter qui utilise ce critère et qui est attribué à une règle de pare-feu correspondante met en œuvre l’action souhaitée.

Les données élémentaires d’utilisation et de volume nécessitent la journalisation du pare-feu. Les compteurs d’envoi et de téléchargement ainsi que les détails sur les types de fichiers nécessitent le déchiffrement HTTPS ; selon Sophos, une Web Policy autre que None améliore également la précision et le niveau de détail. Certaines applications utilisent leurs propres mécanismes de transfert, si bien que certains champs détaillés peuvent malgré tout rester vides.

Sous Traffic shaping, vous pouvez attribuer une Policy de bande passante préparée à une application cloud identifiée. Cette attribution ne remplace ni l’Application Filter ni la règle de pare-feu.

Cas particuliers : stockage en ligne et vidéos Facebook

L’exemple officiel de Google Drive associe l’Application Filter Block_GoogleDrive à la Web Policy BlockPersonalStorage. Le filtre est créé à partir de Allow All, recherche google drive avec Smart Filter, puis définit les applications sélectionnées sur Deny et All the time. Sous Web > Policies, pour la règle de stockage ciblée, désélectionnez All web traffic, recherchez personal avec Add new item > Web category, puis définissez les catégories appropriées sur Block HTTP et Block HTTPS. Les deux Policies doivent être attribuées à la même règle de pare-feu, celle qui est effectivement appliquée. Configurer Web Protection sur Sophos Firewall explique le fonctionnement des Policies.

Dans l’exemple des vidéos Facebook, sélectionnez les résultats correspondant à Facebook videos dans l’Application Filter à l’aide de Select Individual Application. Pour une catégorie personnalisée, Sophos mentionne actuellement facebook.com/watch, facebook.com/reel, gateway.facebook.com, facebook.com/ajax et facebook.com/stories, ainsi que les mots-clés watch, reel, gateway, ajax et videos. Ces valeurs dépendent de la version et ne constituent qu’un point de départ ; vérifiez-les avant leur utilisation, car des mots-clés généraux peuvent également correspondre à d’autres chemins. La catégorie doit se trouver dans une règle de Web Policy associée à une action de blocage ; la procédure Facebook actuelle ne nomme pas cette action aussi explicitement que l’exemple du stockage.

L’exemple Sophos utilise le Web Proxy, déchiffre HTTPS et bloque QUIC. Les clients doivent donc faire confiance à la Sophos Firewall CA. Ne modifiez pas un environnement DPI existant uniquement pour ce cas particulier ; utilisez-y une SSL/TLS Inspection Rule adaptée. La création de catégories personnalisées est expliquée dans Créer des catégories Web sur Sophos Firewall, et le déploiement de la CA dans Déployer le certificat CA de Sophos Firewall pour l’analyse HTTPS.

Utiliser Synchronized Application Control de manière ciblée

Synchronized Application Control complète la détection réseau grâce aux données provenant des Sophos Endpoints administrés. Outre la Web Protection Subscription, cette fonction nécessite Security Heartbeat, une Network Protection Subscription, un compte Sophos Fusion (anciennement Sophos Central) et un Endpoint administré disposant d’une licence d’évaluation ou complète.

L’enregistrement s’effectue sous :

System > Sophos Central > Sophos Central registration > Register

Une fois l’enregistrement réussi, SFOS active automatiquement Security Heartbeat et Synchronized Application Control. Si Security Heartbeat est désactivé, Synchronized Application Control l’est également ; cette méthode ne constitue donc pas un retour arrière ciblé pour une seule application.

Sous Applications > Synchronized Application Control, effectuez une recherche par nom, chemin, catégorie ou Endpoint, puis développez l’entrée pour afficher ses occurrences. Sophos prend en charge jusqu’à 15'000 applications. Depuis SFOS 20.0 MR1, SFOS ne conserve que les cinq occurrences les plus récentes de chaque application par Endpoint.

Lors d’une migration vers SFOS 21.0 ou une version ultérieure, SFOS active le nettoyage automatique de Synchronized Application Control et règle sa durée sur douze mois par défaut. Si une autre durée avait été configurée auparavant, elle est conservée. Le nettoyage supprime également des Application Filters les applications ajoutées individuellement. Lors d’une migration vers SFOS 20.0 MR1 ou une version ultérieure, SFOS supprime les occurrences plus anciennes ; si le nettoyage automatique échoue en raison d’un espace de stockage insuffisant, Sophos recommande de contacter le support.

New désigne les nouvelles entrées, Mapped les applications associées automatiquement et Customized les entrées adaptées manuellement. Sous Manage > More options, les actions suivantes sont disponibles :

• Customize: attribuez un nom explicite et une catégorie appropriée, puis cliquez sur Apply ;
• Acknowledge: remplacez le libellé New par Customized sans modifier le nom ni la catégorie ;
• Hide et Show: masquez l’entrée ou affichez-la de nouveau ;
• Delete: supprimez l’application ainsi que son référencement dans les Application Filters qui l’utilisent.

Après Customize ou Acknowledge, l’application vérifiée est ajoutée à un Application Filter nouveau ou existant. Ce filtre est ensuite associé à la règle de pare-feu qui a effectivement été appliquée. Lancez alors un flux de test reproductible et vérifiez dans le Log Viewer la Rule ID attendue, le nom de l’application et l’action. Ce n’est qu’après cette phase pilote que la détection peut être convertie en règle Allow ou Deny de production.

Une entrée supprimée réapparaît si un Endpoint la signale de nouveau. Avant d’utiliser Delete, vérifiez donc les filtres concernés ; effectuez ensuite un nouveau flux de test et contrôlez la Rule ID attendue. Pour l’IA générative, Détecter et contrôler l’IA générative avec Sophos Firewall présente une procédure pilote dédiée.

Diagnostiquer les erreurs selon leurs symptômes

• La Rule ID attendue est absente : vérifiez l’ordre des règles, Source/Destination, Service, la correspondance de l’utilisateur et le chemin IPv4/IPv6. Tant que le flux correspond à une autre règle, l’Application Filter n’est pas en cause.
• Aucune entrée finale dans le journal du pare-feu : recherchez d’abord la session ouverte sous Current activities > Live connections, puis fermez-la de manière contrôlée. Vérifiez la journalisation et la période de filtrage dans Log Viewer.
• L’application reste unknown ou générique : vérifiez l’état des patterns, Application list, le déchiffrement HTTPS, QUIC et les Web Exceptions. Packet Capture sert uniquement à confirmer le chemin réseau.
• Le blocage affecte trop de services : limitez la règle basée sur Risk, Category, Classification ou Smart Filter à des applications individuelles ou à un groupe plus restreint. Répétez ensuite le test de blocage et la requête de contrôle.
• Davantage d’applications sont bloquées après une mise à jour des patterns : identifiez la nouvelle signature qui correspond à un critère dynamique. Créez une exception précise pour l’application requise au lieu de désactiver l’ensemble du filtre.
• Log Viewer indique Allowed pour le pare-feu, mais le navigateur affiche une page de blocage : si le trafic passe par le proxy, consultez également le journal Web.
• Les détails d’une application cloud sont absents : vérifiez séparément la journalisation du pare-feu, le déchiffrement HTTPS et la Web Policy. Tous les mécanismes de transfert ne renseignent pas l’ensemble des champs détaillés.
• Les vidéos Facebook restent accessibles malgré une configuration complète : vérifiez la Rule ID, l’Application Filter, la Web Policy, les entrées actuelles de la catégorie, QUIC, Decryption, la CA du client et les Web Exceptions. Si le test reste reproductible, Sophos recommande de contacter le support comme étape d’escalade suivante.

Retour arrière et exploitation

Avant le pilote, consignez l’Application Filter, la Web Policy, l’état et la position de la règle, l’association NAT, le chemin TLS et les exceptions. Procédez au retour arrière dans l’ordre suivant :

1. Désactivez la règle pilote distincte ou, dans la règle existante, sélectionnez de nouveau l’Application Filter précédent ou None.
2. Rétablissez la position de règle consignée et uniquement l’association NAT appartenant sans ambiguïté à la configuration pilote.
3. À l’aide du client de contrôle, vérifiez que les nouvelles connexions utilisent l’ancienne Rule ID et retrouvent le comportement attendu.
4. Supprimez ensuite seulement les filtres ou objets pilotes devenus inutiles. Ne supprimez pas sans vérification les filtres partagés, les règles NAT ni les entrées de Synchronized Application Control.

En exploitation, consignez l’objectif, les règles de pare-feu attribuées, les critères dynamiques, les exceptions autorisées, l’Owner, la dernière modification et la date de révision. Pour une analyse centralisée, consultez Activer Central Firewall Reporting et Configurer Syslog et un SIEM sur Sophos Firewall.

Ne modifier la classification globale qu’avec Sophos Support

L’Application Filter d’une règle de pare-feu n’est pas la fonction globale Application Classification de la Device Console. Sophos déconseille de modifier ces commutateurs sans instruction du support. Commencez par consulter l’état sans le modifier :

system application_classification show
system application_classification microapp-discovery show

La classification globale est définie sur on par défaut, et microapp-discovery sur off. Si Sophos Support demande une modification, consignez l’état initial et le numéro de ticket. Les commutateurs documentés sont les suivants :

system application_classification on
system application_classification off
system application_classification microapp-discovery on
system application_classification microapp-discovery off

L’activation de microapp-discovery redémarre des services et interrompt le trafic. Après une modification autorisée, vérifiez les deux sorties show, un véritable flux applicatif et les journaux. Pour revenir en arrière, restaurez exactement l’état initial : appliquez on si la valeur précédente était on, ou off si elle était off, puis contrôlez de nouveau le résultat avec show. Pour les IoC de domaine, la classification globale influe également sur le contexte des Third-Party Threat Feeds.

Questions fréquentes