audit_réseau

Rapport dAudit Projet Scurit Rseau

MASTER2 S.T.R.I. 1 Dcembre 2007

Comit dAudit S.T.R.I.

ETUDIANTS :

Jonathan Blanc

David Gerbaulet

Julien Manuel

David Nembrot

Simon Pachy

Dimitri Tsiopoulos

PROJET SECURITE RESEAU

Groupe Analyse



SOMMAIRE

I. Introduction........................................................................................................................ 3 a. Situation ..................................................................................................................................... 3

b. Objectif ....................................................................................................................................... 3 III. Distribution des tches :................................................................................................. 5

a. Diagramme organisationnel ..................................................................................................... 5

b. Rles............................................................................................................................................ 5

c. Planning...................................................................................................................................... 7

d. Mise en place et dmarrage de lactivit ................................................................................. 8

III. Partie AUDIT ............................................................................................................... 10 a. Prsentation brve de larchitecture cliente : ....................................................................... 10

b. Tches et Ralisations : ........................................................................................................... 11 Contrat................................................................................................................................................ 11 Cahier des charges............................................................................................................................. 11

c. Mise en place de la Mthode MEHARI................................................................................. 12

d. Mise en place de la Sonde : ..................................................................................................... 14 Lanalyse de logs :.............................................................................................................................. 16 Synthses et rdactions des rapports : ............................................................................................. 16

e. Premire Phase ........................................................................................................................ 17 Objectifs viss..................................................................................................................................... 17 Observations durant la confrontation.............................................................................................. 18 Rsultats de lanalyse de log et conseils la dfense....................................................................... 19 Implmentation de nouveaux outils : ............................................................................................... 19

f. Seconde Phase :........................................................................................................................ 20 Objectifs viss..................................................................................................................................... 20 Observations durant la confrontation.............................................................................................. 20 Rsultats de lanalyse de log ............................................................................................................. 24 Implmentation de nouveaux outils : ............................................................................................... 24

IV. Bilan.............................................................................................................................. 25 a. Bilan de laction auprs de la Dfense ................................................................................... 25

b. Bilan de notre organisation..................................................................................................... 25

VI. Annexes......................................................................................................................... 28



I. Introduction

a. Situation

Dans le cadre du cours de scurit des systmes dinformation, il a t mis en

place plusieurs approches mtiers concernant cette dernire.

Trois groupes de six personnes ont t form avec pour chacun deux des buts

diffrents ; tout se base sur la mise en place dun rseau scuris par le groupe

Dfense, sur lequel le groupe Attaque tente de sinfiltrer, de rcuprer des donnes

ou de crer des dnis de service. Paralllement cela, le groupe Audit, met en

place une supervision en troite collaboration avec le groupe Dfense afin de

prvenir toute intrusion et de pouvoir ragir.

Cest ce dernier groupe que nous formons et que nous allons vous prsenter tout

ce qui a t mis en place et a t effectu dans le cadre de notre mission.

b. Objectif

Notre groupe dAnalyse sest fix quelques grandes lignes suivre afin dvoluer

de faon cohrente, notamment de manire atteindre les objectifs inhrents

une supervision de rseau.

Ces derniers ont t amen voluer tout au long du projet en raison du

manque de vision sur un domaine qui nous t encore quelque peu inconnu.

Dans un premier temps les critres de russite que nous nous sommes fixs taient :

Prouver quavec un groupe htrogne du point de vue technique, social et

dun point de vue du management, on tait capable de fournir un travail

clair, propre et sans erreur, ou du moins limites.

Faire preuve dune grande communication, coordination afin de gommer

cette htrognit.

Sur le plan plus technique :

Savoir prdire les failles du systme de scurit mis en place par la dfense.

Dgager les responsabilits, les objectifs et les moyens mis en uvre en les

explicitant dans un contrat dtaill et exhaustif.



Dchiffrer trs clairement les logs des diffrents systmes de supervision mis en

place afin dexposer les grandes lignes au groupe de Dfense.

Suite cela se sont vu ajouts :

Ragir au plus vite suite un dni de service et savoir en informer le groupe

dfense sans perdre de temps afin dallier nos forces pour viter que cela ne

se reproduise.



III. Distribution des tches :

a. Diagramme organisationnel

Gnralits :

Des rfrents ont t dsigns dans chaque ple. Il ntait pas fig et pouvait

tre modifi tout moment sur accord de chaque protagoniste. Toute modification

devait tre reporte lensemble de lquipe.

Jonathan et David N. ont t les rfrents sur les ples Commercial et Technique.

b. Rles

Manager : David G.

- Dfinir les objectifs de chacun, essayer dtablir la charge de travail ncessaire

chaque tche (Diagramme de Gantt) et dorganiser et mettre en relation tous les

acteurs du projet (Aussi bien de notre quipe Analyse que de lquipe Dfense),

- Cerner tous les lments (commercial, juridique et technique) du projet afin que,

mme en labsence des diffrents experts, il y ai une redondance des informations

et la possibilit davoir au moins un interlocuteur comptent face aux demandes de

lquipe Dfense.

- Se pencher sur les diffrentes mthodes daudit

Manager

David G.

Ple Commercial et

juridique

Jonathan B. et Dimitri T.

Ple technique

David N. et Simon P.

P.

Aspect

rdactionnel et pluri

comptence

Julien M.



- Tenir informer lquipe Analyse des dates de runions, des sujets, des participants,

des objectifs et faire transiter les informations.

- Participer lpluchage des logs aprs les confrontations.

Ple Commercial et Juridique : Jonathan B. et Dimitri T.

- Etablir un cadre juridique et commercial entre les deux parties (Contrat entre la

Dfense et Analyse)

- Vrifier lapplication de la politique de scurit au jour le jour et rapporterez,

lensemble de notre quipe ainsi qu lquipe Dfense, les vices de procdures sil

y en a,

- Rdiger des avenants signs par les deux parties pour rgulariser la situation si

besoin.


Ple techniques : David N. et Simon P.

- Rles cls de lquipe. En effet, Il nexiste pas daudit performant sans des experts

techniques tout aussi performant.

- Installer la sonde et les outils adquats.

- Identifier les diffrentes failles de lquipe Dfense et les attaques raliss par

lquipe Attaque. Ensuite, les notifier (Date, Type dattaque, Heure..) lensemble

de notre quipe ainsi qu lquipe Dfense.

- Etablir les procdures ncessaires lobstruction des failles et des procdures de

reprise sur incidents au cas o le systme dfendu venait tre touch.

Aspects rdactionnel et pluri-comptence : Julien M.

- Dfinir un mini-cahier des charges par rapport la demande de lquipe Dfense.

- Rle de volant susceptible dtre appel pour diffrentes tches do une

comprhension globale de tous les aspects du projet.

- Gre le rdactionnel de lquipe pour dcharger les ples et leurs permettre de ne

pas perdre de temps sur la mise en forme de leurs travaux.




c. Planning

Le Diagramme de Gantt ci-dessous montre le planning des activits tel quil tait

prvu au dbut du projet. Cependant, la grve et le blocage du btiment U2 ont

perturb notre planning.

Nous navons pu faire que deux confrontations avec lquipe Attaque (le

17/10/07 et le 04/12/07) et la date de remise du rapport a t reporte au 17

dcembre 2007.



d. Mise en place et dmarrage de lactivit

Dans un premier temps nous nous sommes investis sur certains points particuliers, tout

cela supervis par David Gerbaulet:

La mise en place du contrat nous liant au Groupe Dfense, tche affecte

Jonathan Blanc et Dimitri Tsiopoulos,

La mise en place des systmes de supervision, tche affecte David

Nembrot et Simon Pachy,

La mise en place du cahier des charges, tche affecte Julien Manuel,

La recherche dune mthode daudit pour essayer de la calquer sur notre

projet, tche affecte David Gerbaulet.

Une fois la sonde mise en place et la configuration pour rcuprer les logs

effectue, Julien Manuel sest pench sur les logs pour shabituer au bruit de fond

constant et ainsi permettre une raction plus rapide lors des tentatives dintrusion

ultrieures.



Par la suite est venu la premire confrontation qui a entran un peu de travail

supplmentaire :

Lanalyse en temps rel des vnements sur le rseau du groupe Dfense

Lobservation des demandes de manipulation du groupe Attaque et des

ventuels dni de services

Lanalyse a postriori des logs remonts par les diffrents systmes (la sonde,

le serveur) rpartie entre tous les membres du groupe.



III.Partie AUDIT

a. Prsentation brve de larchitecture cliente :

Ce modle darchitecture est assez sommaire puisque seul le pare-feu du

routeur et le serveur, configurs par la dfense par application de rgles iptables,

permet dassurer une scurit minimale du systme.

Nanmoins, la configuration des vlans a permis de bien cloisonner le

rseau et de segmenter les primtres serveurs et clients.

Le rseau audit se compose donc dun serveur APACHE avec les modules

PHP5 et mod-security ainsi que 2 postes clients Windows XP Pro et XP Pro SP2.

La mise en place ultrieure d'un serveur DNS et d'un proxy web ont permis

de complter la scurit des changes de donnes avec le monde extrieur.

Enfin, les techniciens de la dfense ont pu rapidement export tous les

logs systme vers notre sonde.



b. Tches et Ralisations :

Contrat (voir annexe 1 : Contrat daudit)

Objectifs :

Dlimiter le primtre daction du groupe dAnalyse et du groupe Dfense.

Dfinir les besoins en termes dinformations et daccessibilit au rseau pour

une analyse complte et efficace.

Poser les notions de confidentialits, de rmunration et de rapports

priodiques

Les moyens mis en uvre pour tablir ce contrat ont t dune part, une

profonde recherche sur les lments traiter dans un contrat dans le domaine de la

scurit de rseau informatique et dautre part, un appui sur lexprience de nos

prdcesseurs.

Le contrat a t tabli dans les temps mais nous avons eu quelques difficults

au niveau de la mise en forme pour que ce document soit clair et que les lments

traits ne se recoupent pas les uns les autres.

Cahier des charges (voir annexe 2 : cahier des charges 1iere et 2ieme confrontation)

Objectifs :

Connatre lorganisation de lquipe dfense, ainsi que le rle de chacun au

sein de cette quipe afin de faciliter la communication.

Nous spcifier les droits daccs sur le rseau de la dfense.

Dfinir larchitecture du rseau de la dfense pour la premire confrontation,

ainsi quun aperu des volutions envisages pour la deuxime confrontation.

Dfinir les attentes de lquipe dfense vis--vis de notre quipe daudit.

Enfin, communiquer le calendrier des confrontations labores entre les

diffrentes parties.

Les cahiers des charges nous ont t fournis par lquipe dfense. Le premier

avant la premire confrontation, le second avant la deuxime pour nous signaler

dventuels changements dans larchitecture du rseau.

Ces changes ont eu lieu avec le ple communication de lquipe Dfense.



c. Mise en place de la Mthode MEHARI (voir annexe 3 : Mthode Mehari)

Objectifs :

Essayer de prendre en main un outil complet danalyse.

Cette mthode est trs complte voir trop pour le cadre de notre projet. Cest

pourquoi nous nous sommes limits la dfinition de lexistant, un questionnaire

adapt et une rapide analyse en fonction des recommandations de la norme ISO

17999:2005, rfrence sur la gestion de la scurit informatique.

Ci-dessous, les principales mthodes daudit :

Les principales mthodes d'audit de scurit

Nom Signification Origine Caractristiques

Cobit Control objectives for information and technology ISACA

Mthode accessible tous, dans un langage simple. Les outils

fournis permettent la mesure des performances mais la mthode

est aujourd'hui davantage assimile une mthode de

gouvernance des SI.

Ebios Expression des Besoins et

Identification des Objectifs de

Scurit DCSSI

Notamment dploye au sein de l'administration franaise, cette

mthode comprend une base de connaissances et un recueil de

bonnes pratiques. Elle est tlchargeable sur le site de la DCSSI et

s'accompagne d'un logiciel.

Feros Fiche d'Expression

Rationnelle des Objectifs de

Scurit SCSSI

Pas une mthode proprement parler mais un document

permettant une autorit donne (secteur secret dfense

notamment) de dfinir le niveau d'engagement de sa

responsabilit dans l'application d'une politique de scurit.

Marion Mthodologie d'Analyse de

Risques Informatiques

Oriente par Niveaux CLUSIF

Fonctionne par questionnaires dbouchant sur 27 indicateurs

rpartis en 6 catgories. 2 phases (audit des vulnrabilits et

analyse des risques) permettent la dfinition et la mise en uvre

de plans d'actions personnaliss.

Mehari Mthode Harmonise d'Analyse de Risques CLUSIF

Succde la mthode Marion. S'articule autour de 3 plans. Permet

dsormais d'apprcier les risques au regard des objectifs

"business" de l'entreprise.

Nous avons choisi la mthode MEHARI car dune part, elle est lvolution de la

mthode MARION et dautre part, elle est gratuite.

La premire tape a t de dfinir avec Mr BOSCARI, Chef de projet de la

Dfense, et Mr ABOUZEID, Responsable de la Communication, les diffrents

domaines dactivits et les processus sensibles

Nous avons ensuite demand aux responsables quel serait limpact sur

lentreprise en cas de dysfonctionnements dun des processus.



Il a fallu ensuite dfinir les seuils de gravit pour chaque critre dimpact sachant

que :

- Seuil 1 : Sans dommage significatif - Seuil 2 : Dommage important - Seuil 3 : Grave dommage - Seuil 4 : Dommage extrmement grave

Nous avons ensuite recens et classifier les ressources suivant trois critres :

- Disponibilit - Intgrit - Confidentialit -

Les notes sont comprises entre 1 et 4 sachant que, plus le critre paraissait important,

plus la note tait leve.

Une fois ces classifications termines, nous nous sommes appuys sur les

questionnaires de la mthode MEHARI, bas sur 12 scnarii, pour modeler un

questionnaire denviron 400 questions, dcoup en six domaines et pour donner un

lger aperu de ce que pourrait tre un audit.

Voici les six domaines identifis :

- Domaine dOrganisation

- Domaine des Locaux

- Domaine du Rseau Local (LAN)

- Domaine de lExploitation des Rseaux

- Domaine de la scurit des Systmes et de leur architecture

- Domaine de la Protection de lEnvironnement de Travail

Pour chaque question, le responsable devait rpondre par oui ou par non .

A la suite de a, nous nous sommes penchs sur les rponses ngatives pour

mettre en lumire les non-conformits par rapport la norme ISO 17999: 2005 et

proposs, quand cela tait possible, quelques amliorations.

Ce que lon peut retenir :

Lanalyse aurait pu tre plus approfondie avec le calcul de diffrents indicateurs

tels que la mtrique de risque, de dissuasion, de potentialit, etc.



Nanmoins, cela nous paraissait inutile car la base de questionnaire ayant t

modifie, les calculs qui en dcoulent se trouvent biaiss. De plus, compte tenu du

nombre important de projets que nous avions raliser, nous naurions pas eu le

temps de rentrer plus amplement dans les dtails.

Quoiquil en soit, on a donc pu voir, par cette mthode, que le point le plus

critique du projet tait le domaine des locaux.

Pour conclure, il tait intressant dessayer de prendre en main une mthode

daudit malgr la difficult inhrente. Les cabinets daudits tant de plus en plus

convoits par les entreprises pour obtenir une valuation de leur systme

informatique, on sera peut tre amen, dans un futur proche, travailler au sein

dun de ces cabinets ou faire appel lun deux.

Il devient donc avantageux de connaitre les mthodes et dmarches utilis.

d. Mise en place de la Sonde :

Objectifs :

Installer physiquement la sonde sur le rseau de la Dfense

Dfinir les rgles de scurit sur la sonde pour viter quelle soit compromise

Installer les logiciels permettant la supervision du trafic

Penser une future volution de la supervision (tests de failles, attaques)

En premier lieu, nous avons remplac le daemon telnetd par sshd afin

d'amliorer la scurit concernant l'accs distance. Nous avons ensuite mont le

serveur Web en installant la dernire version d'Apache avec les modules ncessaires

nos besoins : php5, php5-mysql et mod-security principalement...

Une fois le serveur Web mis en place, nous nous sommes attel dployer

une base de donnes locale en installant les paquets mysql-server et php-myadmin.

SCette base servant de systme d'archives pour les outils de dtection d'intrusion

SNORT et de visualisation ACIDBASE, installs aprs beaucoup plus de difficults: les

scripts automatiques de remplissage de la base de donnes ne se sont pas excuts

du premier coup.

Aprs validation des configurations systme (droits de chaque utilisateur,

partage des droits, purge des services inutiles, etc), nous avons dfini un formulaire

d'informations rseau que la dfense a du mal nous retransmettre rapidement. Au

final, nous avons quand mme pu intgr notre sonde au rseau de l'quipe



Dfense. Enfin, pour apporter une gestion de vlan, nous avons du installer le paquet

ponyme pour configurer des interfaces virtuelles.

A terme, nous avons mont un serveur de logs qui recueille tous les logs

systme des hosts du rseau local. La configuration de syslog-ng n'a pas t de tout

repos, mais avec l'intercession de Mr LATU et la collaboration active de Mr PY, nous

avons pu finaliser la centralisation de logs assez rapidement. Le but tant d'avoir une

trace de tout vnement systme afin de mieux prvenir les failles et de

comprendre les ventuelles dmarches d'intrusion.

Ct supervision, nous avons mis en place l'outil Ntop qui restitue

graphiquement l'activit rseau en live. Cet outil nous a beaucoup servi dans la

mesure o il propose un niveau de prcision trs intressant. Par exemple, il est

possible de surveiller un host au niveau port avec une gestion de NetFlow. On voit

donc aisment qui essaie de se connecter, qui communique avec qui.

De faon plus globale, on peut aussi observer la distribution des protocoles utiliss

par chaque machine, apprcier les statistiques au niveau de la taille des trames

relatives et avoir une ide chronologique des transactions de donnes sur le rseau

interne et externe vu que Ntop analyse aussi les machines qui sont rgulirement

impliques dans le trafic local.

Ensuite, nous avons essay de dployer un autre outil de monitoring rseau:

Hobbit ie BB4.

Cet outil en complment de Ntop, permet de connatre les tats de

connexion des quipements en temps rel. Ainsi, il est trs facile de visualiser sur

l'interface Web la saturation d'une machine et de dduire la bande passante rseau

utilise, afin de prendre les dispositions ncessaires pour viter les dnis de service.

Malheureusement, nous n'avons pas russi configurer correctement cet outil.

Tout comme l'outil MRTG qui demandait une implmentation SNMP au sein du

rseau: par manque de temps et de ressources ncessaires aux recherches, nous

n'avons pas pu concrtiser cette ide.

Par contre, nous avons russi installer N3ssus sur la sonde. Aprs

l'interminable mise jour de ses 17838 modules de scurit, nous avons procd

des tests assez pousss de vulnrabilits sur le rseau local afin de conseiller au mieux

l'quipe dfense vis--vis des failles de scurit trouves.

Des rapports ont t envoys l'quipe dfense avec la plus grande priorit

et ont su tre traits rapidement.

Les tches suivantes font suite aux informations recueillies pendant ou

ultrieurement aux confrontations entre la Dfense et lAttaque. Les principales

tches qui dcoulent de ces confrontations sont lanalyse des logs et ltablissement



des rapports priodiques pour le groupe Dfense, leurs objectifs et les moyens mis en

uvre sont les mmes quelque soit la phase du projet et sont les suivants :

Lanalyse de logs : Objectifs :

Identifier les tentatives/russites dintrusion sur le rseau

Retracer les actions de l'quipe Attaque

Afin de collecter le plus grand nombre de logs possibles, nous avons install un

deuxime disque dur ddi pour laisser un peu plus de marge l'outil de sniffeur

rseau TSHARK.

Principalement, lors des confrontations, nous lancions travers un systme de

fentrage virtuel (cf. paquet screen) une capture intgrale de paquets rseau. Un

fichier destination.pcap correspondant au trafic spcifique un protocole

particulier sur un vlan prcis.

Concernant l'analyse en elle-mme, la rpartition des logs frachement

rcolts et l'assignation des tches se faisaient le soir mme. Une connexion SFTP

distante permettant de rapatrier tous les fichiers dsirs et de les redistribuer au sein

de l'quipe.

Lors des confrontations, le chef de projet a pris des notes chronologiques,

servant par la suite de base commune la lecture analytique des fichiers de logs.

Nous avons principalement utilis Wireshark pour les fichiers.pcap et le Ctrl-F pour les

autres fichiers systme.log (oh malheureux ! Un bon coup de grep serait tellement

plus appropri ;)

Synthses et rdactions des rapports : Objectifs :

Synthtiser le contenu des logs et lexploitation faite par les diffrents

membres de notre groupe Audit

Proposer des solutions pour viter de rencontrer de nouveaux les mmes

problmes

La lecture des centaines de Mgaoctets de logs a permis de comprendre en

dtail la mthodologie des attaquants. Nous avions une ide prcise des outils

utiliss pour alourdir les attaques par dictionnaire sur le port SSH, ou par

dbordement de pile sur le port HTTP. De nombreuses remarques en interne ont



permis de recouper les vnements critiques et de confirmer les accs frauduleux au

systme.

De plus, le serveur syslog qui coutait en permanence sur le port 514 et qui

recueillait des logs buffriss nous a permis d'avoir des feedbacks sur les erreurs et de

mieux comprendre l'impact des attaques sur le rseau.

Aprs chaque confrontation, un scan N3ssus tablissait l'tat de sant de la

sonde et du serveur de la dfense. Ce qui permettait d'apprcier chaud les

vulnrabilits rsultantes.

Un rapport bien fourni en commentaires et prcisions techniques tait adress

l'quipe Dfense dans la semaine suivant la confrontation.

Concernant les rapports, nous avons tenu prsenter les vnements

chronologiques un peu comme une intrigue avec des remarques et des annotations

qui rendent le ct technique moins rbarbatif. L'attention du lecteur tant de ce

fait beaucoup plus articule au fil de la lecture.

Notez que les rsultats et les ractions ont t diffrents en fonction des

phases, dus en partie une plus grande matrise des outils utiliss par l'quipe

attaque et une faible volution de larchitecture et des moyens de scurit du

groupe Dfense.

e. Premire Phase

Objectifs viss

A premire vue, le but tait de se familiariser avec les outils dploys par les

techniciens, de comprendre ce qui se passait et comment a se passait, l'aide des

outils d'audit.

La prise en main n'a pas t facile dans la mesure o les techniciens taient

plus proccups finaliser la centralisation des logs avec la dfense alors que le

reste de l'quipe audit essayait d'analyser chaud les actions des attaquants.

Au final, le chef de projet a bien pu noter l'ensemble des vnements

chronologiques, ce qui a grandement facilit la lecture post-attaque des logs.



Observations durant la confrontation Sous la tutelle du chef de projet, les collaborateurs du CASTRI ont pu suivre

grossirement le droulement de la premire attaque:

16h35 Tous les protagonistes sont prts. Lopration Attaque Sovitique est

lance.

16h48 NTOP signale une nouvelle activit TCP et HTTP.

16h57 Loutil Nikto est utilis par les attaquants. Dnis de service du serveur dfense. Temporairement.

17h05 Second Denis de Service avec un trafic HTTP et TCP encore plus intense. Les attaquants semblent avoir utilis python-urllib.

17h07 Lquipe Attaque n'arrive pas pntrer le rseau et

demande la Dfense datteindre lURL : 192.168.0.20/accueil.htm Sans succs

17h10 Les attaquants utilisent un hte de la salle 213.

La sonde audit est victime d'une attaque majeure:

flooding ICMP et attaques des services (bruit de fond)

attaque SSH par dictionnaire (charge utile)

Dnis de service de la sonde audit quasi immdiat mais temporaire. Un torrent de plus de 700 paquets par seconde est identifi !!!

17h45 La dcision est prise : suite une demande de lquipe attaque,

la dfense permet une grosse faille dans le code PHP (# include..).

17h51 La faille est vrifie et le serveur dfense est sous pression.

Les logs de la sonde audit rapportent une vaste attaque SSH par dictionnaire et des tentatives d'injection

de code dans les formulaires du site web de la dfense.

18h00 A la demande de lquipe attaque, lURL fausse est recharge de nouveau.

On se rend compte cet instant que la sonde est vise

18h15 Un processus nomm a.exe est dtect sur le poste client non

mis jour provoquant louverture de pages web. Il est aussitt dtruit.

Le routeur rapporte une erreur ICMP la sonde : le poste client XP tente d'accder au primtre services.

18h17 Les attaquants ont accs au site web du serveur dfense.

Tous les fichiers du site sont rcuprs et archivs.



18h18 La sonde audit est bout de souffle.

Une activit encore plus intense est constate sur le port 22 et elle ne

rpond plus. Une dconnexion physique est dcide pour viter le pire.

18h20 L'quipe audit arrive retrouver un accs distant la sonde

depuis une nouvelle machine de la salle.

18h23 Elle tablit un premier bilan des services et des outils.

18h25 Lopration Attaque Sovitique est officiellement termine.

Le lendemain, de nouvelles attaques ont t dcouvertes: - bad_checksum portscan en bruit de fond

- tentative d'injection de scripts CGI via VPN

Rsultats de lanalyse de log et conseils la dfense

Suite une interception douteuse d'changes de cls du serveur SSH de la

Dfense, nous avons prconis un changement complet des mots de passe.

Autrement, cette premire attaque n'a pas vraiment caus de dgts

consquents l'chelle du rseau grce un bon cloisonnement inter-vlans.

Implmentation de nouveaux outils :

Aprs le premire confrontation, une cellule de recherche a t organise afin de

disposer d'lments nouveaux en matire de :

monitoring rseau travers les outils Hobbit et MRTG,

bouclier du serveur Web Apache (Logcheck et mod-security

principalement),

scans rseau avec N3ssus et les autres outils de dfense offensive

permettant d'identifier les vulnrabilits du rseau mis en place (metasploit,

SSL2open, DNS-bruteforce),

pntration rseau en faisant fi du pare-feu install l'aide des outils

Firewalk et Itrace.



f. Seconde Phase :

Objectifs viss

Premirement, notre but tait d'avoir un contrle temps rel du rseau. Grce

l'interface Ntop, une partie de l'quipe tait capable d'avertir les techniciens

rapidement d'un transit suspect, d'une nouvelle connexion, tout en surveillant les

flux normaux . De mme via AcidBase, qui est cens renseigner trs rapidement les

tentatives d'intrusion.

Deuximement, nous voulions ragir trs vite en rajoutant des rgles iptables

la vole, en manipulant dynamiquement certains services critiques et en avertissant

l'quipe dfense au plus vite lorsqu'ils taient pris pour cible.

Observations durant la confrontation

15h Tous les protagonistes sont prts. L'attaque est lance.

Les rgles iptables draconiennes dployes sur le routeur racine, sur le serveur dfense et sur la sonde ont considrablement

ralenti les tentatives d'intrusion des attaquants.

16h00 Loutil NTOP prsente des dysfonctionnements d'affichage.

Le rafrachissement de l'interface ne livre plus d'informations temps-rel.

Dec 4 16:07:35 sonde-analyse ntop[16391]: **WARNING** free of NULL pointer @ http.c:3588

Dec 4 16:07:35 sonde-analyse ntop[16391]: **ERROR** EPIPE during sending of page to web client

[... ... ...]

Dec 4 16:51:56 sonde-analyse ntop[16391]: **ERROR** EPIPE during sending of page to web client

16h25 Les attaquants utilisent dsormais les outils AcuneTix (scanner de vulnrabilits, SQL injection / Cross site scripting testing) et IngresLock (mise en place de backdoor) afin d'alourdir les attaques par flooding entames sur le port 80 des serveurs audit et dfense.

On a observ que le serveur attaque a tent des injections de code SQL et Java et a envoy une quantit norme

de requtes GET sur les deux instances de phpMyAdmin, La principale cible tant la page web site/etudiant_action.php

16h30 Les premires requtes authentifies apparaissent sur la sonde.

Un GET suivi d'un POST avec le mot de passe admin leur ouvre un accs complet sur le

port 8080 de la sonde.



Les attaquants continuent leur flood sur le port 80 de la dfense, et s'attaquent la page site/prof_action.php

16h35 Les attaquants commencent exploiter le serveur mail.

Postfix signale la sonde la prsence de mails en attente

d'expdition pour [email protected]

16h45 Loutil SNORT est compromis. Son intgrit est mise mal et

la consultation des intrusions via Acidbase ne marche plus (port 8080).

16h48 Les attaquants pntrent le SGBD de la sonde audit et

ont dsormais accs la structure de la base de donnes snort.

Quelques minutes plus tard, on a dcouvert une requte POST sur la page phpmyadmin/import.php contenant du code SQL DROP DATABASE

suivie d'une deuxime pour vrifier d'effacement via SELECT * FROM ...

16h52 Via phpMyAdmin, une attaque est lance depuis un poste de la salle 212.

Il tente un dbordement de pile sur le site web dfense:

/site/index.php?page=http%3A%2F%2F192.168.0.20%{...}

16h59 Toujours via phpMyAdmin, les attaquants envoient un nombre encore plus

impressionnant de requtes GET/POST au serveur dfense sur les pages

inscrit.php & inscription.php

Les daemons mysqld, squid et spamd de la dfense redmarrent suite une erreur de socket.

17h00 Le protocole gIFT (graphic Internet File Transfer) est utilis par l'attaque. Une requte ResetStats est envoye priodiquement la sonde, vraisemblablement pour effacer les logs des outils de monitoring.

Le port 3000 de la sonde se met dlirer srieusement. Les logs montrent des communications suspectes

(envoi priodique du signal ResetStats ?!?)

L'activit SYSLOG est son apoge : la sonde rcolte

prs de 30 Mo de logs provenant de la dfense... en 11 sec !!!

De nombreuses pertes ultrieures de segments TCP ont t observes sur le primtre serveurs.

17h05 Le service mail envoit un log d'alerte : il rapporte l'initialisation du service

SSL imaps en loopback, suivie d'une mauvaise authentification avec

comme message d'erreur:

'' Command: stream end of file, while reading line user=defense2 host=localhost [127.0.0.1]\n ''



17h10 L'quipe dfense dcouvre l'installation du Linux KeyLogger

sur plusieurs ordinateurs de la salle 213 via la commande:

find / -name ' *lkl* '

Notamment sur le poste utilis par Dawid pour se connecter distance sur la sonde. L'quipe attaque a donc eu accs aux mdp systme.

Pour preuve, le changement des mdp de la sonde fait apparatre instantanment des messages ' AUTHENTICATION FAILURE' dans le fichier /var/log/user.log:

Dec 4 17:10:15 sonde-analyse sshd[26203]: Accepted password for sysadmin from 172.16.80.86 port 1385 ssh2 Dec 4 17:10:15 sonde-analyse sshd[26216]: pam_unix(ssh:session): session opened for user sysadmin by (uid=0) Dec 4 17:10:35 sonde-analyse su[26236]: Successful su for root by sysadmin Dec 4 17:10:35 sonde-analyse su[26236]: pam_unix(su:session): session opened for user root by sysadmin(uid=1000) Dec 4 17:12:27 sonde-analyse passwd[26240]: pam_unix(passwd:chauthtok): password changed for root Dec 4 17:12:34 sonde-analyse su[26236]: pam_unix(su:session): session closed for user root Dec 4 17:14:37 sonde-analyse passwd[26273]: pam_unix(passwd:chauthtok): password changed for sysadmin Dec 4 17:15:38 sonde-analyse su[26306]: pam_unix(su:auth): authentication failure; logname=sysadmin uid=1000 euid=0 tty=pts/1 ruser=sysadmin rhost= user=root Dec 4 17:15:40 sonde-analyse su[26306]: pam_authenticate: chec d'authentification Dec 4 17:15:40 sonde-analyse su[26306]: FAILED su for root by sysadmin Dec 4 17:16:05 sonde-analyse su[26328]: pam_unix(su:auth): authentication failure; Dec 4 17:16:38 sonde-analyse su[26340]: pam_unix(su:auth): authentication failure; Dec 4 17:17:04 sonde-analyse su[26341]: pam_unix(su:auth): authentication failure; logname=sysadmin uid=1000 euid=0 tty=pts/1 ruser=sysadmin rhost= user=root Dec 4 17:17:06 sonde-analyse su[26341]: pam_authenticate: chec d'authentification Dec 4 17:17:06 sonde-analyse su[26341]: FAILED su for root by sysadmin Dec 4 17:17:32 sonde-analyse sshd[26346]: Bad protocol version identification from 192.168.0.20 Dec 4 17:18:03 sonde-analyse su[26345]: pam_unix(su:auth): authentication failure;

17h15 L'quipe dfense change eux aussi les mdp de leur serveur et le redmarre.

Aprs le redmarrage, le service mail annonce la couleur: mail : postfix/local[19593]: table hash:/etc/aliases(0,lock|no_proxy|no_unauth) has changed restarting\n

De plus, il envoi la sonde un buffer de donnes qu'il stockait depuis quelques heures.

Les logs ont ainsi montr plusieurs tentatives d'accs au service en fin de matine: Message: Dec 4 11:41:21 mail : spamc[3435]: connection attempt to spamd aborted after 3 retries\n

Message: Dec 4 11:42:02 mail :connect(AF_INET) to spamd at 127.0.0.1 failed : Connection refused\n

17h18 Les logs montrent des activits trs suspectes du serveur dfense:

Message: Dec 4 17:18:22 srv-web apache_error : Not all processes could be identified.\n

Message: Dec 4 17:18:22 srv-web apache_error : Connecting to 192.168.0.20:80... connected.\n

Message: Dec 4 17:18:22 srv-web apache_error : (59.72 MB/s) - `zap2.c' saved [1995/1995]\n

Message: Dec 4 17:18:22 srv-web apache_error : (6.15 MB/s) - `hihi' saved [73716/73716]\n

Message: Dec 4 17:18:22 srv-web apache_error : Connecting to packetstormsecurity.org:80... ready.\n

DAEMON.ERR: Dec 4 17:18:40 srv-web mysqld[2283]: InnoDB: Started; log sequence number 0 43655\n

DAEMON.ERR: Dec 4 17:18:41 srv-web mysqld[2283]: [Note] /usr/sbin/mysqld: ready for connections.\n

DAEMON.ERR: Dec 4 17:18:41 srv-web mysqld[2283]: socket: '/var/run/mysqld/mysqld.sock' port: 3306\n

DAEMON.INFO: Dec 4 17:18:45 srv-web /etc/mysql/debian-start[2348]: Checking for crashed MySQL tables.\n

MAIL.INFO: Dec 4 17:18:46 srv-web spamd[2345]: logger: removing stderr method\n



17h19 Ct dfense, de nombreux accs aux dossiers /proc, /dev, /etc, /usr, /var

ont t refuss ainsi que des tentatives de zip:

Message: apache_error : tar: /etc/lvm/backup: Cannot open: Permission denied\n

Message: apache_error : tar: /etc/mysql/debian.cnf: Cannot open: Permission denied\n

Message: apache_error : tar: /etc/passwd-: Cannot open: Permission denied\n

Message: apache_error : tar: /etc/shadow: Cannot open: Permission denied\

Message: apache_error : tar: /etc/squid/squid.conf: Cannot open: Permission denied\n

Message: apache_error : tar: /etc/ssh/ssh_host_dsa_key: Cannot open: Permission denied\n

Message: apache_error : tar: /etc/ssh/ssh_host_rsa_key: Cannot open: Permission denied\n

Message: apache_error : tar: /etc/ssl/private: Cannot open: Permission denied\n

17h20 Lquipe Attaque continue d'exploiter le serveur mail de la dfense.

En utilisant une session www-data, ils arrivent crer des nouveaux mails dans la file

d'attente de postfix:

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] ...

Le tout imbriqu dans une boucle !!

17h23 Les attaquants lancent un puissant flood SSH et HTTP sur la sonde,

et provoque un Dni de Service meurtrier.

Tshark a montr que les attaquants ont flood la sonde avec les bits RST et ACK 1.

Les attaquants semblent avoir eu accs la sonde vu qu'ils ont russi inhiber le firewall interne mis en place.

Par mesure de scurit, tous les mots de passe de la sonde sont modifis et un rechargement du script

iptables permet de retrouver un tat oprationnel.

La configuration d'Apache est modifie travers la rgression des capacits limites de traitement des instances.

17h40 Les attaquants demandent l'quipe dfense de connecter un poste client

l'adresse publique de leur serveur: http://192.168.0.20/

Le navigateur utilis pour cette manipulation a plant et on a dcouvert l'excution du processus ''dumprep.exe''

qui a pour but de tracer les erreurs logicielles au format texte.

Malheureusement, aucune dtection de spyware n'a t confirme...

18h00 L'attaque est officiellement termine.



Rsultats de lanalyse de log

Les firewalls configurs ont permis de bien protger l'architecture existante.

Sans la prsence du keylogger, les attaquants auraient eu beaucoup plus de mal

pntrer le rseau interne.

La centralisation des logs vers la sonde a t beaucoup plus importante que

la premire confrontation, qui a d'ailleurs grandement facilit les recoupements

d'informations lors de la rdaction du rapport d'audit (mme si la lecture du

GigaOctet de logs a t prouvante...).

Les envois bufferiss de logs ont surtout permis d'avoir des feedbacks et donc

de revenir sur des points antrieurs d'activit rseau de faon plus prcise.

La sonde d'audit a t fortement dvaste. La compromission du SGBD a

empch l'outil SNORT de remonter les intrusions, la prsence du keylogger a

divulgu bon nombre d'informations confidentielles avant de permettre aux

attaquants de provoquer notamment la dsactivation du firewall interne, le dni de

service complet et le crash du serveur SQL.

Le serveur dfense a t le plus prouv dans l'histoire mme s'il a bien tenu le

choc. Le remplissage de la base MYSQL et l'criture continue des logs systme ont

satur l'espace disque et bon fonctionnement de la machine.

Aucun diagnostic n'a pu tre fait en profondeur par manque de temps et de

ressources consacrs ce projet.

Implmentation de nouveaux outils :

De faon optimale, sil y avait eu une autre confrontation, nous pourrions

prvoir un meilleur blindage des outils de monitoring pour viter les requtes

provenant de l'extrieur. Et surtout une vrification systmatique de l'intgrit des

machines utilises...



IV. Bilan

a. Bilan de laction auprs de la Dfense

Les rapports avec lquipe Dfense ont t trs bon. Il convient nanmoins de

relever une petite friction qui sest produite pendant la premire analyse des logs o

les bonnes adresses IP avait t transmise un peu tard par lquipe Dfense.

Nous avons nous mme eu du retard dans la livraison du rapport danalyse des

logs pour la deuxime confrontation.

Bref, chaque partie a apprci la qualit du travaille fournit par lautre quipe.

b. Bilan de notre organisation

Plutt que de finir par un bilan global, il tait plus intressant de laisser la parole

chaque ple pour que chacun puisse pouvoir sexprimer.

Management

En ce qui me concerne, le projet a t une exprience enrichissante, notamment

en gestion des ressources humaines. Jai pu voir quil tait parfois laborieux de grer

un groupe de six personnes. Il a fallut faire en fonction des qualits et de

linvestissement de chacun.

Je me suis beaucoup appuy sur un ple technique performant et

comptent qui reprsentait la clef de vote du projet.

Il est aussi intressant de remarquer que, sans aucune indication pralable,

tout le monde sest plac dans un cadre professionnel en senvoyant des e-mails

toujours trs formels. Cest peut tre aussi pour a que le partenariat avec lquipe

Dfense a si bien fonctionn.

Ple Commercial et Juridique

Ce projet, de manire gnral, donne je pense, une bonne ide de ce que peut

tre la vie en entreprise et la ralisation de projet complexe au sein dune

organisation avec une hirarchie.

Lorganisation du travail sest avre trs efficace en dbut de projet en raison de

pas mal de temps libre de chacun des membres ; que ce soit le contrat, le cahier

des charges, la mthode MEHARI ou la mise en place de la sonde, toutes ces



oprations ont t ralises sans problme vis--vis des dlais que nous nous tions

fixes.

Cependant, on a vite remarqu quavec une quipe dj suprieure trois

membres, nous tions beaucoup dpendants des ct de chacun dentre nous.

Les contraintes temporelles ont quelques moments t dpasses mais le

rsultat du travail est tout de mme rest de bonne qualit.

La grosse difficult de ce projet a t ce respect des dlais que nous nous

tions fix et sans relance de notre manager, il y aurait eu des rpercussions de la

qualit du travail fourni.

Ple Technique

J'ai apprci le contexte gnral du projet. Cette mise en situation concrte a t

tellement rare que je me suis donn fond afin de me rconcilier avec Linux et

mettre profit tous mes acquis des cours de Mr Latu.

Mon affectation la direction technique m'a garanti d'avoir une vision

globale sur le projet avec un interfaage direct avec le chef de projet, mais aussi

de me rendre compte de l'importance des choix d'orientation technique pour notre

machine.

Au dbut, il a t difficile de devenir oprationnel mais au fur et mesure que

le projet avanait, nous prenions force de nuits blanches, une longueur d'avance

afin d'anticiper et d'avoir une dmarche de scurit offensive.

Les interactions avec l'quipe Dfense a t efficace cot technique. Leur

directeur technique a t conciliant et trs disponible (seul).

La grve nous a mis au chmage technique mais bon, vu le travail grer en

parallle, les ressources consacres n'aurait peut tre pas t suffisantes...

Ple Aspect rdactionnel et pluri comptence

Jai pour ma part pris got ce projet, mon poste tait particulirement intressant

car pluri disciplinaire. Jai en effet particip aux tapes de discutions avec lquipe

dfense, aux aspects rdactionnels, mais aussi lanalyse, beaucoup plus

technique, des logs remonts de la sonde pendant les phases de confrontation.

Laspect relationnel avec lquipe dfense ma confort dans lide que la

communication peut tre un point dlicat qui peut entrer des erreurs

dinterprtation. Notamment si les documents, tel que les cahiers des charges par

exemple, ne possdent pas de numro de version. Difficile de sy retrouver par la

suite !



NOTES



V. Annexes



Annexe 1 : Contrat daudit



Contrat daudit informatique

La collaboration entre les quipes dfense et analyse doit faire luvre dun

contrat permettant de fixer les limites dactions auprs de Candide S.A. Ce contrat

aura pour but dassurer le bon droulement de la mission daudit de scurit,

savoir la validation des moyens de protections mis en uvre sur les plans

organisationnels, procduraux et techniques, au regard de la politique de scurit

rdig par les soins de la dfense.

Nous avons donc convenu aprs ngociation avec la dfense, des clauses

suivantes :

Article1 - Informations sur le Rseau :

Laudit, ayant confi lquipe danalyse le soin dassurer un audit complet des

systmes dinformation de Candide S.A, sengage fournir le recensement dtaill

de lensemble des lments qui constituent ce systme. Lauditeur pourra raliser

ltat des lieux et des objectifs de scurit, savoir :

- Rglementation interne, procdures, organigramme du personnel, charte

dutilisation des ressources.

- Scurit physique : Normes de scurit, protection des accs (quipements,

infrastructure cble, etc.), redondance physique, plan de maintenance.

- Exploitation et administration : sauvegarde et archivage des donnes,

continuit de service, journalisation.

- Rseaux et tlcoms : architecture rseau (topologie, plan dadressage),

matriels (modems, routeurs, commutateurs, pare-feux), contrle des accs

logiques.

- Systmes : poste de travail (gestion des droits), serveurs et les services quils

dlivrent, applications, solutions antivirales.

Article2 - Primtre dactions de laudit :

Ayant connaissance des lments composant le systme dinformation, lauditeur

pourra dfinir le primtre de laudit et planifier ses interventions et ses entretiens

avec les personnes interviewer au sein de la dfense. Lquipe danalyse sera

responsable de lorganisation des runions avec lquipe audite et devra, lissue

de celles-ci, proposer des recommandations pour la mise en place de mesures

organisationnelles et techniques.



Article3 - Mise en place des outils de supervision:

Laudit conviendra avec lauditeur dun droit accs physique au systme pour la

mise en place doutils danalyse et de dtection (analyse des logs, scans, sondes).

Sur autorisation explicite de la dfense, lauditeur pourra effectuer des tests

dintrusions selon des scnarios potentiels dattaque, afin de dterminer les

vulnrabilits et les failles de scurit.

Article4 - Compte-rendu :

Chaque phase danalyse et dvaluation ralise par les soins de lquipe danalyse

devra faire luvre dun rapport complet prsentant de manire explicite les

vulnrabilits dtectes sur le systme audit, et proposant des amliorations

techniques et organisationnelles pouvant entraner une revue de la politique de

scurit.

A son tour la dfense devra informer lauditeur de toute modification ou volution

de son systme de scurit.

Article5 - Confidentialit :

Lorganisme daudit, savoir lensemble des personnes qui interviendra pour la

mission daudit de scurit, sengage, sous sa responsabilit exclusive, considrer

confidentielles toutes informations transmises par la dfense, de faon orale ou

crite, et par consquent ne pas les divulguer un tiers. Une clause de

confidentialit sera tablie linitiative de la dfense et devra faire lobjet dune

signature par lensemble des membres composant lquipe danalyse.

Lorganisme daudit est entirement responsable de la scurisation de la sonde et

de laccs au rseau de la dfense par celle-ci ou par ventuelle adresse IP donne

pour cette mme sonde.

De la mme manire, les diffrents droits octroys lorganisme daudit sont sous

leur entire responsabilit.

En cas de violation volontaire ou ngligente de cette clause, la ou les personnes

responsables devront rpondre de sanctions ngocies au pralable avec la

dfense.



Article6 - Cadre juridique :

Lorganisme audit doit tre conscient de la lgislation concernant les systmes

dinformations. Les responsables de scurit ont une obligation de moyens pour que

leur systme de scurit rentre en conformit juridique. Ils doivent tre vigilants au

respect de la protection des donnes prives des employs. Lorganisme

responsable doit galement sensibiliser ses employs sur le cadre dutilisation

dinternet. Un usage abusif sortant du cadre professionnel pouvant induire des

problmes de scurit et mettre en cause la responsabilit civile ou pnale de

lentreprise et de lemploy.

A cet effet une charte dutilisation de linformatique et des tlcommunications

devra tre tablie linitiative de la dfense.

Article7 - Financier :

Par ce contrat la dfense sengage prendre en charge la totalit des frais

matriels indispensables la mise en place dune supervision efficace. Une fois

linstallation effectue, une rmunration mensuelle sera verse lorganisme

daudit pour le travail fourni. Une dduction sur cette rmunration pourra tre

effectue en cas de responsabilit de lorganisme daudit dans un quelconque dni

de service portant atteinte aux activits de lentreprise Dfense.

Au terme des actions entreprises par lquipe dattaque durant le temps imparti aux

trois sances de TP, et aprs tablissement du rapport danalyse, un bilan

organisationnel et technique de la mission accomplie par les deux quipes en

collaboration permettra dvaluer la part de responsabilit de la dfense et de

laudit.

Lquipe ayant le plus failli sa mission aura lhonneur dinviter lautre quipe au

restaurant de son choix.

Article8 - Modification de Contrat :

Pour des ventuelles modifications de contrat des Avenants seront produits et

devront tre obligatoirement signs par les deux partis que ce soit pour une

modification mineure ou majeure afin que tout compromis soit vit.

Article9 - Intgrit physique :

Laudit se dgage de toute responsabilit dans lventualit dune attaque de

niveau physique, le matriel tant hberg dans les locaux clients ; La dfense

prendra donc en charge lintgrit physique du matriel de supervision.



Article 10 - Facilit de supervision :

Lors dune connexion distance par le VPN mis disposition lquipe dfense, une

signalisation de cet accs doit tre effectue M David NEMBROT par mail, afin que

la lecture des logs en soit facilite.

Signatures des deux parties (prcdes de la date et de la mention lu et

approuv ) :

Pour le groupe Dfense, Pour le groupe Analyse,

M. David BOSCARI M. David GERBAULET

Le ........................... Le



Annexe 2 : cahier des charges 1iere et 2ieme

confrontation



Annexe 3 : Application de la mthode MEHARI

Documents

audit_réseau