Comprendre la conception du pare-feu à politique basée sur les zones

Introduction

Ce document décrit le modèle de configuration du jeu de fonctions Cisco IOS® Firewall, ZFW (Zone-Based Policy Firewall).

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

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

Ce nouveau modèle de configuration propose des politiques intuitives pour les routeurs à interfaces multiples, une plus grande granularité de l'application de la politique de pare-feu et une politique de déni par défaut qui empêche le trafic entre les zones de sécurité du pare-feu jusqu'à ce qu'une politique explicite soit appliquée pour permettre un trafic souhaitable.

Quasiment toutes les fonctionnalités du pare-feu classique de Cisco IOS mises en application avant la version 12.4(6)T du logiciel Cisco IOS sont prises en charge par cette nouvelle interface d'inspection de la politique selon des zones :

• Inspection dynamique des paquets

• Pare-feu Cisco IOS sensible à VRF

• Filtrage des URL 

• Réduction du déni de service (DoS)

La version 12.4(9)T du logiciel Cisco IOS a ajouté la prise en charge ZFW pour la session/connexion par classe et des limites de débit, aussi bien que l'inspection de l'application et le contrôle :

• HTTP

• Post Office Protocol (POP3), Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol/Enhanced Simple Mail Transfer Protocol (SMTP/ESMTP)

• Sun Remote Procedure Call (RPC)

• Applications de messagerie instantanée (IM) :

  • Microsoft Messenger

  • Yahoo! Messenger

  • AOL Instant Messenger

• Partage de fichiers en pair à pair (P2P) :

  • BitTorrent

  • KaZaA

  • Gnutella

  • eDonkey

La version 12.4(11)T du logiciel Cisco IOS a ajouté des statistiques pour un ajustement plus facile de la protection DoS.

Certaines fonctionnalités et capacités du pare-feu classique de Cisco IOS ne sont pas encore prises en charge dans un ZFW dans la version 12.4(15)T du logiciel Cisco IOS :

• Proxy d'authentification

• Basculement dynamique du pare-feu

• MIB unifié de pare-feu

• Inspection dynamique d'IPv6

• Assistance aux pannes TCP

ZFW améliore d'une manière générale les performances de Cisco IOS pour la plupart des activités d'inspection du pare-feu. Ni Cisco IOS ZFW ni le pare-feu classique ne prennent en charge l'inspection dynamique du trafic multidiffusion.

Aperçu de la politique selon des zones

L'inpection dynamique du pare-feu classique de Cisco IOS (auparavant connu sous le nom de contrôle d'accès selon le contexte ou CBAC) a utilisé le modèle de configuration sur la base d'une interface, dans lequel une politique d'inspection dynamique a été appliquée à une interface. Tout le trafic transitant par cette interface a reçu la même stratégie d'inspection. Ce modèle de configuration a limité la granularité des politiques de pare-feu et a entraîné la confusion de l'application appropriée des politiques de pare-feu, en particulier dans les scénarios où les politiques de pare-feu doivent être appliquées entre plusieurs interfaces.

Le pare-feu de la politique selon les zones (également connu sous le nom de pare-feu de zone politique ou ZFW) change la configuration du pare-feu de l'ancien modèle basé sur l'interface pour un modèle plus souple et plus facilement compréhensible basé sur des zones. Les interfaces sont attribuées aux zones et la politique d'inspection est appliquée au trafic qui se déplace entre les zones. Les politiques interzonales offrent une flexibilité et une granularité considérables, afin que différentes politiques d'inspection puissent être appliquées aux multiples groupes hôtes connectés à la même interface du routeur .

Les politiques de pare-feu sont configurées avec le langage de stratégie Cisco (CPL), qui utilise une structure hiérarchique pour définir l'inspection des protocoles réseau et des groupes d'hôtes auxquels l'inspection peut être appliquée.

Modèle de la politique de configuration selon des zones

ZFW change complètement la façon dont vous configurez une inspection de pare-feu Cisco IOS, comparativement au pare-feu classique de Cisco IOS.

Le premier changement majeur de la configuration du pare-feu consiste en la mise en place d'une configuration sur la base de zones. Le pare-feu Cisco IOS est la première fonctionnalité de défense contre des menaces du logiciel Cisco IOS pour mettre en application un modèle de configuration par zone. D'autres fonctions peuvent adopter le modèle de zone au fil du temps. Le modèle de configuration sur la base d'interface (ou CBAC) de l'inspection dynamique du pare-feu classique de Cisco IOS qui utilise l'ensemble de commande ip inspect est conservé pendant un certain temps. Cependant, peu de nouvelles fonctionnalités, voire aucune, sont configurables avec l'interface de ligne de commande (CLI) classique. ZFW n'utilise pas l'inspection dynamique ou les commandes CBAC. Les deux modèles de configuration peuvent être utilisés simultanément sur des routeurs, mais pas combinés sur des interfaces. Une interface ne peut pas être configurée en tant que membre de la zone de sécurité et en même temps configurée pour ip inspect .

Les zones établissent les frontières de sécurité de votre réseau. Une zone définit une borne où le trafic est soumis aux restrictions politiques à mesure qu'elle se dirige vers une autre region de votre réseau. La stratégie ZFW par défaut entre les zones est deny all. Si aucune stratégie n'est explicitement configurée, tout le trafic qui se déplace entre les zones est bloqué. Il s'agit d'une différence significative par rapport au modèle d'inspection avec état où le trafic était implicitement autorisé jusqu'à ce qu'il soit explicitement bloqué avec une liste de contrôle d'accès (ACL).

Le deuxième changement majeur est l'introduction d'un nouveau langage de stratégie de configuration appelé CPL. Les utilisateurs familiarisés avec l'interface de ligne de commande (MQC) de qualité de service modulaire (QoS) du logiciel Cisco IOS peuvent reconnaître que le format est similaire à l'utilisation QoS de cartes de classe pour spécifier quel trafic est affecté par l'action appliquée dans une carte de stratégie.

Règles Pour L'Application De Pare-Feu De Stratégie Basée Sur Les Zones

L’appartenance des interfaces réseau des routeurs dans les zones est soumise à plusieurs règles qui régissent le comportement des interfaces, tout comme le trafic qui se déplace entre les interfaces membres des zones :

• Une zone doit être configurée avant que des interfaces puissent être affectées à la zone.

• Une interface peut être affectée à seulement une zone de sécurité.

• Tout trafic en direction et en provenance d'une interface donnée est implicitement bloqué quand l'interface est affectée à une zone, excepté pour le trafic en direction et en provenance d'autres interfaces dans la même zone et le trafic vers toute interface sur le routeur.

• Le trafic est implicitement autorisé à s'écouler par défaut parmi les interfaces qui sont membres de la même zone.

• Afin d'autoriser le trafic en provenance et à destination d'une interface membre d'une zone, une stratégie qui autorise ou inspecte le trafic doit être configurée entre cette zone et toute autre zone.

• La zone auto est la seule exception à la politique par défaut de refus de tout. Tout trafic vers n'importe quelle interface de routeur est autorisé jusqu'à ce que le trafic soit explicitement refusé.

• Le trafic ne peut pas s'écouler entre une interface d'un membre de zone et toute interface qui n'est pas un membre de zone. Les actions de passage, inspection et abandon peuvent seulement être appliquées entre deux zones.

• Les interfaces qui n'ont pas été attribuées à une zone fonctionnent comme des ports de routeur classiques et peuvent toujours utiliser une configuration CBAC/inspection avec état classique.

• S'il est nécessaire qu'une interface sur le boîtier ne fasse pas partie de la politique de zone/pare-feu. Il peut toujours être nécessaire de placer cette interface dans une zone et de configurer une politique « passe tout » (une sorte de politique factice) entre cette zone et toute autre zone vers laquelle le flux de trafic est souhaité.

• À partir du comportement précédent, il est expliqué que, si le trafic doit circuler entre toutes les interfaces d'un routeur, toutes les interfaces doivent faire partie du modèle de zonage (chaque interface doit être membre d'une zone ou d'une autre).

• La seule exception au comportement précédent, l'approche de refus par défaut, est le trafic entrant et sortant du routeur, qui est autorisé par défaut. Une politique explicite peut être configurée pour restreindre ce trafic.

Conception de la sécurité du réseau basée sur les zones

Une zone de sécurité doit être configurée pour chaque région de sécurité relative au sein du réseau, de sorte que toutes les interfaces affectées à la même zone soient protégées avec un niveau de sécurité similaire. Par exemple, considérez un routeur d'accès avec trois interfaces :

• Un interface connectée à l'Internet public.

• Une interface connectée à un LAN privé qui ne doit pas être accessible depuis l'Internet public.

• Une interface connectée à une zone démilitarisée de service Internet (DMZ), où un serveur Web, système de noms de domaine (DNS) et serveur de messagerie électronique doivent être accessibles à l'Internet public.

Chaque interface de ce réseau est affectée à sa propre zone, bien que vous puissiez autoriser un accès varié depuis l'Internet public à des hôtes spécifiques dans la DMZ et des politiques d'utilisation d'applications variées pour les hôtes dans le LAN protégé (voir l'image 1).

Image 1 : Topologie de zone de sécurité de base

Topologie de zone de sécurité de base

Dans cet exemple, chaque zone contient seulement une interface. Si une interface supplémentaire est ajoutée à la zone privée, les hôtes connectés à la nouvelle interface dans la zone peuvent transmettre le trafic à tous les hôtes sur l'interface actuelle dans la même zone. En outre, le trafic hôte vers les hôtes d'autres zones est également affecté par les politiques actuelles.

Généralement, le réseau d’exemple a trois politiques principales :

• Connectivité de zone privée à Internet

• Connectivité de zone privée aux hôtes DMZ

• Connectivité de zone Internet aux hôtes DMZ

Comme la DMZ est exposée à l'Internet public, les hôtes DMZ peuvent être soumis à une activité indésirable de la part d'individus malveillants qui peuvent endommager un ou plusieurs hôtes DMZ. Si aucune politique d'accès n'est fournie pour que des hôtes DMZ atteignent soit des hôtes de zone privés soit des hôtes de zone Internet, alors les personnes qui ont compromis les hôtes DMZ ne peuvent pas utiliser les hôtes DMZ pour conduire toute nouvelle attaque contre des hôtes privés ou Internet. ZFW impose une position de sécurité prohibitive par défaut. Par conséquent, à moins que les hôtes DMZ aient spécifiquement accès à d'autres réseaux, d'autres réseaux sont sauvegardés contre toutes les connexions des hôtes DMZ. De même, aucun accès n'est donné aux hôtes Internet pour accéder aux hôtes de zone privée, ainsi les hôtes de zone privée sont sûrs d'avoir un accès non désiré par des hôtes Internet.

Utiliser le VPN IPSec avec le pare-feu de stratégie basé sur les zones

Les améliorations récentes de VPN IPSec simplifient la configuration de la politique de pare-feu pour la connectivité de VPN. L'interface VTI (Virtual Tunnel Interface) IPSec et GRE+IPSec permettent de confiner les connexions VPN site à site et client à une zone de sécurité spécifique en plaçant les interfaces de tunnel dans une zone de sécurité spécifiée. Des connexions peuvent être isolées dans un DMZ VPN si la connectivité doit être limitée par une politique spécifique. Ou, si la connectivité de VPN est implicitement reconnue comme sûre, la connectivité de VPN peut être placée dans la même zone de sécurité que le réseau interne reconnu comme sûr.

Si un IPSec non-VTI est appliqué, la politique de pare-feu de connectivité VPN requiert un examen minutieux pour assurer la sécurité. La stratégie de zone doit autoriser spécifiquement l'accès par une adresse IP pour les hôtes de site distant ou les clients VPN si les hôtes sécurisés se trouvent dans une zone différente de la connexion chiffrée du client VPN au routeur. Si la stratégie d'accès n'est pas correctement configurée, les hôtes qui doivent être protégés peuvent être exposés à des hôtes indésirables, potentiellement hostiles. Reportez-vous à l' Utilisation de VPN avec la politique de pare-feu selon les zones pour une plus ample discussion sur le concept et la configuration.

Configuration de la politique linguistique de Cisco (CPL)

Cette procédure peut être utilisée pour configurer un ZFW. L'ordre des étapes n'est pas important, mais quelques procédures doivent être effectuées dans l'ordre. Par exemple, vous devez configurer une carte-classe avant d'affecter une carte-classe à une carte-politique. De même, vous ne pouvez pas affecter une carte-politique à une zone-paire jusqu'à ce que vous ayez configuré la politique. Si vous essayez de configurer une section qui se fonde sur une autre partie de la configuration que vous n'avez pas configurée, le routeur répond avec un message d'erreur.

1. Définissez les zones.

2. Définissez des zone-paires.

3. Définissez les cartes-classes qui décrivent le trafic qui doit avoir une politique appliquée tandis qu'il traverse une zone-paire.

4. Définissez des cartes-politiques pour appliquer une action à votre trafic de cartes-classes.

5. Appliquez les cartes-politiques aux zones-paires.

6. Affectez les interfaces aux zones.

Configurer des cartes de classe de pare-feu basées sur des zones

Les cartes-classes définissent le trafic que le pare-feu sélectionne pour l'application de la politique. Les cartes-classes de la couche 4 trient le trafic sur la base des critères énumérés ici. Ces critères sont spécifiés avec la commande match dans un class-map :

• Groupe d'accès - Un ACL standard, étendu ou nommé peut filtrer le trafic sur la base de l'adresse IP de source et de destination et du port de source et de destination.

• Protocole : les protocoles de couche 4 (TCP, UDP et ICMP) et les services d'application tels que HTTP, SMTP, DNS, etc. Tout service connu ou défini par l'utilisateur connu du mappage d'application de port peut être spécifié.

• Carte-classe - Une carte-classe subordonnée qui fournit des critères de correspondance supplémentaires peut être emboîtée dans une autre carte-classe.

• Not : le critère not spécifie que tout trafic qui ne correspond pas à un service (protocole), un groupe d'accès ou une carte-classe subordonnée spécifié est sélectionné pour la carte-classe.

Combiner les critères de correspondance : Tous les critères et Tous les critères

Les cartes-classes peuvent appliquer les opérateurs correspondance-n'importe quel ou correspondance-tout pour déterminer comment appliquer les critères de correspondance. Si match-any est spécifié, le trafic ne doit répondre qu'à l'un des critères de correspondance du class-map. Si match-all est spécifié, le trafic doit correspondre à tous les critères de la carte de classe pour appartenir à cette classe particulière.

Les critères de correspondance doivent être appliqués dans l'ordre de plus spécifique à moins spécifique si le trafic répond à plusieurs critères. Par exemple, considérez cette carte-classe :

class-map type inspect match-any my-test-cmap
 match protocol http
 match protocol tcp

Le trafic HTTP doit rencontrer le protocole de correspondance http d'abord pour s'assurer que le trafic est traité par les capacités spécifiques du service de l'inspection HTTP. Si les lignes de correspondance sont inversées, de sorte que le trafic rencontre l'instruction TCP de protocole de correspondance avant de la comparer au protocole de correspondance http, le trafic est simplement classé comme trafic TCP et inspecté en fonction des capacités du composant Inspection TCP du pare-feu. Il s'agit d'un problème pour certains services tels que FTP, TFTP et divers services multimédias et de signalisation de voix tels que H.323, SIP, Skinny, RTSP et d'autres. Ces services requièrent des capacités d'inspection supplémentaires pour identifier les activités plus complexes de ces services.

Appliquer une liste de contrôle d’accès comme critère de correspondance

Les cartes-classes peuvent appliquer un ACL en tant qu'un des critères de correspondance pour l'application de la politique. Si un class-map ne correspond qu'à un critère est une ACL et que le class-map est associé à un policy-map qui applique l'action inspect, le routeur applique l'inspection TCP ou UDP de base pour tout le trafic autorisé par l'ACL, à l'exception de celui pour lequel ZFW fournit une inspection sensible aux applications. Ceci inclut (sans s'y limiter) FTP, SIP, Skinny (SCCP), H.323, Sun RPC et TFTP. Si l'inspection spécifique à l'application est disponible et que l'ACL permet le canal primaire ou de contrôle, tout canal secondaire ou média associé au primaire/contrôle est autorisé, indépendamment de l'autorisation de trafic par ACL.

Si une carte-classe applique seulement ACL 101 comme critère de correspondance, un ACL 101 apparaît tel que :

access-list 101 permit ip any any

Tout le trafic est autorisé dans la direction de la politique de service appliquée à une zone-paire donnée, et le trafic de retour qui correspond à cela est autorisé dans la direction opposée. Par conséquent, ACL doit appliquer la restriction pour limiter le trafic aux types spécifiques désirés. Notez que la liste PAM inclut des services d'application tels que HTTP, NetBIOS, H.323 et DNS. Cependant, en dépit de la connaissance de PAM de l'utilisation spécifique d'une application d'un port donné, le pare-feu n'applique qu'une capacité suffisante spécifique à l'application pour s'adapter aux exigences bien connues du trafic de l'application. Ainsi, le trafic d'application simple tel que telnet, SSH et d'autres applications à canal unique sont inspectés comme TCP, et leurs statistiques sont combinées dans la sortie de commande show. Si une visibilité spécifique à l'application sur l'activité du réseau est souhaitée, vous devez configurer l'inspection des services par nom d'application (configurer le protocole de correspondance HTTP, le protocole de correspondance Telnet, etc.).

Comparez les statistiques disponibles dans la commande show policy-map type inspect zone-pair de cette configuration avec la politique de pare-feu plus explicite montrée plus loin dans la page. Cette configuration est utilisée pour inspecter le trafic d'un téléphone IP Cisco, aussi bien que plusieurs postes de travail qui utilisent une grande variété de trafic, comprenant http, ftp, netbios, ssh et dns :

class-map type inspect match-all all-private
 match access-group 101
!         
policy-map type inspect priv-pub-pmap
 class type inspect all-private
  inspect
 class class-default
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

Alors que cette configuration est facile à définir et facilite tout trafic qui provient de la zone privée (tant que le trafic observe les ports de destination standards, reconnus par PAM), elle offre une visibilité limitée dans l'activité de service et ne donne pas l'occasion d'appliquer la bande passante de ZFW et les limites de session pour des types déterminés de trafic. Cette sortie de commande show policy-map type inspect zone-pair priv-pub est le résultat de la configuration simple précédente qui utilise seulement une autorisation de tout ACL ip [sous-réseau] entre zone-paires. Comme vous pouvez le voir, la plupart du trafic du poste de travail est compté dans les statistiques TCP ou UDP de base :

stg-871-L#show policy-map type insp zone-pair priv-pub
Zone-pair: priv-pub
 
  Service-policy inspect : priv-pub-pmap
 
    Class-map: all-private (match-all)
      Match: access-group 101
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [413:51589]
        udp packets: [74:28]
        icmp packets: [0:8]
        ftp packets: [23:0]
        tftp packets: [3:0]
        tftp-data packets: [6:28]
        skinny packets: [238:0]
 
        Session creations since subsystem startup or last reset 39
        Current session counts (estab/half-open/terminating) [3:0:0]
        Maxever session counts (estab/half-open/terminating) [3:4:1]
        Last session created 00:00:20
        Last statistic reset never
        Last session creation rate 2
        Maxever session creation rate 7
        Last half-open session total 0
 
    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

En revanche, une configuration similaire qui ajoute des classes spécifiques à l'application fournit des statistiques et un contrôle d'application plus granulaires, et prend toujours en charge la même étendue de services que celle qui a été montrée dans le premier exemple lorsque vous définissez la carte-classe de la dernière chance qui correspond uniquement à la liste de contrôle d'accès comme dernière chance dans la carte-politique :

class-map type inspect match-all all-private
 match access-group 101
class-map type inspect match-all private-ftp
 match protocol ftp
 match access-group 101
class-map type inspect match-any netbios
 match protocol msrpc
 match protocol netbios-dgm
 match protocol netbios-ns
 match protocol netbios-ssn
class-map type inspect match-all private-netbios
 match class-map netbios
 match access-group 101
class-map type inspect match-all private-ssh
 match protocol ssh
 match access-group 101
class-map type inspect match-all private-http
 match protocol http
 match access-group 101
!
policy-map type inspect priv-pub-pmap
 class type inspect private-http
  inspect
 class type inspect private-ftp
  inspect
 class type inspect private-ssh
  inspect
 class type inspect private-netbios
  inspect
 class type inspect all-private
  inspect
 class class-default!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

La configuration plus spécifique fournit cette sortie granulaire substantielle pour la commande show policy-map type inspect zone-pair priv-pub :

stg-871-L#sh policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub

   Service-policy inspect : priv-pub-pmap

     Class-map: private-http (match-all)
       Match: protocol http
       Match: access-group 101
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:2193]

         Session creations since subsystem startup or last reset 731
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [0:3:0]
         Last session created 00:29:25
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 4
         Last half-open session total 0

     Class-map: private-ftp (match-all)
       Match: protocol ftp
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [86:167400]
         ftp packets: [43:0]

         Session creations since subsystem startup or last reset 7
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [2:1:1]
         Last session created 00:42:49
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 4
         Last half-open session total 0

     Class-map: private-ssh (match-all)
       Match: protocol ssh
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:62]

         Session creations since subsystem startup or last reset 4
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [1:1:1]
         Last session created 00:34:18
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 2
         Last half-open session total 0

     Class-map: private-netbios (match-all)
       Match: access-group 101
       Match: class-map match-any netbios
         Match: protocol msrpc
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-dgm
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-ns
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-ssn
           2 packets, 56 bytes
           30 second rate 0 bps
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:236]
 
         Session creations since subsystem startup or last reset 2
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [1:1:1]
         Last session created 00:31:32
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 1
         Last half-open session total 0

     Class-map: all-private (match-all)
       Match: access-group 101
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [51725:158156]
         udp packets: [8800:70]
         tftp packets: [8:0]
         tftp-data packets: [15:70]
         skinny packets: [33791:0]

         Session creations since subsystem startup or last reset 2759
         Current session counts (estab/half-open/terminating) [2:0:0]
         Maxever session counts (estab/half-open/terminating) [2:6:1]
         Last session created 00:22:21
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 12
         Last half-open session total 0
 
     Class-map: class-default (match-any)
       Match: any 
       Drop (default action)
         4 packets, 112 bytes

Un autre avantage supplémentaire de l'utilisation d'une configuration plus granulaire de carte-classe et de carte-politique, comme mentionné précédemment, est une opportunité d'appliquer des limites spécifiques à la classe sur les valeurs de session et de débit ; et, d'ajuster spécifiquement les paramètres d'inspection par l'application d'une carte-paramètre pour ajuster chaque comportement d'inspection de classe.

Configurer les mappages de politiques de pare-feu basés sur les zones

Le policy-map applique des actions de politique de pare-feu à un ou plusieurs class-maps pour définir la politique de service qui est appliquée à une zone-paire de sécurité. Quand une carte-politique de type inspecter est créée, une classe par défaut nommée classe / classe par défaut est appliquée à l'extrémité de la classe. L'action de stratégie par défaut class class-default est drop mais peut être modifiée pour passer. L'option de journal peut être ajoutée avec l'action d'abandon. L'inspection ne peut pas être appliquée à la classe / classe par défaut.

Actions de la politique de pare-feu selon des zones

ZFW fournit trois actions pour le trafic qui traverse d'une zone à l'autre :

• Drop : il s'agit de l'action par défaut pour tout le trafic, telle qu'appliquée par la classe class-default qui termine chaque policy-map de type inspect. D'autres cartes-classes dans une carte-politique peuvent également être configurées pour abandonner le trafic non désiré. Le trafic qui est géré par l'action de suppression est abandonné en silence (c'est-à-dire qu'aucune notification de la suppression n'est envoyée à l'hôte d'extrémité concerné) par le ZFW, par opposition à un comportement de liste de contrôle d'accès lorsqu'il envoie un message d'hôte ICMP inaccessible à l'hôte qui a envoyé le trafic refusé. Actuellement, il n'y a pas d'option pour changer le comportement de la suppression silencieuse. L'option journal peut être ajoutée avec l'abandon pour la notification de syslog que le trafic a été abandonné par le pare-feu.

• Passage - Cette action laisse le routeur expédier le trafic d'une zone à l'autre. L'action de passage n'assure pas le suivi de l'état des connexions ou sessions dans le trafic. Le passage permet seulement le trafic dans une direction. Une politique parallèle doit être appliquée pour permettre au trafic de retour de passer dans la direction opposée. L'action de passage est utile pour des protocoles tels que IPSec ESP, IPSec AH, ISAKMP et d'autres protocoles sécurisés de façon inhérente dotés d'un comportement prévisible. Cependant, la plupart du trafic d'application est mieux traité dans le ZFW avec l'action inspecter.

• Inspecter - L'action inspecter offre le contrôle de trafic selon l'état. Par exemple, si le trafic de la zone privée à la zone Internet dans l'exemple de réseau précédent est inspecté, le routeur met à jour la connexion ou les informations de session pour le trafic TCP et le protocole de datagramme utilisateur (UDP). Par conséquent, le routeur permet le trafic de retour envoyé des serveurs de zone Internet en réponse aux requêtes de connexion de zone privée. En outre, l'inspection peut fournir une inspection et un contrôle d'application pour certains protocoles de service qui peuvent transporter du trafic d'application vulnérable ou sensible. La vérification rétrospective peut être appliquée avec une carte-paramètre pour enregistrer le début de la connexion/session, arrêt, durée, volume de données transférées et adresses d'origine et de destination.

Les actions sont associées à des cartes-classes dans des cartes-politiques :

configure terminal
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Les cartes-paramètres offrent des options pour modifier les paramètres de connexion pour une politique d'inspection de carte-classe donnée.

Configurer les mappages de paramètres du pare-feu Zone-Policy

Les mappages de paramètres spécifient le comportement d'inspection de ZFW, pour des paramètres tels que la protection DoS, les minuteurs de session de connexion TCP/UDP et la configuration de la journalisation de la piste d'audit. Les cartes-paramètres sont également appliquées avec la classe de couche 7 et les cartes-politiques pour définir le comportement spécifique à l'application, des conditions telles que les objets HTTP, conditions d'authentification POP3 et IMAP et toute autre information spécifique à l'application.

Les cartes-paramètres d'inspection pour ZFW sont configurées en tant que inspecter type, semblable à l'autre classe ZFW et objets de la politique :

stg-871-L(config)#parameter-map type inspect z1-z2-pmap 
stg-871-L(config-profile)#?
parameter-map commands:
  alert           Turn on/off alert
  audit-trail     Turn on/off audit trail
  dns-timeout     Specify timeout for DNS
  exit            Exit from parameter-map
  icmp            Config timeout values for icmp
  max-incomplete  Specify maximum number of incomplete connections before
                  clamping
  no              Negate or set default values of a command
  one-minute      Specify one-minute-sample watermarks for clamping
  sessions        Maximum number of inspect sessions
  tcp             Config timeout values for tcp connections
  udp             Config timeout values for udp flows

Les types spécifiques de cartes-paramètres spécifient des paramètres appliqués par les politiques d'inspection de la couche 7. Les cartes-paramètres de type Regex définissent une expression régulière à utiliser avec l'inspection d'application HTTP qui filtre le trafic avec une expression régulière :

parameter-map type regex [parameter-map-name]

Les cartes-paramètres Protocol-info-type définissent les noms de serveurs à utiliser avec l'inspection d'application IM :

parameter-map type protocol-info [parameter-map-name]

Des détails de la configuration complète pour l'inspection de l'application HTTP et IM sont fournis dans les respectives sections d'inspection d'application de ce document.

Application de la journalisation pour les politiques de pare-feu basées sur les zones

ZFW offre des options de journalisation pour le trafic qui est abandonné ou inspecté par défaut ou des actions de politique de pare-feu configurées. La journalisation de la vérification rétrospective est disponible pour le trafic que le ZFW inspecte. La piste d'audit est appliquée lorsqu'une piste d'audit est définie dans une carte-paramètre et que la carte-paramètre avec l'action d'inspection est appliquée dans une carte-politique :

configure terminal
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [parameter-map-name (optional)]

La journalisation de l'abandon est disponible pour le trafic que ZFW abandonne. La suppression de la journalisation est configurée par lorsque vous ajoutez un journal avec l'action de suppression dans un policy-map :

configure terminal
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Modifier les cartes de classe et de stratégie de pare-feu Zone-Policy

ZFW n'incorpore actuellement pas un éditeur permettant de modifier les diverses structures ZFW telles que des cartes-politiques, des cartes-classes et des cartes-paramètres. Afin de réordonner des déclarations de correspondance dans une carte-classe ou application d'action pour diverses cartes-classes contenues dans une carte-politique, vous devez suivre ces étapes :

1. Copiez la structure actuelle dans un éditeur de texte tel que le Bloc-notes Microsoft Windows ou dans un éditeur tel que vi sur les plates-formes Linux/Unix.

2. Supprimer la structure actuelle de la configuration du routeur.

3. Modifier la structure dans votre éditeur de texte.

4. Copiez la structure dans l’interface de ligne de commande du routeur.

Exemples de configuration

Cet exemple de configuration utilise un routeur à services intégrés Cisco 1811. Une configuration de base avec une connectivité IP, configuration VLAN et un pontage transparent entre deux segments privés de réseau Ethernet est disponible dans l'annexe A. Le routeur est divisé en cinq zones :

• L'Internet public est connecté à FastEthernet 0 (zone d'Internet)

• Deux serveurs Internet sont connectés à FastEthernet 1 (zone DMZ)

• Le commutateur Ethernet est configuré avec deux VLAN :

  • Des postes de travail sont connectés à VLAN1 (zone client).

  • Des serveurs sont connectés à VLAN2 (zone de serveur).

  • Les zones du client et du serveur sont sur le même sous-réseau. Un pare-feu transparent est appliqué entre les zones, de sorte que les politiques inter-zones sur ces deux interfaces ne peuvent affecter que le trafic entre les zones client et serveur.

• Les interfaces VLAN1 et VLAN2 communiquent avec d'autres réseaux par le pont d'interface virtuelle (BVI1). Cette interface est affectée à la zone privée. (Voir la figure 2.)

Image 2 : Détails de la topologie de zone

Détail de topologie de zone

Ces politiques sont appliquées, avec les zones réseau définies précédemment :

• Les hôtes dans la zone Internet peuvent atteindre les services DNS, SMTP et SSH sur un serveur dans le DMZ. L'autre serveur propose des services SMTP, HTTP et HTTPS. La stratégie de pare-feu limite l'accès aux services spécifiques disponibles sur chaque hôte.

• Les serveurs DMZ ne peuvent se connecter aux serveurs dans aucune autre zone.

• Les serveurs dans la zone client peuvent se connecter aux hôtes dans la zone de serveur sur tous les services TCP, UDP et ICMP.

• Les serveurs dans la zone de serveur ne peuvent pas se connecter à des hôtes dans la zone client, excepté un serveur d'application basé sur Unix pouvant ouvrir des sessions de client X Windows pour des serveurs X Windows sur les PC de bureau dans la zone client sur les ports 6900 à 6910.

• Tous les hôtes dans la zone privée (combinaison des clients et des serveurs) peuvent accéder à des hôtes dans le DMZ sur des services SSH, FTP, POP, IMAP, ESMTP et HTTP et, dans la zone Internet, sur des services HTTP, HTTPS et DNS ainsi qu'ICMP. En outre, l'inspection d'application est appliquée sur les connexions HTTP de la zone privée à la zone Internet afin de s'assurer que les applications IM et P2P prises en charge ne sont pas transportées sur le port 80. (Voir l'image 3.)

Image 3 : Exemple de configuration des autorisations de service de paire de zones à appliquer

Autorisations de service de zone-paire à appliquer dans l'exemple de configuration

Ces politiques de pare-feu sont configurées par ordre de complexité :

1. Inspection des clients-serveurs TCP/UDP/ICMP

2. Inspection privée-DMZ SSH/FTP/POP/IMAP/ESMTP/HTTP

3. Internet - Inspection DMZ SMTP/HTTP/DNS limitée par l'adresse de hôte

4. Inspection des serveurs-clients X Windows avec un service déterminé de mappage d'application de port (PAM)

5. Internet-privé HTTP/HTTPS/DNS/ICMP avec inspection de l'application HTTP

Étant donné que vous appliquez des parties de la configuration à différents segments de réseau à des moments différents, il est important de se rappeler qu’un segment de réseau perd sa connectivité avec d’autres segments lorsqu’il est placé dans une zone. Par exemple, lorsque la zone privée est configurée, les hôtes de la zone privée perdent la connectivité avec les zones DMZ et Internet jusqu'à ce que leurs politiques respectives soient définies.

Pare-feu de routage d'inspection dynamique

Configurez la politique de l'Internet privé

L'image 4 illustre la configuration de la politique Internet privée.

Image 4 : Inspection de service de la zone privée à la zone Internet

Service d'inspection depuis une zone privée vers une zone Internet

La politique de l'Internet privé s'applique à l'inspection de la couche 4 pour HTTP, HTTPS, DNS et l'inspection de la couche 4 pour ICMP de la zone privée à la zone Internet. Cela permet les connexions de la zone privée à la zone Internet et autorise le trafic de retour. L'inspection de la couche 7 présente les avantages d'un contrôle plus strict des applications, d'une meilleure sécurité et d'une prise en charge des applications nécessitant une correction. Cependant, l’inspection de la couche 7, comme mentionné, nécessite une meilleure compréhension de l’activité du réseau, car les protocoles de couche 7 qui ne sont pas configurés pour l’inspection ne sont pas autorisés entre les zones.

1. Définissez des cartes-classes qui décrivent le trafic que vous souhaitez autoriser entre les zones, en fonction des politiques décrites précédemment :

   configure terminal
    class-map type inspect match-any internet-traffic-class
     match protocol http
     match protocol https
     match protocol dns
     match protocol icmp

2. Configurez une carte-politique pour inspecter le trafic sur les cartes-classes que vous venez de définir :

   configure terminal
    policy-map type inspect private-internet-policy
     class type inspect internet-traffic-class
      inspect

3. Configurez les zones privées et d'Internet et affectez les interfaces du routeur à leurs zones respectives :

   configure terminal
    zone security private
    zone security internet
    int bvi1            
     zone-member security private
    int fastethernet 0
     zone-member security internet

Configurez la zone-paire et appliquez la carte-politique appropriée.

Remarque : il vous suffit de configurer la paire de zones Internet privées pour l'instant afin d'inspecter les connexions provenant de la zone privée qui se déplace vers la zone Internet, comme indiqué ci-dessous :

configure terminal
 zone-pair security private-internet source private destination internet
  service-policy type inspect private-internet-policy

Ceci achève la configuration de la politique d'inspection de la couche 7 sur la zone-paire privée d'Internet pour permettre aux connexions HTTP, HTTPS, DNS et ICMP de la zone de clients à la zone de serveurs et d'appliquer l'inspection de l'application au trafic HTTP pour s'assurer que le passage du trafic non désiré n'est pas permis sur le port de service HTTP, TCP 80.

Configurez la politique privée de DMZ

L'image 5 illustre la configuration de la politique DMZ privée.

Image 5 : Inspection de service de la zone privée à la zone DMZ

Inspection de service d'une zone privée vers une zone DMZ

La politique privée de DMZ ajoute de la complexité parce qu'elle requiert une meilleure compréhension du trafic du réseau entre les zones. Cette politique s'applique à l'inspection de la couche 7 de la zone privée au DMZ. Ceci permet les connexions de la zone privée à la DMZ et autorise le trafic de retour. L'inspection de la couche 7 présente les avantages d'un contrôle plus strict des applications, d'une meilleure sécurité et d'une prise en charge des applications nécessitant une correction. Cependant, l’inspection de la couche 7, comme mentionné, nécessite une meilleure compréhension de l’activité du réseau, car les protocoles de couche 7 qui ne sont pas configurés pour l’inspection ne sont pas autorisés entre les zones.

1. Définissez des cartes-classes qui décrivent le trafic que vous souhaitez autoriser entre les zones, en fonction des politiques décrites précédemment :

   configure terminal
    class-map type inspect match-any L7-inspect-class
     match protocol ssh
     match protocol ftp
     match protocol pop
     match protocol imap
     match protocol esmtp
     match protocol http

2. Configurez des cartes-politiques pour inspecter le trafic sur les cartes-classes que vous venez de définir :

   configure terminal
    policy-map type inspect private-dmz-policy
     class type inspect L7-inspect-class
      inspect

3. Configurez les zones privées et DMZ et affectez les interfaces du routeur à leurs zones respectives :

   configure terminal
    zone security private
    zone security dmz
    int bvi1            
     zone-member security private
    int fastethernet 1
     zone-member security dmz

4. Configurez la zone-paire et appliquez la carte-politique appropriée.

Remarque : il vous suffit de configurer la zone-paire DMZ privée pour l'instant afin d'inspecter les connexions provenant de la zone privée qui se déplace vers la zone DMZ, comme indiqué ci-dessous :

configure terminal
 zone-pair security private-dmz source private destination dmz
  service-policy type inspect private-dmz-policy

Ceci achève la configuration de la politique d'inspection de la couche 7 sur le DMZ privé pour permettre toutes les connexions TCP, UDP et ICMP de la zone de clients à la zone de serveurs. La stratégie n'applique pas de correction pour les canaux subordonnés, mais fournit un exemple de stratégie simple pour prendre en charge la plupart des connexions d'application.

Configurez la politique Internet DMZ

L'image 6 illustre la configuration de la politique Internet DMZ.

Image 6 : Inspection de service de la zone Internet à la zone DMZ

Inspection de service de la zone Internet à la zone DMZ

Cette politique s'applique à l'inspection de la couche 7 de la zone Internet au DMZ. Ceci permet les connexions de la zone Internet à la DMZ et autorise le trafic de retour des hôtes DMZ vers les hôtes Internet à l'origine de la connexion. La politique Internet DMZ combine l'inspection de la couche 7 avec des groupes d'adresses définis par les ACL pour restreindre l'accès aux services spécifiques sur les hôtes spécifiques, groupes d'hôtes ou sous-réseaux. Pour ce faire, imbriquez un mappage de classe qui spécifie des services dans un autre mappage de classe qui référence une liste de contrôle d'accès pour spécifier des adresses IP.

1. Définissez des cartes-classes et des listes de contrôle d’accès qui décrivent le trafic que vous souhaitez autoriser entre les zones, en fonction des politiques décrites précédemment.

   Plusieurs cartes-classes pour les services doivent être utilisées, car différentes stratégies d'accès sont appliquées pour l'accès à deux serveurs différents. Des connexions DNS et HTTP à 172.16.2.2 sont concédées aux hôtes Internet et des connexions SMTP sont concédées à 172.16.2.3. Notez la différence dans les class-maps. Les cartes-classes spécifiant des services utilisent le mot clé match-any pour permettre l'un des services énumérés. Les cartes-classes associant les ACL aux cartes-classes de service utilisent le mot-clé match-all pour exiger que les deux conditions dans la carte-classe soient remplies pour permettre le trafic :

   configure terminal
    access-list 110 permit ip any host 172.16.2.2
    access-list 111 permit ip any host 172.16.2.3
    class-map type inspect match-any dns-http-class
     match protocol dns
     match protocol http
    class-map type inspect match-any smtp-class
     match protocol smtp
    class-map type inspect match-all dns-http-acl-class
     match access-group 110
     match class-map dns-http-class
    class-map type inspect match-all smtp-acl-class
     match access-group 111
     match class-map smtp-class

2. Configurez des cartes-politiques pour inspecter le trafic sur les cartes-classes que vous venez de définir :

   configure terminal
    policy-map type inspect internet-dmz-policy
     class type inspect dns-http-acl-class
      inspect
     class type inspect smtp-acl-class
      inspect

3. Configurez les zones Internet et DMZ et affectez les interfaces du routeur à leurs zones respectives. Sautez la configuration DMZ si vous l'avez établie dans la section précédente :

   configure terminal
   zone security internet
   zone security dmz
   int fastethernet 0            
    zone-member security internet
   int fastethernet 1
    zone-member security dmz

4. Configurez la zone-paire et appliquez la carte-politique appropriée.

   Remarque : il vous suffit de configurer la paire de zones Internet DMZ pour l'instant, afin d'inspecter les connexions provenant de la zone Internet qui se dirige vers la zone DMZ, comme indiqué ci-dessous :

   configure terminal
    zone-pair security internet-dmz source internet destination dmz
     service-policy type inspect internet-dmz-policy

   Ceci achève la configuration de la politique d'inspection spécifique à l'adresse de la couche 7 sur la zone-paire DMZ d'Internet.

Pare-feu transparent d'inspection dynamique

Configurez la politique serveurs-clients

L'image suivante illustre la configuration de la stratégie serveur-client.

Image 7 : Inspection de service de la zone Serveurs à la zone Clients

Inspection de service d'une zone de serveurs vers une zone clients

La stratégie serveurs-clients applique l'inspection avec un service défini par l'utilisateur. L'inspection de la couche 7 est appliquée de la zone de serveurs à la zone de clients. Cela permet des connexions X Windows à une plage de ports spécifique de la zone des serveurs à la zone des clients et autorise le trafic de retour. X Windows n'est pas un protocole pris en charge en mode natif dans PAM, donc un service configuré par l'utilisateur dans PAM doit être défini afin que le ZFW puisse reconnaître et inspecter le trafic approprié.

Deux interfaces de routeur ou plus sont configurées dans un groupe de ponts IEEE pour fournir un routage et un pontage intégrés (IRB) pour fournir un pontage entre les interfaces dans le groupe de ponts et pour router vers d'autres sous-réseaux via l'interface virtuelle de pont (BVI). La politique de pare-feu transparent applique une inspection de pare-feu pour le trafic traversant le pont, mais pas pour le trafic qui quitte le groupe de ponts via l'interface BVI. La politique d'inspection s'applique seulement au trafic qui traverse le groupe de pontage. Par conséquent, dans ce scénario, l'inspection n'est appliquée qu'au trafic qui se déplace entre les zones clients et serveurs, qui sont imbriquées à l'intérieur de la zone privée. La politique appliquée entre la zone privée et les zones publiques et DMZ, entre seulement en jeu quand le trafic sort du groupe de pontage par l'intermédiaire du BVI. Lorsque le trafic quitte les zones clients ou serveurs via l'interface BVI, la stratégie de pare-feu transparente n'est pas invoquée.

1. Configurez PAM avec une entrée définie par l'utilisateur pour X Windows.

   Les clients X Windows (où les applications sont hébergées) ouvrent des connexions pour afficher des informations aux clients (où l'utilisateur travaille) dans une plage qui commence au port 6900.

   Chaque connexion supplémentaire utilise les ports successifs, ainsi si un client affiche 10 sessions différentes sur un hôte, le serveur utilise des ports 6900-6909. Par conséquent, si vous inspectez la plage de ports comprise entre 6900 et 6909, les connexions ouvertes aux ports au-delà de 6909 échouent :

   configure terminal
    ip port-map user-Xwindows port tcp from 6900 to 6910

2. Examinez les documents PAM pour des questions PAM supplémentaires ou examinez la documentation de l'inspection du protocole granulaire pour des informations sur les détails de l'interopérabilité entre PAM et l'inspection dynamique du pare-feu Cisco IOS.

3. Définissez des cartes-classes qui décrivent le trafic que vous souhaitez autoriser entre les zones, en fonction des politiques décrites précédemment :

   configure terminal
    class-map type inspect match-any Xwindows-class
     match protocol user-Xwindows

4. Configurez des cartes-politiques pour inspecter le trafic sur les cartes-classes que vous venez de définir :

   configure terminal
    policy-map type inspect servers-clients-policy
     class type inspect Xwindows-class
      inspect

5. Configurez les zones de client et de serveur et affectez les interfaces du routeur à leurs zones respectives.

   Si vous avez configuré ces zones et affecté les interfaces dans la section de la politique de configuration Clients-Serveurs, vous pouvez passer à la définition de la zone-paire. La configuration du pontage IRB est donnée à des fins d'exhaustivité :

   configure terminal
   bridge irb
   bridge 1 protocol ieee
   bridge 1 route ip
   zone security clients
   zone security servers
    int vlan 1
    bridge-group 1
    zone-member security clients
   int vlan 2
    bridge-group 1
    zone-member security servers

6. Configurez la zone-paire et appliquez la carte-politique appropriée.

   Remarque : il vous suffit de configurer la paire de zones serveurs-clients pour l'instant afin d'inspecter les connexions provenant de la zone serveurs qui se déplacent vers la zone clients, comme indiqué ci-dessous :

   configure terminal
    zone-pair security servers-clients source servers destination clients
     service-policy type inspect servers-clients-policy

   Ceci achève la configuration de la politique d'inspection définie par l'utilisateur dans la zone-paire de serveurs-clients pour permettre des connexions X Windows de la zone de serveur à la zone client.

Configurez la politique Serveurs-Clients

L'image 8 illustre la configuration de la stratégie client-serveur.

Image 8 : Inspection de service de la zone Clients à la zone Serveurs

Inspection de service d'une zone de clients vers une zone de serveurs

La politique serveurs-client est moins complexe que les autres. L'inspection de la couche 4 est appliquée de la zone de clients à la zone de serveurs. Cela permet les connexions de la zone clients à la zone serveurs et autorise le trafic de retour. L'inspection de la couche 4 présente l'avantage de la simplicité de la configuration du pare-feu, du fait que seulement quelques règles sont nécessaires pour permettre la plupart du trafic. Cependant, l'inspection de la couche 4 comporte également deux inconvénients importants :

• Les applications telles que FTP ou les services multimédias négocient fréquemment un canal subordonné supplémentaire entre le serveur et le client. Cette fonctionnalité est généralement prise en compte dans une correction de service qui surveille le dialogue du canal de contrôle et autorise le canal subordonné. Cette fonction n'est pas disponible dans l'inspection de la couche 4.

• L'inspection de la couche 4 permet quasiment tout le trafic de la couche d'application. Si l'utilisation du réseau doit être contrôlée afin que seulement quelques applications soient permises par le pare-feu, un ACL doit être configuré sur le trafic en partance pour limiter les services permis par le pare-feu.

Les deux interfaces de routeur étant configurées dans un groupe de ponts IEEE, cette stratégie de pare-feu applique une inspection transparente du pare-feu. Cette politique est appliquée sur deux interfaces dans un groupe de pontage IEEE IP. La politique d'inspection s'applique uniquement au trafic qui traverse le groupe de ponts. Ceci explique pourquoi les zones de clients et de serveurs sont emboîtées à l'intérieur de la zone privée.

1. Définissez des cartes-classes qui décrivent le trafic que vous souhaitez autoriser entre les zones, en fonction des politiques décrites précédemment :

   configure terminal
    class-map type inspect match-any L4-inspect-class
    match protocol tcp
    match protocol udp
    match protocol icmp

2. Configurez des cartes-politiques pour inspecter le trafic sur les cartes-classes que vous venez de définir :

   configure terminal
    policy-map type inspect clients-servers-policy
    class type inspect L4-inspect-class
     inspect

3. Configurez les zones de clients et de serveurs et affectez les interfaces du routeur à leurs zones respectives :

   configure terminal
    zone security clients
    zone security servers
    interface vlan 1            
     zone-member security clients
    interface vlan 2
     zone-member security servers

4. Configurez la zone-paire et appliquez la carte-politique appropriée.

   Remarque : il vous suffit de configurer la paire de zones clients-serveurs pour l'instant, afin d'inspecter les connexions provenant de la zone clients qui se déplacent vers la zone serveurs, comme indiqué ci-dessous :

   configure terminal
    zone-pair security clients-servers source clients destination servers
     service-policy type inspect clients-servers-policy

   Ceci achève la configuration de l'inspection de la couche 4 pour que la zone-paire de clients-serveurs permette toutes les connexions TCP, UDP, et ICMP de la zone de clients à la zone de serveurs. La stratégie n'applique pas de correction pour les canaux subordonnés, mais fournit un exemple de stratégie simple pour prendre en charge la plupart des connexions d'application.

Politique de débit pour le pare-feu de politique basée sur les zones

Les réseaux de données bénéficient souvent de la capacité à limiter le débit de transmission de types spécifiques de trafic réseau et à limiter l'impact du trafic de moindre priorité au trafic essentiel pour l'entreprise. La plate-forme logicielle Cisco IOS offre cette fonctionnalité avec la réglementation du trafic , qui limite le débit nominal et la salve du trafic. Le logiciel Cisco IOS a assuré la régulation du trafic depuis la version 12.1(5)T de Cisco IOS.

La version 12.4(9)T du logiciel Cisco IOS complète ZFW par une limitation de débit lorsque vous ajoutez la capacité de contrôler le trafic qui s'applique et qui correspond aux définitions d'une carte-classe spécifique lorsqu'il traverse le pare-feu d'une zone de sécurité à une autre. Un point de configuration permet de décrire un trafic spécifique, d'appliquer une politique de pare-feu et de contrôler la consommation de bande passante du trafic. ZFW diffère de l'interface basée sur le fait qu'il fournit uniquement les actions de transmission pour la conformité de la politique et de suppression pour la violation de la politique. ZFW ne peut pas marquer le trafic pour DSCP.

ZFW peut uniquement spécifier l'utilisation de la bande passante en octets/seconde, en paquets/seconde et le pourcentage de bande passante n'est pas offert. ZFW peut être appliqué avec ou sans interface. Par conséquent, si des fonctionnalités supplémentaires sont requises, ces fonctionnalités peuvent être appliquées par interface. Si l'interface est utilisée avec le pare-feu, assurez-vous que les stratégies ne sont pas en conflit.

Configurer la stratégie ZFW

La réglementation ZFW limite le trafic dans une carte-classe de carte-politique à une valeur de débit définie par l'utilisateur comprise entre 8 000 et 2 000 000 000 bits par seconde, avec une valeur de salve configurable comprise entre 1 000 et 512 000 000 octets.

Le contrôle ZFW est configuré par une ligne supplémentaire de configuration dans la carte-politique, qui est appliquée après l'action de politique :

policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect
  police rate [bps rate value <8000-2000000000>] burst [value in bytes <1000-512000000>]

Contrôle de session

La stratégie ZFW a également introduit le contrôle de session pour limiter le nombre de sessions pour le trafic dans un policy-map qui s'applique et qui correspond à un class-map. Ceci ajoute à la capacité actuelle d'appliquer la politique de protection DoS par class-map. En effet, cela permet un contrôle granulaire sur le nombre de sessions qui s'appliquent qui correspondent à n'importe quelle carte-classe donnée qui traverse une zone-paire. Si la même carte-classe est utilisée sur de multiples cartes-politiques ou zones-paires, différentes limites de session peuvent être appliquées sur les diverses applications de carte-classe.

Le contrôle de session est appliqué lorsqu'une carte-paramètre est configurée qui contient le volume de session souhaité, puis la carte-paramètre est ajoutée à l'action d'inspection appliquée à une carte-classe sous une carte-politique :

parameter-map type inspect my-parameters
 sessions maximum [1-2147483647]

policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect my-parameters

Les cartes-paramètres peuvent uniquement être appliquées à l'action d'inspection et ne sont pas disponibles pour les actions de passage ou de suppression.

Les activités de contrôle et de réglementation de session ZFW sont visibles avec cette commande :

show policy-map type inspect zone-pair

Inspection d'application

L'inspection d'application met en place une fonction supplémentaire de ZFW. Les politiques d'inspection d'application sont appliquées à la couche 7 du modèle OSI, où les applications de l'utilisateur envoient et reçoivent des messages qui permettent aux applications d'offrir des capacités utiles. Certaines applications peuvent offrir des fonctionnalités indésirables ou vulnérables. Par conséquent, les messages associés à ces fonctionnalités doivent être filtrés pour limiter les activités sur les services d'application.

ZFW du logiciel Cisco IOS fournit l'inspection d'application et le contrôle de ces services d'applications :

• HTTP

• SMTP

• POP3

• IMAP

• Sun RPC

• Trafic d'application P2P

• IM applications

L'inspection et le contrôle d'application (AIC) varient en termes de capacité par service. L'inspection HTTP offre un filtrage granulaire sur plusieurs types d'activité d'application, et fournit des fonctionnalités pour limiter la taille du transfert, la longueur des adresses Web et l'activité du navigateur pour appliquer la conformité aux normes de comportement des applications et pour limiter les types de contenu qui sont transférés sur le service. AIC pour SMTP peut limiter la longueur du contenu et imposer la conformité au protocole. L'inspection POP3 et IMAP permet de s'assurer que les utilisateurs utilisent des mécanismes d'authentification sécurisés pour empêcher la compromission des identifiants utilisateur.

L'inspection d'application est configurée comme un ensemble supplémentaire de cartes-classes et de cartes-politiques spécifiques à l'application, qui sont ensuite appliquées aux cartes-classes et cartes-politiques d'inspection actuelles lorsque vous définissez la politique de service d'application dans la carte-politique d'inspection.

Inspection d'application HTTP

L'inspection d'application peut être appliquée sur le trafic HTTP pour contrôler l'utilisation non souhaitée du port de service HTTP pour d'autres applications telles que la messagerie instantanée, le partage de fichiers P2P et les applications de tunneling qui peuvent rediriger des applications autrement protégées par un pare-feu via TCP 80.

Configurez une carte-classe d'inspection d'application pour décrire le trafic qui viole le trafic HTTP permis :

! configure the actions that are not permitted
class-map type inspect http match-any http-aic-cmap
 match request port-misuse any
 match req-resp protocol-violation 
! define actions to be applied to unwanted traffic
policy-map type inspect http http-aic-pmap
 class type insp http http-aic-cmap
  reset
  log
! define class-map for stateful http inspection
class-map type inspect match-any http-cmap
 match protocol http
! define class-map for stateful inspection for other traffic
class-map type inspect match-any other-traffic-cmap
 match protocol smtp
 match protocol dns
 match protocol ftp
! define policy-map, associate class-maps and actions
policy-map type inspect priv-pub-pmap
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap
 class type inspect other-traffic-cmap
  inspect

Améliorations d'inspection d'application HTTP

La version 12.4(9)T du logiciel Cisco IOS apporte des améliorations aux fonctionnalités d'inspection HTTP de ZFW. Le pare-feu Cisco IOS a mis en place l'inspection d'application HTTP introduite dans la version 12.3(14)T du logiciel Cisco IOS. La version 12.4(9)T du logiciel Cisco IOS augmente les fonctionnalités actuelles lorsque vous ajoutez :

• Capacité d'autoriser, refuser et contrôler les demandes et les réponses basées sur le nom de l'en-tête et les valeurs d'en-tête. Ceci est utile pour bloquer les demandes et les réponses qui portent des champs d'en-tête vulnérables.

• Possibilité de limiter la taille des différents éléments dans les en-têtes de requête et de réponse HTTP tels que la longueur maximale de l'URL, la longueur maximale de l'en-tête, le nombre maximal d'en-têtes, la longueur maximale de la ligne d'en-tête, etc. Cette fonctionnalité est utile pour empêcher les dépassements de mémoire tampon.

• Possibilité de bloquer les demandes et les réponses qui transportent plusieurs en-têtes du même type ; par exemple, une demande avec deux en-têtes de longueur de contenu.

• Capacité à bloquer des demandes et des réponses avec des en-têtes non-ASCII. Ceci est utile pour empêcher les diverses attaques qui emploient des caractères binaires ainsi que non-ASCII pour introduire des vers et tout autre contenu malveillant dans les serveurs Web.

• La capacité à grouper des méthodes HTTP dans des catégories personnalisées par l'utilisateur et la flexibilité de bloquer/autoriser/contrôler chacun des groupes est offerte. Le RFC de HTTP permet un ensemble limité de méthodes HTTP. Certaines des méthodes standards sont considérées peu sûres parce qu'elles peuvent être utilisées pour exploiter des vulnérabilités sur un serveur Web. Plusieurs des méthodes non standards présentent un faible degré de sécurité.

• Méthode pour bloquer les URI spécifiques basée sur une expression régulière configurée par l'utilisateur. Cette fonctionnalité permet à l'utilisateur de bloquer les requêtes et les URI personnalisés.

• Capacité de mystifier des types d'en-tête (en particulier type d'en-tête de serveur) avec les chaînes de caractères personnalisables d'utilisateur. Ceci est utile au cas où un attaquant analyserait des réponses de serveur Web et apprendrait autant d'informations que possible, puis lancerait une attaque exploitant les faiblesses de ce serveur Web particulier.

• Capacité à bloquer ou émettre une alerte sur une connexion HTTP si une ou plusieurs valeurs de paramètre HTTP correspondent à des valeurs saisies par l'utilisateur comme expression régulière. Certains des contextes de valeur possibles HTTP incluent l'en-tête, le corps, nom d'utilisateur, mot de passe, agent utilisateur, la ligne de requête, ligne d'état et les variables CGI décodées.

Les exemples de configuration pour les améliorations d'inspection d'application HTTP supposent un réseau simple, comme illustré dans l'image 9.

Image 9 : L'inspection des applications suppose un réseau simple

Inspection d'application Supposons un réseau simple

Le pare-feu regroupe le trafic dans deux classes :

1. Trafic HTTP
2. Tout autre trafic TCP, UDP et ICMP à canal unique

HTTP est séparé pour permettre l'inspection spécifique sur le trafic Web. Ceci vous permet de configurer le contrôle dans la première section de ce document et l'inspection de l'application HTTP dans la deuxième section. Vous pouvez configurer des cartes-classes et des cartes-politiques spécifiques pour le trafic P2P et IM dans la troisième section de ce document. La connectivité est permise de la zone privée à la zone publique. Aucune connectivité n'est fournie de la zone publique à la zone privée.

Reportez-vous à l'annexe C pour obtenir une configuration complète qui implémente la stratégie initiale.

Configuration des améliorations du contrôle des applications HTTP

L'inspection d'application HTTP (aussi bien que d'autres politiques d'inspection d'application) requiert une configuration plus complexe que la configuration de base de la couche 4 . Vous devez configurer la classification et la politique du trafic de la couche 7 pour identifier le trafic spécifique que vous souhaitez contrôler et appliquer l'action désirée au trafic désirable et indésirable.

L'inspection d'application HTTP (semblable à d'autres types d'inspection d'application ) peut seulement être appliquée au trafic HTTP. Donc, vous devez définir des cartes-classes et des cartes-politiques de la couche 7 pour le trafic HTTP spécifique, puis définir une carte-classe de la couche 4 spécifiquement pour HTTP et appliquer la politique de la couche 7 à l'inspection HTTP dans une carte-politique de la couche 4, ainsi :

!configure the layer-7 traffic characteristics:
class-map type inspect http match-any http-l7-cmap
 match  req-resp protocol-violation
 match  request body length gt 4096
!
!configure the action to be applied to the traffic 
!matching the specific characteristics:
policy-map type inspect http http-l7-pmap
 class type inspect http http-l7-cmap
  reset
  log 
!
!define the layer-4 inspection policy
class-map type inspect match-all http-l4-cmap
 match protocol http
!
!associate layer-4 class and layer-7 policy-map
!in the layer-4 policy-map:
policy-map type inspect private-allowed-policy
 class type inspect http-l4-cmap
  inspect
  service-policy http http-l7-pmap

Toutes ces caractéristiques d'inspection de trafic d'application HTTP sont définies dans une carte-classe de la couche 7 :

• La commande d'inspection d'en-tête permet d'autoriser/refuser/surveiller les requêtes ou les réponses dont l'en-tête correspond à l'expression régulière configurée. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-6-HTTP_HDR_REGEX_MATCHED

  Utilisation des commandes :

match {request|response|req-resp} header regex <parameter-map-name>

Exemple de cas d'utilisation

• Configurez une politique appfw HTTP pour bloquer une requête ou une réponse dont l'en-tête contient des caractères non-ASCII.

parameter-map type regex non_ascii_regex
   pattern “[^\x00-\x80]”
class-map type inspect http non_ascii_cm
   match req-resp header regex non_ascii_regex
policy-map type inspect http non_ascii_pm
   class type inspect http non_ascii_cm
      reset

Inspection de longueur d'en-tête - Cette commande contrôle la longueur d'une en-tête de requête ou réponse et applique une action si la longueur dépasse le seuil configuré. Action autorisée ou réinitialisée. L'ajout de l'action journal entraîne un message syslog :

APPFW-4- HTTP_HEADER_LENGTH

Utilisation des commandes :

match {request|response|req-resp} header length gt <bytes>

Exemple de cas d'utilisation

Configurez une stratégie appfw http pour bloquer les requêtes et les réponses dont la longueur d'en-tête est supérieure à 4 096 octets.

class-map type inspect http hdr_len_cm
   match req-resp header length gt 4096

policy-map type inspect http hdr_len_pm
   class type inspect http hdr_len_cm
      reset

Inspection du nombre d'en-tête - Cette commande vérifie le numéro de lignes d'en-tête (zones) dans une requête/réponse et applique l'action quand le nombre dépasse le seuil configuré. Action autorisée ou réinitialisée. L'ajout de l'action journal entraîne un message syslog :

APPFW-6- HTTP_HEADER_COUNT

Utilisation des commandes :

match {request|response|req-resp} header count gt <number>

Exemple de cas d'utilisation

Configurez une politique appfw http pour bloquer une requête qui a plus de 16 champs d'en-tête.

class-map type inspect http hdr_cnt_cm
   match request header count gt 16

policy-map type inspect http hdr_cnt_pm
   class type inspect http hdr_cnt_cm
      reset

Inspection de champ d'en-tête - Cette commande confère la capacité d'autoriser/refuser/contrôler des demandes/réponses qui contiennent un champ d'en-tête HTTP et une valeur spécifiques. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-6- HTTP_HDR_FIELD_REGEX_MATCHED

Utilisation des commandes :

match {request|response|req-resp} header <header-name>

Exemple de cas d'utilisation

Configurez une politique d'inspection d'application HTTP pour bloquer le spyware/adware :

parameter-map type regex ref_regex
   pattern “\.delfinproject\.com”
   pattern “\.looksmart\.com”

parameter-map type regex host_regex
   pattern “secure\.keenvalue\.com”
   pattern “\.looksmart\.com”

parameter-map type regex usragnt_regex
   pattern “Peer Points Manager”

class-map type inspect http spy_adwr_cm
   match request header refer regex ref_regex 
   match request header host regex host_regex
   match request header user-agent regex usragnt_regex

policy-map type inspect http spy_adwr_pm
   class type inspect http spy_adwr_cm
      reset

Inspection de longueur de champ d'en-tête - Cette commande confère la capacité de limiter la longueur d'une ligne de champ d'en-tête. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-6- HTTP_HDR_FIELD_LENGTH

Utilisation des commandes :

match {request|response|req-resp} header <header-name> length gt <bytes>

Exemple de cas d'utilisation

Configurez une politique appfw http pour bloquer une requête dont la longueur de champ de cookie et d'agent-utilisateur dépasse 256 et 128, respectivement.

class-map type inspect http hdrline_len_cm
   match request header cookie length gt 256
   match request header user-agnet length gt 128

policy-map type inspect http hdrline_len_pm
   class type inspect http hdrline_len_cm
      reset

Inspection de répétition de champ d'en-tête - Cette commande vérifie si une requête ou réponse a répété des champs d'en-tête. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. Une fois activée, l'action journal entraîne un message syslog :

APPFW-6- HTTP_REPEATED_HDR_FIELDS

Utilisation des commandes :

match {request|response|req-resp} header <header-name>

Exemple de cas d'utilisation

Configurez une politique appfw http pour bloquer une requête ou une réponse qui a plusieurs longueurs de contenu de lignes d'en-tête. C'est l'une des fonctionnalités les plus utiles utilisées pour empêcher la contrebande de session .

class-map type inspect http multi_occrns_cm
   match req-resp header content-length count gt 1

policy-map type inspect http multi_occrns_pm
   class type inspect http multi_occrns_cm
      reset

• Inspection de méthode - Le RFC HTTP permet un ensemble limité de méthodes HTTP. Cependant, même certaines des méthodes standards sont considérées comme peu sûres dans la mesure où certaines méthodes peuvent être utilisées pour exploiter des vulnérabilités sur un serveur Web. Plusieurs des méthodes non standards sont fréquemment utilisées pour une activité malveillante. Ceci nécessite de regrouper les méthodes en diverses catégories et de laisser l'utilisateur choisir l'action pour chaque catégorie. Cette commande fournit à l'utilisateur un moyen flexible de regrouper les méthodes dans diverses catégories telles que les méthodes sûres, les méthodes non sûres, les méthodes webdav, les méthodes RFC et les méthodes étendues. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-6-HTTP_METHOD

Utilisation des commandes :

match request method <method>

Exemple de cas d'utilisation

Configurez une stratégie appfw http qui regroupe les méthodes HTTP en trois catégories : safe, unsafe et webdav. Elles sont présentées dans le tableau suivant. Configurez les actions telles que :

• Toutes les méthodes sûres sont permises sans journal.

• Toutes les méthodes peu sûres sont permises avec le journal.

• Toutes les méthodes webdav sont bloquées avec le journal.

Sécuritaire	Non sécuritaire	WebDAV
GET, HEAD, OPTION	POST, PUT, CONNECT, TRACE	BCOPY, BDELETE, BMOVE

http policy:

class-map type inspect http safe_methods_cm
   match request method get
   match request method head
   match request method option
   
class-map type inspect http unsafe_methods_cm
   match request method post
   match request method put
   match request method connect
   match request method trace

class-map type inspect http webdav_methods_cm
   match request method bcopy
   match request method bdelete
   match request method bmove

policy-map type inspect http methods_pm
   class type inspect http safe_methods_cm
      allow
   class type inspect http unsafe_methods_cm
      allow log
      class type inspect http webdav_methods_cm
      reset log

Inspection URI - Cette commande confère la capacité d'autoriser/refuser/contrôler des requêtes pour lesquelles les correspondances URI ont configuré une inspection régulière. Ceci donne à l'utilisateur la capacité de bloquer des URL personnalisés et des requêtes. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-6- HTTP_URI_REGEX_MATCHED

Utilisation des commandes :

match request uri regex <parameter-map-name>

Exemple de cas d'utilisation

Configurez une politique appfw http pour bloquer une requête dont l'URI correspond à l'une de ces expressions régulières :

• .*cmd.exe 

• .*sexe 

• .*paris  

parameter-map type regex uri_regex_cm
   pattern “.*cmd.exe”
   pattern “.*sex”
   pattern “.*gambling”

class-map type inspect http uri_check_cm
   match request uri regex uri_regex_cm

policy-map type inspect http uri_check_pm
   class type inspect http uri_check_cm
      reset

• Inspection de la longueur de l'URI : cette commande vérifie la longueur de l'URI qui est envoyé dans une requête et applique l'action configurée lorsque la longueur dépasse le seuil configuré. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-6- HTTP_URI_LENGTH

  Utilisation des commandes :

  match request uri length gt <bytes>

  Exemple de cas d'utilisation

Configurez une politique appfw http pour déclencher une alarme à chaque fois que la longueur URI d'une requête dépasse 3076 octets.

class-map type inspect http uri_len_cm
   match request uri length gt 3076

policy-map type inspect http uri_len_pm
   class type inspect http uri_len_cm
      log

Inspection d'argument - Cette commande confère la capacité à autoriser, refuser ou contrôler une requête dont les arguments (paramètres) correspondent à l'inspection régulière configurée. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-6- HTTP_ARG_REGEX_MATCHED

Utilisation des commandes :

match request arg regex <parameter-map-name>

Configurez une politique appfw http pour bloquer une requête dont les arguments correspondent à l'une de ces expressions régulières :

• .*CodeRed 

• .*attaque 

parameter-map type regex arg_regex_cm
   pattern “.*codered”
   pattern “.*attack”

class-map type inspect http arg_check_cm
   match request arg regex arg_regex_cm

policy-map type inspect http arg_check_pm
   class type inspect http arg_check_cm
      reset

• Inspection de longueur d'argument — Cette commande vérifie la longueur des arguments qui sont envoyés dans une requête et applique l'action configurée lorsque la longueur dépasse le seuil configuré. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-6- HTTP_ARG_LENGTH

  Utilisation des commandes :

  match request arg length gt <bytes>

  Exemple de cas d'utilisation

Configurez une politique appfw http pour déclencher une alarme à chaque fois que la longueur d'argument d'une requête dépasse 512 octets.

class-map type inspect http arg_len_cm
   match request arg length gt 512

policy-map type inspect http arg_len_pm
   class type inspect http arg_len_cm
      log

• Inspection de corps - Cette CLI permet à l'utilisateur de spécifier une liste des expressions régulières à apparier au corps de la requête ou de la réponse. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-6- HTTP_BODY_REGEX_MATCHED

  Utilisation des commandes :

  match {request|response|reg-resp} body regex <parameter-map-name>

  Exemple de cas d'utilisation

Configurez un appfw http pour bloquer une réponse dont le corps contient le modèle .*[Aa][Tt][Tt][Aa][Cc][Kk]

parameter-map type regex body_regex
   pattern “.*[Aa][Tt][Tt][Aa][Cc][Kk]”

class-map type inspect http body_match_cm
   match response body regex body_regex

policy-map type inspect http body_match_pm
   class type inspect http body_match_cm
      reset

Inspection de la longueur du corps (contenu) — Cette commande vérifie la taille du message qui est envoyé par requête ou réponse. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-4- HTTP_CONTENT_LENGTH

Utilisation des commandes :

match {request|response|req-resp} body length lt <bytes> gt <bytes>

Exemple de cas d'utilisation

Configurez une politique appfw http pour bloquer une session http qui porte un message de plus de 10K octets dans une requête ou une réponse.

class-map type inspect http cont_len_cm
   match req-resp header content-length gt 10240

policy-map type inspect http cont_len_pm
   class type inspect http cont_len_cm
      reset

Inspection de la ligne d'état - Cette commande permet à l'utilisateur de spécifier la liste des expressions régulières à apparier face à la ligne d'état d'une réponse. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

APPFW-6-HTTP_STLINE_REGEX_MATCHED

Utilisation des commandes :

match response status-line regex <class-map-name>

Exemple de cas d'utilisation

Configurez un appfw http pour programmer une alarme à chaque fois qu'une tentative est faite pour accéder à une page interdite. Une page interdite contient généralement un code d'état 403 et la ligne d'état ressemble à HTTP/1.0 403 page interdite\r\n.

parameter-map type regex status_line_regex
   pattern “[Hh][Tt][Tt][Pp][/][0-9][.][0-9][ \t]+403”

class-map type inspect http status_line_cm
   match response status-line regex status_line_regex

policy-map type inspect http status_line_pm
   class type inspect http status_line_cm
      log

• Inspection de type-contenu - Cette commande vérifie si le type de contenu de l'en-tête du message est dans la liste des types de contenus pris en charge. Il vérifie également que le type de contenu de l'en-tête correspond au contenu des données du message ou de la partie de corps d'entité. Si le mot clé mismatch est configuré, la commande vérfie le type de contenu du message de réponse vis-à-vis de la valeur du champ acceptée du message de requête. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne le message syslog approprié :

  APPFW-4- HTTP_CONT_TYPE_VIOLATION 
  APPFW-4- HTTP_CONT_TYPE_MISMATCH
  APPFW-4- HTTP_CONT_TYPE_UNKNOWN

  Utilisation des commandes :

  match {request|response|req-resp} header content-type [mismatch|unknown|violation]

  Exemple de cas d'utilisation

  Configurez une stratégie appfw http pour bloquer une session http qui transporte des requêtes et des réponses dont le type de contenu est inconnu.

  class-map type inspect http cont_type_cm
     match req-resp header content-type unknown
  
  policy-map type inspect http cont_type_pm
     class type inspect http cont_type_cm
        reset

Inspection d'utilisation abusive du port - Cette commande est utilisée pour empêcher le port http (80) d'utiliser abusivement d'autres applications telles que IM, P2P, Tunneling, etc. L'action Autoriser ou Réinitialiser peut être appliquée à une requête ou une réponse qui correspond aux critères de la carte de classe. L'ajout de l'action journal entraîne le message syslog approprié :

APPFW-4- HTTP_PORT_MISUSE_TYPE_IM
APPFW-4-HTTP_PORT_MISUSE_TYPE_P2P
APPFW-4-HTTP_PORT_MISUSE_TYPE_TUNNEL

Utilisation des commandes :

match request port-misuse {im|p2p|tunneling|any}

Exemple de cas d'utilisation

Configurez une stratégie appfw http pour bloquer une session http qui est mal utilisée pour l'application IM.

class-map type inspect http port_misuse_cm
   match request port-misuse im

policy-map type inspect http port_misuse_pm
   class type inspect http port_misuse_cm
      reset

• Inspection http strict - Cette commande active un contrôle de conformité de protocole strict vis-à-vis de requêtes et réponses HTTP. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-4- HTTP_PROTOCOL_VIOLATION

  Utilisation des commandes :

  match req-resp protocol-violation

  Exemple de cas d'utilisation

  Configurez une stratégie appfw http pour bloquer les requêtes ou les réponses qui enfreignent la RFC 2616 :

  class-map type inspect http proto-viol_cm 
     match req-resp protocol-violation 
  
  policy-map type inspect http proto-viol_pm 
     class type inspect http proto-viol_cm 
        reset

• Transfer-Encoding Inspection : cette commande permet d'autoriser, de refuser ou de surveiller les requêtes/réponses dont le type de codage de transfert correspond au type configuré. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-6- HTTP_TRANSFER_ENCODING

  Utilisation des commandes :

  match {request|response|req-resp} header transfer-encoding 
  {regex <parameter-map-name> |gzip|deflate|chunked|identity|all}

  Exemple de cas d'utilisation

  Configurez une politique appfw http pour bloquer une requête ou réponse qui a un type de codage comprimé.

  class-map type inspect http trans_encoding_cm
     match req-resp header transfer-encoding type compress
  
  policy-map type inspect http trans_encoding_pm
     class type inspect http trans_encoding_cm
        reset

• Inspection Applet Java - Cette commande contrôle si une réponse a l'applet Java et applique l'action configurée à la découverte de l'applet. L'action permettre ou réinitialiser peut être appliquée à une requête ou à une réponse correspondant aux critères de la carte-classe. L'ajout de l'action journal entraîne un message syslog :

  APPFW-4- HTTP_JAVA_APPLET 

  Utilisation des commandes :

  match response body java-applet

  Exemple de cas d'utilisation

  Configurez une politique appfw http pour bloquer des applets Java.

  class-map type inspect http java_applet_cm
     match response body java-applet
  
  policy-map type inspect http java_applet_pm
     class type inspect http java_applet_cm
        reset

Assistance ZFW du contrôle de transmission de messages instantanée et d'application pair à pair

Le logiciel Cisco IOS version 12.4(9)T a mis en place l'assistance ZFW pour IM et les applications P2P

Le logiciel Cisco IOS a mis en place la prise en charge du contrôle de l'application IM dans le logiciel Cisco IOS version 12.4(4)T. La version initiale de ZFW ne prenait pas en charge l'application IM dans l'interface ZFW. Si le contrôle d'application IM était désiré, les utilisateurs n'étaient pas en mesure de migrer vers l'interface de configuration ZFW. Le logiciel Cisco IOS Version 12.4(9)T introduit la prise en charge ZFW pour l'inspection de messagerie instantanée, qui prend en charge Yahoo ! Messenger (YM), MSN Messenger (MSN) et AOL Instant Messenger (AIM). La version 12.4(9)T du logiciel Cisco IOS est la première version du logiciel Cisco IOS qui offre une prise en charge native du pare-feu Cisco IOS pour les applications de partage de fichiers P2P.

IM et l'inspection P2P offrent tous les deux les politiques de la couche 4 et de la couche 7 pour le trafic d'application. Cela signifie que ZFW peut fournir une inspection avec état de base pour autoriser ou refuser le trafic, ainsi qu'un contrôle granulaire de couche 7 sur des activités spécifiques dans les divers protocoles, de sorte que certaines activités d'application sont autorisées tandis que d'autres sont refusées.

Inspection d'application P2P et contrôle

SDM 2.2 a mis en place le contrôle de l'application P2P dans la section de sa configuration du pare-feu. SDM a appliqué une stratégie de reconnaissance d’application basée sur le réseau (NBAR) et de qualité de service pour détecter et contrôler l’activité des applications P2P à un débit de ligne de zéro et pour bloquer tout le trafic P2P. Cela a soulevé le problème suivant : les utilisateurs CLI, qui attendaient la prise en charge P2P dans la CLI du pare-feu Cisco IOS, n'ont pas pu configurer le blocage P2P dans la CLI, à moins qu'ils n'aient connaissance de la configuration NBAR/QoS nécessaire. La version 12.4(9)T du logiciel Cisco IOS introduit le contrôle P2P natif dans l'interface de ligne de commande de ZFW, afin d'exploiter NBAR pour détecter l'activité des applications P2P. Cette version du logiciel prend en charge plusieurs protocoles d'application P2P :

• BitTorrent

• eDonkey

• FastTrack

• Gnutella

• KaZaA / KaZaA2

• WinMX

Les applications P2P sont particulièrement difficiles à détecter, en raison du comportement de saut de port et d'autres astuces pour éviter la détection, ainsi que des problèmes introduits par des modifications et des mises à jour fréquentes des applications P2P qui modifient les comportements des protocoles. ZFW combine l'inspection dynamique du pare-feu original avec les capacités de reconnaissance de trafic de NBAR pour assurer le contrôle de l'application P2P dans l'interface de configuration CPL de ZFW. NBAR offre deux excellents avantages :

1. Reconnaissance d'application sur une base heuristique facultative pour identifier des applications malgré le comportement complexe, difficile à détecter.

2. Infrastructure extensible offrant un mécanisme de mise à jour pour suivre les mises à jour et les modifications de protocole

Configurer l'inspection P2P

Comme mentionné précédemment, l'inspection P2P et le contrôle offrent une inspection dynamique de la couche 4 et le contrôle d'application de la couche 7. L'inspection de la couche 4 est configurée de la même manière que les autres services d'application, si l'inspection des ports de service d'application natifs est adéquate :

class-map type inspect match-any my-p2p-class
match protocol [bittorrent | edonkey | fasttrack | gnutella | kazaa | kazaa2 | winmx ] 
[signature (optional)]
!
policy-map type inspect private-allowed-policy
 class type inspect my-p2p-class
  [drop | inspect | pass]

Remarquez la signature supplémentaire du protocole correspondant [nom-service]. Lorsque l'option de signature est ajoutée à la fin de l'instruction de protocole de correspondance, l'heuristique NBAR est appliquée au trafic pour rechercher des indicateurs dans le trafic qui indiquent une activité d'application P2P spécifique. Ceci comprend le saut de port et d'autres changements du comportement de l'application pour éviter la détection de trafic. Ce niveau d'inspection du trafic est établi au prix de l'utilisation accrue du CPU et de la capacité réduite du débit du réseau. Si l'option de signature n'est pas appliquée, l'analyse heuristique basée sur NBAR n'est pas appliquée pour détecter le comportement de saut de port, et l'utilisation du CPU n'est pas affectée dans la même mesure.

L'inspection du service natif présente l'inconvénient de ne pas pouvoir garder le contrôle sur les applications P2P dans le cas où l'application saute vers un port source et de destination non standard, ou si l'application est mise à jour pour commencer son action sur un numéro de port non reconnu :

Application	Ports originaux (tels que reconnus par 12.4(15)T PAM liste)
bittorrent	TCP 6881-6889
edonkey	TCP 4662
fasttrack	TCP 1214
gnutella	TCP 6346-6349 TCP 6355,5634 UDP 6346-6348
kazaa2	Dépendant de PAM
winmx	TCP 6699

Si vous souhaitez autoriser (inspecter) le trafic P2P, vous pouvez avoir besoin de fournir une configuration supplémentaire. Certaines applications peuvent utiliser plusieurs réseaux P2P, ou mettre en oeuvre des comportements spécifiques que vous devez intégrer dans la configuration de votre pare-feu pour permettre à l'application de fonctionner :

• Les clients BitTorrent communiquent généralement avec des trackers (serveurs d'annuaire homologues) via http qui s'exécute sur un port non standard. Il s’agit généralement du protocole TCP 6969, mais vous devez vérifier le port de suivi spécifique au torrent. Si vous souhaitez autoriser BitTorrent, la meilleure méthode pour prendre en charge le port supplémentaire est de configurer HTTP comme l'un des protocoles de correspondance et d'ajouter TCP 6969 à HTTP avec la commande ip port-map :

  ip port-map http port tcp 6969
  

  Vous devez définir http et bittorrent comme critères de correspondance appliqués dans la carte-classe.

• eDonkey semble lancer les connexions qui sont détectées comme eDonkey et Gnutella.

• L'inspection de KaZaA dépend entièrement de la détection de signature NBAR.

L'inspection de couche 7 (application) complète l'inspection de couche 4 avec la capacité de reconnaître et d'appliquer des actions spécifiques au service, telles que le blocage ou l'autorisation sélectifs des fonctionnalités de recherche de fichiers, de transfert de fichiers et de conversation textuelle. Capacités spécifiques au service par service.

L'inspection de l'application P2P est semblable à l'inspection de l'application HTTP :

!configure the layer-7 traffic characteristics:
class-map type inspect [p2p protocol] match-any p2p-l7-cmap
 match action
!
!configure the action to be applied to the traffic 
!matching the specific characteristics:
policy-map type inspect [p2p protocol] p2p-l7-pmap
 class type inspect p2p p2p-l7-cmap
  [ reset | allow ]
  log
!
!define the layer-4 inspection policy
class-map type inspect match-all p2p-l4-cmap
 match protocol [p2p protocol]
!
!associate layer-4 class and layer-7 policy-map
!in the layer-4 policy-map:
policy-map type inspect private-allowed-policy
 class type inspect p2p-l4-cmap
  [ inspect | drop | pass ]
  service-policy p2p p2p-l7-pmap

L'inspection de l'application P2P offre des capacités spécifiques pour un sous-ensemble des applications prises en charge par l'inspection de la couche 4 :

• edonkey

• fasttrack

• gnutella

• kazaa2

Chacune de ces applications offre des options de critères de correspondance variables spécifiques à l'application :

edonkey

router(config)#class-map type inspect edonkey match-any edonkey-l7-cmap
router(config-cmap)#match ?
  file-transfer     Match file transfer stream
  flow              Flow based QoS parameters
  search-file-name  Match file name
  text-chat         Match text-chat

fasttrack

router(config)#class-map type inspect fasttrack match-any ftrak-l7-cmap
router(config-cmap)#match ?
  file-transfer  File transfer stream
  flow           Flow based QoS parameters

gnutella

router(config)#class-map type inspect gnutella match-any gtella-l7-cmap
router(config-cmap)#

kazaa2

router(config)#class-map type inspect kazaa2 match-any kazaa2-l7-cmap
router(config-cmap)#match ?
  file-transfer  Match file transfer stream
  flow           Flow based QoS parameters

Les nouvelles définitions de protocole P2P ou les mises à jour des protocoles P2P actuels peuvent être chargées avec la fonctionnalité de mise à jour pdlm dynamique de NBAR. Celle-ci est la commande de configuration pour charger le nouveau PDLM :

ip nbar pdlm <file-location>

Le nouveau protocole est disponible dans les commandes match protocol pour class type inspect. Si le nouveau protocole P2P a des services (sous-protocoles), la nouvelle couche 7 qui inspecte des types de carte-classe aussi bien que les critères de correspondance de la couche 7, deviennent disponibles.

Inspection d'application IM et contrôle

Le logiciel Cisco IOS version 12.4(4)T a mis en place l'inspection et le contrôle de l'application IM. La prise en charge de l'IM n'a pas été mis en place avec ZFW dans 12.4(6)T, ainsi les utilisateurs ne pouvaient pas appliquer le contrôle IM et le ZFW dans la même politique de pare-feu, car ZFW et des caractéristiques de pare-feu habituelles ne peuvent pas coexister sur une interface donnée.

Le logiciel Cisco IOS version 12.4(9)T prend en charge l'inspection dynamique et le contrôle d'application pour ces services IM :

• AOL Instant Messenger

• MSN Messenger

• Yahoo! Messenger

L’inspection de la messagerie instantanée diffère légèrement de la plupart des services, car elle contrôle l’accès à un groupe spécifique d’hôtes pour chaque service donné. Les services IM comptent généralement sur un groupe relativement permanent de serveurs de répertoire, que les clients doivent pouvoir contacter afin d'accéder au service IM. Les applications IM tendent à être très difficiles à contrôler du point de vue du protocole ou du service. La façon la plus efficace de contrôler ces applications est de limiter l'accès aux serveurs IM fixes.

Configurer l'inspection IM

L'inspection et le contrôle MI offrent une inspection dynamique de couche 4

et le contrôle des applications de couche 7.

L'inspection de la couche 4 est configurée de la même façon que d'autres services d'applications :

class-map type inspect match-any my-im-class
match protocol [aol | msnmsgr | ymsgr ]
!
policy-map type inspect private-allowed-policy
 class type inspect my-im-class
  [drop | inspect | pass

Les applications IM peuvent entrer en contact avec leurs serveurs sur plusieurs ports pour conserver leur fonctionnalité. Pour autoriser un service de messagerie instantanée donné avec l'action d'inspection, vous ne pouvez pas avoir besoin d'une liste de serveurs pour définir l'accès autorisé aux serveurs du service de messagerie instantanée. Cependant, lorsque vous configurez une carte-classe qui spécifie un service de messagerie instantanée donné, tel qu'AOL Instant Messenger, et que vous appliquez l'action d'abandon dans la carte-politique associée, le client de messagerie instantanée peut essayer de localiser un autre port où la connectivité à Internet est autorisée. Si vous ne voulez pas permettre la connectivité à un service donné ou si vous voulez restreindre la capacité de service IM au texte-dialogue en ligne, vous devez définir une liste de serveur afin que ZFW puisse identifier le trafic associé à l'application IM :

!configure the server-list parameter-map:
parameter-map type protocol-info <name>
  server name <name> 
  server ip a.b.c.d
  server ip range a.b.c.d a.b.c.d

Par exemple, la liste de serveur IM de Yahoo est définie en tant que telle :

parameter-map type protocol-info ymsgr-pmap
  server name scs.msg.example.com
  server name scsd.msg.example.com
  server ip 10.0.77.88
  server ip range 172.16.0.77 172.16.0.99

Vous devez appliquer la liste de serveurs à la définition de protocole :

class-map type inspect match-any ym-l4-cmap
 match protocol ymsgr ymsgr-pmap

Vous devez configurer les commandes ip domain lookup et ip name-server ip.ad.re.ss afin de permettre la résolution de noms.

Les noms de serveur IM sont assez dynamiques. Vous devez vérifier régulièrement que vos listes de serveurs de messagerie instantanée configurées sont complètes et correctes.

L'inspection de couche 7 (application) complète l'inspection de couche 4 avec la capacité de reconnaître et d'appliquer des actions spécifiques au service, telles que le blocage ou l'autorisation sélectifs des fonctionnalités de conversation textuelle et le refus d'autres fonctionnalités de service.

L'inspection de l'application IM offre actuellement la capacité de différencier entre l'activité de texte-dialogue en ligne et tous les autres services d'application. Afin de restreindre l'activité IM au texte-dialogue en ligne, configurez la politique de la couche 7 :

class-map type inspect ymsgr match-any ymsgr-text-cmap
  match service text-chat

class-map type inspect ymsgr match-any ymsgr-default-cmap
  match service any

policy-map type inspect im ymsgr-l7-pmap
  class type inspect im ymsgr-text-cmap
    allow
    [log]
  class type inspect im ymsgr-text-cmap
    reset
    [log]

Appliquez la politique de la couche 7 à Yahoo ! Politique de Messenger configurée plus tôt :

class-map type inspect match-any my-im-class
match protocol ymsgr
!
policy-map type inspect private-allowed-policy
 class type inspect my-im-class
  inspect
  service-policy im ymsgr-l7-pmap

Filtres d'URL

ZFW offre des fonctionnalités de filtrage URL pour limiter l'accès au contenu Web à celui spécifié par une liste blanche ou noire définie sur le routeur ou en transmettant des noms de domaines vers un serveur de filtrage URL pour vérifier l'accès aux domaines spécifiques. Le filtrage URL de ZFW dans le logiciel Cisco IOS versions 12.4(6)T à 12.4(15)T est appliqué comme action supplémentaire de politique, semblable à l'inspection de l'application.

Pour le Filtrage URL basé sur le serveur, vous devez définir une carte-paramètre qui décrit la configuration du serveur urlfilter :

parameter-map type urlfilter websense-parmap
 server vendor [n2h2 | websense] 10.1.1.1

Si des listes statiques blanches ou noires sont préférées, vous pouvez définir une liste des domaines ou des sous-domaines qui sont spécifiquement permis ou refusés, alors que l'action inverse est appliquée au trafic qui ne correspond pas à la liste :

parameter-map type urlfilter websense-parmap
 exclusive-domain deny .example.com
 exclusive-domain permit .cisco.com

Si une liste noire d'URL est définie avec des options de refus dans les définitions de domaines exclusifs, tous les autres domaines sont autorisés. Si des définitions d'« autorisation » sont définies, tous les domaines autorisés doivent être explicitement spécifiés, de la même manière que les listes de contrôle d'accès IP.

Configurez une carte-classe qui correspond au trafic HTTP :

class-map type inspect match-any http-cmap
 match protocol http

Définissez une carte-politique qui associe votre carte-classe avec les actions inspecter et urlfilter :

policy-map type inspect http-filter-pmap
 class type inspect http-cmap
  inspect 
  urlfilter websense-parmap

Ceci configure la condition minimale de communiquer avec un serveur de filtrage URL. Plusieurs options sont disponibles pour définir le comportement supplémentaire de filtrage URL.

Certains déploiements réseau souhaitent appliquer le filtrage URL à certains hôtes ou sous-réseaux et contourner le filtrage URL pour d’autres hôtes. Par exemple, dans l'image 9, tous les hôtes de la zone privée doivent faire contrôler le trafic HTTP par un serveur de filtre d'URL, à l'exception de l'hôte spécifique 192.168.1.101.

Image 10 : Exemple de topologie de filtrage d'URL

Exemple de topologie de filtrage URL

Ceci peut être accompli si vous définissez deux cartes de carte de classe différentes :

• Une carte-classe qui ne correspond qu'au trafic HTTP pour le plus grand groupe d'hôtes, qui reçoivent le filtrage des URL.

• Une carte-classe pour le plus petit groupe d'hôtes, qui ne reçoivent pas de filtrage d'URL. La deuxième class-map correspond au trafic HTTP, ainsi qu'à une liste d'hôtes qui sont exemptés de la stratégie de filtrage d'URL.

Les deux cartes-classes sont configurées dans une carte-politique, mais une seule reçoit l'action urlfilter :

class-map type inspect match-any http-cmap
 match protocol http
class-map type inspect match-all http-no-urlf-cmap
 match protocol http
 match access-group 101
!
policy-map type inspect http-filter-pmap
 class type inspect http-no-urlf-cmap
  inspect
 class type inspect http-cmap
  inspect 
  urlfilter websense-parmap
!
access-list 101 permit ip 192.168.1.101 any

Contrôle de l'accès au routeur

La plupart des ingénieurs de sécurité réseau sont mal à l'aise s'ils exposent les interfaces de gestion du routeur (par exemple, SSH, Telnet, HTTP, HTTPS, SNMP, etc.) à l'Internet public et, dans certaines circonstances, le contrôle est également nécessaire pour l'accès LAN au routeur. Le logiciel Cisco IOS offre un certain nombre d'options pour limiter l'accès aux diverses interfaces, qui comprennent la fonctionnalité familiale Network Foundation Protection (NFP), divers mécanismes de contrôle d'accès pour les interfaces de gestion et l'auto-zone de ZFW. Vous devez examiner d'autres fonctionnalités, telles que le contrôle d'accès VTY, la protection du plan de gestion et le contrôle d'accès SNMP, afin de déterminer quelle combinaison de fonctionnalités de contrôle de routeur convient le mieux à votre application spécifique.

Généralement, la famille de fonctionnalité NFP est plus adaptée pour le contrôle du trafic destiné au routeur lui-même. Référez-vous à Vue d'ensemble de la sécurité du plan de contrôle dans le logiciel Cisco IOS pour des informations qui décrivent la protection du routeur avec les fonctionnalités NFP.

Si vous décidez d'appliquer ZFW pour contrôler le trafic vers et depuis les adresses IP sur le routeur lui-même, vous devez comprendre que la stratégie et les capacités par défaut du pare-feu diffèrent de celles disponibles pour le trafic de transit. Le trafic de transit est défini comme le trafic réseau dont les adresses IP source et de destination ne correspondent à aucune adresse IP appliquée à l'une des interfaces du routeur, et le trafic n'entraîne pas l'envoi par le routeur, par exemple, de messages de contrôle de réseau tels que l'expiration de la durée de vie du protocole ICMP ou des messages d'inaccessibilité du réseau/de l'hôte.

ZFW applique une politique de refus de tout par défaut au trafic qui se déplace entre les zones, à l'exception, comme mentionné dans les règles générales, du trafic dans n'importe quelle zone qui circule directement vers les adresses des interfaces du routeur est implicitement autorisé. Ceci s'assure que la connectivité aux interfaces de gestion du routeur est conservée quand une configuration de pare-feu de zone est appliquée au routeur. Si la même politique refuser tout affectait la connectivité directement sur le routeur, une configuration de politique complète de gestion devrait être appliquée avant que des zones soient configurées sur le routeur. Ceci perturberait vraisemblablement la connectivité de gestion si la politique était incorrectement mise en application ou appliquée dans un ordre incorrect.

Quand une interface est configurée pour être un membre de zone, les serveurs connectés à l'interface sont inclus dans la zone. Cependant, le trafic qui circule vers et depuis les adresses IP des interfaces du routeur n'est pas contrôlé par les politiques de zone (à l'exception des circonstances décrites dans la note de l'image 10). Au lieu de cela, toutes les interfaces IP sur le routeur sont automatiquement intégrées à la zone self lorsque ZFW est configuré. Afin de contrôler le trafic IP qui se déplace vers les interfaces du routeur à partir des différentes zones d'un routeur, des politiques doivent être appliquées pour bloquer ou autoriser/inspecter le trafic entre la zone et la zone autonome du routeur, et vice versa (voir l'image 11).

Image 11 : Application de la stratégie entre les zones réseau et la zone autonome du routeur

Application électronique des politiques entre les zones réseau et la zone autonome du routeur

Bien que le routeur offre une politique d'autorisation par défaut entre toutes les zones et la zone autonome, si une politique est configurée d'une zone à l'autre et qu'aucune politique n'est configurée d'elle-même aux zones connectées à l'interface configurables par l'utilisateur du routeur, tout le trafic provenant du routeur rencontre la politique de zone connectée à la zone autonome à son retour au routeur et est bloqué. Par conséquent, le trafic provenant d'un routeur doit être inspecté pour permettre son retour dans la zone d'auto-adressage.

Remarque : le logiciel Cisco IOS utilise toujours l'adresse IP associée à une interface des hôtes de destination les plus proches pour le trafic tel que syslog, tftp, telnet et d'autres services du plan de contrôle, et soumet ce trafic à la politique de pare-feu de zone autonome. Cependant, si un service définit une interface spécifique comme l'interface source avec des commandes qui incluent, mais sans s'y limiter, logging source-interface [type number] , ip tftp source-interface [type number] , et ip telnet source-interface [type number] , le trafic est soumis à la zone self.

Remarque : certains services (en particulier les services de voix sur IP des routeurs) utilisent des interfaces éphémères ou non configurables qui ne peuvent pas être affectées à des zones de sécurité. Ces services ne peuvent pas fonctionner correctement si leur trafic ne peut pas être associé à une zone de sécurité configurée.

Limitations de la politique de zone individuelle

La politique de zone individuelle a une fonctionnalité limité en comparaison aux politiques disponibles pour les zones paires de trafic en transit :

• Comme cela était le cas pour l'inspection dynamique, le trafic engendré par routeur se limite à l'inspection du protocole complexe TCP, UDP, ICMP pour H.323.

• L'inspection de l'application n'est pas disponible pour les politiques de zone individuelle.

• La limitation de session et de débit ne peut pas être configurée dans les politiques de zone individuelle.

Configuration de la politique de zone individuelle

Dans la plupart des cas, il s'agit de politiques d'accès souhaitables pour les services de gestion des routeurs :

• La connectivité Telnet refuser tout, comme le protocole de libellé de Telnet expose facilement les identifiants et autres informations confidentielles de l'utilisateur.

• Permettez les connexions SSH de n'importe quel utilisateur dans n'importe quelle zone. SSH encrypte les identifiants de l'utilisateur et les données de session, ce qui assure la protection contre les utilisateurs malveillants qui emploient des outils de saisie de paquet pour surveiller l'activité de l'utilisateur et compromettre les identifiants ou les informations confidentielles telles que la configuration du routeur. SSH Version 2 offre une protection renforcée et résout les vulnérabilités spécifiques inhérentes à SSH Version 1.

• Autorisez la connectivité HTTP au routeur à partir des zones privées si la zone privée est fiable. Dans le cas contraire, si la zone privée risque de compromettre les informations par des utilisateurs malveillants, HTTP n'utilise pas de cryptage pour protéger le trafic de gestion et peut révéler des informations sensibles telles que les informations d'identification ou la configuration des utilisateurs.

• Permettez la connectivité HTTPS de n'importe quelle zone. Semblable au SSH, HTTPS encrypte les données de session et les identifiants de l'utilisateur.

• Limitez l'accès restreint SNMP à un hôte spécifique ou sous-réseau. SNMP peut être utilisé pour modifier la configuration du routeur et révéler les informations de configuration. Le protocole SNMP doit être configuré avec un contrôle d'accès sur les différentes communautés.

• Bloquer les requêtes ICMP de l'Internet public vers l'adresse de la zone privée (cela suppose que l'adresse de la zone privée est routable). Une ou plusieurs adresses publiques peuvent être exposées pour le trafic ICMP à des fins de dépannage réseau, si nécessaire. Plusieurs attaques d'ICMP peuvent être utilisées pour accabler les ressources du routeur ou pour reconnaître la topologie du réseau et l'architecture.

Un routeur peut appliquer ce type de politique en plus de deux zones-paires pour chaque zone qui doit être contrôlée. Chaque paire de zones pour le trafic entrant ou sortant vers la zone autonome du routeur doit correspondre à la politique correspondante dans la direction opposée, à moins que le trafic ne soit pas généré dans la direction opposée. Une carte-politique peut être appliquée à chacune des zones-paires interne et externe, décrivant tout le trafic ou des cartes-politiques spécifiques par zone-paire peuvent être appliqués. La configuration de zones-paires spécifiques par carte-politique fournit une granularité pour visualiser l'activité qui correspond à chaque carte-politique.

Dans un exemple de réseau avec une station de gestion SNMP à l’adresse 172.17.100.11 et un serveur TFTP à l’adresse 172.17.100.17, ce résultat fournit un exemple de la politique d’accès à l’interface de gestion complète :

class-map type inspect match-any self—service-cmap
 match protocol tcp
 match protocol udp
 match protocol icmp
 match protocol h323
!
class-map type inspect match-all to-self-cmap
 match class-map self—service-cmap
 match access-group 120
!
class-map type inspect match-all from-self-cmap
 match class-map self—service-cmap
!
class-map type inspect match-all tftp-in-cmap
 match access-group 121
!
class-map type inspect match-all tftp-out-cmap
 match access-group 122
!
policy-map type inspect to-self-pmap
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
zone security private
zone security internet
zone-pair security priv-self source private destination self
 service-policy type inspect to-self-pmap
zone-pair security net-self source internet destination self
 service-policy type inspect to-self-pmap
zone-pair security self-priv source self destination private 
 service-policy type inspect from-self-pmap
zone-pair security self-net source self destination internet
 service-policy type inspect from-self-pmap

!
interface FastEthernet 0/0
 ip address 172.16.100.10
 zone-member security internet
!
interface FastEthernet 0/1
 ip address 172.17.100.10
 zone-member security private
!
access-list 120 permit icmp 172.17.100.0 0.0.0.255 any
access-list 120 permit icmp any host 172.17.100.10 echo
access-list 120 deny icmp any any
access-list 120 permit tcp 172.17.100.0 0.0.0.255 host 172.17.100.10 eq www
access-list 120 permit tcp any any eq 443
access-list 120 permit tcp any any eq 22
access-list 120 permit udp any host 172.17.100.10 eq snmp
access-list 121 permit udp host 172.17.100.17 host 172.17.100.10 
access-list 122 permit udp host 172.17.100.10 host 172.17.100.17

Malheureusement, la politique de zone indivuelle n'offre pas la capacité d'inspecter des transferts TFTP. Ainsi, le pare-feu doit passer tout le traffic en direction et en provenance du serveur TFTP si TFTP doit passer par le pare-feu.

Si le routeur met fin à des connexions VPN IPSec, vous devez également définir une stratégie pour transmettre IPSec ESP, IPSec AH, ISAKMP et NAT-T IPSec (UDP 4500). Cela dépend de ce qui est nécessaire en fonction des services que vous utilisez. Cette stratégie suivante peut être appliquée en plus de la stratégie ci-dessus. Notez la modification des policy-maps où une class-map pour le trafic VPN a été insérée avec une action de passage. Généralement, le trafic encrypté est digne de confiance, à moins que votre politique de sécurité énonce que vous devez laisser le trafic encrypté en direction et en provenance de points finaux déterminés.

class-map type inspect match-all crypto-cmap
 match access-group 123
!
policy-map type inspect to-self-pmap
 class type inspect crypto-cmap
  pass
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect crypto-cmap
  pass
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
access-list 123 permit esp any any
access-list 123 permit udp any any eq 4500
access-list 123 permit ah any any 
access-list 123 permit udp any any eq 500

Pare-feu selon des zones et services d'application de vaste domaine

Reportez-vous à la Note de version de Cisco Wide Area Application Services (Software Version 4.0.13) - New Features for Software Version 4.0.13 pour obtenir une note d'application qui fournit des exemples de configuration et des conseils d'utilisation

Surveillance du pare-feu de stratégie basé sur les zones avec les commandes show et debug

ZFW met en place de nouvelles commandes afin de visualiser la politique de configuration et contrôler l'activité de pare-feu.

Affichez la description de zone et les interfaces contenues dans une zone spécifique :

show zone security [<zone-name>]

Quand le nom de la zone n'est pas compris, la commande affiche l'information de toutes les zones configurées.

Router#show zone security z1
zone z1
  Description: this is test zone1
  Member Interfaces:
    Ethernet0/0

Affichez la zone source, la zone de destination et la politique liée à la zone paire :

show zone-pair security [source <source-zone-name>] [destination <destination-zone-name>]

Quand aucune source ou destination n'est spécifiée, toutes les zones-paires avec source, destination et politique associée sont affichées. Quand seulement la zone source/de destination est mentionnée, toutes les zones paires qui contiennent cette zone en tant que source/destination sont affichées.

Router#show zone-pair security   
zone-pair name zp
  Source-Zone z1  Destination-Zone z2 
  service-policy p1

Affiche une carte-politique déterminée :

show policy-map type inspect [<policy-map-name> [class <class-map-name]]

Lorsque le nom d'une carte-politique n'est pas spécifié, il affiche toutes les cartes-politiques de type inspecter (ainsi que les cartes-politiques de couche 7 qui contiennent un sous-type).

Router#show policy-map type inspect p1
 Policy Map type inspect p1
   Class c1
    Inspect

Affiche les statistiques de mappage de stratégie de type d'inspection d'exécution actuellement sur une zone-paire spécifiée.

show policy-map type inspect zone-pair [zone-pair-name] [sessions]

Quand aucun nom de zone-paire est mentionné, des cartes-politiques sur toutes les zones-paires sont affichées.

L'option sessions affiche les sessions d'inspection créées par l'application de carte-politique sur la zone-paire spécifique.

Router#show policy-map type inspect zone-pair zp
 Zone-pair: zp

  Service-policy : p1

    Class-map: c1 (match-all)
      Match: protocol tcp
      Inspect
        Session creations since subsystem startup or last reset 0
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [0:0:0]
        Last session created never
        Last statistic reset never
        Last session creation rate 0
        Last half-open session total 0   

    Class-map: c2 (match-all)
      Match: protocol udp
      Pass
        0 packets, 0 bytes

    Class-map: class-default (match-any)
      Match: any
      Drop
        0 packets, 0 bytes

Le mot-clé urlfilter affiche les statistiques liées à l'urlfilter qui concernent la carte-politique spécifiée (ou des cartes politiques sur toutes les cibles quand aucun nom de zone-paire n'est spécifié) :

show policy-map type inspect zone-pair [zone-pair-name] [urlfilter [cache]]

Quand le mot clé cache est spécifié avec urlfilter, il affiche le cache d'urlfilter (d'adresse IP).

Résumé de la commande show policy-map pour inspecter les cartes-politiques :

show policy-map type inspect inspect { <policy name> [class <class name>] |
	                  zone-pair [<zone-pair name>] [sessions | urlfilter cache] }

Régler la protection par déni de service du pare-feu par zone

ZFW offre la protection DoS pour alerter des ingénieurs réseau aux changements excessifs de l'activité réseau, et pour atténuer l'activité non désirée pour réduire l'incidence des modifications d'activité réseau. ZFW met à jour un compteur distinct pour chaque carte-classe de carte-politique. Ainsi, si une carte-classe est utilisée pour deux cartes-politiques de paires de zones différentes, deux ensembles différents de compteurs de protection DoS sont appliqués.

ZFW assure la réduction d'attaque DoS par défaut sur des versions du logiciel Cisco IOS antérieures à 12.4(11)T. Le comportement de protection DoS par défaut a changé avec le logiciel Cisco IOS version 12.4(11)T. 

Reportez-vous à la Définir des politiques pour protéger contre des attaques de déni de service SYN TCP pour plus d'informations sur les attaques DoS SYN TCP.

Annexes

Annexe A : Configuration de base

ip subnet-zero
ip cef
!
bridge irb
!
interface FastEthernet0
 ip address 172.16.1.88 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1
 ip address 172.16.2.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2
 switchport access vlan 2
!
interface FastEthernet3
 switchport access vlan 2
!
interface FastEthernet4 
 switchport access vlan 1
!
interface FastEthernet5 
 switchport access vlan 1
!
interface FastEthernet6 
 switchport access vlan 1
!
interface FastEthernet7 
 switchport access vlan 1
!
interface Vlan1
 no ip address
 bridge-group 1
!
interface Vlan2
 no ip address
 bridge-group 1
!
interface BVI1
 ip address 192.168.1.254 255.255.255.0
 ip route-cache flow
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
bridge 1 protocol ieee
bridge 1 route ip
!
end

Annexe B : Configuration finale (complète)

ip subnet-zero
ip cef
!
ip port-map user-Xwindows port tcp from 6900 to 6910
!
class-map type inspect match-any L4-inspect-class
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-any L7-inspect-class
  match protocol ssh
  match protocol ftp
  match protocol pop
  match protocol imap
  match protocol esmtp
  match protocol http
class-map type inspect match-any dns-http-class
 match protocol dns
 match protocol http
class-map type inspect match-any smtp-class
 match protocol smtp
class-map type inspect match-all dns-http-acl-class
 match access-group 110
 match class-map dns-http-class
class-map type inspect match-all smtp-acl-class
 match access-group 111
 match class-map smtp-class
class-map type inspect match-any Xwindows-class
 match protocol user-Xwindows
class-map type inspect match-any internet-traffic-class
 match protocol http
 match protocol https
 match protocol dns
 match protocol icmp
class-map type inspect http match-any bad-http-class
 match  port-misuse all
 match  strict-http
!
policy-map type inspect clients-servers-policy
 class type inspect L4-inspect-class
  inspect
policy-map type inspect private-dmz-policy
  class type inspect L7-inspect-class
   inspect
policy-map type inspect internet-dmz-policy
 class type inspect dns-http-acl-class
  inspect
 class type inspect smtp-acl-class
  inspect
policy-map type inspect servers-clients-policy
 class type inspect Xwindows-class
  inspect
policy-map type inspect private-internet-policy
  class type inspect internet-traffic-class
   inspect
  class type inspect bad-http-class
   drop
!
zone security clients
zone security servers
zone security private
zone security internet
zone security dmz
zone-pair security private-internet source private destination internet
  service-policy type inspect private-internet-policy
zone-pair security servers-clients source servers destination clients
  service-policy type inspect servers-clients-policy
zone-pair security clients-servers source clients destination servers
  service-policy type inspect clients-servers-policy
zone-pair security private-dmz source private destination dmz
  service-policy type inspect private-dmz-policy
zone-pair security internet-dmz source internet destination dmz
  service-policy type inspect internet-dmz-policy
!
bridge irb
!
interface FastEthernet0
 ip address 172.16.1.88 255.255.255.0
 zone-member internet
!
interface FastEthernet1
 ip address 172.16.2.1 255.255.255.0
 zone-member dmz
!
interface FastEthernet2
 switchport access vlan 2
!
interface FastEthernet3
 switchport access vlan 2
!
interface FastEthernet4 
 switchport access vlan 1
!
interface FastEthernet5 
 switchport access vlan 1
!
interface FastEthernet6 
 switchport access vlan 1
!
interface FastEthernet7 
 switchport access vlan 1
!
interface Vlan1
 no ip address
 zone-member clients 
 bridge-group 1
!
interface Vlan2
 no ip address
 zone-member servers
 bridge-group 1
!
interface BVI1
 ip address 192.168.1.254 255.255.255.0
 zone-member private
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
access-list 110 permit ip any host 172.16.2.2
access-list 111 permit ip any host 172.16.2.3
!
bridge 1 protocol ieee
bridge 1 route ip
!
End

Annexe C : Configuration de base du pare-feu à politique de zone pour deux zones

Cet exemple fournit une configuration simple comme base pour tester les fonctionnalités pour les améliorations apportées au logiciel Cisco IOS ZFW. Cette configuration est une configuration modèle pour deux zones, telle que configurée sur un routeur 1811. La zone privée est appliquée aux ports du commutateur fixe du routeur, ainsi tous les serveurs sur les ports de commutation sont connectés au VLAN 1. La zone publique est appliquée sur FastEthernet 0 (voir l’image 12).

Image 12 : Zone publique appliquée sur FastEthernet 0

Zone publique appliquée sur FastEthernet 0

class-map type inspect match-any private-allowed-class
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-all http-class
 match protocol http
!
policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect my-parameters
 class type inspect private-allowed-class
  inspect
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect private-allowed-policy
!
interface fastethernet 0
 zone-member security public
!
interface VLAN 1
 zone-member security private

Informations connexes

• Assistance et documentation techniques - Cisco Systems