Upload
doanduong
View
222
Download
5
Embed Size (px)
Citation preview
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
La métrologie : netflowIncident de sécurité
Conclusion
Sommaire :
1 La métrologie : netflow
2 Incident de sécurité
3 Conclusion
2/20
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
Conclusion
Infrastructure IPSL
Schéma réseau IPSL
Ressources 2x1Gb/s mais 1 Gb/s en sortie effective
8/20
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
Conclusion
Console d’observation et d’analyse restreinte
10/20
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
Conclusion
Etude d’un incident
L’incident : phishing et vol d’identifiants
13/20
La métrologie : netflowIncident de sécurité
Conclusion
Chronologie de l’incident
Au LOCEAN : multi sites internationnauxSamedi 3 janvier, um message de type phishing des plusclassiques est envoyé
14/20
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
Conclusion
Méthodologie d’attaque simple
Vérification par webmail, envoi des spams par smtps
Attaque depuis l’île Maurice18/20
La métrologie : netflowIncident de sécurité
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
La métrologie : netflowIncident de sécurité
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