Métrologie et gestion d incidents!

Métrologie et gestion d’incidents !

Frédéric Bongat

Assemblée des CSSI

Janvier 2015

Sommaire :

1 La métrologie : netflow

2 Incident de sécurité

3 Conclusion

La métrologie

Mon objectif : savoir mieux ce qui se passe sur le réseau du point de vue du CSSI

Au jour le jour

Connaître les usages et applications utilisées (on a souvent une connaissance non complète de son trafic)

Détecter de façon pro-active des déviations par rapport à un état normal

En cas d’incident : aide et soutien après un incident (recherche d’informations)

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

On souhaite une visualisation de statistiques horaires et journalières

Les flux réseaux

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

Un flux est défini comme une sucession de paquets IP transitant par un point d’observation du réseau durant un intervalle de temps.

Aspect de comtabilisation des flux

Mes critères d’un flux réseau

Adresses IP (source et destination) Protocoles

Ports applicatifs (source et destination) Type of Service (ToS)

Interfaces d’entrée et de sortie du routeur

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 flux transitant sur le réseau, et ce sans avoir à déployer des sondes ou des agents.

Choix d’une sonde d’émission dans un des formats (et non pas en 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 classifier les paquets en fonction de leur contenu.

Agrégation possibles

Les flux de type netflow

Format Netflow

Les versions 1, 5,6, 7, 8 sont propriétaires (nombres de paramè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 les graphes.

Présentation du contexte

Institut Pierre-Simon Laplace

IDES, LATMOS, LMD, LISA, LOCEAN, LPMAA, LSCE, SISYPHE

Sur le Campus Jussieu

Fédération IPSL (400 personnels)

LMD, LOCEAN, LATMOS, IPSL (infrastructure réseau commune)

Présentation de l’incident au LOCEAN

CNRS, IRD, MNHN, UPMC Les tutelles :

Paris (Jussieu/Muséum), Bondy

LMI : Sénégal (Dakar, Saint-Louis), Brésil (Niteroi), Pérou (Callao), IRD Nouméa

Infrastructure IPSL

Schéma réseau IPSL

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

Architecture de gestion des flux

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

nfcapd : 8 Go/mois silk : 5 Go/mois

Console d’observation et d’analyse restreinte

Les profiles

Nouvelles vues d’analyses sur des critères prédéfinis

Ensemble des profiles (10) : environ 2 Go/mois de données

Les outils d’analyse

Outils de "recherche" en ligne de commande

Analyse : silk

Nombreuses commandes intégrées (rwfilter, rwcut, rwstat, ...), map de sortie en format binaire

besoin de moins de commandes shell

Etude d’un incident

L’incident : phishing et vol d’identifiants

Chronologie de l’incident

Au LOCEAN : multi sites internationnaux

Samedi 3 janvier, um message de type phishing des plus

classiques est envoyé

Chronologie de l’incident : le phishing

Vérification de la dangerosité du message

Le lien est des plus mêne sur un site en République Tchèque L’interface ne ressemble pas du tout à celui de l’UPMC

Par acquit de conscience : le lundi matin, j’envoie un message aux utilisateurs sur cette campagne de phishing

En fin de matînée, deux utilisateurs se sont présentés comme victimes

Mesure : changement des mots de passe, ouf ! !

Observation de l’incident

Lundi en soirée, début des hostilités

Graphique de la messagerie et la période de spam

Graphique du mail en temps normal sur une semaine

Analyse de la situation

Validation de l’attaque sur le serveur de messagerie Caracté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 compte

Maintenance du serveur, redémarrage du service

Analyse de l’incident

Méthodologie d’attaque simple

Vérification par webmail, envoi des spams par smtps

Attaque depuis l’île Maurice

Suite de l’incident

De nouveau une nouvelle attaque (adaptée)

Nouveau compte compromis : toujours une réponse au phishing

Première partie mardi soir 18h30-20h Deuxième partie : mercredi 7h30-9h

Même méthode d’attaque, nouvelle ip de la même région géographique

Ensemble des 3 attaques

Même gestion que précédemment

Action niveau administrateur : mise en place du contrôle de la _19/20

Conclusion

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

C’est complémentaire à un IDS

Avec le problème de la visualisation de la console (veille)

Au niveau gestion d’incidents

Outils très performants

Beaucoup d’informations disponibles

C’est un bon outil pour un CSSI

Améliore la connaissance de son environnement et du fonctionnement des applications réseaux

Beaucoup d’informations disponibles