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

Le contrôle des applications sur Sophos Firewall identifie les applications indépendamment du simple port. Cela permet, par exemple, d’autoriser, de bloquer ou de journaliser spécifiquement les outils de contrôle à distance, les applications de tunneling, le streaming, le stockage cloud, les messageries ou les contournements de navigateur à risque.

L’utilité pratique n’apparaît que lorsque le contrôle des applications est actif dans la bonne règle de pare-feu, que l’application est réellement reconnue et que les journaux sont analysés. Une politique de filtre d’application enregistrée ne bloque rien à elle seule.

Réponse rapide

Le contrôle des applications est utilisé en deux étapes :

1. Sous Applications > Application filter, planifiez ou créez une politique de filtre d’application.
2. Dans la règle de pare-feu appropriée, sélectionnez Identify and control applications (App control) sous Other security features.

Dans les anciennes vues de navigation, cette section peut parfois se trouver sous Protect > Applications > Application filter. Ensuite, il faut vérifier avec un client de test réel si le trafic passe par cette règle et si l’application est correctement reconnue dans le Log Viewer. Pour le trafic chiffré, l’inspection TLS peut être cruciale, car sinon le pare-feu voit moins de détails selon l’application.

Quand le contrôle des applications est-il utile ?

Le contrôle des applications est particulièrement utile lorsque les ports seuls ne sont pas suffisamment significatifs. De nombreuses applications utilisent HTTPS, des cibles changeantes ou une infrastructure cloud. Une règle de port seule ne voit alors que 443, mais pas si derrière se cache un service commercial autorisé, un outil de contrôle à distance ou un stockage cloud indésirable.

Cas d’utilisation typiques :

• Bloquer TeamViewer, AnyDesk, Tor ou les outils proxy
• Restreindre le streaming ou les réseaux sociaux dans certains réseaux
• Contrôler le stockage cloud
• Limiter les messageries ou les jeux dans les réseaux invités ou scolaires
• Activer la reconnaissance des applications pour le reporting et l’analyse
• Préparer le Traffic Shaping pour les applications reconnues

Si l’objectif n’est pas la reconnaissance ou le blocage, mais la priorisation ou la limitation de la bande passante, il convient de configurer le Traffic Shaping des applications sur Sophos Firewall.

Prérequis

Avant la configuration, ces points doivent être vérifiés :

• licence appropriée avec Web Protection ou Application Control
• règle de pare-feu concernée connue
• Log firewall traffic est actif pour la règle de test
• application ou catégorie souhaitée clairement définie
• client de test et cible de test définis
• pour les applications HTTPS, il est clair si TLS Inspection doit être utilisée
• les signatures d’application et les mises à jour de patterns fonctionnent

Le statut de la licence est vérifié sous System > Administration > Licensing. Dans les bundles typiques de Sophos Firewall avec Web Protection, le contrôle des applications est inclus. La logique de licence concrète doit néanmoins être contrôlée avant l’introduction en production, surtout en cas de souscriptions expirées ou de licences d’essai.

Planifier le filtre d’application

Un bon filtre d’application n’est pas simplement une longue liste de blocage. Il faut d’abord clarifier ce que l’on souhaite atteindre.

• Bloquer les outils de contrôle à distance à risque: Bloquer des applications ciblées ou une catégorie
• Restreindre le Wi-Fi invité: Bloquer les catégories indésirables, laisser ouverts les services de base autorisés
• Seulement journaliser l’application: Utiliser d’abord Allow avec journalisation et rapports
• Éviter les faux positifs: Choix d’application plus restreint au lieu d’une catégorie large
• Prioriser une application critique pour l’entreprise: Combiner le contrôle des applications avec le Traffic Shaping

Pour les réseaux en production, un mode d’observation est souvent judicieux : activer d’abord le contrôle des applications, vérifier les journaux et les rapports, puis bloquer spécifiquement. Cela permet de voir quelles applications apparaissent réellement et si un blocage perturberait des processus légitimes.

Avec des critères larges, il faut aussi penser à la maintenance ultérieure. Les nouvelles applications sont automatiquement prises en compte dans les Application Filter Policies et les règles de pare-feu par les mises à jour de la base de signatures d’applications. Si une règle bloque par exemple toutes les applications High-Risk, une nouvelle signature High-Risk peut être bloquée plus tard sans modification manuelle supplémentaire de la policy. C’est voulu, mais cela doit être connu dans le processus de changement et de revue.

Planifier le déploiement en phases

Le contrôle des applications ne doit pas être activé d’un seul coup pour tous les réseaux. Un petit déploiement avec un groupe de test clair, une journalisation visible et une décision définie sur le moment où l’observation devient un blocage est préférable.

Un déroulement pratique :

• Inventaire: Découvrir quelles applications apparaissent réellement. Filtre d’application avec journalisation, sans blocage large pour l’instant
• Pilote: Vérifier des utilisateurs sélectionnés ou un réseau de test. Bloquer des applications à risque individuelles, contrôler étroitement l’ID de règle et les journaux
• Mise en production: Appliquer la politique confirmée au réseau cible. Activer le filtre dans la règle de production, documenter les exceptions
• Exploitation: Surveiller les effets et les effets secondaires. Vérifier régulièrement les rapports, le Log Viewer, le Central Reporting ou le Syslog

Avant la mise en production, il doit être clair quelles applications doivent rester autorisées. Cela inclut souvent les services de mise à jour, le support à distance, les outils de collaboration, le stockage cloud, la téléphonie ou les applications spécifiques à un secteur. Si ces dépendances ne deviennent visibles qu’après le blocage, le contrôle des applications peut rapidement apparaître comme un facteur perturbateur plutôt qu’une fonction de protection.

Pour l’acceptation, une courte liste de décisions est utile : quelle application est bloquée, quel groupe d’utilisateurs est concerné, quelle exception est autorisée, qui est le propriétaire fonctionnel et quand la politique sera-t-elle réexaminée ? Cette documentation est plus importante qu’un premier filtre parfait.

Distinguer Application Filter, Application Object et Shaping

Les termes sont proches, mais répondent à des besoins différents. Cette distinction évite beaucoup de recherches d’erreurs :

• Application Filter: définit quelles applications sont autorisées, bloquées ou journalisées. Typique pour les outils de contrôle à distance, le stockage cloud ou un mode d’observation.
• Application Object: regroupe des applications dans un objet. Utile pour des groupes réutilisables lorsque la même sélection est nécessaire plusieurs fois.
• Application-based Traffic Shaping: priorise ou limite les applications reconnues. Typique pour prioriser Teams, limiter le streaming ou brider le Wi-Fi invité.
• Synchronized Application Control: complète la reconnaissance applicative avec les données des systèmes Sophos Endpoint via Security Heartbeat. Cela aide surtout pour les programmes que le pare-feu ne reconnaîtrait sinon que de manière générique, voire pas du tout.

Pour une simple politique de blocage ou d’autorisation, l’Application Filter est le point d’entrée principal. Les Application Objects et le Traffic Shaping ne deviennent intéressants que lorsque la sélection d’applications doit être réutilisée ou que la bande passante doit être pilotée de manière ciblée.

Synchronized Application Control ne remplace pas des règles de pare-feu propres. Il nécessite Sophos Central, Security Heartbeat et une couverture Sophos Endpoint adaptée. Les applications nouvellement reconnues apparaissent dans des catégories propres comme SyncAppCtl discovered et ne doivent pas être bloquées aveuglément. Il faut d’abord vérifier, puis catégoriser, puis les intégrer dans l’Application Filter.

Les applications détectées reçoivent automatiquement une étiquette de statut : New pour les applications encore inconnues, Mapped pour les applications automatiquement associées à une catégorie et Customized pour les entrées ajustées manuellement. Sophos prend en charge Synchronized Application Control pour jusqu’à 15 000 applications et ne conserve que les cinq dernières occurrences par application et par terminal afin d’économiser de l’espace de stockage. Cette limite est particulièrement importante lorsqu’il faut retracer, à des fins d’investigation, la fréquence d’apparition d’une application sur un terminal.

Créer un filtre d’application

Chemin de menu :

Applications > Application filter

Dans les anciennes vues de navigation, le chemin peut apparaître comme Protect > Applications > Application filter.

Procédure :

1. Ouvrir Add.
2. Donner un nom explicite, par exemple Block_Remote_Control_Tools.
3. Choisir une policy existante comme template, par exemple une policy Allow-All comme point de départ pour des règles de blocage ciblées.
4. Enregistrer la policy.
5. Rouvrir la policy et ajouter une règle dans le filtre.
6. Sélectionner l’application, la catégorie, le risque, les Characteristics, la Technology, la Classification ou le Smart Filter.
7. Définir l’action, par exemple Deny ou Allow.
8. Définir le Schedule si la règle ne doit s’appliquer que temporairement.
9. Enregistrer la règle, puis enregistrer la policy.

Pour les catégories, il faut être prudent. Une catégorie large peut toucher plus d’applications que prévu. Pour les premiers tests, des applications individuelles ou des groupes bien définis sont souvent meilleurs qu’un grand bloc collectif.

Lors de l’ajout d’une règle, il existe deux méthodes de travail typiques. Select All avec des filtres convient lorsqu’un groupe entier est visé, par exemple Category File Transfer, Characteristics Transfer files et Technology Browser Based. Select Individual Application est préférable lorsque seules certaines applications comme AnyDesk, TeamViewer ou un service cloud précis sont concernées. Le Smart Filter recherche le nom et la description d’une application ; il ne remplace pas la vérification technique de la liste de résultats.

Le filtre Classification s’applique uniquement aux applications cloud. Si une cloud app est reclassifiée ultérieurement, Sophos Firewall met aussi à jour les règles basées sur cette Classification. Ces règles sont pratiques, mais plus dynamiques qu’une liste fixe d’applications individuelles.

Exemple : bloquer les transferts de fichiers basés sur navigateur

Un bon premier exemple consiste à bloquer les transferts de fichiers basés sur navigateur dans un réseau invité ou client. Il ne s’agit pas de bloquer globalement toute la catégorie File Transfer, mais de limiter la sélection aux transferts de fichiers basés sur navigateur.

Configuration dans l’Application Filter :

1. Ouvrir Applications > Application filter.
2. Créer une policy, par exemple Block_File_Transfer.
3. Choisir une policy Allow adaptée comme template.
4. Enregistrer la policy et la rouvrir.
5. Ouvrir Add pour une nouvelle règle de filtre.
6. Utiliser Select All et restreindre la sélection avec Category: File Transfer, Characteristics: Transfer files et Technology: Browser Based.
7. Définir Action sur Deny.
8. Définir Schedule sur All the time si aucune planification horaire n’est souhaitée.
9. Enregistrer la règle de filtre, puis enregistrer la policy.

Cet exemple est volontairement plus strict qu’un blocage global de toutes les applications File Transfer. Dans beaucoup d’entreprises, des services cloud, de mise à jour, de sauvegarde ou de collaboration légitimes seraient sinon concernés. Avant l’utilisation en production, le filtre doit être testé dans le Log Viewer avec de vrais clients.

Activer dans la règle de pare-feu

Le contrôle des applications n’a d’effet que si le filtre est sélectionné dans une règle de pare-feu.

Chemin de menu :

Protect > Rules and policies > Firewall rules

Procédure :

1. Ouvrir la règle de pare-feu par laquelle le trafic concerné passe réellement.
2. Ouvrir la section Other security features.
3. Sélectionner le filtre d’application sous Identify and control applications (App control).
4. Activer Log firewall traffic, au moins pour le test et l’acceptation.
5. Enregistrer la règle.
6. Tester avec un client défini.

L’ordre des règles est crucial. Si le trafic est déjà traité par une règle plus générale plus haut, il n’atteint pas la règle avec le contrôle des applications. La configuration dans le WebAdmin semble alors correcte, mais n’a aucun effet.

Si une nouvelle règle LAN-WAN est créée, NAT doit être considéré séparément. Les exemples Sophos utilisent souvent Create linked NAT rule avec MASQ pour un accès Internet simple. Dans des règles de production existantes, il ne faut toutefois pas créer de nouvelles règles NAT sans vérifier quelle règle SNAT/MASQ s’applique déjà à ce trafic.

Pour les policies Application Control basées sur les utilisateurs ou les groupes, la règle de pare-feu doit réellement matcher le contexte utilisateur. Match known users et une authentification fonctionnelle sont alors aussi importants que l’Application Filter lui-même. Sans contexte utilisateur, la policy ne s’applique qu’aux critères réseau, zones et services.

Pour les nouvelles règles, il faut aussi choisir consciemment entre IPv4 et IPv6. Application Control est activé dans la règle de pare-feu concernée. Si un client emprunte un autre chemin en IPv6 qu’en IPv4, le test peut sembler propre alors qu’une partie du trafic contourne la règle attendue.

Les bases concernant la source, la destination, les services, les fonctionnalités de sécurité et l’ordre des règles sont expliquées dans Comprendre et configurer en toute sécurité les règles de Sophos Firewall.

Vérifier consciemment la correspondance de règle

Avant l’enregistrement, la règle doit être lue comme un cas de test :

• Source zone et Source network: Le client de test doit réellement provenir de cette zone et de ce réseau
• Destination zone et Destination network: Les destinations larges peuvent fonctionner, mais sont plus difficiles à tracer
• Services: Pour le trafic web, TCP 80/443 est souvent pertinent ; QUIC utilise UDP 443
• Web policy, IPS et TLS Inspection: Plusieurs fonctions de sécurité peuvent influencer le même flux
• Log firewall traffic: Sans journalisation, l’effet est difficile à prouver dans le Log Viewer

Lorsque le contrôle des applications est introduit, la première règle doit de préférence être un peu plus étroite et facile à mesurer. Une très grande règle LAN vers WAN avec de nombreuses exceptions est beaucoup plus pénible à valider.

Inspection TLS et reconnaissance

Le contrôle des applications peut reconnaître certaines applications même sans inspection TLS complète. Pour de nombreux services HTTPS et cloud modernes, le pare-feu ne voit cependant que des informations limitées sans déchiffrement, telles que l’adresse IP, le SNI, les données de certificat, le nom d’hôte ou les métadonnées de connexion.

Cela ne suffit pas toujours pour une reconnaissance fiable. Si une application n’est pas reconnue comme prévu via HTTPS, il convient de vérifier :

• le trafic passe-t-il par la bonne règle de pare-feu ?
• le contrôle des applications est-il actif dans cette règle ?
• l’application est-elle fondamentalement reconnue par Sophos ?
• l’inspection TLS est-elle nécessaire et acceptable pour ce trafic ?
• y a-t-il du QUIC ou du HTTP/3 qui compliquent le contrôle ?
• des politiques Web, IPS ou DNS Protection s’appliquent-elles en plus ?

L’inspection TLS doit être introduite progressivement et avec des exceptions. La procédure appropriée est décrite dans Introduire correctement l’inspection TLS sur Sophos Firewall. Pour QUIC et HTTP/3, voir Bloquer correctement le protocole QUIC et HTTP/3 sur Sophos Firewall.

Tester l’effet

Après l’activation, il ne faut pas seulement attendre les retours des utilisateurs. Un test propre économise beaucoup de temps.

Procédure pratique :

1. Définir le client de test et l’IP source.
2. Démarrer consciemment l’application ou appeler la cible.
3. Dans le Log viewer, filtrer par IP source, destination, service et application.
4. Vérifier quelle ID de règle de pare-feu a été atteinte.
5. Vérifier si le contrôle des applications reconnaît l’application.
6. Noter Application ID, catégorie, action et Application Filter.
7. En cas de blocage, vérifier si le blocage est souhaité fonctionnellement.
8. En cas de reconnaissance incertaine, compléter avec Packet Capture, les journaux de service et, en cas de journalisation centrale, les champs Syslog.

Le contrôle des applications utilise souvent ips.log dans le chemin technique. L’attribution des journaux est expliquée dans Dépannage Sophos Firewall : Services et journaux. Pour la délimitation avec Log Viewer et Packet Capture, voir Tester une règle Sophos Firewall avec Log Viewer, Policy Test et Packet Capture.

Les événements Application Control apparaissent dans le Log Viewer comme événements Application ou Content Filtering. Pour l’acceptation, les éléments les plus importants sont Firewall Rule ID, utilisateur, application, catégorie, risque, action, source et destination. Pour l’évaluation Syslog ou SIEM, il faut aussi contrôler des champs comme fw_rule_id, application_name, application_filter_policy, application_category, application_risk, status et appresolvedby. Ce dernier aide à comprendre si l’application a par exemple été reconnue par signature, logique proxy ou Synchronized Application Control.

Passer de l’observation au blocage

Le passage d’une simple détection au blocage doit être volontaire. Dans de nombreux environnements, il est préférable d’utiliser d’abord le contrôle des applications comme outil d’observation et de reporting. Ensuite, seules les applications dont le risque, le groupe d’utilisateurs et la dépendance métier sont compris doivent être bloquées.

Avant un blocage, il faut vérifier :

• Quels utilisateurs, réseaux ou appareils utilisent réellement l’application ?
• Quelle règle de pare-feu et quelle Rule ID apparaissent dans Log Viewer ?
• L’application est-elle reconnue de manière fiable ou seulement comme catégorie générique ?
• Existe-t-il une utilisation métier légitime, des cas de support ou des outils éditeur ?
• L’application doit-elle être bloquée partout ou seulement dans les réseaux invités, scolaires, clients ou serveurs ?
• Qui valide une exception et quand sera-t-elle réexaminée ?

Une approche propre consiste à collecter d’abord les journaux, puis à bloquer une application individuelle ou un petit groupe, et ensuite à valider avec un client de test et Log Viewer. Si un blocage est trop large, il ne faut pas désactiver tout l’Application Filter, mais ajuster précisément l’application, la catégorie ou la position de règle concernée.

Si le contrôle des applications ne s’applique pas

En cas de problème, il ne faut pas désactiver immédiatement tout le filtre. Il faut d’abord vérifier où le processus se rompt.

• Aucune entrée de journal pour la connexion de test: La journalisation manque ou le trafic n’atteint pas la règle de pare-feu. Vérifier l’ID de règle, la zone source et Packet Capture
• Le Log Viewer affiche une autre ID de règle: Une règle plus générale se trouve plus haut. Corriger l’ordre des règles et les critères de correspondance
• L’application reste unknown ou générique: La reconnaissance ne suffit pas sans plus de contexte. Vérifier TLS Inspection, QUIC et les signatures d’application
• Le blocage touche trop de services: La catégorie ou le Smart Filter est trop large. Utiliser des applications individuelles ou des groupes plus petits
• Après une mise à jour de pattern, davantage d’éléments sont soudainement bloqués: Une règle large basée sur Risk, Category ou Classification touche de nouvelles signatures. Vérifier les critères de règle et le processus de changement.
• Les détails cloud app manquent: Sans HTTPS-Decryption ou sans Web Policy, les détails d’upload, de download et de type de fichier sont limités. Vérifier le Cloud-App-Reporting et le statut TLS.
• Le blocage ne fonctionne que pour certains clients: Règle, zone, groupe d’utilisateurs ou chemin de navigateur différent. Comparer le client de test, l’utilisateur et le chemin réseau
• IPv6 se comporte différemment d’IPv4: Règle IPv6 séparée, chemin DNS différent ou chemin navigateur différent possible. Tester consciemment les deux protocoles ou tenir compte d’IPv6 proprement dans le jeu de règles.

Le point de contrôle le plus important est l’ID de règle. Si la règle attendue n’est pas atteinte, la politique Application Control n’est presque jamais la véritable cause.

Traiter correctement les faux positifs

Si le contrôle des applications bloque un trafic légitime, il ne faut pas désactiver immédiatement tout le filtre.

Ordre logique :

1. Documenter l’application concernée et l’entrée de journal.
2. Vérifier quelle règle de pare-feu et quel filtre d’application sont impliqués.
3. Vérifier l’application, la catégorie et l’action dans le filtre.
4. Vérifier si l’application est reconnue différemment par l’inspection TLS.
5. Définir l’exception aussi étroitement que possible : application, réseau source, groupe d’utilisateurs ou cible.
6. Documenter le propriétaire et la date de révision pour l’exception.

Une exception pour Any ou une catégorie large résout souvent rapidement le cas actuel, mais affaiblit le contrôle de manière durable. Mieux vaut une petite exception traçable avec une justification claire.

Erreurs typiques

• Filtre d’application créé, mais non sélectionné dans la règle: Aucun effet sur le trafic. Activer le filtre dans la véritable règle de pare-feu
• Le trafic passe par une autre règle: Le filtre n’est jamais atteint. Vérifier l’ID de règle dans le Log Viewer
• Catégorie trop large bloquée: Services cloud ou commerciaux légitimes affectés. Utiliser des applications individuelles ou des groupes plus restreints
• Filtres dynamiques mal compris: Risk, Category ou Classification peuvent produire de nouveaux matches après des mises à jour de signatures et de cloud apps. Contrôler régulièrement.
• Reconnaissance HTTPS surestimée: L’application n’est pas reconnue de manière fiable. Vérifier l’inspection TLS et le comportement QUIC
• Journalisation manquante: L’effet reste invisible. Activer la journalisation des règles pour le test et l’exploitation
• Exception trop large: La fonction de protection est pratiquement annulée. Définir une exception étroite et avec une date de révision

Vérification opérationnelle

Le contrôle des applications doit être vérifié régulièrement. Les applications changent, les services cloud utilisent de nouveaux points de terminaison, les utilisateurs utilisent de nouveaux outils et les signatures sont mises à jour.

Il faut documenter :

• Objectif du filtre d’application
• Règles de pare-feu concernées
• Applications bloquées ou autorisées
• Exceptions connues
• Propriétaire fonctionnel
• Date de révision
• Dernière modification pertinente

Si le contrôle des applications est utilisé pour des applications commerciales critiques, des réseaux scolaires ou des exigences de conformité, il convient également de vérifier le Central Reporting, le Syslog ou le SIEM. Pour une évaluation centrale, voir Activer le Central Firewall Reporting ou Configurer le Syslog et le SIEM sur Sophos Firewall.

Liste de contrôle

• Statut de la licence vérifié.
• Règle de pare-feu concernée clairement identifiée.
• Filtre d’application créé avec un objectif clair.
• Template, filtres dynamiques et critères de règle documentés.
• Filtre sélectionné dans la bonne règle de pare-feu.
• Journalisation des règles active.
• Client de test et application de test définis.
• Log Viewer vérifié pour l’ID de règle et le contrôle des applications.
• Utilisation réelle, owner et règle d’exception clarifiés avant le blocage.
• Chemin IPv4 et IPv6 vérifié si les deux sont actifs dans le réseau.
• Inspection TLS et QUIC évalués si la reconnaissance HTTPS est incertaine.
• Cloud-App-Reporting vérifié si nécessaire avec HTTPS-Decryption et Web Policy.
• Exceptions documentées de manière étroite.
• Date de révision fixée.

Questions fréquentes