lundi 25 septembre 2017

Cisco ASA – Access Rules

Les Access Rules sont les règles permettant d’autoriser ou non certains trafics à traverser l’ASA. Les Access Rules reposent sur des ACL. La maitrise des ACL permet donc de mettre en place facilement des Access Rules.
Autorisation du trafic sur les interfaces
Un mot sur deux options importantes des interfaces avant de parler des Access Rules.
Dans la page de configuration des interfaces, deux options sont disponibles en bas de page.
La non-activation de ces options est souvent à l’origine de problèmes de communication au sein de l’ASA. Il est donc essentiel de les activer si vous le juger nécessaire.
Pour le trafic concerné par l’une de ces deux options, l’ajout d’une Access Rule autorisant le trafic ne permet pas de se passer de l’activation de ladite option.

Configuration d’une Access Rules

L’ASA possède deux types d’Access Rules.
  • Les Access Rules sur les interfaces
  • L’Access Rule Global
L’ordre d’application des règles est le suivant :
  • Interface access rule
  • Global access rule
  • Implicit deny

Cela signifie que les Access Rules configurées sur les interfaces sont analysées en premières.
Ensuite, l’Access Rule Global est analysée. Elle s’applique à tout le trafic qui travers l’ASA.
Enfin, s’il n’y a toujours pas de Match, le trafic est droppé.
Contrairement aux ACL classiques (sur des routeurs par exemple), les Access Rules de l’ASA ne possèdent pas d’Implicit Deny à la fin.
En revanche, la Global Access Rule possède un Implicit Deny à la fin.
Cela signifie que le trafic qui n’est pas explicitement autorisé par l’une des règles et droppé.
Lors-ce que l’ASA parcours les règles, si un match est trouvé (Permit ou Deny), la recherche s’arrête et l’action est exécutée.

Access Rule basique

Comme toujours, il est préférable d’utiliser des Object dans la configuration des règles.
Voici comment créer une Access Rule permettant d’autoriser le trafic IP allant du Vlan 10 (10.0.10.0 /24) au VLAN 20 (10.0.20.0 / 24). La règle est appliquée en entrée sur l’interface Vlan 10.
Le trafic en réponse est autorisé par défaut.
Pour autoriser les communications initiées depuis le VLAN 20 vers le VLAN 10, la configuration est la suivante.
Il est possible de changer l’ordre des règles dans la liste.

Access Rule globale

Comme cela a été dit, la Global Access Rule s’applique sur tout le trafic qui traverse l’ASA.
L’utilisation de cette règle permet de faciliter la configuration dans certains cas.
Voici un exemple permettant d’autoriser le trafic entre les VLAN 10 et 20.

Access Rule pour rendre un serveur local accessible depuis internet

Comme cela a été détaillé dans l’article sur le NAT, il est indispensable de créer une Access Rule pour rendre accessible un serveur local depuis internet (en plus de créer une règle de NAT Statique).

Outils supplémentaires

Plusieurs outils sont disponibles dans l’ASA pour faciliter la configuration des Access Rules.
Premièrement, il est possible d’afficher un diagramme de la règle. Cela permet de mieux visualiser la règle.
Ensuite, comme toujours l’outil Packet Tracer permet de simuler l’envoi de trafic. L’outil indique alors si le trafic peut arriver à destination.

Enfin, un compteur indique le nombre de nombre de match qu’il y a eu sur chaque entrée des Access Rules.

Cisco ASA – Authentification LDAP et RADIUS

L’ASA permet de recourir à un serveur d’authentification plutôt qu’à une base d’utilisateurs locale. Ainsi il est par exemple possible d’utiliser un serveur RADIUS, TACACS+, LDAP, etc… pour authentifier les utilisateurs qui se connectent en SSH, via l’ASDM, en VPN, etc…
Dans cet article nous verrons comment mettre en place une authentification LDAP et RADIUS et comment l’utiliser lors des connections SSH et ASDM. Bien entendu, cette configuration pourra servir pour d’autres utilisations (VPN notamment).

LDAP

 Dans cette partie nous verrons comment connecter l’ASA à un serveur LDAP Microsoft. Il s’agit de l’une des configurations les plus courantes.

Configuration du serveur LDAP

Voici la configuration du serveur LDAP auquel sera connecté l’ASA dans les exemples suivants.
Une simple OU nommé Firewall a été créé. Elle contient un groupe « admin_ASA » et un utilisateur basique nommé « testeur No1 ».

Configuration de l’ASA

La configuration de l’ASA est simple.
Il convient tout d’abord de créer un groupe de serveurs.
Il est ensuite possible d’ajouter des serveurs dans le groupe.
L’ordre des serveurs dans le groupe est important. Si le premier serveur ne répond pas, l’ASA passe au deuxième et ainsi de suite.
Voici la configuration cohérente avec la configuration du serveur LDAP présentée ci-dessus.
Voici quelques détails sur les options de configuration.
  • Interface Name: interface derrière laquelle se trouve le serveur LDAP
  • Server Type: type de serveur, ici Microsoft
  • Base DN: emplacement dans la hiérarchie où débuter la recherche (ici on considère tout ce qui est dans l’OU Firewall)
  • Scope : ampleur de la recherche
  • Naming Attribute: le RDN – Relative Distinguished Name qui identifie de manière unique les entrées dans l’annuaire (sAMAccountName est l’attribut par défaut chez Microsoft)
  • Login DN: le DN – Distinguished Name avec suffisamment de droit pour lancer des recherches, c’est-à-dire le compte qu’utilise l’ASA pour se connecter au serveur LDAP
  • Login Password: le mot de passe pour ce DN

Pour valider la configuration, vous pouvez configurer l’ASA pour qu’il utilise le groupe de serveurs précédemment créé lors d’une connexion SSH.

RADIUS


Configuration du serveur RADIUS

Il est possible d’utiliser différents types de serveur RADIUS. Un serveur LDAP Windows est capable de faire office de serveur RADIUS à l’aide de sa base d’utilisateurs.
Ici le serveur LDAP permet l’authentification RADIUS pour les utilisateurs faisant partie du groupe « admin_ASA ».

Vous trouverez facilement des procédures de configuration du rôle RADIUS sur un serveur Windows.
Voici un résumé de ce qu’il faut faire.
Pour utiliser un serveur Windows comme serveur RADIUS, il faut ajouter le rôle NPS – Network Policy and Access Services.
Il faut ensuite configurer le serveur NPS pour ajouter une (ou plusieurs) machine autorisée à interroger le serveur RADIUS et choisir un secret partagé.
Il faut ensuite créer une nouvelle stratégie qui définit les utilisateurs autorisés à se connecter en RADIUS.
Enfin, il faut inscrire le serveur NPS dans le domaine Active Directory.

Configuration de l’ASA

La configuration RADIUS est encore plus simple que celle du LDAP.

Tout d’abord il faut créer un groupe de serveurs RADIUS.
Puis il faut ajouter un ou plusieurs serveurs dans ce groupe.
Enfin, pour valider la configuration, vous pouvez configurer l’ASA pour qu’il utilise le RADIUS lors d’une connexion SSH.

Cisco ASA – VPN Remote Access IPsec

Dans cet article nous verrons comment configurer un VPN Remote Access IPsec, permettant à des clients de se connecter à distance au réseau local de l’ASA. Contrairement à l’AnyConnect qui repose sur SSL, celui-ci utilise l’IPsec, comme son nom l’indique. La solution possède des avantages et des inconvénients. La raison principale du choix d’un VPN Remote Access plutôt qu’un AnyConnect est le coût des licences.
Voyons comment mettre en place cette solution.

 Configuration

 Comme toujours pour les VPN, le plus simple est d’utiliser le Wizard pour la première configuration.


Il est possible d’utiliser une authentification par clé partagée ou par certificat. Le plus simple est d’utiliser la clé partagée. L’authentification par certificat est bien entendu la méthode la plus sécurisée.




L’authentification peut se faire à l’aide de la base d’utilisateur locale ou bien à l’aide d’un serveur d’authentification.



Il convient ensuite de définir un pool DHCP pour les clients.




Le NAT exempt permet de choisir le ou les réseaux locaux à exposer, si ceux-ci sont normalement natés lors d’une communication vers l’extérieur. Il est possible de modifier cette configuration par la suite depuis l’écran de paramétrage du NAT (notamment si d’autres réseaux doivent être exposés).
Enfin, il est possible d’activer le Split Tunneling.
Sans Split Tunneling, tout le trafic du client est envoyé dans le VPN. C’est-à-dire que même le trafic à destination d’internet remonte dans le VPN, pour ressortir par l’ASA.
Cela peut être intéressant pour sécuriser la connexion.

Test du VPN

 La configuration est à présent terminée.
 Le client IPsec Cisco n’étant plus maintenu, il est peut être nécessaire de se tourner vers une autre solution.
Ici je vous propose la configuration du client ShrewVPN permettant de se connecter au VPN précédemment configuré.

Troubleshooting et configuration additionnelle
Enfin, si vous ne parvenez pas à initier le VPN, ou si vous souhaitez modifier certains paramètres, je vous invite à consulter la dernière partie de l’article sur le VPN Any Connect. Les explications s’appliquent aussi pour le VPN IPsec.