TP Sécurité réseau n°1 : Firewalls et outils d’audit réseau

C E T P I L L U S T R E R A

1 Configuration réseau d’un routeur filtrant

2 Utilisation des règles de filtrage ACL

3 Utilisation de l’interface ASDM pour le filtrage des données par l’intermédiaire du CISO PIX

4 Utilisation de IPTABLES pour le filtrage des données par l’intermédiaire d’un routeur logiciel LINUX

5 Outils d’audit réseau

6 Outils de détection d’intrusion

IESSA SIC - Durée : 6H

Octobre 2009

Remarques préliminaires Pour ce TP, chaque binôme travaille sur un îlot isolé et dispose de trois PC Linux et un PC Windows XP équipés de deux cartes Ethernet. Chaque îlot est doté de deux HUBs Ethernet ainsi que de deux SWITCHs Ethernet. Un routeur CISCO série 1600 ainsi qu’un routeur Firewall CISCO PIX sont aussi disponibles. Pour la partie 1 du TP seuls 2 PCs linux, deux HUBs (ou SWITCHs au choix) réseau et le routeur Cisco seront nécessaires. Le troisième PC linux n’interviendra que dans les parties 2 et suivantes du TP. Toutes les commandes réseau (ifconfig, wireshark, iptables, snort…) doivent être exécutées en tant que ROOT. Le mot de passe vous sera communiqué au début du TP. Attention !!! en tant que ROOT vous pouvez endommager gravement votre système et hypothéquer le bon déroulement de votre TP, il est donc nécessaire de réflechir avant d’exécuter toute commande en tant qu’utilisateur ROOT. Le compte rendu devra faire apparaître en clair la séquence des commandes que vous aurez réalisée ainsi que les captures d’écran des situations que vous jugerez utiles de mentionner par écrit. Toute commande ou capture d’écran devra être justifiée et son fonctionnement explicité avec soin. Pour éviter tout problème d’une configuration de firewall existante dans votre îlot, veuillez exécuter le script de la partie 2 §3.1.3 sur chacune de vos machines avant d’aller plus loin.

Partie 1 : configuration réseau minimale et routage

1. Branchement et découverte du matériel Connectez chacune de vos machines à un des deux hubs (ou switchs) via une prise RJ45. Connectez ensuite le routeur Cisco sur chacun des hubs (ou switchs) en prenant soin de connecter chacune des interfaces du routeur sur un réseau disjoint.

2. Paramétrage IP La commande ifconfig permet de récupérer les informations sur les interfaces réseaux de votre machine, utilisez la pour configurer les interfaces de vos deux machines afin de leur attribuer une adresse réseau valide. Il est vivement conseillé de regarder le man de cette commande. Attention au choix des adresses réseaux qui doivent faire appartenir chaque machine à des réseaux différents ! La configuration se fera sur l’interface eth1 (carte réseau située en bas de votre unité centrale).

- les réseaux utilisés sont les réseaux 192.168.1.0 et 192.168.2.0 - le dernier chiffre de la partie hôte de l’adresse doit reprendre le numéro de la machine

G17-XX (par exemple machine G17-12 => @IP 192.168.X.12).

3. Utilisation d’un routeur Nous allons maintenant utiliser un routeur CISCO de la série 1600 pour interconnecter les deux réseaux logiques.

3.1. Configuration basique Le routeur le plus haut présent dans la baie de brassage n’est pas configuré. On va donc commencer à le configurer, par l’intermédiaire de la liaison série. Relier une des machines de l’îlot à la prise série du routeur, lancer l’outil kermit, signaler à kermit l’utilisation de la liaison série par la commande set line /dev/ttyS0, la non vérification de la porteuse par la commande set carrier-watch off et demander la connexion par la commande connect. Allumer le routeur et attendre la connexion entre le terminal et le routeur. Configurez l’interface 0 via la liaison série.

3.2. Fin de la configuration du routeur Connecter une machine et le routeur par telnet. On va maintenant configurer l’interface ethernet 1 du routeur. Pour ce faire, il faut se placer en mode enable, puis demander à passer en mode configuration par terminal (commande configure terminal), puis configurez l’interface 1 pour quelle appartienne à l’autre réseau logique.

3.3. Vérification de la configuration du routeur Maintenant que le routeur est configuré, on va vérifier cette configuration par l’utilitaire ping, disponible sur le routeur. A l’aide de cet utilitaire, essayez de joindre les machines du réseau. A ce niveau, le routeur doit être capable de joindre toutes les machines.

Essayer maintenant de faire communiquer les machines de votre îlot. Terminez la configuration du routeur pour rentre possible cette communication.

4. Routes statiques On veut maintenant faire en sorte que les deux réseaux, avec les caractéristiques définies précédemment soient capables de se voir. Pour réaliser cela, on va mettre en place des routes statiques, par l’intermédiaire de la commande route. Par exemple sur une des machines linux d’extrémité on exécute la commande : route add –net 192.168.x.0/24 gw 192.168.y.100 eth1 Visualiser le résultat à l’aide de la commande route –n. Remarque : si des routes statiques passant par eth0 persistent dans votre configuration, exécutez la commande ifconfig eth0 down. Réaliser ces commandes sur vos deux machines d’extrémité et vérifier la connectivité entre ces deux machines à l’aide de la commande ping.

Partie 2 : notion de filtrage en sécurité réseau

1. Filtrage sur les routeurs : découverte des ACL CISCO Nous allons maintenant utiliser les possibilités de filtrage offertes par le routeur CISCO. Pour ce faire, nous n’allons utiliser qu’une petite partie de ces capacités, en se limitant au filtrage de niveau réseau. Cette fonctionnalité est appelée Access Control List.

1.1. Introduction des ACL CISCO Les Access Control List (ACL) sont des listes de filtrage présentes sur quasiment tous les routeurs CISCO. On définit des autorisations et des interdictions. Une ACL :

- est définie par un numéro, qui permet de classifier sa complexité (d’un simple filtrage sur les adresses IP à des filtres plus élaborés prenant en compte les ports sources et destinations des protocoles).

- Par les règles qui lui son propre - Par son application sur une interface en entrée ou en sortie de cette dernière - Par un parcours séquentiel lors de son application, avec une sortie dès qu’une

condition est validée. L’ordre des autorisation et des interdictions est donc très important.

Les possibilités de filtrage sont donc réelles et très complexes à mettre en œuvre. Le but de cette partie du TP est d’autoriser le trafic SSH entre vos deux PCs Linux situés de part et d’autre du routeur CISCO. Pour cela nous nous utiliserons une ACL étendue (numéro > 99) agissant sur le protocole applicatif transporté uniquement (ici SSH). Remarque : il est à signaler que la configuration des ACL est assez délicate et qu’il n’est pas possible de changer l’ordre des autorisations et des interdictions. Il est donc vivement

conseillé de commencer par une réflexion papier avant de se lancer directement sur la configuration. Néanmoins, il est possible d’effacer une access-list erronée. Pour cela, il faut utiliser la commande : no access-list <ACLnumber>

1.2. Paramétrage des ACL Pour paramétrer les ACL, se mettre en mode ENABLE, puis en configuration terminal. On voit alors, par l’aide des commandes, qu’on a accès aux ACL. Le numéro de l’ACL sera le 105. Une fois l’ACL paramétrée, on attache cette ACL à une interface, par la configuration de l’interface : ip access-group 105 [in/out]. Ce qui suit est un exemple d’une ACL qui peut être positionnée, elle est à adapter en fonction de vos configuration réseaux (notamment les adresses IP qui apparaissent dans les ACL).

nantes(config)#access-list ? <1-99> IP standard access list <100-199> IP extended access list <1100-1199> Extended 48-bit MAC address access list <1300-1999> IP standard access list (expanded range) <200-299> Protocol type-code access list <2000-2699> IP extended access list (expanded range) <700-799> 48-bit MAC address access list nantes(config)#access-list 105 ? deny Specify packets to reject dynamic Specify a DYNAMIC list of PERMITs or DENYs permit Specify packets to forward nantes(config)#access-list 105 deny ? <0-255> An IP protocol number ahp Authentication Header Protocol […/…] icmp Internet Control Message Protocol […/…] ip Any Internet Protocol […/…] tcp Transmission Control Protocol udp User Datagram Protocol nantes(config)#access-list 105 deny ip ? A.B.C.D Source address any Any source host host A single source host nantes(config)#access-list 105 deny ip 100.0.1.9 ? A.B.C.D Source wildcard bits nantes(config)#access-list 105 deny ip 100.0.1.9 0.0.0.0 ? A.B.C.D Destination address any Any destination host host A single destination host nantes(config)#access-list 105 deny ip 100.0.1.9 0.0.0.0 100.0.2.10 0.0.0.0 ? fragments Check non-initial fragments log Log matches against this entry

log-input Log matches against this entry, including input interface precedence Match packets with given precedence value tos Match packets with given TOS value <cr>

On met l'ACL sur l'interface eth 0 en entrée :

nantes(config)#interface ethernet 0 nantes(config-if)#ip access-group 105 ? in inbound packets out outbound packets nantes(config-if)#ip access-group 105 in

On vérifie la configuration nantes(config-if)#exit nantes(config)#exit nantes#sh nantes#sh nantes#show run nantes#show running-config Building configuration... Current configuration: ! […/…] ! interface Ethernet0 ip address 100.0.1.1 255.255.255.0 ip access-group 105 in no ip directed-broadcast ! interface Ethernet1 ip address 100.0.2.1 255.255.255.0 no ip directed-broadcast ! ip classless ! access-list 105 deny ip host 100.0.1.9 host 100.0.2.10 !

Rappel : pour effacer une access-list erronée il faut utiliser la commande : no access-list 105

Des exemples d’ACL sont disponibles dans le fichier

ilot1_config_solution_cisco.txt situé sur le poste Windows XP de votre îlot. Il est recommander de copier ce fichier et de ne pas travailler directement dessus.

Questions :

1. Quel est le réglage à mettre dans l’ACL ? 2. Sur quelle interface faut-il l’appliquer ? En entrée ou en sortie ?

Remarque : il n’existe pas une réponse unique aux deux questions précédentes.

3. Une fois l’ACL mise en place, vérifier son bon fonctionnement.

2. Utilisation d’un firewall matérielle : CISCO PIX Dans cette partie, nous vous proposons de remplacer le routeur CISCO 1605 par un firewall routeur matériel CISCO PIX afin de profiter de la souplesse et de la puissance d’utilisation de l’interface CISCO ASDM. VERIFICATION préliminaire : assurer vous que le Java Runtime Environment (JRE) utilisé sur le système est bien la version 1.5, sinon l’interface ASDM refusera de se lancer. Pour cela aller dans les paramètres Windows, cliquez sur Java et dans la fenètre qui monte choisissez l’onglet Java, bouton Afficher, il suffit d’activer UNIQUEMENT la JRE 1.5. Dans un deuxième temps, vous pourez accéder à l’interface ASDM via applet java au travers du navigateur Internet Explorer.

2.1. Exercice 1 A l’aide des annexes A et B configurer le firewall CISCO PIX pour qu’il puisse servir de routeur entre les deux réseaux logiques précédemment configurés. Vous configurerez dans un premier temps son interface ethernet 1 en mode commande (laison série). Ainsi, la configuration du CISCO PIX se fera à partir du poste Windows XP dans un premier temps avec le programme hyper-terminal puis dans un deuxième temps à l’aide de ASDM. A l’aide d’une connexion série vous devez réinitialiser la configuration du CISCO PIX en lançant la commande : write erase. Confirmez puis lancez la commande : reload qui provoquera un redémarrage du CISCO PIX. Lorsque le firewall a redémarré, il vous propose un menu de pré configuration, acceptez l’invitation.

Répondez par défaut aux questions posées, jusqu’à la saisie de l’ « inside IP address ».

Très Important : En aucun cas et à quelque moment vous ne devez changer quelque mot de passe qui soit. Remarque : les firewalls sur lesquels vous allez travailler au cours de ce stage n’ont pas de mot de passe. Ce n’est bien sûr pas une pratique recommandable en exploitation.

L’ « Inside IP address » est l’adresse de l’interface ethernet 1 qui doit être une

adresse réseau appartenant à un des réseaux logiques configurés dans la partie précédente. Saisir également le masque de réseau, le nom de votre firewall, le nom de domaine ainsi que l’adresse de votre station de configuration qui est celle de la machine windows XP

Vérifiez votre configuration et validez en répondant affirmativement à la question « use this configuration and write to flash ».

Vous terminerez la configuration de la deuxième interface à l’aide de l’interface graphique ASDM (cf. annexe. B).

2.2. Exercice 2 Une fois la configuration réseau mise en place, configurer le CISCO PIX pour qu’il serve d’outil de filtrage pour permettre uniquement au trafic SSH de passer d’un réseau à l’autre. Pour cela vous vous inspirerez de l’annexe C qui décrit la mise en place d’une règle de filtrage pour le protocole FTP.

3. Evolution de la configuration réseau Nous allons maintenant délaisser l’utilisation du firewall routeur Cisco PIX et le remplacer par un routeur logiciel Linux, qui va nous permettre de tester les fonctionnalités de filtrage avancé ainsi que d’audit réseau. Pour ce faire, vous utiliserez la troisième machine Linux à votre disposition dans l’îlot de TP et vous configurerez ses deux interfaces pour que chacune d’elle appartienne à un des réseaux défini au début de ce tp. Vérifier l’activitation du forwarding IP sur la machine qui vous sert de routeur logiciel (fichier /proc/sys/net/ipv4/ip_forward à 1). A l’issue de cette configuration, veuillez retester la connectivité entre les machines d’extrémité à l’aide de la commande ping.

3.1. Filtrage avancé avec « iptables »

3.1.1. Description Iptables est le module noyau de linux gérant le filtrage des paquets. Il peut donc constituer un bon pare-feu, tant sur une station de travail qu'en tant qu'équipement dédié. Iptables est constituée de 3 tables. La trame est reçue par la carte réseau, qui décapsule le paquet IP et le relaie au noyau. Le paquet va ensuite traverser la chaîne INPUT, puis la chaîne FORWARD et enfin, la chaîne OUTPUT juste avant son envoi à la carte réseau. Par ailleurs, la table FILTER permet elle de traiter les paquets devant être routés. Elle permet donc de rediriger des flux à la volée, faire du NAT. . . Le filtrage est défini sous la forme de règles, aboutissant à une action : DROP, ACCEPT, LOG, REJECT, MASQUERADE, DNAT, SNAT. . .

3.1.2. Commandes utiles Les commandes suivantes vous seront utiles :

• iptables -F : enlève les règles existantes sur la table principale (INPUT, OUTPUT, FORWARD)

• iptables -X : enlève les règles utilisateurs • iptables -L : liste les règles • iptables -P INPUT DROP : définit la police par défaut pour la table concernée • iptables -t XXX -F : enlève les règles sur la table XXX. Vous utiliserez principalement

les tables suivantes : o mangle : permet d'effectuer des traitements post et pré routage. o nat : pour la traduction d'adresses. Il existe deux types de chaînes :

POSTROUTING et PREROUTING, avec les cibles MASQUERADE (traduction d'adresse), DNAT (changement de l'adresse ou du port de destination), SNAT (changement de l'adresse ou du port de la source)

• iptables -A INPUT -i lo -j ACCEPT : ajoute une règle dans la table principale INPUT qui autorise les paquets venant de l'interface loopback

• iptables -A FORWARD -i eth0 -o eth0 -s 192.168.100.0/24 -d 192.168.0.1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT : accepte de relayer les paquets venant de l'interface eth0 du réseau 192.168.100.0/24 et sortant sur l'interface eth0 vers 192.168.0.1 si la connexion est nouvelle, déjà établie, ou relative à une connexion déjà établie (utile pour les connexions FTP par exemple).

• iptables -N LOG_DROP : crée une nouvelle chaîne • iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination

192.168.0.1:22 : redirige tous les paquets TCP destinés au port 2222 vers l'hôte 192.168.0.1 sur le port 22

3.1.3. Initialisation iptables Avant de démarrer il est nécessaire d’activer tous les échanges sur les différentes tables pour ne pas induire de comportement parasite. iptables -X iptables –P INPUT ACCEPT iptables –P OUTPUT ACCEPT iptables –P FORWARD ACCEPT iptables –F INPUT iptables –F OUTPUT iptables –F FORWARD Commenter le résultat de l’exécution de ces commandes en vous aidant du résultat de la commande iptables –L avant et après l’exécution du script ci-dessus. Remarque : cette configuration n’est pas celle utilisée par défaut par les administrateurs réseau qui choisissent plutôt de tout bloquer et d’autoriser uniquement les connexions qu’ils jugent nécessaire. Néanmoins pour des besoins de simplification des règles nous ne suivront pas ce type de politique dans un premier temps.

3.2. Exercice basique Faites en sorte d’interdire aux deux machines d’extrémité de se pinguer.

Pour plus de simplicité, vous pouvez créer un script regroupant toutes les règles définies, à lancer en une seule fois. Ceci évite de multiplier les fautes de frappe. Vous pouvez vous inspirer du script disponible sur chacun des ilôts dans le répertoire /home/eleve/SECRE/ilot1_config_stagiaires_iptables.txt. Il est impératif de copier ce fichier et de ne pas travailler directement dessus.

3.3. Exercice avancé Maintenant nous allons nous mettre dans le cas de figure d’un vrai administrateur réseau. Il est donc nécessaire d’interdire tous les échanges sur les différentes tables pour ne pas induire de failles de sécurité et de n’autoriser que les connexions que l’on a identifié. iptables –P INPUT DROP iptables –P OUTPUT DROP iptables –P FORWARD DROP Nous proposons dans cette configuration que vous mettiez en place les règles suivantes :

• Autoriser le ping entre les deux machines d’extrémités. • Autoriser les flux SSH au sein du réseau.

De la même façon qu’à la question précédente, vous pouvez créer un script regroupant toutes les règles définies, à lancer en une seule fois et vous inspirer du script disponible sur chacun des ilôts dans le répertoire /home/eleve/SECRE/ilot1_config_stagiaires_iptables.txt. Il est impératif de copier ce fichier et de ne pas travailler directement dessus.

Partie 3 : outils de sécurité réseau pour l’audit

1. Outil d'analyse réseau : Wireshark Le logiciel WIRESHARK va permettre de voir les trames Ethernet qui transitent sur le réseau pendant cette phase d’audit. Nous utiliserons ce logiciel pour analyser le trafic Ethernet de la salle. Pour le lancer, tapez dans un terminal la commande wireshark. Cet outil nous permettra d’analyser le comportement des outils d’audit que nous allons maintenant utiliser. Il est nécessaire à cet instant de revenir dans un configuration IPTables qui permette de laisser passer le trafic NMAP, pour cela exécuter le script de la partie 2 §3.1.3.

2. Scanner de port : NMAP Nmap permet d'obtenir des informations sur le système distant. La commande suivante permet de pinger un ensemble d'hôtes pour vérifier qu'ils sont atteignables : nmap -sP 192.168.X.1-255.

2.1. Exercice Détectez les ports réseaux ouverts (de 1 à 5000) sur votre client, et détecter le système d'exploitation distant (vous pouvez vous aider de nmap -h ou man nmap). Attention : le scan d'un hôte est considéré juridiquement comme une attaque réseau. Seul est autorisé le scan sur un hôte dont l'auteur est lui même l'administrateur. Un scan doit être considéré comme un moyen pour réaliser un audit, mais en aucun cas une attaque. Corréler les informations relevées avec Wireshark pour décortiquer le fonctionnement de cet outil.

3. Outil NESSUS Nessus est un outil permettant de détecter les failles d'un serveur. Il est évident que Nessus ne doit être exécuté que sur un de ses propres serveurs afin de tester sa robustesse et sa protection aux attaques. Une attaque réseau est passible de peines de prison. Nessus est continuellement mis à jour et possède actuellement plus de 10 000 plugins différents. Nessus se compose d'une partie serveur et d'une partie client. Le serveur ne devrait être démarré qu'à la demande, même s'il n'autorise que des connexions TLS et qu'une authentification par certificats est possible. En d'autres termes, il est conseillé d'arrêter le serveur lorsque l'opération souhaitée est terminée, afin d'éviter que tout autre client s'y connecte, et détecte ainsi les failles du réseau interne. Les versions 2.x sont opensource, les nouvelles versions 3.x sont maintenant devenues propriétaires.

3.1. Exercice Réalisez un scan de votre routeur logiciel et de votre machine cliente. Pour cela vous utiliserez le compte eleve et le mot de passe eleve à spécifier dans le logiciel nessus. Corréler les informations relevées avec Wireshark pour décortiquer le fonctionnement de cet outil. Des vulnérabilités importantes ont-elles été détectées ?

Partie 4 : la détection d’intrustion avec SNORT

1. Description générale Snort est un Network IDS. Il peut fonctionner en mode sniffer (capture le traffic et l'affiche), packet logger (capture le traffic et le stocke, i.e. agit en tant que sonde), NIDS (en temps réel sur le traffic capturé). Bien entendu, il est conseillé de réfléchir à la localisation la plus judicieuse d'un NIDS (avant ou après le firewall). Le noyau charge au démarrage un ensemble de règles configurables. Durant l'exécution, il est chargé de capturer les paquets. Les règles d'analyse sont ensuite exécutées, et selon les résultats, plusieurs actions peuvent être prises (ajout dans les logs, base de données. . .). Snort

propose en téléchargement un grand nombre de règles relatives aux vulnérabilités connues (une partie est payante, une partie gratuite). Remarque : pour que snort s’exécute sans erreur il faut le lancer depuis le répertoire /etc/snort. Vous pourrez observer les différentes règles de snort dans le répertoire /etc/snort/rules. Voici un exemple de règle : alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS cmd.exe access"; flags: A+; content:"cmd.exe"; nocase; classtype:web-application-attack; sid:1002; rev:2;) Elle détecte un paquet http venant de l'extérieur et destiné à un de nos serveurs webs contenant le mot cmd.exe (insensible à la casse), classant l'attaque parmi les applications webs. La règle déclenchera l'inscription de msg dans les logs (fichier /var/log/snort). Par ailleurs, sid et rev permettent d'identifier la provenant des règles, et définit un numéro de version. Vous pouvez regarder pour avoir d'autres exemples de règles le fichier /etc/snort/snort.conf.

2. Exercices Dans cette partie, vous allez être mis en situation « professionnelle » dans le sens où un des objectifs pour vous sera d’utiliser tous les moyens d’information à votre disposition (papier et électronique) pour aller chercher de l’information sur l’utilisation de cet outil nouveau qu’est Snort. Remarque : l’autonomie et l’esprit d’initiative dont vous ferez preuve lors de cette dernière partie seront particulièrement recherchés. Tout d’abord commencez par :

• Testez un scan de ports nmap vers une machine exécutant snort. Observez les fichiers de logs de snort. Commentez le résultat.

L’objectif final de la manipulation est le suivant :

• Mettez en place l’alerte suivante : une tentative de connexion (sur la machine déployant snort) à l’aide du protocole ssh de la part du compte utilisateur eleve

ANNEXE A Configuration pix en mode commande

1 Ce que vous avez besoin de savoir sur les commandes pix SAS

1.1. Généralités sur l'interface Utilisateur :

1.1.1. Deux niveaux d'accès aux commandes : Pour des raisons de sécurité, l'interface utilisateur du cisco pix présente deux niveaux

d'accès aux commandes, le mode utilisateur (user EXEC) et le mode privilégié (privileged EXEC).

L'accès au mode privilégié nécessite la saisie d'un mot de passe et ce n'est qu'après avoir accédé à ce mode, que la configuration du routeur est possible. A chaque mode correspond une invite spécifique.

Lorsqu’on démarre, le firewall on est en mode user EXEC. Pour avoir la liste des commandes disponibles du niveau dans lequel on se trouve, il suffit de faire ? :

pix> ? (invite du mode user EXEC) Exec commands: <1-99> Session number to resume connect Open a terminal connection disconnect Disconnect an existing telnet session enable Turn on privileged commands exit Exit from the EXEC . . . where List active telnet connections x3 Set X.3 parameters on PAD xremote Enter XRemote mode Pour passer en mode privileged EXEC, il faut utiliser la commande enable. Le système demande alors un mot de passe. Tapez la touche entrée (pas de mot de passe)

pix> enable Password:

pix # ? (prompt du mode Privileged EXEC) Exec commands: bfe For manual emergency modes setting clear Reset functions clock Manage the system clock configure Enter configuration mode connect Open a terminal connection copy Write running configuration to flash, network, or terminal . . .

x3 Set X.3 parameters on PAD xremote Enter XRemote mode

1.1.2. Le préfixe de commande show : Le préfixe show permet de visualiser la configuration du routeur.

• show running-config permet de visualiser la configuration globale du routeur. • show ip interface visualise les informations ip sur chaque interface • show version donne une quantité d’informations utiles • show memory état d’occupation de la mémoire

1.1.3. La commande configure Pour pouvoir configurer le firewall, une fois en mode privilégié, il faut saisir la

commande configure terminal. Lorsque les manips seront terminées il faudra faire Ctrl-Z et copy running-config startup-config pour écrire les modifications dans la mémoire. pix# configure terminal pix(config)# (invite du mode configure)

1.1.4. Le préfixe de commande no : Presque toutes les commandes sont annulées avec l'utilisation du préfixe no

suivi de la commande. exemple : ip routing met en place le routage IP no ip routing supprime le routage IP

ANNEXE B Configuration pix en mode graphique

1) Installation de ASDM Sur la machine windows, fermer le terminal série. Lancez firefox et saisir l’url :

https://192.168.n.1 Le cisco pix vous envoie son certificat X509, acceptez le.

Faire OK à la fenêtre pop sans rien saisir.

Activez le bouton « Download ASM Launcher and Start ASDM”

Rapatriez le fichier d’installation sur le disque

Vous devez avoir présent sur votre bureau une nouvelle icône :

Double clic sur l’icône d’installation, répondez deux fois next puis install.

Une nouvelle icône est présente sur le bureau

2) Première utilisation Lancer ASDM, saisissez l’adresse IP de votre firewall et laissez le username et le

password vide, si tout va bien, vous devez trouver l’interface de gestion du cisco Pix.

La page d’accueil (home) vous donne des informations.

3) Configuration des interfaces

3.1. Ajout de ethernet0

Le menu de pré configuration ne nous a permis d’activer qu’une seule interface sur les trois physiquement présentes sur l’appareil, vous allez mettre en place l’interface ethernet 0. Cliquez sur le bouton configuration puis choisir la ligne de l’interface ethernet0 et exécuter un double clic. Nommez l’interface ethernet0 « mefiance ». Choisissez 0 comme niveau de sécurité.

Indiquez l’adresse internet associée à l’interface (2). Ne pas oublier de cocher le bouton « enable interface » et de faire « apply ».

3.2. Renommer ethernet1 Editez la configuration de l’interface ethernet1 et renommez l’interface « confiance »

ANNEXE C Positionnement d’une règle de filtrage avec le pix en mode graphique

Ex : vous voulez qu’un serveur ftp protégé soit accessible de part et d’autre du réseau

La création d’une nouvelle règle s’effectue en cinq étapes 1 – Choisir permit ou deny 2 – choisir l’interface source et indiquer l’adresse du (ou des) hôte(s) concerné(s) 3 – choisir l’interface destination et indiquer l’adresse du (ou des) hôte(s) concerné(s) 4 – choisir si besoin le ou les protocoles source concernés 5 – choisir si besoin le ou les protocoles destination concernés

Règles de Méfiance vers Sas

TP Sécurité réseau n°2 : Messagerie sécurisée

Certificats – OpenSSL – IMAPS

C E T P I L L U S T R E R A

1 Création et manipulation de certificats numériques

2 Configuration d’un serveur de messagerie sécurisé

3 Analyse de trafic applicatif chiffré

IESSA SIC - Durée : 4H

Octobre 2009

Remarques préliminaires

Ce TP est dans la continuité du TP réalisé en tronc commun dans le cadre de la mise en place d’un serveur mail SMTP. Vous utiliserez en particulier la même configuration réseau ainsi que les mêmes environnements (un serveur Linux et un client Windows XP ou Linux en fonction de votre travée).

Au cours du TP de l’an dernier nous avions configuré un serveur SMTP et récupéré les mails sur ce serveur à l’aide du protocole IMAP. Nous nous sommes aperçu que les login et mots de passe transitaient en clair sur le réseau de la salle de TP. Pour remédier à cette grosse faille de sécurité nous allons authentifier et chiffrer l’échange entre le serveur Linux et le client de mail XP à l’aide de certificats et de l’utilisation du protocole SSL associé à SMTP et IMAP.

Il est nécessaire de reconfigurer le serveur de mail SMTP « basique » avant de procéder à sa sécurisation par l’utilisation de certificats SSL. Pour cela reportez vous aux annexes A et B qui résument les commandes à exécuter pour déployer un serveur de mail PostFix.

Création et manipulation d'un certificat SSL auto-signé

Tout d’abord installez les paquetages manquant pour ce TP : openssl et postfix-tls à l’aide de la commande apt-get install.

Nous allons travaillé dans un premier temps avec un certificat généré en local. Dans ce cadre, il n'y a pas besoin d'autorité de certification, et ce certificat ne peut pas être automatiquement accepté par une application ; puisque qu’aucune autre ne le valide.

Il est facile à réaliser en une ligne :

$ openssl req –new -x509 –nodes -out smtpd.pem -keyout smtpd.pem –days 3650

Et il suffit de répondre aux questions. A la fin, le certificat et la clé se retrouvent dans le fichier smtpd.pem .

Pour vérifier que le certificat est valide, exécutez :

$ openssl x509 -in smtpd.pem -text –noout

Ce certificat va nous servir dans la partie suivante pour autentifier toute communication entre le serveur Postfix sécurisé et ses clients.

SMTP authentifié et sécurisé avec PostFix (SMTP over SSL)

Il est souvent pratique d'avoir une connexion SMTP sécurisé, avec SSL ou TLS. Cela permet entre autre de permettre aux mots de passe de ne pas passer en clair sur le réseau.

Deux méthodes sont possibles pour faire du SMTP sécurisé. On peut faire passer une nouvelle connexion SMTP dans un tunnel SSL déjà établis au préalable, souvent sur le port 465 (SMTPS). La seconde méthode suit le protocole indiqué dans la RFC 2487. Dans ce cas, après s'être connecté au serveur SMTP, le client liste les extensions que celui-ci supporte. Si l'option STARTTLS est supportée, le client négocie alors une connexion SSL.

1- Configuration de SMTP over SSL.

Nous allons regarder la seconde méthode, c'est la plus simple à mettre à oeuvre. Vous reprendrez pour ce faire le cerficat généré dans la partie I du TP.

Ensuite, il suffit d'activer dans le fichier /etc/postfix/main.cf le support TLS/SSL de Postfix, et lui indiquer où trouver les certificats.

smtp_use_tls = yes smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /etc/postfix/ssl/smtpd.pem smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pem smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes tls_random_source = dev:/dev/urandom

Rem : ici, les certificats seront placés dans un répertoire « ssl » à créer au préalable dans le répertoire de configuration de Postfix.

Relancez PostFix.

2- Observation du fonctionnement du service SSL

Après avoir réalisé cette configuration, connectez vous via telnet sur le serveur de mail et exécutez la commande EHLO. Notez la réponse que vous fait le serveur.

Dans un deuxième temps, désactivez l’option TLS dans le fichier main.cf, relancez postfix puis relancez une connexion via telnet sur le serveur de mail. Quel est le message manquant qui indique que la connexion était sécurisée au préalable et plus maintenant ?

IMAP authentifié et sécurisé avec (IMAP over SSL)

1- Configuration de IMAP over SSL.

Faites un apt-get install courier-imap-ssl. Debian se chargera tout seul d'installer le reste des paquets nécessaires. Puis effacez les certificats *.pem afin d'en recréer avec les bonnes informations. Lancez ensuite un dpkg-reconfigure courier-imap-ssl et vérifiez la présence de vos nouveaux certificats (la commande ls -l vous y aidera). Lancez ensuite les démons, par un : /etc/init.d/postfix restart et de même pour courier, courier-authdaemon et courier-imap-ssl. Vérifiez que tout est bien lancé par un netstat -an | grep 993 (c'est le daemon imap-ssl).

2- Après avoir réalisé cette configuration, vérifiez que la réception des mails à l’aide du protocole IMAP est sécurisée (protocole IMAPS) à l’aide de votre client Thunderbird sous XP ou Linux (en fonction de votre travée) vers le serveur Linux. Que se passe-t-il de différent par rapport à une connexion non sécurisée ?

3- Fermez le client Thunderbird et réouvrez le en prenant soin de lancer au préalable une capture sur le serveur de mail à l’aide du logiciel Wireshark. Renouvelez ensuite la réception de vos mails et capturez en parallèle le trafic réseau généré lors de la phase d’authentification entre le serveur Linux et le client Windows XP ou Linux, qu’observez vous dans la capture?

4- Retrouvez dans les différents paquets échangés les différentes étapes de la connexion SSL telle qu’elle a été abordée en cours.

ANNEXE A : Configurer son serveur de mail local Table des matières 1. Installation de Postfix 2. Configuration de Postfix

Tous les ordinateurs sous Linux ont besoin d'un serveur de mail pour fonctionner correctement. Par contre, pour mettre en place un vrai serveur de mail destiné à recevoir des mails de l'extérieur, il faut des entrées dans la DNS et surtout un machine en état de fonctionnement 24h/24 et 7j/7.

Ce chapitre explique seulement la configuration d'un serveur mail qui gère le mail en local et l'envoi des mails. La configuration d'un vrai serveur de mail avec les entrées DNS qui vont avec est expliquée dans la partie Debian GNU/Linux en réseau de la documentation du système Debian disponible en ligne sur http://www.debian.org.

Installation de Postfix

Le serveur de mail installé par défaut sur une Debian est Exim. Je vous propose de le remplacer par Postfix, qui est réputé fiable et facile à configurer :

# apt-get install --purge postfix

Configuration de Postfix

Lors de l'installation du package, il vous pose des questions de configuration. A la première question Type de configuration ? Répondez Pas de configuration.

Une fois qu'il a fini l'installation du package, lancez la commande suivante pour relancer la procédure de configuration (cette astuce permet d'avoir un assistant de configuration plus détaillé) :

# dpkg-reconfigure postfix

Au deuxième écran, quand il vous redemande Type de configuration ? Répondez cette fois Site Internet. Ensuite, acceptez tous les paramètres qu'il vous propose par défaut !

Notez bien les infos apparaissant dans la console à l’issue de cette phase de configuration initiale.

1. main.cf La configuration de Postfix se fait dans le fichier /etc/postfix/main.cf.

Dans notre exemple, le serveur s'appelle facteur et son domaine localhost. Une petite note sur la configuration : la variable mynetworks est cruciale pour le bon fonctionnement de postfix, autorisant les plages d'adresses mentionnées ci-dessous. command_directory = /usr/sbin daemon_directory = /usr/lib/postfix program_directory = /usr/lib/postfix setgid_group = postdrop append_dot_mydomain = no smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no delay_warning_time = 4h smtpd_client_restrictions = permit_mynetworks virtual_maps = hash:/etc/postfix/virtual_maps myhostname = localhost alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = localhost.salletpg17 mydestination = salletpg17, localhost, localhost.salletpg17 relayhost =

mynetworks = 127.0.0.0/8, 192.168.1.0/16 mailbox_command = maildrop mailbox_size_limit = 0 recipient_delimiter = +

Notez que j'autorise ici localhost, salleg17 et localhost.salleg17 comme domaines. Cela veut dire que postfix laissera passer tout mail venant de ces domaines vers l'extérieur.

Une fois que vous avez personnalisé le fichier main.cf en lisant les commentaires contenus dans le fichier, il faut dire à Postfix de relire sa configuration :

# /etc/init.d/postfix reload

2. Les alias Les alias permettent de faire des correspondances entre des adresses mails et des comptes locaux, d'autres adresses mails ou encore des commandes à exécuter. Ils sont définis dans le fichier /etc/aliases. La syntaxe de ce fichier est très simple :

# /etc/aliases # Fichier d'alias mail # NE PAS OUBLIER d'exécuter "newaliases" après chaque modification # Fait suivre le mail reçu à l'adresse <alexis.delattre@nom_de_domaine> # au compte local "alexis" : alexis.delattre: alexis # Fait suivre le mail reçu à l'adresse <toto@nom_de_domaine> # à l'adresse <titi@yahoo.fr> : toto: titi@yahoo.fr # Fait suivre le mail reçu à l'adresse <machin@nom_de_domaine> # aux comptes "user1" et "user2" et à l'adresse <bidulle@exemple.org> : machin: user1,user2,bidulle@exemple.org # A la réception d'un mail à l'adresse <bruit@nom_de_domaine>, # exécute la commande "/usr/lib/ecartis/ecartis -s bruit" : bruit: "|/usr/lib/ecartis/ecartis -s bruit"

Normalement, on définit aussi dans ce fichier à quel compte local (ou à quelle adresse) le serveur de mail doit faire suivre le mail destiné à l'utilisateur root. En effet, comme il n'y a pas besoin d'avoir tous les pouvois pour lire le mail du root, il serait absurde (et même dangereux) de lire les mails du root en tant que root. Il est préférable de faire suivre le mail du root vers un autre compte ou une autre adresse.

Il faut également faire des alias pour les adresses postmaster et abuse, qui sont deux adresses standards pour pouvoir joindre les administrateurs du serveur de mails d'un domaine. Par exemple, si vous utilisez un compte local admin pour lire les logs et les mails d'administration, ajoutez les lignes suivantes au fichier d'alias :

root: admin postmaster: admin

abuse: admin

Ensuite, exécutez la commande suivante pour qu'il re-génère la base de donnée d'alias contenue dans le fichier /etc/aliases.db (ne pas oublier d'exécuter cette commande après chaque modification du fichier /etc/aliases) :

# newaliases

3. Les commandes de base d'administration Voici une petite liste des commandes de base d'administration de Postfix : • Liste la queue de mails en attente d'envoi : % mailq

Cette commande est équivalente à la commande postqueue -p.

• Force Postfix à réessayer d'envoyer les mails en attente d'envoi immédiatement : % postqueue -f

• Supprime un mail de la queue des mails en attente d'envoi : # postsuper -d mail_ID

Où mail_ID est l'identifiant du mail dans la queue (il apparaît à gauche dans la sortie de la commande mailq).

ANNEXE B : poster et lire son courrier avec telnet

1. Le protocole SMTP

Le protocole SMTP (Simple Mail Transfer Protocol, traduisez Protocole Simple de Transfert de Courrier) est le protocole standard permettant de transférer le courrier d'un serveur à un autre en connexion point à point.

Il s'agit d'un protocole fonctionnant en mode connecté, encapsulé dans une trame TCP/IP. Le courrier est remis directement au serveur de courrier du destinataire. Le protocole SMTP fonctionne grâce à des commandes textuelles envoyées au serveur SMTP (par défaut sur le port 25). Chacune des commandes envoyées par le client (validée par la chaîne de caractères ASCII CR/LF, équivalent à un appui sur la touche entrée) est suivi d'une réponse du serveur SMTP composée d'un numéro et d'un message descriptif.

Voici un scénario de demande d'envoi de mail à un serveur SMTP

• Lors de l'ouverture de la session SMTP, la première commande à envoyer est la commande HELO suivie d'un espace (noté <SP>) et du nom de domaine de votre machine (afin de dire "bonjour je suis telle machine"), puis valider par entrée (noté <CRLF>). Depuis avril 2001, les spécifications du protocole SMTP, définies dans le RFC 2821, imposent que la commande HELO soit remplacée par la commande EHLO.

• La seconde commande est "MAIL FROM:" suivie de l'adresse email de l'expéditeur. Si la commande est acceptée le serveur renvoie le message "250 OK"

• La commande suivante est "RCPT TO:" suivie de l'adresse email du destinataire. Si la commande est acceptée le serveur renvoie le message "250 OK"

• La commande DATA est la troisième étape de l'envoi. Elle annonce le début du corps du message. Si la commande est acceptée le serveur renvoie un message intermédiaire numéroté 354 indiquant que l'envoi du corps du mail peut commencer et considère l'ensemble des lignes suivantes jusqu'à la fin du message repéré par une ligne contenant uniquement un point. Le corps du mail contient éventuellement certains des en-têtes suivants :

o Date o Subject o Cc o Bcc o From

Si la commande est acceptée le serveur renvoie le message "250 OK"

Les spécifications de base du protocole SMTP veulent que tous les caractères transmis soient codés en code ASCII sur 7 bits et que le 8ème bit soit explicitement mis à zéro. Ainsi pour envoyer des caractères accentués il faut faire recours à des algorithmes intégrant les spécifications MIME :

• base64 pour les fichiers attachés • quoted-printable (d'abbréviation QP) pour les caractères spéciaux contenus dans le

corps du message

Il est ainsi possible d'envoyer un courrier grâce à un simple telnet sur le port 25 du serveur SMTP :

telnet smtp.enac.fr 25 (le serveur indiqué ci-dessus est volontairement inexistant, vous pouvez essayer en remplaçant commentcamarche.net par le domaine de votre fournisseur d'accès à internet)

Voici un récapitulatif des principales commandes SMTP

Commande Exemple Description HELO (désormais EHLO)

EHLO 193.56.47.125 Identification à l'aide de l'adresse IP ou du nom de domaine de l'ordinateur expéditeur

MAIL FROM: MAIL FROM: expediteur@domaine.com Identification de l'adresse de l'expéditeur

RCPT TO: RCPT TO: destinataire@domaine.com Identification de l'adresse du destinataire

DATA DATA message Corps du mail QUIT QUIT Sortie du serveur SMTP

HELP HELP Liste des commandes SMTP supportées par le serveur

L'ensemble des spécifications du protocole SMTP sont définies dans le RFC 821 (depuis avril 2001, les spécifications du protocole SMTP sont définies dans le RFC 2821).

Poster un message

La connexion au serveur se fait sur le port 25 (SMTP) :

telnet smtp.chez.mon.fai. smtp Trying 192.168.1.1... Connected to smtp.chez.mon.fai. Escape character is '^]'. 220 smtp.chez.mon.fai ESMTP Sendmail 8.9.3/8.9.3; Sun, 27 Feb 2000 15:58:15 +0100

On remarque tout de suite le ESMPT avec un "E" comme étendu : le serveur accepte le 8-bits. Disons-lui bonjour en lui indiquant que nous aussi nous parlons le 8-bits couramment en répondant ehlo (s'il nous dit simplement SMTP nous répondrons HELO) suivi de notre nom de domaine. Le serveur n'est pas trop regardant sur la distinction majuscules / minuscules tant que l'on n'est pas dans les en-têtes ou dans le corps du message.

ehlo chez.mon.fai 250-smtp.chez.mon.fai Hello toto@ppp136.chez.mon.fai [192.168.1.2], pleased to meet you 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250 HELP

On commence par écrire l'enveloppe :

mail from: toto@chez.mon.fai 250 toto@chez.mon.fai... Sender ok rcpt to: titi@chez.lui titi@chez.lui... Recipient ok data 354 Enter mail, end with "." on a line by itself

Notons au passage que vous pouvez poster a) chez votre fournisseur à destination de n'importe qui à partir de chez vous, ou b) parfois sur un serveur smtp quelconque à

destination d'un des clients du dit serveur, mais pas c) sur n'importe quel serveur pour n'importe qui à partir de n'importe où (message du type 550 titi@hop.la... Relaying denied.

Maintenant passons aux en-têtes - certains champs dont la date et le Message-ID seront rajoutés par le serveur SMTP - en faisant bien attention à la syntaxe (majuscule initiale, minuscule, pas d'espace avant ":" mais un espace après) puis au texte du message séparé par une ligne blanche. Tout ça se finit par une ligne ne comportant qu'un point ".", et l'on quitte par la commande quit si l'on a fini.

From: toto@chez.mon.fai To: titi@chez.lui Subject: test (de veau) blabla blabla . 250 WAA11355 Message accepted for delivery quit 221 smtp.chez.mon.fai closing connection Connection closed by foreign host.

Un certain nombre d'en-têtes sont classiquement reconnus par les logiciels de courrier, on aura par exemple :

Organization: bof X-Mailer: Linux netkit-telnet 0.14

On évitera soigneusement de mettre des accents dans les en-têtes.

Lire son courrier

La connexion au serveur se fait sur le port 110 (POP3) :

telnet pop3.chez.mon.fai pop3 Trying 192.168.1.1... Connected to pop3.chez.mon.fai. Escape character is '^]'. +OK pop3.chez.mon.fai POP3 Server (Version 1.006d) ready at <Sun Feb 27 10:13:32 2000> user toto +OK please send PASS command pass R5fg6Yh9 +OK 2 messages ready for toto stat +OK 2 1558 list +OK 2 messages; msg# and size (in octets) for undeleted messages: 1 780 2 778 .

list 2 2 778

Ci-dessus, nous venons de voir comment se connecter (commandes USR et PASS), comment avoir le total des messages (commande STAT) et quelques détails (commande LIST avec ou sans le numéro du message).

Maintenant lisons le courrier :

RETR 1 +OK message 1 (780 octets): Return-Path: <titi@chez.lui> Received: from [blabla chemin suivi par le message] From: titi@chez.lui <Gros Titi> To: toto@chez.mon.fai Subject: Bonjour Date: : Thu, 17 Feb 2000 21:38:05 +0100 Message-ID: <123456789.abcdefgh@mail.chez.lui> blabla blabla .

Et si le message est trop long ? Demandons à n'afficher que les 5 premières lignes du message numéro 2 :

top 2 5 [les en-têtes + la ligne blanche + les 5 premières lignes qui suivent]

Si le message est long, faire top 5 puis top 25 puis top 45 etc.

Et l'on quitte proprement (les messages lus restent dans la boîte aux lettres) :

quit +OK pop3.chez.mon.fai POP3 Server (Version 1.006d) shutdown. Connection closed by foreign host.

Finissons en disant que l'accès aux serveurs SMTP est encore moins sécurisé que celui aux serveurs POP3, il n'y a même pas de mot de passe...