Jean-Luc Archimbaud CNRS/UREC ARCHITECTURE DE RESEAU SECURISEE avec filtrages http://www.urec.cnrs.fr/securite/articles/archi.reseau.pdf 24/3/2000 Jean-Luc Archimbaud CNRS/UREC

Rester totalement ouvert : inconscience L’Internet a changé … Réseau académique  LE réseau (universel) Nombre de machines connectées en France 1990 : 3 000 1994 : 70 000 1997 : 300 000 Fév 2000 : 1 264 027 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 : 10 - 98 : 20 - 99 : 100 - 01/2000 : 190 Nos réseaux et nos accès à Renater Conçus en 94-95 pour un Internet académique « familial » Rester totalement ouvert : inconscience

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é

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

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)

Architecture : schéma simplifié

Architecture : schéma détaillé

Architecture : filtres au point d’accès

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 …

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 : 30 000 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

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, …