Analyse d’une architecture réseau

Présentation au sujet: "Analyse d’une architecture réseau"— Transcription de la présentation:

1 Analyse d’une architecture réseau
Mastère SSI Module M9 Jean-Christophe GALLARD

2 Plan du Cours Introduction Méthodologie - une introduction
Limites de telles analyses Prise d’empreinte Utilisation des outils d ’audit Identification et exploitation des vulnérabilités Le rapport d’analyse Conclusion

3 Introduction

4 Introduction A quoi sert un audit technique?
=> Fournir un « instantané » technique objectif de l’état de la sécurité d’un Système Deux grand types d’audit : « Boîte blanche » « Boîte noire » (red team, pen test - test intrusif en conditions quasi réelles)

5 Introduction Audit « boîte blanche » :
type d’audit dans lequel l’auditeur dispose : de toutes les informations voulues (documentation, administrateurs…), d’un accès physique aux éléments constitutifs du Système d’Information volonté d’exhaustivité des vulnérabilités (vœux pieux…)

6 Introduction Audit « boîte noire » :
type d’audit dans lequel l’auditeur se place dans la position d’un attaquant probable (dénommé également « test intrusif »). L’attaquant supposé n’est pas nécessairement un pirate sévissant sur l’Internet (attaquant interne à l’entreprise par exemple) Les informations utiles ne sont pas forcément toutes disponibles On cherche surtout à démontrer la faisabilité d’une attaque depuis un point donné.

7 Introduction Différences entre les deux méthodes: motivations
furtivité (quoi que…) phase d’apprentissage plus lourde en boite noire résultats plus riches en boîte blanche Similitudes : mêmes outils à de rares différences près mêmes techniques PAS de garantie d’exhaustivité => raisons pour lesquelles ce même cours recouvre les deux aspects

8 Méthodologie - une introduction

9 Problématique de l’analyse de vulnérabilités
Que cherche t-on ? Quelles sont les conditions initiales (accès local, distant…) Jusqu’où est on autorisé à aller ? Problèmes légaux

10 Traçabilité des actions (1/2)
Toute analyse technique revêt une part de risque : pour l’audité (mise à mal de son système, déni de service, traces mal effacées…), et ses éventuels partenaires (dommages collatéraux ?) mais aussi pour l’auditeur (risque juridique - code pénal)

11 Traçabilité des actions (2/2)
D’ou une nécessité de TOUJOURS tracer la moindre action : journal de bord logs des outils logs systèmes keylogger ...

12 Les bases de vulnérabilités (1/2)
Domaine très vaste Présentes sous deux formes : bases formelles : souvent présentes dans les outils d’analyse automatique et couplées aux « exploits » correspondants, bases informelles : bases personnelles, mais surtout sites Internet spécialisés

13 Les bases de vulnérabilités (2/2)
Quelques sites incontournables : Packetstorm (miroir France) SecurityFocus La liste bugtraq / NTBugtraq Le site CVE : CERT Microsoft

14 La prise de renseignement technique (1/2)
Notion de prise d’empreinte (fingerprinting) Principe de base : « Chaque système trahit son existence et ses paramètres par son comportement »

15 La prise de renseignement technique (2/2)
Principalement utilisée en boîte noire, mais peut être une précieuse alliée même en boite blanche Techniques actives et/ou passives En boîte blanche ; sert de complément indispensable à l’analyse des documentations fournies => vérification de leur justesse et situation réelle comparée à celle supposée

16 L’identification des vulnérabilités (1/2)
Un seul outil reste vraiment indispensable : Un cerveau (standard et de préférence en état de fonctionnement)

17 L’identification des vulnérabilités (2/2)
Des outils + ou - automatiques peuvent être employés : scanners de services (port scanners) scanners de vulnérabilités (spécifiques ou généralistes) outils standards détournés de leur utilisation normale (telnet, traceroute, nslookup…) outillage réseau complémentaire (sniffers, générateurs de paquets)

18 L’exploitation des vulnérabilités
La mise de jour de certaines vulnérabilités peut amener à progresser plus avant dans le système si on les exploite En boite boire : c’est un peu le but du jeu… En boîte blanche : ATTENTION à ne pas outrepasser ses droits A tracer avec la plus extrême minutie

19 Limites des analyses

20 Limites techniques / exhaustivité des résultats
La qualité des résultats obtenus reste fortement dépendante des facteurs suivants : caractéristiques des moyens de com (débit du point d’accès, QoS…) efficacité des outils de tests à disposition efficacité des moyens de filtrages entre « l’attaquant » et sa cible présence ou non de contres-mesures (IDS, systèmes réactifs, honeypot…) types de protocoles utilisés... Dans tous les cas il n’existe AUCUNE garantie d’exhaustivité => problème du niveau d’assurance

21 Contraintes Certaines contraintes techniques et/ou organisationnelles peuvent s’avérer particulièrement pénalisantes pour l’auditeur : méfiance des utilisateurs / administrateurs (boîte blanche) => rétention d ’information, voire désinformation débit du point d’accès insuffisant pour mener certains tests nécessité de mener des tests furtifs délais d’audit très courts Déni de service

22 Problématique du déni de service
De nombreuses vulnérabilités en déni de service ne peuvent être mises en évidence qu’en réalisant le test « en live ». => si le test est positif, le système cible devient hors service ! => l’auditeur censé améliorer la sécurité devient alors celui qui la dégrade... Une règle : ne JAMAIS réaliser de test en DoS sauf en cas de demande écrite explicite.

23 L’abaissement du niveau de sécurité d’origine
Un mal nécessaire ? Progresser dans un SI nécessite parfois que l’auditeur (en particulier en red team) s’installe une ou plusieurs portes de services dans le système cible. Conséquence : cette action dégrade la sécurité du système cible Si cette action apparaît inévitable ; faire en sorte de protéger ces entrées de services. Toujours avertir le responsable avant l’introduction d’une telle porte d’entrée

24 La prise d’empreinte

25 Techniques passives (1/2)
Technique de base : le « sniffing » Analyse de flux binaires sur un réseau : identifier les machines et leurs rôles, les services utilisés, les utilisateurs, les habitudes de fonctionnement De très nombreux outils disponibles (de 0 à €), plus ou moins performants et spécialisés

26 Techniques passives (2/2)
Reconstitution de l ’architecture d ’un réseau : Cette phase, souvent utilisée en Red Team simulant une attaque interne, consiste à tenter de reconstituer l ’architecture d’un SI à l ’aide d’informations récupérées passivement. sera par la suite complétée par des investigations actives

27 Techniques actives (1/9)
Exploitation des particularités des protocoles réseau : En-têtes Ethernet (id constructeur) Protocoles ARP/RARP ICMP (traceroute, enregistrement de routes, messages de paquets détruits, pings…) broadcasting (ethernet, IP) Bannières de connexions

28 Techniques actives (2/9)
Environnements commutés : dans un environnement switché, il n’est plus possible de capturer tout le traffic sur un segment de réseau. Cependant, il est parfois possible de contourner la difficulté : Trames de broadcast (passif) passage du switch en mode « diffusion » (aggressif) manipulation ARP/RARP

29 Techniques actives (3/9)
Le « port scanning » : « déterminer la liste exhaustive des services réseaux disponible sur une machine donnée » Utilise les particularités des protocoles TCP-UDP/IP : Syn Scan (scan classique) Half Syn Scan (furtivité de base) Idle Host Scanning (furtivité évoluée) … Très nombreux outils (nmap : la « star »)

30 Techniques actives (4/9)
Principe de base de détection de port TCP ouvert : Client Serveur SYN ACK, SYN ACK Toute réponse d’acquittement à une trame de type SYN implique que le port TCP correspondant est ouvert (poursuite des échanges)

31 Techniques actives (5/9)
Technique du Half-Syn Scan : Identique au SYN scan à ceci près que, lors d’une réponse « ACK,SYN », l’attaquant ne poursuit pas les échanges => comme la connexion n’est pas menée à son terme, rien n’apparaît dans les éventuels logs du système.

32 Techniques actives (6/9)
Technique de l’Idle Host Scanning : on utilise une machine tierce, inactive et dont les numéros de séquence TCP sont prévisibles utilisation de Hping pour émettre des paquets IP à la cible et dont l’adresse source est falsifiée (source = machine tierce) envoi de trames (hping) à la machine tierce et analyse des numéros de séquences renvoyés Vu de la victime : c’est la machine tierce qui réalise les scans

33 Techniques actives (7/9)
Cas 1 : port TCP ouvert C A 1 : Src = B Cible Attaquant 2 : ACK, SYN 3: RST 4 : requêtes IP 5 : Réponses IP car paquets RST émis dans (Sauts de séquences l’intervalle) B Machine Tierce Plus de prévisibilité des numéros de séquence : => Le port est ouvert

34 Techniques actives (8/9)
Cas 2 : port TCP fermé C A 1 : Src = B Cible Attaquant 2 : RST 3 : requêtes IP (pas de sauts de séquences) 4 : Réponse IP Poubelle ! B Prévisibilité des numéros de séquence maintenus => Le port est fermé Machine Tierce

35 Techniques actives (9/9)
OS Fingerprinting : détection de système d’exploitation Plusieurs techniques « ancestrales »: état global des services disponibles (+ ou - fiable) bannières de connexion (problèmes de falsification ou d’absence) exploitation de certains services réseaux (ex : Netbios) Méthode de Fyodor (nmap): technique la plus aboutie « repérer les particularités des piles TCP/IP des OS par analyse des réponses à des requêtes IP données » il existe cependant des patchs (Linux) pour leurrer cette technique (IP personality)

36 Détection des paramètres de configuration d’un OS (1/2)
Les services « bavards » : certains services réseau donnent de nombreuses informations sur l’état de configuration d’un OS => exploiter ces particularités pour se renseigner. Finger, SNMP FTP et bien sûr : SMB-CIFS / NetBios

37 Détection des paramètres de configuration d’un OS (2/2)
Cas de Windows Les services réseau de Windows sont TRES bavards En outre, selon la configuration choisie, la récupération d’information peut se faire sans être authentifié sur le système cible. LanGuard NetWork Scanner Winfingerprint Hyena ...

38 Utilisation des outils d’audit

39 Les scanners de vulnérabilités (1/2)
Les « Stars » : ISS Nessus Saint Cybercop Scanner (anciennement Balista)

40 Les scanners de vulnérabilités(2/2)
Offre du marché (non exhaustif):

41 Mise en œuvre de scanners de vulnérabilités (1/2)
Ciblage et paramétrage : ne mener que les tests utiles Démarche incrémentale : Zero knowledge Anonymous mode User mode Admin mode

42 Mise en œuvre de scanners de vulnérabilités (2/2)
Dépouillement des résultats : quelles vulnérabilités retenir ? Sont elles pertinentes ? Sont elles exploitables ? Dans quelles conditions ? Peut-on s’en protéger ? Comment ? => détermination du chemin d’attaque

43 Tests Manuels Complément aux tests automatiques
Constitue un « ciment » pour l’audit technique Exemples en boîte blanche : vérification de la configuration locale d’une machine analyse d’un fichier de filtrage (routeur ou firewall)

44 Quelques outils complémentaires

45 Identification et exploitation des vulnérabilités

46 Identification et exploitation des vulnérabilités
La phase de dépouillement doit permettre la mise en évidence des vulnérabilités exploitables sur le système cible. Cette liste peut être exploitée afin de poursuivre les investigations : démarche incrémentale Mise en évidence de chemin(s) d’attaque et, surtout, des chemins critiques : permettra de valuer les vulnérabilités... ...et de prioriser les corrections

47 Le rapport d’analyse

48 Généralités L’objectif du rapport d’audit est de fournir à l’audité les éléments nécessaires à une meilleure sécurité de son système d ’information A ce titre, il ne doit pas constituer une simple liste « à la Prévert » des failles décelées. Chaque faille doit être pondérée en fonction : de sa gravité, de son caractère exploitable ou non, et dans quelles conditions.

49 Généralités Un rapport d’audit doit également préciser une proposition de plan d’action personnalisé pour améliorer la sécurité : du général au particulier ne pas hésiter à regrouper les failles décelées sous une même contre-mesure lorsque cela est possible proposer des jalons temporels chiffrer les coûts (financiers, mais surtout humains), même approximativement adapter le plan d’action à l’audité (capacités financières et humaines, temps nécessaire…)

50 Quelles informations donner ?
Deux approches : Exhaustive : toutes les vulnérabilités sont listées Synthétique : on ne donne que les points les plus durs Solution optimale : opter pour un mélange des deux approches : une synthèse courte des problèmes rencontrés, essentiellement à l’attention des décideurs une ou plusieurs annexes, plutôt destinées aux administrateurs.

51 Quelles informations donner ?
Ne pas hésiter à marquer les esprits en disant les choses telles qu’elles sont : un auditeur est avant tout une personne extérieure au système, présentant ses résultats sans compromis et de la façon la plus objective. Toujours rester factuel, bannir le « flou artistique ».

52 Conclusions