Conception et r

1
Conception et réalisation dune architecture
tolérant les intrusions pour des serveurs Internet

• Ayda Saidane, Yves Deswarte, Vincent Nicomette
• Tolérance aux fautes et Sûreté de Fonctionnement
  informatique
• LAAS-CNRS
• Projet DIT (Programme DARPA OASIS)

2
Internet un réseau ouvert

• Environnement hétérogène
• Différents types dutilisations dInternet
  Commerciales (B2C), professionnelles (B2B),
  administratives (B2A, C2A, e-Gov), sociales,
  culturelles,
• Toutes ces utilisations sont légitimes
• Tout le monde n a pas les mêmes besoins de
  sécurité
• gt Beaucoup de systèmes mal administrés

• Attaques de plus en plus efficaces
• Des attaques de grande envergure en un
  minimum de temps
• le ver Slammer (2003) ? 6 mois après
  lannonce de la vulnérabilité
• le ver Witty (2004) ? 24 heures après
  lannonce de la vulnérabilité

3
Connexion des systèmes critiques à Internet

• Approches classiques insuffisantes
• Renforcer l'authentification et l'autorisation ?
  inapplicable pour des serveurs accessibles au
  public
• Inefficaces contre les vulnérabilités ?
  correction ("patches")
• Les systèmes sont trop complexes
• Fonctionnalités standard
• Utilisation des COTS
• Rentabilité/sécurité

Objectif ? Des systèmes capables de fournir
le service pendant les attaques
4
Systèmes cibles

• Serveurs publiant des informations critiques
• Propriétés critiques intégrité, disponibilité
• Les données ne sont pas très confidentielles

• Par exemple
• Serveur publiant des alertes de sécurité
• Fortes exigences en intégrité et disponibilité
• Informations rarement mises à jour
• Les mises à jours peuvent être faites hors-ligne
• Serveur dune agence de voyage sur Internet
• Fortes exigences en intégrité et disponibilité
• Système très dynamique
• ? Les mises à jour doivent être faites en temps
  réel

5
Objectifs

• Concevoir un serveur Internet tolérant aux
  intrusions à base de COTS 
• Fournir un bon compromis performance/sécurité
• Assurer, en permanence, lintégrité et la
  disponibilité des données 

6
Caractéristiques des attaques

• Contrairement aux fautes accidentelles
• Les attaques ne sont pas indépendantes
• Leur distribution nest pas uniforme dans le
  temps
• Les attaques visent des vulnérabilités
  spécifiques à un système .exploitation, un
  logiciel d'application ou une plateforme
  matérielle

7
Un serveur tolérant les intrusions Comportement
en cas dattaques Mise en œuvre et mesures de
performances Bilan et perspectives
8
Un serveur tolérant les intrusions
Internet

• Diversification
• . Matériel
• . OS
• . Logiciel

9
Un serveur tolérant les intrusions

• Diversification
• Mandataires

• Surveillance mutuelle
• Surveillance des serveurs dapplication

• Gestion des alertes

10
Un serveur tolérant les intrusions
Meneur

1. Diversification
2. Mandataires
3. Mécanismes de détection

• Protocole daccord (PA)

11
Un serveur tolérant les intrusions

1. Diversification
2. Mandataires
3. Mécanismes de détection

• Protocole daccord (PA)

• Détection dintrusion (IDS)

12
Un serveur tolérant les intrusions
R H(DéfiFichier) / H  fonction de hachage
Comparaison avec réponse pré-calculée

1. Diversification
2. Mandataires
3. Mécanismes de détection

• Protocole daccord (PA)

• Détection dintrusion (IDS)

• Protocole de Défi-Réponse

13
Un serveur tolérant les intrusions

1. Diversification
2. Mandataires
3. Mécanismes de détection

• Protocole daccord (PA)

• Détection dintrusion (IDS)

• Protocole de défi-réponse

• Vérification de modèle en ligne

14
Un serveur tolérant les intrusions

1. Diversification
2. Mandataires
3. Mécanismes de détection
4. Gestionnaire des alertes (G.A)

15
Un serveur tolérant les intrusions
Gestionnaire dalertes
G.A
Moniteur du protocole
daccord
Protocole daccord
Moniteur PDR
Gestionnaire de
Vérifieur en ligne
la politique de
tolérance
G.A
Moniteur SNORT
Moniteur EMERALD
Exécuteur
Changement de rôle
Autres Moniteurs
G.A

1. Diversification
2. Mandataires
3. Mécanismes de détection
4. Gestionnaire des alertes (G.A)

16
Un serveur tolérant les intrusions
Meneur

• Diversification
• Mandataires
• Mécanismes de détection
• Gestionnaire des alertes (G.A)

1. Régimes de fonctionnement

• Simplex, duplex, triple redondance

17
Un serveur tolérant les intrusions
Meneur

1. Diversification
2. Mandataires
3. Mécanismes de détection
4. Gestionnaire des alertes (G.A)

1. Régimes de fonctionnement

• Simplex, duplex, triple redondance

18
Un serveur tolérant les intrusions
Triple redondance
Meneur

1. Diversification
2. Mandataires
3. Mécanismes de détection
4. Gestionnaire des alertes (G.A)

1. Régimes de fonctionnement

• Simplex, duplex, triple redondance

19
Un serveur tolérant les intrusions
SGBD TaF
Adjudicateur
Meneur

1. Diversification
2. Mandataires
3. Mécanismes de détection
4. Gestionnaire des alertes (G.A)

1. Régimes de fonctionnement
2. Gestion des données dynamiques

20
Un serveur tolérant les intrusions
SGBD TaF
Médiateur
Adjudicateur
Meneur
Médiateur
Médiateur

1. Diversification
2. Mandataires
3. Mécanismes de détection
4. Gestionnaire des alertes (G.A)

Médiateur

1. Régimes de fonctionnement
2. Gestion des données dynamiques

21
Un serveur tolérant les intrusions
Adjudicateur
Mandataire
Meneur
auxiliaire
Messages de contrôle
Messages de contrôle
Médiateur
Médiateur
Médiateur
diateur
diateur
diateur
1
2
3
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur de bases de données tolérant aux fautes
COTS
COTS
COTS
COTS
COTS
COTS
22
Un serveur tolérant les intrusions
Adjudicateur
Mandataire
Meneur
auxiliaire
Messages de contrôle
Messages de contrôle
Médiateur
Médiateur
Médiateur
diateur
diateur
diateur
1
2
3
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur de bases de données tolérant aux fautes
COTS
COTS
COTS
COTS
COTS
COTS
23
Un serveur tolérant les intrusions
Adjudicateur
Mandataire
Meneur
auxiliaire
Médiateur
Médiateur
Médiateur
diateur
diateur
diateur
1
2
3
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur de bases de données tolérant aux fautes
COTS
COTS
COTS
COTS
COTS
COTS
24
Objectifs Un serveur tolérant les
intrusions Comportement en cas dattaques Mise en
œuvre et mesures de performances Bilan et
perspectives
25
Comportement en cas dattaques

• Quelle est le composant ciblé par lattaque ?
• Mandataires
• Serveurs dapplication ou
• Base de données

26
Attaque contre les mandataires

• Mécanismes de prévention
• Des techniques de développement de logiciels
  critiques sont utilisés pour le développement des
  codes des mandataires
• Système dexploitation  allégé 
• Un seul mandataire accessible de lextérieur
• Pare-feu
• Mécanismes de tolérance
• Mécanismes de détection diversifiés
• Les mandataires se surveillent mutuellement

27
Attaque contre les serveurs dapplication

• Mécanismes de prévention
• Les types et nombre de serveurs répondants à une
  requête donnée sont inconnus
• Le Meneur rejette les requêtes suspectes
• Mécanismes de tolérance
• Lattaque ne peut réussir que sur une petite
  minorité (1 seul) des serveurs (diversification
  matériel/OS/logiciel)
• Les mécanismes de détection diversifiés

28
Attaque contre la base de données

• Mécanismes de prévention
• Pas daccès direct à la base de données
• Bibliothèque spécifique daccès à la base de
  données
• Vérification syntaxique sur le Médiateur/Adjudicat
  eur
• Mécanismes de tolérance
• Base de données tolérante aux fautes
  accidentelles
• Protocole daccord sur lAdjudicateur
• Recouvrement dun Adjudicateur corrompu

29
Recouvrement dune intrusion

• Recouvrement du Meneur ou de lAdjudicateur
• Élection dun nouveau Meneur/Adjudicateur
• Redémarrage du Meneur/Adjudicateur corrompu
• Si ladjudicateur est corrompu, défaire les
  dernières modifications sur la base de données
• Recouvrement dun mandataire auxiliaire
• Redémarrage du mandataire corrompu
• Recouvrement dun serveur dapplication
• Redémarrage du serveur corrompu
• Renvoi des requêtes en cours à dautres serveurs
  (si besoin)

30
Objectifs Un serveur tolérant les
intrusions Comportement en cas dattaques Mise en
œuvre et mesures de performances Bilan et
perspectives
31
Plateforme expérimentale
32
Première mesureTemps de traitement dune requête
sans accès à la base de données

1. Fichier html 0 Octet
2. Fichier html 44 KO
3. Fichier html 1 MO

33
Première mesureTemps de traitement dune requête
sans accès à la base de données

1. Fichier html 0 Octet
2. Fichier html 44 KO
3. Fichier html 1 MO

34
Première mesureTemps de traitement dune requête
sans accès à la base de données
35
Deuxième mesureTemps de traitement dune requête
avec accès à la base de données
36
Deuxième mesureTemps de traitement dune requête
avec accès à la base de données
37
Deuxième mesureTemps de traitement dune requête
avec accès à la base de données
38
Troisième mesureTemps de réponse à une alerte
avec redémarrage du serveur corrompu
39
Troisième mesureTemps de réponse à une alerte
avec redémarrage du serveur corrompu
FIN
40
Troisième mesureTemps de réponse à une alerte
avec redémarrage du serveur corrompu
41
Objectifs Un serveur tolérant les
intrusions Comportement en cas dattaques Mise en
œuvre et mesures de performances Bilan et
perspectives
42
Bilan

• Une architecture générique tolérant les
  intrusions, répondant à trois
• exigences fixées au préalable  
• utilisation des composants COTS
• assurer lintégrité des réponses et
  disponibilité du service, même pendant les
  attaques
• un bon compromis entre sécurité et performances.

• Intégration de différentes techniques de
  prévention, détection et
  . tolérance pour les fautes accidentelles les
  malveillances
• Redondance avec diversification / Niveau de
  redondance variable
• Gestion des alertes de différents niveaux de
  crédibilité
• Un protocole de défi-réponse pour lintégrité
  de serveurs distants
• Performances prometteuses

43
Perspectives

• Evaluation de la généricité de larchitecture
• Application de larchitecture à dautres services
• Application de l'architecture à des systèmes de
  très grande taille
• Evaluer les limites de l'architecture de point de
  vue robustesse et performance
• Évaluation quantitative et expérimentale de la
  sécurité
• Des expérimentations plus poussées pour les
  mesures de performances
• Validation formelle du déterminisme