Expression, analyse et déploiement de politiques de sécurité - Application réseau - Frédéric Cuppens Nora Cuppens-Boulahia
Le contexte actuel Nombreux outils permettant de réaliser automatiquement des attaques Trinoo, Stacheldraht Blaster, Slammer, Sacer, Attaques contre la disponibilité (déni de service) Environ, un millier de nouvelles vulnérabilités découvertes chaque année dans les environnements Internet Listes diffusant des informations sur les vulnérabilités et incidents CERT Advisory, Rootshell, Bugtrack Sites constructeurs (SUN, HP, Mircrosoft, ) Augmentation régulière du trafic sur ces listes 2
Contexte actuel Les mêmes vulnérabilités apparaissent (ou réapparaissent) dans tous les systèmes Vulnérabilités dans le code Pile TCP/IP (Ping of Death) Erreurs d installation et de configuration Les besoins utilisateur priment sur la sécurité Courrier (traverse les gardes-barrière) chevaux de Troie, échange de virus (Word) Intercommunications Internet Explorer, Active X Chiffrement faible pour raisons de performance et/ou de législation gouvernementale Voir problème du chiffrement utilisé dans les GSM et les DVD 3
Faiblesses au niveau applicatif : Exemples Elgg Logiciel de réseau social open source Plus de 100 points de contrôle avant l accès à la base de données De nombreuses vulnérabilités CSRF (Cross-Site Request Forgery) phpmyadmin Une application web PHP pour la gestion des Base de données MySQL Plus de 1000 points de contrôle Plus de 60 vulnérabilités en raison de l oubli de certains de ces points de contrôle XSS (Cross Site Scripting), Injection de code, redirection, 4
Faiblesses au niveau réseau : Exemple Flooding ICMP : Smurfing Existence d une adresse «broadcast» en xxx.xxx.xxx.255 ECHO REQUEST de la victime vers 192.168.0.255 Envoi d un message «echo request» forgé avec l adresse de la victime (spoofing) Attaquant Internet Des centaines de messages «echo reply» envoyés à la victime ECHO REPLY de ECHO 192.168.0.20 REPLY vers de ECHO 192.168.0.20 REPLY la victime vers de ECHO 192.168.0.20 REPLY la victime vers de ECHO 192.168.0.20 REPLY la victime vers de ECHO 192.168.0.20 REPLY la victime vers de 192.168.0.20 la victime vers la victime Victime 5
Problématique L administration des politiques de sécurité est une tâche complexe Risque d erreurs Exploitation de vulnérabilités 6
Problématique 7
Démarche Deux stratégies complémentaires (1) Déploiement automatique de politiques de sécurité (top-down) (2) Analyse et réécriture des configurations déployées (bottom-up) 8
Démarche Politique de sécurité (1) Déploiement automatique de politiques de sécurité (top-down) SGBD Firewall zonei NIDS OS HIDS 9
Démarche (2) Analyse et réécriture des configurations déployées (bottom-up) 10
Déploiement automatique des politiques de sécurité 11
Politique de sécurité réseau : Déploiement : Déploiement Nous disposons de Un ensemble de composants, PEP Une politique sécurité de sécurité De stratégies de gestion de conflits Nous souhaitons Déployer la politique sur les PEP Concevoir un PDP «intelligent» Deux cas Signatures détection d intrusions Politique de organisationnelle Politique de sécurité réseau Architectures simples Les PEP sont identifiés et désignés par l administrateur Architectures plus complexes Règles de firewall Autres composants Autres Politiques dérivées Plusieurs PEP avec fonctionnalités différentes ou équivalentes Difficultés : quelles règles sur quels PEP Autres composants 12
Déploiement : concepts de base Deux modes de déploiement entre les PDP et les PEP Provisioning : le PDP «pousse» la politique vers le PEP Outsourcing : lorsque le PEP reçoit une requête d accès, il contacte le PDP qui prend la décision. Le PEP applique ensuite la décision Les expérimentations montrent que le mode provisioning Donne en général de meilleures performances que le mode outsourcing Dans la suite, on va s intéresser au déploiement en mode provisioning 13
Déploiement réseau : l Existant Plateforme mono constructeur CheckPoint SmartCenter CiscoWorks LAN Management Solution Plateforme mutli constructeur Firewall Builder IBM Proventia endpoint secure control Juniper Network and Security Manager, LogLogic Security Change Manager (ex Solsoft NetPartionner) Tuffin SecureTrack et SecureChange Bilan de l existant Aide à pousser les règles avec interfaces conviviales Automatisation partielle Règles de bas niveau / Pas de politique globale Pas de garantie que le déploiement est correct 14
Raffinement de politiques Politique formalisée dans le modèle OrBAC Permission d un rôle de réaliser un activité sur une vue Permission d un sujet d exécuter une action sur un objet role activity view Organization Dans un certain contexte subject action object 15
Raffinement de politiques Politique formalisée dans le modèle OrBAC subjects : local host, subnetwork, server actions : http, ssh, ftp objects : messages, IP packets role activity view Organization Dans un certain contexte subject action object 16
Déploiement : Une politique d accès réseau OrBACisée Spécifier les organisations en charge de gérer la politique réseau Dns_Server Admin-Server DMZ DM Z Web_Server Intranet Internet DMZ Private 17
Déploiement : Une politique d accès réseau OrBACisée Spécifier les permissions Exemple Dans «Corporate network», «Intranet hosts» peut envoyer des «web requests» to «Internet hosts» Permission ( Corporate, Intranet, Web_HTTP, To_Internet) 18
Déploiement : Le processus Network Security policy XML XSLT Generic firewall rules XML XSLT... Checkpoint rules PIX rules NetFilter rules IpFilter rules... 19
Déploiement : Le processus 20
Déploiement : Cas des architectures complexes Besoin de données topologiques Zones : ensembles de machines d un sous réseau et interfaces de composants de sécurité Fonctionnalités de sécurité offertes Voisinage Détermination du chemin de déploiement Pour chacune des règles ou package de règles Zone source, zone destination Composants de sécurité récepteurs 21
Déploiement : Cas des architectures complexes Déploiement de politiques contextuelles Les PEPs ne disposent pas toujours des fonctionnalités nécessaires pour gérer certains contextes Solution La gestion du contexte est confiée au PDP Le PDP gère l activation et la désactivation du contexte Le PDP redéploye la politique lorsque le contexte change 22
Déploiement de politiques contextuelles : Application 23
Déploiement de politiques contextuelles : Application Default Requirements The OrBAC policy R1 Permisssion(R_Intra, rw_mail, multi-serv, default) R2 Permisssion(R_MultiServ, w_mail, Internet, default) The email services are accessible from the Intra zone R3 Permisssion(R_Internet, w_mail, multi-serv, The email server activates the smtp default) service to the Internet The DNS service is accessible R4 from Permisssion(R_Corporate, all zones dns, dnsserv, default) The icmp traffic is allowed R5in the Permisssion(R_Internet, Corporate (Corp) zonesdns, dnsserv, default) The PDP activates the Netconf R6 service Permisssion(R_DNS, with the PEPs dns, Internet, default) The Administration may access R7 Permisssion(R_Corporate, the PEPs via ssh icmp, Corp, default) R8 Permisssion(R_Corporate, icmp, Internet, default) R9 R10 Contextual Requirements Permisssion(R_PDP, netconf, PEP, default) All Intra BackUP Site TCP traffic is protected Permisssion(R_Admin, ssh, PEP, default) R11 Permisssion(R_Admin, During w.h., TCP TCP, traffic Internet, is allowed default) from Intra to Internet R12 Permisssion(R_PEP, The pop, imap ssh, and Admin, smtp are default) accessible from the Invited zone R13 Permisssion(R_Intra, These services TCP, are blocked BkUp, protected) after 3 failed logins (3.l.f) R14 Permisssion(R_Intra, The IDS detects TCP, the Internet, syn-flooding w.h.) attacks and alerts the PDP R15 Permisssion(R_Invited, The web server is rw_mail, public if multi-serv, no syn-flooding!(3.l.f))(s.f.) is detected R16 Permisssion(R_IDS, alert, PDP, syn-flooding) R17 Permisssion(R_Internet, WEB, multi-serv,!(s.f.)) 24
Déploiement de politiques contextuelles : Protocole de communication PDP PEP Netconf : http://www.ops.ietf.org/netconf/ YencaP : http://ensuite.sourceforge.net/ Modules Netconf «stand alone» Proof of concept : module Netfilter pour gérer des contextes temporels time option: -m time datestart $date1 datestop $date2 Cas 1 : Gestion du contexte temporel par le PDP Cas 2 : Gestion du contexte temporel par le PEP 25
Déploiement de politiques contextuelles : Validation et application Utilisation de la méthode B Spécification du déploiement Expression et preuve d invariants Détection des fonctionnalités manquantes Application Confinement de services Délégation sécurisée de service dans les réseaux domestiques IPV6 26
Détection des anomalies et des redondances
Analyse : Anomalies dans la politique déployée Politique de sécurité du système à protéger Déploiement sur les différents composants de sécurité Approche correcte par construction Processus de raffinement Approche basée sur l expertise de l administrateur de sécurité Processus de vérification a posteriori Besoin de combiner l approche raffinement avec une approche analytique 28
Analyse : Anomalies dans la politique déployée Analyser les configurations existantes Deux problèmes différents Analyse intra composant Détecter les anomalies dans la configuration d un composant Analyse inter composant Détecter les conflits entre configurations de composants différents Objectif Méthode générale pour analyser différents types de composants Firewall, VPN, IDS, IPS 29
Analyse intra-composants Risque de conflit entre règles avec des décisions différentes s appliquant sur le même flux Approche «classique» Conflit résolu en ordonnant les règles «First matching» Mais des problèmes subsistent Redondance (redundancy) La règle r est redondante si l on peut supprimer r sans changer la décision de filtrage Masquage (shadowing) La règle r est masquée si la règle r n est jamais appliquée 30
Analyse intra-composants Analyse complète par réécriture Principe Réécriture des règles Élimination des recouvrements entre règles Après application de l algorithme, les règles sont 2 à 2 indépendantes 31
Analyse inter-composants Principe de l algorithme Modélisation du réseau Zones, voisin, chemin, premier composant, dernier composant, type de composant et route minimale Analyse complète par corrélation Exemple simplifié Soit r une règle de filtrage entre une zone source s et une zone destination d source s... dest d FW 1 FW 2 FW n 33
Analyse inter-composants Cas 1 : decision(r) = accept Règle r source s... dest d FW 1 FW 2 FW n Cas 2 : decision(r) = deny Règle r La redondance est peut être souhaitée?!!! source s... FW 1 FW 2 FW n dest d 34
Taxonomie des anomalies détectées Anomalies Intra-firewall Inter-firewall Shadowing Shadowing Redundancy Redundancy Irrelevance Misconnection 35
Irrelevance E1 C1 C6 E2 200.160.[1,2].0/24 10.0.[24,25,27].0/24 P2 192.170.[21,22,23].0/24 C3 C4 C2 10.0.16.0/24 10.0.[26,28].0/24 P5 P1 P4 10.0.[31,32,33].0/24 10.0.[34,35,36].0/24 P3 C5 36
Conclusion / Perspectives
Conclusion / Perspectives Analyse d anomalies Expérimentation de Mirage Architecture réelle (1000+ firewalls, 300+ règles par firewall) Extension aux firewalls stateful Fermer la boucle top down / bottom up Outils de role mining Dérivation de la politique globale à partir des configurations déployées Agrégation de permissions et génération de rôles 38
Projet Scientifique Administration Politique de Sécurité Gestion Conflits Analyse de Risques Réaction Réflexe Détection d Intrusions Déploiement Gestion Anomalies Architecture de Sécurité Le Système Anomalies MAJ Attaques 39