Sécurité : Dispositifs de sécurité de la gamme Cisco PIX 500

PIX/ASA : Exemple de configuration d'un proxy à coupure pour l'accès réseau à l'aide d'un serveur TACACS+ et RADIUS

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit comment créer l'accès AAA-authentifié (de proxy de cut-through) à un Pare-feu PIX qui exécute les versions du logiciel PIX 6.3 et plus tard.

Le Pare-feu PIX offre la représentation qui est excessivement meilleure que des Pare-feu de concurrence. Il gagne la vitesse par un processus de brevet en instance appelé Cut-through Proxies, qui est le moyen le plus rapide pour qu'un Pare-feu authentifie un utilisateur.

À la différence d'un serveur proxy qui doit analyser chaque paquet à la couche sept du modèle OSI, d'un temps et de fonction traiter-intensive, le Pare-feu PIX questionne d'abord un serveur TACACS+ ou de RAYON pour l'authentification. Une fois qu'approuvé, le Pare-feu PIX établit alors un flux de données et tout le trafic circule ensuite directement et rapidement entre les deux interlocuteurs.

Les proxys de cut-through ont permis le Pare-feu PIX d'exécuter excessivement les serveurs plus rapide que basés sur proxy tout en mettant à jour l'état de session. Le proxy de cut-through diminue également le coût de possession en réutilisant la base de données d'authentification existante.

Afin de créer AAA-a authentifié l'accès à un Pare-feu PIX qui exécute la version du logiciel PIX 5.2 à 6.2, se rapportent à comment exécuter l'authentification et l'activation sur le pare-feu Cisco Secure PIX (5.2 à 6.2). Ce document fournit également des informations au sujet de la façon activer l'authentification, syslogging, et accédant quand le serveur d'AAA est en panne.

Afin de se renseigner plus sur l'authentification et la commande d'autorisation pour PIX 6.2, référez-vous à l'autorisation d'authentification et de commande pour PIX 6.2.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Versions de logiciel 6.3 de pare-feu Cisco Secure PIX et plus tard

  • Version 3.2 et ultérieures du Cisco Secure Access Control Server (ACS)

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Produits connexes

Cette configuration peut également être utilisée avec l'appliance de Sécurité de gamme de Cisco ASA 5500 avec la version 7.x.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Vous pouvez employer des Listes d'accès pour contrôler le trafic basé sur l'adresse IP et le protocole. Cependant, vous devez employer l'authentification et l'autorisation afin de contrôler l'accès et l'utilisation pour les utilisateurs ou les groupes spécifiques. L'authentification, qui est le processus d'identifier des utilisateurs, est prise en charge par le Pare-feu PIX pour des serveurs de RAYON et TACACS+. L'autorisation identifie les autorisations spécifiques pour un utilisateur donné.

Si vous voulez appliquer l'authentification et l'autorisation quand un hôte interne (de gens du pays) initie une connexion à un réseau externe (de Sécurité inférieure), vous devez l'activer sur l'interface interne (de Sécurité plus élevée). Afin d'installer l'authentification et l'autorisation de se produire quand un hôte externe initie une connexion à un hôte interne, vous devez l'activer sur l'interface extérieure.

L'AAA permet aux dispositifs de sécurité de déterminer qui l'utilisateur est (authentification), ce que l'utilisateur peut faire (autorisation), et ce que l'utilisateur a fait (comptabilité).

L'AAA fournit un niveau de protection et un contrôle supplémentaires pour l'accès client qu'utilisant seul le Listes de contrôle d'accès (ACL). Par exemple, vous pouvez créer un ACL qui permet à tous les utilisateurs externes pour accéder au telnet sur un serveur sur le réseau DMZ. Si vous voulez que seulement quelques utilisateurs accèdent au serveur et vous ne pourriez pas toujours connaître des adresses IP de ces utilisateurs, vous pouvez permettre à l'AAA de laisser les utilisateurs seulement authentifiés et/ou autorisés pour le faire par les dispositifs de sécurité. Le serveur telnet impose également l'authentification. Les dispositifs de sécurité empêchent des utilisateurs non autorisés d'une tentative d'accéder au serveur.

Vous pouvez utiliser l'authentification seule ou avec l'autorisation et la comptabilité. L'autorisation exige toujours d'un utilisateur d'être authentifié d'abord. Vous pouvez utiliser seule la comptabilité, ou avec l'authentification et l'autorisation.

Configurez l'AAA dans PIX

Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.

Remarque: Utilisez l'outil Command Lookup Tool (clients enregistrés seulement) pour obtenir plus d'informations sur les commandes utilisées dans cette section.

Vous devez se terminer ces derniers afin d'activer l'authentification et l'autorisation :

  1. Identifiez l'adresse IP du serveur d'authentification que vous utiliser-et déterminerez une clé de chiffrement de serveur à partager par le serveur d'authentification et le Pare-feu PIX.

  2. Configurez le serveur d'authentification avec les utilisateurs qui peuvent accéder au réseau, les services qu'ils peuvent utiliser, et les hôtes qu'ils peuvent accéder à.

  3. Configurez le Pare-feu PIX à l'enable ou désactivez l'authentification ou l'autorisation.

En outre, vous pouvez configurer le Pare-feu PIX afin de contrôler l'accès client aux hôtes spécifiques ou aux services. Cependant, il est plus facile de mettre à jour ce genre de contrôle d'accès dans un emplacement simple, au serveur d'authentification. Après que vous activiez l'authentification et l'autorisation, le Pare-feu PIX incite des utilisateurs de FTP, de telnet, ou d'accès de HTTP (Web). Le contrôle de l'accès à un système ou à un service spécifique est manipulé par le serveur d'authentification et d'autorisation.

Remarque: Quand vous utilisez la version 6.3 ou ultérieures de Pare-feu PIX, vous pouvez activer l'authentification avec une base de données d'utilisateur que vous configurez localement sur votre Pare-feu PIX. Les étapes de configuration sont semblables à ceux pour la configuration d'un serveur RADIUS/TACACS+. Les différences sont notées dans chaque étape de cette procédure.

Terminez-vous ces étapes afin de permettre au Pare-feu PIX de prendre en charge l'authentification de l'utilisateur et l'autorisation :

  1. Pour l'authentification d'arrivée, créez les déclarations de charge statique et de commande access-list requises permettre les hôtes extérieurs aux serveurs d'accès sur le réseau intérieur.

  2. Si le réseau interne se connecte à l'Internet, créez un pool d'adresses globales des adresses IP enregistrées.

  3. Émettez la commande nat avec la commande access-list afin de spécifier les hôtes internes qui peuvent commencer les connexions sortantes.

  4. Émettez l'ordre d'AAA-serveur afin d'identifier le serveur qui traite l'authentification ou l'autorisation.

    Créez un seul nom de groupe de serveurs.

    Exemple :

    pix(config)#aaa-server AuthInbound protocol tacacs+
    
    pix(config)#aaa-server AuthInbound (inside) host 10.1.1.1 TheUauthKey 
    
    pix(config)#aaa-server AuthOutbound protocol tacacs+
    
    pix(config)#aaa-server AuthOutbound (inside) host 10.1.1.2 TheUauthKey
    

    Remarque: Cette étape n'est pas exigée quand vous utilisez la base de données locale pour l'authentification.

    Remarque: L'autorisation RADIUS est équipée de déclaration de commande access-list comme décrit dans la section d'autorisation RADIUS de configurer.

    Le premier appel de procédure dans cet exemple crée le groupe d'authentification d'AuthInbound utilisant l'authentification TACACS+. Le deuxième appel de procédure déclare que le serveur d'AuthInbound est sur l'interface interne, cela que l'adresse IP est 10.1.1.1, et la clé de chiffrement est TheUauthKey.

    Le troisième appel de procédure crée le groupe d'authentification d'AuthOutbound utilisant l'authentification TACACS+. La déclaration de quatrième commande déclare que le serveur d'AuthOutbound est sur l'interface interne, cela que l'adresse IP est 10.1.1.2, et la clé de chiffrement est TheUauthKey.

  5. Émettez l'authentication command d'AAA afin d'activer l'authentification.

    pix(config)#aaa authentication include authen_service if_name 0 0 0 0 
    <server_tag|LOCAL>
    
    

    La partie d'authen_service de la commande représente le type de trafic pour inclure ou l'exclure de l'authentification. Ceci est basé sur l'option sélectionnée de service, telle que le FTP, le telnet, le HTTP ou les https.

    Ce sont les options de service d'authentification d'accès :

    • enable

    • séquentiel

    • ssh

    • telnet

    Spécifiez l'interface série pour l'accès de console série, le telnet pour l'accès de telnet, le ssh pour l'accès de SSH, et l'enable pour l'accès de mode enable. Les options de service d'authentification de cut-through sont ceux-ci :

    • telnet

    • FTP

    • HTTP

    • https

    • ICMP/type

    • proto

    • TCP/port

    • UDP/port

    Le proto variable peut être n'importe quelle valeur ou nom prise en charge de protocole IP, tel que l'IP ou l'igmp. Seulement le telnet, le FTP, le HTTP, ou les https trafiquent l'authentification d'utilisateur interactif de déclencheur. Référez-vous à la section d'authentication command d'AAA dans la référence de commandes de Pare-feu de Cisco PIX pour des informations sur cette option.

    La partie d'if_name de la commande représente le nom d'interface dont les utilisateurs ont besoin de l'authentification. Si vous configuriez comme extérieur (comme configuré avec la commande de nameif), elle en active l'authentification pour des connexions provenues du réseau extérieur à réseau d'intérieur. Employez le mot clé LOCAL afin d'utiliser la base de données locale pour l'authentification. Afin d'utiliser un serveur d'AAA, remplacez le server_tag par le nom de Groupe de serveurs AAA défini avec l'ordre d'AAA-serveur.

    Exemple :

    Une adresse IP de 0 signifie tous les hôtes. Quand vous placez l'adresse IP locale à 0, ceci permet le serveur d'authentification de décider quels hôtes sont authentifiés.

    Cet exemple active l'authentification pour toutes les connexions de FTP provenues du réseau extérieur au réseau d'intérieur :

    pix(config)#aaa authentication include ftp outside 0 0 0 0 AuthOutbound
    
    pix(config)#aaa authentication include telnet outside 0 0 0 0 AuthOutbound
    
    pix(config)#aaa authentication include http outside 0 0 0 0 AuthOutbound
    
    pix(config)#aaa authentication include ftp inside 0 0 0 0 AuthInbound
    

    Cet exemple active l'authentification pour toutes les connexions de telnet provenues du réseau intérieur au n'importe quel réseau extérieur :

    pix(config)#aaa authentication include telnet inside 0 0 0 0 AuthInbound
    
    pix(config)#aaa authentication include http inside 0 0 0 0 AuthInbound
    

    Remarque: Faites attention à s'appliquer l'authentification seulement aux protocoles qui peuvent être authentifiés. Si vous employez le n'importe quel mot clé pour appliquer l'authentification, des protocoles tels que le Protocole SMTP (Simple Mail Transfer Protocol) sont empêchés de traverser le Pare-feu PIX.

  6. Émettez la commande d'autorisation d'AAA afin d'activer l'autorisation.

    pix(config)#aaa authorization include authen_service if_name 0 0 0 0
    

    Le Pare-feu PIX vérifie la demande d'autorisation avec le serveur d'AAA, qui prend la décision au sujet de quels services un utilisateur peut accéder à.

    La partie d'authen_service de la commande représente les services qui exigent l'autorisation. Les valeurs valides en sont, FTP, HTTP, telnet, ou protocole/port. En employez pour fournir l'autorisation pour tous les services de TCP. Employez le protocole/forme de port pour fournir l'autorisation pour des services d'UDP.

    La partie d'if_name de la commande représente le nom d'interface dont les utilisateurs ont besoin de l'authentification. Utilisez l'interface-nom, combiné avec l'adresse IP locale et l'adresse étranger-IP, afin de déterminer d'où l'accès est recherché et de qui. L'adresse IP locale est toujours sur l'interface de niveau de Sécurité la plus élevée et l'étranger-IP est toujours sur le plus bas.

    Une adresse IP de 0 signifie tous les hôtes. Quand vous placez l'adresse IP locale à 0, ceci permet le serveur d'autorisation de décider quels hôtes sont autorisés.

    Remarque: Cette étape n'est pas exigée quand vous utilisez la base de données locale pour l'authentification.

    Exemple :

    pix(config)#aaa authorization include ftp outside 0 0 0 0
    
    pix(config)#aaa authorization include telnet outside 0 0 0 0
    
    pix(config)#aaa authorization include http outside 0 0 0 0
    
    pix(config)#aaa authorization include ftp inside 0 0 0 0
    
    pix(config)#aaa authorization include telnet inside 0 0 0 0
    
    pix(config)#aaa authorization include http inside 0 0 0 0
    

    Référez-vous à la référence de commandes de Pare-feu de Cisco PIX pour plus d'informations sur les différentes options disponibles pour les paramètres d'autorisation et d'authentification.

Configuration d'échantillon de PIX

Le Pare-feu PIX vous permet de définir les groupes distincts de serveurs TACACS+ ou de RAYON afin de spécifier différents types de trafic, tels qu'un serveur TACACS+ pour le trafic d'arrivée et un serveur de RAYON pour le trafic sortant.

Cet exemple crée l'AuthInbound pour l'authentification TACACS+, des groupes de serveurs d'AuthOutbound pour l'authentification de RAYON, et le spécifie que le serveur 172.68.118.101 sur l'interface interne fournit l'authentification.

pix(config)#aaa-server AuthInbound protocol tacacs+ 
pix(config)#aaa-server AuthInbound (inside) host 172.68.118.101 cisco timeout 5
pix(config)#aaa-server AuthOutbound protocol radius 
pix(config)#aaa-server AuthOutbound (inside) host 172.68.118.101 cisco timeout 5
pix(config)#aaa authentication include ftp outside 0 0 0 0 AuthOutbound
pix(config)#aaa authentication include telnet outside 0 0 0 0 AuthOutbound
pix(config)#aaa authentication include http outside 0 0 0 0 AuthOutbound
pix(config)#aaa authentication include ftp inside 0 0 0 0 AuthInbound
pix(config)#aaa authentication include telnet inside 0 0 0 0 AuthInbound
pix(config)#aaa authentication include http inside 0 0 0 0 AuthInbound

De PIX 7.x, vous pouvez spécifier le nombre d'essais ratés permis pour n'importe quel serveur donné au groupe de serveurs avant que le serveur est désactivé. Émettez la commande de maximum-échouer-tentatives en mode de Groupe de serveurs AAA. Vous devez faire configurer le Groupe de serveurs AAA avant que vous puissiez émettre cette commande. Exemple :

hostname(config)#aaa-server svrgrp1 protocol tacacs+

hostname(config-aaa-server-group)#max-failed-attempts 4

Authentification de telnet

Vous voyez une demande pour le mot de passe PIX et puis une demande pour le nom d'utilisateur et mot de passe de RAYON ou TACACS (enregistré sur le serveur TACACS - 10.31.1.41). Exemple :

pix(config)#aaa-server topix protocol tacacs+

pix(config)#aaa-server topix host 10.31.1.41 cisco timeout 5

pix(config)#aaa authentication telnet console topix

Authentification de port de console

Vous voyez une demande pour le mot de passe PIX et puis une demande pour le nom d'utilisateur/mot de passe RADIUS/TACACS (enregistré sur le serveur de RAYON - 10.31.1.41). Exemple :

pix(config)#aaa-server topix protocol radius

pix(config)#aaa-server topix host 10.31.1.41 cisco timeout 5

pix(config)#aaa authentication serial console topix

Authentification d'enable

Ici, vous êtes incité pour un nom d'utilisateur et mot de passe qui est envoyé au serveur TACACS ou de RAYON. Vous pouvez se connecter dans le PIX avec TACACS ou RAYON et enable par TACACS ou RAYON avec le même nom d'utilisateur/mot de passe parce que le paquet d'authentification pour l'enable est identique que le paquet d'authentification pour la procédure de connexion.

pix(config)#aaa-server topix protocol radius

pix(config)#aaa-server topix host 10.31.1.41 cisco timeout 5

pix(config)#aaa authentication enable console topix

Authentification sécurisée d'enable des clients web

La version 6.3 de Pare-feu PIX introduit une méthode sécurisée pour permuter des noms de l'utilisateur et des mots de passe entre un web client et un Pare-feu PIX. Cette version utilise le HTTP au-dessus du Protocole SSL (Secure Socket Layer) (HTTPS). HTTPS chiffre le nom d'utilisateur et mot de passe, et rend la transmission sécurisée.

Quand vous avez authentifié un navigateur Web à l'aide d'un serveur d'AAA sur des versions antérieures de Pare-feu PIX, le nom d'utilisateur et mot de passe ont été obtenus du client de HTTP en texte clair.

Ajoutez ce mot clé à la commande d'AAA d'activer cette caractéristique :

pix(config)#aaa authentication secure-http-client

Le sécurisé-http-client de mot clé active cette caractéristique ainsi le nom d'utilisateur et mot de passe sont permutés sécurisé entre les clients de HTTP et le Pare-feu PIX.

Vous devez configurer l'authentification d'AAA et émettre cette commande afin d'activer cette caractéristique :

pix(config)#aaa authentication include authen_service if_name 0 0 0 0 <server_tag|LOCAL>

Voyez l'AAA de configurer dans la section PIX pour la syntaxe de cette commande.

Cette caractéristique prend en charge également l'authentification des clients qui accèdent aux sites Web (HTTPS) sécurisés.

Remarque: Quand vous activez l'authentification d'AAA, le sécurisé-HTTP-client n'est pas requis d'authentifier des sessions HTTPS.

Après que vous activiez cette caractéristique, quand les accès client une page Web qui exige l'authentification, le Pare-feu PIX demande un nom d'utilisateur et mot de passe pour l'authentification HTTPS.

tacacs-radius-config6.gif

Remarque: La commande d'authentique-demande est émise dans cet exemple afin de personnaliser le champ texte de Cisco Systems. Ce champ est vide si vous n'écrivez pas une chaîne avec la commande d'authentique-demande. Référez-vous à la référence de commandes de Pare-feu de Cisco PIX pour la syntaxe détaillée de cette commande.

Après que l'utilisateur entre un nom d'utilisateur valide et un mot de passe, une fenêtre réussie d'authentification apparaît et se ferme automatiquement. Si l'utilisateur n'entre pas un nom d'utilisateur valide et un mot de passe, une fenêtre d'échec de l'authentification apparaît.

On permet un maximum de 16 authentifications simultanées HTTPS. Si chacun des passage de 16 procédures d'authentification HTTPS, une nouvelle connexion qui exige l'authentification ne réussit pas. Débuts d'une procédure d'authentification quand le Pare-feu PIX reçoit le nom d'utilisateur et mot de passe du navigateur et finit quand il reçoit le résultat d'authentification du serveur d'AAA. La durée exigée pour compléter chaque procédure d'authentification dépend du temps de réponse de la source d'authentification. Si la base de données locale est utilisée, elle est très rapide. Si un serveur de RAYON ou TACACS+ est utilisé, il dépend du temps de réponse de serveur.

Quand la commande du délai d'attente 0 d'uauth est configurée (le délai d'attente d'uauth est placé à 0), l'authentification HTTPS ne pourrait pas fonctionner. Si un navigateur initie de plusieurs connexions TCP pour charger une page Web après l'authentification HTTPS, la première connexion est a permis, mais les connexions ultérieures déclenchent l'authentification. En conséquence, des utilisateurs sont continuellement présentés avec une page d'authentification, même si le nom d'utilisateur et mot de passe correct sont écrits chaque fois. Le contournement est de placer le délai d'attente d'uauth à 1 seconde avec la commande de l'uauth 0:0:1 de délai d'attente. Cependant, ce contournement ouvre une occasion fournie 1-second qui pourrait permettre aux utilisateurs non-authentifiés pour passer par le Pare-feu s'ils proviennent la même adresse IP source.

Si un navigateur Web lance une demande de page Web HTTPS tandis que sécurisé authentification est dans le processus pour une demande de HTTP précédente, la demande HTTPS déclenche une deuxième procédure d'authentification sécurisée, même si l'authentification sécurisée n'est pas spécifiquement activée pour HTTPS. Une fois que la procédure d'authentification pour l'un ou l'autre de page Web est terminée avec succès, la demande que reste peut être terminée en rechargeant la page.

Puisque l'authentification HTTPS se produit sur le port 443 SSL, n'utilisez pas la commande access-list de bloquer le trafic du client de HTTP au serveur HTTP sur le port 443. En outre, si vous configurez le PAT statique pour le trafic web sur le port 80, vous devez également configurer une entrée statique pour le port 443 SSL. Dans cet exemple, la première ligne configure le PAT statique pour le trafic web et la deuxième ligne doit être ajoutée pour prendre en charge la configuration d'authentification HTTPS dans le mode de configuration :

static (inside,outside) tcp 10.132.16.200 www 10.130.16.10 www

static (inside,outside) tcp 10.132.16.200 443 10.130.16.10 443

Les utilisateurs de HTTP voient une fenêtre externe générée par le navigateur si l'ordre de sécurisé-HTTP-client d'authentification d'AAA n'est pas configuré. Si l'ordre de sécurisé-HTTP-client d'authentification d'AAA est configuré, des chargements d'une forme dans le navigateur pour collecter le nom d'utilisateur et mot de passe. Dans l'un ou l'autre de cas, si vous entrez un mot de passe incorrect, vous êtes incité de nouveau. Quand le web server et le serveur d'authentification sont sur des différents hôtes, émettez la commande virtuelle de recevoir le comportement correct d'authentification.

Configurez le SSH pour l'authentification

PIX 5.2 a ajouté le support de version 1 de Protocole Secure Shell (SSH). Le SSH 1 est basé sur novembre, 1995, projet soumis à l'IETF. Les versions SSH 1 et 2 ne sont pas compatibles avec l'un l'autre. Référez-vous aux forums aux questions de Protocole Secure Shell (SSH)leavingcisco.com pour plus d'informations sur le SSH.

Le PIX est considéré le serveur de SSH. Le trafic des clients SSH (c'est-à-dire, enferme dans une boîte le SSH courant) au serveur de SSH (le PIX) est chiffré. Quelques clients de la version SSH 1 sont répertoriés dans les notes en version PIX 5.2. Des tests de TP Cisco ont été faits avec le SSH F-sécurisé 1.1 sur le NT et la version 1.2.26 pour le Solaris.

Remarque: Pour PIX 7.x, référez-vous à la section laissante d'Access de SSH de gérer le système Access. En outre, référez-vous à la configuration d'échantillon dans PIX/ASA 7.x : SSH/Telnet sur l'exemple de configuration d'interface interne et externe.

Terminez-vous ces étapes afin de configurer le SSH authentifié par AAA :

  1. Assurez-vous que vous pouvez telnet à PIX avec l'AAA en fonction, mais sans SSH :

    pix(config)#aaa-server AuthOutbound protocol radius (or tacacs+)
    pix(config)#aaa authentication telnet console AuthOutbound
    pix(config)#aaa-server AuthOutbound host 172.18.124.111 cisco
    

    Remarque: Quand le SSH est configuré, la commande de 172.18.124.114 255.255.255.255 de telnet n'est pas nécessaire parce que le ssh 172.18.124.114 255.255.255.255 à l'intérieur de commande est émis sur le PIX. Les deux commandes sont incluses afin de tester.

  2. Émettez ces commandes dans le mode de configuration afin d'ajouter le SSH :

    hostname goss-d3-pix515b
    domain-name rtp.cisco.com
    ca gen rsa key 1024
    
    
    !--- Caution: The RSA key is not saved without
    !--- the ca save all command.
    !--- The write mem command does not save it. 
    !--- In addition, if the PIX has undergone a write erase
    !--- or has been replaced, then cutting and pasting  
    !--- the old configuration does not generate the key.
    !--- You must re-enter the ca gen rsa key command.
    !--- If there is a secondary PIX in a failover pair, the write standby 
    !--- command does not copy the key from the primary to the secondary. 
    !--- You must also generate and save the key on the secondary device.
    
    
    
    ssh 172.18.124.114 255.255.255.255 inside
    ssh timeout 60
    aaa authen ssh console AuthOutbound
    logging trap debug
    logging console debug
  3. Émettez l'ordre de la RSA de mypubkey de l'exposition Ca en mode de config :

    goss-d3-pix(config)#show ca mypubkey rsa
     % Key pair was generated at: 08:22:25 Aug 14 2000
     Key name: goss-d3-pix.rtp.cisco.com
      Usage: General Purpose Key
      Key Data:
       30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00ad4bcb 
       e9c174d5 0657a0f3 c94e4b6d 32ac8500 6b84e754 59e20df4 f28c257d 131af21d 
       4c0a8f4c e79d8b6d a3520faa 1a42d577 c6adfe51 9d96fa62 f3be07fb 01e082d7 
       133cecff bf24f653 bc690b11 ee222070 413c1920 d02321f8 4fc3c5f1 f0c6e077 
       81e93184 af55438b dcdcda34 c0a5f5ad 87c435ef 
          67170674 4d5ba51e 6d020301 0001
     % Key pair was generated at: 08:27:18 Aug 14 2000
     Key name: goss-d3-pix.rtp.cisco.com.server
      Usage: Encryption Key
      Key Data:
       307c300d 06092a86 4886f70d 01010105 00036b00 30680261 00d4f61b ec45843a 
       4ad9266d b125ee26 efc63cc4 e5e9cda4 9418ee53 6e4d16cf 3d0dc864 4d4830c8 
       fa7f110e 8a5761ed 4ca73ea7 5d405862 6f3150df 9eb0d11e 9c4d3563 95ff51ae 
       6711d60b 9a1415e4 19201d3f 03b455ea c1df9a41 b3a5a73f 4f020301 0001
  4. Émettez un telnet de la station de Solaris :

    rtp-evergreen#./ssh -c 3des -l cisco -v 172.18.124.157
    

    Remarque: Le nom d'utilisateur sur le serveur RADIUS/TACACS+ est Cisco et 172.18.124.157 est la destination.

Utilisation de la commande d'exclure

Si vous ajoutez un autre extérieur d'hôte (chez 99.99.99.100) au réseau, et cet hôte est de confiance, vous pouvez les exclure de l'authentification et de l'autorisation avec ces commandes :

pix(config)#aaa authentication exclude telnet inbound 0.0.0.0 0.0.0.0 99.99.99.100
 255.255.255.255 AuthInbound

pix(config)#aaa authorization exclude telnet inbound 0.0.0.0 0.0.0.0 99.99.99.100 
255.255.255.255 AuthInbound

Configurez le serveur du RAYON \ TACACS+ utilisant le Cisco Secure ACS

Terminez-vous ces étapes afin de configurer le RAYON et le TACACS+ dans un Cisco Secure ACS.

  1. Vous devez configurer le PIX pour localiser le CSACS afin de vérifier les identifiants utilisateurs.

    Exemple :

    pix(config)#aaa-server AuthOutbound protocol radius
    pix(config)#aaa-server AuthOutbound (inside) host 171.68.118.101 testkey
    
  2. Choisissez la configuration réseau du côté gauche et cliquez sur Add l'entrée pour ajouter une entrée pour le PIX dans la base de données du serveur TACACS+ ou de RAYON. Choisissez la base de données du serveur selon la configuration PIX.

    /image/gif/paws/70992/tacacs-radius-config1.gif

  3. Entrez dans 172.16.1.85 dans le domaine d'adresse IP, et écrivez le test pour la zone de tri secrète partagée. Choisissez le RAYON (Cisco IOS/PIX) dans l'authentifier utilisant la liste déroulante. Cliquez sur Submit.

    tacacs-radius-config2.gif

    La clé est utilisée pour authentifier entre le serveur PIX et CSACS (serveur de RAYON). Si vous voulez sélectionner le protocole TACACS+ pour l'authentification, alors choisissez TACACS+ (Cisco IOS) dans l'authentifier utilisant relâchent vers le bas le menu.

    /image/gif/paws/70992/tacacs-radius-config3.gif

  4. Écrivez le nom d'utilisateur dans le domaine d'utilisateur dans la base de données Cisco Secure, puis cliquez sur Add/l'éditez.

    Dans cet exemple, le nom d'utilisateur est user1.

    tacacs-radius-config4.gif

  5. Dans la prochaine fenêtre, entrez le mot de passe pour user1.

    Dans cet exemple, le mot de passe est également password1. Vous pouvez tracer le compte utilisateur à un groupe si vous souhaitez. Quand vous avez terminé, cliquez sur Submit.

    tacacs-radius-config5.gif

Configurez l'autorisation TACACS+

Vous pouvez configurer les dispositifs de sécurité pour exécuter l'autorisation d'accès au réseau avec TACACS+. Vous spécifiez l'ACLs que les règles d'autorisation doivent apparier afin d'identifier le trafic à autoriser. Alternativement, vous pouvez identifier le trafic directement dans l'autorisation s'ordonne.

L'utilisation d'ACLs d'identifier le trafic à autoriser peut a considérablement réduit le nombre d'autorisation vous commande doit entrer. C'est parce que chaque règle d'autorisation que vous écrivez peut spécifier seulement un source, sous-réseau de destination et service, tandis qu'un ACL peut inclure beaucoup d'entrées.

Les déclarations d'authentification et d'autorisation sont indépendantes. Cependant, n'importe quel trafic unauthenticated apparié par une déclaration d'autorisation est refusé. Pour que l'autorisation réussisse, un utilisateur doit d'abord authentifier avec les dispositifs de sécurité. Puisqu'un utilisateur aux besoins donnés d'une adresse IP seulement d'authentifier une fois pour tous les règles et types, si la session d'authentification n'a pas expiré, autorisation peut se produire même si le trafic est apparié par une instuction d'authentification.

Après qu'un utilisateur authentifie, les dispositifs de sécurité vérifient les règles d'autorisation pour apparier le trafic. Si le trafic apparie la déclaration d'autorisation, les dispositifs de sécurité envoient le nom d'utilisateur au serveur TACACS+. Le serveur TACACS+ répond aux dispositifs de sécurité avec une autorisation ou un refuser pour ce trafic, basé sur le profil utilisateur. Les dispositifs de sécurité imposent la règle d'autorisation dans la réponse.

Voyez la documentation pour votre serveur TACACS+ pour les informations sur la façon dont aux autorisations d'accès de configure network pour un utilisateur.

Terminez-vous ces étapes afin de configurer l'autorisation TACACS+ :

  1. Authentification d'enable.

    Référez-vous à activer le pour en savoir plus d'authentification d'accès au réseau. Si vous avez déjà activé l'authentification, continuez à l'étape suivante.

  2. Émettez la commande access-list afin de créer un ACL qui identifie les adresses sources et les adresses de destination du trafic que vous voulez autoriser.

    Pour des étapes, référez-vous à ajouter une liste d'accès étendue. Le trafic assorti de marque d'as d'autorisation pour l'autorisation, tandis que refusez des entrées excluent le trafic assorti de l'autorisation. L'ACL que vous utilisez pour apparier d'autorisation devrait contenir des règles aux lesquelles soyez égal, ou un sous-ensemble de, les règles dans l'ACL utilisé pour apparier d'authentification.

    Remarque: Si vous avez configuré l'authentification et voulez autoriser tout le trafic étant authentifié, vous pouvez utiliser le même ACL que vous avez créé pour l'usage avec la commande match d'authentification d'AAA.

  3. Émettez cette commande afin d'activer l'autorisation :

    hostname/contexta(config)#aaa authorization match acl_name 
    interface_name server_group
    

    La partie d'acl_name de la commande est le nom de l'ACL que vous avez créé dans l'étape 2, la partie d'interface_name de la commande est le nom de l'interface comme spécifiée avec la commande de nameif ou par défaut, et la partie de server_group de la commande est le Groupe de serveurs AAA vous avez créé quand vous avez activé l'authentification.

    Remarque: Alternativement, vous pouvez utiliser l'autorisation d'AAA incluez la commande. Ceci identifie le trafic dans la commande. Cependant, vous ne pouvez pas utiliser les deux méthodes dans la même configuration. Référez-vous au pour en savoir plus de référence de commandes d'appareils de sécurité Cisco.

    Ces commandes authentifient et autorisent le trafic intérieur de telnet. Le trafic de telnet aux serveurs autres que 10.165.201.5 peut seul être authentifié, mais le trafic à 10.165.201.5 exige l'autorisation.

    hostname/contexta(config)#access-list TELNET_AUTH extended permit tcp any any 
    eq telnet
    
    hostname/contexta(config)#access-list SERVER_AUTH extended permit tcp any host 
    10.165.201.5 eq telnet
    
    hostname/contexta(config)#aaa-server AuthOutbound protocol tacacs+
    
    hostname/contexta(config-aaa-server-group)#exit
    
    hostname/contexta(config)#aaa-server AuthOutbound (inside) host 10.1.1.1
    
    hostname/contexta(config-aaa-server-host)#key TACPlusUauthKey
    
    hostname/contexta(config-aaa-server-host)#exit
    
    hostname/contexta(config)#aaa authentication match TELNET_AUTH inside AuthOutbound
    
    hostname/contexta(config)#aaa authorization match SERVER_AUTH inside AuthOutbound
    

Configurez l'autorisation RADIUS

Le Pare-feu PIX permet à un serveur de RAYON pour envoyer des attributs de groupe d'utilisateurs au Pare-feu PIX dans le message de réponse d'authentification de RAYON.

L'administrateur définit d'abord des Listes d'accès sur le Pare-feu PIX pour chaque groupe d'utilisateurs. Par exemple, il a pu y avoir des Listes d'accès pour chaque service dans une organisation, des ventes, vente, ingénierie, et ainsi de suite. L'administrateur répertorie alors la liste d'accès dans le profil de groupe dans la version de Cisco du RAYON, appelée CiscoSecure.

Le Pare-feu PIX demande l'authentification de l'utilisateur par le serveur de RAYON. Si l'utilisateur est autorisé, le serveur de RAYON renvoie un message de réponse confirmant d'autorisation au Pare-feu PIX avec le constructeur l'attribut que spécifique 11 (filtre-id) a placé à la liste d'accès pour le groupe donné de l'utilisateur. L'attribut RADIUS 11 ne peut pas être utilisé pour passer ces informations.

Le Pare-feu PIX fournit également la même fonctionnalité pour TACACS+ afin de mettre à jour la cohérence.

Remarque: Des Listes d'accès peuvent être utilisées avec le RAYON ou le TACACS, mais autorisant le FTP, le HTTP, ou le telnet est seulement possible avec TACACS+.

Émettez ces déclarations de commande access-list afin de limiter des utilisateurs dans un service à trois serveurs et refuser tout autrement :

access-list eng permit ip any server1 255.255.255.255

access-list eng permit ip any server2 255.255.255.255

access-list eng permit ip any server3 255.255.255.255

access-list eng deny ip any any

Dans cet exemple, la chaîne d'attribut de constructeur-particularité dans la configuration de CiscoSecure a été placée à acl=eng. Employez ce champ dans la configuration de CiscoSecure afin d'identifier le nom d'identification de liste d'accès. Le Pare-feu PIX reçoit la chaîne d'acl=acl_ID de CiscoSecure, extrait l'identifiant d'ACL, et le met dans l'entrée d'uauth de l'utilisateur.

Quand les essais d'un utilisateur pour ouvrir une connexion, le Pare-feu PIX vérifie la liste d'accès dans l'entrée d'uauth de l'utilisateur et, permet ou refuse la connexion. Ceci dépend de l'autorisation ou refuse le statut de la correspondance de liste d'accès. Quand une connexion est refusée, le Pare-feu PIX génère un message correspondant de Syslog. S'il n'y a aucune correspondance, alors la règle implicite est de refuser.

Puisque le source ip d'un utilisateur donné peut varier selon d'où ils sont logging on, en place l'adresse source dans la déclaration de commande access-list à, et l'adresse de destination pour identifier les services réseau auxquels on permet l'utilisateur ou accès refusé.

Remarque: La commande d'autorisation d'AAA n'exige pas une option distincte de RAYON.

Exemption basée sur MAC d'AAA d'utilisation

Les versions 6.3 et ultérieures de Pare-feu PIX vous permettent d'employer des adresses MAC pour sauter l'authentification pour les périphériques, tels que des Téléphones IP de Cisco, qui ne prennent en charge pas l'authentification d'AAA. Vous devez identifier les adresses MAC sur l'interface intérieure (de Sécurité plus élevée) afin d'utiliser cette caractéristique. Le Pare-feu PIX utilise l'adresse MAC et l'adresse IP, cela a été dynamiquement assignée à l'adresse MAC, afin d'éviter le serveur d'AAA pour le trafic qui apparie. Des services d'autorisation sont automatiquement désactivés quand vous sautez l'authentification. Les enregistrements des comptes sont encore générés (si activé), mais le nom d'utilisateur n'est pas affiché.

Créez une liste d'adresses MAC à exempter de l'authentification d'AAA et puis assignez la liste à un serveur d'AAA afin d'activer l'exemption basée sur MAC d'AAA.

Remarque: Cette caractéristique ne peut pas être appliquée sur l'extérieur ou l'interface à niveau de sécurité inférieur.

  1. Émettez cette commande dans le mode de configuration afin de définir une liste d'adresses MAC :

    mac-list mcl-id deny | permit mac mac-mask
    

    Émettez cette commande autant de fois de définir selon les besoins toutes les adresses MAC que vous voulez ajouter à la liste. Remplacez le mcl-id par l'identifiant de la liste de MAC.

    Utilisez l'option d'autorisation d'identifier les adresses MAC à exempter de l'authentification. Utilisez l'option de refuser d'empêcher sauter de l'authentification. Remplacez le MAC par une adresse MAC partielle qui peut être utilisée pour sélectionner un groupe de périphériques basés sur une partie commune de l'adresse de matériel, telle que le constructeur que l'identification remplacent le MAC-masque par un masque qui identifie la partie de l'adresse MAC qui devrait être utilisée pour apparier.

    Par exemple, cette commande saute l'authentification pour une adresse MAC simple :

    mypix(config)#mac-list adc permit 00a0.c95d.0282 ffff.ffff.ffff
    

    Dans cet exemple, le masque FFFF.FFFF.FFFF demande au Pare-feu PIX pour apparier chacun des 12 chiffres (six octets) dans l'adresse hexadécimale précédente.

    Cette commande saute l'authentification pour tous les Téléphones IP de Cisco, qui ont l'ID 0003.E3 de matériel :

    mypix(config)#mac-list adc permit 0003.E300.0000 FFFF.FF00.0000
    
  2. Émettez cette commande afin d'appliquer la liste de MAC au serveur d'AAA :

    mypix(config)#aaa mac-exempt match<mcl-id>
    
    

    Remplacez le mcl-id par l'identifiant pour la liste de MAC que vous voulez appliquer.

    Par exemple, cette commande applique la MAC-liste CDA au serveur d'AAA :

    mypix(config)#aaa mac-exempt match<adc>
    
    
  3. Émettez cette commande afin de visualiser les entrées en cours dans une liste spécifique de MAC :

    mypix#show mac-list [mcl-id]
    

    Si vous omettez l'identifiant de liste de MAC, le système affiche les listes tout actuellement configurées de MAC.

  4. Émettez cette commande afin d'effacer toutes les entrées sur une liste de MAC :

    mypix#clear mac-list [mclid]
    

    Si vous omettez l'identifiant de liste de MAC, le système efface toutes les listes actuellement configurées de MAC.

Configurez la base de données locale comme méthode de retour

Cette section décrit comment gérer des utilisateurs dans la base de données locale. Vous pouvez utiliser la base de données locale pour l'authentification d'accès CLI, l'authentification de mode privilégié, l'autorisation de commande, l'authentification d'accès au réseau, et l'authentification et l'autorisation VPN. Vous ne pouvez pas utiliser la base de données locale pour l'autorisation d'accès au réseau. La base de données locale ne prend en charge pas la comptabilité.

Pour le mode de contexte multiple, vous pouvez configurer des noms d'utilisateur dans l'espace d'exécution de système afin de fournir différentes procédures de connexion utilisant la commande login. Cependant, vous ne pouvez configurer aucune commandes d'AAA dans l'espace d'exécution de système.

Remarque:  Si le serveur primaire d'authentification, par exemple, ACS, est haut et accessible, mais le nom d'utilisateur n'existe pas dans la base de données, alors l'ASA ne permet pas au retour à la base de données locale pour rechercher cet utilisateur. L'ASA retombe à la base de données locale ou à la base de données secondaire seulement si le serveur primaire descend.

Procédez comme suit :

  1. Émettez ces commandes afin de définir un compte utilisateur dans la base de données locale :

    • Pour PIX 6.3 :

      hostname(config)#username username {[{nopassword | password 
      password} [encrypted]] [privilege level]}
      
    • Pour PIX/ASA 7.x :

      Syntaxe

      hostname(config)#username user password password1 encrypted
      pix(config)#aaa authentication {telnet | ssh | http | serial} console 
      {LOCAL | server_group [LOCAL]}
      

    Remarque: Si vous utilisez un groupe serveur TACACS+ ou RADIUS pour l'authentification, vous pouvez configurer l'appliance de sécurité pour utiliser la base de données locale comme méthode de secours si le serveur AAA est indisponible. Spécifiez le nom de groupe de serveurs suivi des GENS DU PAYS (les GENS DU PAYS distinguent les majuscules et minuscules). Cisco recommande que vous utilisiez le même nom d'utilisateur et mot de passe dans la base de données locale que le serveur d'AAA parce que la demande de dispositifs de sécurité ne donne aucune indication que la méthode est utilisé.

    Exemple :

    pix(config)#aaa authentication ssh console TACACS+ LOCAL
    

    Vous pouvez alternativement utiliser la base de données locale en tant que votre méthode d'authentification principale (sans le retour) en entrant dans seul LOCAL. Par exemple, émettez cette commande afin de définir un compte utilisateur dans la base de données locale et exécuter l'authentification locale pour une connexion SSH :

    Exemple :

    pix(config)#aaa authentication ssh console LOCAL
    
  2. De PIX 7.x, émettez cette commande afin de configurer un compte d'utilisateur local avec des attributs VPN :

    hostname/contexta(config)#username username attributes
    

    Quand vous émettez les attributs d'un nom d'utilisateur commandent, vous entrent le mode de nom d'utilisateur. Ce sont les commandes disponibles dans ce mode qui doivent être émises afin de configurer le profil utilisateur :

    • group-lock

    • mot de passe-mémoire

    • VPN-Access-heures

    • VPN-filtre

    • VPN-encadrer-IP-adresse

    • VPN-groupe-stratégie

    • VPN-inactif-délai d'attente

    • VPN-session-délai d'attente

    • VPN-simultané-procédures de connexion

    • VPN-tunnel-Protocol

    • webvpn

Telnet virtuel

Bien que vous puissiez authentification d'accès de configure network pour n'importe quel protocole ou service (voyez la correspondance d'authentification d'AAA ou l'authentification d'AAA inclure la commande), vous pouvez authentifier directement avec le HTTP, le telnet, ou le FTP seulement. Un utilisateur doit d'abord authentifier avec un de ces services avant l'autre trafic qui exige l'authentification est laissé. Si vous ne voulez pas permettre le HTTP, le telnet, ou le FTP par les dispositifs de sécurité, mais voulez authentifier d'autres types de trafic, vous pouvez configurer le telnet virtuel. Les telnets d'utilisateur à une adresse IP donnée configurée sur les dispositifs de sécurité, et les dispositifs de sécurité fournit une demande de telnet.

Afin de configurer un serveur telnet virtuel, émettez cette commande :

hostname(config)#virtual telnet <ip_address>

L'argument d'ip_address place l'adresse IP pour le serveur telnet virtuel. Assurez-vous que cette adresse est une adresse inutilisée qui est conduite aux dispositifs de sécurité.

Vous devez configurer l'authentification pour l'accès de telnet à l'adresse virtuelle de telnet aussi bien que les autres services que vous voulez authentifier utilisant la correspondance d'authentification ou l'authentification d'AAA incluent la commande.

Quand un utilisateur unauthenticated se connecte à l'adresse IP virtuelle de telnet, l'utilisateur est défié pour un nom d'utilisateur et mot de passe, et puis authentifié par le serveur d'AAA. Une fois qu'authentifié, l'utilisateur voit le message « authentification réussie. » Puis, l'utilisateur peut avec succès accéder à d'autres services qui exigent l'authentification.

Pour les utilisateurs d'arrivée (de la Sécurité inférieure à une Sécurité plus élevée), vous devez également inclure l'adresse virtuelle de telnet comme interface de destination dans la liste d'accès appliquée à l'interface de source. En outre, vous devez ajouter une commande statique pour l'adresse IP virtuelle de telnet, même si NAT n'est pas prié (utilisant l'aucune commande de nat-control). Une commande NAT d'identité est typiquement utilisée (où vous traduisez l'adresse à elle-même).

Pour les utilisateurs sortants, il y a une autorisation explicite pour le trafic. Cependant, si vous appliquez une liste d'accès à une interface interne, veillez à permettre l'accès à l'adresse virtuelle de telnet. Une déclaration statique n'est pas exigée.

Afin de se déconnecter des dispositifs de sécurité, rebranchez à l'adresse IP virtuelle de telnet. Vous êtes incité à se déconnecter.

Cet exemple affiche comment activer le telnet virtuel avec l'authentification d'AAA pour d'autres services :

hostname(config)#virtual telnet 10.165.202.129
hostname(config)#access-list ACL-IN extended permit tcp any host 10.165.200.225 
eq smtp
hostname(config)#access-list ACL-IN

!--- This is the SMTP server on the inside

hostname(config)#access-list ACL-IN extended permit tcp any host 10.165.202.129 
eq telnet
hostname(config)#access-list ACL-IN 

!--- This is the virtual Telnet address

hostname(config)#access-group ACL-IN in interface outside
hostname(config)#static (inside, outside) 10.165.202.129 10.165.202.129 netmask 
255.255.255.255
hostname(config)#access-list AUTH extended permit tcp any host 10.165.200.225 
eq smtp
hostname(config)#access-list AUTH

!--- This is the SMTP server on the inside

hostname(config)#access-list AUTH extended permit tcp any host 10.165.202.129 
eq telnet
hostname(config)#access-list AUTH

!--- This is the virtual Telnet address

hostname(config)#aaa-server ACS protocol tacacs+
hostname(config)#aaa-server Acs (inside) host 10.1.1.1 TheUauthKey
hostname(config)#aaa authentication match AUTH outside ACS
hostname(config)#aaa authorization match AUTH outside ACS

Vérifiez

Il n'y a actuellement aucune procédure de vérification disponible pour les configurations dans ce document.

Dépannez

Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.

Problème : Incapable d'entrer directement dans le mode enable après authentification dans PIX/ASA

Vous ne pouvez pas entrer directement dans le mode enable après authentification dans PIX/ASA.

Solution

Il n'est pas possible d'entrer directement dans le mode enable car ceci n'est pas pris en charge sur PIX/ASA. Vous devez entrer dans le mode enable manuellement.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 70992