Stere Prada, déploiement de la politique de sécurité
Transcription
Stere Prada, déploiement de la politique de sécurité
Détection d’anomalies dans les configurations de composants de sécurité réseau Stere Preda [email protected] 27 mars 2 février 20072007 Plan • Contexte • Problématique : gestion des anomalies • Démarche : déploiement de la politique de sécurité • Travail réalisé • Conclusions / Perspectives 1 Contexte Déploiement de la politique de sécurité configuration des composants de sécurité classe de composants : IDS, Firewall, VPN, IPS détection d’anomalies gestion des anomalies par déploiement administration de la sécurité 2 Plan • Contexte • Problématique : gestion des anomalies • Démarche : déploiement de la politique de sécurité • Travail réalisé • Conclusions / Perspectives 3 Problématique Politique de sécurité du système à protéger Déploiement sur les différents composants de sécurité Sans les anomalies intra & inter composants Approches : analytique raffinement 4 Problématique Approche analytique analyser les configurations existantes • intra composant : un seul composant analysé • inter composant : conflit entre configurations de composants différents méthode générale pour analyser les configurations de différents composants de sécurité : firewall, VPN, IDS, IPS 5 Principales anomalies Firewall intra : • shadowing • redondance inter : • Conflits inter firewalls • conflit firewall – autre composant Solutions : algorithmes de réécritures - F. Cuppens, N. Cuppens-Boulahia, J. Garcia-Alfaro, "Detection and removal of firewall misconfiguration", 2005 IASTED International Conference on Communication, Network and Information Security, Phoenix, AZ, USA, Novemb re, 2005. 6 Principales anomalies IDS Anomalies : • Conflit IDS & firewall • Redondance IDS & firewall • Signature non pertinente Solution : algorithmes de corrélation de configurations inter composants Joaquin G. Alfaro, Frédéric Cuppens, Nora Cuppens-Boulahia, "Analysis of Policy Anomalies on Distributed Network Security Setups", 2006. 7 Principales anomalies VPN Conflit VPN - firewall Enchevêtrement des tunnels - Zhi Fu, S. Felix Wu, He Huang, Kung Loh, Fengmin Gong, Ilia Baldine, and Chong Xu, "IPSec/VPN Security Policy: Correctness, Conflict Detection, and Resolution", Springer-Verlag Berlin Heidelb erg 2001 8 Problématique du stage Approche raffinement : « top-down » 9 Plan • Contexte • Problématique : gestion des anomalies • Démarche : déploiement de la politique de sécurité • Travail réalisé • Conclusions / Perspectives 10 Démarche OrBAC : modèle de contrôle d’accès basé sur l’organisation Permission d’un rôle de réaliser une activité sur une Rôles, Sujets,ex. ex.: :rôle machine de firewall, locale, rôle sous-réseau, de serveur serveur web, rôle vue de bout VPN Activités, Actions, ex. ex.d’un :: http, « all_tcp ftp, de ssh, », réaliser « ftp web »,une « icmp » sur un objet Permission sujet action Vues, Messages, ex. : «objets, Internet ex.» :- paquet toutes les IP, machines entité destinataire ayant le rôle « R_Internet » rôle activité vue Organisation sujet action objet 11 Démarche Décomposition de la politique de sécurité - F. Cuppens, N. Cuppens-Boulahia, T. Sans, A. Miège. "A formal approach to specify and deploy a network security policy", Second Workshop on Formal Aspects in Security and Trust (FAST). Toulouse, France. August, 2004. 12 Plan • Contexte • Problématique : gestion des anomalies • Démarche : déploiement de la politique de sécurité • Travail réalisé • Conclusions / Perspectives 13 Travail réalisé Approche raffinement méthodologie de déploiement automatique de la politique de sécurité à la base du modèle OrBAC déploiement sur les « bons » composants de sécurité composant cibles : • firewall Netfilter • l’IPS Netasq (firewall & VPN) • IDS Snort 14 Travail réalisé Expression XML des concepts OrBAC Ex. de permission OrBAC : rôle → activité →vue contexte <permission> <permissionName>P_siteExt_srv_BD</permissionName> <roleName>R_Site_ext</roleName> <serviceName>ALL_TCP</serviceName> <target> <roleName>R_srv_BD</roleName> </target> <contexte name="protected"/> </permission> sans le « securityRole » 15 Travail réalisé Déploiement sur les « bons » composants algorithme d’identification des composants de sécurité : • principe du « plus court chemin » • zones, voisins, prise en compte des fonctionnalités des composants de sécurité • balises spéciales : « R_FW », « R_VPN », « R_IDS » • réduction de la « redondance » dans le cas des firewalls • résout le conflit firewall – VPN : définition de nouvelles permissions au niveau OrBAC 16 Travail réalisé La première transformation XSLT La deuxième transformation XSLT niveau intermédiaire, indépendant du choix de composant le traitement des hiérarchies de rôles conforme à la grammaire du composant de sécurité Ex. : « la zone Intra a le droit de naviguer sur Internet » Netasq F200 NetFilter : [Intra-ALL_TCP-Net_group_1] iptables -N Intra-ALL_TCP-Net host_1_1_Intra-ALL_TCP-Net=111.222.2.0, type=host, resolve=static plage_1_2_Intra-ALL_TCP-Net=111.222.2.2:111.222.2.53 iptables -A FORWARD -s 111.222.2.0/24 -d 0.0.0.0/0 -p tcp -j Intra-ALL_TCP-Net plage_1_3_Intra-ALL_TCP-Net=111.222.2.55:111.222.2.255 iptables [Intra-ALL_TCP-Net_group_2] -A Intra-ALL_TCP-Net -s 111.222.2.1 -j RETURN iptables -A Intra-ALL_TCP-Net -s 111.222.2.54 -j RETURN plage_2_1_Intra-ALL_TCP-Net=0.0.0.1:111.221.255.255 iptables -A Intra-ALL_TCP-Net -d 111.222.0.0/16 -j RETURN plage_2_2_Intra-ALL_TCP-Net=111.223.0.0:255.255.255.255 iptables -A Intra-ALL_TCP-Net -j ACCEPT pass proto tcp from Intra-ALL_TCP-Net_group_1 to Intra-ALL_TCP-Net_group_2 17 Travail réalisé Le traitement des alertes algorithme d’identification des composants de sécurité : • principe du « plus court chemin » • réduction du « spoofing » 18 Travail réalisé Expression XML des concepts OrBAC Ex. « warning » OrBAC (vulnérabilité - manuel SNORT) : <!--ext mountd acces--> <warning> <warningName>W_ExtMount_Net_Intra</warningName> # avec l’hypothèse de règles mutuellement disjointes : <roleName>R_Net</roleName> pass tcp !111.222.0.0/16 any -> 111.222.2.1 111 (msg:"external mountd access"; content:"|00 01 86 a5|"; ) <serviceName>RPC</serviceName> pass tcp !111.222.0.0/16 any -> 111.222.2.54 111 (msg:"external mountd access"; content:"|00 01 86 a5|"; ) <target> any -> 111.222.2.0/24 111 (msg:"external mountd access"; content:"|00 01 86 alert tcp !111.222.0.0/16 <roleName>R_Intra</roleName> a5|";) </target> <contexte> < !--l’algorithme peut être un code de cette vulnérabilité--> # avec de CVE découpage d’intervalles d’adresses : <content>|00 01 86 a5|</content> alert tcp !111.222.0.0/16 any -> </contexte> [111.222.2.0/32,111.222.2.2/31,111.222.2.4/30,111.222.2.8/29,111.222.2.16/28,111.222.2.32/28,111.2 <msg>external mountd access</msg> 22.2.48/30,111.222.2.52/31,111.222.2.55/32,111.222.2.56/29,111.222.2.64/26,111.222.2.128/25] 111 </warning> (msg:"external mountd access"; content:"|00 01 86 a5|";) 19 Travail réalisé La redondance IDS-firewall « top – down » indication du mauvais fonctionnement d’un firewall D • « warning » IDS, W : (S,D,P) • politique de filtrage (pass/accept) F : F Wa (alert) Wr (redondance) W S 20 Plan • Contexte • Problématique : gestion des anomalies • Démarche : déploiement de la politique de sécurité • Travail réalisé • Conclusions / Perspectives 21 Conclusions Expression XML de la politique de sécurité Jeu de transformations XSLT qui fonctionnent pour tout composant Netasq dans les hypothèses : adresses IPv4 « plus court chemin » configuration de firewalls et VPN Perspectives : la deuxième transformation XSLT vers « fwbuilder » IPv6 22 Merci de votre attention Questions? 23 conflit VPN - firewall « trafic sécurisé entre les zones « Intra » et « BD » » tunnel VPN entre les zones Intra et BD X 3. isakmp ? 24 Shadowing : On dit qu’une règle est masquée (shadowed) si la règle ne s’applique jamais parce que des règles ayant des priorités plus grandes sont toujours applicables. Redondance : On dit qu’une règle est redondante, si on peut la supprimer sans changer la décision de filtrage, quel que soit le paquet présenté en entrée du firewall. 25 26 accept deny