Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte de filtrage IP que nous souhaitons mettre en place. Aujourd’hui, nous allons faire un tour de vue du fonctionnement de nos équipements de sécurité et de routage : les Cisco ASA 5510.
Avant de rentrer dans le vif du sujet, arrêtons-nous pour faire un petit point d’avancement. Nous commençons à avoir des configurations de base relativement solides qui nous permettent de déployer la topologie IP du réseau à chaque session de travail. Le montage de cette topologie ne pose désormais plus de problème particulier. Nous avons réussi à résoudre le problème de la communication entre deux interfaces d’un même ASA. La résolution de ce problème nous a permis de simplifier grandement nos configurations en supprimant toutes les identités NAT des interfaces à security-level 100, soit toutes nos interfaces internes. Je suis content de notre avancement et nous devrions aboutir sur une préparation satisfaisante.
Les ASA sont la gamme d’équipements de sécurité Cisco orientés vers l’entreprise. J’emplois le terme d’équipement de sécurité et non de pare-feu car cette terminologie est bien plus proche de la réalité. Les fonctionnalités d’un ASA dépassent très largement celles de filtrage protocolaire IP, TCP et UDP. Je vous laisse consulter la liste de fonctionnalités sur le site de Cisco. Nous avons également une carte SSM-AIP pour chaque ASA permettant de faire de l’IPS ce que nous utiliserons pendant l’événement si nous nous ennuyons (sait-on jamais).
Nous avons 4 équipements Cisco ASA 5510 à notre disposition. La version logicielle associée est la version « Base » contrairement à son équivalent haut de gamme, « Security Plus ». La différence entre ces deux versions est réellement énorme. La version « Security Plus » permet de transformer deux interfaces 10/100 en interfaces Gigabit, de débloquer l’interface 3 et d’utiliser le port de « Management » en tant qu’interface de données.
La configuration des ASA est légèrement différente de celle de routeurs Cisco classiques. Cette différence est liée au fait que les ASA ne sont pas basés sur un IOS mais un « Security Appliance OS ». Il y a de nombreuses similarités mais suffisamment de différences pour devoir se documenter spécifiquement.
Je ne vais pas pouvoir détailler toute la configuration des Cisco ASA dans ce billet car il ferait de très nombreuses pages. Je vais cependant relever les points clés qui nous ont posé problème.
Tout d’abord, les ASA sont faits pour faire du NAT entre toutes les interfaces par défaut. Ceci vient de leur héritage historique vis-à-vis des PIX. Ce comportement induit la nécessité d’effectuer de très nombreuses règles de NAT. Il est, heureusement, possible de désactiver ce comportement grâce à la commande « no nat-control « . Une fois le nat-control désactivé, il sera possible de router en direct entre les interfaces tant qu’on effectue une descente dans les security-level. Il sera nécessaire de faire une petite règle de NAT afin de remonter les security-level. Il est cependant tout à fait possible d’effectuer une règle de NAT qui ne modifie aucunement les adresses IP ni les ports afin que l’ASA se comporte comme un routeur.
Ensuite, les ASA considèrent par défaut que du trafic entre deux interfaces de même security-level effectue une montée de security-level. Ce comportement implique la création de nouvelles règles de NAT. Afin d’éviter ce comportement et de minimiser les lignes de configuration, il est possible d’utiliser la commande « same-security-traffic permit inter-interface « . Ainsi, vous simplifiez votre configuration ce qui est très intéressant.
Je mets à votre disposition la configuration de l’ASA nommé Fuji afin que vous puissiez y jeter un regard plus approfondi que mes explications assez superficielles. Il manque les ACL de filtrage en mode tournoi car nous ne les avons pas encore intégrées ainsi que le paramétrage avancé de l’OSPF.
