Sécuriser l'accès Sophos Firewall : configurer Device Access

Sous Administration > Device access, Sophos Firewall définit depuis quelles zones les services locaux de la firewall sont accessibles. Il s’agit par exemple de HTTPS pour WebAdmin Console, SSH pour la CLI, Ping, DNS, User Portal, VPN Portal et d’autres services.

Cette zone est critique pour la sécurité. Les règles firewall normales contrôlent le trafic à travers la firewall. Device access contrôle le trafic vers la firewall elle-même. Si WebAdmin ou SSH est accessible depuis une zone non fiable, cela crée un accès de gestion direct à l’équipement de sécurité.

⚠️ WebAdmin, SSH et les portails ne devraient être accessibles que depuis des réseaux de confiance. En production, il est préférable de limiter l’accès à un réseau de management, une IP admin fixe, VPN ou Sophos Central Firewall Management.

Pourquoi Device Access n’est pas une règle firewall

Une règle firewall typique autorise ou bloque des connexions entre des zones, par exemple LAN vers WAN ou VPN vers Server. Device Access est différent : il concerne les services qui s’exécutent directement sur Sophos Firewall.

Exemples :

• Un admin ouvre https://172.16.16.16:4444.
• Un client utilise la firewall comme serveur DNS.
• Un système de monitoring ping la firewall.
• Un utilisateur ouvre User Portal ou VPN Portal.
• Un admin se connecte à la firewall par SSH.

Ce trafic ne cible pas un serveur derrière la firewall, mais la firewall elle-même. Il est donc contrôlé par la local service ACL.

C’est aussi la raison pour laquelle Device Access fait partie du hardening de base de chaque Sophos Firewall. Un jeu de règles LAN-to-WAN propre ne protège pas automatiquement les services de management et de portail de la firewall. Ces services doivent être vérifiés et limités séparément.

Comprendre les autorisations par zone

Dans la partie supérieure de Administration > Device access, on trouve une table avec les zones et les services. Lorsqu’un service est activé pour une zone, l’accès à ce service local est généralement autorisé depuis cette zone.

La table des zones est utile, mais assez large. Elle convient à des zones internes claires comme LAN, Management ou VPN. Dès qu’un service ne doit être accessible que depuis certaines IP admin, certains sites, pays ou destinations support, les Local service ACL exception rules sont préférables.

Exemples typiques :

Pour les Custom Zones, l’accès aux services locaux peut aussi être influencé par les paramètres de zone. Malgré cela, Device Access doit toujours être vérifié consciemment, car il constitue la vue centrale des services locaux de la firewall.

Quels services peuvent être limités par ACL Rules ?

Local Service ACL et ACL Exception Rules permettent de contrôler très finement les services locaux de la firewall. Ces services sont particulièrement importants :

Plus ces services sont accessibles depuis WAN, des réseaux invités, IoT ou des zones mal définies, plus la surface d’attaque augmente. L’objectif n’est pas de tout désactiver, mais de rendre chaque service accessible uniquement là où il est réellement nécessaire.

Définir les sources aussi précisément que possible

Une ACL Rule ne doit pas simplement autoriser Any. Les sources peuvent être définies très précisément, par exemple avec :

• des adresses IP admin individuelles
• des réseaux de management
• des IP ranges
• des IP lists
• des FQDN hosts
• des FQDN host groups
• des DNS hosts ou DNS groups
• des Country objects ou groupes de pays
• des réseaux VPN ou support dédiés

Cela permet de limiter l’accès beaucoup plus proprement. Exemple : si un service support externe vient seulement d’un FQDN fixe ou d’une plage IP définie, toute la zone WAN ne doit pas obtenir l’accès à HTTPS ou SSH. Si un système de monitoring a besoin de SNMP, un réseau serveur complet ne devrait pas pouvoir interroger SNMP sur la firewall.

Dans les scénarios Remote Access globaux, la délimitation est plus difficile. Certaines entreprises ne peuvent pas simplement autoriser SSL VPN ou VPN Portal depuis la Suisse, l’Allemagne ou un seul pays, car les utilisateurs travaillent dans le monde entier. Dans ce cas, il faut ajouter MFA, logging, paramètres de portail restrictifs et Threat Feeds.

Local Service ACL Exception Rule

Lorsqu’un service ne doit pas être activé pour toute une zone, on utilise une Local service ACL exception rule. Elle permet de définir très précisément qui peut accéder à quel service local.

Chemin :

1. Ouvrir Administration.
2. Sélectionner Device access.
3. Faire défiler jusqu’à Local service ACL exception rule.
4. Cliquer sur Add.

Une ACL Exception Rule se compose essentiellement de ces champs :

Pour l’accès WebAdmin depuis Internet, il ne faut jamais utiliser Any comme source. Sophos empêche volontairement l’accès WebAdmin depuis la zone WAN pour toutes les sources, car ce serait un risque élevé. Si l’accès WAN est vraiment nécessaire, il doit être autorisé uniquement via des IP source spécifiques, des réseaux définis, des objets FQDN ou d’autres sources strictes.

L’ordre est également important. Les ACL Exception Rules sont évaluées de haut en bas. Une règle Drop plus haute peut rendre une règle Accept ultérieure inefficace. À l’inverse, une règle Accept trop large peut contourner des restrictions prévues. L’ordre des règles doit donc être vérifié aussi soigneusement que pour les règles firewall.

Configuration de base recommandée

Pour de nombreux environnements de production, cette logique est pertinente :

• Autoriser HTTPS/WebAdmin uniquement depuis Management, admin VPN ou une IP admin fixe.
• Désactiver SSH par défaut et l’autoriser seulement au besoin via une ACL ciblée.
• Activer DNS uniquement dans les zones où les clients utilisent vraiment la firewall comme serveur DNS.
• Autoriser Ping pour les systèmes de monitoring internes, mais pas largement depuis WAN.
• Activer User Portal, VPN Portal et SSL VPN uniquement si nécessaire.
• Autoriser RED uniquement pour les sites ou sources où se trouvent réellement des appliances RED.
• Autoriser SNMP uniquement depuis le système de monitoring.
• Autoriser SMTP Relay uniquement pour des systèmes internes définis.
• Activer Dynamic Routing uniquement dans les segments où des protocoles de routing dynamiques sont utilisés.
• Vérifier MFA pour WebAdmin, VPN Portal et Remote Access.
• Utiliser Sophos Central Firewall Management si un accès de gestion externe sécurisé est nécessaire.

Traiter SSH avec une prudence particulière

SSH est très utile pour troubleshooting et support, mais ne doit pas rester largement ouvert. Pour SSH :

• Seul l’utilisateur admin peut se connecter par SSH.
• L’authentification par public key est recommandée.
• L’accès depuis WAN ne doit être autorisé que via des IP source fixes ou VPN.
• Après une analyse, vérifier si SSH est encore nécessaire.

Plus de détails : Se connecter à Sophos Firewall par SSH.

Bots, brute force et Threat Feeds

En pratique, les services trop ouverts sont très souvent découverts immédiatement par des bots. WebAdmin, User Portal, VPN Portal et SSL VPN sont particulièrement concernés. Même lorsqu’un service est protégé par mot de passe et MFA, les logins publics génèrent des tentatives d’attaque, du trafic brute-force, du bruit dans les logs et une charge inutile sur la firewall.

Cela ne signifie pas automatiquement qu’une attaque réussit. Mais cela montre que le service fait partie de la surface d’attaque publique. Moins il y a de sources capables d’atteindre le login, mieux c’est.

Lorsqu’un portail doit être accessible dans le monde entier, les filtres pays ou les IP source individuelles ne suffisent souvent pas. Dans ces environnements, nous recommandons aussi les Third-Party Threat Feeds. Les Threat Feeds fournissent en continu à la firewall des Indicators of Compromise actuels, par exemple des adresses IP, domaines ou URLs malveillants. Les scanners connus, botnets et attaquants peuvent ainsi être bloqués avant d’atteindre WebAdmin, VPN Portal, SSL VPN ou d’autres services publiés.

Plus de détails : Sophos Firewall Threat Feeds

Erreurs fréquentes

Vérifier une règle firewall au lieu de Device Access

Si WebAdmin, SSH, DNS ou Ping vers la firewall ne sont pas accessibles, une règle firewall normale n’aide pas. Le trafic ne traverse pas la firewall, il se termine sur la firewall elle-même. Il faut donc vérifier Administration > Device access.

Autoriser WebAdmin depuis trop de zones

WebAdmin ne devrait pas être accessible depuis chaque zone interne. Un réseau invité, IoT ou VoIP n’a généralement pas besoin d’accéder à l’administration de la firewall. Même en interne, des clients compromis doivent être envisagés. Un réseau de management séparé ou admin VPN réduit nettement ce risque.

DNS non activé pour la zone client

Si les clients doivent utiliser la firewall comme serveur DNS, DNS doit être autorisé pour la bonne zone. Sinon les clients atteignent l’IP de la firewall, mais ne reçoivent pas de réponse DNS. Inversement, DNS ne doit pas être autorisé depuis des zones où la firewall ne doit pas servir de résolveur DNS.

Confondre User Portal et VPN Portal

User Portal et VPN Portal sont deux services différents. Selon le concept Remote Access, il faut vérifier quel portail est réellement nécessaire. Souvent, un portail est activé parce qu’un utilisateur devait télécharger une configuration une fois, puis il reste ouvert pendant des années. Ces reliquats doivent être supprimés régulièrement.

Oublier le cas particulier du Web Proxy

Lorsque Web Proxy est utilisé, les requêtes HTTP et HTTPS peuvent sembler internes du point de vue du proxy. Cela peut influencer le contrôle des accès à WebAdmin, Captive Portal, VPN Portal ou User Portal. Dans les environnements avec proxy, il faut donc tester précisément quels accès sont réellement possibles.

Règle ACL trop large

Une ACL Exception Rule avec Source zone: Any, Source Network / Host: Any et Services: HTTPS, SSH n’est presque jamais une bonne idée. De telles règles contournent le gain de sécurité de l’exception ACL. Une petite règle claire avec une source définie et uniquement les services nécessaires est préférable.

Règle Drop mal positionnée

Si une règle Drop se trouve au-dessus d’une règle Accept, l’accès souhaité peut tout de même être bloqué. Avec les ACL Exception Rules, l’ordre est donc aussi important qu’avec les règles firewall.

SSL VPN et VPN Portal laissés trop ouverts

Remote Access doit souvent être accessible de l’extérieur. Il faut néanmoins vérifier si tous les pays, réseaux et groupes d’utilisateurs ont réellement besoin d’accès. Si aucune restriction de source stricte n’est possible, MFA, logging et Threat Feeds doivent être appliqués d’autant plus systématiquement.

Troubleshooting

Si un service local n’est pas accessible, l’ordre suivant aide :

1. L’IP de destination de la firewall est-elle correcte ?
2. Le client vient-il de la zone attendue ?
3. Le service est-il autorisé pour cette zone sous Administration > Device access ?
4. Existe-t-il une Local service ACL exception rule adaptée ?
5. Une règle ACL supérieure avec Drop correspond-elle ?
6. Le service est-il configuré sur un autre port ?
7. L’accès est-il vu différemment à cause de VPN, proxy ou NAT ?
8. Log Viewer montre-t-il une indication ?
9. Packet Capture voit-il la tentative de connexion sur l’interface ?

Pour les accès support, il peut être utile de créer une ACL Exception Rule ciblée et de la supprimer ou désactiver une fois l’intervention terminée.

Plus d’informations

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Se connecter à Sophos Firewall par SSH
• Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access