La 2FA Palo Alto GlobalProtect via RADIUS, sans serveur RADIUS distinct

Les pare-feu Palo Alto Networks peuvent transmettre les connexions VPN GlobalProtect à un serveur RADIUS. C’est tout ce dont l’auth-proxy Notakey a besoin : il s’insère dans le chemin RADIUS et ne laisse passer une connexion qu’une fois que l’utilisateur l’a approuvée sur son téléphone.

L’objection habituelle porte sur le serveur RADIUS lui-même. Beaucoup d’équipes n’en exploitent pas, et monter un FreeRADIUS ou un Microsoft NPS uniquement pour ajouter un second facteur est un projet à part entière. Ce guide s’appuie plutôt sur le plugin RADIUS livré avec l’appliance on-premise Notakey : l’appliance constitue alors à elle seule tout le back-end, avec le proxy, RADIUS et l’approbation sur téléphone au même endroit.

Nous n’avons pas testé nous-mêmes de pare-feu Palo Alto en laboratoire. Les réglages Palo Alto ci-dessous proviennent de la documentation de Palo Alto, liens à l’appui. Le pare-feu dialogue avec l’auth-proxy en RADIUS standard, exactement comme les concentrateurs VPN de nos autres guides.

Comment l’ensemble s’articule

GlobalProtect app ──▶ Palo Alto portal/gateway ──RADIUS──▶ Notakey auth-proxy ──RADIUS──▶ RADIUS plugin
                                                                  │
                                                                  └──▶ approval request ──▶ user's phone

L’utilisateur se connecte avec GlobalProtect et saisit son nom d’utilisateur et son mot de passe.
Le pare-feu envoie une requête RADIUS à l’auth-proxy de l’appliance.
Le proxy confie la vérification du mot de passe au plugin RADIUS. Un mot de passe erroné est rejeté immédiatement.
Si le mot de passe est accepté, le proxy envoie une demande d’approbation sur le téléphone de l’utilisateur et maintient l’échange RADIUS ouvert pendant que l’utilisateur décide, 30 secondes par défaut.
En cas d’approbation, le pare-feu reçoit Access-Accept. En cas de refus ou d’absence de réponse, la connexion est rejetée.

Ce que le plugin change au mot de passe

Il y a un compromis à peser avant de choisir le plugin. Celui-ci ne vérifie pas le mot de passe de l’utilisateur dans l’annuaire. Il accepte soit un mot de passe global commun à tous, soit une courte liste de mots de passe par utilisateur conservée dans la configuration du plugin (plugin de service RADIUS).

Concrètement, c’est l’approbation sur téléphone qui protège la connexion : la demande part vers le téléphone enrôlé pour ce nom d’utilisateur, et la personne qui le détient voit ce qu’elle approuve. Avec le mot de passe global, l’étape du mot de passe est une barrière commune plutôt qu’un second secret propre à chaque utilisateur.

Si votre politique de sécurité ou votre auditeur exige que le mot de passe de l’annuaire soit l’un des deux facteurs, faites pointer l’auth-proxy vers un serveur RADIUS qui interroge Active Directory, comme Microsoft NPS, plutôt que vers le plugin. Toute la partie Palo Alto de ce guide reste identique ; seuls l’adresse de destination et le secret du proxy changent, comme l’explique notre guide 2FA sur un VPN via RADIUS.

Étape 1 – Créer l’application VPN dans Notakey

Dans le tableau de bord Notakey, créez une application (service) pour le VPN, enrôlez les téléphones des utilisateurs et copiez l’Access ID de l’application.

Le nom d’utilisateur saisi dans GlobalProtect doit parvenir au proxy exactement tel qu’il a été enrôlé dans Notakey. Gardez-le à l’esprit à l’étape 4, où Palo Alto peut ajouter ou retirer un domaine.

Étape 2 – Démarrer le plugin RADIUS sur l’appliance

Dans la CLI de l’appliance, définissez l’image du plugin, remplacez le secret et le mot de passe par défaut, puis démarrez-le. Ne conservez pas les valeurs par défaut : elles sont publiées dans notre documentation.

ntk cfg setc :plugins.radius.image "notakey/radius-all:latest"
ntk cfg setc :plugins.radius.env.SECRET "<long-random-secret>"
ntk cfg setc :plugins.radius.env.PASSWORD "<global-password>"
ntk plugins update
ntk plugins start

PASSWORD est le mot de passe global que les utilisateurs saisissent dans GlobalProtect. Pour attribuer plutôt un mot de passe propre à certains utilisateurs, ajoutez USER1/PASSW1, USER2/PASSW2, etc. ; la liste complète des options figure dans l’article consacré au plugin.

Étape 3 – Pointer l’auth-proxy vers le plugin

Le proxy trouve le plugin grâce au nom de son conteneur, radius. Utilisez le même secret des deux côtés, comme l’indique l’article sur le plugin ; le pare-feu s’en servira également.

ntk cfg set :ap.vpn_port_in "1812"
ntk cfg set :ap.vpn_radius_address "radius"
ntk cfg set :ap.vpn_secret_in "<long-random-secret>"
ntk cfg set :ap.vpn_secret_out "<long-random-secret>"
ntk cfg set :ap.vpn_access_id "<access-id-from-step-1>"
ntk cfg set :ap.vpn_message_ttl "30"
ntk cfg set :ap.message_title "VPN login"
ntk cfg set :ap.message_description "Allow {0} to connect to the VPN?"
ntk ap start

vpn_message_ttl correspond au temps dont dispose l’utilisateur pour approuver. Dans la description, {0} est remplacé par le nom d’utilisateur. Le proxy écoute les requêtes RADIUS sur le port UDP 1812 ; le pare-feu doit pouvoir joindre l’appliance sur ce port.

Une différence par rapport aux autres VPN : avec GlobalProtect, ne comptez pas voir l’adresse IP de l’utilisateur sur la carte d’approbation. L’auth-proxy lit l’adresse du client dans l’attribut RADIUS standard prévu à cet effet, Calling-Station-Id. GlobalProtect n’y place pas l’IP du client ; il ne l’envoie que dans un attribut propriétaire de Palo Alto (vendor-specific attribute) (note de SecureAuth sur ce comportement). Rédigez la description de sorte que la carte indique malgré tout à l’utilisateur ce qu’il approuve : le service et le nom d’utilisateur.

Étape 4 – Configurer le pare-feu Palo Alto

Le guide de Palo Alto Set Up RADIUS or TACACS+ Authentication décrit la démarche générale. Voici les réglages qui comptent pour une approbation sur téléphone.

Profil de serveur RADIUS (Device → Server Profiles → RADIUS) (référence des champs) :

Server : l’adresse de l’appliance, le port 1812 et le secret de l’étape 3.
Timeout : la valeur par défaut est de 3 secondes, ce qui suffit pour vérifier un mot de passe, mais nullement pour qu’une personne trouve son téléphone. La plage autorisée va de 1 à 120 secondes, et la propre recommandation de Palo Alto pour les configurations multifacteurs est de laisser aux utilisateurs le temps de répondre. Choisissez une valeur nettement supérieure à la fenêtre de 30 secondes du proxy, par exemple 60.
Retries : la valeur par défaut est 3. Avec un délai long, 1 suffit. Si le pare-feu renvoie malgré tout une requête, l’auth-proxy la reconnaît et l’ignore : l’utilisateur ne reçoit donc pas de seconde demande d’approbation.
Authentication Protocol : choisissez PAP. Le protocole par défaut, PEAP-MSCHAPv2, encapsule la connexion dans un tunnel chiffré et, par défaut, masque l’identité de l’utilisateur dans la requête externe. Or le proxy doit lire le nom d’utilisateur pour savoir à quel téléphone s’adresser. PAP est l’option que Palo Alto indique pour un serveur RADIUS qui n’utilise ni EAP ni CHAP. Avec PAP, RADIUS transmet le nom d’utilisateur en clair et ne masque que le mot de passe, à l’aide du secret partagé (RFC 2865). Faites passer la liaison entre le pare-feu et l’appliance par un réseau de confiance, et choisissez un secret long et aléatoire.

Profil d’authentification (Device → Authentication Profile) :

Type : RADIUS, avec le profil de serveur ci-dessus.
Username Modifier : %USERINPUT% transmet le nom d’utilisateur tel quel. Si vous définissez un User Domain, Palo Alto l’ajoute en préfixe ou en suffixe, ou retire le domaine saisi par l’utilisateur. Quel que soit le résultat, il doit correspondre au nom d’utilisateur enrôlé dans Notakey.
Allow List (onglet Advanced) : la liste est vide par défaut, ce qui bloque tout le monde. Ajoutez les utilisateurs ou groupes autorisés à se connecter, ou all.

Portail et passerelle : ajoutez le profil d’authentification aux paramètres d’authentification des clients du portail et de la passerelle GlobalProtect, puis validez la configuration (commit).

Étape 5 – Éviter deux approbations par connexion

Une connexion GlobalProtect s’authentifie deux fois : une fois auprès du portail, une fois auprès de la passerelle. Avec RADIUS des deux côtés, l’utilisateur reçoit deux demandes d’approbation pour une seule connexion. Or c’est précisément ce genre de bruit qui habitue les gens à approuver sans lire.

Les cookies de contournement d’authentification de Palo Alto règlent ce problème (paramètres d’authentification du portail). Le portail émet un cookie chiffré après la première connexion réussie, et la passerelle l’accepte au lieu de redemander une authentification :

Sur le portail, activez Generate cookie for authentication override.
Sur la passerelle, activez Accept cookie for authentication override.
Utilisez le même certificat sur le portail et sur la passerelle pour chiffrer et déchiffrer le cookie.
Choisissez la durée de vie du cookie en connaissance de cause. Tant qu’il est valide, l’utilisateur n’est pas sollicité à nouveau : une durée longue signifie moins d’approbations, mais aussi moins de protection si l’ordinateur portable est volé.

Testez

Connectez-vous avec GlobalProtect. Après le mot de passe, la demande d’approbation arrive sur le téléphone avec le titre et la description définis à l’étape 3. Approuvez, et le tunnel s’établit. Recommencez ensuite et refusez : la connexion doit échouer.

Si les connexions échouent alors même que vous approuvez rapidement, vérifiez d’abord les délais :

le délai du profil de serveur RADIUS sur le pare-feu, qui doit dépasser les 30 secondes du proxy ;
le délai de connexion propre à GlobalProtect. Des administrateurs rapportent sur le forum communautaire de Palo Alto l’avoir augmenté pour les connexions multifacteurs (discussion sur le forum). Si les approbations tardives échouent alors que les rapides fonctionnent, c’est la cause probable : augmentez ce délai ou réduisez vpn_message_ttl.

Ce que cela ne couvre pas

Les connexions relayées par hameçonnage. Une approbation sur téléphone empêche qu’un mot de passe volé ou deviné suffise à lui seul. Elle n’arrête pas un attaquant qui relaie une véritable connexion à travers une fausse page en temps réel ; seules les méthodes liées au site, comme les clés FIDO, y parviennent. Nous expliquons la différence dans notre billet sur la lassitude MFA et les attaques par relais.
L’exposition du pare-feu lui-même. Pourquoi une connexion VPN ou d’administration protégée par un simple mot de passe pose problème, et ce qu’il faut corriger en priorité, nous l’expliquons dans notre billet sur FortiBleed. Les enseignements valent pour les pare-feu de tous les fabricants.

Essayez la démo en ligne pour approuver une connexion depuis votre propre téléphone en deux minutes environ, ou demandez une démo et nous vous aiderons à préparer un projet pilote GlobalProtect.