Aperçu du VPN d’accès à distance Cisco Secure Firewall Threat Defense
Cisco Secure Firewall Threat Defense fournit des fonctionnalités de passerelle sécurisée qui prennent en charge les VPN d’accès à distance SSL et IPsec-IKEv2. Le client du tunnel complet, Secure Client, fournit des connexions SSL et IPsec-IKEv2 sécurisées à la passerelle de sécurité pour les utilisateurs distants. Lorsque le client négocie une connexion SSL VPN avec le périphérique défense contre les menaces , il se connecte à l’aide de Transport Layer Security (TLS) ou de Datagram Transport Layer Security (DTLS).
Secure Client est le seul client pris en charge sur les périphériques de point terminal pour la connectivité VPN à distance vers les périphériques défense contre les menaces . Le client offre aux utilisateurs distants les avantages d’un client VPN SSL ou IPsec-IKEv2 sans que les administrateurs réseau n’aient à installer et à configurer les clients sur les ordinateurs distants. Secure Client pour Windows, Mac et Linux est déployé à partir de la passerelle sécurisée lors de la connectivité. Les applications Secure Client pour les périphériques Apple iOS et Android sont installées à partir de l’App Store de la plateforme.
Utilisez l’assistant de politique VPN d’accès à distance dans centre de gestion pour configurer rapidement et facilement les VPN d’accès à distance SSL et IPsec-IKEv2 avec des fonctionnalités de base. Ensuite, améliorez la configuration de politique comme vous le souhaitez et déployez-la sur vos périphériques Cisco Secure Firewall Threat Defense de passerelle sécurisés.
Fonctionnalités du VPN d’accès à distance
Le tableau suivant décrit les fonctionnalités du VPN d'accès à distance Cisco Secure Firewall Threat Defense :
Description |
|
---|---|
fonctionnalités du VPN d'accès à distance Cisco Secure Firewall Threat Defense |
|
Fonctionnalités AAA |
|
Fonctionnalités de tunnellisation VPN |
|
Fonctionnalités de surveillance de VPN d’accès à distance |
|
Composants Secure Client
Déploiement Secure Client
Votre politique de VPN d’accès à distance peut inclure Secure Client Image et Secure Client Profile pour la distribution aux points terminaux qui se connectent. Le logiciel client peut également être distribué par d’autres méthodes. Consultez le chapitre Déployer Cisco Secure Client dans Guide de l'administrateur de Cisco Secure Client (y compris AnyConnect), version 5.
Sans client installé précédemment, les utilisateurs distants saisissent l’adresse IP dans leur navigateur d’une interface configurée pour accepter les connexions VPN SSL ou IPsec-IKEv2. À moins que le périphérique de sécurité ne soit configuré pour rediriger les requêtes http:// vers https://, les utilisateurs distants doivent saisir l’URL sous la forme https://adresse. Une fois que l’utilisateur a saisi l’URL, le navigateur se connecte à cette interface et affiche l’écran de connexion.
Après la connexion d’un utilisateur, si la passerelle sécurisée estime que l’utilisateur a besoin du client VPN, elle télécharge le client qui correspond au système d’exploitation de l’ordinateur distant. Après le téléchargement, le client s’installe et se configure, établit une connexion sécurisée et reste ou se désinstalle (selon la configuration du périphérique de sécurité) lorsque la connexion s’interrompt. Dans le cas d’un client déjà installé, après la connexion, la passerelle de sécurité défense contre les menaces examine la version du client et le met à niveau au besoin.
Opération Secure Client
Lorsque le client négocie une connexion avec le périphérique de sécurité, il se connecte à l’aide de Transport Layer Security (TLS) et éventuellement de Datagram Transport Layer Security (DTLS). L’utilisation de DTLS évite les problèmes de latence et de bande passante associés à certaines connexions SSL et améliore la performance des applications en temps réel sensibles aux retards de paquets.
Lorsqu’un client VPN IPsec-IKEv2 établit une connexion à la passerelle sécurisée, la négociation consiste à authentifier le périphérique par le biais d’Internet Key Exchange (IKE), suivi de l’authentification de l’utilisateur au moyen de l’authentification étendue IKE (Xauth). Le profil de groupe est transmis au client VPN et une association de sécurité IPsec est créée pour terminer le VPN.
Secure Client Profile et Éditeur
Le Secure Client Profile est un groupe de paramètres de configuration, stocké dans un fichier XML que le client VPN utilise pour configurer son fonctionnement et son apparence. Ces paramètres (balises XML) comprennent les noms et les adresses des ordinateurs hôtes et les paramètres permettant d’activer davantage de fonctionnalités client.
Vous pouvez configurer un profil à l'aide de Secure Client Profile Editor. Cet éditeur est un outil de configuration pratique basé sur une interface graphique utilisateur et disponible avec le progiciel Secure Client. Il s’agit d’un programme indépendant que vous exécutez en dehors de centre de gestion.
Authentification du VPN d'accès à distance
Authentification du serveur VPN d’accès à distance
Les passerelles sécurisées Cisco Secure Firewall Threat Defense utilisent toujours des certificats pour s’identifier et s’authentifier auprès du point terminal client VPN.
Pendant que vous utilisez l’assistant de politique VPN d’accès à distance, vous pouvez inscrire le certificat sélectionné sur le périphérique défense contre les menaces ciblé. Dans l’assistant, sous Access and Certificate (Accès et certificats), sélectionnez l’option « Inscrire l’objet de certificat sélectionné sur les périphériques cibles ». L’inscription du certificat est automatiquement lancée sur les périphériques précisés. Pendant que vous terminez la configuration de la politique VPN d’accès à distance, vous pouvez afficher l’état du certificat inscrit sur la page d’accueil du certificat du périphérique. L’état indique clairement si l’inscription au certificat a réussi ou non. La configuration de votre politique VPN d’accès à distance est maintenant entièrement terminée et prête à être déployée.
L’obtention d’un certificat pour la passerelle sécurisée, également connu sous le nom d’inscription PKI, est expliqué dans Certificats. Ce chapitre contient une description complète de la configuration, de l’inscription et de la maintenance des certificats de passerelle.
Client d’accès à distance pour le VPN AAA
Pour SSL et IPsec-IKEv2, l'authentification de l'utilisateur distant est effectuée à l'aide des noms d'utilisateur et des mots de passe uniquement, des certificats uniquement ou des deux.
Remarque |
Si vous utilisez des certificats clients dans votre déploiement, ils doivent être ajoutés à la plateforme de votre client indépendamment de Cisco Secure Firewall Threat Defense ou Cisco Secure Firewall Management Center. Des installations telles que SCEP ou CA Services ne sont pas fournies pour remplir vos clients avec des certificats. |
Les serveurs AAA permettent aux périphériques gérés servant de passerelles sécurisées de déterminer qui est un utilisateur (authentification), ce que l’utilisateur est autorisé à faire (autorisation) et ce qu’il a fait (comptabilité). RADIUS, LDAP/AD, TACACS+ et Kerberos sont des exemples de serveurs AAA. Pour le VPN d'accès à distance sur les périphériques défense contre les menaces , les serveurs AD, LDAP et RADIUS AAA sont pris en charge pour l’authentification.
Reportez-vous à la section Comprendre l’application des politiques des autorisations et des attributs pour en savoir plus sur l’autorisation VPN d’accès à distance.
Avant d’ajouter ou de modifier la politique VPN d’accès à distance, vous devez configurer le domaine et les groupes de serveurs RADIUS que vous souhaitez spécifier. Pour plus de renseignements, consultez les sections Créer un domaine LDAP ou un domaine Active Directory et un répertoire de domaine et Ajouter un groupe de serveurs RADIUS.
Sans DNS configuré, le périphérique ne peut pas résoudre les noms de serveur AAA, les URL nommées et les serveurs CA avec FQDN ou noms d’hôte, il ne peut résoudre que les adresses IP.
Les informations de connexion fournies par un utilisateur distant sont validées par un domaine LDAP ou AD ou un groupe de serveurs RADIUS. Ces entités sont intégrées à la passerelle sécurisée Cisco Secure Firewall Threat Defense.
Remarque |
Si les utilisateurs s’authentifient auprès du VPN d’accès à distance en utilisant Active Directory comme source d’authentification, ils doivent se connecter avec leur nom d’utilisateur; le format domaine\nom_utilisateur ou nom_utilisateur@domaine échoue. (Active Directory fait référence à ce nom d’utilisateur sous le nom de nom de connexion ou parfois sous le nom de sAMAccountName.) Pour en savoir plus, consultez Attributs de dénomination des utilisateurs sur MSDN. Si vous utilisez RADIUS pour l’authentification, les utilisateurs peuvent se connecter dans l’un des formats mentionnés ci-dessus. |
Une fois authentifié au moyen d’une connexion VPN, l’utilisateur distant prend une identité VPN. Cette identité VPN est utilisée par les politiques d’identité sur la passerelle sécurisée Cisco Secure Firewall Threat Defense pour reconnaître et filtrer le trafic réseau appartenant à cet utilisateur distant.
Les politiques d’identité sont associées aux politiques de contrôle d’accès, qui déterminent qui a accès aux ressources réseau. C’est de cette façon que l’utilisateur distant a bloqué ou autorisé l’accès à vos ressources réseau.
Pour en savoir plus, consultez les sections À propos des politiques d’identité et Politiques de contrôle d’accès.
Comprendre l’application des politiques d’autorisations et d’attributs
Le périphérique Cisco Secure Firewall Threat Defense prend en charge l’application d’attributs d’autorisation d’utilisateur (également appelés droits ou autorisations d’utilisateur) aux connexions VPN à partir d’un serveur d’authentification externe ou d’un serveur d’autorisation AAA (RADIUS) ou d’une politique de groupe sur le périphérique défense contre les menaces . Si le périphérique défense contre les menaces reçoit des attributs du serveur AAA externe qui sont en conflit avec ceux configurés dans la politique de groupe, les attributs du serveur AAA prévalent toujours.
Le périphérique défense contre les menaces applique les attributs dans l’ordre suivant :
-
Attributs de l’utilisateur sur le serveur AAA externe : le serveur renvoie ces attributs une fois l’authentification ou l’autorisation de l’utilisateur réussie.
-
Politique de groupe configurée sur le périphérique Firepower Threat Defense : Si un serveur RADIUS renvoie la valeur de l’attribut de classe RADIUS IETF-Class-25 (OU= group-policy) pour l’utilisateur, le périphérique défense contre les menaces place l’utilisateur dans la politique de groupe de du même nom et applique les attributs de la politique de groupe qui ne sont pas renvoyés par le serveur.
-
Politiques de groupe affectées par le profil de connexion (également appelé groupes de tunnels) : le profil de connexion contient les paramètres préliminaires pour la connexion et comprend une politique de groupe par défaut appliquée à l’utilisateur avant l’authentification.
Remarque |
Le périphérique défense contre les menaces ne prend pas en charge la transmission des attributs du système par défaut de la politique de groupe par défaut, DfltGRPPlicy. Les attributs de la politique de groupe affectés au profil de connexion sont utilisés pour la session utilisateur, s’ils ne sont pas remplacés par les attributs d’utilisateur ou la politique de groupe du serveur AAA, comme indiqué ci-dessus. |
Comprendre la connectivité des serveurs AAA
Les serveurs LDAP, AD et RADIUS AAA doivent être accessibles à partir du périphérique défense contre les menaces aux fins prévues : uniquement le traitement de l’identité de l’utilisateur, l’authentification VPN uniquement ou les deux activités. Les serveurs AAA sont utilisés dans le VPN d’accès à distance pour les activités suivantes :
-
Gestion de l’identité de l’utilisateur : les serveurs doivent être accessibles par l’interface de gestion.
Sur le défense contre les menaces , l’interface de gestion nécessite une configuration et un processus de routage distincts pour les interfaces de les interfaces normales utilisées par le VPN.
-
Authentification VPN : les serveurs doivent être accessibles sur l’une des interfaces standard : l’interface de dépistage ou une interface de données.
Pour les interfaces standard, deux tables de routage sont utilisées. Une table de routage de gestion uniquement pour l’interface de dépistage ainsi que toute autre interface configurée pour la gestion uniquement, et une table de routage des données utilisée pour les interfaces de données. Lorsqu’une recherche de routage est terminée, la table de routage de gestion uniquement est vérifiée en premier, puis la table de routage des données. La première correspondance est choisie pour atteindre le serveur AAA.
Remarque
Si vous placez un serveur AAA sur une interface de données, assurez-vous que les politiques de routage de gestion uniquement ne correspondent pas au trafic destiné à une interface de données. Par exemple, si vous avez une voie de routage par défaut par l’interface de dépistage, le trafic ne reviendra jamais vers la table de routage des données. Utilisez les commandes show route management-only et show route pour vérifier la détermination du routage.
Pour les deux activités sur les mêmes serveurs AAA, en plus de rendre les serveurs accessibles par l’interface de gestion pour le traitement de l’identité de l’utilisateur, effectuez l’une des opérations suivantes pour fournir un accès d’authentification VPN aux mêmes serveurs AAA :
-
Activez et configurez l’interface de dépistage avec une adresse IP sur le même sous-réseau que l’interface de gestion, puis configurez une voie de routage vers le serveur AAA par cette interface. L’accès de l’interface de dépistage sera utilisé pour l’activité VPN et l’accès de l’interface de gestion pour le traitement de l’identité.
Remarque
Lorsqu’elle est configurée de cette façon, vous ne pouvez pas avoir une interface de données sur le même sous-réseau que les interfaces de dépistage et de gestion. Si vous souhaitez que l’interface de gestion et une interface de données se trouvent sur le même réseau, par exemple lorsque vous utilisez le périphérique lui-même comme passerelle, vous ne pourrez pas utiliser cette solution, car l’interface de dépistage doit rester désactivée.
-
Configurer un routage par l’intermédiaire d’une interface de données vers le serveur AAA. L’accès à l’interface de données sera utilisé pour l’activité VPN et l’accès à l’interface de gestion pour le traitement de l’identité de l’utilisateur.
Pour plus d’informations sur les différentes interfaces, consultez Interfaces de pare-feu standard.
Après le déploiement, utilisez les commandes CLI suivantes pour surveiller et dépanner la connectivité du serveur AAA à partir du périphérique défense contre les menaces :
-
show aaa-server pour afficher les statistiques du serveur AAA.
-
show route management-only pour afficher les entrées de la table de routage destinées à la gestion uniquement.
-
show network et show network-static-routes pour afficher la route par défaut de l’interface de gestion et les routes statiques.
-
show route pour afficher les entrées de la table de routage du trafic de données.
-
ping system et traceroute system pour vérifier le chemin d’accès au serveur AAA via l’interface de gestion.
-
leping interface ifname et traceroute destination pour vérifier le chemin d’accès au serveur AAA à l’aide des interfaces de dépistage et de données.
-
test aaa-server authentication et test aaa-server authorization pour tester l’authentification et l’autorisation sur le serveur AAA.
-
clear aaa-server statistics groupname ou clear aaa-server statistics protocol protocol pour effacer les statistiques d’un serveur AAA par groupe ou protocole.
-
aaa-server groupname active host hostname pour activer un serveur AAA en panne ou aaa-server groupname fail host hostname pour activer un serveur AAA en panne.
-
debug ldap level , debug aaa authentication , debug aaa authorization et debug aaa accounting .