Dans cet article nous allons voir comment sécuriser notre réseau, en filtrant le trafic sur le réseau grâce à ZPF.
ZPF permettant de filtrer nos communications en nous basant sur des zones, en effet lors de l’implémentation de ZPF nous allons segmenter notre réseau en plusieurs zones.
Puis, nous allons définir la politique à appliquer entre chaque zones c’est-à-dire qu’on va spécifier le trafic autorisé ou interdit entre la zone A et la zone B mais aussi le trafic entre B et A.
ZPF présente plusieurs avantages :

Dans cet exemple nous avons 2 zones, une qui définit l’intérieur de notre réseau et l’autre l’extérieur du réseau.
Voici un exemple un peu plus complexe.
Les actions de ZPF:
Lors de l’analyse du trafic, ZPF peut appliquer 3 actions :
La configuration de ZPF se fait en plusieurs étapes :
Création des zones
Pour les besoins de l’article j’ai réalisé une simulation sous packet tracer. Voilà mon réseau :
Mon réseau est séparé en deux zones, en rouge la zone interne et en bleu la zone externe.
Nous allons donc configurer ZPF sur le router R3 :
R3(config)#zone security INTERNE
R3(config-sec-zone)#exit
R3(config)#zone security EXTERNE
R3(config-sec-zone)#exit
Ces commandes vont nous permettre de créer nos zones, nous avons donc nos deux zones créées.
Création de la class-map
La class-map va nous permettre de spécifier quel trafic nous allons analyser. Nous pouvons analyser le trafic selon le protocole utilisé ( TCP, UDP, ICMP…), mais aussi en fonction d’une ACL.
Pour mon exemple je vais créer une ACL étendue qui va spécifier le trafic sortant de mon réseau interne (192.168.3.0/24) vers tous les autres réseaux.
R3(config)#access-list 101 permit ip 192.168.3.0 0.0.0.255 any
Voilà mon ACL est créée je vais donc pouvoir créer ma class-map :
R3(config)#class-map type inspect INTERNE-EXTERNE-CMAP
R3(config-cmap)#match access-group 101
R3(config-cmap)#match protocol ftp
Ces commandes vont me permettrent de créer ma class-map nommer INTERNE-EXTERNE-CMAP et spécifier qu’il faut analyser le trafic correspondant à mon ACL précédemment créée et le trafic correspondant au protocole ftp.
Voilà notre class-map est prête, nous pouvons bien sûr en créer d’autre pour spécifier d’autres types de trafic.
Création de la policy-map
Nous allons maintenant créer notre policy-map qui va contenir notre class-map et préciser quelle action appliquer à chaque class-map.
R3(config)#policy-map type inspect INTERNE-EXTERNE-PMAP
R3(config-pmap)#class INTERNE-EXTERNE-CMAP
R3(config-pmap-c)#inspect
Ces commandes nous permettent de créer notre policy-map nommer INTERNE-EXTERNE-PMAP, et qui va définir l’action inspect pour notre class-map précédemment créer (nous pouvons bien sûr utiliser une autre des 3 actions possibles).
Création de la zone paire
Nous allons créer une zone-pair qui va nous permettre de définir une zone source et une zone de destination sur lequel nous allons appliquer notre policy-map.
R3(config)#zone-pair security INTERNE-2-EXTERNE source INTERNE destination EXTERNE
R3(config-sec-zone-pair)#service-policy type inspect INTERNE-EXTERNE-PMAP
Ces commandes nous permettent de créer une zone paire nommer INTERNE-2-EXTERNE qui a pour zone source INTERNE et destination EXTERNE c’est-à-dire que cette zone-pair spécifie la politique à appliquer pour le trafic circulant de la zone INTERNE vers la zone EXTERNE, ce trafic sera alors soumis aux politiques définies dans notre policy-map.
Affectation des interfaces a une zone
Nous allons maintenant voir notre dernière étape qui consiste à affecter nos interfaces à une zone.
R3(config)#interface fastEthernet 0/1
R3(config-if)#zone-member security INTERNE
R3(config)#interface se0/0/1
R3(config-if)#zone-member security EXTERNE
Ces commandes nous permettent d’affecter l’interface fastEthernet 0/1 à la zone INTERNE et l’interface se0/0/1 à la zone EXTERNE.
Voilà notre configuration de ZPF est fonctionnelle.
Cet article se termine et nous avons vu ce qu’est ZPF et comment configurer ZPF sur nos équipements Cisco. Cette nouvelle manière de filtrer nos communications et avantageuse dans la mesure où nous n’avons plus à segmenter notre réseau selon des interfaces physiques mais selon un raisonnement logique basées sur des zones. Dans ce cas, uniquement le traffic ayant pour source INTERNE et pour destination EXTERNE ont été traité mais n’oubliez pas créer une autre zone-pair pour autoriser le traffic EXTERNE à revenir vers le traffic INTERNE.
Avez-vous des questions? Utilisez-vous d’autres manières de filtrer vos communications ?
cedric.robert
4 commentaires
Bonjour, Cédric,
Je me permets de vous laisser un petit commentaire pour vous remercier de la clarté de votre article.
J’aurai cependant une question concernant les ZBF.
J’ai créé une topologie sous packet tracer, avec deux routeurs chacun ayant un système NAT activé dessus. (ip nat inside, outside et overload) et un serveur WEB derrière chacun d’eux.
Je suis obligé de créer deux zone pair afin que les équipements puissent communiquer vers le serveur WEB :
- Une zone pair INTERNAL vers WAN
- Une zone pair WAN vers INTERNAL
Sur ces deux zone pair la même politique est appliquée sans quoi rien ne communique…
Si j’ai bien compris une seule zone pair avec un inpect devrait suffire ?
Ci-dessous la config de test utilisée :
Current configuration : 1446 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname Router
!
!
!
!
!
!
!
!
!
!
!
!
ip ssh version 1
!
!
spanning-tree mode pvst
!
class-map type inspect match-any ALL_PROTO
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-all MYNETWORK
match access-group 101
match protocol http
!
policy-map type inspect ALL_PROTO_POLICY
class type inspect ALL_PROTO
inspect
!
policy-map type inspect MYNETWORKPMAP
class type inspect MYNETWORK
inspect
!
!
!
zone security WAN
zone security INTERNAL
zone-pair security INTERNAL2WAN source INTERNAL destination WAN
service-policy type inspect MYNETWORKPMAP
!
interface FastEthernet0/0
ip address 192.168.2.254 255.255.255.0
zone-member security INTERNAL
ip nat inside
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/1/0
ip address 172.16.100.1 255.255.255.0
zone-member security WAN
ip nat outside
ipv6 ospf cost 781
!
interface Vlan1
no ip address
shutdown
!
router rip
version 2
network 192.168.2.0
!
ip nat inside source list 101 interface Serial0/1/0 overload
ip nat inside source static tcp 192.168.2.250 80 172.16.100.1 80
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/1/0
!
!
access-list 101 permit ip 192.168.2.0 0.0.0.255 any
!
!
!
!
!
line con 0
line vty 0 4
login
!
!
!
end
Je sèche…
Merci d’avance
Bonjour nemorelax,
Je me permet de répondre à la place de Cédric.
Les zones pairs définissent une source vers une destination. S’il n’existe pas de zones pairs avec des règles appliqués à cette zone pair la communication entre deux zones est systématiquement interdite. C’est pourquoi il est nécessaire de faire deux zones pairs (en inversant les sources et les destinations) si on veut que la communication passe entre les deux zones.
Dans ton cas si tu veux faire passer le traffic depuis la zone WAN vers INTERNAL tu créer une zone pair qui a pour source WAN et pour destination INTERNAL.
Si on définit pas de règles pour le traffic qui vient de la zone INTERNAL vers la zone WAN alors le traffic de retour sera automatiquement supprimé.
En espérant que mes indications t’ont aidés
Bonjour Loic et merci d’avoir pris le temps de répondre aussi vite !!
En fait je pensais qu’a partir du moment ou une connexion était initié à partir du réseau INTERNAL (dans mon cas) à l’aide d’un « inspect », l’IOS allait créer une règle permettant le trafic de retour, un peu à la façon des CBAC…
Ma problématique étant d’autoriser le retour initié par mon réseau interne…
Ici il faudrait donc que j’applique deux zone pair avec la même politique ? N’est ce pas moyen au niveau sécurité ?
Je pense que quelque chose m’échappe…
Dans l’exemple de Cédric, il n’a pas eu besoin de créer une zone-pair pour le trafic de retour ou je n’ai rien compris ? (ce qui est fort probable)
Merci encore
Il ne l’a pas fait mais c’est nécessaire
…. Je vais le préciser d’ailleurs (merci pour l’info).
Pour autoriser le traffic retour au lieu d’utiliser le ZPF je te recommande les ACLs réflexives qui marchent super bien aussi