Sophos Firewall : Device Access et Local Service ACL

Sous Administration > Device access, on définit depuis quelles zones les services locaux de Sophos Firewall sont accessibles. Il s’agit notamment de HTTPS pour WebAdmin et l’API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal et VPN Portal.

Ces services aboutissent directement sur le pare-feu et constituent sa surface de gestion et de services. Si une autorisation est trop large, des bots, des clients internes compromis ou des attaquants externes peuvent accéder directement aux pages de connexion, à l’API et à SSH pour tester des identifiants, des vulnérabilités connues ou des erreurs de configuration. MFA et les mots de passe robustes restent importants, mais ils ne limitent pas l’exposition réseau : Device Access réduit la surface d’attaque avant la connexion et fait donc partie des premières mesures de hardening.

La source d’identité reste distincte. Si WebAdmin doit utiliser des identifiants TACACS+ centraux, TACACS+ pour les administrateurs Sophos Firewall explique la connexion du serveur, l’attribution locale du profil, la connexion pilote et l’accès de secours ; l’accessibilité HTTPS continue d’être limitée ici.

La destination de la connexion est déterminante :

• Tableau des zones Device Access : autorise de manière générale un service local du pare-feu depuis une zone.
• Local service ACL exception rule : autorise ou bloque un service local pour des sources, des destinations et des services précis.
• Règle de pare-feu : contrôle le trafic à travers le pare-feu, par exemple de LAN vers un serveur dans DMZ.

Par exemple, lorsqu’on ouvre https://172.16.16.16:4444, la connexion aboutit sur le pare-feu. Une règle de pare-feu normale ne remplace donc pas une autorisation Device Access.

⚠️ WebAdmin, SSH et les portails ne devraient être accessibles que depuis les réseaux qui en ont réellement besoin. Pour l’administration externe, un VPN d’administration, Sophos Central Firewall Management dans Sophos Fusion (connexion sur fusion.sophos.com), un réseau de gestion ou une exception ACL précise sont plus sûrs qu’une autorisation WAN étendue.

Deux cas particuliers peuvent contourner le tableau des zones pour les services HTTP et HTTPS :

• Web Proxy : les requêtes effectuées via le Web Proxy sont considérées comme internes et ne peuvent pas être contrôlées par zone source au moyen de Device Access. Toute personne autorisée à utiliser le proxy peut ainsi accéder à WebAdmin, Captive Portal, VPN Portal et User Portal, même si le service est désactivé pour sa propre zone.
• Port Sharing : si VPN Portal et SSL VPN utilisent le même port et le même protocole, VPN Portal devient accessible depuis toutes les zones d’accès SSL VPN. De plus, les paramètres sous Login security ne s’appliquent alors plus.

Ces deux chemins doivent être testés séparément lors de la validation. L’article général Hardening de Sophos Firewall replace Device Access dans la stratégie globale de durcissement du système.

Planifier les zones et les services locaux

Le tableau des zones convient à des autorisations de base claires, par exemple DNS depuis LAN, Ping depuis une zone de supervision ou HTTPS depuis un réseau de gestion. Si seule une adresse IP ou un petit réseau nécessite un accès, une ACL Exception Rule est plus précise.

Une zone regroupe des interfaces. Pour une zone personnalisée, l’accès aux services locaux peut aussi être autorisé ou bloqué sous Network > Zones. Avant toute modification, il faut donc identifier l’interface d’entrée réelle et sa zone. Il faut également préparer l’objet source précis, l’Interface Host requis comme destination et le port réellement utilisé par le service. Les IP Hosts existants se trouvent sous Hosts and services > IP host ; les Interface Hosts sont gérés via Network > Interfaces.

Lire la matrice par défaut comme point de départ

Une nouvelle configuration SFOS 22 autorise par défaut les services locaux depuis les zones suivantes. Cette matrice n’est pas un objectif de durcissement : une restauration, une migration, l’assistant et les modifications ultérieures peuvent produire un autre état, et les services inutiles sont supprimés après des tests positifs et négatifs.

Décisions courantes :

• HTTPS : autoriser WebAdmin et l’API uniquement depuis des réseaux de gestion ou des sources d’administration définies précisément.
• SSH: À autoriser uniquement pour l’administration ou le support, de préférence avec une clé publique. Pour SSH via le réseau, la méthode de connexion documentée dans SFOS 22/23 utilise le compte intégré admin ; une autorisation CLI accordée par un profil ne confirme pas la possibilité de se connecter en SSH avec un compte d’administrateur nominatif. Seul l’administrateur par défaut gère les paramètres de clé publique et les clés.
• DNS : l’autoriser uniquement pour les zones clientes internes qui utilisent le pare-feu comme résolveur DNS. DNS depuis WAN n’est pas un cas client normal.
• Ping/Ping6 : l’autoriser pour la supervision requise, pas de manière générale depuis des zones non fiables.
• SNMP : l’autoriser uniquement depuis le système ou le réseau de supervision ; la configuration est décrite dans Supervision matérielle par SNMP.
• RADIUS SSO : uniquement depuis l’expéditeur d’accounting fixe. RADIUS SSO avec accounting explique l’association entre l’adresse IP client et l’utilisateur.
• SSL VPN : ne l’exposer à l’extérieur que dans la mesure nécessaire, avec MFA, journalisation et un port et un protocole choisis délibérément.
• VPN Portal : depuis SFOS 20, il fournit Sophos Connect ainsi que les configurations IPsec et SSL VPN.
• User Portal : il donne notamment accès aux données personnelles, aux jetons OTP, à la quarantaine, aux exceptions et aux Policy Overrides, mais pas au téléchargement de la configuration VPN.
• RED, SMTP Relay et Dynamic Routing : les autoriser uniquement dans les réseaux prévus ou pour les pairs définis. Configurer PIM-SM sur Sophos Firewall montre comment vérifier cette limite pour les voisins multicast ; pour les petits domaines de routage IPv4, configurer RIPv2 sur Sophos Firewall explique l’autorisation séparée de la zone du peer et du trafic de données.

Le dialogue des services propose également AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy et Wireless Protection. Le fait qu’un service puisse être sélectionné ne recommande pas une autorisation étendue par zone ; chaque sélection nécessite un chemin client, peer ou d’administration précis. Les champs de recherche Source Network / Host, Destination host et Services recherchent aussi les attributs. La saisie de 53 permet par exemple de trouver le service DNS.

Depuis SFOS 22, WebAdmin, VPN Portal et User Portal prennent en charge TLS 1.3. Un chiffrement robuste ne réduit toutefois pas la surface d’attaque d’un service accessible inutilement.

Device Access détermine uniquement depuis quel réseau la console WebAdmin est accessible. Si la connexion doit utiliser Microsoft Entra ID, Entra ID SSO pour WebAdmin de Sophos Firewall explique l’association distincte des rôles et groupes Entra aux profils d’administrateur locaux.

De plus, restrict-admin-console-wan-access peut bloquer globalement l’accès WebAdmin depuis toutes les sources WAN. Contrôler les Advanced Firewall Settings en toute sécurité explique la logique enable/disable volontairement inversée et sa distinction avec la Local Service ACL.

Limiter précisément les sources

Une ACL Exception Rule prend en charge les sources Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list et Network. Les FQDN avec caractères génériques ne sont pas pris en charge.

WebAdmin ne doit pas être autorisé depuis WAN pour toutes les sources. SFOS ne permet pas de créer l’exception ACL lorsque Source Network / Host est défini sur Any ou que l’adresse IP source est 0.0.0.0. Cette restriction du produit ne rend pas automatiquement les autres grands réseaux sûrs. Une adresse IP d’administration fixe, un petit réseau de gestion ou un objet FQDN tenu à jour sont nettement plus sûrs. Pour les utilisateurs mobiles dont les adresses source changent, l’accès administratif devrait passer par un VPN ou Sophos Fusion.

Depuis SFOS 19.5 MR2, les autorisations WAN étendues pour WebAdmin et User Portal sont automatiquement désactivées après 90 jours consécutifs sans connexion réussie. Cela ne concerne pas les sources WAN spécifiques des ACL Exception Rules, qui doivent toujours être contrôlées régulièrement. Le Sophos Firewall Health Check facilite les revues périodiques des accès de gestion, de MFA et de la configuration.

Vérifier Web Proxy et Port Sharing au préalable

Avant le durcissement, il faut relever les ports et protocoles utilisés sous Administration > Admin and user settings ainsi que dans SSL VPN global settings.

• WebAdmin utilise par défaut TCP 4444, User Portal TCP 4443 et VPN Portal TCP 443.
• Dans SFOS 22/23, TCP 443 est la valeur par défaut documentée pour WAF ; relever toutefois les listeners WAF réellement configurés avant de rechercher des conflits.
• SSL VPN utilise TCP 8443 par défaut ; UDP peut également être sélectionné comme protocole.
• WebAdmin et User Portal ne doivent pas partager leur port avec d’autres services.
• VPN Portal et SSL VPN ne devraient pas utiliser le même port et le même protocole, sans quoi les restrictions de zone et Login Security ne fonctionneraient pas comme prévu.

Si le Web Proxy est actif, un test sans proxy ne suffit pas. La même requête vers un portail ou WebAdmin doit également être testée via le proxy explicite depuis une zone censée être bloquée.

Configurer Direct Web Proxy avec un fichier PAC explique comment limiter le listener proxy à un client pilote et valider cette exposition de manière contrôlée.

Créer une Local Service ACL Exception Rule précise

Avant un accès direct à WebAdmin depuis WAN : Dans la Device Console, utiliser d’abord la commande en lecture seule show advanced-firewall pour consigner la valeur réelle de restrict-admin-console-wan-access et le build installé. Pour SFOS 22/23, Sophos décrit enable comme un blocage de WebAdmin depuis toutes les sources WAN et comme la valeur par défaut ; ce défaut ne remplace pas la valeur précédente relevée. Les instructions ACL décrivent des exceptions WAN précises, mais ne clarifient pas leur priorité par rapport à cette restriction globale. Ne pas supposer que l’exception ACL ci-dessous suffit à rendre WebAdmin accessible depuis WAN. Avec enable, conserver la restriction et utiliser la voie d’accès autorisée et déjà testée par VPN d’administration, réseau de gestion ou Fusion. Si l’accès WAN direct est indispensable et que l’interaction n’est pas clairement établie pour le build installé, arrêter le changement d’accès WAN direct et clarifier ce point avec Sophos Support. Si un test positif échoue, vérifier d’abord ce prérequis au lieu d’élargir l’ACL.

Cet exemple ACL n’est pas une instruction pour régler le paramètre global sur disable. Modifier la restriction globale exige un changement autorisé séparément, avec une voie d’administration indépendante fonctionnelle, la valeur précédente réelle documentée, des tests propres depuis des sources WAN autorisées et bloquées, ainsi que le rétablissement exact de cette valeur précédente en cas d’interruption et à la fin d’un accès temporaire. Ne rien modifier si la valeur initiale ou la voie de récupération ne peut pas être déterminée de façon fiable. Mettre en œuvre l’exemple WAN précis ci-dessous uniquement après clarification de ces prérequis.

Une exception classique autorise WebAdmin depuis WAN uniquement pour une adresse IP de support fixe. Le chemin de menu est Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Rule position: pour une exception WAN spécifique, sélectionner Top et vérifier les chevauchements avec les autres règles.
3. Description: documenter l’objectif, le ticket et la date d’expiration prévue.
4. IP version: sélectionner la version correspondant à la source, généralement IPv4.
5. Source zone: WAN
6. Source Network / Host: sélectionner une adresse IP d’administration précise ou un objet restreint et tenu à jour.
7. Destination host: limiter ce champ à l’adresse ou à l’interface requise du pare-feu. Any étend les adresses ou interfaces de destination accessibles, et non les services sélectionnés sous Services.
8. Services: sélectionner uniquement HTTPS ; ne pas ajouter SSH par commodité.
9. Action: Accept

Les valeurs de l’exemple ne doivent pas être reprises sans adaptation. Pour un réseau d’administration interne, le même modèle peut employer Source zone: LAN ou une zone d’administration personnalisée, Source Network / Host: mgmt-net, l’Interface Host de l’IP d’administration comme Destination host, HTTPS et Accept. Pour exclure une source connue au sein d’une zone dont l’accès reste nécessaire, une règle distincte placée de manière appropriée utilise l’objet source précis, uniquement les services concernés et Drop. Un groupe de pays constitue tout au plus une limite réseau grossière, et non un substitut à une source d’administration fixe ou à un VPN.

Enregistrer ensuite la règle et effectuer un test depuis une source autorisée ainsi que depuis une source non autorisée. La position de la règle est importante : les règles situées plus haut peuvent influencer le résultat. En cas de chevauchement, il faut vérifier le comportement réel sur le pare-feu au lieu de le déduire uniquement de la liste.

Accès API

Trois conditions doivent être réunies pour l’accès API :

1. L’API est activée sous Administration > API access.
2. L’adresse source figure dans Allowed IP hosts.
3. Device Access autorise HTTPS depuis la zone concernée ou au moyen d’une exception ACL adaptée.

Depuis SFOS 22, la configuration de l’API se trouve sous Administration et prend en charge les objets hôtes IP pour les adresses, les plages et les réseaux. Jusqu’à 64 objets sont possibles. Une autorisation HTTPS étendue n’est pas nécessaire. La configuration complète est décrite dans Limiter de manière sécurisée l’accès API à Sophos Firewall.

Automatisation XML : réglage de zone, pas exception ACL

La documentation XML des zones de SFOS 22/23 place HTTPS et SSH sous Zone/ApplianceAccess/AdminServices/HTTPS et Zone/ApplianceAccess/AdminServices/SSH, respectivement. Il s’agit de l’accès aux services locaux au niveau d’une zone : ni d’une règle de pare-feu pour le trafic de transit, ni d’une Local service ACL exception rule limitée à une source précise. Modifier cette branche affecte l’accessibilité de l’administration depuis la zone ; cela ne limite pas l’accès à une seule adresse IP d’administration. Pour autoriser une source précise, l’exception ACL décrite ci-dessus reste la limite appropriée.

La documentation se contredit sur les valeurs : l’exemple XML indique Enable/Disable, tandis que le tableau commun des paramètres répète Enable et mentionne aussi 12 et 40. Cela ne permet pas d’établir un codage booléen ou numérique fiable. Avant toute écriture automatisée, clarifier la syntaxe pour le firmware installé ; cette explication de la hiérarchie n’est pas un modèle exécutable d’autorisation d’accès.

Zone/MemberPorts n’est pas non plus une instruction d’écriture : le commentaire de l’exemple XML indique explicitement que les ports membres sont en lecture seule. La ligne CSV facultative du tableau décrit leur affichage, pas une méthode de modification vérifiée. Avant toute modification automatisée d’une zone, tester une voie de récupération indépendante avec une session ouverte, puis vérifier les sources autorisées et bloquées comme décrit dans le déploiement ci-dessous.

Supprimer une zone personnalisée en toute sécurité

Supprimer une Local service ACL exception rule supprime uniquement cette exception, pas la zone désignée par son nom. Désactiver un service local ne supprime pas non plus une zone. Zones et interfaces explique les associations.

1. Sous Network > Zones, identifier le nom exact de la zone personnalisée qui n’est plus nécessaire en production et consigner son état précédent. Retired_Test est seulement un exemple, pas une cible de suppression à reprendre. D’abord, ouvrir une session et tester la voie d’administration indépendante décrite dans le déploiement ci-dessous ; elle ne doit dépendre ni de cette zone ni des interfaces ou règles à modifier.
2. Sous Network > Interfaces, examiner toutes les affectations à cette zone et, sous Rules and policies > Firewall rules, toutes les références comme Source zone ou Destination zone. Ne pas supprimer les interfaces ou règles nécessaires : les réaffecter à la zone restante prévue uniquement dans le cadre d’un changement autorisé et vérifier l’effet. Si des références doivent subsister ou si leur usage est incertain, conserver la zone et ses dépendances et arrêter la suppression. Ne pas supprimer en cascade des dépendances de production pour forcer l’opération.
3. Après clarification des dépendances seulement, supprimer exclusivement cette zone nommée. La documentation XML de SFOS 22/23 exige Name avec au maximum 60 caractères : d’abord A-Za-z1-9 (pas 0), puis A-Za-z0-9_. Cela n’établit ni la prise en charge de caractères génériques ni une suppression automatique en cascade ; aucune requête XML ni aucun dialogue de suppression non étayé n’est prescrit ici.
4. Ensuite, vérifier que seule la zone prévue manque, que les affectations d’interfaces et règles de pare-feu restantes sont correctes et que le trafic de transit nécessaire fonctionne toujours. Retester les services locaux depuis des sources autorisées et bloquées ainsi que la voie d’administration indépendante. En cas d’écart, arrêter et utiliser cette voie pour annuler sélectivement les changements documentés, pas élargir les autorisations.

Les statuts XML documentés sont 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) et 504 (ZoneFirewallRuleExists). Pour 503 ou 504, réexaminer les références d’interfaces ou de règles concernées au lieu de supprimer indistinctement les objets dépendants. 500 n’est pas un succès ; même 200 ne remplace pas la vérification finale.

DNS depuis le WAN

Une exception ACL pour DNS depuis WAN ne suffit pas à faire répondre le pare-feu aux requêtes DNS sur cette zone. Il faudrait également configurer un hôte DNS statique avec Publish on WAN sous Network > DNS. Cette configuration ne devrait être utilisée que pour un cas d’usage autoritatif précis ; elle ne doit pas transformer le pare-feu en résolveur récursif public. Configurer et tester les DNS Host Entries sur Sophos Firewall explique la délégation, la DNS Host Entry ainsi que les tests positifs et négatifs.

Détails opérationnels avant la modification

Après une mise à niveau ou une restauration depuis une version antérieure à SFOS 20, VPN Portal reprend l’ancien port de User Portal, y compris un port personnalisé. User Portal passe à 4443, ou à 65040 si ce port est occupé. Vérifier le port configuré plutôt que sa seule valeur par défaut avant de rechercher une autorisation ACL apparemment manquante. Les utilisateurs ou groupes de VPN Portal doivent aussi appartenir à une politique Remote Access adaptée ; l’accessibilité seule ne leur accorde pas d’autorisation.

Le listener WAF doit différer de VPN Portal par l’adresse IP WAN ou le port. Face à SSL VPN, un protocole différent suffit également : WAF et VPN Portal utilisent TCP, tandis que SSL VPN peut utiliser TCP ou UDP. La séparation des listeners n’est pas une autorisation ACL ; retester les services concernés après chaque changement de port.

Dynamic Routing autorise les mises à jour de routage vers le pare-feu, pas le trafic de données qui le traverse. L’activer pour la zone réelle du peer, pas automatiquement pour WAN. Dans l’exemple WAN avec deux pare-feu RIP, seul le côté autorisé reçoit les mises à jour ; l’autre les rejette et n’apprend pas les réseaux annoncés. Si des routes manquent d’un seul côté, vérifier la zone du peer aux deux extrémités, puis la configuration du protocole dans l’article de routage lié.

Le widget Messages du Control center peut signaler l’accès WAN à HTTPS et SSH. Vérifier les autorisations de zone et les exceptions ACL et limiter l’accès à un VPN ou à des hôtes et réseaux précis. Les messages ne peuvent pas être supprimés manuellement ; certains disparaissent lorsque leur condition est remplie. Leur disparition ne remplace pas les tests positifs et négatifs. Les messages concernant la clé principale, l’enregistrement, les licences, les rapports et le firmware relèvent de leurs procédures opérationnelles respectives, pas d’une règle ACL supplémentaire.

Déployer les modifications sans perdre l’accès

Les modifications de Device Access prennent effet immédiatement.

La voie de secours doit continuer à fonctionner après le changement de zone ou de port prévu. Un second onglet utilisant le même accès bloqué n’est pas indépendant. Avant de commencer, consigner les réglages précédents exacts et identifier la personne disposant d’un accès console ; ne pas intervenir à distance sans voie de récupération fonctionnelle. Lors d’une intervention à distance, une session doit déjà être ouverte et testée via la seconde voie d’administration avant la modification.

1. Documenter les autorisations de zone, les exceptions ACL, les ports et les services requis actuellement.
2. Ouvrir une voie d’accès indépendante, par exemple la console locale, le LAN de gestion, un VPN d’administration ou Sophos Fusion.
3. Pour les modifications importantes, disposer d’une sauvegarde récente et du Secure Storage Master Key.
4. Créer la nouvelle exception Accept précise sans supprimer encore l’autorisation étendue existante.
5. Tester l’accès autorisé comme référence. Tant que l’autorisation de zone étendue reste active, ce test ne prouve pas encore que la nouvelle exception s’applique.
6. Sous Diagnostics > Packet capture, définir un filtre précis pour la source, la destination et le port, puis activer Trace On.
7. Supprimer l’ancienne autorisation de zone étendue via la voie d’administration indépendante.
8. Effectuer immédiatement un test fonctionnel du service depuis la source autorisée. Une connexion TCP/TLS ou au service réussie et, généralement, Status: Consumed confirment le cas positif ; Reason: LOCAL_ACL ne doit pas nécessairement apparaître.
9. Tester le même service depuis une source non autorisée. Pour la tentative bloquée, Status: Violation et Reason: LOCAL_ACL sont généralement attendus.
10. Pour HTTP/HTTPS, tester également le chemin Web Proxy ; pour les portails, vérifier les zones d’accès SSL VPN.
11. Arrêter Packet Capture et vérifier les événements de service ou de connexion complémentaires dans Log viewer. L’ID de règle affiché dans Packet Capture est celui de la règle de pare-feu, et non celui de l’ACL Exception Rule, et peut être 0 pour le trafic local.
12. Documenter la règle, son objectif, le responsable, le ticket, la source, le service et la date de révision ou d’expiration.

Interruption et retour arrière : si l’accès autorisé échoue, utiliser la voie indépendante pour rétablir le dernier réglage modifié à sa valeur précédente documentée, puis retester l’accès. Si une source bloquée atteint toujours le service, ne pas élargir l’autorisation : examiner le proxy, Port Sharing et les règles ACL qui se chevauchent, puis limiter le chemin indésirable sans perdre l’accès de secours. Répéter les deux tests uniquement après correction.

Des exemples de documentation compacts facilitent les contrôles ultérieurs :

• HTTPS : règle admin-https-from-mgmt, source mgmt-net, objectif WebAdmin, contrôle trimestriel.
• SSH : source support-ip-temporary, objectif cas de support, suppression après la clôture du ticket.
• SNMP : source monitoring-server, objectif supervision du matériel et des interfaces, contrôle semestriel.
• SSL VPN : source WAN, objectif Remote Access, contrôle mensuel des logs.

Pour plusieurs pare-feu ou un cluster HA, il faut d’abord modifier un système offrant de bonnes possibilités de retour arrière. Le guide Configurer la haute disponibilité de Sophos Firewall aborde les changements de rôle et l’accès de maintenance.

Cas particuliers et protection supplémentaire

User Portal, VPN Portal et SSL VPN

Il faut d’abord déterminer quel portail est réellement nécessaire. Les clients et configurations VPN relèvent de VPN Portal ; User Portal propose d’autres fonctions destinées aux utilisateurs. La page Comparaison des portails Sophos Firewall fournit une vue d’ensemble.

Si un service Remote Access doit être accessible dans le monde entier, MFA, des groupes d’utilisateurs restrictifs et la journalisation sont plus importants qu’une restriction géographique inadaptée. La configuration est décrite dans MFA pour WebAdmin, VPN Portal et Remote Access. Il faut néanmoins éviter Port Sharing : l’authentification ne remplace pas un contrôle correct de l’accessibilité.

Les pages de connexion WebAdmin, User Portal, VPN Portal et SSL VPN accessibles publiquement sont rapidement détectées par les scanners et les bots. Même avec MFA, elles génèrent du trafic par force brute, du bruit dans les logs et une charge supplémentaire.

Si de nombreux échecs de connexion au VPN Portal ou des verrouillages de compte se produisent déjà, Protéger le VPN Portal de Sophos Firewall contre les attaques par force brute réunit le contrôle des logs, la vérification de l’identité, le confinement par ACL et le contrôle final dans une procédure de réponse à incident.

Si un portail doit rester accessible dans le monde entier, Sophos Firewall Threat Feeds avec l’action Block peut en plus bloquer des sources IPv4 malveillantes connues issues de Third-Party Feeds tels que Cybora, y compris pour le trafic destiné au pare-feu lui-même. Les IoC de domaine ou d’URL ne protègent pas une connexion contre une adresse IP source malveillante ; les sources IPv6 ne sont actuellement pas prises en charge. Les Threat Feeds constituent donc une protection supplémentaire et ne remplacent pas des ACL précises. L’article lié explique la configuration, les tests et l’allowlisting.

SSH et règles de support temporaires

SSH ne devrait être accessible qu’en cas de besoin depuis un réseau de gestion, via un VPN ou pour une adresse IP de support fixe. L’authentification par clé publique est préférable. L’exception ACL temporaire est supprimée après le cas de support ; il ne faut pas supposer l’existence d’un état désactivé qui n’a pas été confirmé dans l’interface actuelle. Des étapes supplémentaires sont disponibles dans Se connecter à Sophos Firewall via SSH.

Une autorisation CLI ne vaut pas autorisation de connexion SSH : Selon sa description pour SFOS 22/23, le profil Administrator accorde un accès complet à la CLI, sans préciser le transport. En revanche, le guide PuTTY de ces mêmes versions impose le nom d’utilisateur admin pour SSH via le réseau et exclut les autres noms d’utilisateur ; cela concerne également la connexion par mot de passe. On n’en déduit ici ni une capacité de connexion SSH pour les comptes d’administrateur nominatifs, ni une règle générale applicable à tous les accès CLI. La fonction Console de WebAdmin ouvre une console dans le navigateur via l’accès WebAdmin et ne constitue pas une preuve de connexion SSH via le réseau. La possibilité pour un compte nominatif donné d’utiliser cet accès dans le navigateur doit être vérifiée séparément en fonction de ses autorisations et du firmware installé. La gestion des clés, réservée à l’administrateur par défaut, constitue elle aussi une autorisation distincte et ne détermine pas quels comptes peuvent se connecter en SSH par mot de passe.

Vérifier la voie de secours réelle avant toute modification ACL : Pour la méthode documentée de connexion SSH via le réseau, utiliser le compte intégré admin avec ses identifiants actuels ou une clé configurée à cet effet. Se connecter par la voie choisie dans une nouvelle session, ouvrir la console nécessaire et consigner le compte, le transport et la version du firmware dans le dossier de changement ; l’accessibilité d’un port TCP ne suffit pas à elle seule. Un accès fonctionnel à Console dans le navigateur reste dépendant du chemin WebAdmin et ne constitue pas une voie de secours indépendante si ce chemin est bloqué. Si un compte nominatif est nécessaire comme voie de secours SSH ou si le comportement observé contredit le guide, arrêter la modification, conserver un accès autorisé déjà testé et clarifier avec Sophos Support le périmètre exact des comptes et des transports concernés. Ne pas élargir l’ACL ni multiplier les tentatives de connexion pour remplacer cette clarification.

Supprimer une exception expirée sous Administration > Device access > Local service ACL exception rule avec Delete sur la règle concernée, puis confirmer avec OK. Tester d’abord la voie d’administration à conserver ; ensuite, vérifier que l’ancienne source de support ne peut plus se connecter. Une date d’expiration consignée ici est une obligation de révision, pas la preuve d’une suppression automatique.

Résolution des problèmes

Si une connexion devient soudainement inaccessible, vérifier aussi Administration > Admin and user settings > Login security > Block login. Ce blocage par IP source dépend des échecs de connexion et peut toucher WebAdmin, CLI, VPN Portal et User Portal. Ce n’est pas une règle ACL. Les échecs CAPTCHA ne sont pas comptés comme ces tentatives de connexion. Examiner la durée de blocage configurée et les événements plutôt que d’autoriser HTTPS pour toute une zone ou de désactiver systématiquement la protection.

Si un service local n’est pas accessible ou bloqué comme prévu, vérifier les points suivants dans cet ordre :

1. Destination et port : l’adresse IP du pare-feu est-elle correcte et le service utilise-t-il le port attendu ?
2. Zone source : le client se connecte-t-il directement depuis la zone attendue, via un VPN ou via le Web Proxy ?
3. Tableau des zones : le service est-il autorisé pour cette zone sous Administration > Device access ?
4. Exceptions ACL : IP version, Source zone, l’objet source, Destination host, Service, Action et la position correspondent-ils ?
5. Port Sharing : VPN Portal et SSL VPN partagent-ils le même port et le même protocole ?
6. API : l’activation de l’API, Allowed IP hosts et HTTPS Device Access sont-ils cohérents ?
7. DNS : DNS est-il autorisé pour les clients internes ? La publication sur le WAN nécessite en outre Publish on WAN.
8. Logs : Log Viewer affiche-t-il des événements de service ou de connexion complémentaires ?
9. Packet Capture : démarrer la trace avant de répéter le test. L’accès autorisé doit fonctionner et affiche généralement Status: Consumed ; la tentative bloquée affiche généralement Status: Violation et Reason: LOCAL_ACL. L’ID de règle n’est pas celui de l’exception ACL. Le fonctionnement est expliqué dans Packet Capture sur Sophos Firewall.

Si WebAdmin ou un portail reste accessible malgré la désactivation de la zone source, tester en priorité Web Proxy et Port Sharing. Une règle de pare-feu supplémentaire ne résout pas ce problème.

Pour une traçabilité à long terme, utiliser Central Firewall Reporting ou Envoyer les journaux Syslog de Sophos Firewall à un SIEM.

Liste de contrôle opérationnelle

• WebAdmin n’est pas largement accessible depuis WAN ni depuis les zones invités, IoT ou VoIP.
• HTTPS, SSH et SNMP sont limités à des sources précises de gestion ou de supervision.
• User Portal, VPN Portal et SSL VPN ne sont actifs que si le modèle opérationnel les exige.
• VPN Portal et SSL VPN ne partagent pas le même port et le même protocole.
• L’accès par Web Proxy aux services HTTP/HTTPS locaux a été testé séparément.
• API access, Allowed IP hosts et HTTPS Device Access sont coordonnés.
• Les exceptions ACL temporaires comportent un objectif et une date d’expiration et sont supprimées après utilisation.
• Les sources autorisées et bloquées ont été testées ; les logs confirment le résultat.
• Les règles sont contrôlées régulièrement afin de détecter les sources obsolètes, les services inutiles et les exceptions Accept trop étendues.

Réserves sur les sources

STAS assure l’authentification des utilisateurs ; ce n’est ni un VPN ni un canal d’administration chiffré. L’autorisation de son service d’authentification ne remplace pas un accès d’administration protégé.

Les instructions conservées sur les clés SSH de SFOS 22/23 sont ambiguës : elles indiquent RSA/DSA avec au moins 2048 bits et citent ECDSA en excluant ED25519. N’en déduisez pas la prise en charge d’ED25519 et ne considérez pas DSA comme une recommandation. Avant l’enregistrement, confirmez l’algorithme pris en charge par le firmware réellement utilisé ; téléversez uniquement la clé publique et conservez une voie de récupération distincte. Une autorisation Device Access ne valide pas un algorithme de clé.

Adaptive Learning inclut aussi les URL des virus détectés, les noms/URL/adresses IP des menaces, les adresses IP sources et les applications utilisées. Les rapports HTTPS activés par défaut couvrent les données de l’appareil, du firmware et des licences (sans informations sur le propriétaire), l’état des fonctions/HA/gestion cloud, le nombre d’objets, les erreurs et les pourcentages d’utilisation CPU/mémoire/disque. Il s’agit d’une décision de transmission de données, pas d’un contrôle ACL. Sophos Assistant est activé par défaut ; pour le désactiver, décochez Turn on Sophos Assistant sous Administration > Admin and user settings, cliquez sur Apply, puis déconnectez-vous et reconnectez-vous. Cela ne désactive pas la télémétrie.

FAQ