[WEB PENTESTING] Be sure that your website is "secure"!

Quand il s'agit de tests d'intrusion externes, nous nous retrouvons souvent face à un serveur WEB en tant que point d'entrée. Par exemple, imaginez que vous deviez auditer la société Suisjesecure, on vous donnera certainement l'adresse IP publique www.suisjesecure.com comme seule et unique information (du moins, s'il s'agit d'un test en aveugle). Si un tel test demande de nombreuses étapes (de la prise d'information à la récupération de données sensibles ou la prise de contrôle d'une partie du réseau), les failles repérées le plus fréquemment sont de type XSS (Cross Site Scripting) ou SQL Injection. Pour cela, nous allons voir comment Firefox peut devenir notre allié pour autmatiser ce genre de tâches.

Installation des extensions :

Les extensions en question sont XSS-me et SQL inject-me de la suite Exploit-me. Comme leur nom l'indique, le premier teste les vulnérabilités de type Cross Site Scripting d'un site tandis que le second teste les failles de type injections SQL.

• Commençons par télécharger les modules XSS-me et SQL inject-me (issus donc de la suite Exploit-me de la société SecurityCompass) ;
• Ensuite, installer les modules en les ouvrant simplement avec votre navigateur Firefox ;
• Une fois terminé, vous n'avez plus qu'à redémarrer le navigateur ;
• C'est tout !

Mise en oeuvre :

Tout aussi simplement, nous allons testé chacun de ses composants. Avant cela, nous pourrons utiliser 0, 1 ou les extensions en fonction du site testé. En effet, en amont, nous devrions regarder si :

a) Le site peut être vulnérable aux attaques de type XSS (présence de scripts, zones de saisie, ...) . Ce point pourra être vérifié en naviguant sur le site, tout simplement ;
b) Le site nécessite l'utilisation d'un base de données. Ceci sera sûrement le cas s'il s'agit d'un site marchand par exemple. Nous pourrons le vérifier aussi avec un scanner de ports comme nmap pour effectuer nos vérifications et même, déterminer le type de la base de données (MySQL, Oracle, PostgreSQL, ...).

En fonction des réponses, nous utiliserons les composants plausibles (inutile de faire du bruit pour rien ;)

Supposons que suisjesecure.com est potentiellement vulnérable aux deux types d'attaques.

1/ XSS-me

Pour utiliser le module, nous nous rendons dans le menu de Firefox : Outils > XSS ME.
Nous pouvons commencer par configurer le composant. Il faut savoir que nous pourrons lancer ensuite soit tous les tests disponibles, soit les X top attaques (X = 9 par défaut). Dans le panneau de configuration, nous pouvons d'une part modifier la valeur de X et d'autre par ajouter ou supprimer des tests d'attaque XSS dans la liste mise à disposition comme nous le montre le premier fond d'écran.
Ensuite, nous pouvons configurer les champs à tester et les tests à exécuter dans l'interface du module comme le montre le deuxième fond d'écran.Nous choisissons de lancer les "top attack" .... résultats :
Pas de chance, tous les tests ont été passés avec succès. Alors tentons cette fois avec les failles de type SQL injections.

2/SQL inject-me

Exactement de la même façon, nous pouvons configurer le composant dans le menu de firefox, puis dans l'interface, une fois le modu lancé. Nous sommes prêts, lançons les tests !

Cette fois, nous voyons quatre tests qui n'ont pas réussis. Des failles ? Regardons plus en détail ?

L'étape suivante est donc d'analyser les résultats et de vérifier la possibilité d'exploiter les failles.

Pour conclure :

Si ces deux composants devraient apporter un maximum d'information dans de nombreux cas, il ne faut pas oublier qu'il existe tout un panel d'attaques ciblant un site WEB. Par conséquent, afin d'être suffisamment exhaustif lors d'un test d'intrusion externe, nous devrons rester rigoureux dans notre démarche et tester les autres types de vulnérabilités (ex : contrôle d'accès).
Aussi, dans le cas d'applications WEB spécifiques, il se peut qu'une commande elle-même spécifique existe. Dans ce cas, elle ne figure pas forcément dans la liste des tests proposés et nous pourrions alors passer à côté d'une faille pouvant être critique. Par exemple, si la base n'a pas été mise à jour avec des vulnérabilités récentes ou si l'application en question n'est tout simplement pas prise en compte. Bref, la vigilance reste donc de vigueur...

[VULNERABILITY ASSESSMENT] MISSION: Find the hole!

Les tests de vulnérabilités occupent une grande place dans les besoins de sécurité des SI pour évaluer la sécurité d'un système ou dans le cadre d'un test d'intrusion. Le but est bien entendu de trouver les faiblesses des serveurs afin d'assurer une sécurité système maximale au final. Pour mieux comprendre ce sujet, je vous invite à lire mon dossier paru dans le magazine Hakin9, n°26 - Juillet/Août. Ma pub étant faite ;), je vous propose d'en voir les points essentiels dans ce blog à travers trois parties : la préparation d'un test, son déroulement et son interprétation.

Introduction et définitions :

Avant de parler de tests de vulnérabilités, je vous invite avant tout à lire la définition d'une vulnérabilité (sur le site de Wikipédia par exemple). Quant aux tests eux-mêmes, ils sont définis par le clusif comme "l'identification de failles connues". Nous ne sommes donc pas dans la même problématique d'un test d'intrusion où ce qui prévaut est la créativité et l'ingéniosité à trouver les faiblesses d'un réseau.

Préparation d'un test de vulnérabilités :

Le but de cette partie est d'essayer d'obtenir les résultats les plus pertinents possible et d'éviter les faux-positifs.

1. Trouver le(s) bon(s) outil(s) :

Il pourrait exister autant de tests de vulnérabilités que de serveurs. En effet, les besoins sont différents en fonction de la machine à auditer et selon, les outils utilisés le seront aussi. Par exemple, dans le cadre d'un serveur WEB, on utilisera très certainement un scanner WEB comme NIKTO. Cependant, un serveur ne se caractérise pas seulement par son rôle principal mais de manière plus complexe (un OS, des comptes, des droits, des partages, etc ...). C'est pour cette raison que pour réaliser un test complet, il faudra utiliser une combinaison d'outils appropriés. Cependant, dans de nombreux cas, NESSUS est l'outil privilégié pour ce genre de tâche. il existe des outils plus complets mais qui entrent plutôt dans le cadre d'un test d'intrusion.

2. Déterminer la nature du test :
Le demandeur devra choisir en premier lieu entre :

• Les tests externes ; Nous simulons un attaquant qui opère depuis le réseau internet ;
• Les tests internes ; Nous simulons un employé de l'entreprise ou un intrus qui s'est infiltré physiquement au sein de celle ci.

Puis, il devra choisir entre :

• Les tests dits "boîte noire" ; tout ce que l'auditeur a à sa disposition, c'est une adresse IP ou un range d'adresses. Il simule ainsi le comportement d'un attaquant.
  
• Les tests dits "boîte grise" ; l'auditeur connaît les informations de bases sur la ou les cibles.
  
• Les tests dits "boîte blanche" ; l'auditeur a accès à toutes les informations qu'il désire sur la ou les cibles.

Le choix se fera en fonction des besoins du demandeur. Par exemple, un test externe en boîte noire révèlera seulement ce qu'un hacker pourra trouver en choisissant l'entreprise pour cible (aléatoire ?) alors qu'un test interne en boîte blanche fournira le maximum d'information et les actions correctives pourront être plus poussées.

3. La configuration de l'outil :

Après avoir pris connaissance des informations nécessaires - ne serait-ce qu'une adresse IP dans le cas d'un test en boîte noire - nous devons nous en servir pour configurer les outils choisis. Si nous prenons par exemple le cas de NESSUS, la configuration s'effectuera en plusieurs étapes ici simplifiée à l'extrême :

• Renseigner la ou les adresses IP (ou noms de serveurs) ;
• Déterminer le(s) type(s) de scan de ports à utiliser (ex : scan TCP, SYN, etc...) ainsi que le range de ports à étudier ;
• Donner les paramètres de connexions vers la serveur NESSUS ;
• Donner les paramètres des tests ("safe check" ou non, "optimize the test" ou non, etc ...) ;
• Activer les plugins nécessaires et seulement ceux-là (un plugin = un module ayant pour fonction d'exécuter un test). Il est possible de désactiver les attaques DoS pour éviter de faire tomber le serveur ;
  
• Et enfin lancer le scan (qui a dit qu'un test de vulnérabilités consistait seulement à cliquer sur le bouton "start" ? ;)

Déroulement d'un test :

La plupart du temps, un test de vulnérabilités consistera en :

• connexion de ports ;
• lancement de module executant des tests ;
• récupération d'information sur les tests réussis et traitement des données.

De nouveau, prenons NESSUS pour exemple car un peu plus complexe mais du coup plus intéressant :

1. L'utilisateur se connecte via son client vers le serveur NESSUS (en effet, cette solution fonctionne en mode client / serveur). La connexion est chiffrée (certificats).

2. Le serveur NESSUS effectue les tests vers la machine à auditer.

3. Pendant cette phase de tests, NESSUS se sert de la base de connaissances pour optimiser l'exécution des tests (entre autres, il enregistrant les informations collectées au fur et à mesure et évite ainsi d'effectuer plusieurs fois les mêmes tests, comme la présence d'un serveur FTP sur le port XX).

4. Les résultats sont renvoyés aux clients qui peut alors générer un rapport.

Interprétation d'un test :

A l'issue de la deuxième phase, nous avons donc en main toutes les informations nécessaires (certainement sous forme de rapport). Peut-être que les mêmes personnes qui pensaient qu'appuyer sur le bouton "start" suffisait pensent que nous en avons fini ? Ce serait une erreur ! Au contraire, la partie la plus importante (et intéressante) va commencer...

Pour cela, voici le résumé des étapes ;

• Repérer les failles réelles ou éventuelles parmi les alertes relevées par le scanner,
• Evaluer la pertinence de chaque faille,
• Evaluer l'importance de chaque faille (criticité, impact, risque),
• Ajuster les évaluations en fonction des conditions de tests (zone critique ou non, serveur critique ou non, etc ...) et des paramètres des tests (attaques DoS activées ou non, mode "safe check" ou non, etc ...).

Augmenter le niveau de pertinence des résultats en ;

• Eliminant les incohérences évidentes (ex : faille concernant un SOLARIS 8 alors que nous sommes en version 10),
• Trouvant les intéractions entre les alertes (ex : "un mot de passe n'a jamais été changé" et "une "le mot de passe n'expire jamais selon sa politique de sécurité"),
• Eliminer les derniers faux-positifs grâce à NASL - langage dans lequel sont écrits les plugins - en l'utilisant en ligne de commande ou en créant ses propres plugins,
• Utiliser plusieurs outils pour confirmer ou non une faille.

Ensuite, il faudra agrémenter le rapport avec ;

• Des explications sur la faille et le risque encouru (travail de sensibilisation),
• Des solutions contenant des actions correctives concrètes et réalisables,
• Des références (documents, références CVE ou autre),
• Une évaluation globale de la sécurité avec les conseils avisés de l'auditeur.

Pour conclure :

Un test de vulnérabilités n'étant pas aussi complet qu'un test d'intrusion, nous ne pourrons pas tout voir dans notre cas. Cependant, à l'issu de notre travail, nous devrions avoir repéré les problèmes majeurs aux niveaux OS et applicatif. Mais "savoir" ne suffit pas. Pour que la tâche ait vraiment un intérêt, il faut pouvoir appliquer les actions correctives et alors réellement augmenter le niveau de sécurité du système audité. Evidemment, un travail de fond serait à envisager pour obtenir les meilleurs résultats : il s'agirait en amont de déterminer des politiques de sécurité, un hardening des OS strict et en aval de maintenir le niveau de sécurité à travers une gestion de correctifs continue accompagnée d'une veille de vulnérabilités. Bref, c'est ce qu'on peut appeller un cycle vertueux, non ?

[SIM] MISSION: Watch everything!

Dans de nombreuses tâches de sécurité, il faut faire appel aux logs. Mais il s'agit certainement de l'une des tâches des plus difficiles car deux problématiques essentielles se posent : où chercher ? et comment ne pas manquer l'information utile parmi tous les logs fournis par l'ensemble du réseau (serveurs et équipements réseau) ? La solution existe depuis un moment maintenant et son nom de code est SIM pour Security Information Management. A travers l'exemple Open Source nommé OSSIM, nous verrons les caractéristiques et les réponses techniques apportées par ce type d'outils.

Identification :

• Définition ;
  

Un SIM est un moteur de corrélation dont la puissance peut être évaluée par le nombre de logs qu'il peut traiter à la seconde et les types d'information qu'il est capable de comprendre. A l'issue de cela, un SIM corrèle les logs selon des règles pré-établies afin de remonter des alertes en (quasi) temps réel.

• Caractéristiques basiques ;

S'il existe de nombreux SIMs sous forme d'appliance, OSSIM est entièrement software. Il a plusieurs but principaux qui sont de superviser et de piloter la sécurité d'un (sous-)réseau dans sa globalité. En effet, il prendra en compte aussi bien les serveurs (quelque soit l'OS) que les équipements réseau (pare-feu, routeurs, etc...). Pour cela, notre SIM utilise une architecture client / serveur. Nous aurons d'une part la partie serveur sur lequel tournera un service pour l'affichage de la console de pilotage et d'autre part, les clients qui sont en réalité ni plus ni moins des agents. Ces derniers auront simplement pour rôle de collecter des informations et de les renvoyer vers le serveur. Comme nous l'avons compris, OSSIM est une solution Open Source par sa conception mais aussi par les modules (appelés sensors) utilisés. En effet, pour collecter les informations nécessaires, notre corrélateur se base sur les outils les plus connus de la communauté Open Source utilisés en tant que "sensor". On parle alors de SNORT/ACID, NESSUS, NMAP, NTOP, p0f, TCPTrack, Syslog, PADS et NAGIOS.

• Caractéristiques avancées :

A - La corrélation

La corrélation se fait à partir de toutes les informations récoltées par les agents, chacun devant être disposés sur des noeuds stratégiques du réseau à superviser. Ensuite, les informations sont traitées en les confrontant. Premier avantage, on réduit le nombre de faux-positifs qu'un sensor à lui-seul fournirait (ex : SNORT). La corrélation peut être détaillée en trois étapes :

1. Cohérence des données - OSSIM commene par examiner la cohérence des données collectées pour en déterminer la pertinence. Grâce à un inventaire de matériel et de logiciels présents sur le réseau, nous saurons que tel serveur utilise IIS par exemple. Si une alerte à propos de cette même machine concerne Apache, le score de pertinence sera très faible.
2. Correspondance des données - OSSIM a aussi à sa disposition une table de correspondance alertes-versions et alertes-vulnérabilités fournies par SNORT et NESSUS. Ainsi, supposons qu'une alerte remonté par SNORT correspond à une vulnérabilité connue après un scan de NESSUS, le score de pertinence sera cette fois élevé.
3. Les directives logiques - Pour terminer, notre solution fonctionne aussi avec des directives ou règles qui permettent de corréler des anomalies, des alertes et des états (fournis via les moniteurs).

B - La prioritisation ;

Pour qu'une solution de sécurité soit efficace, il faut que celle-ci s'adapte au mieux aux particularités et aux exigences de l'environnement où nous désirons la déployer. OSSIM est capable de répondre aux questions suivantes :
1. Qu'est-ce qui est important pour la sécurité ?
2. Quelles sont les adresses sources que l'on redoute avant tout ?
3. Quelles sont les adresses de destination les plus critiques ?

Par exemple, nous admettons qu'une attaque provenant d'Internet et ayant pour cible une adresse interne de notre réseau est prioritaire, d'autant plus s'il s'agit d'un serveur financier plutôt qu'un serveur d'impression. Alors, nous pourrons via notre SIM donné un score de priorité entre 0 (priorité minimale) et 5 (priorité maximale) pour chaque équipement réseau.

C - L'évaluation des risques ;

Grâce à la combinaison de plusieurs éléments, OSSIM est capable d'évaluer le risque d'une attaque en cours. Il se base sur :

1. L'algorithme CALM (Compromise et Attack Level Monitor).
2. Les directives (pré-établies ou écrites).
3. Des seuils de tolérance.

Ce système de points fait l'objet d'un calcul qui permet d'évaluer le niveau de l'alarme :

niveau_alerte = (importance_machine * prioritisation * risque) / 10

Le tableau de bord d'OSSIM :

A travers un exemple concret d'attaque et d'investigation, voyons le tableau de bord fourni par la solution. Celui-ci est founi via un portail WEB. A noter que des fonds d'écran sont disponibles sur le site d'OSSIM.

• Le panneau de contrôle général ; Fournit les informations globales (niveau de sécurité actuel de l'ensemble du réseau, alerte la plus grave pour le réseau, les sous-réseaux, les serveurs). Aussi, on y trouve un graphe avec le nombre de machines éventuellement attaquées et attaquantes (après compromission).

• Le riskmeter. Si le premier panneau montre un problème (ex : nombre de machine attaquées en augmentation), nous nous dirigeons vers le riskmeter qui est un graphe en barre dont la valeur augmente dans le même temps qu'une attaque s'intensifie. par exemple, lors d'un scan massif, au fur et à mesure des scans, nous verrons la barre correspondant à la machine cible avancer en temps réel. Quelque chose se prépare !
  
• Le tableau d'alerte. Ici sont regroupées les alertes remontées par SNORT et visualisées avec l'interface ACID ou BASE (au choix). Chaque alerte peut correspondre à une phase de l'attaque.
  
• Le tableau d'alarme. L'ensemble des alertes relevées en 3 peuvent constituer une alarme après corrélation. Dans ce nouveau tableau, nous voyons les attaques repérées (ex : la propagation d'un vers) et le niveau de l'alarme (de 0 à 10).

• La gestion d'incident. Il est donc temps d'agir alors, on utilise l'outil de ticketing qui permettra d'alerter les personnes concernées de l'attaque en cours. La réactivité est de mise dans ce genre de situation.
  
• Les statistiques. Une fois l'incident repéré et traité, il ne faut pas que cela se reproduise. Grâce aux panneaux fournis par NTOP entre autres, nous pourrons trouver des indices par rapport à l'origine de l'attaque. Aussi des tableaux comme le top 20 des attaques nous permettront de concentrer nos efforts sur les points les plus critiques de notre S.I.
  

Les résultats fournis par OSSIM :

Un tel outil n'a de sens que s'il est en mesure de fournir différents résultats qui nous aideront à gérer les incidents, à fournir les informations nécessaires en cas de forensics, à dessiner les graphes qui vont bien pour évaluer la sécurité de son S.I et en trouver les points faibles (dans le but d'y remédier bien sûr).

C'est donc sous forme de mails, ticketing, graphes, tableaux et rapports (PDF, HTML, ...) que nous aurons à disposition toutes les informations nécessaires.
Les informations obtenues, étant de différentes natures, pourront soit être utiles à un Administrateur Sécurité (rapport technique, relevé d'incident,...) soit à un RSSI (statistiques, top20, synthèses).

D'autres information dans l'article d'Hakin9, numéro 10/2007.

[FORENSICS] MISSION: catch the attacker!

*** A L E R T E *** Une intrusion a été signalée ! Nous devons absolument retrouver l'attaquant afin que son crime ne reste pas impuni. Difficile ? Non, impossible ! Sinon, ce serait trop facile pour l'agent que nous sommes ;)

L'enquête :

• Recherche d'indice

Les pistes sont nombreuses et selon la circonstance, il faudra trouver les bons filons. Les logs représentent évidemment les éléments clés de nos recherches mais de quelle nature peuvent-ils être : en réalité, il peut s'agir des logs DNS, logs du serveur WEB (e.g Apache ou IIS), du serveur Mail, tout serveur applicatif (FTP, Base de données, etc...). Au niveau système, l'Event Viewer d'un machine Windows ou la base Syslog sont des sources à ne surtout pas négliger. Ensuite, nous devrions penser aux équipements réseau comme les routeurs, pare-feu, proxies, VPNs, ISP et autres "intermédiaires" qui ont pu enregistré des traces. Une autre piste concerne les fichiers de configuration. Dans un premier temps, nous pouvons regarder les fichiers réseau par exemple comme xinetd.conf. Plus tard, au fur et à mesure des indices trouvés, nous regarderons de plus près les fichiers de configuration associés susceptibles d'avoir été modifiés.

Aussi, chaque phase de l'attaque peut révéler un indice intéressant. Par exemple, un mail laissé lors d'une attaque de type phishing, un message quelconque (à travers quelle application ?), une connexion ou un port resté ouvert (e.g. Une porte dérobée).

Nous partons du principe que l'attaquant s'est forcément connecté sur un point (ou plus) de notre réseau et à partir d'un point (de notre réseau -dans le cas d'une machine compromise - ou non).

De cette manière, la plupart du temps, nous devrions trouver une adresse IP. Elle représente le point de départ de la deuxième phase de notre investigation.

• Localisation de l'attaquant

Notre suspect aura donc certainement laissé des traces de son passage mais il est possible d'en trouver nous-mêmes. Maintenant que nous connaissons son ou ses adresse(s) IP, nous pouvons partir à la recherche d'information ciblée. Pour cela, nous disposons sur Internet de nombreux éléments comme les bases WHOIS. Aussi, GOOGLE - à travers des requêtes intelligentes - pourra se montrer riche en indices et en preuves. Le WEB constitue donc une composante essentielle dans notre démarche. Pour localiser l'attaquant géographiquement, ce site de Geobytes nous permettra d'obtenir la réponse.

A l'action :

• Prise d'information active

Selon les informations trouvées précédemment, nous pourrons les compléter avec des commandes réseaux comme NETSTAT, NBSTAT, TRACEROUTE, ... et différents outils comme NMAP, Caïn&Abel, NIKTO, WHIRESHARK, un simple navigateur ou un client de messagerie pour trouver les informations d'un mail. Pour l'investigation, il est très utile d'avoir à sa disposition des solutions de sécurité comme un IDS (ex : SNORT) ou un IPS. Des alertes seront ainsi générées et nous fourniront des informations complémentaires dans ce genre de situation. De même, en mettant en place le module d'Apache MOD_SECURITY, nous pourrons non seulement filtrer les requêtes mais aussi avoir à notre disposition des données importantes. Un autre système, nommé TRIPWIRE, lancera quant à lui des alertes dans le cas d'une modification d'un fichier. Comme nous l'avons vu plus haut, des fichiers de configuration - critiques certainement - pourront être modifiés pendant l'attaque. Cette dernière solution est donc un bon moyen de repérer ce genre d'incident. Dans la perspective d'obtenir des alertes en temps réel en cas d'attaque, un SIM (pour Security Information Manager) nous fournira un grand nombre d'information utile comme le type de l'alerte, la ou les cible(s), la ou les source(s), la nature et l'évaluation de l'attaque entre autres. Il existe d'ailleurs une version Open Source appelée OSSIM.

Dans un tout autre registre et à vrai dire pas toujours exploitable, il ne faut cependant pas oublier l'analyse de la mémoire des machines touchées. Pour cela, un outil comme Volatools (cf. ici pour plus d'information) pourra s'avérer très utile.

Pour un besoin plus spécifique mais dans certains cas indispensables, un debugger peut être un moyen supplémentaire de retrouver des informations compromettantes. Imaginons par exemple le cas d'un programme malveillant installé suite à la compromission d'un serveur. Alors, debugger un programme nous permettra de l'analyser et en comprendre le fonctionnement jusqu'a en trouver des informations probantes sur l'attaquant. Niveau outil, on peut utiliser par exemple ELFsh. En complément, citons la checklist proposée par SANS.

• Arrêter le coupable

Arrêter le coupable suppose que nous sommes sûr de notre suspect. Le bénéfice du doute n'est pas permis. Cependant, comme dans toute enquête, son activité (informatique j'entends) pourra confirmer ou non nos résultats. Ensuite, trouver le client d'un backdoor correspondant au serveur sur son poste peut de nouveau peser dans la balance. D'ailleurs, l'ensemble de son système devrait nous apporter les preuves nécessaires. par exemple, la commande history pourra nous permettre de retracer l'attaque. Si on juge que nous avons trouvé la bonne personne, il est temps de déconnecter cet intrus et d'imposer les restrictions nécessaires et de le sensibiliser à ses actions.

• Effacer les traces
  

Une fois le coupable mis hors d'atteinte, il ne faut pas oublier que notre machine a été infectée. Evidemment, le bon reflexe aura été d'isoler la machine en premier lieu, et ce, avant toute investigation. Ensuite, nos recherches devront s'axer vers les portes dérobées et tout programme installé à notre ainsi. En réalité, le meilleur et seul moyen de s'assurer que notre machine est de nouveau saine, c'est de la formater entièrement. Par contre, il faudra absolument garder une copie des logs : d'une part ils pourront toujours être utiles de nouveau et d'autre part, ils seront certainement nécessaires d'un point de vue légal. Mais le formatage ne suffira pas. Il faudra ensuite installer de nouveau le système d'exploitation, les applications, tous les correctifs nécessaires, reconfigurer la machine (fichiers de configuration, comptes et groupes, ...), la scanner et la remettre en production seulement une fois que son niveau de sécurité est satisfaisant.

Cas d'étude :

Après le briefing, passons à la pratique. Pour des exemples plus complexes et - un peu plus fantaisistes aussi :) -, je vous recommande les livres Hacker's Challenge 1, 2 et 3. Mais de manière plus concrète, je vous proposerai prochainement dans ce blog un exemple rencontré.