métrologie et gestion d'incidents !

La métrologie : netflowIncident de sécurité

Conclusion

Métrologie et gestion d’incidents !

Frédéric Bongat

Assemblée des CSSI

Janvier 2015

1/20


Conclusion

Sommaire :

1 La métrologie : netflow

2 Incident de sécurité

3 Conclusion

2/20


Conclusion

La métrologie

Mon objectif : savoir mieux ce qui se passe sur le réseau dupoint de vue du CSSIAu jour le jour

Connaître les usages et applications utilisées (on a souvent uneconnaissance non complète de son trafic)Détecter de façon pro-active des déviations par rapport à unétat normalEn cas d’incident : aide et soutien après un incident (recherched’informations)

Un monitoring moderne entre dans les planifications PDCA(d’une PSSI)

On souhaite une visualisation de statistiques horaires etjournalières

3/20


Conclusion

Les flux réseaux

Analyse du trafic = Analyse des fluxQu’est-ce qu’un flux :

Un flux est défini comme une sucession de paquets IPtransitant par un point d’observation du réseau durant unintervalle de temps.Aspect de comtabilisation des flux

Mes critères d’un flux réseauAdresses IP (source et destination)ProtocolesPorts applicatifs (source et destination)Type of Service (ToS)Interfaces d’entrée et de sortie du routeur

4/20


Conclusion

Les protocoles de flux réseaux

Les protocoles Netflow (Cisco) et sFlow (Extreme Networks,3COM, HP Procurve . . . ) sont les principaux implantés par leséquipementiers réseau.

Ils fournissent les informations de niveau 3 et 4 sur les fluxtransitant sur le réseau, et ce sans avoir à déployer des sondesou des agents.Choix d’une sonde d’émission dans un des formats (et non pasen fonction des équipements)

Particularités :Flux unidirectionnels ou bidirectionnels (aller-retour,comportement TCP, ...)Flux d’application : vue au delà des en-têtes afin de classifierles paquets en fonction de leur contenu.Agrégation possibles

5/20


Conclusion

Les flux de type netflow

Format NetflowLes versions 1, 5,6, 7, 8 sont propriétaires (nombres deparamètres fixes)La version 9 : extensible et flexible (templates)Nouveau standard : IPFIX, compatible v9

Pour exploiter les informations NetFlow, il faut mettre enœuvre :

un collecteur chargé d’enregistrer les informations NetFlowémises par le (ou les) équipement(s),un analyseur pour produire les tableaux statistiques et lesgraphes.

6/20


Conclusion

Présentation du contexte

Institut Pierre-Simon LaplaceIDES, LATMOS, LMD, LISA, LOCEAN, LPMAA, LSCE,SISYPHE

Sur le Campus JussieuFédération IPSL (400 personnels)LMD, LOCEAN, LATMOS, IPSL (infrastructure réseaucommune)

Présentation de l’incident au LOCEANLes sites du LOCEAN

CNRS, IRD, MNHN, UPMCLes tutelles :

Paris (Jussieu/Muséum), BondyLMI : Sénégal (Dakar, Saint-Louis), Brésil (Niteroi), Pérou(Callao), IRD Nouméa

7/20


Conclusion

Infrastructure IPSL

Schéma réseau IPSL

Ressources 2x1Gb/s mais 1 Gb/s en sortie effective

8/20


Conclusion

Architecture de gestion des flux

Repose sur deux colecteurs (basés sur nfdump et silk)

nfcapd : 8 Go/moissilk : 5 Go/mois

9/20


Conclusion

Console d’observation et d’analyse restreinte

10/20


Conclusion

Les profiles

Nouvelles vues d’analyses sur des critères prédéfinisEnsemble des profiles (10) : environ 2 Go/mois de données

11/20


Conclusion

Les outils d’analyse

Outils de "recherche" en ligne de commandeAnalyse : nfdump et shell

Analyse : silkNombreuses commandes intégrées (rwfilter, rwcut, rwstat, ...),map de sortie en format binairebesoin de moins de commandes shell

12/20


Conclusion

Etude d’un incident

L’incident : phishing et vol d’identifiants

13/20


Conclusion

Chronologie de l’incident

Au LOCEAN : multi sites internationnauxSamedi 3 janvier, um message de type phishing des plusclassiques est envoyé

14/20


Conclusion

Chronologie de l’incident : le phishing

Vérification de la dangerosité du messageLe lien est des plus mêne sur un site en République TchèqueL’interface ne ressemble pas du tout à celui de l’UPMC

Par acquit de conscience : le lundi matin, j’envoie un messageaux utilisateurs sur cette campagne de phishingEn fin de matînée, deux utilisateurs se sont présentés commevictimesMesure : changement des mots de passe, ouf ! !

15/20


Conclusion

Observation de l’incident

Lundi en soirée, début des hostilitésGraphique de la messagerie et la période de spam

Graphique du mail en temps normal sur une semaine

16/20


Conclusion

Analyse de la situation

Validation de l’attaque sur le serveur de messagerieCaractéristiques de cette attaques

environ 450000 messages et 1,6Go de données dans le spool(incomming, deferred, ...)

Blocage du serveur, identification du compte,Changement du mot de passe du compteMaintenance du serveur, redémarrage du serviceAnalyse de l’incident

17/20


Conclusion

Méthodologie d’attaque simple

Vérification par webmail, envoi des spams par smtps

Attaque depuis l’île Maurice18/20


Conclusion

Suite de l’incident

De nouveau une nouvelle attaque (adaptée)Nouveau compte compromis : toujours une réponse auphishing

Première partie mardi soir 18h30-20hDeuxième partie : mercredi 7h30-9hMême méthode d’attaque, nouvelle ip de la même régiongéographiqueEnsemble des 3 attaques

Même gestion que précédemmentAction niveau administrateur : mise en place du contrôle de laqueue sur le serveur.

19/20


Conclusion

Conclusion

Les analyses de flux sont très intressantesD’un point de vu de la détection

C’est complémentaire à un IDSAvec le problème de la visualisation de la console (veille)

Au niveau gestion d’incidentsOutils très performantsBeaucoup d’informations disponibles

C’est un bon outil pour un CSSIAméliore la connaissance de son environnement et dufonctionnement des applications réseauxBeaucoup d’informations disponibles

20/20

métrologie et gestion d'incidents !

Documents