Version 1.3 du 30/03/2004
EPITA SRS 2004 - Rush #1 : Avril 2004
Ce mini-rush de 3 jours a pour objectif de vous faire construire une architecture Internet complétée par un système de test de vulnérabilités et de détection d'attaque.
- Un environnement cible : un architecture Internet applicative typique comprenant au minimum 2 serveurs qui implémentent des serveurs classiques tels que Web, FTP, mail, de nom, de temps, etc.
- Un environnement d'attaque : il comprendra au minimum deux postes de travail configurés de façon à tester la sécurité de l'environnement cible
- Un environnement de détection : il comprendra les moyens de détecter les attaques visant l'environnement cible
Ce mini-rush commencera le
Jeudi 1er avril 2004 à 8h00 du matin et sera clos le
Dimanche 4 avril 2004 à 19h00.
Les 46 élèves de la promotion devront se répartir en 3 groupes de 15 ou 16 personnes. Dans chaque groupe, 3 équipes de 5 ou 6 personnes devront être créées :
- l'équipe "A" s'occupera de l'environnement d'Attaque
- l'équipe "C" s'occupera de l'environnement Cible
- l'équipe "D" s'occupera de l'environnement de Détection
Chaque équipe dispose d'un VLAN d'au maximum 6 ordinateurs. Chaque groupe dispose d'un routeur situé dans
les VLANs des trois équipes et assurant la jonction entre eux. De plus, les trois routeurs font eux-mêmes
partie d'un autre VLAN : il est donc possible de faire communiquer entre eux les trois groupes.
La disposition physique et logique des machines ainsi que les paramètres de connexion à l'extérieur
sont les seules contraintes qui vous sont imposées. En termes de plan d'adressage et de nommage, c'est à
vous de vous concerter et de vous organiser.
Les soutenances se dérouleront le
Lundi 5 avril 2004 de 8h00 à 18h00
Il vous est demandé de mettre en place au minimum 2 serveurs sous un système de type Unix.
- Sur le premier, vous effectuerez une installation par défaut d'une distribution Linux (RedHat ou Debian), avec les logiciels imposés ci-dessous, sans paramétrage sécurité particulier et sans application de correctifs supplémentaires.
- Sur le second, vous devrez fournir exactement les mêmes services et fonctionnalités apportés par le premier serveur, mais vous utiliserez les systèmes et logiciels que vous jugerez adéquats et appliquerez les patches et divers paramétrages de sécurité que vous jugerez nécessaires afin de garantir un niveau de sécurité que vous jugerez indispensable.
Vous devez fournir au minimum les
six premières applications réseaux mentionnées ci-dessous, puis les suivantes en fonction du temps dont vous disposerez :
- Serveur Web servant des pages HTML statiques, et dynamiques à base d'interface CGI. Le support dans le serveur de PHP, Perl, ou autre langage de génération dynamique de pages Web, est facultatif (mais un bonus).
Le logiciel imposé pour le premier serveur est : Apache (http://httpd.apache.org)
- Serveur DNS de contenu, répondant aux requêtes DNS itératives pour un domaine que vous choisirez et sous lequel l'ensemble de vos machines seront nommées.
Le logiciel imposé pour le premier serveur est : BIND (http://www.isc.org/index.pl?/sw/bind)
- Serveur de résolution DNS, répondant à toutes les requêtes DNS récursives effectuées par les machines de votre réseau.
Le logiciel imposé pour le premier serveur est : BIND (http://www.isc.org/index.pl?/sw/bind)
Notez que la même instance de BIND peut être utilisée pour ce service et le précédent.
- Serveur SMTP acceptant le courrier pour votre domaine, et pouvant servir de relais pour le courrier en provenance des machines de votre réseau.
Le logiciel imposé pour le premier serveur est : Sendmail (http://www.sendmail.org).
- Serveur POP3 permettant d'accéder de l'extérieur aux boîtes aux lettres de votre domaine.
Le logiciel imposé pour le premier serveur est : QPopper (http://www.eudora.com/qpopper)
- Serveur FTP anonyme. Logiciel imposé pour le premier serveur : WU-FTP (http://www.wu-ftpd.org)
- Serveur FTP non anonyme. Logiciel recommandé : WU-FTP (http://www.wu-ftpd.org)
- Serveur NTP. (Pas de logiciel imposé)
- Serveur SSH version 2. (http://www.openssh.org).
La documentation que vous rédigerez indiquera de façon claire toutes les origines et les versions des logiciels et des composants que vous aurez installés.
Votre objectif est donc de mettre en œuvre une configuration opérationnelle, l'une étant sécurisée et devant résister aux attaques, et l'autre servant de
machine témoin.
Il vous est demandé de mettre en place au minimum 2 machines sous un système de type Unix.
- Sur la première, vous effectuerez une installation par défaut d'une distribution Linux, sans paramétrage sécurité particulier et sans application de correctifs supplémentaires. Vous installerez uniquement les outils mentionnés.
- Sur la seconde, vous appliquerez au système de votre choix tous les correctifs et paramétrages de sécurité que vous jugerez nécessaires afin de garantir un niveau de service que vous jugerez indispensable. Vous installerez, en plus des outils mentionnés, les logiciels de votre choix.
Vous devez installer au minimum les
deux premières applications mentionnées ci-dessous, ainsi que les suivantes en fonction du temps dont vous disposerez :
- Le logiciel de test de vulnérabilités : Nessus (http://www.nessus.org)
- Le logiciel de test de vulnérabilités : Nikto (http://www.cirt.net/code/nikto.shtml)
- Le logiciel de test de vulnérabilités : NMap (http://www.insecure.org/nmap)
- Le logiciel de test de vulnérabilités : SPIKE Proxy (http://www.immunitysec.com/spikeproxy.html)
Il vous est demandé de mettre en place au minimum 2 machines sous un système de type Unix.
- Sur la première, vous effectuerez une installation par défaut d'une distribution Linux, sans paramétrage sécurité particulier et sans application de correctifs supplémentaires. Vous installerez uniquement les outils mentionnés.
- Sur la seconde, vous appliquerez au système de votre choix tous les correctifs et paramétrages de sécurité que vous jugerez nécessaires afin de garantir un niveau de service que vous jugerez indispensable. Vous installerez, en plus des outils mentionnés, les logiciels de votre choix.
Vous devez installer au minimum les
trois premières applications mentionnées ci-dessous, ainsi que les suivantes en fonction du temps dont vous disposerez :
- Le logiciel de détection d'attaques : Snort (http://www.snort.org)
- Le logiciel d'amélioration de Snort : IDS Alert Verification (http://www.cs.ucsb.edu/~wkr/projects/ids_alert_verification/
- Le logiciel d'analyse de trames : tcpdump (http://www.tcpdump.org)
- Le logiciel de type pot de miel : Honeyd (http://www.citi.umich.edu/u/provos/honeyd)
- Le logiciel d'analyse : Dsniff (http://naughty.monkey.org/~dugsong/dsniff)
- Le logiciel d'analyse : Ettercap (http://ettercap.sourceforge.net)
S'il vous reste du temps, il vous est demandé de compléter l'architecture existante en implémentant le logiciel suivant :
Afin de faciliter l'installation et la mise en œuvre, il vous est demandé de les réaliser sur un serveur sous Linux Debian.
Il s'agit donc d'un travail complet analogue à ce qui vous sera demandé au cours de votre vie professionnelle : organisation, réalisation technique et documentation.
À l'issue de ce rush, chaque équipe remettra deux éléments :
- Une documentation au format électronique (le format HTML est recommandé, les format texte, Postscript ou PDF sont acceptés) décrivant le résultat obtenu et toutes les informations jugées nécessaires à une bonne compréhension du travail effectué.
Dans cette documentation, vous pourrez intégrer le détail des paramétrages requis pour arriver à une configuration opérationnelle, les éventuelles instructions de compilation, d'installation, d'application de patches...
- Une image électronique sous forme d'un CDROM de chaque machine nécessaire à la constitution de chacun des environnements. Elle devra permettre de reconstituer l'environnement complet en moins de 1 heure sur un système vierge.
Lors des soutenances, le premier critère d'appréciation du travail réalisé consistera en la vérification de l'intégration de la configuration réalisée. Il vous sera ainsi demandé d'insérer le(s) CDROM dans des PC non configuré(s) et de montrer comment parvenir à la configuration opérationnelle en un minimum de temps et surtout en un minimum d'actions et d'opérations manuelles.
Lors de ces soutenances, il sera demandé à l'équipe "A" de lancer les outils mis en place contre les cibles de l'équipe "C" avec les outils mis en place par l'équipe "D" en écoute sur le réseau mis en place.
- Sera mesurée pour l'équipe "A" :
- sa capacité à faire fonctionner correctement les outils d'attaque mis en place
- sa capacité à faire mettre en évidence d'éventuelles vulnérabilités sur les autres machines (dont les machines avec installation par défaut)
- sa capacité à présenter de façon claire et compréhensible les éventuelles vulnérabilités détectées sur les autres machines
- Sera mesurée pour l'équipe "C" :
- sa capacité à faire fonctionner correctement les outils mis en place
- sa capacité à résister aux attaques sur, au minimum, la configuration sécurisée
- sa capacité à journaliser les attaques reçues sur, au minimum, la configuration sécurisée
- Sera mesurée pour l'équipe "D" :
- sa capacité à faire fonctionner correctement les outils de détection et d'analyse mis en place
- sa capacité à détecter et/ou à interpréter les attaques lancées par les outils de l'équipe "A"
- sa capacité à journaliser les attaques détectées et à les corréler
- Sera mesurée pour ceux ayant participé à la mise en œuvre du logiciel OSSIM :
- la capacité à faire fonctionner correctement le logiciel
- la capacité à expliquer le fonctionnement et la configuration du logiciel
- la capacité à démontrer de façon concrète ce qu'il peut apporter dans la configuration
Pour finir, la lecture de la documentation permettra de mesurer le niveau de finition de la configuration réalisée lors du rush.
- La maîtrise de la langue est fondamentale. Faites attention à votre orthographe, votre grammaire et votre style : cela peut soit vous rapporter quelques points supplémentaires soit vous en enlever beaucoup plus si votre documentation est pénible à lire et truffée de "fôte d'ortograf" (sic) ...
- De mauvais paramétrages ou de mauvais choix documentés valent mieux que de bons paramétrages, de bonnes implémentations et de bon choix non documentés.
- Ce qui sera utilisé comme référence n'est pas votre implémentation sur les machines, mais le contenu de vos CDROM et votre documentation. Si votre implémentation s'écarte de ce que vous avez rédigé ou gravé, c'est un bug. Prenez-y garde.
- En cas de difficulté d'implémentation, ne restez pas bloqué : faites des recherches sur Internet, consultez vos collègues, ... et en dernier ressort, expliquez et documentez vos problèmes.
- Une implémentation qui marche presque est une implémentation qui ne marche pas du tout, et qui sera notée comme telle, sans tenir compte de la quantité de travail fournie. Seul le résultat final et sa documentation comptent.
- Vous diposez de suffisamment de temps pour réaliser ce rush dans de bonnes conditions et rédiger une documentation. Tout travail bâclé sera noté sans indulgence. Mettez à profit le temps dont vous disposez et rédigez la documentation en parallèle ; n'attendez pas la dernière minute pour commencer à la rédiger.
Bon Rush !