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. Sophos documente une exception pour les installations isolées (air gap) : les signatures IPS et applicatives sont mises à jour même lorsque la protection IPS est désactivée.

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. Les rapports locaux ne sont pas disponibles sur les XGS 87/87w et XGS 88/88w ; utilisez les contrôles des journaux et des connexions sur ces modèles.

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. La procédure proxy ne prouve pas un blocage équivalent des vidéos Facebook via DPI ; validez une conception DPI distincte avec Sophos Support et des tests clients avant de vous y fier. 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.

Lors de la première utilisation, après l’enregistrement, vérifiez dans Sophos Fusion (anciennement Sophos Central) que Synchronized Application Control est activé et activez-le si nécessaire. Le domaine créé sur le pare-feu doit correspondre au domaine sélectionné sur l’Endpoint.

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 uniquement si Synchronized Application Control (SAC) est activé. La durée de conservation par défaut est de douze mois. Si une autre durée avait été configurée auparavant, elle est conservée. Si SAC est désactivé, SAC et le nettoyage automatique restent tous deux désactivés. 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.

Vérifier l’ensemble des choix et de la configuration d’exemple

Catalogue, modèles et blocages ciblés

Dans le catalogue, ouvrez Filter à côté du champ concerné ; sauf pour Name, choisissez une valeur dans la liste. Smart Filter recherche dans les noms et descriptions. Toute Application Filter Policy existante, même personnalisée, peut servir de modèle. Vérifiez ses règles et calendriers avant de la copier.

Les catégories décrivent différentes fonctions, pas automatiquement un niveau de sécurité :

• File transfer : transferts et envois ; Download applications : téléchargements, partage de fichiers, stockage et accélérateurs ; Storage and backup : stockage de fichiers, collaboration et stockage de mots de passe.
• Gaming : jeux et concours ; Streaming media : audio, vidéo et diffusion en direct ; Social networking : réseaux sociaux ; E-commerce : applications commerciales.
• Instant messenger : chat ; VoIP : téléphonie IP ; Conferencing : réunions virtuelles ; Web mail : messagerie dans le navigateur ; Desktop mail : clients de messagerie.
• General internet : notamment actualités, recherche, navigateurs, achats et espaces de travail ; General business : hébergement, collaboration, comptabilité et sauvegarde ; Mobile applications : applications de systèmes mobiles ; Software update : mises à jour des systèmes et applications.
• Infrastructure : par exemple DNS, DHCP, SMTP, MySQL, QUIC et TLS sur d’autres ports ; Network services : routage, démarrage, QoS et FTPS ; P2P : partage de fichiers entre pairs ; Proxy and tunnel : proxys et VPN ; Remote access : accès et bureau à distance ; Industrial control system : communications des bâtiments, de téléconduite et des processus.
• SyncAppCtl discovered : applications inconnues découvertes par SAC ; Sophos applications : applications Sophos associées par SAC ; System applications : services système associés par SAC, notamment Windows ou Linux ; Generative AI : applications et services d’IA.

Allow All autorise et Deny All rejette toutes les applications. Block filter avoidance apps bloque tunnels, proxys et applications contournant les politiques ; Block generally unwanted apps couvre notamment les transferts de fichiers, proxy/tunnel, applications à risque et P2P. Le P2P peut diffuser des logiciels malveillants ; le bloquer est pertinent sauf besoin professionnel approuvé. Les modèles à haut risque ciblent les niveaux 4/5 ou uniquement 5.

Pour un blocage individuel, filtrez Facebook Games sous Select Individual Application > Name, sélectionnez-le et enregistrez avec Action: Deny, Schedule: All the time. La même procédure convient à WhatsApp, Skype, LinkedIn ou Internet Download Manager. Pour des groupes, utilisez Category: Generative AI ou Category: P2P. L’exemple UltraVPN utilise Category: Proxy and Tunnel et PPTP Protocol ; cela ne garantit pas la détection de tous les tunnels VPN.

Pour Block_High_Risk_Apps, après enregistrement et réouverture, choisissez Add > Select All > Risk, sélectionnez High et Very High, confirmez avec OK, puis définissez Deny et All the time. Enregistrez la règle et la politique et attribuez celle-ci à la règle de pare-feu Block_High_Risk_Apps_Rule. Les nouvelles signatures correspondantes sont également incluses après les mises à jour des patterns. D’anciens exemples décrivent une politique vide permissive et la section Advanced ; pour SFOS 22/23, utilisez explicitement Allow All et vérifiez l’attribution sous Other security features, sans reprendre ces anciens détails sans contrôle.

Paramètres communs du pare-feu et du Web

Les exemples de transfert et de stockage utilisent une règle Accept de LAN vers WAN, Log firewall traffic, Rule group: None, During scheduled time: All the time et Rule position: Top. Réseaux sources, réseaux de destination et services sont définis sur Any ; l’exemple à haut risque utilise même Any pour les deux zones. Ces valeurs larges ne sont pas une recommandation pour le pilote : limitez la source au client de test, adaptez zones et services au chemin réel et placez volontairement la règle au-dessus de celle qui correspondrait autrement. Sans Match known users, la règle s’applique au trafic réseau correspondant indépendamment de l’utilisateur ; avec cette option, choisissez par exemple Marketing pour le stockage ou Open Group pour les transferts sous User or groups > Add new item. Remplacez ces noms par votre groupe approuvé ; le journal de test doit montrer la bonne association utilisateur.

Si nécessaire, Create linked NAT rule crée une règle avec Translated source (SNAT): MASQ ; l’exemple la place également sur Top. Enregistrez d’abord la règle NAT, puis celle du pare-feu. Dans un réseau existant, l’association NAT vérifiée auparavant reste déterminante.

Pour le stockage, activez la règle Web sous Status après avoir défini Block HTTP/Block HTTPS, puis enregistrez. Dans le chemin proxy, bloquez aussi QUIC, activez Scan HTTP and decrypted HTTPS et Decrypt HTTPS during web proxy filtering, puis distribuez la CA avant le test.

Pour Facebook, enregistrez la catégorie personnalisée sous Web > Categories > Add avec Classification: Unproductive et les valeurs Domain et Keyword indiquées plus haut. Sous Web > Policies > Add policy > Add rule, retirez All web traffic de Activities, sélectionnez la catégorie via Add new item > Web category, choisissez Apply selected items, vérifiez les actions de blocage HTTP/HTTPS et l’état activé, puis Save et, le cas échéant, Skip this step. Enregistrez toutes les correspondances Facebook videos dans l’Application Filter avec Deny et All the time. L’exemple proxy complet active aussi Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, Scan FTP for malware, Decrypt HTTPS during web proxy filtering et Block QUIC protocol. L’analyse FTP est une protection supplémentaire, pas une preuve du blocage vidéo. Une option au nom similaire ne suffit pas à établir que le chemin DPI a été testé comme équivalent ; si le blocage échoue, suivez le diagnostic et l’escalade au support décrits plus haut.

Terminer les opérations cloud et SAC

Après Classify, confirmez avec Apply ; après Traffic shaping, sélectionnez une politique existante et Save. Vous pouvez par exemple examiner les applications de réseaux sociaux unsanctioned sur une période donnée ou limiter le streaming vidéo.

Les applications SAC inconnues entrent initialement dans SyncAppCtl discovered ; les applications connues sont catégorisées automatiquement. Limitez la recherche, par exemple à System applications. Après Hide, les entrées apparaissent uniquement sous Hidden applications ; rétablissez-les avec Show. Customize reste disponible ultérieurement et définit le libellé sur Customized.

Clean up application database nécessite l’enregistrement auprès de Sophos Fusion/Sophos Central. Après une vérification quotidienne, SFOS supprime les anciennes applications par lots de 100 toutes les cinq minutes, y compris les entrées ajoutées individuellement aux politiques. Vérifiez leur utilisation avant de modifier la période ; la raccourcir n’est pas une solution de stockage sans risque. Sans Web Protection Subscription valide, SAC peut être configuré, mais pas utilisé.

Automatiser Application Control via la XML API

Les références XML pour SFOS 22/23 décrivent différents objets aux noms similaires. Une classification cloud n’est ni une règle de filtrage ni le commutateur global de la Device Console. Avant un appel en écriture, l’état existant et les politiques qui l’utilisent sont sauvegardés. L’accès, l’analyse des réponses et les nouvelles tentatives sécurisées sont expliqués dans Sécuriser l’accès à la XML API de Sophos Firewall. Les structures suivantes expliquent le contrat documenté, et non une requête testée sur un pare-feu.

Classifications cloud individuelles et multiples

ApplicationClassificationAssignment met à jour exactement une affectation : les deux champs obligatoires Application et Classification sont des chaînes. L’exemple de référence mentionne Facebook Website et New. Il ne s’agit pas d’un catalogue complet des classifications autorisées ; les valeurs de l’interface et leur casse ne sont pas automatiquement considérées comme des valeurs d’énumération de l’API.

ApplicationClassificationBatchAssignment utilise en revanche ClassAssignmentList avec des objets ClassAssignment répétés. Chaque objet contient les champs en minuscules app et class, et non Application et Classification. La structure documentée se présente par exemple ainsi :

<ApplicationClassificationBatchAssignment>
  <ClassAssignmentList>
    <ClassAssignment>
      <app>iCloud</app>
      <class>New</class>
    </ClassAssignment>
    <ClassAssignment>
      <app>iPlay Website</app>
      <class>New</class>
    </ClassAssignment>
  </ClassAssignmentList>
</ApplicationClassificationBatchAssignment>

Les noms sont des exemples de référence et sont remplacés par des applications réellement présentes. Le tableau des paramètres décrit ClassAssignmentList comme un tableau facultatif d’objets contenant plusieurs valeurs. Cela n’implique ni qu’une opération par lot vide soit pertinente, ni une garantie de traitement atomique, de restauration ou de statut par entrée. Après une modification, relire séparément chaque affectation demandée et ne vérifier l’effet d’un filtre de classification qu’avec du nouveau trafic. Pour l’opération par lot, la référence indique 200 avec Operation Successful. et 500 avec Operation Fail. ; pour l’opération individuelle, elle indique 200 et 500 avec les symboles non résolus Message.AppClassificationUpdateSuccess et Message.AppClassificationUpdateFail, respectivement.

Politique de filtrage : Template ou règles personnalisées

Pour ApplicationFilterPolicy, Template est prioritaire : s’il est fourni, le contrat documenté ignore DefaultAction et RuleList. Une requête contenant un Template et une règle Deny personnalisée ne constitue donc pas une combinaison fiable des deux variantes. Sans Template, la référence décrit DefaultAction avec Allow ou Deny et RuleList/Rule pour les règles personnalisées. La longueur maximale d’un caractère également indiquée contredit ces mots ; aucune valeur abrégée à un caractère n’en est déduite. L’exemple XML écrit AllowAll, tandis que l’interface affiche Allow All. Ne pas reprendre le texte de l’interface comme jeton API sans vérification.

À l’intérieur de Rule se trouvent SelectAllRule, les conteneurs de sélection ainsi que Action et Schedule. Les conteneurs sont CategoryList/Category, RiskList/Risk, CharacteristicsList/Characteristics, TechnologyList/Technology, ClassificationList/Classification et ApplicationList/Application. Dans l’exemple, SelectAllRule utilise Enable/Disable ; il s’agit d’un commutateur, et non de la valeur de liste d’une catégorie. Les cinq premières listes présentent SelectALL, tandis que la liste des applications présente SelectAll. Les commentaires de l’exemple indiquent qu’une sélection de tous les éléments ignore les autres entrées de la même liste. Ne pas normaliser les graphies ni en déduire une priorité non documentée entre différents critères. Le tableau des paramètres mentionne en outre Search comme chaîne de recherche ; ne pas le confondre avec le SmartFilter d’un Application Object.

Le nom de la politique est obligatoire, autorise UTF-8, mais pas les virgules, et comporte au maximum 60 caractères ; Description autorise au maximum 1000 caractères. MicroAppSupport mentionne True et False, mais ne prouve pas que le déchiffrement HTTPS est activé. Le tableau présente Action et Schedule comme des tableaux dont les doublons ne sont pas ignorés, tandis que l’exemple XML les présente pour chaque règle. Ne pas dédupliquer ni réordonner les listes de sa propre initiative. Après l’enregistrement, relire l’action par défaut, l’ordre, la sélection et le Schedule ; seuls l’affectation à la règle de pare-feu appropriée et le test côté client confirment le blocage souhaité.

Distinguer le QoS des catégories des objets SD-WAN

ApplicationFilterCategory identifie la catégorie existante au moyen du champ obligatoire Name ; ce nom de catégorie ne peut pas être modifié. Le champ obligatoire QoSPolicy au niveau de la catégorie doit être distingué de ApplicationSettings/Application/QoSPolicy : ce dernier appartient à l’application dont le Name figure dans le sous-objet correspondant. L’exemple présente également BandwidthUsageType avec Individual/Shared. Le contexte du partage de bande passante est ainsi visible, mais aucune règle complète de priorité entre l’affectation à la catégorie et l’affectation à l’application n’est démontrée. Vérifier les affectations QoS existantes et l’utilisation partagée ou individuelle souhaitée avant la modification ; le déroulement opérationnel est expliqué dans Application Traffic Shaping.

ApplicationObject fournit une sélection d’applications pour les routes SD-WAN basées sur les applications, et non une ApplicationFilterPolicy avec des règles Allow/Deny. Ses champs obligatoires sont Name et SelectAllRule (Enable ou Disable) ; le nom autorise UTF-8, aucune virgule et au maximum 80 caractères. L’exemple XML utilise les mêmes six conteneurs de sélection que ci-dessus, ainsi que SmartFilter comme chaîne de recherche. Là encore, il présente SelectALL pour les critères et SelectAll pour les applications. La sélection d’applications visible ne constitue pas l’identité de l’objet nommé : lors d’un Update, relire l’objet visé ; pour Delete, cette page Add/Edit ne constitue pas une preuve du contrat d’identification.

Pour Application object add et Application object edit, la référence attribue les mêmes codes à chacune :

Ces symboles ne sont pas des messages d’erreur rédigés en toutes lettres, et les codes ne sont pas automatiquement équivalents à des codes de statut HTTP. Consigner ensemble l’opération, le code et la réponse réelle. Avant un Retry, relire le nom de l’objet réellement enregistré et la sélection ; une erreur ambiguë ne doit pas conduire à créer un deuxième objet ou un objet de portée plus large. Pour Policy-Edit, la référence mentionne également 502 avec Message.AFPRecordExists, en plus de 200/Message.AFPUpdateSuccess et de 500/Message.AFPUpdateFail. Là encore, la signification du texte de message non résolu reste indéterminée ; un code de succès ne remplace ni le contrôle de l’état ni le test du trafic.

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