Cisco – Implémenter un firewall ASA/PIX en mode multi-context

Vous connaissez sans doute le principe des outils VMWARE, XEN, VIRTUAL BOX et autres permettant la virtualisation des machines physiques afin de mutualiser l’exploitation de divers types de systèmes d’exploitations. Ce concept a subit certaines évolutions, notamment dans le domaine des équipements de sécurité. Le sujet sur lequel je m’attarde n’a rien de nouveau, mais il présente l’avantage de pouvoir mutualiser les appliances de sécurité PIX & ASA de Cisco en de multiples instances logique.

Le concept:

Certains constructeurs dont Juniper (Netscreen), Cisco ou Fortinet pour ne pas les citer, intègrent des fonctionnalités permettant la virtualisation des appliances. Le concept initial est relativement simple, mutualiser une appliance physique en de multiples instances logiques. On peut prendre l’image (ceci n’est qu’une représentation du concept) de VMWARE avec son hyperviseur (*) de niveau 1 ESX SERVER permettant d’héberger sur un même système hôte plusieurs systèmes hotes (windows 2003 server, Linux Redhat etc …).

(*) Les hyperviseurs:

  • Un hyperviseur de niveau 1 est un système composé d’un noyau qui s’exécute directement sur une plateforme matérielle, exemple VMWARE ESX SERVER, ZEN etc …

Hard –> Hyperviseur niveau 1 (Esx server, Hyper-V ….) –> OS invité (Linux, Unix, Windows …).

  • Un hyperviseur de niveau 2 est un soft s’exécutant par-dessus un système d’exploitation. Le noyau n’est pas en interaction direct avec la plateforme matérielle à l’exemple de VMWARE SERVER, Virtual Box, QEMU et autre virtual PC de microsoft permettant la virtualisation des hôtes par-dessus un système hôte en charge de l’hyperviseur.

Hard –> OS (Windows XP, 7, Linux …) –> Hyperviseur niveau 2 (QEMU, VIRTUAL PC, VMWARE SERVER, Dynamips etc ..) –> OS invité (Linux, Unix, Windows, IOS …).

Dans notre cas de figure nous restons dans un concept d’hyperviseur de niveau 1, en raison de l’interaction directe des context avec le noyau.

Un même concept, une vision différente:

Cette technologie est utilisée par plusieurs constructeurs, avec notamment Juniper est Fortinet en tête. Checkpoint a poussé plus loin le concept en permettant la mise en œuvre d’appliance sur machine virtuel (Virtualisation du MDS).

Fortinet (FortiOS): VDOM (Virtual DOMain).

  • Ce mécanisme permet de mettre en place plusieurs FortiGates logiques avec un seul équipement (Antispam, Web Filtering, Antivirus / Antispyware, Intrusion , Prevention (IPS), Firewall / VPN, Bandwidth Shaping). Ce thème fera l’objet d’un article dédié prochainement.

Juniper/netscreen (screenOS): VSYS (Virtual System).

  • Ce concept permet sensiblement les mêmes fonctionnalités que la gamme Fortinet.

Les limites du mode multi-context:

Avant de continuer, il faut savoir que le passage en mode multi-context implique la perte de plusieurs fonctions:

  • Mise en œuvre de routage dynamique.
  • Un contexte permet uniquement la mise en œuvre de routes statique. Il n’est pas possible de mettre en œuvre du routage de type OSPF, RIP, EIGRP en mode multi-context.
  • Les VPN (IPSEC, SSL ….).
  • Le routage multicast.
  • Threat Detection.

Les étapes de mise en oeuvre:

1.       Passer le système en mode multi-context.
2.       Redémarrer l’équipement.
3.       Supprimer le context admin par defaut (ceci n’est pas obligatoire).
4.       Créer un premier context.
5.       Attribuer les interfaces en fonction des besoins du context.
6.       Créer le fichier de configuration de l’instance (context).
7.       Mise en place de la politique du context.
8.       Réitérer les étapes 3 à 6 en fonction des besoins.

Afin de mieux comprendre l’implémentation, j’ai réalisé une maquette sous GNS3 par le biais d’une mise en situation. J’ai créé deux pare-feu logiques que l’on appellent des context , un dédié à l’administration des différents pare-feu logique et le second dédié à la sécurisation de la communication entre deux VRF.

ci-dessous le synoptique:

Mise en œuvre du mode Multi context :

Passer l’équipement en mode Multi context :

Suite à l’insertion de la commande il est nécessaire de redémarrer l’équipement.

FW2(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
The old running configuration file will be written to flash
 
The admin context configuration will be written to flash
The new running configuration file was written to flash
Security context mode: multiple
***
*** — SHUTDOWN NOW —
***
*** Message to all terminals:
***
***   change mode
Rebooting….
Booting system, please wait…

Suite au redémarrage, consulter la configuration. Celle-ci ressemblera à ce que vous voyez ci-dessous:

Comme vous pouvez le voir dans la configuration, un context par défaut nommé admin est inscrit.

FW2# sh run
: Saved
:
PIX Version 8.0(3) <system>
!
hostname FW2
enable password 8Ry2YjIyt7RRXU24 encrypted
no mac-address auto
!
interface Ethernet0
shutdown
!
interface Ethernet1
shutdown
!
interface Ethernet2
shutdown
!
interface Ethernet3
shutdown
!
interface Ethernet4
shutdown
!
class default
limit-resource All 0
limit-resource ASDM 5
limit-resource SSH 5
limit-resource Telnet 5
!
ftp mode passive
pager lines 24
no failover
no asdm history enable
arp timeout 14400
console timeout 0
 
admin-context admin
context admin
config-url flash:/admin.cfg
!
prompt hostname context
Cryptochecksum:434c2e098b81afbfef79523ac3508efc
: end

Supprimé le context admin par défaut:

Cette action n’est pas un prérequis, ça permet juste de reprendre l’ensemble depuis le début dans un but pédagogique.

FW2(config)# clear configure context
WARNING: Removing all contexts in the system
Proceed with removing the contexts? [confirm]
Removing context ‘admin’ (1)… Done

Vérifions si le context est toujours présent:

FW2(config)# show context
Context Name      Class      Interfaces           URL
 
Total active Security Contexts: 0

Créer un premier context :

Ayant supprimé précédemment le context admin, nous allons créer une nouvelle instance administrative nommée lan-admin.

Le context de type « admin-context » est similaire à un autre context, sauf qu’il permet l’administration des autres context qui eux ne disposent pas de cette spécificité. Il est nécessaire par la suite de créer un compte disposant des privilèges nécessaires afin de permettre l’administration des autres context depuis notre context d’administration.

FW2(config)# admin-context lan-admin
Creating context ‘lan-admin’… Done. (2)

Passer dans le context lan-admin :

FW2(config)# context lan-admin
FW2(config-ctx)# ?

Création du context lan-admin :

FW2(config)# admin-context lan-admin
Creating context ‘lan-admin’… Done. (2)

Vérifions si le context a bien été créé :

FW2(config)# show running-config context
admin-context lan-admin
context lan-admin
!

Vous pouvez constater qu’il n’y a pas de fichier de configuration pour le moment.

Création du fichier de configuration du context lan-admin :

Passons maintenant à la création du fichier de configuration de la partition lan-admin.

Comme l’indique le prompt, nous somme dans le contexte : FW2(config-ctx)

FW2(config-ctx)# config-url flash:lan-admin.cfg
INFO: Converting flash:lan-admin.cfg to flash:/lan-admin.cfg
 
WARNING: Could not fetch the URL flash:/lan-admin.cfg
INFO: Creating context with default config
INFO: Admin context will take some time to come up …. please wait.

Passons à l’allocation des ressources du context lan-admin :

Nous allons procéder à une attribution des ressources, à savoir l’ajout d’une interface d’administration.

FW2(config-ctx)# allocate-interface eth2 admin
FW2(config-ctx)#

Création du second context – data-mobility :

Ce second context sera dédié aux échanges entre deux périmètres réseaux. Afin de simplifier l’intégration nous allons éditer les informations du premier afin de l’adapter au second.

FW2(config)# context data-mobility
 
Creating context ‘data-mobility’… Done. (3)
 
FW2(config-ctx)# allocate-interface eth0
 
FW2(config-ctx)# allocate-interface eth1
 
FW2(config-ctx)# config-url flash:/data-mobility
 
 
WARNING: Could not fetch the URL flash:/data-mobility
 
INFO: Creating context with default config
 
FW2(config-ctx)#

Vérifier l’application des nouveaux context :

FW2(config)# show context
 
Context Name      Class      Interfaces           URL
 
*lan-admin        default    Ethernet2            flash:/lan-admin.cfg
 
data-mobility    default    Ethernet0,Ethernet1  flash:/data-mobility
 
 
Total active Security Contexts: 2
 
FW2(config)#

Configuration des context

Configuration du context lan-admin:

Passer depuis le context data-mobility ou l’instance system vers le context lan-admin :

Il est  possible de basculer d’un context vers un autre sans que ce soit l’instance system ou un context de type context-admin. La commande « changeto context “le nom du context” » permet de réaliser cette action à condition de disposer d’un compte avec les privilèges administrateurs déclarés sur le context-admin.

FW2(config)# changeto context lan-admin

Configuration de l’instance:

Je commence par la configuration des différents éléments qui me permettront la prise en main à distance pour l’administration de l’équipement.

FW2/lan-admin (config)#interface ethernet 2
 
FW2/lan-admin (config-if)#nameif admin
 
FW2/lan-admin (config-if)#security-level 100
 
FW2/lan-admin (config-if)#ip address 192.168.1.2 255.255.255.0
 
FW2/lan-admin(config)# username admin password admin privilege 15
 
FW2/lan-admin(config)# aaa authentication enable console LOCAL
 
FW2/lan-admin(config)#  crypto key gen rsa mod 1024
 
INFO: The name for the keys will be: <Default-RSA-Key>
 
Keypair generation process begin. Please wait…
 
FW2/lan-admin(config)# ssh 192.168.1.0 255.255.255.0 admin
 
FW2/lan-admin(config)# aaa authentication SSH console LOCAL
 
FW2/lan-admin(config)#

Configuration du context data-mobility:

Passer depuis le context lan-admin vers data-mobility :

FW2(config)# changeto context data-mobility

Plutôt que de reprendre toute la configuration vous trouverez ci-dessous la configuration du context.

FW2/data-mobility(config)# sh run
 
: Saved
 
:
 
PIX Version 8.0(3) <context>
 
!
 
hostname data-mobility
 
enable password 8Ry2YjIyt7RRXU24 encrypted
 
names
 
!
 
interface Ethernet1
 
nameif if_mobility
 
security-level 100
 
ip address 10.1.1.1 255.255.255.0
 
!
 
interface Ethernet0
 
nameif if_data
 
security-level 0
 
ip address 172.16.1.1 255.255.255.0
 
!
 
passwd 2KFQnbNIdI.2KYOU encrypted
 
access-list mobile-to-data extended permit icmp 10.1.1.0 255.255.255.0 172.16.1.0 255.255.255.0
 
access-list data-to-mobile extended permit icmp 172.16.1.0 255.255.255.0 10.1.1.0 255.255.255.0
 
pager lines 24
 
logging enable
 
logging console debugging
 
mtu if_mobility 1500
 
mtu if_data 1500
 
icmp unreachable rate-limit 1 burst-size 1
 
no asdm history enable
 
arp timeout 14400
 
access-group mobile-to-data in interface if_mobility
 
access-group data-to-mobile in interface if_data
 
timeout xlate 3:00:00
 
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
 
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
 
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
 
timeout uauth 0:05:00 absolute
 
no snmp-server location
 
no snmp-server contact
 
telnet timeout 5
 
ssh timeout 5
 
!
 
class-map inspection_default
 
match default-inspection-traffic
 
!
 
!
 
policy-map type inspect dns preset_dns_map
 
parameters
 
message-length maximum 512
 
policy-map global_policy
 
class inspection_default
 
inspect dns preset_dns_map
 
inspect ftp
 
inspect h323 h225
 
inspect h323 ras
 
inspect netbios
 
inspect rsh
 
inspect rtsp
 
inspect skinny
 
inspect esmtp
 
inspect sqlnet
 
inspect sunrpc
 
inspect tftp
 
inspect sip
 
inspect xdmcp
 
!
 
service-policy global_policy global
 
Cryptochecksum:9ff7bf69f960e3e89781c2eb92c9575b
 
: end

Tests de la communication depuis le context data-mobility :

Testons la communication entre la vrf_mobility et la vrf_data

Ping depuis la vrf_mobility

mobility#ping 172.16.1.254
 
Type escape sequence to abort.
 
Sending 5, 100-byte ICMP Echos to 172.16.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/27/44 ms
mobility#

Trace depuis le PIX de la communication :

FW2/data-mobility(config)# logging enable %PIX-7-609001: Built local-host if_mobility:10.1.1.254
 
%PIX-7-609001: Built local-host if_data:172.16.1.254
 
%PIX-6-302020: Built outbound ICMP connection for faddr 172.16.1.254/0 gaddr 10.1.1.254/8 laddr 10.1.1.254/8
 
%PIX-6-302020: Built inbound ICMP connection for faddr 172.16.1.254/0 gaddr 10.1.1.254/8 laddr 10.1.1.254/8
 
%PIX-6-302021: Teardown ICMP connection for faddr 172.16.1.254/0 gaddr 10.1.1.254/8 laddr 10.1.1.254/8
 
%PIX-6-302021: Teardown ICMP connection for faddr 172.16.1.254/0 gaddr 10.1.1.254/8 laddr 10.1.1.254/8
 
%PIX-7-609002: Teardown local-host if_data:172.16.1.254 duration 0:00:04
 
%PIX-7-609002: Teardown local-host if_mobility:10.1.1.254 duration 0:00:04

Ping depuis la vrf_data

data#ping 10.1.1.254
 
Type escape sequence to abort.
 
Sending 5, 100-byte ICMP Echos to 10.1.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/52 ms
 
data#

Trace depuis le PIX de la communication :

FW2/data-mobility(config)# %PIX-7-609001: Built local-host if_data:172.16.1.254
%PIX-7-609001: Built local-host if_mobility:10.1.1.254
%PIX-6-302020: Built inbound ICMP connection for faddr 172.16.1.254/6 gaddr 10.1.1.254/0 laddr 10.1.1.254/0
%PIX-6-302020: Built outbound ICMP connection for faddr 172.16.1.254/6 gaddr 10.1.1.254/0 laddr 10.1.1.254/0
%PIX-6-302021: Teardown ICMP connection for faddr 172.16.1.254/6 gaddr 10.1.1.254/0 laddr 10.1.1.254/0
%PIX-6-302021: Teardown ICMP connection for faddr 172.16.1.254/6 gaddr 10.1.1.254/0 laddr 10.1.1.254/0
%PIX-7-609002: Teardown local-host if_mobility:10.1.1.254 duration 0:00:04
%PIX-7-609002: Teardown local-host if_data:172.16.1.254 duration 0:00:04

Laisser une réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *