Protéger le VPN Portal de Sophos Firewall contre les attaques par force brute

De nombreux échecs de connexion au Sophos Firewall VPN Portal montrent d’abord que le portail est accessible depuis Internet et fait l’objet d’attaques automatisées. Ils ne prouvent pas encore qu’une intrusion a réussi. La situation devient critique lorsque de vrais noms d’utilisateur sont ciblés, que des comptes AD ou Microsoft Entra ID sont verrouillés ou qu’une connexion réussie inconnue apparaît entre les tentatives infructueuses.

Pour contenir l’attaque, suivre cet ordre :

1. Conserver dans les logs la période, les utilisateurs, les adresses IP sources et les méthodes d’authentification.
2. Contrôler les connexions réussies et les événements d’identité pendant la même période.
3. Limiter le VPN Portal aux sources ou aux pays nécessaires avec une Local Service ACL.
4. Activer Block login et exclure le partage de port entre VPN Portal et SSL VPN.
5. Supprimer les méthodes d’authentification inutiles et contrôler MFA ou la protection Entra.
6. Bloquer en complément les sources IPv4 malveillantes connues avec des Threat Feeds et surveiller l’effet.

⚠️ Ne pas désactiver le VPN Portal sans préparation. Sophos Connect Provisioning et Microsoft Entra ID SSO utilisent le port du VPN Portal. Avant toute modification de Device Access ou des ports, prévoir un second accès administrateur testé ainsi qu’un plan pour les profils clients, les Redirect URIs et le retour arrière.

Confirmer l’attaque dans Log Viewer

Dans Log Viewer, ouvrir les événements d’authentification et appliquer les filtres suivants :

• Log component: VPN Portal Authentication
• Status: Failed

Pour chaque résultat, l’heure, Source IP, Source country, Username, Authentication mechanism et Reason sont pertinents. Dans un SIEM, utiliser les champs Syslog log_component avec la valeur VPN Portal Authentication et status avec la valeur Failed ; la syntaxe exacte de la requête dépend du SIEM utilisé.

Rechercher ensuite également Successful pour les mêmes noms d’utilisateur et la même période. Une connexion réussie inconnue est plus importante que le simple nombre de tentatives infructueuses et doit être traitée comme un incident de compte potentiel.

Source unique ou attaque distribuée

La répartition détermine la protection efficace :

• Nombreuses tentatives depuis une adresse IP : Block login peut bloquer temporairement la source une fois le seuil atteint.
• Peu de tentatives depuis de nombreuses adresses IP : Un botnet distribué peut rester sous le seuil pour chaque source. Les ACL, la protection de l’identité et les Threat Feeds deviennent alors plus importants.
• Nombreux noms d’utilisateur depuis la même source : Ce comportement correspond au Password Spraying ou au Credential Stuffing.
• Toujours le même utilisateur réel : Contrôler les logs AD, Entra ou RADIUS pour détecter les verrouillages de compte et les connexions réussies.
• Noms aléatoires inexistants : Il s’agit souvent d’un scan automatisé, qui génère néanmoins de la charge et du bruit dans les logs.

Le blocage manuel de la seule adresse IP source résout rarement une attaque distribuée de manière durable. Réduire d’abord la surface accessible, puis ajouter automatiquement les sources malveillantes connues.

Contrôler précisément les logs bruts

Si Log Viewer ne fournit pas assez de contexte, télécharger les fichiers concernés sous Diagnostics > Tools > Troubleshooting logs :

• vpnportal.log pour l’accès au portail ;
• access_server.log pour l’authentification et l’autorisation des utilisateurs ;
• oauth_sso_vpn.log en complément pour Microsoft Entra ID SSO.

En revanche, sslvpn.log appartient au service SSL VPN et n’est pertinent que si l’erreur se produit lors de l’établissement du tunnel et non lors de la connexion au portail. Les logs d’authentification peuvent contenir des noms d’utilisateur, des adresses IP publiques et d’autres données sensibles des requêtes. Les extraits doivent donc être limités dans le temps et dans leur contenu, expurgés avant leur transmission et ne pas être copiés sans contrôle dans des tickets publics. Services et logs Sophos Firewall permet d’identifier d’autres fichiers de logs ; Sauvegarder les logs Sophos Firewall décrit une archive structurée destinée au support.

Limiter le VPN Portal aux sources nécessaires

Le VPN Portal est un service local du firewall. Les règles normales de firewall ou DNAT ne contrôlent pas cet accès ; il faut utiliser Administration > Device access. Les principes complets sont décrits dans Device Access et Local Service ACL.

Avant la modification, ouvrir et tester réellement un accès indépendant par la console, le LAN de gestion, un VPN d’administration ou Sophos Central. Créer ensuite d’abord l’exception restrictive :

1. Sous Administration > Device access > Local service ACL exception rule, cliquer sur Add.
2. Name: par exemple vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4 ; si IPv6 est publié, une règle IPv6 distincte est également nécessaire.
5. Source zone: WAN.
6. Source networks and hosts: réseaux partenaires fixes, liste IP tenue à jour ou Country Group contenant les pays réellement nécessaires.
7. Destination host: l’interface WAN ou l’adresse IP WAN configurée sur le Sophos Firewall sur laquelle arrive l’accès. Derrière un routeur NAT en amont, il ne s’agit pas de l’adresse publique de ce routeur.
8. Services: uniquement VPN portal.
9. Action: Accept.
10. Enregistrer la règle.

Dans l’état cible, le VPN Portal n’est pas activé globalement pour WAN dans la matrice Device Access ; il est accessible uniquement par les exceptions ACL nécessaires. Les modifications de Device Access prennent effet immédiatement. Le basculement sûr avec test positif, test négatif et retour arrière est donc volontairement décrit dans le guide détaillé de Device Access.

Tester ensuite l’exception depuis une source externe autorisée et une source non autorisée. Tant qu’une autorisation WAN étendue reste active, un test positif réussi ne prouve pas à lui seul que l’exception limite l’accès comme prévu.

Une restriction géographique est utile lorsque le groupe d’utilisateurs est clairement défini. Elle ne constitue toutefois pas un contrôle d’identité : les voyageurs, les réseaux mobiles, les fournisseurs VPN et les erreurs de géolocalisation IP peuvent bloquer des utilisateurs légitimes. Un accès mondial nécessite donc une protection particulièrement forte de l’identité, MFA, du logging et un processus de révision.

Configurer correctement Login Security et les ports

Sous Administration > Admin and user settings > Login security, activer Block login. Le Sophos Firewall Health Check utilise comme point de départ cinq échecs de connexion en 60 secondes et une durée de blocage de cinq minutes. La valeur appropriée en production dépend néanmoins du nombre d’utilisateurs, du processus du helpdesk et des sources NAT partagées.

Le blocage fonctionne par adresse IP source et, une fois le seuil atteint, ne concerne pas seulement VPN Portal. WebAdmin, CLI, VPN Portal et User Portal ne s’ouvrent alors plus depuis cette source. Un bureau, un hôtel ou un NAT de fournisseur peut donc toucher simultanément plusieurs utilisateurs légitimes et un administrateur. Un test négatif ne doit jamais être réalisé depuis le seul accès administrateur disponible.

Lors d’une attaque distribuée, Block login n’est qu’une couche de protection. De nombreux bots peuvent rester individuellement sous le seuil.

Exclure le partage de port

Comparer les deux valeurs suivantes :

• Administration > Admin and user settings > VPN portal HTTPS port, TCP 443 par défaut
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, 8443 par défaut avec TCP ou UDP

Si VPN Portal et SSL VPN utilisent le même port et le même protocole, les paramètres de Login Security ne s’appliquent pas. Le VPN Portal devient également accessible depuis les zones autorisées pour SSL VPN, même s’il y est désactivé dans Device Access.

La combinaison doit donc être unique. Le simple déplacement vers un port aléatoire n’empêche pas une attaque. Si le port du VPN Portal est modifié, mettre à jour l’URL du portail, l’Entra Redirect URI et la valeur vpn_portal_port pour Sophos Connect Provisioning, puis effectuer un nouveau test avec un utilisateur pilote.

Protéger l’authentification et les comptes concernés

Sous Authentication > Services > VPN portal authentication methods, laisser actifs uniquement les serveurs réellement nécessaires au concept Remote Access actuel. Un chemin local, AD, LDAP ou RADIUS qui n’est plus utilisé n’apporte aucun avantage, mais peut exposer des identifiants supplémentaires à des tests contre le portail public.

MFA n’empêche pas chaque tentative infructueuse, mais réduit le risque qu’un mot de passe connu ou deviné suffise à lui seul. MFA pour VPN Portal et Remote Access décrit la configuration pour les utilisateurs locaux et d’annuaire. Avec Microsoft Entra ID SSO, contrôler également Entra MFA, Conditional Access, Sign-in Logs et Risk Events.

Un utilisateur réel présentant des tentatives infructueuses suspectes ne doit pas être examiné uniquement sur le firewall :

1. Contrôler les verrouillages de compte et les connexions réussies dans l’Identity Provider responsable.
2. Mettre fin aux sessions réussies inconnues conformément au processus de gestion des incidents.
3. Réinitialiser le mot de passe et les méthodes MFA enregistrées en cas de suspicion de compromission.
4. Contrôler l’appartenance aux groupes et l’autorisation Remote Access.
5. Ensuite seulement, vérifier avec une connexion pilote documentée que l’accès légitime fonctionne de nouveau.

Le VPN Portal ne peut être entièrement retiré de WAN que si aucun processus nécessaire n’en dépend. Entra SSO et le Provisioning par .pro utilisent le port du portail. Avec des fichiers .ovpn distribués manuellement, un processus de publication plus restrictif peut être possible, mais les modifications de profil doivent alors être distribuées et testées de manière contrôlée.

Ajouter des Threat Feeds contre les sources connues

Sophos Firewall peut également comparer les adresses IP sources malveillantes connues pour le trafic dirigé vers le système et des services tels que VPN Portal, WebAdmin et VPN. Des flux IPv4 tenus à jour conviennent comme couche de protection supplémentaire.

Configurer les Threat Feeds sur Sophos Firewall décrit la configuration complète, les exigences de licence, le pilote Monitor, le fonctionnement en Block, les False Positives et les flux Cybora testés par Avanet. Pour un nouveau flux, il faut toujours contrôler la récupération et le contenu des IoC, observer d’abord l’effet, puis seulement activer le blocage de manière contrôlée.

Pour que les détections Active Threat Response apparaissent dans Log Viewer, Local reporting doit être activé pour Active threat response sous System services > Log settings.

Les Threat Feeds ne remplacent ni une ACL ni une protection forte de l’identité. Ils ne détectent que les indicateurs qu’ils contiennent, les Third-Party Feeds prennent actuellement en charge IPv4 pour les IoC d’IP source, et une adresse IP de bot nouvelle ou non répertoriée reste accessible. À l’inverse, un False Positive peut bloquer un utilisateur légitime ; un processus documenté d’exception et de révision est donc nécessaire.

Contrôler l’effet et poursuivre la surveillance

Après chaque modification, répéter le même test défini :

1. Une source externe autorisée atteint le VPN Portal et un utilisateur pilote peut se connecter.
2. Une source non autorisée n’atteint plus le portail.
3. VPN Portal et SSL VPN utilisent une combinaison unique de port et de protocole.
4. Une tentative infructueuse contrôlée apparaît dans Log Viewer avec l’adresse IP source et la méthode d’authentification attendues.
5. Sophos Connect Provisioning, Entra SSO et le tunnel VPN lui-même continuent de fonctionner.
6. Les détections Threat Feed apparaissent dans le log Active Threat Response si cette couche de protection est utilisée.
7. Aucun verrouillage de compte AD ou Entra ni aucune connexion réussie inconnue ne se produit.

Pour la détection à long terme, envoyer les logs d’authentification à un SIEM. Les alertes utiles ne considèrent pas seulement le nombre d’erreurs, mais aussi de nombreuses sources différentes ciblant le même utilisateur, de nombreux noms d’utilisateur depuis une même source et des connexions réussies après une série de tentatives infructueuses.

FAQ