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, 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.

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 : l’autoriser uniquement pour l’administration ou le support et, si possible, avec une clé publique. Les administrateurs disposant du profil Administrator peuvent recevoir un accès CLI ; seul l’administrateur par défaut gère les paramètres et les clés publiques.
• 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.

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.

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. 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 Central.

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.
• SSL VPN utilise par défaut TCP ou UDP 8443.
• 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

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. Description: documenter l’objectif, le ticket et la date d’expiration prévue.
3. Rule position: pour une exception WAN spécifique, sélectionner Top et vérifier les chevauchements avec les autres règles.
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

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.

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éployer les modifications sans perdre l’accès

Les modifications de Device Access prennent effet immédiatement. 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 Central.
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 la source autorisée ne fonctionne pas après la suppression de l’autorisation étendue ou si une source bloquée peut toujours atteindre le service, rétablir immédiatement l’autorisation étendue via la voie d’administration indépendante. Corriger ensuite la règle ACL nouvelle ou contradictoire et répéter la procédure.

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.

Résolution des problèmes

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.

FAQ