CBAC - Configuration ccnp_cch ccnp_cch

Sommaire • Introduction • Présentation de CBAC - Ce que fait CBAC? - Ce que ne fait pas CBAC? - Comment CBAC fonctionne-t-il? - Où et quand configurer CBAC? - Le processus CBAC - Protocoles supportés - Restrictions - Impact mémoire et performance • Configuration de CBAC - Choix d'une interface: Interne ou Externe - Configurer les listes d'accès sur l'interface - Configurer le timeout et les seuils globaux - Définir une règle d'inspection - Appliquer la règle d'inspection à une interface - Afficher la configuration, les états et les statistiques pour CBAC. • Debug et CBAC - Commandes Debug Génériques - Commandes Debug niveau Transport - Commandes Debug niveau protocole Application • Intercepter les messages Syslog et Console générés par CBAC - Messages d'erreur de détection d'attaque de type "Déni de Service" - Messages d'erreur de détection d'attaque SMTP - Messages d'erreur blocage Java - Messages d'erreur FTP - Messages d'erreur Audit-Trail • Dévalider CBAC • Exemple de configuration de CBAC ccnp_cch

Introduction ccnp_cch Ce document décrit comment configurer CBAC (Context-Based access Control). CBAC fournit une fonctionnalité avancée de filtrage de trafic et peut être utilisé comme partie intégrante de votre pare-feu de réseau. Présentation générale de CBAC Cette section décrit: • Que fait CBAC? • Que ne fait pas CBAC? • Comment CBAC fonctionne-t-il? • Où et quand configurer CBAC? • Le processus CBAC • Protocoles supportés • Restrictions • Impact mémoire et performance Ce que fait CBAC CBAC filtre intelligemment les paquets TCP et UDP sur la base des informations de ses- sion de protocole de couche application et peut être utilisé pour des Intranet, Extranet ou Internet. Vous pouvez configurer CBAC pour permettre du trafic TCP et UDP spéci- fique à travers un pare-feu uniquement lorsque la connexion est initiée depuis le réseau que vous voulez protéger. En d'autres termes, CABC peut inspecter le trafic des sessi- ons qui sont issues du réseau externe, CBAC peut également inspecter le trafic des ses- sions qui sont issues de différentes sources. Sans CABC, le filtrage de trafic est limité à l'implémentation de listes d'accès qui exami nent les paquets au niveau de la couche réseau ou de la couche transport. CBAC n'exa- mine pas uniquement les informations des couches réseau et transport mais examine également les informations de protocole de couche application (telle l'information de connexion FTP) pour connaître l'état de la session TCP ou UDP. Ceci permet le support de protocoles qui comprennent plusieurs canaux crées après négociation par un canal de contrôle. La majorité des protocoles multimédia ainsi que d'autres protocoles (FTP, RPC, SQL*Net) utilisent de multiples canaux. CBAC inspecte le trafic qui traverse le pare-feu pour obtenir et gérer des informations d'état pour les sessions UDP et TCP. Cette information d'état est utilisée pour créer des ouvertures temporaires dans les listes d'accès du pare-feu pour autoriser le trafic de re- tour et des connexions de données additionnelles pour les sessions permises (sessions qui sont issues du réseau interne). CBAC a également les avantages suivants: • Blocage de Java • Détecter et empêcher le déni de service (Denial of Service) • Alertes temps réel et messages d'audit ccnp_cch

1. User1 initie une session Telnet Ce que ne fait pas CBAC? CBAC ne fournit pas de filtrage de trafic intelligent pour tous les protocole; il fonctionne uniquement pour les protocoles que vous spécifiez. Si vous ne spécifiez pas un protocole dans CBAC, la liste d'accès détermine comment ce protocole est filtré. Aucune ouverture temporaire du pare-feu ne sera faite pour les protocoles non-spécifiés pour l'inspection CBAC. CBAC ne protège pas contre les attaques issues du réseau interne protégé. CBAC détec- te et protège uniquement contre les attaques qui essaient de traverser le pare-feu. CBAC protège contre certaines attaques mais ne doit pas être considéré comme une dé- fense parfaite et impénétrable. Très déterminés, des attaquants très outillés peuvent lancer des attaques efficaces. Il n'existe pas de défense parfaite mais CBAC protège con- tre les attaques les plus communes. Comment fonctionne CBAC? Il est nécessaire de bien comprendre le fonctionnement de CBAC sinon vous risquez d'introduire des risques de sécurité en configurant CBAC de manière inappropriée. Généralités CBAC crée des ouvertures temporaires dans les listes d'accès affectées aux interfaces du pare-feu. Ces ouvertures sont crées quand du trafic spécifique sort de votre réseau interne au travers du pare-feu. Ces ouvertures permettent le trafic en retour ( qui serait normalement bloqué) et des canaux de données additionnels à entrer dans votre réseau interne au travers du pare-feu. Ce trafic en retour est autorisé à passer à travers le pa- re-feu uniquement s'il fait partie de la même session que le trafic original qui à traversé le pare-feu en sortie. Dans la figure suivante, les listes d'accès en entrée sur S0 et S1 sont configurées pour bloquer le trafic Telnet et il n'y a pas de liste d'accès configurée en sortie sur E0. Quand la requête de connexion pour la session Telnet de USER1 passe dans le pare-feu, CBAC crée une ouverture temporaire dans la liste d'accès sur S0 pour permettre le trafic re- tour de la session Telnet de USER1. (Si la même liste d'accès est appliquée à S0 et S1, la même ouverture apparaît sur les deux interfaces). Si cela était nécessaire, CBAC au- rait également crée une ouverture similaire dans la liste d'accès en sortie sur E0 pour permettre le trafic retour. 1. User1 initie une session Telnet User1 1. Le trafic retour de la session Telnet de User est autorisé 3. D'autres trafics Telnet sont bloqués S0 E0 S1 ccnp_cch

Détails Cette section décrit comment CBAC inspecte les paquets et maintient les informations d'état au sujet des sessions pour fournir un flitrage intelligent. Les paquets sont inspectés Avec CBAC, vous spécifiez quels sont les protocoles qui doivent être inspectés, l'inter- face et le sens (in ou out) sur laquelle l'inspection est faite. Seuls les protocoles spéci- fiés seront inspectés par CABC. Pour ces protocoles, les paquets passant par le pare- feu quelque soit le sens seront inspectés chaque fois qu'ils passeront par l'interface sur laquelle l'inspection est configurée. Les paquets entrant dans le pare-feu seront inspectés uniquement s'ils passent avec succès la liste d'accès en entrée sur l'interface. Si le paquet est refusé par la liste d'ac- cès, il sera simplement éliminé et ne sera pas inspecté par CBAC. CBAC inspecte et surveille uniquement les canaux de commande pour les connexions, les canaux de données ne sont pas inspectés. Par exemple, pendant les sessions FTP, le canal de contrôle et de données (ils sont crées lors d'un transfert de fichier) sont su- pervisés pour les changements d'état mais seul le canal de commande est inspecté (le logiciel CBAC vérifie les commandes et les réponses FTP). L'inspection CBAC reconnaît les commandes spécifiques à l'application dans le canal de commande et ainsi détecte et évite certaines attaques au niveau applicatif. Une table d'états garde les informations d'états des sessions Chaque fois qu'un paquet est inspecté, une table d'état est mise à jour pour inclure l'information au sujet de l'état de la connexion du paquet. Le trafic en retour sera per- mis au travers du pare-feu uniquement si la table d'états contient l'information indi- quant que le paquet appartient bien à une session autorisée. L'inspection contrôle le trafic qui appartient à une session valide et achemine le trafic qu'il ne connaît pas. Quand le trafic retour est inspecté, les informations de la table d'états sont mises à jour si nécessaire. Les sessions UDP sont évaluées Avec UDP (service en mode non-connecté) il n'y a pas de session établie aussi le logiciel évalue les sessions en examinant les informations dans le paquet, détermine si le pa- quet est similaire à d'autres paquets UDP (exemple les adresses source/destination et numéros de ports) et si celui-ci a été détecté dans la période de validité (idle timeout) après un autre paquet UDP similaire. La période de validité est configurable avec un timer appelé "idle-timeout". Des entrées de listes d'accès sont créées dynamiquement CBAC crée et efface dynamiquement des entrées de listes d'accès sur les interfaces du pare-feu d'après les informations gardées dans les tables d'états. Ces entrées de liste d'accès sont appliquées aux interfaces pour examiner le trafic revenant vers le réseau interne. Ces entrées créent des ouvertures temporaires dans le pare-feu pour permet- tre uniquement le trafic qui fait partie d'une session autorisée. ccnp_cch

Où et quand configurer CBAC Où et quand configurer CBAC? Configurer CBAC sur des pare-feu protégeant les réseaux internes. De tels pare-feu peuvent être des routeurs Cisco avec la fonctionnalité pare-feu configurée. Utilisez CBAC quand le pare-feu doit laisser passer du trafic tel: • Applications standard TCP et UDP • Applications Multimédia • Support Oracle Utilisez CBAC pour ces applications si vous voulez que le trafic des applications soit permis au travers du pare-feu uniquement lorsque la session de trafic est initiée à par- tir d'un côté particulier du pare-feu (usuellement à partir du réseau interne protégé). Dans plusieurs cas, vous configurerez CBAC uniquement dans une seule direction sur une seule interface ce qui entraine que le trafic sera permis en retour vers le réseau in- terne uniquement si le trafic fait partie d'une session valide autorisée. Dans de rares cas, vous aurez à configurer CBAC dans les deux sens sur une ou plu- sieurs interfaces ce qui est une solution plus complexe. CBAC est usuellement confi- guré dans les deux sens lorsque les deux réseaux situés de chaque côté du pare-feu doivent être protégés comme par exemple pour des configurations Intranet et Extranet. Par exemple si le pare-feu est situé entre deux réseaux de sociétés partenaires, vous aurez peut-être besoin de restreindre le trafic dans un sens pour certaines applications et restreindre le trafic dans l'autre sens pour d'autres applications. Le processus CBAC Cette section décrit un exemple de séquence d'évènements qui se produisent quand CBAC est configuré sur une interface externe pour se connecter à un réseau externe tel Internet. Dans cet exemple, un paquet TCP sort du réseau interne au travers du pare-feu par l'interface externe. Le paquet TCP est le premier paquet de la session Telnet et Telnet est configuré pour l'inspection CBAC. 1. Le paquet atteint l'interface externe du pare-feu. 2. Le paquet est évalué par la liste d'accès en sortie de l'interface et le paquet est auto- risé. (Un paquet refusé est simplement éliminé). 3. Le paquet est inspecté par CBAC pour déterminer et enregistrer l'information au su- jet de la connexion pour le paquet. Cette information est enregistrée dans une nou- velle entrée de la table d'état créee pour la nouvelle connexion. (Si le paquet de l'application Telnet n'était pas configuré pour l'inspection CBAC, le paquet aurait simplement été acheminé en sortie sur l'interface sans être inspecté par CBAC. 4. Sur la base de l'information d'état, CBAC crée une entrée de liste d'accès temporaire qui est insérée en début de la liste d'accès en entrée de l'interface externe. Cette en- ccnp_cch

trée temporaire de la liste d'accès est conçue pour permettre les paquets entrants qui font partie de la même connexion que le paquet sortant qui vient d'être inspecté. 5. Le paquet est acheminé sur l'interface de sortie. 6. Peu de temps après, un paquet arrive sur l'interface en entrée. Ce paquet fait partie de la même connexion Telnet que celle établie précédemment avec un paquet en sor- tie. Le paquet entrant est évalué par la liste d'accès en entrée et il est autorisé par l'entrée temporaire crée précédemment. 7. Le paquet permis en entrée est inspecté par CBAC et l'entrée de la table d'état est mise à jour si nécessaire. Sur la base des informations d'état mises à jour, les en- trées temporaires de la liste d'accès peuvent être modifiées pour permettre unique- ment les paquets qui sont valides pour l'état courant de cette connexion. 8. Tout paquet supplémentaire entrant ou sortant et appartenant à cette connexion sera inspecté pour mettre à jour l'entrée de la table d'état et pour modifier l'entrée temporaire de la liste d'accès en entrée si nécessaire et sera acheminé sur l'interface. 9. Quand la connexion est libérée normalement ou sur timeout, l'entrée de la table d'état pour cette connexion est effacée et l'entrée temporaire de la liste d'accès en entrée est effacée. Dans l'exemple ci-dessus, les listes d'accès du pare-feu sont configurées comme suit: • Une liste d'accès IP en sortie (standard ou étendue) est appliquée à l'interface externe. Cette liste d'accès permet tous les paquets que vous voulez autoriser à sortir du ré- seau y compris les paquets que vous voulez faire inspecter par CBAC. Dans ce cas les paquets Telnet sont permis. • Une liste d'accès IP étendue en entrée est appliquée à l'interface externe. Cette liste d'accès refuse tout trafic qui doit être inspecté par CBAC y compris les paquets Telnet. Quand CBAC est déclenché par un paquet sortant, CBAC crée une entrée temporaire dans la liste d'accès en entrée pour permettre uniquement le trafic qui fait partie d'une session existante valide. Si la liste d'accès en entrée avait été configurée pour permettre tout trafic, CBAC au- rait crée des ouvertures sans intérêt pour un trafic qui aurait déjà été autorisé. Protocoles supportés Vous pouvez configurer CBAC pour inspecter les types de sessions suivants: • Toutes les sessions TCP sans tenir compte du protocole de couche application ( appelée quelques fois inspection TCP "single channel" ou générique ("generic"). • Toutes les sessions UDP sans tenir compte du protocole de couche application ( appelée quelques fois inspection UDP "single channel" ou générique ("generic"). Vous pouvez également configurer CBAC pour qu'il inspecte certains protocoles de cou- che application. Les protocoles de couche application suivants peuvent être configurés pour CBAC. • CU-See-Me (Uniquement la version white Pine) ccnp_cch

• CU-See-Me (Uniquement la version white Pine) • FTP • H323 (NetMeeting ProShare) • Java • Commandes UNIX "r" (rlogin, rexec, rsh...) • RealAudio • RPC (Sun RPC, pas les RPC DCE ou Microsoft) • SMTP • SQL*net • StreamWorks • TFTP • VDoLive Quand un protocole est configuré dans CBAC, le trafic du protocole est inspecté, l'in- formation d'état est maintenue et les paquets en retour seront autorisés à traverser le pare-feu uniquement s'ils font partie d'une session autorisée. Restrictions CBAC est utilisable uniquement pour le trafic IP. Seuls les paquets UDP et TCP sont inspectés. (D'autre trafic IP, tel ICMP ne peut pas être filtré avec CBAC et doit être fil- tré avec des listes d'accès). Vous pouvez utiliser CBAC avec d'autres fonctionnalités de pare-feu mentionnées pré- cédemment. CBAC fonctionne avec "Fast Switching" et "Process Switching". Si vous reconfigurez vos listes d'accès quand vous configurez CBAC, sachez que si vo- tre liste d'accès bloque le trafic TFTP sur une interface, vous ne pourrez pas faire un "Boot" réseau par cette interface. (Ceci n'est pas une limitation propre à CBAC mais une part de la fonctionnalité des listes d'accès). Les paquets avec le pare-feu comme adresse source ou destination ne sont pas inspec- tés par CBAC ou évalués par les listes d'accès. CBAC ignore les messages ICMP "Destination inaccessible". Trafic FTP et CBAC Pour FTP, CBAC n'autorise pas les connexions en trois étapes. Quand CBAC inspecte le trafic FTP, il autorise les canaux de données uniquement avec le numéro de port dans l'intervalle 1024 à 65535. CBAC n'ouvrira pas de canal de données si l'authentification client-serveur échoue. Technologie de cryptage Cisco et compatibilité CBAC Si du trafic crypté est échangé entre deux routeurs et que le pare-feu est entre ces deux routeurs, CBAC ne fonctionne pas. Ceci est du au fait que la charge utile des paquets est cryptée et par conséquent CBAC ne peut pas inspecter le trafic. Si le cryptage et CBAC sont configurés sur le même pare-feu, CBAC ne fonctionnera ccnp_cch

pas pour certains protocoles pas pour certains protocoles. Dans ce cas CBAC fonctionne avec TCP et UDP en canal unique sauf pour Java et SMTP. CBAC ne fonctionnera pas pour les protocoles multi- canaux sauf pour StreamWorks et CU-See-Me. Si vous configurez le cryptage sur le pare-feu, vous devez configurer CBAC unique- ment pour les protocoles suivants: • TCP générique • UDP générique • CU-See-Me • StreamWorks IPSEC et compatibilité CBAC Quand CBAC et IPSec sont validés sur le même routeur et que le routeur cible est une extrémité pour IPSec pour ce flux particulier alors IPSEC est compatible avec CBAC (CBAC peut exécuter l'inspection normale sur le flux). Si le routeur n'est pas une extrémité IPSec mais le paquet est un paquet IPSec alors CBAC n'inspectera pas les paquets car le numéro de protocole dans l'en-tête n'est ni TCP ni UDP. CBAC inspecte uniquement les paquets TCP et UDP. Impact mémoire et performance CBAC utilise un peu moins de 600 octets de mémoire par connexion. A cause de cette utilisation de la mémoire vous devez utiliser CBAC uniquement si cela est nécessaire. Il y a également un léger traitement additionnel chaque fois qu'un paquet est inspecté par CBAC. Quelquefois CBAC doit évaluer de longues listes d'accès ce qui entraine un effet néga- tif sur les performances. Toutefois cet effet négatif est limité car CBAC utilise une mé- thode rapide pour évaluer les listes d'accès (CBAC hache les listes d'accès et évalue le hachage). ccnp_cch

Configuration de CBAC Pour configurer CBAC, réaliser les tâches décrites dans les sections suivantes: • Choix d'une interface: Interne ou Externe • Configurer la liste d'accès IP sur l'interface • Configurer le time-out global et les seuils • Définir une règle d'inspection • Appliquer la règle d'inspection à l'interface Vous pouvez également exécuter les tâches décrites dans les sections suivantes. Ces tâches sont optionnelles. • Afficher la configuration, les états et les statistiques pour CBAC • Utiliser la commande debug pour CBAC • Interpréter les messages Syslog et Console générés par CBAC • Arrêter CBAC Note : Si vous essayez de configurer CBAC mais si vous n'avez pas une bonne compré- hension de CBAC, vous pouvez par inadvertance introduire des failles de sécurité sur le pare-feu et sur le réseau protégé. Vous devez être sur de ce que fait CABC avant de le configurer. Choix d'une Interface : Interne ou Externe Vous devez décider si vous configurez CBAC sur une interface interne ou externe de votre pare-feu. "Interne" fait référence au côté à partir duquel les sessions doivent avoir leur origine pour que leur trafic soit autorisé à traverser le pare-feu. "Externe" fait référence au cô- té à partir duquel le sessions ne peuvent pas être initiées (les sessions initiées à partir du côté externe seront bloquées). Si vous configurez CBAC dans les deux directions, vous devez configurer CBAC dans une seule direction d'abord en utilisant les désignations "Interne" et "Externe" appro- priées. Quand vous configurez CBAC dans l'autre direction, les désignations des inter- faces seront interchangées. (CBAC est rarement configuré dans les deux directions. Cela se produit lorsque le pare-feu est situé entre deux réseaux qui ont besoin de se protéger l'un de l'autre tels deux réseaux de sociétés partenaires connectés par un pare-feu). Le pare-feu est plus communément utilisé avec une des deux topologies de base. En déterminant laquelle de ces topologies est la plus proche de la votre, cela peut vous aider à décider si vous devez configurer CBAC sur une interface interne ou exter- ne. La première topologie est illustrée par la figure qui suit. Dans cette topologie simple CBAC est configuré pour l'interface externe Serial1. Ceci empêche le trafic du protocole spécifié d'entrer dans le pare-feu et dans le réseau interne sauf si le trafic fait partie d'une session initiée depuis le réseau interne. ccnp_cch

ccnp_cch Réseau Interne Réseau Externe Internet Trafic sortant Trafic entrant Serial1 La seconde topologie est illustrée par la figure suivante. dans cette topologie, CBAC est configuré pour l'interface interne Ethernet0. ceci autorise le trafic externe à accéder aux services situés dans la DMZ (Demilitarized Zone) tels que les services DNS mais évite que le trafic du protocole spécifié entre dans le réseau interne à moins que ce trafic fasse partie d'une session initiée depuis le réseau interne. Internet Réseau Interne Réseau Externe Trafic sortant Trafic entrant DMZ Serveur Web Serveur DNS Ethernet0 Accès autorisé Utilisez ces deux topologies pour décider si CBAC doit être configuré sur l'interface in- terne ou externe. ccnp_cch

Configurer les listes d'accès IP sur l'interface Pour que CBAC fonctionne correctement, vous devez vous assurer que vous avez une liste d'accès IP configurée correctement sur l'interface. Suivre ces deux règles générales quand vous évaluer vos listes d'accès sur le pare-feu: • Permettre le trafic CBAC quittant le réseau au travers du pare-feu. Toutes les listes d'accès qui évaluent le trafic quittant le réseau protégé doivent per- mettre le trafic qui sera inspecté par CBAC, ensuite le trafic Telnet doit être permis sur toutes les listes d'accès qui s'appliquent au trafic quittant le réseau. • Utilisez les listes d'accès étendues pour interdire le trafic CBAC en retour qui entre dans le réseau au travers du pare-feu. Pour les ouvertures temporaires devant être créées dans une liste d'accès, la liste d'accès doit être une liste d'accès étendue. Ainsi à chaque fois que vous aurez une liste d'accès qui s'applique à du trafic retour ,vous devrez utiliser une liste d'accès étendue. Cette liste d'accès doit interdire le trafic CBAC retour car CBAC va ouvrir des entrées temporaires dans la liste d'accès (Vous voulez que le trafic soit normalement bloqué quand il entre dans votre réseau. Note: Si votre pare-feu a uniquement deux connexions, une vers le réseau interne et une vers le réseau externe, assurez-vous que les listes d'accès en entrée fonctionnent correctement car les paquets seront stoppés avant qu'ils aient une chance d'affecter le routeur. Interface Externe Voici quelques conseils pour vos listes d'accès quand vous allez configurer CBAC sur une interface externe. • Si vous avez une liste d'accès IP en sortie sur l'interface externe, la liste d'accès peut être une liste d'accès standard ou étendue. Cette liste d'accès doit permettre le trafic qui doit être inspecté par CBAC. Si le trafic n'est pas permis, il ne sera pas inspecté par CBAC mais sera simplement rejeté. • La liste d'accès IP en entrée sur l'interface externe doit être une liste d'accès étendue. Cette liste d'accès en entrée doit interdire le trafic qui doit être inspecté par CBAC. ( CBAC créera une entrée temporaire dans cette liste d'accès pour permettre le trafic retour qui fait partie d'une session valide et existante. Interface Interne Voici quelques conseils pour vos listes d'accès quand vous allez configurer CBAC sur une interface interne. • Si vous avez une liste d'accès IP en entrée sur l'interface interne, la liste d'accès peut être une liste d'accès standard ou étendue. Cette liste d'accès doit permettre le trafic qui doit être inspecté par CBAC. Si le trafic n'est pas permis, il ne sera pas inspecté par CBAC mais sera simplement rejeté. • La liste d'accès IP en sortie sur l'interface interne doit être une liste d'accès étendue. Cette liste d'accès en sortie doit interdire le trafic qui doit être inspecté par CBAC. ( CBAC créera une entrée temporaire dans cette liste d'accès pour permettre le trafic retour qui fait partie d'une session valide et existante). ccnp_cch

Vous n'avez pas nécessairement besoin de configurer des listes d'accès étendues sur l'interface interne ou sur l'interface externe, mais au moins une est nécessaire pour restreindre le trafic passant au travers du pare-feu vers le réseau interne protégé. Configuration globale des timeout et des seuils CBAC utilise des "timeout" et des seuils pour déterminer quand éliminer les sessions qui ne passent pas pas à l'état "Etablies". Ces timeout et ces seuils s'appliquent globa- lement à toutes les sessions. Vous pouvez utiliser le timeout et les valeurs de seuils par défaut ou vous pouvez les changer pour qu'elles correspondent mieux à votre politique de sécurité. Vous devez faire les modifications de timeout et de seuils avant de continuer à configurer CBAC. Notez que si vous voulez valider une prévention de déni de service spécifique host plus agressive qui inclut le blocage d'initiation de session pour un host, vous devez fixer le "block-time" spécifié dans la commande ip tcp max-incomplete host. Tous les timeout et les seuils de CBAC sont listés dans le tableau suivant avec le nom de la commande correspondante et la valeur par défaut. Valeur de timeout ou de seuil Commande pour modification Valeur par défaut Durée d'attente pour qu'une session TCP passe à l'état établie avant que celle-ci soit rejetée ip inspect tcp synwait-time seconds 30 secondes Durée pendant laquelle une session TCP est gérée après la détection de FIN. ip inspect tcp finwait-time seconds 5 secondes Durée pendant laquelle une session TCP est gérée après fin d'activité. (TCP idle timeout).1 ip inspect tcp idle-time seconds 3600 secondes (1 heure) Durée pendant laquelle une session UDP est gérée après fin d'activité. (UDP idle timeout).1 ip inspect udp idle-time seconds Durée pendant laquelle une session DNS est gérée après fin d'activité. ip inspect dns timeout seconds Nombre de sessions semi-ouvertes à partir duquel le logiciel élimine ces sessions semi-ouvertes.2 ip inspect max-incomplete high number 500 sessions semi-ouvertes Nombre de sessions semi-ouvertes à partir duquel le logiciel arrête d'éliminer ces sessions semi-ouvertes.2 ip inspect max-incomplete low number 400 sessions semi-ouvertes Taux de nouvelles sessions non établies à partir duquel le logiciel commence à effacer les sessions semi-ouvertes. 2 ip inspect one-minute high number par minute ccnp_cch

Taux de nouvelles sessions non établies à partir duquel le logiciel arrête d'effacer les sessions semi-ouvertes. 2 ip inspect one-minute low number 400 sessions semi-ouvertes par minute Nombre de sessions TCP 3 semi-ouvertes avec la même adresse host destination à partie duquel le logiciel commence à effacer les sessions semi-ouvertes avec la même adresse host destination. ip inspect tcp max-incomplete host number block-time minutes 50 sessions semi-ouvertes 0 minutes 1. Les timeout d'inactivité globaux TCP et UDP peuvent être outrepassés pour des ses- sions de protocoles de couche application spécifiques comme cela est décrit dans la description de la commande ip inspect name. 2. Voir la section "Connexions semi-ouvertes". 3. Chaque fois que le seuil max-incomplete host est dépassé, le logiciel élimine les ses- ions semi-ouvertes différemment si le "block-time" est égal à zéro ou à un nombre po- sitif. Si le "block-time" est égal à zéro, le logiciel efface la session semi-ouverte la plus ancienne pour le host pour chaque nouvelle requête de connexion du host et laisse passer le paquet SYN. Si le timeout "block-time" est supérieur à zéro, le logiciel effa- ce toutes les sessions semi-ouvertes du host et bloque les nouvelles requêtes de con- nexion du host. Le logiciel bloquera toute nouvelle requête de connexion jusqu'à ex- piration du timeout "block-time". Pour revenir à la valeur par défaut d'un timeout ou d'un seuil, utilisez la commande du tableau précédent avec la forme no. Sessions semi-ouvertes Un nombre de sessions semi-ouvertes anormalement élevé (soit absolu ou mesuré en nombre d'arrivées) peut indiquer qu'une attaque de type déni de service est en train de se produire. Pour TCP "half-open" ou semi-ouverte signifie que la session n'a pas atteint l'état "établie" - Le dialogue TCP en trois étapes n'a pas réussi. Pour UDP "half-open" ou semi-ouverte signifie que le pare-feu n'a pas détecté de trafic retour. CBAC mesure à la fois le nombre total de sessions semi-ouvertes et la cadence des ten- tatives d'ouvertures de sessions. Un comptage total du nombre de sessions semi-ouver- tes est fait pour TCP et UDP ainsi que la cadence de tentatives d'ouvertures de sessions. Les mesures sont faites toutes les minutes. Quand le nombre total de sessions semi-ouvertes dépasse un seuil (nombre max-incom- plete high), le logiciel efface les sessions semi-ouvertes de manière appropriée pour per- mettre de nouvelles requêtes de connexion. Le logiciel continue d'effacer les sessions semi-ouvertes jusqu'à ce que le nombre de sessions semi-ouvertes passe en dessous d'un seuil (nombre max-incomplete low). ccnp_cch

Quand le rythme des tentatives de nouvelle connexion dépasse un seuil (nombre one- minute high), le logiciel efface les sessions semi-ouvertes de manière appropriée pour permettre de nouvelles tentatives de connexion. Le logiciel continuera d'effacer les ses- sions semi-ouvertes jusqu'à ce que le rythme de tentatives de nouvelle connexion passe en dessous d'un seuil (nombre one-minute low). Les seuils des rythmes sont mesurés en nombre de nouvelles tentatives de connexion détectées dans la dernière minute. (Ce rythme est calculé selon une loi exponentielle). Définir une règle d'inspection Après avoir configuré les timeout globaux et les seuils, vous devez définir une règle d'inspection. Cette règle spécifie quel trafic IP (quels protocoles de couche application) sera inspecté par CBAC sur une interface. Normalement, vous définissez une seule règle d'inspection. La seule exception se pro- duit si vous voulez valider CBAC dans les deux directions. Pour CBAC configuré dans les deux directions sur une seule interface, vous devez configurer deux règles, une dans chaque direction. Une règle d'inspection doit spécifier chaque protocole de couche ap- plication tout comme TCP ou UDP générique selon les besoins. La règle d'inspection est constituée d'une série d'instructions dont chacune indique le protocole et le même nom de règle d'inspection. Pour définir une règle d'inspection, suivez les instructions des sections suivantes: • Configurer l'inspection du protocole de couche application • Configurer l'inspection générique UDP et TCP. Configurer l'inspection du protocole de couche application Note: Si vous voulez que l'inspection CBAC fonctionne avec NetMeeting 2.0 ( protocole de couche application H323), vous devez également configurer l'inspection TCP. Cette obligation est due au fait que NetMeeting 2.0 utilise un canal TCP additionnel non défi- ni dans la spécification H323. Pour configurer l'inspection CBAC pour un protocole de couche application, utilisez une ou les deux commandes suivantes en mode de configuration global. Commande Fonction ip inspect name inspection-name protocol [timeout seconds] Configure l'inspection CBAC pour un protocole de couche application (sauf RPC et Java). Utilisez un des mots-clés définis dans le tableau suivant. Répéter cette commande pour chaque protocole désiré. Utilisez le même inspection-name pour créer une règle d'inspectuon unique. ip inspect name inspection-name rpc program-number number [wait-time minutes] [timeout seconds] Configure l'inspection CBAC pour un protocole de couche application RPC. Vous pouvez spécifier plusieurs numéros de programmes RPC en répétant cette commande pour chaque numéro de programme. ccnp_cch

Pour configurer l'inspection CBAC pour Java, voir la section suivante "Configurer l'ins- pection Java". Le tableau suivant identifie les mots-clés des protocoles de couche appli- cation.. Protocole Application Mot-clé protocol CU-SeeMe cuseeme FTP ftp H.323 h323 UNIX commandes R (rlogin, rexec, rsh) rcmd RealAudio realaudio SMTP smtp SQL*Net sqlnet StreamWorks streamworks TFTP tftp VDOLive vdolive Configurer l'inspection Java Avec Java, vous devez vous protéger contre le risque que des utilisateurs téléchargent des applets destructrices dans votre réseau. Pour se protéger contre ce risque, vous devez exiger que tous les utilisateurs dévalident Java dans leur navigateur. Si cela n'est pas une solution très facile, vous pouvez utiliser CBAC pour filtrer les applets Java sur le pare-feu ce qui permet d'autoriser les utilisateurs à télécharger uniquement les ap- plets résidants dans le pare-feu et les applets certifiés à l'extérieur du pare-feu. Le filtrage des applets Java fait la distinction entre les applets certifiés et celles qui ne le sont pas en se reposant sur une liste de sites externes que vous désignez comme "amicaux". Si une applet est issu d'un site amical, le pare-feu autorise le passage de celle-ci. Si l'applet n'est pas issue d'un site amical, l'applet sera bloquée. (D'une autre façon vous pouvez autoriser tous les sites externes sauf ceux que vous spécifiez comme "hostiles"). Pour bloquer tous les applets Java sauf celles issues de sites de confiance, utilisez les commandes suivantes en mode de configuration global. Etape Commande Fonction 1 ip access-list standard name permit.. deny...(Utilisez permit ou deny selon les besoins) ou access-list access-list-number {deny|permit} source [source-wildcard] Crée une liste d'accès standard qui permet le trafic uniquement des sites amicaux et rejette le trafic des sites hostiles Si vous voulez que tous les utilisateurs internes téléchargent des applets amicales , utilisez le mot-clé any pour la destina-tion de manière appropriée. Attention de ne pas utilisez le mot-clé any pour autori-ser par inadvertance tous les applets. ccnp_cch

2 ip inspect name inspection-name http [java-list access-list] [timeout seconds] Bloque toutes les applets Java sauf les applets des sites amicaux définis dans la liste d'accès. Le blocage de Java fonction-ne uniquement des listes d'accès standard numérotées. Utilisez le même inspect-name que pour les protocoles afin de créer une seule règle d'inspection. Attention: CBAC ne détecte pas et ne bloque pas les applets Java encapsulés. Par con- séquent, les applets Java qui sont encapsulés dans des formats .zip ou .jar ne sont pas bloquées par le pare-feu. CBAC également ne détecte pas et ne bloque pas les applets chargées par FTP, Gopher ou un port HTTP non-standard. Configurer l'inspection générique TCP et UDP Vous pouvez configurer l'inspection générique TCP et UDP pour permettre aux paquets UDP et TCP d'entrer dans le réseau interne au travers du pare-feu même si le protoco- le de couche application n'est pas configuré pour être inspecté. Cependant l'inspection générique TCP et UDP ne reconnaît pas les commandes spécifiques de l'application et par conséquent ne pourra pas permettre tous les paquets en retour pour une applica- tion et particulièrement si les paquets retour ont un numéro de port différent du paquet sortant. Tout protocole de couche application qui est inspecté a la priorité sur l'inspection géné- rique TCP et UDP. Par exemple, si l'inspection est configurée pour FTP, toutes les infor- mations du canal de commande seront enregistrées dans la table d'état et tout le trafic FTP sera autorisé en retour au travers du pare-feu si les informations du canal de com- mande sont valides pour l'état de la session FTP. Le fait que l'inspection générique TCP soit configurée n'a pas de lien direct avec l'information d'état FTP. Avec l'inspection générique TCP et UDP, les paquets entrant dans le réseau doivent cor- respondre exactement aux paquets qui sont précédemment sortis. Les paquets entrants doivent avoir les mêmes adresse source/destination, numéros de ports source/destina- tion mais permutés; s'il en est autrement, les paquets seront bloqués à l'interface. De même tous les paquets TCP avec un numéro de séquence hors de la fenêtre seront éli- minés. Avec l'inspection UDP configurée, les réponses seront autorisées à passer le pare-feu s'i elles sont reçues dans un délai configurable. (Ce délai est configuré avec la comman- de ip inspect udp idle-time). Pour configurer l'inspection CBAC pour les paquets TCP et UDP, utilisez une de ces deux commandes en mode de configuration global. Commande Fonction ip inspect name inspection-name tcp [timeout seconds] Valide l'inspection CBAC pour les paquets TCP. Utilisez le même inspection-name afin de créer une règle d'inspection unique ip inspect name inspection-name udp [timeout seconds] Valide l'inspection CBAC pour les paquets UDPP. Utilisez le même inspection-name afin de créer une règle d'inspection unique ccnp_cch

Appliquer une règle d'inspection à une interface Après avoir défini une règle d'inspection, vous appliquez cette règle à une interface. Normalement, vous appliquez une seule règle d'inspection à une interface. La seule ex- ception peur se produire si vous voulez valider CBAC dans les des sens comme cela a été décrit dans les sections précédentes. Pour CBAC configuré dans les deux sens sur une seule interface de pare-feu, vous devez appliquer deux règles, une pour chaque di- rection. Si vous configurez CBAC sur une interface externe, appliquez la règle au trafic sortant. Si vous configurez CBAC sur une interface interne, appliquez la règle au trafic entrant. Pour appliquer une règle d'inspection à une interface, utilisez les commandes suivantes en mode de configuration global. Commande Fonction ip inspect inspection-name {in|out} Applique une règle d'inspection à une interface. Afficher la configuration, les états et les statistiques CBAC Vous pouvez afficher certaines informations concernant CBAC en utilisant une ou plu- sieurs des commandes suivantes en mode EXEC. Commande Fonction show ip inspect name inspection-name Affiche une règle d'inspection particulière show ip inspect config Affiche la totalité de le configuration de l'inspection CBAC. show ip inspect interfaces Affiche la configuration de l'interface concernant les règles d'inspection et les listes d'accès appliquées. show ip inspect session [detail] Affiche les sessions qui sont en cours d'inspection CBAC. show ip inspect all Affiche toute la configuration CBAC et les sessions existantes en cours d'inspection CBAC. ccnp_cch

Debug pour CBAC ccnp_cch Pour aider à la résolution de problèmes CBAC, vous pouvez activer l'affichage des mes- sages d'audit qui seront affichés sur la console à la fin de chaque session CBAC. Pour valider les messages d'audit, utilisez les commandes suivantes en mode de configu- ration global. Commande Fonction ip inspect audit trail Valide les messages d'audit de CBAC. Si besoin est, vous pouvez aussi utiliser les commandes debug pour CBAC listées dans cette section.(Le "debugging" peut être arrêté pour chaque commande de cette section en utilisant la forme no de la commande. Pour arrêter complètement le "debugging", uti- lisez la commande no debug all ou undebug all en mode EXEC privilégié. Les commandes debug disponibles sont listées dans les catégories suivantes: • Commandes Debug génériques • Commandes Debug niveau Transport • Commandes Debug niveau Application Commandes Debug génériques Vous pouvez utiliser les commandes debug génériques en étant en mode EXEC privilé- gié. Commande Fonction debug ip inspect function-trace Affiche les messages au sujet des fonctions logicielles appelées par CBAC. debug ip inspect object-creation Affiche les messages au sujet des objets crées par CBAC. La création d'objet correspond au début de la session d'inspection CBAC. debug ip inspect object-deletion Affiche les messages au sujet des objets effacés par CBAC. L'effacement d'objet correspond à la fin de la session d'inspection CBAC. debug ip inspect events Affiche les messages au sujet des évènements logiciels de CBAC y compris des informations sur le traitement des paquets. debug ip inspect timers Affiche les messages au sujet des évènements timers tel que l'expiration de CBAC idle-timeout. debug ip inspect detail Valide l'option detail qui peut être utilisée en combinaison avec d'autres options pour obtenir des informations sup- plémentaires. ccnp_cch

Commandes Debug niveau transport Vous pouvez utiliser les commandes debug niveau transport en étant en mode EXEC privilégié. Commande Fonction debug ip inspect tcp Affiche les messages au sujet des évènements TCP inspectés par CBAC incluant les détails sur le paquets TCP. debug ip inspect udp Affiche les messages au sujet des évènements UDP inspectés par CBAC incluant les détails sur le paquets UDP. Commandes Debug niveau Protocole Application Vous pouvez utiliser les commandes debug niveau protocoles application en étant en mode EXEC privilégié. Commande Fonction debug ip inspect protocol Affiche les messages au sujet du protocole inspecté par CBAC incluant les détails sur les paquets du protocole. debug ip inspect udp Affiche les messages au sujet des évènements UDP inspectés par CBAC incluant les détails sur le paquets UDP. Le tableau suivant identifie les mots-clés pour les protocoles d'applications utilisés pour la commande debug ip inspect. Protocole Application Mot-clé protocol CU-SeeMe cuseeme FTP commandes et réponses ftp-cmd FTP tokensd (valide le traçage des tokens FTP) ftp-tokens H.323 h323 Java applets http UNIX commandes R (rlogin, rexec, rsh) rcmd RealAudio realaudio SMTP smtp SQL*Net sqlnet StreamWorks streamworks TFTP tftp VDOLive vdolive ccnp_cch

Interpréter les messages Syslog et Console générés par CBAC CBAC génère des messages syslog, des messages d'alerte et d'audit sur la console. Ces messages sont très utiles car ils peuvent vous alerter sur des attaques car ils fournis- sent également un audit qui donne des détails sur les sessions inspectées par CBAC. Bien qu'ils soient généralement référencés comme des messages d'erreur, tous les mes- sages d'erreur n'indiquent pas forcément un problème avec votre système. Les types de messages d'erreur suivants peuvent être générés par CBAC: • Messages d'erreur pour détection d'attaque Déni de Service • Messages d'erreur pour détection d'attaque SMTP • Messages d'erreur Blocage Java • Messages d'erreur FTP • Messages d'erreur trace d'Audit Messages d'erreur pour détection d'attaque Déni de Service CBAC détecte et bloque les attaques de type Déni de Service (DoS) et les notifie. Des messages d'erreur tels que les suivants peuvent indiquer des attaques de type Déni de Service (Denial of Service). %FW-4-ALERT_ON: getting aggressive, count (550/500) current 1-min rate: 250 %FW-4-ALERT_OFF: calming down, count (0/400) current 1-min rate: 0 Quand les messages d'erreur %FW-4-ALERT_ON et %FW-4-ALERT_OFF apparaissent ensem- bles, chaque paire de messages "aggressive/calming" indique une attaque. Les messages ci dessus indiquent une attaque. Les messages d'erreur suivants peuvent indiquer qu'une attaque Déni de Service s'est produite à partir d'un host particulier. %FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 172.21.127.242. %FW-4-BLOCK_HOST: Blocking new TCP connections to host 172.21.127.242 for 2 minutes (half-open count 50 exceeded) %FW-4-UNBLOCK_HOST: New TCP connections to host 172.21.127.242 no longer blocked Messages d'erreur pour détection d'attaque SMTP CBAC détecte et bloque les attaques SMTP (commandes illégales) et les notifie. Le mes- sage d'erreur suivant indique qu'une attaque SMTP s'est produite. %FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator (192.168.12.3:52419) Messages d'erreur Blocage Java CBAC détecte et bloque de manière sélective les applets Java et le notifie. Le message d'erreur suivant indique qu'une applet Java a été bloquée. %FW-4-HTTP_JAVA_BLOCK: JAVA applet is blocked from (172.21.127.218:80) to (172.16.57.30:44673). ccnp_cch

Messages d'erreur trace d'Audit Messages d'erreur FTP CBAC détecte et empêche certaines attaques FTP et les notifie. Des messages d'erreur tels que les suivants peuvent apparaître quand CBAC détecte des attaques FTP. %FW-3-FTP_PRIV_PORT: Privileged port 1000 used in PORT command -- FTP client 10.0.0.1 FTP server 10.1.0.1 %FW-3-FTP_SESSION_NOT_AUTHENTICATED: Command issued before the session is authenticated -- FTP client 10.0.0.1 %FW-3-FTP_NON_MATCHING_IP_ADDR: Non-matching address 172.19.148.154 used in PORT command -- FTP client 172.19.54.143 FTP server 172.16.127.242 Messages d'erreur trace d'Audit CBAC fournit des messages de trace d'audit pour enregistrer les détails des sessions d'inspection. Pour déterminer quel protocole a été inspecté, regardez le numéro de port du "responder" qui suit l'adresse du "responder". Voici un exemple de message de trace d'audit. %FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.13:33192) sent 22 bytes -- responder (192.168.129.11:25) sent 208 bytes %FW-6-SESS_AUDIT_TRAIL: http session initiator (172.16.57.30:44673) sent 1599 bytes -- responder (172.21.127.218:80) sent 93124 bytes Dévalider CBAC Vous pouvez dévalider CBAC avec la commande no ip inspect en mode de configura- tion global. Note: La commande no ip inspect retire toutes les entrées de configuration CBAC, les timeouts globaux et les seuils sont remis à leurs valeurs par défaut. Toutes les sessions existantes sont effacées et les listes d'accès associées sont retirées. Dans la majorité des situations, l'arrête de CBAC n'a pas d'impact négatif sur la sécuri- té car CBAC crée uniquement de listes d'accès "permit". Sans CBAC aucune liste d'accès "permit"n'est automatiquement créee et maintenue. Par conséquent aucun trafic retour ou canal de commande ne peut traverser le pare-feu. Il existe une exception pour le tra- fic SMTP et le blocage des applets Java. Avec CBAC dévalidé, des commandes SMTP non conformes ou des applets Java peuvent traverser le pare-feu. Exemple de configuration CBAC Cet exemple de configuration montre un pare-feu configuré avec CBAC. Ce pare-feu est positionné entre un réseau interne d'une agence et le réseau WAN de l'entreprise. CBAC est configuré sur le pare-feu dans le but de protéger le réseau interne des menaces potentielles venant du côté WAN. Le pare-feu a deux interfaces configurées: • Ethernet0 connectée au réseau interne protégé • Serial0 connectée au WAN avec du Frame Relay ccnp_cch

! ---------------------------------------------------------------------- ! This first section contains some configuration that is not required for CBAC, ! but illustrates good security practices. Note that there are no ! services on the Ethernet side. Email is picked up via POP from a server on the ! corporate side. ! hostname user1-examplecorp-fr boot system flash c1600-fw1600-l enable secret 5 <elided> username user1 password <elided> ip subnet-zero no ip source-route ip domain-name example.com ip name-server 172.19.2.132 ip name-server 198.92.30.32 ! ----------------------------------------------------------------------- ! The next section includes configuration required specifically for CBAC. ! The following commands define the inspection rule “myfw”, allowing ! the specified protocols to be inspected. Note that Java applets will be permitted ! according to access list 51, defined later in this configuration. ip inspect name myfw cuseeme timeout 3600 ip inspect name myfw ftp timeout 3600 ip inspect name myfw http java-list 51 timeout 30 ip inspect name myfw rcmd timeout 3600 ip inspect name myfw realaudio timeout 3600 ip inspect name myfw smtp timeout 3600 ip inspect name myfw tftp timeout 30 ip inspect name myfw udp timeout 15 ip inspect name myfw tcp timeout 3600 ! The following interface configuration applies the “myfw” inspection rule to ! inbound traffic at Ethernet 0. Since this interface is on the internal network ! side of the firewall, traffic entering Ethernet 0 is actually ! exiting the internal network. Applying the inspection rule to this interface causes ! inbound traffic (which is exiting the network) to be inspected; return traffic will ! only be permitted back through the firewall if part of a session which began from ! within the network. ! Also note that access list 101 is applied to inbound traffic at Ethernet 0. ! (Traffic blocked by the access list will not be inspected.) interface Ethernet0 description ExampleCorp Ethernet chez user1 ip address 172.19.139.1 255.255.255.248 ip broadcast-address 172.19.131.7 ccnp_cch

ccnp_cch no ip directed-broadcast no ip proxy-arp ip inspect myfw in ip access-group 101 in no cdp enable ! interface Serial0 description Frame Relay (Telco ID 22RTQQ062438-001) to ExampleCorp HQ no ip address ip broadcast-address 0.0.0.0 encapsulation frame-relay IETF no arp frame-relay bandwidth 56 service-module 56k clock source line service-module 56k network-type dds frame-relay lmi-type ansi ! Note that the following interface configuration applies access list 111 to ! inbound traffic at the external serial interface. (Inbound traffic is ! entering the network.) When CBAC inspection occurs on traffic exiting the ! network, temporary openings will be added to access list 111 to allow returning ! traffic that is part of existing sessions. interface Serial0.1 point-to-point ip unnumbered Ethernet0 ip access-group 111 in frame-relay interface-dlci 16 ip classless ip route 0.0.0.0 0.0.0.0 Serial0.1 ! The following access list defines “friendly” and “hostile” sites for Java ! applet blocking. Because Java applet blocking is defined in the inspection ! rule “myfw” and references access list 51, applets will be actively denied ! if they are from any of the “deny” addresses and allowed only if they are from ! either of the two “permit” networks. access-list 51 deny 172.19.1.203 access-list 51 deny 172.19.2.147 access-list 51 permit 172.18.0.0 0.1.255.255 access-list 51 permit 192.168.1.0 0.0.0.255 access-list 51 deny any ! The following access list 101 is applied to interface Ethernet 0 above. ! This access list permits all traffic that should be CBAC inspected, and also ! provides anti-spoofing. The access list is deliberately set up to deny unknown ! IP protocols, because no such unknown protocols will be in legitimate use. access-list 101 permit tcp 172.19.139.0 0.0.0.7 any access-list 101 permit udp 172.19.139.0 0.0.0.7 any access-list 101 permit icmp 172.19.139.0 0.0.0.7 any access-list 101 deny ip any any ! The following access list 111 is applied to interface Serial 0.1 above. ! This access list filters traffic coming in from the external side. When ! CBAC inspection occurs, temporary openings will be added to the beginning of ! this access list to allow return traffic back into the internal network. ! This access list should restrict traffic that will be inspected by ! CBAC. (Remember that CBAC will open holes as necessary to permit returning traffic.) ! Comments precede each access list entry. These entries are not all specifically ! related to CBAC, but are created to provide general good security. ccnp_cch

ccnp_cch ! ! Anti-spoofing. access-list 111 deny ip 172.19.139.0 0.0.0.7 any ! Sometimes EIGRP is run on the Frame Relay link. When you use an ! input access list, you have to explicitly allow even control traffic. ! This could be more restrictive, but there would have to be entries ! for the EIGRP multicast as well as for the office’s own unicast address. access-list 111 permit igrp any any ! These are the ICMP types actually used... ! administratively-prohibited is useful when you are trying to figure out why ! you cannot reach something you think you should be able to reach. access-list 111 permit icmp any 172.19.139.0 0.0.0.7 administratively-prohibited ! This allows network admins at headquarters to ping hosts at the field office: access-list 111 permit icmp any 172.19.139.0 0.0.0.7 echo ! This allows the field office to do outgoing pings access-list 111 permit icmp any 172.19.139.0 0.0.0.7 echo-reply ! Path MTU discovery requires too-big messages access-list 111 permit icmp any 172.19.139.0 0.0.0.7 packet-too-big ! Outgoing traceroute requires time-exceeded messages to come back access-list 111 permit icmp any 172.19.139.0 0.0.0.7 time-exceeded ! Incoming traceroute access-list 111 permit icmp any 172.19.139.0 0.0.0.7 traceroute ! Permits all unreachables because if you are trying to debug ! things from the remote office, you want to see them. If nobody ever did ! any debugging from the network, it would be more appropriate to permit only ! port unreachables or no unreachables at all. access-list 111 permit icmp any 172.19.139.0 0.0.0.7 unreachable ! These next two entries permit users on most ExampleCorp networks to Telnet to ! a host in the field office. This is for remote administration by the network admins. access-list 111 permit tcp 172.18.0.0 0.1.255.255 host 172.19.139.1 eq telnet access-list 111 permit tcp 192.168.1.0 0.0.0.255 host 172.19.139.1 eq telnet ! Final deny for explicitness access-list 111 deny ip any any no cdp run snmp-server community <elided> RO line con 0 exec-timeout 0 0 password <elided> login local line vty 0 length 35 line vty 1 password 7 <elided> line vty 2 ccnp_cch

ccnp_cch line vty 3 exec-timeout 0 0 password 7 <elided> login local line vty 4 ! scheduler interval 500 end ccnp_cch