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 aux règles de classe de trafic d’une politique de service pour pour une interface donnée selon les règles suivantes :

1. Un paquet ne peut correspondre qu’à une seule règle de classe de trafic pour chaque type de fonctionnalité.

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

3. Si le paquet correspond à une règle de trafic ultérieure pour un type de fonctionnalité différent, l’ASA applique également les actions pour la règle 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 d’une politique de service sont exécutés est indépendant de l’ordre dans lequel ils apparaissent dans le tableau de la politique.

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 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

La classe de trafic d’inspection par défaut, 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, ce qui vous donne ainsi la possibilité d’appliquer des inspections à des ports non standard, par exemple.

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 liste des 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; il correspond au trafic d’inspection par défaut. Cette carte, 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 carte 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.

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.