Sophos Firewall : sécuriser Device Access

Dans Administration > Device access, vous définissez à partir de quelles zones les services locaux de Sophos Firewall sont accessibles. Cela inclut par exemple HTTPS pour la console WebAdmin, SSH pour la CLI, Ping, DNS, User Portal, VPN Portal et d’autres services.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

Cette section est critique pour la sécurité. Les règles de pare-feu normales contrôlent le trafic à travers le pare-feu. Device access contrôle le trafic vers le pare-feu lui-même. Si WebAdmin ou SSH sont accessibles depuis une zone non sécurisée, cela crée un accès direct à la gestion de l’appareil de sécurité.

L’API est également importante : l’autorisation Device Access pour HTTPS/WebAdmin s’applique aussi aux accès API. Depuis SFOS 22, les sources d’accès API sont en plus gérées sous Administration > API access, mais un hôte API autorisé ne sert à rien si Device Access bloque l’accès HTTPS local depuis cette zone.

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

En pratique, cette distinction aide:

• Tableau des zones Device Access : autoriser ou bloquer globalement un service par zone, par exemple DNS pour LAN, Ping pour une zone de supervision ou SSL VPN pour une zone Remote Access nécessaire.
• Local Service ACL Exception Rule : contrôler plus finement l’accès selon la source, la destination et le service, par exemple WebAdmin uniquement depuis le réseau de gestion, SSH uniquement depuis une IP de support ou SNMP uniquement depuis le système de supervision.
• Règle de pare-feu normale : autoriser ou bloquer le trafic à travers le pare-feu, par exemple lorsqu’un client de LAN accède à un serveur en DMZ ou à un service internet.

Cela clarifie le point suivant: une règle de pare-feu ne remplace pas le durcissement de Device Access. Si HTTPS ou SSH est accessible trop largement via Device Access, un client atteint le service local du pare-feu avant même qu’une règle de transit classique soit le bon point de contrôle.

Pourquoi Device Access ne fonctionne pas comme une règle de pare-feu

Une règle de pare-feu typique permet ou bloque les connexions entre les zones, par exemple de LAN à WAN ou de VPN à Server. Device Access est différent : il concerne les services qui fonctionnent directement sur Sophos Firewall.

Exemples :

• Un administrateur ouvre https://172.16.16.16:4444.
• Un client utilise le pare-feu comme serveur DNS.
• Un système de surveillance ping le pare-feu.
• Un utilisateur ouvre le User Portal ou le VPN Portal.
• Un administrateur se connecte en SSH au pare-feu.

Ce type de trafic ne cible pas un serveur derrière le pare-feu, mais le pare-feu lui-même. C’est pourquoi il est contrôlé par la Local Service ACL.

C’est aussi la raison pour laquelle Device Access fait partie du renforcement de base de chaque Sophos Firewall. Un ensemble de règles propre pour LAN-à-WAN ne protège pas automatiquement les services de gestion et de portail du pare-feu lui-même. Ces services doivent être vérifiés et restreints séparément.

Comprendre les autorisations de zone

Dans la partie supérieure de Administration > Device access, vous voyez un tableau avec des zones et des services. Si un service est activé pour une zone, l’accès à ce service local est généralement autorisé depuis cette zone.

Le tableau des zones est pratique, mais grossier et convient aux zones internes claires, comme LAN, Management ou VPN. Dès qu’un service doit être accessible uniquement pour certaines adresses IP admin, emplacements, pays ou objectifs de support, les Local service ACL exception rules sont un meilleur choix.

Pour les Custom Zones, il faut aussi vérifier les paramètres de zone. Les services locaux peuvent également y être influencés. Administration > Device access reste toutefois l’emplacement central où l’on autorise ou restreint consciemment les services locaux du pare-feu.

Exemples typiques :

• HTTPS : accès WebAdmin depuis le réseau de gestion. Ne pas l’autoriser largement depuis WAN.
• SSH : accès CLI pour les administrateurs ou le support. Autoriser uniquement de manière ciblée, de préférence avec clé publique.
• Ping/Ping6 : supervision et tests simples de disponibilité. Ne pas activer inutilement depuis des zones non sécurisées.
• DNS : les clients utilisent le pare-feu comme résolveur DNS. Activer uniquement pour les zones client internes.
• SSL VPN : les utilisateurs SSL VPN établissent une connexion au pare-feu. Ouvert à l’extérieur uniquement si nécessaire et sécurisé avec MFA ; vérifier séparément le port dans la zone Remote Access.
• User Portal : les utilisateurs téléchargent des configurations VPN ou des tokens. De préférence accessible via VPN/ZTNA ou très strictement limité.
• VPN Portal : utilisateurs VPN Remote Access. Seulement si vraiment nécessaire et sécurisé avec MFA.
• RED : les appliances RED se connectent au pare-feu. Autoriser uniquement pour de vrais sites RED ou des sources définies.
• SMTP Relay : les systèmes internes utilisent le pare-feu comme relais SMTP. Ne pas l’exposer comme relais ouvert depuis des zones non sécurisées.
• SNMP : la supervision interroge les valeurs du pare-feu. Autoriser uniquement depuis le système de supervision ; les détails se trouvent dans Surveillance matérielle SNMP.
• Dynamic Routing : protocoles de routage entre routeurs et pare-feu. Activer uniquement dans les segments réseau prévus à cet effet.

Dans SFOS 22, WebAdmin, VPN Portal et User Portal prennent en charge TLS 1.3. C’est positif pour le chiffrement, mais cela ne change pas le principe de base : un service accessible depuis trop de sources reste une surface d’attaque inutile. Le chiffrement du transport ne remplace pas une ACL propre.

Quels services peuvent être restreints par les règles ACL ?

Grâce à la Local Service ACL et aux ACL Exception Rules, vous pouvez contrôler très finement les services locaux du pare-feu. Ces services sont particulièrement pertinents :

• DNS : le pare-feu répond aux requêtes DNS provenant de réseaux qu’il ne devrait pas desservir.
• Dynamic Routing : les protocoles de routage sont accessibles depuis des segments incorrects.
• HTTPS : la console WebAdmin est accessible depuis trop de sources.
• Ping/Ping6 : le pare-feu est inutilement visible et scannable.
• RED : les services RED sont accessibles depuis des zones sources trop larges.
• SMTP Relay : les mauvaises configurations peuvent favoriser l’abus de relais.
• SNMP : les données de supervision sont interrogeables depuis des réseaux incorrects.
• SSH : l’accès direct à la CLI du pare-feu est trop ouvert.
• SSL VPN : les points de connexion VPN sont accessibles dans le monde entier et sont scannés.
• User Portal : le login au portail et les téléchargements VPN sont inutilement exposés.
• VPN Portal : le portail Remote Access est la cible de bots et de tentatives de force brute.

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

Définir les sources d’accès aussi précisément que possible

Une règle ACL ne doit pas simplement autoriser Any. Vous pouvez travailler très finement avec des sources, par exemple :

• adresses IP admin individuelles
• réseaux de gestion
• plages IP
• listes IP
• hôtes FQDN
• groupes d’hôtes FQDN
• hôtes DNS ou groupes DNS
• objets pays ou groupes de pays
• réseaux VPN ou de support dédiés

Cela permet de limiter beaucoup mieux un accès. Par exemple : si un service de support externe provient uniquement d’un FQDN fixe ou d’une plage IP définie, la zone WAN entière ne devrait pas avoir accès à HTTPS ou SSH. Si un système de surveillance a besoin de SNMP, un réseau de serveurs complet ne devrait pas pouvoir interroger SNMP sur le pare-feu.

Dans les scénarios d’accès à distance mondiaux, la délimitation est plus difficile. Certaines entreprises ne peuvent pas simplement autoriser SSL VPN ou VPN Portal uniquement pour la Suisse, l’Allemagne ou un seul pays, car les employés voyagent dans le monde entier. Dans ces cas, il est conseillé de travailler également avec MFA, journalisation, paramètres de portail restrictifs et Threat Feeds.

Modèle de décision pour les services locaux

Pour chaque service local, il faut décider consciemment quel niveau d’accès est approprié. Il est rarement judicieux de traiter WebAdmin, SSH, User Portal, VPN Portal, DNS et SNMP de la même manière.

• Désactivé : pertinent lorsque le service n’est pas nécessaire dans l’environnement. Exemple : SSH désactivé en permanence si aucun accès CLI n’est prévu.
• Zone interne uniquement : pertinent lorsque le service est nécessaire pour de nombreux clients internes. Exemple : DNS depuis LAN, si les clients utilisent le pare-feu comme résolveur DNS.
• Réseau de gestion : pertinent pour les services administratifs ou liés à la supervision. Exemple : HTTPS, SSH et SNMP uniquement depuis Management.
• VPN admin : pertinent si les administrateurs doivent travailler à distance, mais pas directement depuis Internet. Exemple : WebAdmin accessible uniquement via VPN.
• ACL Exception Rule : pertinent si l’accès doit provenir d’une source très concrète. Exemple : une IP de support peut accéder temporairement à HTTPS ou SSH.
• Largement accessible depuis WAN : uniquement pour de vrais services Remote Access et avec protection supplémentaire. Exemple : SSL VPN pour utilisateurs mobiles avec MFA, journalisation et Threat Feeds.

Cette décision doit être documentée. Surtout pour les exceptions depuis WAN, il doit être possible de comprendre plus tard pourquoi le service est accessible, qui en a besoin et quand l’exception sera réexaminée.

L’accès WAN est une exception

WAN n’est pas simplement une autre zone. Tout ce qui est accessible depuis WAN est trouvé par des scanners, des bots et des outils de force brute. C’est pourquoi WebAdmin ne devrait pas être planifié comme une variante normale d’exploitation depuis WAN.

Si un accès de gestion externe est nécessaire, ces variantes sont généralement plus sûres :

• Sophos Central Firewall Management pour les tâches administratives.
• VPN admin avec MFA et groupe d’utilisateurs clair.
• Une règle d’exception ACL temporaire pour une IP source fixe.
• Un réseau de gestion dédié via VPN site-à-site.

Pour le renforcement général, Utiliser correctement le Sophos Firewall Health Check est également approprié, car il évalue les accès de gestion, MFA, sauvegardes et l’hygiène des règles ensemble.

Sophos protège en plus WebAdmin contre une exposition à toutes les sources WAN. Si l’accès WAN est vraiment nécessaire, il doit être limité à des sources spécifiques comme des IP individuelles, des réseaux ou des objets FQDN. Les anciennes autorisations larges provenant de configurations historiques doivent être vérifiées régulièrement : Sophos peut désactiver automatiquement certaines expositions WAN larges pour WebAdmin ou User Portal après une longue période d’inactivité, tandis que des exceptions ACL ciblées pour des sources WAN concrètes peuvent continuer à s’appliquer.

Local Service ACL Exception Rule

Si un service ne doit pas être autorisé pour une zone entière, utilisez une Local service ACL exception rule. Cela vous permet de définir très précisément qui peut accéder à quel service local.

Chemin :

1. Ouvrez Administration.
2. Sélectionnez Device access.
3. Faites défiler jusqu’à Local service ACL exception rule.
4. Cliquez sur Add.

Déroulement typique pour une exception admin stricte depuis le WAN :

1. Définir Rule name, par exemple admin-https-from-support-ip.
2. Placer Rule position sur Top si une règle Drop ou Allow existante pourrait sinon s’appliquer avant.
3. Choisir IP version selon la source, le plus souvent IPv4.
4. Définir Source zone sur WAN.
5. Définir Source Network / Host sur l’IP admin concrète, un petit réseau admin ou un objet FQDN/IP maintenu.
6. Limiter Destination host à l’adresse du pare-feu ou à l’interface concernée, sauf si toutes les destinations locales sont volontairement visées.
7. Définir Services sur le service local nécessaire, par exemple HTTPS pour WebAdmin ou API, et non HTTPS plus SSH par confort.
8. Définir Action sur Accept.
9. Enregistrer et tester immédiatement depuis une source autorisée et une source non autorisée.

Une règle d’exception ACL se compose essentiellement de ces champs :

• Rule name : nom unique, par exemple admin-https-from-mgmt.
• Rule position : ordre des règles ACL.
• Source zone : zone d’où provient l’accès, par exemple WAN, LAN ou VPN.
• Source Network / Host : IP admin autorisée, réseau de gestion, hôte FQDN ou liste IP.
• Destination host : IP du pare-feu ou interface à laquelle on accède.
• Services : service local, par exemple HTTPS, SSH, Ping ou DNS.
• Action : Accept ou Drop.

Pour l’accès WebAdmin depuis Internet, vous ne devez jamais utiliser Any comme source. Sophos empêche consciemment l’accès WebAdmin depuis la zone WAN pour toutes les sources, car cela représenterait un risque élevé. Si l’accès WAN est vraiment nécessaire, il ne doit être autorisé que via des adresses IP sources spécifiques, des réseaux définis, des objets FQDN ou d’autres sources étroites.

Pour l’automatisation API, la même logique s’applique. Un hôte peut être autorisé sous Administration > API access et échouer tout de même si l’autorisation HTTPS manque sous Device Access. À l’inverse, une autorisation HTTPS ne doit pas devenir plus large simplement parce qu’un outil API est raccordé. Pour les détails API, voir Limiter en toute sécurité l’accès à l’API Sophos Firewall.

L’ordre est également important. Les règles d’exception ACL sont évaluées de haut en bas. Une règle Drop plus élevée peut rendre une règle Accept ultérieure inefficace. Inversement, une règle Accept trop large peut annuler des restrictions planifiées ultérieurement. L’ordre des règles doit donc être vérifié aussi consciemment que pour les règles de pare-feu.

Le Destination host est particulièrement important lorsque le pare-feu possède plusieurs interfaces, adresses alias, adresses VPN ou cibles séparées de portail/administration. Une règle doit viser aussi précisément que possible l’adresse du pare-feu qui doit réellement être administrée ou utilisée. Sinon, une autorisation source en apparence étroite peut soudain s’appliquer à davantage de services locaux ou d’interfaces que prévu.

Éviter le verrouillage avant le changement

Les modifications de Device Access affectent directement les accès de gestion et de portail. Par conséquent, avant toute restriction, il doit être clair comment revenir au pare-feu si une règle est mal appliquée.

Avant de sauvegarder une modification risquée, vérifiez :

• Un deuxième administrateur avec un profil de droits approprié est-il disponible ?
• Y a-t-il un accès via un autre réseau, par exemple Management-LAN, Admin-VPN ou Sophos Central ?
• Une accessibilité locale à la console ou hors bande est-elle disponible si WebAdmin n’est plus accessible ?
• Travaillez-vous actuellement sur un cluster HA où un changement de rôle peut modifier le chemin d’accès ?
• Le fichier de sauvegarde actuel, la clé maître de stockage sécurisé et l’accès d’urgence sont-ils documentés ?
• Y a-t-il une courte fenêtre de maintenance où les accès incorrects seront immédiatement remarqués ?

Surtout pour les sites distants, vous ne devez pas d’abord supprimer l’autorisation large, puis tester. Il est plus sûr de suivre le processus inverse : créer une nouvelle règle d’exception ACL étroite, tester l’accès autorisé, confirmer le deuxième chemin admin, puis seulement réduire l’ancienne autorisation de zone large.

Déployer les modifications en toute sécurité

Les modifications de Device Access peuvent exclure les administrateurs. Par conséquent, vous ne devez pas les modifier à la légère, mais les traiter comme une modification de gestion.

Processus éprouvé :

1. Documentez l’accès actuel : WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP et Ping.
2. Assurez-vous qu’un deuxième chemin admin est disponible, par exemple console locale, Admin-VPN ou Sophos Central.
3. Créez une sauvegarde avant de mettre en œuvre des modifications ACL majeures.
4. Créez une nouvelle règle d’exception ACL aussi spécifique que possible.
5. Testez l’accès depuis la source autorisée.
6. Testez l’accès depuis une source non autorisée.
7. Vérifiez le Log Viewer pour voir si les événements attendus sont visibles.
8. Supprimez l’ancienne autorisation de zone large uniquement lorsque le nouvel accès est confirmé.
9. Documentez la modification avec la date, la source, le service et le responsable.

Si plusieurs pare-feu ou clusters HA sont concernés, la modification doit d’abord être testée sur un système avec une bonne possibilité de retour en arrière. Pour les environnements HA, Configurer la haute disponibilité de Sophos Firewall est également approprié, car les accès de gestion, les changements de rôle et les fenêtres de maintenance doivent être considérés ensemble.

Contrôle après les modifications de Device Access

Après une adaptation, il ne suffit pas de vérifier uniquement votre propre accès WebAdmin. Vous devez tester à la fois les sources autorisées et non autorisées, sinon il reste incertain si le renforcement fonctionne vraiment.

• WebAdmin depuis le réseau de gestion : l’accès fonctionne comme prévu.
• WebAdmin depuis un réseau client normal : l’accès est bloqué, sauf autorisation explicite.
• SSH depuis le réseau admin : l’accès fonctionne uniquement si SSH est explicitement autorisé.
• SSH depuis WAN ou réseau invité : l’accès est bloqué.
• DNS depuis le réseau client : DNS fonctionne uniquement dans les réseaux qui doivent utiliser le pare-feu comme résolveur.
• User Portal ou VPN Portal : seuls les portails nécessaires sont accessibles.
• SNMP depuis le système de supervision : la supervision fonctionne, les autres sources sont bloquées.

Si un accès fonctionne de manière inattendue, vous ne devez pas seulement vérifier la règle d’exception ACL. Le tableau des zones dans la partie supérieure de Device Access, les paramètres de zone personnalisée, la zone VPN, le comportement du proxy et les règles Accept larges existantes peuvent également être la cause.

Pour la documentation, une courte liste par service suffit souvent :

• HTTPS : source autorisée mgmt-net, raison Accès admin WebAdmin, revue trimestrielle.
• SSH : source autorisée support-ip-temporary, raison Cas de support, revue après la clôture du ticket.
• SNMP : source autorisée monitoring-server, raison Surveillance matérielle et des interfaces, revue semestrielle.
• SSL VPN : source autorisée WAN, raison Remote Access, revue avec contrôle mensuel des logs.

Lors de chaque contrôle ultérieur, il faut aussi vérifier si les accès réussis et bloqués sont réellement visibles. Pour des tests courts, le Log viewer suffit souvent. Pour une conservation plus longue ou des questions d’audit, Central Reporting ou Syslog sont mieux adaptés, car les logs locaux peuvent tourner ou être perdus lors d’incidents.

Configuration de base recommandée

Pour de nombreux environnements de production, la logique suivante est judicieuse :

• Autoriser HTTPS/WebAdmin uniquement depuis Management, Admin-VPN ou une IP admin fixe.
• Autoriser API uniquement depuis des hôtes d’automatisation ou de monitoring définis et limiter aussi HTTPS de manière cohérente via Device Access.
• SSH désactivé par défaut et autorisé uniquement si nécessaire via ACL.
• Activer DNS uniquement dans les zones où les clients utilisent réellement le pare-feu comme serveur DNS.
• Autoriser Ping pour les systèmes de surveillance internes, mais pas globalement depuis WAN.
• Activer User Portal, VPN Portal et SSL VPN uniquement s’ils sont nécessaires.
• Autoriser RED uniquement pour les sites ou zones sources où des appliances RED sont réellement présentes.
• Autoriser SNMP uniquement pour le système de surveillance.
• Autoriser SMTP Relay uniquement pour les systèmes internes définis.
• Activer Dynamic Routing uniquement dans les segments de routage où les protocoles de routage dynamiques sont réellement utilisés.
• Vérifier MFA pour WebAdmin, VPN Portal et accès à distance ; l’installation est décrite dans Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et accès à distance.
• Utiliser Sophos Central Firewall Management si un accès de gestion externe sécurisé est nécessaire.

Pour une traçabilité plus longue, vous devez également vérifier la stratégie de journalisation. Les journaux locaux suffisent pour un dépannage immédiat, mais pas pour chaque question d’audit ou de réponse aux incidents. Si les accès au portail ou à la gestion doivent être traçables à long terme, Central Firewall Reporting ou Envoyer les journaux Sophos Firewall Syslog à SIEM sont des éléments plus appropriés.

Traiter SSH avec une prudence particulière

SSH est très utile pour le dépannage et le support, mais ne doit pas être ouvert en permanence. Pour SSH, il est conseillé :

• Seul l’utilisateur admin peut se connecter via SSH.
• L’authentification par clé publique est la méthode préférée.
• L’accès depuis WAN ne doit se faire que via des adresses IP sources fixes ou VPN.
• Après une analyse, vérifiez si SSH est toujours nécessaire.

Pour plus de détails, consultez le guide Connecter Sophos Firewall via SSH.

Bots, force brute et Threat Feeds

Dans la pratique, on constate très souvent que les services trop ouverts sont immédiatement découverts par des bots. WebAdmin, User Portal, VPN Portal et SSL VPN sont particulièrement concernés. Même si un service est protégé par mot de passe et MFA, les connexions publiques génèrent des tentatives d’attaque, du trafic de force brute, du bruit dans les journaux et une charge inutile sur le pare-feu.

Cela ne signifie pas automatiquement qu’une attaque réussie a lieu. Cela montre cependant que le service fait partie de la surface d’attaque publique. Moins il y a de sources qui peuvent atteindre la connexion, mieux c’est.

Si un portail doit être accessible dans le monde entier, les filtres par pays ou les adresses IP sources individuelles ne suffisent souvent pas. Dans ces environnements, nous recommandons également les Third-Party Threat Feeds. Les Threat Feeds fournissent au pare-feu des indicateurs de compromission à jour, tels que des adresses IP malveillantes, des domaines ou des URL. Les scanners, botnets et attaquants connus peuvent ainsi être bloqués avant d’atteindre WebAdmin, VPN Portal, SSL VPN ou d’autres services publiés.

L’article Sophos Firewall Threat Feeds explique la planification, la liste blanche et l’exploitation.

Erreurs fréquentes

Règle de pare-feu vérifiée au lieu de Device Access

Si WebAdmin, SSH, DNS ou Ping ne sont pas accessibles sur le pare-feu, une règle de pare-feu normale n’aide pas. Le trafic ne traverse pas le pare-feu, mais se termine sur le pare-feu lui-même. C’est pourquoi Administration > Device access doit être vérifié.

WebAdmin autorisé 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 à la gestion du pare-feu. Même en interne, il faut supposer que des clients compromis peuvent exister. Un réseau de gestion séparé ou un VPN admin réduit considérablement ce risque.

DNS non activé pour la zone client

Si les clients doivent utiliser le pare-feu comme serveur DNS, DNS doit être autorisé pour la zone appropriée. Sinon, les clients atteignent l’IP du pare-feu, mais ne reçoivent pas de réponse DNS. Inversement, DNS ne doit pas être autorisé dans les zones où le pare-feu ne doit pas être utilisé comme résolveur DNS.

User Portal et VPN Portal confondus

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

Si les portails doivent rester accessibles depuis Internet, il ne suffit pas de vérifier la case à cocher. MFA, groupes d’utilisateurs, processus de token/provisioning, expiration des utilisateurs temporaires, journalisation et nécessité durable du portail après le déploiement doivent aussi être clarifiés.

Cas particulier du proxy Web ignoré

Si le proxy Web est utilisé, les requêtes HTTP et HTTPS peuvent sembler internes du point de vue du proxy. Cela peut affecter la façon dont les accès à WebAdmin, Captive Portal, VPN Portal ou User Portal sont contrôlés. Dans les environnements avec proxy, vous devez donc tester très précisément quels accès sont réellement possibles.

Règle ACL trop large

Une règle d’exception ACL 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 véritable gain de sécurité de l’exception ACL. Il est préférable d’avoir une petite règle claire avec une source unique et les services nécessaires.

Règle Drop à la mauvaise position

Si une règle Drop se trouve au-dessus d’une règle Accept, l’accès autorisé peut quand même être bloqué. Pour les règles d’exception ACL, l’ordre est donc aussi important que pour les règles de pare-feu.

À l’inverse, une règle Accept large en haut de la liste peut rendre des règles Drop ultérieures pratiquement inutiles. Après chaque changement de règle, il faut donc vérifier non seulement la nouvelle règle, mais aussi la logique de matching des règles situées au-dessus.

SSL VPN et VPN Portal laissés trop ouverts

L’accès à distance doit souvent être accessible de l’extérieur. Cependant, vous devez vérifier si tous les pays, réseaux et groupes d’utilisateurs ont vraiment besoin d’accès. Si une limitation stricte des sources n’est pas possible, MFA, journalisation et Threat Feeds doivent être utilisés de manière encore plus conséquente.

Dépannage

Si un service local n’est pas accessible, suivez cet ordre :

1. L’IP cible du pare-feu est-elle correcte ?
2. Le client provient-il de la zone attendue ?
3. Le service est-il autorisé dans Administration > Device access pour cette zone ?
4. Existe-t-il une Local service ACL exception rule appropriée ?
5. Une règle ACL supérieure avec Drop s’applique-t-elle éventuellement ?
6. Le service est-il configuré sur un autre port ?
7. L’accès est-il perçu différemment via VPN, proxy ou NAT ?
8. Le Log Viewer montre-t-il un indice ?
9. Packet Capture peut-il voir la tentative de connexion sur l’interface ?

Pour les accès de support, il peut être judicieux de créer une règle d’exception ACL ciblée et de la supprimer ou désactiver après la clôture.

Liste de vérification opérationnelle

• WebAdmin non accessible largement depuis WAN.
• SSH autorisé uniquement temporairement ou depuis des réseaux de gestion/admin.
• DNS actif uniquement pour les zones client qui utilisent réellement le pare-feu comme résolveur.
• SNMP autorisé uniquement depuis le système de surveillance ou le réseau de surveillance.
• User Portal, VPN Portal et SSL VPN actifs uniquement s’ils sont nécessaires dans le concept d’accès à distance.
• MFA vérifié pour WebAdmin, VPN Portal et accès à distance.
• Accès API autorisé uniquement depuis des hôtes définis et aligné avec Device Access.
• Règles d’exception ACL nommées avec une source, un service et un objectif clairs.
• Règles de support temporaires documentées avec date d’expiration.
• Accès testé depuis des sources autorisées et non autorisées.
• Journalisation, Central Reporting ou Syslog vérifiés pour les accès pertinents au portail et à la gestion.
• Revue trimestrielle planifiée pour WebAdmin, SSH, SNMP, User Portal, VPN Portal et SSL VPN.

FAQ