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