Jean-Luc Archimbaud CNRS/UREC

Présentation au sujet: "Jean-Luc Archimbaud CNRS/UREC"— Transcription de la présentation:

1 Jean-Luc Archimbaud CNRS/UREC
ARCHITECTURE DE RESEAU SECURISEE avec filtrages /3/2000 Jean-Luc Archimbaud CNRS/UREC

2 Rester totalement ouvert : inconscience
L’Internet a changé … Réseau académique  LE réseau (universel) Nombre de machines connectées en France 1990 : 1994 : 1997 : Fév 2000 : De plus en plus de problèmes de sécurité Equipes sécurité CERT-Renater ½ p -> 4 p UREC ½ p -> 2 p ½ Nombre mensuel d’incidents traités par le CERT-Renater 97 : : : /2000 : 190 Nos réseaux et nos accès à Renater Conçus en pour un Internet académique « familial » Rester totalement ouvert : inconscience

3 Les systèmes n’ont pas changés …
Les Windows (NT …) ne sont pas mieux qu’Unix (pour la sécurité) Tous les systèmes ont des bogues (de sécurité) 1/1 – 24/3/00 : CERT-Renater 45 vulnérabilités et 6 alertes Ils sont toujours livrés ouverts par défaut Avec des démons ou services réseaux actifs et inutiles qui sont autant de points d’attaques Les administrateurs doivent « faire le ménage » De plus en plus de stations dans les labos / campus On ne peut pas maintenir la totalité de son parc informatique sans trou de sécurité

4 Outil classique d’attaque sur Internet
1. Scan d’un réseau pour découvrir les stations 2. Vérification des versions des démons et services réseaux démarrés 3. Attaque des versions avec des trous de sécurité 4. Passage en mode administrateur Enregistrement de nouveaux utilisateurs Modification des exécutables : portes dérobées Installation de sniffers : récupération de mots de passe Installation de zombies, agents, … : dénis de service Protection : Bloquer ou limiter la portée des étapes 2 et 3

5 Architecture d’un site : principes
Segmentation du réseau avec des routeurs Entrée de site : zone semi-ouverte Serveurs réseau Un segment (ou VLAN …) par laboratoire / service / … Filtres entre les segments Flux des applications : contrôles Dans le sens sortant : peu de limitations : toutes les stations peuvent être clientes (sauf étudiants ?) Dans le sens entrant : Tout interdire par défaut Ne laisser passer que les applications utilisées vers des serveurs identifiées et bien administrées Où (mettre des filtres) ? En entrée de site Entre segment (laboratoires ou services)

6 Architecture : schéma simplifié

7 Architecture : schéma détaillé

8 Architecture : filtres au point d’accès

9 Bénéfices de l’architecture
L’attaque décrite avant Ne testera que les services de la zone semi-ouverte Ne pourra pas attaquer Les démons sendmail … des Unix internes Les services ou les chevaux de Troie NT Administration des stations Internes (très nombreuses) : laxisme tolérable Zone semi-ouverte (une poignée) : avec beaucoup de soin Chgt version, correctifs, gestion utilisateurs, … Evolutions possibles sans remise en cause de l’architecture : Nouveau service réseau Garde-barrière applicatif …

10 Alternatives à cette architecture
Pourquoi pas ? Avantages : Oblige à faire un inventaire des services utiles Rend inaccessibles les stations clientes Mais si bon inventaire et bon filtrage en place NAT n’apporte pas de fonction de sécurité supplémentaire Garde-barrière applicatif Goulot d’étranglement en débit Coût : il faut l’acheter et l’administrer CNRS = 1300 laboratoires : Matériel : F x 1300 = 190 MF ? Personnel : 1300 ITA ? Mais solution envisageable sur certains sites Petites entités sans serveur Internet Adressage local - privé Proxy : messagerie – Web

11 Mise en place de l’architecture
C’est un modèle à adapter On peut ouvrir quand besoin particulier Où ? Porte du campus – de l’université – de l’UFR – du laboratoire ? Définir une méthodologie pour la définition et la mise en place : concertation obligatoire avec les utilisateurs et les administrateurs Ce modèle ne restreint pas l’utilisation de l’Internet Un utilisateur a les mêmes services qu’avant Il faut ensuite un suivi : journaux, …