FAMEL Yoan 05/11/2015PAYET YoannBTS SIO – SISR

SISR4Administration des systèmes

Sécurité des accès aux matériels et aux serveurs

Table des matièresIntroduction..........................................................................................................................................2Infrastructure réseau.............................................................................................................................3Mise en place d'un accès sécurisé sur les matériels d'interconnexion..................................................4

Test de piratage du commutateur....................................................................................................4 Sécurisation des accès au commutateur........................................................................................12 Sécurisation des accès au routeur.................................................................................................14

Mise en place d'un accès sécurisé sur un serveur Linux....................................................................18 Mise en place du service sur le serveur........................................................................................18 Sécurisation des accès à partir d'un poste Linux...........................................................................19 Sécurisation des accès à partir d'un poste Windows.....................................................................23

Conclusion..........................................................................................................................................26

1 / 26

Introduction

Dans cette étude nous allons comprendre le fonctionnement de la mise en place d'une sécurité supplémentaire, cette implémentation se fera au niveau des matériels composant notre réseau, soit un commutateur ainsi qu'un routeur de marque CISCO Systems, nous comprendrons le fonctionnement du cryptage des accès par le biais de mots de passe, nous utiliserons également le logiciel Wireshark un analyseur de paquets sous licence GPL connu plus communément sous le nom de sniffer, il nous aidera ainsi à analyser les trames transitant sur le réseau.

Il est possible de retrouver plus d'informations concernant Wireshark en suivant l'adresse suivante,

https://www.wireshark.org/

Je conseille également l'utilisation du site Zataz ou encore 01net afin de se tenir au courantdes dernières failles en termes de sécurité et rester ainsi à niveau pour éviter tout problèmes internes à l'entreprise.

« Zataz, présenté comme un projet personnel du journaliste Damien Bancal, a pour vocation la vulgarisation de l'information concernant principalement la délinquance informatique. Le site se proclame le « premier magazine actualité informatique décalée »1 et prétend ainsi avoir pu aider plus de 8 000 sociétés françaises et une américaine au cours de son histoire »

2 / 26

Infrastructure réseau

Pour la réalisation de ce TP nous mettrons en place un réseau local virtualisé comportant un serveur supposé web Debian 7 et fonctionnant avec le service Apache 2, un commutateur CISCO 2960-24TT ainsi qu'un routeur 2620. Deux postes seront également présents et évoluant sous Windows 7 jouant le rôle d'administrateur.

Voici donc la topologie que nous réaliserons.

Le réseau est en cours de sécurisation au niveau des accès sur les matériels de couche 2 et 3 (commutateur, routeur) ainsi que le serveur Linux.

3 / 26

Mise en place d'un accès sécurisé sur les matériels d'interconnexion

Test de piratage du commutateur

Nous définirons dans un premier temps tout les mots de passe sur le commutateur selon les différents modes, console, telnet, privilégié.

La définition du mot de passe de l'accès en mode console se fait comme suit,

CommutateurA(config)#line con 0CommutateurA(config-line)#password ciscoconCommutateurA(config-line)#loginCommutateurA(config-line)#exit

La définition du mot de passe de l'accès par Telnet se fait quasiment de la même manière,

CommutateurA(config)#line vty 0CommutateurA(config-line)#password ciscoconCommutateurA(config-line)#loginCommutateurA(config-line)#exit

Nous noterons que l'instruction login autorise la connexion, sans elle, la connexion n'est pas réalisable. Pour vérifier que le mot de passe à bien été pris en compte, il nous faudra redémarrer minicom et nous constaterons que le terminal nous demande de nous authentifier via ces mêmes mots de passe.

Nous vérifions dans la configuration du switch,

line vty 0 4 password ciscocon loginline vty 5 15 password ciscocon login

4 / 26

Nous constatons alors que les mots de passe ne sont pas cryptés, en effet, ils s'affichent enclair. Afin de sécuriser d'avantage notre matériel nous allons mettre en place un mot de passe pour le mode privilégié enable, sans ce dernier, il est alors impossible de se connecter à ce mode depuis un accès distant. Par défaut le système IOS de CISCO possède un système de cryptage en md5, nous constaterons par la suite que le mot de passe est belet bien crypté.

Pour ce faire nous définissons donc le mot de passe de la sorte,

CommutateurA(config)#enable secret class

Puis nous vérifions comme mentionné le cryptage de ce dernier grâce à un simple,

CommutateurA#sh run

Ce qui aura pour effet de nous montrer :

enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1

Lors de la reconnexion au mode nous avons bien les deux mots de passe précédemment créés :

User Access Verification

Password:

CommutateurA>enablePassword: CommutateurA#

Par défaut, l'affichage des mots de passe lors de leur entrée n'est pas affiché pour apporterune sécurité supplémentaire, similairement aux systèmes Linux.

5 / 26

Nous n'oublierons pas de donner l'adresse IP présente sur notre schéma au commutateur sur le VLAN 1 par défaut de la manière suivante,

CommutateurA#conf tCommutateurA(config)#interface vlan 1CommutateurA(config-if)#ip address 172.32.1.253 255.255.0.0CommutateurA(config-if)#no shut

%LINK-5-CHANGED: Interface Vlan1, changed state to up

L'accès par console au matériel apporte un avantage quand au fait qu'il faut être physiquement présent afin de se connecter grâce au câble console, cependant il n'est pas toujours simple de le faire c'est pourquoi des accès distants tel que Telnet existe.

Certes le côté pratique de Telnet est attrayant, mais sa sécurité en est des moindre, en effetavec Telnet toutes les informations transmises transitent en clair sur le réseau, y compris lesmots de passe, ce qui permet à un éventuel pirate simplement à l'écoute du réseau d'intercepter toutes les données sensibles qui transiteraient de cette manière.

Nous allons donc démontrer ces faits par la suite en nous plaçant sous le poste Administrateur B que nous avons au préalable renommé et configuré sur notre réseau (Adresse IP et masque).

Nous nous assurons bien entendu de la liaison avec le commutateur grâce à un ping depuis la machine,

PC>ping 172.32.1.253

Pinging 172.32.1.253 with 32 bytes of data:

Reply from 172.32.1.253: bytes=32 time=31ms TTL=255Reply from 172.32.1.253: bytes=32 time=47ms TTL=255Reply from 172.32.1.253: bytes=32 time=31ms TTL=255Reply from 172.32.1.253: bytes=32 time=32ms TTL=255

Ping statistics for 172.32.1.253: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 47ms, Average = 35ms

6 / 26

Nous installerons également l'analyseur de trafic Wireshark pour nos tests.

Il est alors conseillé d'aller sur le site officiel de Wireshark (sécurisé, https) :

Putty sera également nécessaire, cet émulateur de terminal fonctionnant sous Windows estdisponible sur son site officiel, ne pas se fier cependant à l'apparence douteuse du site :

Libre alors à l'administrateur de choisir la version qu'il souhaite, nous choisirons la première, il n'y a pas réellement d'installation et le lancement est rapide.

7 / 26

Une fois Putty lancé nous arrivons alors sur l'interface suivante :

Pour la suite nous sélectionnerons le bouton radio « Telnet » (se situant sur le port 23), et nous ajouterons l'adresse IP de notre commutateur dans le champ approprié.

Dans un même temps nous lancerons notre sniffer de paquets sans oublier de sélectionnerla bonne interface de notre machine :

8 / 26

Pour le savoir nous tape sur l'invité de commande ipconfig et sur Wireshark, nous cochonsl'interface ayant l'adresse mac et l'adresse ip de notre carte. Ensuite, nous cliquons sur Capture All in Promiscuous mode,

Nous cliquons ensuite sur close et nous pouvons lancer la capture des paquets avec start.

Nous ouvrons la connexion Telnet au commutateur via Putty en cliquant sur Open et en saisissant le mot de passe, nous lancerons la commande sh run pour l'exemple, et quittons.

9 / 26

Nous retournons ensuite dans l'interface de Wireshark où nous cliquons sur stop pour arrêter la capture des trames.

À savoir qu'il est possible d'appliquer un filtre afin de retrouver plus simplement et n'avoir que les paquets à destination du site.

Pour cela nous tapons,

ip.dst == « 172.32.1.253 »

dans le champs filter ci-dessous :

De cette manière l'interface nous sera plus synthétique et nous perdrons moins de temps àessayer de retrouver les informations.

Une fois les trames retrouvés il nous est alors possible d'en analyser le contenu pour cela nous cliquons de droite sur celle-ci et nous sélectionnons TCP stream :

10 / 26

Une fenêtre s'ouvre alors, lorsque nous recherchons dans les données nous remarquons alors qu'il est possible de retrouver les mots de passes définis pour le mode Telnet et privilégié.

C'est là que nous remarquons toute la vulnérabilité de cette communication à distance, les mots de passe sont révélés et quelqu'un de malintentionné pourrait alors facilement prendre contrôle de notre matériel si il accède à notre réseau et cela même si les mots de passe sont cryptés dans la configuration du commutateur.

C'est pour cela que nous allons maintenant montrer qu'il est possible de crypter tout les mots de passe du commutateur localement sur le fichier de configuration grâce à la commande,

CommutateurA(config)#service password-encryption

11 / 26

Nous appliquons la commande et vérifions dans la configuration l'application du cryptage :

line con 0 password 7 0822455D0A1606181C login!line vty 0 4 password 7 0822455D0A1606181C loginline vty 5 15 password 7 0822455D0A1606181C

Nous remarquons les mots de passe cryptés par rapport à avant.

Sécurisation des accès au commutateur

Dans cette partie nous allons activer le service SSH sur le commutateur, nous lui créons tout d'abord un nom de domaine :

CommutateurA(config)#ip domain-name sio2gx.local

Et nous y générons une clé rsa cryptée avec la commande suivante :

CommutateurA(config)#ip domain-name sio2gx.localThe name for the keys will be: CommutateurA.sio2gx.local Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

Nous fixons également le délai d'expiration en cas d'inactivité sur le service :

CommutateurA(config)#ip ssh time-out 60

Et le nombre de connexions autorisé de tentatives de connexion sur le commutateur :

CommutateurA(config)#ip ssh authentication-retries 2

12 / 26

Nous limiterons l'accès au commutateur uniquement en SSH,

CommutateurA(config)#line vty 0 15

CommutateurA(config)#transport input ssh

Nous retournons ensuite sur la station de l'administrateur et nous tenterons de nous connecter via Telnet au port 23, ce qui nous retourne l'erreur suivante,

Ce qui est normal puisque la connexion estfavorisé uniquement en SSH.

Nous créons à présent un utilisateur admin ainsi que son mot de passe,

#On créer l'utilisateur par défaut du commutateur

CommutateurA(config)#aaa new-model

CommutateurA(config)#username amin password 0 cisco

Nous lançons ensuite une capture sous Wireshark et nous nous connectons au port 22 du commutateur, nous validerons l'empreinte du commutateur.

Nous lançons une commande sur le commutateur et nous constaterons par la suite que lestrames sont cryptées :

13 / 26

Sécurisation des accès au routeur

Nous allons donc maintenant sécuriser l'accès au niveau de la couche 3, donc du routeur en créant un utilisateur avec un mot de passe qui permettra de se connecter à distance à celui-ci.

Nous paramétrons donc le routeur en lui attribuant dans un premier temps un nom d'hôte ainsi qu'une adresse IP sur son interface (ici FastEthernet 0/1) :

Router(config)#hostname RouteurA RouteurA(config)#interface fastethernet 0/1RouteurA(config-if)#ip address 172.32.1.254 255.255.0.0 RouteurA(config-if)#no shut RouteurA(config-if)#ex

Nous vérifions bien sûr que le statut à bien changé en tant que up en allant dans la configuration du routeur :

RouteurA#show prGlobal values: Internet Protocol routing is enabledFastEthernet0/0 is administratively down, line protocol is downSerial0/0 is administratively down, line protocol is downFastEthernet0/1 is up, line protocol is up Internet address is 172.32.1.254/16

Nous testons la connexion entre les deux matériels,

14 / 26

Puis nous lui définissons un mot de passe pour la connexion par console de la sorte,

RouteurA(config)#line con 0 RouteurA(config-line)#password ciscocon RouteurA(config-line)#login RouteurA(config-line)#exit

Ainsi qu'un mot de passe pour qu'un mot de passe pour le mode privilégié,

RouteurA(config)#enable secret class

En faisant un show run nous constatons alors que ce mot de passe est crypté en md5,

#Cryptage du mot de passeenable secret 5 $1$0Kx7$qFkFD5TDMbTkbAhXenIV1.

Pour que ce dernier fonctionne il suffira de se déconnecter et de se reconnecter au mode privilégié avec enable. Le terminal nous affiche alors :

#demande de mot de passeUser Access Verification Password:

Nous allons également appliquer le cryptage simple des mots de passe afin d'apporter unesécurité supplémentaire, ici le mot de passe console :

RouteurA(config)#service password-encryption

Puis nous y créons l'utilisateur admin ainsi que son mot de passe,

#On créer l'utilisateur par défaut du routeurRouteurA(config)#aaa new-modelRouteurA(config)#username admin password 0 cisco

L'utilisateur créé sera alors l'utilisateur par défaut du routeur.

15 / 26

Nous définirons également le nom de domaine du routeur comme suit,

RouteurA(config)#ip domain-name sio2gx.local

Nous lui générons une clé ssh cryptée avec rsa de la manière suivante :

RouteurA(config)#crypto key generate rsa

Ce qui aura pour effet de nous retourner :

The name for the keys will be: RouteurA.sio2gx.local Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

Nous limiterons l'accès via les lignes VTY en SSH :

RouteurA(config)#line vty 0 4 RouteurA(config-line)#transport input ssh RouteurA(config-line)#exit

Nous retournons ensuite sur la station Windows de l'administrateur et nous tentons une nouvelle connexion en telnet depuis Putty, l'erreur suivante apparaît :

En effet, la connexion s'effectue maintenant uniquement en SSH.

16 / 26

Nous faisons alors un test de connexion en SSH depuis notre autre station administrateur évoluant sous Linux :

Puis nous revenons sur le poste évoluant sur Windows pour effectuer le test suivant dans Putty avec une connexion en SSH (nous lançons au préalable Wireshark pour sniffer les paquets transitant sur le réseau) :

Nous fermons la connexion et arrêtons la capture des trames et constatons alors en rentrant dans une des trames que les données sont cryptées :

17 / 26

Mise en place d'un accès sécurisé sur un serveur Linux

Mise en place du service sur le serveur

Nous téléchargeons dans un premier temps le paquet destiné à installer SSH sur le serveur en vérifiant qu'il ne le soit pas déjà (dpkg -l openssh-server) pour cela nous faisons la commande :

apt-get install openssh-server

Nous vérifions son bon fonctionnement :

Nous paramétrons ensuite notre serveur en lui attribuant son adresse IP afin qu'il soit dans notre réseau,

18 / 26

Sécurisation des accès à partir d'un poste Linux

Nous retournons ensuite sur la machine Administrateur A évoluant sous Linux et nous testons la connexion avec un test ICMP.

Nous lançons ensuite la capture des trames sous Wireshark, puis nous nous connectons auport 22 via SSH au serveur A :

Comme nous le constatons nous devrons valider l'enregistrement avec yes, puis nous saisirons le mot de passe du compte root soit root. L'adresse IP confirme l'authenticité de la connexion.

19 / 26

Nous arrêtons à présent la capture des trames et nous les examinons.

Les données sont entièrement cryptées, ce qui est beaucoup plus avantageux en termes desécurité que le protocole Telnet, qui rappelons le, ne cryptais pas ses données qui elle même s'affichait en clair.

En nous connectant en SSH au serveur nous avons ajouté l'hôte – soit Administrateur A – àla liste d'hôtes connus, en effet, lors de la connexion le shell nous renvoi que l'authenticité de l'hôte ne peut être établie (ce que nous confirmons ensuite par yes), nous supposons que le serveur puisse posséder également l'authentification du matériel de couche 2 et 3.

Par défaut la connexion s'effectue avec le compte root du serveur A, mais il est également possible de se connecter avec un autre compte tel que administrateur par exemple.

Dans ce cas nous saisirons la commande suivante :

administrateur@172.32.1.1

Nous changeons ici simplement l'utilisateur qui se connectera à distance sur la machine.

Nous affichons ensuite la clé publique du serveur en saisissant la commande suivante :

cat /root/.ssh/known_hosts

La copie de la clé publique se trouve alors dans ce dossier de l'arborescence sur le poste administrant le serveur, si sa clé est modifié la connexion n'existera plus.

20 / 26

Cependant pour sécuriser encore plus les échanges, il est possible de nous authentifier par clé publique/privée (chiffrement asymétrique). Cette clé elle même sera crypté grâce à une passphrase de notre création renforçant sa sécurité. Sans cela il y a un risque que celle-ci soit découverte par un tiers et le chiffrement n'est pas effectué.

Toujours sur le même poste – Administrateur B – nous générons une paire de clé publique/privée avec la commande suivante :

ssh-keygen -t rsa

Nous venons ainsi de générer un nouveau de clés dites publique/privée.

Nous listons ensuite le contenu du dossier caché .ssh et nous remarquons alors la présence d'une clé privée id_rsa et d'une clé publique id_rsa.pub :

21 / 26

Nous allons ensuite envoyer la clé publique au serveur par SSH, mais elle peut également très bien être transmise par clé USB en main propre pour éviter encore une fois un vol de données.

Pour cela nous entrons la commande suivante et nous préciserons la passphrase,

ssh-copy-id -i /root/.ssh/id_rsa.pub 172.32.1.1

Ce qui nous donne :

Nous nous connectons ensuite au serveur A pour observer la différence :

À présent nous n'avons pas à utiliser le mot de passe du serveur A, nous utilisons la passphrase qui apporte un niveau de sécurité supplémentaire, sinon nous n'aurions eu aucun mot de passe pour nous connecter.

La passphrase peut également être paramétré de façon à ce qu'elle ne soit valable pendant une session unique, à la close de la session elle n'existera plus.

22 / 26

Nous nous déconnectons du serveur.

Et nous déclarons la passphrase en saisissant :

ssh-add

Nous nous connectons à nouveau avec ssh 172.32.1.1.

De cette manière nous sommes directement connecté sans avoir à saisir de passphrase, celle-ci ayant été déclaré plus tôt.

Sécurisation des accès à partir d'un poste Windows

Pour cette manipulation nous aurons besoin de Putty d'installé, que la station soit bien configuré sur le réseau, nous testons bien entendu comme à chaque fois la connectivité entre le poste et le matériel (ici le serveur) :

Nous lançons ensuite Puttygen et nous y générons une paire de clés publique/privée en cliquant sur Generate. (figure suivante)

Cela peut prendre quelques instant il ne faudra pas fermer la fenêtre et agiter le curseur dans la zone blanche lors de la création afin que ce sois un peu plus rapide.

23 / 26

Voici donc l'interface en question :

Nous confirmerons la génération en inscrivant deux fois la passphrase :

Nous enregistrerons la clé privée en cliquant sur save private key et nous copierons la clé publique.

Nous retournons ensuite sur notre serveur afin d'y ajouter la clé publique dans le fichier authorized_keys.

24 / 26

Pour cela il est possible depuis l'émulateur de terminal lorsque nous sommes connecté en ssh au serveur de coller directement dans l'éditeur de texte nano - après avoir créé le fichier – la clé en question.

Nous fermons ensuite puttygen et redémarrons une session sur putty, dans window nous vérifions que UTF-8 est bien fixé puis dans SSH/Auth nous recherchons notre clé grâce au bouton browse (de gauche à droite) :

25 / 26

Puis dans session nous saisissons l'adresse de notre serveur avant de cliquer sur open pournous connecter, nous n'aurons alors qu'à préciser notre passphrase.

Et nous afficherons également l'adressage de notre machine afin de nous assurer de son authenticité :

Puis nous quitterons la session par un exit.

Conclusion

Il est donc évident que nous préconisons l'utilisation du protocole SSH cryptant les données et trames transitant sur le réseau plutôt que le protocole Telnet qui ne crypte rien,de même l'utilisation d'un système de cryptage par clé est un énorme avantage pour la sécurisation des accès en apportant une authentification supplémentaire et communes à deux entités, dans le cas où l'entreprise aurait à se connecter à distance par exemple.

Il est néanmoins possible de modifier le port par défaut d'un mode de connexion et d'en choisir un parmi la vaste échelle de ports disponibles pour augmenter encore plus la sécurité.

Il est donc toujours important de faire attention tant au niveau personnel que professionnel aux données que nous envoyons et stockons en les protégeant par des moyens adéquats.

26 / 26