Les politiques de service permettent d’appliquer des services avancés au trafic que vous autorisez. Tout trafic autorisé par les règles d’accès peut faire l’objet de politiques de service et donc recevoir un traitement spécial, comme être redirigé vers un module de service ou faire l’objet d’une inspection d’application.

Vous pouvez avoir les types de politiques de service suivants :

• Une politique globale qui s’applique à toutes les interfaces.

• Une politique de service appliquée par interface. La politique peut être un ensemble de cartes pour le trafic passant par le périphérique et le trafic de gestion dirigé vers l’interface de l’ASA plutôt que de passer par elle.

Chaque politique de service est composée des éléments suivants :

1. La liste des politiques de service, qui est l’ensemble ordonné de règles, et est nommée dans la commande service-policy. Dans ASDM, la liste des politiques est représentée sous forme de dossier sur la page des règles de politique de service.

2. Des règles, chaque règle étant une commande class dans la liste des politiques de service et les commandes associées à la commande class. Dans ASDM, chaque règle est affichée sur une ligne distincte, et le nom de la règle est le nom de la carte.

   La commande class définit les critères de correspondance de trafic pour la règle.

   Les commandes associées à la carte, telles que inspect, set connection timeout, etc., définissent les services et les contraintes à appliquer au trafic correspondant. Notez que les commandes d’inspection peuvent pointer vers des listes des politiques d’inspection, qui définissent les actions à appliquer au trafic inspecté. Gardez à l’esprit que les listes des politiques d’inspection ne sont pas la même chose que les listes des politiques de service.

L’exemple suivant compare la façon dont les politiques de service s’affichent dans l’interface de ligne de commande avec la façon dont elles s’affichent dans ASDM. Notez qu’il n’y a pas de mappage un à un entre les appels de figure et les lignes dans l’interface de ligne de commande.

L’interface de ligne de commande suivante est générée par les règles affichées dans la figure ci-dessus.

: Access lists used in class maps.
: In ASDM, these map to call-out 3, from the Match to the Time fields.
access-list inside_mpc line 1 extended permit tcp 10.100.10.0 255.255.255.0 any eq sip
access-list inside_mpc_1 line 1 extended deny udp host 10.1.1.15 any eq snmp
access-list inside_mpc_1 line 2 extended permit udp 10.1.1.0 255.255.255.0 any eq snmp
access-list inside_mpc_2 line 1 extended permit icmp any any
: SNMP map for SNMP inspection. Denies all but v3.
: In ASDM, this maps to call-out 4, rule actions, for the class-inside policy.
snmp-map snmp-v3only
  deny version 1
  deny version 2
  deny version 2c
: Inspection policy map to define SIP behavior.
: The sip-high inspection policy map must be referred to by an inspect sip command
: in the service policy map.
: In ASDM, this maps to call-out 4, rule actions, for the sip-class-inside policy.
policy-map type inspect sip sip-high
  parameters
    rtp-conformance enforce-payloadtype
    no traffic-non-sip
    software-version action mask log
    uri-non-sip action mask log
    state-checking action drop-connection log
    max-forwards-validation action drop log
    strict-header-validation action drop log
: Class map to define traffic matching for the inside-class rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map inside-class
  match access-list inside_mpc_1
: Class map to define traffic matching for the sip-class-inside rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map sip-class-inside
  match access-list inside_mpc
: Class map to define traffic matching for the inside-class1 rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map inside-class1
  match access-list inside_mpc_2
: Policy map that actually defines the service policy rule set named test-inside-policy.
: In ASDM, this corresponds to the folder at call-out 1.
policy-map test-inside-policy
: First rule in test-inside-policy, named sip-class-inside. Inspects SIP traffic.
: The sip-class-inside rule applies the sip-high inspection policy map to SIP inspection.
: In ASDM, each rule corresponds to call-out 2.
  class sip-class-inside
    inspect sip sip-high
: Second rule, inside-class. Applies SNMP inspection using an SNMP map.
  class inside-class
    inspect snmp snmp-v3only
: Third rule, inside-class1. Applies ICMP inspection.
  class inside-class1
    inspect icmp
: Fourth rule, class-default. Applies connection settings and enables user statistics.
  class class-default
    set connection timeout embryonic 0:00:30 half-closed 0:10:00 idle 1:00:00
reset dcd 0:15:00 5
    user-statistics accounting
: The service-policy command applies the policy map rule set to the inside interface.
: This command activates the policies.
service-policy test-inside-policy interface inside

Le tableau suivant répertorie les fonctionnalités que vous configurez à l’aide des politiques de service.

Les actions sont appliquées au trafic de manière bidirectionnelle ou unidirectionnelle, selon la fonctionnalité. Pour les fonctionnalités appliquées de manière bidirectionnelle, tout le trafic qui entre ou sort de l’interface à laquelle vous appliquez la liste des politiques est affecté si le trafic correspond à la carte de trafic dans les deux sens.

Remarque

Lorsque vous utilisez une politique globale, toutes les fonctionnalités sont unidirectionnelles ; les fonctionnalités qui sont normalement bidirectionnelles lorsqu’elles sont appliquées à une seule interface ne s’appliquent qu’au trafic entrant de chaque interface lorsqu’elles sont appliquées globalement. Comme la politique est appliquée à toutes les interfaces, la politique sera appliquée dans les deux sens, de sorte que la bidirectionnalité dans ce cas est redondante.

Pour les fonctionnalités appliquées de manière unidirectionnelle, par exemple la file d’attente de priorité QoS, seul le trafic qui entre (ou quitte, selon la fonctionnalité) l’interface à laquelle vous appliquez la liste des politiques est affecté. Consultez le tableau suivant pour connaître le sens d’application de chaque fonctionnalité.

Un paquet correspond de mappage de classe dans une mise en correspondance de politiques pour une interface donnée selon les règles suivantes :

1. Un paquet ne peut correspondre qu’à une seule carte de classe dans la et chaque type de fonctionnalité.

2. Lorsque le paquet correspond à une de carte de trafic pour un type de fonctionnalité, l’ASA ne tente pas de le mettre en correspondance avec les de cartes de trafic ultérieures pour ce type de fonctionnalité.

3. Si le paquet correspond à une de carte de trafic ultérieure pour un type de fonctionnalité différent, l’ASA applique également les actions pour la de carte de trafic ultérieure, si elle est prise en charge. Consultez Incompatibilité de certaines actions de fonctionnalité pour obtenir plus d’informations sur les combinaisons non prises en charge.

   Remarque

   L’inspection d’application comprend plusieurs types d’inspection, et la plupart s’excluent mutuellement. Pour les inspections qui peuvent être combinées, chaque inspection est considérée comme une fonctionnalité distincte.

L’ordre dans lequel les différents types d’actions dans une politique de service de sont effectués est indépendant de l’ordre dans lequel les actions apparaissent dans le de la liste des politiques.

Les actions sont effectuées dans l’ordre suivant :

1. régulation d’entrée QoS

2. Normalisation TCP, limites et délais d’expiration de connexion TCP et UDP, randomisation du numéro de séquence TCP et contournement de l’état TCP.

   Remarque

   Lorsque l’ASA effectue un service de proxy (comme AAA) ou qu’il modifie la charge utile TCP (comme l’inspection FTP), le normaliseur TCP agit en mode double, où il est appliqué avant et après le service de modification du proxy ou de la charge utile.

3. Inspections d’application qui peuvent être combinées avec d’autres inspections :

   1. IPv6

   2. Options d’adresse IP

   3. WAAS

4. Inspections d’application qui ne peuvent pas être combinées avec d’autres inspections. Consultez Incompatibilité de certaines actions de fonctionnalité pour de plus amples renseignements.

5. Régulation de sortie QoS

6. File d’attente prioritaire standard QoS

Remarque

Le filtrage de la journalisation des événements sécurisés NetFlow et les statistiques d’utilisateur pour le pare-feu d’identité sont indépendants de l’ordre.

Certaines fonctionnalités ne sont pas compatibles entre elles pour le même trafic. La liste suivante peut ne pas inclure toutes les incompatibilités ; pour en savoir plus sur la compatibilité de chaque fonctionnalité, consultez le chapitre ou la section correspondant à la fonctionnalité :

• Vous ne pouvez pas configurer la mise en file d’attente prioritaire QoS et la régulation QoS pour le même ensemble de trafic.

• La plupart des inspections ne doivent pas être combinées avec une autre inspection, donc l’ASA n’applique qu’une seule inspection si vous configurez plusieurs inspections pour le même trafic. Les exceptions sont répertoriées dans Ordre dans lequel plusieurs actions de fonctionnalité sont appliquées.

Remarque

Lacommande match default-inspection-traffic, qui est utilisée dans la politique globale par défaut, est un raccourci d’interface de ligne de commande spécial pour faire correspondre les ports par défaut pour toutes les inspections. Lorsqu’elle est utilisée dans une liste des politiques, cette carte de trafic garantit que l’inspection correcte est appliquée à chaque paquet, en fonction du port de destination du trafic. Par exemple, lorsque le trafic UDP pour le port 69 atteint l’ASA, l’ASA applique l’inspection TFTP; lorsque le trafic TCP pour le port 21 arrive, l’ASA applique l’inspection FTP. Ainsi, dans ce cas uniquement, vous pouvez configurer plusieurs inspections pour la même carte de trafic. Normalement, l'ASA n'utilise pas le numéro de port pour déterminer quelle inspection appliquer, vous donnant ainsi la flexibilité d'appliquer des inspections à des ports non standard, par exemple.

Un exemple d’erreur de configuration est si vous configurez plusieurs inspections dans la même liste des politiques et n’utilisez pas le raccourci default-inspection-traffic. Dans le premier exemple, le trafic destiné au port 21 est configuré par erreur pour l’inspection FTP et HTTP. Dans le deuxième exemple, le trafic destiné au port 80 est configuré par erreur pour l’inspection FTP et HTTP. Dans les deux cas d’exemples de configuration incorrecte, seule l’inspection FTP est appliquée, car FTP précède HTTP dans l’ordre des inspections appliquées.

class-map ftp
   match port tcp eq 21
class-map http
   match port tcp eq 21 [it should be 80]
policy-map test
   class ftp
     inspect ftp
   class http
     inspect http

class-map ftp
   match port tcp eq 80 [it should be 21]
class-map http
   match port tcp eq 80
policy-map test
   class ftp
     inspect ftp
   class http
     inspect http

Pour le trafic TCP et UDP (et ICMP lorsque vous activez l’inspection ICMP dynamique), les politiques de service fonctionnent sur les flux de trafic, et pas seulement sur les paquets individuels. Si le trafic fait partie d’une connexion existante qui correspond à une fonctionnalité dans une politique sur une interface, ce flux de trafic ne peut pas également correspondre à la même fonctionnalité dans une politique sur une autre interface; seule la première politique est utilisée.

Par exemple, si le trafic HTTP correspond à une politique sur l’interface interne pour inspecter le trafic HTTP, et que vous disposez d’une politique distincte sur l’interface externe pour l’inspection HTTP, ce trafic n’est pas également inspecté à la sortie de l’interface externe. De même, le trafic de retour pour cette connexion ne sera pas inspecté par la politique d’entrée de l’interface externe ni par la politique de sortie de l’interface interne.

Pour le trafic qui n’est pas traité comme un flux, par exemple ICMP lorsque vous n’activez pas l’inspection ICMP avec état, le trafic de retour peut correspondre à une carte de politiques différente sur l’interface de retour.

Par défaut, la configuration comprend une politique qui correspond à tout le trafic d’inspection d’application par défaut et applique certaines inspections au trafic sur toutes les interfaces (politique globale). Toutes les inspections ne sont pas activées par défaut. Vous ne pouvez appliquer qu’une seule politique globale, donc si vous souhaitez modifier la politique globale, vous devez soit modifier la politique par défaut, soit la désactiver et en appliquer une nouvelle. (Une politique d’interface remplace la politique globale pour une fonctionnalité particulière.)

La politique par défaut inclut les inspections d'application suivantes :

• DNS

• FTP

• H323 (H225)

• H323 (RAS)

• RSH

• RTSP

• ESMTP

• SQLnet

• Skinny (SCCP)

• SunRPC

• SIP

• NetBios

• TFTP

• Options d’adresse IP

La configuration comprend une carte de trafic de couche 3/4 par défaut (classe de trafic) que l’ASA utilise dans la politique globale par défaut appelée default-inspection-traffic ; elle correspond au trafic d’inspection par défaut. Cette classe, qui est utilisée dans la politique globale par défaut, est un raccourci spécial pour faire correspondre les ports par défaut pour toutes les inspections.

Lorsqu’elle est utilisée dans une politique, cette classe garantit que l’inspection correcte est appliquée à chaque paquet, en fonction du port de destination du trafic. Par exemple, lorsque le trafic UDP pour le port 69 atteint l’ASA, l’ASA applique l’inspection TFTP; lorsque le trafic TCP pour le port 21 arrive, l’ASA applique l’inspection FTP. Ainsi, dans ce cas uniquement, vous pouvez configurer plusieurs inspections pour la même carte de trafic. Normalement, l’ASA n’utilise pas le numéro de port pour déterminer quelle inspection appliquer, ce qui vous donne ainsi la possibilité d’appliquer des inspections à des ports non standard, par exemple.

class-map inspection_default
 match default-inspection-traffic

Une autre carte de trafic qui existe dans la configuration par défaut est appelée class-default, et elle correspond à tout le trafic. Cette carte de trafic apparaît à la fin de toutes les listes des politiques de couche 3/4 et indique essentiellement à l’ASA de n’effectuer aucune action sur tout autre trafic. Si vous utilisez la classe par défaut (la classe Tout trafic dans ASDM), utilisez-la à des fins plus larges comme l’activation de l’aléatoire des séquences TCP, du décrément des TTL ou toute autre modification d’attribut facultatif. Ne l’utilisez pas pour l’inspection, car cela pourrait perturber le trafic. Certaines fonctionnalités sont uniquement disponibles pour class-default.

class-map class-default
 match any

Dans cet exemple, toute connexion HTTP (trafic TCP sur le port 80) qui entre dans l’ASA ou en sort par l’interface externe est classée pour l’inspection HTTP. Tout trafic HTTP qui quitte l’interface externe est classé pour le contrôle.

Consultez les commandes suivantes pour cet exemple :

hostname(config)# class-map http_traffic
hostname(config-cmap)# match port tcp eq 80

hostname(config)# policy-map http_traffic_policy
hostname(config-pmap)# class http_traffic
hostname(config-pmap-c)# inspect http
hostname(config-pmap-c)# police output 250000
hostname(config)# service-policy http_traffic_policy interface outside

Dans cet exemple, toute connexion HTTP (trafic TCP sur le port 80) qui entre dans l’ASA par l’intermédiaire d’une interface est classée pour l’inspection HTTP. Comme la politique est une politique globale, l’inspection se produit uniquement lorsque le trafic entre dans chaque interface.

Consultez les commandes suivantes pour cet exemple :

hostname(config)# class-map http_traffic
hostname(config-cmap)# match port tcp eq 80

hostname(config)# policy-map http_traffic_policy
hostname(config-pmap)# class http_traffic
hostname(config-pmap-c)# inspect http
hostname(config)# service-policy http_traffic_policy global

Dans cet exemple, toute connexion HTTP destinée au serveur A (trafic TCP sur le port 80) qui entre dans l’ASA par l’intermédiaire de l’interface externe est classée pour l’inspection HTTP et les limites de connexion maximales. Les connexions initiées du serveur A à l’hôte A ne correspondent pas à l’ACL dans la carte de trafic, elles ne sont donc pas affectées.

Toute connexion HTTP destinée au serveur B qui entre dans l’ASA par l’intermédiaire de l’interface interne est classée pour l’inspection HTTP. Les connexions initiées du serveur B à l’hôte B ne correspondent pas à l’ACL dans la carte de trafic, elles ne sont donc pas affectées.

Consultez les commandes suivantes pour cet exemple :

hostname(config)# object network obj-192.168.1.2
hostname(config-network-object)# host 192.168.1.2
hostname(config-network-object)# nat (inside,outside) static 209.165.201.1 
hostname(config)# object network obj-192.168.1.0
hostname(config-network-object)# subnet 192.168.1.0 255.255.255.0
hostname(config-network-object)# nat (inside,outside) dynamic 209.165.201.2
hostname(config)# access-list serverA extended permit tcp any host 209.165.201.1 eq 80
hostname(config)# access-list ServerB extended permit tcp any host 209.165.200.227 eq 80

hostname(config)# class-map http_serverA
hostname(config-cmap)# match access-list serverA
hostname(config)# class-map http_serverB
hostname(config-cmap)# match access-list serverB

hostname(config)# policy-map policy_serverA
hostname(config-pmap)# class http_serverA
hostname(config-pmap-c)# inspect http
hostname(config-pmap-c)# set connection conn-max 100
hostname(config)# policy-map policy_serverB
hostname(config-pmap)# class http_serverB
hostname(config-pmap-c)# inspect http

hostname(config)# service-policy policy_serverB interface inside
hostname(config)# service-policy policy_serverA interface outside

Dans cet exemple, l’hôte du réseau interne a deux adresses : l’une est l’adresse IP réelle 192.168.1.1, et l’autre est une adresse IP mappée utilisée sur le réseau externe, 209.165.200.225. Vous devez utiliser l’adresse IP réelle dans la liste de contrôle d’accès dans la carte de trafic. Si vous l’appliquiez à l’interface externe, vous utiliseriez également l’adresse réelle.

Consultez les commandes suivantes pour cet exemple :

hostname(config)# object network obj-192.168.1.1
hostname(config-network-object)# host 192.168.1.1
hostname(config-network-object)# nat (VM1,outside) static 209.165.200.225

hostname(config)# access-list http_client extended permit tcp host 192.168.1.1 any eq 80

hostname(config)# class-map http_client
hostname(config-cmap)# match access-list http_client

hostname(config)# policy-map http_client
hostname(config-pmap)# class http_client
hostname(config-pmap-c)# inspect http

hostname(config)# service-policy http_client interface inside