Documentation technique groupe rush A

Documentation groupe rush A: Description du système cible

Présentation de l'environnement cible

Les systèmes de base consistent en:
  1. Securisé: Debian 3.0r1 2.4.25 + grsec
  2. Non-Securisé: Debian 3.0r1 2.4.18-bf24
Le système d'exploitation choisi pour les deux machines est la distribution Linux [debian.org] Debian, dont la version utilisee est la 3.0r1 La première étape a été d'installer le système de base, c'est a dire un kernel et les outils systèmes linux de base.

Par défaut, le kernel installé est un 2.4.18-bf24. Pour la machine témoin nous n'avons pas modifié ce kernel bien qu'il contienne de nombreuses failles de securité connues et exploitables à ce jour.
Note: les initiales bf dans le numéro de version signifient que ce kernel est identique à celui des disquettes de boot. (boot floppies)
En revanche, sur la machine a securisée, nous avons opté pour la dernière version du kernel de la branche des 2.4 à savoir le 2.4.25. Ce choix a été notamment motivé par le fait que le patch [grsecurity.net] grsecurity pour les kernels 2.6 n'est pas encore totalement finalisé. Ce patch kernel rajoute de nombreuses options destinées a renforcer la sécurité du système. Parmis elles l'impossibilité de se logger en root en dehors de la console locale et la création d'un certain nombre de groupes permettant d'imposer des restrictions. De plus, nous avons inclu dans ce nouveau kernel, les options supplémentaires permettant de mettre en place un firewall basé sur iptables. L'ensemble des packages de base a été mis à jour par le système de gestion des packages debian apt, afin de disposer des dernières versions de ceux-ci. Par défaut debian installe les correctifs de sécurité pour les packages présents sur le système. Sur la machine sécurisée, nous avons procédé a une vérification de la signature de chaque package à installer grâce au script apt-check-sigs afin de s'assurer de l'intégrité et de l'authenticité des paquets.

Installation des divers services demandes:

Serveur Web:

  1. Securisé: Apache 1.3.26-0woody3 + php 4.1.2-6woody3
  2. Non-Securisé: Apache 1.3.26-0woody3 + php 4.1.2-6woody3
Le logiciel imposé sur la machine non-securisée est apache. Apache étant reconnu pour sa stabilité et sa facilité d'intégration avec php, nous avons réitéré ce choix sur la machine securisée. La version utilisée sur les deux machines est celle présente dans la version debian stable à savoir 1.3.26-0woody3. Ceci n'est pas la derniere version d'apache, mais des patchs ont ete appliqués par l'équipe de securité debian, afin de corriger les failles présentes dans la version de base. Afin de rendre plus difficile la détection de la version par d'éventuels attaquants, la signature du serveur a été retirée. La seule information que l'on peut obtenir est le nom du serveur utilisé : Apache. Pour la generation des pages dynamiques, PHP et CGI sont disponibles. La version de php integrée a apache est la 4.1.2-6woody3, que nous avons installé en module dans les deux cas.

Serveur DNS:

  1. Secure: BIND 9.2.1-2.woody.1
  2. Non-Secure: BIND 9.2.1-2.woody.1
Pour le service DNS, le choix s'est porté sur Bind9. En effet, ce serveur possède de nombreuses fonctionnalités utiles pour le travail à effectuer, comme la création de zones. Pour l'occasion, nous avons créé un domaine sous lequel nous avons adressé nos machines : rush.epita.fr. On pourra donc repérer les différents éléments de notre architecture. Par convention, les noms des machines témoin sont préfixés par n-. La liste des machines est la suivante :
  1. adm.rush.epita.fr et n-adm.rush.epita.fr sont les deux machines "cibles" des attaques.
  2. ids.rush.epita.fr et n-ids.rush.epita.fr sont les deux IDS.
  3. attack-1.rush.epita.fr et attack-2.rush.epita.fr sont les attaquants.
Les machines locales (192.168/24) possèdent également des reverse. Afin de garder une cohérence dans le DNS et faciliter les mises à jour, la machine 'adm' est master pour la zone 'rush.epita.fr', et 'n-adm' fait office de DNS secondaire. N'ayant pas d'accès direct externes, les requêtes auxquelles nous n'auront pas pu répondre sont transmises au serveur dns de l'epita (10.42.6.6) Concernant les fonctionnalités demandées, nous avons créé 2 zones :
  1. une zone interne, pour laquelle le serveur servira de cache DNS et répondra aux requêtes des clients du réseau local.
  2. une zone externe, pour laquelle le serveur répondra aux requêtes concernant la zone rush.epita.fr.

Serveur pop3

  1. Securisé: Qpopper 4.0.4-2.woody3 + SSL
  2. Non-Securisé: Qpopper 4.0.4-2.woody3
Le logiciel imposé pour la machine témoin est Qpopper. Qpopper étant fiable et fréquemment utilisé pour assurer le service pop3, nous avons décidé de l'utiliser également sur la configuration sécurisée. De plus, le support SSL a ete ajouté afin de permettre la securité des données.

Serveur SMTP

  1. Securisé: Exim 3.35-1woody2
  2. Non-Securisé: SendMail 8.12.3-6.6
Le logiciel imposé est sendmail. Il est assez compliqué à configurer en temps normal. La distribution que nous avons utilisée possède une configuration par défaut qui lui permet de fonctionner. Par contre, pour la machine securisée, nous avons plutôt opté pour exim 4. Ce choix étant motivé principalement par le fait que de nombreuses failles de sécurité sont regulièrement découvertes dans sendmail. Ces deux logiciels n'ont pas demandé de configuration spécifique, la plupart du travail étant effectué par l'assistant qui demande les informations nécessaires au moment de l'installation.

Serveur FTP

  1. Sécurisé: ProFTPd 1.2.5rc1 + SSL
  2. Non-Sécurisé: wu-ftpd 2.6.2-3.woody2
Le logiciel imposé pour ce service est wu-ftpd. Par défaut, sous debian, wu-ftpd est configuré pour accepter les connexions anonymes. Pour la machine securisée, wu-ftpd ne nous satisfaisant pas, nous avons choisi d'installer ProFTPd, que nous avons déjà eu l'occasion d'utiliser et qui est notamment utilisé chez Free.fr pour ses pages perso. Les connexions anonymes ne sont pas possibles par défaut, mais il est assez facile de configurer celà. Pour ajouter encore a la sécurité, les connexions SSL sont acceptées. Les ports pour les connexions en mode passif ont été définis entre 42000 et 43000 pour faciliter la configuration du firewall.

Serveur NTP

  1. Sécurisé: NTPd 4.1.0-8
  2. Non-Sécurisé: NTPd 4.1.0-8
Afin de synchroniser les différentes machines entre elles, nous avons installé ntpd. Par défaut, la serveur se trouve en stratum 16 ce qui empeche les machines de l'utiliser comme serveur de temps car ce niveau est beaucoup trop élevé. Nous avons donc passé la machine securisée et la machine témoin en stratum 10 afin de permettre la synchronisation des autres machines.
Note: le réglage stratum définit le niveau d'autorité du serveur, plus le nombre est bas, plus le serveur doit être considéré comme autoritaire en tant que serveur de temps.

Serveur SSH

  1. Sécurisé: OpenSSH 3.4p1.woody.3 V2 only
  2. Non-Sécurisé: OpenSSH 3.4p1.woody.3 V2 only
Les deux systèmes ont été équipés du même serveur SSH. Les connexions sont limitées au protocole SSH version 2. Par défaut, l'utilisateur root peut se connecter directement via SSH. Dans la configuration sécurisée, l'action est possible, mais seulement avec une identification par clé ssh.

Firewall iptables

  1. Sécurisé: iptables 1.2.6a-5
  2. Non-Sécurisé: Rien
Note: Le système de firewall de Linux est appelé Netfilter, iptables est la commande userland qui permet de le configurer.
Afin de limiter les connexions non-autorisées, nous avons mis en place sur la machine sécurisée un pare-feu basé sur iptables (netfilter). Seuls les services peuvent générer du traffic vers l'extérieur. Les connexions sont cependant possible par l'interface locale. Seuls les ports des services sont accessibles depuis l'extérieur, à savoir (21, 22, 25, 53, 80, 110, 42000-43000). Les ports passifs pour le ftp ont ete forcés entre 42000 et 43000, qui sont des ports generalement non utilisés et non scannés. De plus nous exploitons les fonctionnalités d'iptables pour faire un firewall a états. Les paquets ICMP sont autorisés a sortir et nous avons choisi de répondre au ping. Chaque chaine possède une règle qui logge les paquets refusés.