CBAC - Avantages et Limitations ccnp_cch ccnp_cch

Sommaire • Introduction • Qu'est-ce que CBAC? • Concepts et terminologie - Conversations (communications) - Canaux - Ensembles d'inspection - Inspection générique • Avantages - Faibles ouvertures dans les listes d'accès - Filtrage des attaques type tierce partie - Résistance aux attaques TCP SYN, DoS - Synergie avec NAT (Network Address Translation) • Limitations et faiblesses - Limites de l'inspection - Redondance, reroutage et assymétrie - Reconfiguration dynamique - Sessions UDP avec timeout - DNS avec UDP • Informations importantes - L'inspection opère dans le sens de l'initialisation de la communication - L'inspection opère uniquement après l'établissement de la communication ccnp_cch

Introduction ccnp_cch Le pare-feu Cisco IOS est un ensemble de fonctionnalités qui rendent le logiciel Cisco IOS plus efficace pour le périmètre de sécurité. Les fonctionnalités de pare-feu sont basées sur l'inspection de données dans les paquets y compris les données après les en-têtes. CBAC (Context-Based Access Control) fait que le routeur garde un état en permanence basé sur l'information d'inspection des paquets et utilise cette information d'état pour décider quel trafic doit être acheminé. CBAC est la pièce maîtresse de la fonctionnalité de pare-feu et des autres fonctionnalités constituées autour de CBAC. Les informations de connexion peuvent être rassemblées par CBAC et transmises à un serveur Syslog. Qu'est-ce que CBAC? Le pare-feu Cisco IOS est un système d'inspection de paquets. C'est un système "State- ful", il garde des informations au sujet des connexions qui se terminent en dehors de la durée de vie d'un paquet. CBAC est une fonctionnalité pour IP uniquement. Un rou- teur utilisant CBAC reconnaît TCP (Transport Control protocol), UDP (User Datagram Protocol) et quelques autres protocoles de couches supérieures et examine les paquets au-delà des en-têtes. CBAC garde une trace des informations apprises des paquets qu'il examine. CBAC fait plusieurs choses importantes: • Comme CBAC reconnaît TCP, UDP et quelques protocoles des couches supérieures, il extrait des informations du flux de données au sujet des paquets qui sont autori- sés à passer au travers du pare-feu pour que ces protocoles fonctionnent correcte- ment. Par exemple CBAC permet le trafic retour d'une connexion TCP une fois que la connexion a été initiée et reconnaît les connexions de données FTP. CBAC utilise ces informations pour créer des exceptions au filtrage défini par les listes d'accès. • CBAC scrute les violations de protocole et les commandes suspectes dans les flux de protocoles traversant le routeur. Si le mode d'attaque est connu ou une violation sé- rieuse de protocole est détectée, le trafic non conforme est bloqué et une alerte est signalée. • CBAC fournit les bases pour effectuer des statistiques et du logging de sessions. La fonctionnalité de logging utilise les informations de CBAC pour transmettre des in- formtions de log vers un serveur Syslog. Les logs comprennent des informations au sujet des host qui communiquent, des numéros de ports et du nombre d'octets transférés. L'IOS Cisco Firewall n'est pas un système proxy. Il ne n'agit pas comme un point ter- minal TCP. Les paquets entrants y compris les fragments sont passés au travers du routeur sans être modifiés. CBAC insère des lignes dans les listes d'accès ne les rem- place pas. En fait, les listes d'accès sont quasiment toujours nécessaires pour que CBAC soit utile. CBAC bloque le trafic réseau uniquement quand il reconnaît une violation de protocole ou quelque chose qui est reconnu comme une attaque. Ce blocage est une fonctionna- lité importante mais pour des besoins de configuration CBAC crée des ouvertures dans le pare-feu. Avec CBAC, vous utilisez des listes d'accès du routeur pour définir quelles ccnp_cch

sessions seront autorisées à passer au travers du routeur au lieu de spécifier exactem- ent les paquets sont autorisés. Vos listes d'accès ont seulement besoin de permettre le premier paquet de couche application d'une communication. CBAC crée automatique- ment les entrées dynamiques temporaires dans les listes d'accès pour permettre le tra- fic retour et le trafic sur des connexions secondaires associées avec la communication. Comme CBAC ajoute des entrées permit au début des listes d'accès, CBAC permet plus de trafic que seule la liste d'accès le permettrait. L'avantage est que le trafic permit est soigneusement choisi. Quand CBAC est utilisé, la liste d'accès sous-jacente peut être beaucoup plus restrictive qu'elle le serait sans CBAC. CBAC crée uniquement les ex- ceptions spécifiques qui sont réellement nécessaires. Concepts et Terminologie Conversations (Communications) Dans ce document, une conversation est une session de protocole de couche applica- tion tel que Telnet, FTP ou une conférence H.323. Le mot session n'est pas utilisé ceci pour éviter des confusions avec les sessions qui sont affichées par la commande show ip inspect sessions et les sessions de couche application. Une conversation peut englober plus d'une paire de hosts et ports au niveau de la cou- che transport. Par exemple une conversation FTP inclut quasiment toujours au moins deux sessions TCP: une pour le contrôle et une pour les données. Une conversation H.323 peut inclure plusieurs flux de données UDO: voix, vidéo et tableau blanc. CBAC crée une conversation quand il voit le paquet qui débute la conversation. Avec FTP, CBAC cherche une commande port/passif dans le flux de données pour déterminer s'il doit autoriser le trafic. Canaux Un canal est une ouverture dans le pare-feu qui permet une communication entre un port spécifique sur un host et un port spécifique sur un autre host. Chaque entrée af- fichée par la commande show ip inspect sessions représente un canal unique. Pour les protocoles basés sur TCP, les canaux correspondent directement aux connexions TCP. Il y a un canal pour chaque connexion TCP. CBAC crée dynamiquement les canaux selon les besoins du protocole de l'application. Par exemple si un client FTP exécute des commandes qui nécessitent l'établissement d'une connexion de données, CBAC ouvre un canal pour permettre cette connexion. Ce canal fait partie de la conversation globale FTP. La connexion de commande a aussi un canal ainsi il y a au moins deux canaux pour la majorité des connexions FTP. Quand les données ont été transférées, CBAC ferme automatiquement le canal de don- nées et quand l'utilisateur FTP se déconnecte, CBAC ferme automatiquement le canal de commande. Chaque fois que CBAC crée un canal, il modifie automatiquement les listes d'accès sur les interfaces appropriées pour permettre le trafic sur ce canal. Ceci autorise le trafic du canal à passer au travers du routeur même si les listes d'accès ne le permettait pas. Ces modifications de listes d'accès sont temporaires. Elles sont visi- bles dans l'affichage de la commande show access-lists mais n'apparaissent pas dans la configuration du système. ccnp_cch

Ensembles d'inspection Un ensemble d'inspection est un ensemble nommé de paramètres de configuration CBAC définissant quel trafic CBAC inspectera et comment il va faire cela. Toutes les commandes ip inspect name <inspection-name> qui utilisent la même valeur inspec- tion-name font partie du même ensemble d'inspection. Il peut y avoir plusieurs ensem- bles d'inspection définis dans une seule configuration de routeur. Chaque ensemble d'inspection peut être appliqué au trafic entrant sur une ou plusieurs interfaces ou les deux. Pour les règles d'application des ensembles d'inspection, le sens du trafic est le sens de l'initiation de la conversation. Par exemple si une connexion Telnet est faite au travers du routeur, les paquets circulent dans les deux directions. La direction dans laquelle l'inspection est configurée est la direction du paquet TCP SYN (Synchronize) qui initie la connexion Telnet car CBAC examine les paquets circulant dans les deux direc- tions. Inspection générique L'inspection générique vous permet d'utiliser CBAC pour des protocoles de couche ap- plication dont le système ne sait pas analyser les flux de données. Avec l'inspection gé- nérique par exemple vous pouvez permettre le trafic Telnet bien qu'il n'y ait pas d'ins- pection spécifique pour Telnet. L'inspection générique fonctionne uniquement pour les protocoles qui utilisent une seule connexion TCP initiée côté client. CBAC crée un seul canal en réponse au paquet TCP SYN qui ouvre la connexion TCP et détruit le canal en réponse au paquet TCP FIN qui termine la conversation. L'inspection UDP générique fonctionne uniquement pour les protocoles qui utilisent une seule paire client host/port et une seule paire serveur host/port. CBAC crée un canal en réponse au premier paquet que le client transmet au serveur et laisse ce canal ouvert jusqu'à ce qu'il n'y ait plus d'activité pendant une période donnée. Avantages Faibles ouvertures dans les listes d'accès CBAC vous autorise à permettre moins de trafic que vous auriez à permettre pour obte- nir une fonctionnalité identique avec des listes d'accès statiques. Par exemple considé- rons une configuration simple d'un pare-feu avec un réseau privé sur Ethernet0 et In- ternet sur Serial0. Nous voulons que les utilisateurs du réseau privé soient capables de se connecter aux services d'Internet mais nous ne voulons aucun accès depuis Internet dans le réseau privé. Le réseau privé n'a aucun serveurs que le monde extérieur pour- rait utiliser. Pour le moment, nous ne tiendront pas compte de certains aspects tels que l'anti-usurpation et le retour pour ICMP (Internet Control Message Protocol) et nous ne montrerons que quelques configurations partielles simplifiées. ccnp_cch

Internet ccnp_cch Schéma du réseau Réseau protégé S0 E0 Cisco IOS Firewall Exemple 1 - Sans CBAC Sans CBAC, une configuration partielle simplifiée peut ressembler à cela: !--- Ethernet0 est le réseau interne protégé. interface ethernet 0 ip address 10.0.0.1 ! !--- Le trafic réseau d'Internet arrive sur la Serial0. interface serial 0 ip address 1.1.1.1 ip access-group 101 in !--- Laisse entrer les données associées à une connexion initiée en sortie. !--- Cette ouverture permet des attaques de type fragmentation access-list 101 permit tcp any any established !--- Le serveur DNS interne 10.0.0.2 peut transmettre des requêtes !--- aux autres serveurs DNS en utilisant le port 53. Cette entrée !--- permet également aux machines externes d'atteindre le DNS. access-list 101 permit udp any host 10.0.0.2 eq 53 !--- Cette liste d'accès est nécessaire pour permettre aux utilisateurs !--- internes d'atteindre des services UDP externes. access-list 101 permit udp any any gt 1024 !--- Cette liste d'accès est nécessaire pour autoriser les utilisateurs !--- à accéder à un FTP passive. access-list 101 tcp any any gt 1023 access-list 101 deny ip any any Avec cette configuration, les utilisateurs doivent être très sélectifs avec les clients FTP qu'ils utilisent, les commandes UNIX rsh ne fonctionnent pas et il y a toujours des ris- ques sérieux de sécurité. Chaque service UDP avec un numéro de port supérieur à 1024 est disponible. Ceci peut être amélioré en bloquant des ports dangereux mais une charge administrative et pas très fiable est générée. Si un serveur proxy DNS était utili- sé on pourrait bloquer tous les ports UDP sauf les ports connus et utilisés par des pro- grammes connus. ccnp_cch

Exemple 2 - Avec CBAC Avec CBAC, une configuration partielle simplifiée peut ressembler à cela: !--- Ethernet0 est le réseau interne protégé. interface ethernet 0 ip address 10.0.0.1 ! !--- L'inspection est appliquée en entrée car les paquets d'initiation des !--- entrent par cette interface en venant du réseau privé interne. !--- Inspection est toujours appliquée dans la direction de l'initiation !--- des connexions bien qu'elle traite les paquets circulant dans les deux !--- sens. Aucune initiation de conversation n'est autorisée de l'Internet !--- vers le réseau privé interne. ip inspect firewall in !--- Le trafic réseau d'Internet entre par l'interface Serial0. interface serial 0 ip address 1.1.1.1 ip access-group 101 in !--- La liste d'accès ne permet rien vers le réseau privé interne. !--- CBAC crée des ouvertures en réponse aux connexions initiées depuis le !--- réseau privé interne pour que le trafic retour entre. access-list 101 deny ip any any !--- Voici la liste des protocoles inspectés. L'hypothèse est que nous !--- voulons que les utilisateurs du réseau privé puissent initier toutes !--- sortes de conversations en sorties. ip inspect name firewall cuseeme ip inspect name firewall ftp ip inspect name firewall h323 !--- L'inspection HTTP non opportune ici, elle est équivalent à une !--- inspection TCP. On peut valider le filtrage Java ici, mais celui-ci !--- est réellement recommandé si vous avez des attaques spéciales à bloquer. ip inspect name firewall http ip inspect name firewall netshow ip inspect name firewall rcmd ip inspect name firewall realaudio !--- L'inspection SMTP(Simple Mail Transfer Protocol) recherche des !--- commandes incorrectes. ip inspect name firewall smtp ip inspect name firewall sqlnet ip inspect name firewall streamworks ip inspect name firewall tftp !--- L'inspection TCP Generique permet le fonctionnement normal de la !--- majorité des protocoles tant qu'ils utilisent une seule connexion TCP. ip inspect name firewall tcp !--- L'inspection UDP Generique UDP est identique à l'inspection générique !--- TCP tant qu'il y a une seule paire client host/port et serveur host/port. ip inspect name firewall udp ip inspect name firewall vdolive ccnp_cch

La configuration est longue mais pas compliquée La configuration est longue mais pas compliquée. La majorité des lignes valident toutes sortes d'inspections possibles (sauf RPC (Remote Procedure Call) de Sun). cette configu- ration permet aux utilisateurs d'utiliser n'importe quel service TCP qui utilise une seule connexion et tout service UDP qui utilise uniquement un seul serveur/host et plusieurs services multimédia. Les utilisateurs peuvent utiliser tout client FTP ou TFTP et peu- vent exécuter les commandes "r". En même temps, la sécurité est meilleure que celle de l'exemple 1. Les paquets TCP peuvent venir de l'extérieur uniquement en réponse à un trafic initié depuis l'intérieur. Les limitations du mot-clé "established" sont évitées. Filtrage des usages abusifs de protocoles CBAC reconnaît quelques méthodes connues d'usages abusifs de protocoles et prend les mesures pour les stopper. Par exemple CBAC ne permettra pas les attaques FTP de type tierce partie. Quand l'inspection SMTP est validée, CBAC cherchera dans la charge utile des paquets SMTP les commandes invalides. Les commandes SMTP valides sont indiquées dans le document "IOS Security Command Reference". Au cours du temps le nombre de violations de protocoles reconnues par CBAC augmente. Résistance aux attaques de type DoS (Denial of Service) Une attaque TCP SYN apparaît quand un host source génère des paquets TCP SYN avec des adresses sources aléatoires et les transmet successivement et à un rythme très élevé vers le host victime. Le host destination victime transmet un SYN ACK destiné à l'adresse source aléatoire et ajoute une entrée dans la file de connexion. Comme le message SYN ACK est destiné à un host inexistant ou incorrect, l'acquittement n'est jamais reçu et l'entrée reste dans la file de connexion jusqu'à ce que le timer de validité expire. La file de connexion se remplit et les utilisateurs légitimes ne peuvent pas utili- ser les services TCP. Cependant avec CBAC les paquets TCP passent de l'extérieur vers l'intérieur en réponse au trafic transmis depuis l'intérieur. Le host attaquant ne peut pas faire passer ses paquets vers le réseau interne et l'attaque échoue. De plus en inspectant le trafic entrant sur l'interface externe (l'interface serial0 dans l'exemple ci-dessus) CBAC peut comptabiliser le nombre de connexions semi-ouvertes sur le pare-feu et peut commencer à fermer ces connexions semi-ouvertes sans attendre l'ex- piration du délai de validité. Le pare-feu arrêtera de fermer ces connexions semi-ou- vertes jusqu'à ce leur nombre redescende à une valeur définie par l'administrateur. Synergie avec NAT (Network Address Translation) Quand CBAC et NAT sont combinés, le pare-feu réalise l'inspection CBAC et les tâches suivantes: • Cache vos adresses IP internes au monde externe • Fournit des protections supplémentaires pour un protocole comme ICMP qui n'est pas supporté par CBAC. Comme NAT alloue uniquement des adresses pour les noeuds qui transmettent du trafic au travers du routeur, les hosts internes sont protégés des attaques spontanées venant d'Internet. Un host doit envoyer des informations vers Internet avant de pouvoir être attaqué. ccnp_cch

Limitations et Faiblesses Limitations de l'Inspection Il y a deux philosophies de base pour un pare-feu qui examine le trafic des couches hautes. • Le pare-feu peut essayer de comprendre chaque protocole supporté jusqu'à une cou- che donnée, toutes les commandes possibles, les formats de données et les options de ce protocole. Une fois que cela est fait, il rejette tout ce qu'il ne comprend pas en considérant que c'est une violation du protocole. Cette approche offre une sécurité très élevée mais de faibles performances et une complexité accrue du pare-feu, de grandes chances de problèmes lorsque le pare-feu doit opérer avec un grand nombre d'implémentations de protocoles et une attente importante pour la mise en oeuvre de nouvelles fonctionnalités pour un protocole. • Le pare-feu essaie de comprendre uniquement ce qui est le plus important de savoir au sujet de ce protocole et rejette le trafic uniquement quand il voit des informations qui sont connues comme des attaques de sécurité ou des violations de protocoles si sévères qu'il ne peut pas vérifier les informations critiques dans ce flux de données. Cette approche est simple, rapide et flexible. Elle permet le déploiement de nouveaux protocoles et des implémentations non usuelles sans mise à jour constante du pare- feu. Cependant elle permet l'introduction de risques de violation de sécurité qui ne sont pas connus du pare-feu. Aucune des approches n'est viable dans sa forme pure. Tous les pare-feu représentent un compromis entre ces deux approches. Dans la majorité des cas, l'IOS Cisco Firewall favorise la seconde approche spécialement pour la couche application. Comme CABC protège d'abord contre les attaques connues, il ne peut pas fournir de protection contre des attaques inconnues ou de nouveaux modes d'attaques. CBAC permet des choses que certains administrateurs considèrent dangereuses. Par exemple, il permet les commandes EXPN et VRFY sur le connexions SMTP. Bien qu'elles soient des parties légitimes de SMTP, beaucoup de personnes pensent que ces coman- des commandes ne doivent pas franchir les limites du domaine administratif. L'intervention relativement sélective de CBAC sur les informations traversant le pare-feu le rend rapide et flexible mais il est requis que l'administrateur comprenne ce qui est et ce qui n'est pas testé. Examinez toujours la documentation avant compter sur l'IOS Cisco Firewall pour protéger contre des attaques spécifiques sur un protocole devant traverser le pare-feu. Si la documentation ne dit pas explicitement que cette partie doit être testée vous devez en déduire que ce n'est pas testé et utiliser d'autres moyens pour vous protéger. Vous ne devez jamais exposer un service à Internet à moins que vous pensiez que ce logiciel fournissant ce service est robuste et sécurisé; ne comptez pas sur CBAC (ou tout autre chose) pour compenser complètement toutes les vulnérabilités de sécurité possibles sur un host. ccnp_cch

Redondance, reroutage et assymétrie Tous les états du pare-feu sont internes à un seul routeur et il y n'y a pas de possibilité de redondance avec un autre routeur. Par conséquent si un routeur opérant avec CBAC ne fonctionne plus, les conversations CBAC sont perdues. Les configurations avec routage assymétrique dans lesquelles un seul sens par session passe au travers du pare-feu routeur ne fonctionnent pas. Bien que le Firewall IOS Cisco ne supporte pas la redondance de routeur, il supporte la redondance d'interface et le partage de charge. Quand CBAC crée un nouveau canal, il installe les entrées de listes d'accès temporaires sur les interfaces utilisées par le pa- quet initial. La même liste d'accès peut être installée sur l'interface de secours qui four- nit des chemins additionnels vers les mêmes destinations. On peut possible utiliser CBAC avec le partage de charge tant que les interfaces en parallèle sont configurées de manière identique. Si vous configurez les mêmes listes d'accès et paramètres d'ins- pection sur deux interfaces qui sont des chemins alternatifs vers la même destination cela pourrait fonctionner plus ou moins bien. Note: Vous devez utiliser la liste d'accès (même numéro sur les deux interfaces) sur les deux interfaces. Reconfiguration dynamique CBAC modifie les listes d'accès qui sont normalement considérées comme partie de la configuration système. Bien que les changement soient temporaires et non écrits dans le fichier de configuration, il interagissent avec le reste de la configuration. En consé- quence la modification des listes d'accès pendant que CBAC fonctionne peut être dan- gereux. Voici quelques exemples de problèmes: • Si une liste d'accès est effacée et recréée, les entrées temporaires de CBAC dans cette liste d'accès sont perdues. Comme le seul moyen de modifier une liste d'accès est de l'effacer puis de la recréer, la reconfiguration de la liste d'accès peut bloquer tous les canaux CBAC utilisant cette interface. Si le numéro de la liste d'accès appli- quée à l'interface est changé, les entrées CBAC dynamiques ne sont pas transférées sur la nouvelle liste d'accès. Les conversations CBAC sont perdues. • Si la même liste d'accès est appliquée à une ou plusieurs interfaces, les entrées CBAC dynamiques sont appliquées à toutes les interfaces. Ceci peut être utilisé pour supporter la redondance d'interface, ce qui est généralement une bonne chose, mais vous ne devez pas utiliser la même liste d'accès pour deux interfaces sauf si elles représentent des chemins redondants dans le même domaine de sécurité. • Si une interface a une liste d'accès configurée avec la commande ip access-group et que cette liste d'accès n'existe pas, vous entrez dans une particularité de l'IOS Cisco. Une liste d'accès vide permet tout alors qu'une liste d'accès non vide rejette tout ce qui n'est pas explicitement permis. Quand CBAC ajoute une entrée tempo- raire à la liste d'accès vide elle devient non vide et par conséquent sa sémantique s'inverse. Assurez-vous que la liste d'accès que vous utilisez avec la commande ip access-group existe. ccnp_cch

Sessions UDP avec timeout Comme UDP est fondamentalement non-connecté, l'inspection générique CBAC UDP ne peut pas savoir quand la requête du client a été satisfaite. Par conséquent, l'inspection générique UDP crée un canal quand elle voit le premier paquet de requête venant du client et garde ce canal ouvert jusqu'à ce qu'il n'y ait plus de trafic détecté entre le ser- veur et le client pendant une durée prédéterminée. DNS UDP CBAC n'inspecte pas directement le protocole DNS (Domain Name Service); il utilise l'inspection générique UDP pour le DNS. Toutefois CBAC peut appliquer un timer d'inactivité DNS différent de celui utilisé pour les autres transactions UDP. Ceci est très important car un long timeout pour DNS peut résulter en un grand nombre de canaux UDP ouverts. Pas de support ICMP CBAC ne connaît pas ICMP, soit comme protocole soit comme source de données en à une conversation utilisant TCP ou UDP. Quand vous configurez CBAC vous devez prendre des décisions globales pour autoriser les paquets ICMP à traverser le pare-feu. Informations importantes L'inspection opère dans le sens de l'initiation de la conversation Le Firewall IOS Cisco n'a pas de concept d'interfaces "inside" ou "outside"; vous pouvez appliquer l'inspection à tout trafic sur toute interface. Le pare-feu utilise le sens de la conversation. Le sens de la conversation est le sens du premier paquet client qui établit la conversation. Par exemple si une machine sur un réseau privé se connecte à Internet le sens de la conversation est du réseau privé vers Internet. Pour que CBAC inspecte cette conversation ( et par conséquent crée les entrées de liste d'accès autorisant le trafic) la commande ip inspect doit être appliquée soit en entrée sur l'interface du ré- seau privé soit en sortie sur l'interface vers Internet. L'inspection opère uniquement après l'établissement de la conversation CBAC ne pourra pas créer de conversation ou ouvrir de canaux sauf si les deux listes d'accès en entrée et en sortie autorisent le paquet qui initie la conversation. Cela si- gnifie que les listes d'accès peuvent être utilisées pour contrôler les conversations qui peuvent être créées. Une fois que les conversations sont créées, CBAC les gère. Par exemple quand une connexion est faite du réseau privé vers Internet les deux listes d'accès en entrée et en sortie autorisent le paquet qui initie la conversation. Si une des listes d'accès rejette le paquet la conversation n'est pas créee et CBAC ne crée pas d'entrée temporaire dans la liste d'accès. ccnp_cch