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.

Avant chaque modification, noter les réglages actuels ou sauvegarder la configuration. Conserver la case WAN de VPN portal, tous les champs et l’ordre des exceptions Local Service ACL, l’état et les trois valeurs de Block login, les ports et protocoles de VPN Portal et SSL VPN, ainsi que la sélection et l’ordre des serveurs d’authentification. Pour le Provisioning ou Entra SSO, relever aussi vpn_portal_port, l’URL du portail et la Redirect URI. Pour un Threat Feed modifié, conserver l’URL, le type d’indicateur, l’action, l’état d’activation et les options personnalisées. Le retour arrière rétablit ces valeurs, et non des valeurs par défaut supposées.

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. Tous ne sont pas des colonnes standard dans chaque vue ; Detailed view et les colonnes supplémentaires montrent les détails disponibles pour l’événement. S’il manque du contexte, consulter ensuite les logs bruts et ceux de l’Identity Provider. Dans un SIEM, filtrer log_component sur VPN Portal Authentication et status sur Failed ; la syntaxe exacte dépend du SIEM.

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 Fusion (anciennement Sophos Central). Créer ensuite d’abord l’exception restrictive :

1. Sous Administration > Device access > Local service ACL exception rule, cliquer sur Add.
2. Rule 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.

Après l’enregistrement, tester d’abord l’exception depuis une source externe autorisée. Par le second accès administrateur validé, retirer ensuite l’autorisation générale WAN de VPN portal dans la matrice Device Access et enregistrer. Les modifications de Device Access prennent effet immédiatement. La source autorisée doit encore atteindre le portail, tandis qu’une source externe non autorisée ne doit plus l’atteindre. Si le test positif échoue, rétablir l’autorisation WAN précédente par le second accès. Le guide Device Access décrit d’autres variantes de basculement.

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.

Le proxy web configuré sur le firewall constitue une exception importante. SFOS traite ses requêtes HTTP et HTTPS comme internes et non comme provenant d’une zone. Un utilisateur autorisé à utiliser le proxy peut donc atteindre VPN Portal et d’autres services HTTP du firewall, même si Device Access les désactive pour sa zone. Si le proxy est utilisé, effectuer le test négatif une fois directement et une fois de manière vérifiable via le proxy explicite ou transparent. Device Access ne peut pas bloquer ce chemin interne par zone ; il faut limiter l’accès au proxy lui-même si le résultat est indésirable.

Configurer correctement Login Security et les ports

Sous Administration > Admin and user settings > Login security, activer Block login et renseigner les trois champs pour le nombre d’échecs, la période et la durée de blocage. Cinq échecs en 60 secondes suivis d’un blocage de cinq minutes ne sont qu’un exemple de configuration, ni une valeur Sophos universelle ni un réglage de production à reprendre sans pilote. Choisir les valeurs selon le nombre d’utilisateurs, le support et les sources NAT partagées. Tester depuis une IP contrôlée en gardant le second accès administrateur ouvert.

Le blocage fonctionne par adresse IP source et s’applique à tous les services après le seuil, notamment WebAdmin, CLI, VPN Portal et User Portal. Derrière le NAT d’un bureau, d’un hôtel ou d’un fournisseur, plusieurs utilisateurs légitimes et un administrateur peuvent être touchés ensemble. Ne jamais effectuer le test négatif par 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. Les échecs de CAPTCHA ne comptent pas comme des échecs de connexion et ne déclenchent pas le blocage.

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, ne laisser actifs que les serveurs nécessaires. Un chemin local, AD, LDAP ou RADIUS inutilisé permet des essais superflus contre un autre annuaire. Au moins un serveur doit rester sélectionné. VPN Portal ne prend pas en charge RADIUS avec challenge-based MFA ; ne pas prévoir ce mécanisme comme MFA du portail.

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. Le Provisioning .pro se connecte via vpn_portal_port. Avec Entra SSO, l’URL utilisée pour VPN Portal et Remote Access ainsi que la Redirect URI enregistrée doivent correspondre à la passerelle et au port publiés. Des fichiers .ovpn distribués manuellement peuvent permettre une publication plus restrictive, mais les modifications de profil doivent rester contrôlées et testées.

Ajouter des Threat Feeds contre les sources connues

Sophos Firewall peut aussi comparer les adresses IP sources malveillantes connues pour le trafic vers ses propres services, dont VPN Portal, WebAdmin et VPN. Selon l’aide SFOS 22, cette comparaison s’applique aux MDR, NDR Essentials et Third-Party Threat Feeds, mais pas aux Sophos X-Ops Threat Feeds. Un Third-Party Feed IPv4 tenu à jour convient donc comme couche supplémentaire contre des sources connues.

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 afficher localement les détections dans Log Viewer, activer Local reporting pour Active threat response sous System services > Log settings. Les XGS 87/87w et 107/107w ne prennent pas en charge le reporting local ; utiliser Sophos Fusion ou un serveur Syslog sur ces modèles.

Les Threat Feeds ne remplacent ni une ACL ni une authentification forte. Ils ne comparent que les adresses répertoriées. Les Third-Party Feeds acceptent des adresses IPv4 individuelles, mais pas IPv6, les plages IP ni les adresses réseau ; une nouvelle adresse de bot reste accessible. Un False Positive peut bloquer un utilisateur légitime. Démarrer un feed en Monitor, contrôler les erreurs et les détections inattendues, puis seulement passer à Block. Une Threat Exclusion s’applique à tous les modules Active Threat Response : elle doit être étroite, justifiée et limitée dans le temps. Les détections et les exceptions sont revues régulièrement.

Pour revenir en arrière, remettre un feed modifié sur son action précédente ; désactiver un nouveau feed plutôt que le supprimer sans contrôle. Vérifier ensuite qu’une source victime d’un False Positive atteint de nouveau le portail et que les autres protections fonctionnent toujours.

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 sur la destination de logs configurée si cette protection est utilisée.
7. Aucun nouveau verrouillage AD ou Entra ni aucune connexion réussie inconnue n’apparaît pendant la période d’observation définie.

Si un test échoue, rétablir d’abord uniquement la dernière modification à sa valeur précédente documentée. Il peut s’agir de l’action du feed, d’un serveur d’authentification, de Block login, du port et de la Redirect URI ou de Device Access. Pour Device Access, rétablir l’ancienne autorisation WAN par le second accès avant de retirer la nouvelle exception ACL. Pour un port, rétablir ensemble port, protocole, .pro, URL du portail et Redirect URI, puis répéter les tests autorisé et interdit.

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