Objectif
Contenir une campagne de tentatives d’authentification frauduleuses sur un VPN et déterminer si elle a abouti, sans se limiter au blocage d’adresses IP, puis renforcer l’accès distant avec MFA, politiques de lockout adaptées, restrictions d’exposition et supervision.
Prérequis
- Logs VPN contenant au minimum heure, IP source, utilisateur, résultat et méthode d’authentification.
- Accès au firewall/VPN, à l’annuaire et au système MFA.
- Liste des comptes ciblés, comptes réellement actifs et utilisateurs autorisés au VPN.
- Canal pour contacter rapidement les utilisateurs dont une connexion réussie paraît anormale.
- Sauvegarde de la configuration VPN avant durcissement.
Procédure pas à pas
Préserver les journaux et normaliser les heures
Exportez les logs avant rotation et conservez le fuseau. Regroupez les tentatives par compte et IP, puis distinguez brute force sur un compte et password spraying sur de nombreux comptes. Notez aussi les noms d’utilisateurs inexistants : ils peuvent révéler une phase d’énumération. Conservez les fichiers bruts en plus de votre synthèse.
- La campagne est quantifiée par période, source et comptes ciblés.
Chercher d’abord les authentifications réussies
Pour chaque compte ciblé, recherchez un succès pendant et après la campagne. Comparez l’IP, le pays, l’heure, le device et le second facteur aux habitudes connues. Un utilisateur qui confirme la connexion permet de clôturer ce point ; un succès inexpliqué déclenche la procédure de compte compromis : révocation de session, rotation de credential et investigation des actions postérieures.
- Chaque succès dans la période est expliqué ou traité comme incident de compromission.
Vérifier les comptes inexistants, désactivés et privilégiés
Identifiez les noms tentés qui correspondent à des comptes administrateurs, anciens employés ou comptes de service. Désactivez les comptes inutiles et retirez l’accès VPN des identités qui n’en ont pas besoin. Un portail qui accepte de tester des noms d’utilisateurs génériques augmente la surface : réduisez le périmètre au groupe VPN réellement autorisé.
- Seuls les comptes ayant un besoin métier peuvent s’authentifier au VPN.
Bloquer temporairement les sources les plus agressives
Ajoutez les sources manifestement malveillantes à une liste de blocage ou à une threat feed avec une date de révision. Ne laissez pas une liste manuelle croître indéfiniment. Si le volume vient majoritairement de régions sans utilisateur légitime, une restriction géographique peut réduire l’exposition, mais elle doit être testée et documentée.
- Le bruit immédiat diminue sans bloquer les utilisateurs légitimes.
Configurer une limitation de tentatives
Sur FortiGate
config vpn ssl settings
set login-attempt-limit 2
set login-block-time 60
endshow vpn ssl settings- Les rafales de mots de passe erronés déclenchent un blocage temporaire contrôlé.
Imposer le MFA à tous les utilisateurs humains
Le MFA réduit fortement l’impact d’un mot de passe deviné ou réutilisé. Vérifiez qu’aucune exception non justifiée ne permet une authentification simple pour un compte humain. Pour les comptes techniques, utilisez un mécanisme spécifique plutôt que de contourner le MFA du portail utilisateur. Testez le parcours de secours et la révocation d’un token perdu.
- Aucun accès VPN humain ne dépend du seul mot de passe.
Réduire l’exposition du portail
Si le VPN n’est utilisé que par des sites ou pays connus, limitez les sources via local-in policy, adresses géographiques ou autre mécanisme supporté. Désactivez les fonctionnalités du portail web inutilisées et n’exposez le service que sur l’interface nécessaire. Un port non standard peut réduire le bruit automatisé mais ne constitue pas une mesure de sécurité suffisante.
- Le portail est accessible uniquement au périmètre réellement nécessaire.
Durcir les groupes et policies après authentification
Une authentification réussie ne doit pas donner un accès réseau large. Associez les groupes VPN aux seules ressources nécessaires, segmentez les profils et journalisez les connexions. Si un compte est compromis, le moindre privilège réduit l’impact. Vérifiez aussi les routes et DNS poussés au client afin d’éviter un accès involontaire à tout le SI.
- Les utilisateurs VPN possèdent des flux limités à leur besoin métier.
Créer des alertes sur les motifs réellement utiles
Alertez sur un grand nombre d’échecs, un succès après plusieurs échecs, une connexion depuis une nouvelle zone, un compte désactivé, un compte privilégié et une modification de configuration VPN. Établissez un seuil basé sur votre trafic normal pour éviter le bruit. Conservez une vue quotidienne des principales sources et comptes ciblés.
- Une nouvelle campagne et surtout un succès suspect sont détectés rapidement.
Clôturer et documenter l’incident
Conservez la chronologie, les comptes touchés, les IP, les succès vérifiés, les mesures de blocage et les modifications de configuration. Retirez les blocages temporaires devenus inutiles après la période prévue. Si aucune compromission n’est confirmée, indiquez-le explicitement au lieu de conclure qu’un simple blocage IP a « résolu » l’attaque.
- Le rapport distingue clairement tentatives, succès confirmés, compromission éventuelle et mesures de prévention.
Validation
La procédure est validée lorsque :
- Aucun succès de connexion suspect ne reste sans explication.
- Tous les utilisateurs VPN humains utilisent un MFA effectif.
- Les tentatives répétées déclenchent une limitation ou un blocage adapté.
- Le portail et les policies post-authentification sont limités au besoin métier.
- Les nouvelles campagnes et succès après échecs déclenchent une alerte.
Retour arrière
- Retirer une IP ou une géolocalisation bloquée si elle affecte un utilisateur légitime, avec exception ciblée plutôt qu’ouverture globale.
- Revenir aux valeurs précédentes de login-attempt-limit/login-block-time si le support constate des lockouts excessifs.
- Ne désactivez pas le MFA pour rétablir rapidement un utilisateur ; corrigez sa méthode d’authentification ou utilisez le parcours de secours prévu.
Dépannage / erreurs fréquentes
- Échecs continuent malgré blocage IP : la campagne est distribuée ; concentrez-vous sur MFA, limitation, restrictions du portail et surveillance des succès.
- Utilisateur légitime bloqué : vérifier son IP, le compteur de tentatives, le second facteur et la durée de blocage avant de modifier globalement la policy.
- Logs montrent des noms inexistants : réduire l’exposition et vérifier qu’aucune différence de réponse ne permet une énumération utile.
- Succès suspect puis activité interne : basculer immédiatement vers la procédure de compromission de compte et corréler les logs d’annuaire, VPN et ressources accédées.