ZneTS v1.2 «The NEtwork Trafic Supervisor»



Documents pareils
Le monitoring de flux réseaux à l'in2p3 avec EXTRA

Gestion et Surveillance de Réseau

Métrologie et gestion d incidents!

IPFIX (Internet Protocol Information export)

Internet - Outils. Nicolas Delestre. À partir des cours Outils réseaux de Paul Tavernier et Nicolas Prunier

Vue d'ensemble de NetFlow. Gestion et Supervision de Réseau

Teste et mesure vos réseaux et vos applicatifs en toute indépendance

SECURIDAY 2013 Cyber War

TP réseau Les réseaux virtuels (VLAN) Le but de se TP est de segmenter le réseau d'une petite entreprise dont le câblage est figé à l'aide de VLAN.

RFC 7011 : Specification of the IP Flow Information export (IPFIX) Protocol for the Exchange of Flow Information

LINUX - Sécurité. Déroulé de l'action. - 3 jours - Contenu de formation

KMnet Admin LOGICIEL COMPLET ET PERFORMANT D'ADMINISTRATION DES PÉRIPHÉRIQUES.

Présentation du modèle OSI(Open Systems Interconnection)

Programme formation pfsense Mars 2011 Cript Bretagne

Détection d'intrusions et analyse forensique

Retour d expérience sur Prelude

Firewall IDS Architecture. Assurer le contrôle des connexions au. Sécurité 1

CONFIGURATION DE BASE. 6, Rue de l'industrie BP130 SOULTZ GUEBWILLER Cedex. Fax.: Tel.:

netmet Network's METrology, De nouveaux besoins, de nouvelles fonctionnalités

Devoir Surveillé de Sécurité des Réseaux

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant.

PACK SKeeper Multi = 1 SKeeper et des SKubes

VoIP et "NAT" VoIP et "NAT" 1/ La Traduction d'adresse réseau. 1/ La traduction d'adresse réseau. 1/ La traduction d'adresse réseau

Administration de Réseaux d Entreprises

Présentation et portée du cours : CCNA Exploration v4.0

Introduction. Adresses

Figure 1a. Réseau intranet avec pare feu et NAT.

Chap.9: SNMP: Simple Network Management Protocol

Dispositif e-learning déployé sur les postes de travail

Plan. Rappels sur Netflow v1 v8. Netflow v9. Collecteur UTC «IPFlow» Cisco IOS : Implémentation de Netflow IPv6

TP Analyse de flux et outils Netflow : Nfdump et Nfsen

Intérêt du NAT (Network Address Translation) Administration Réseau Niveau routage. Exemple d Intranet. Principe NAT

Réseau : Interconnexion de réseaux, routage et application de règles de filtrage.

Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des tablettes ou smartphones.

Services Réseaux - Couche Application. TODARO Cédric

Nmap (Network Mapper) Outil d exploration réseau et scanneur de ports/sécurité

La supervision des services dans le réseau RENATER

But de cette présentation

II/ Le modèle OSI II.1/ Présentation du modèle OSI(Open Systems Interconnection)

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2.

Sécurité des réseaux Firewalls

Sécurisation du réseau

KASPERSKY DDOS PROTECTION. Découvrez comment Kaspersky Lab défend les entreprises contre les attaques DDoS

18 TCP Les protocoles de domaines d applications

Administration Réseau

La surveillance centralisée dans les systèmes distribués

TER Réseau : Routeur Linux 2 Responsable : Anthony Busson

Présentation et portée du cours : CCNA Exploration v4.0

Test d un système de détection d intrusions réseaux (NIDS)

Plan de cours. Fabien Soucy Bureau C3513

Routeur Gigabit WiFi AC 1200 Dual Band

Principaux utilisateurs du Réseau

Dossier de réalisation d'un serveur DHCP et d'un Agent-Relais SOMMAIRE. I. Principe de fonctionnement du DHCP et d'un Agent-Relais

DHCP et NAT. Cyril Rabat Master 2 ASR - Info Architecture des réseaux d entreprise

UCOPIA EXPRESS SOLUTION

Master d'informatique 1ère année. Réseaux et protocoles. Architecture : les bases

Etape 1 : Connexion de l antenne WiFi et mise en route

Sécurité et Firewall

Informations Techniques Clic & Surf V 2.62

Réseaux. Moyens de sécurisation. Plan. Evolutions topologiques des réseaux locaux

ManageEngine Netflow Analyser


LAB : Schéma. Compagnie C / /24 NETASQ

ETI/Domo. Français. ETI-Domo Config FR

Cahier des Clauses Techniques Particulières. Convergence Voix - Données

CONFIGURATION DE BASE

Assistance à distance sous Windows

Charte d installation des réseaux sans-fils à l INSA de Lyon

CONFIGURATION FIREWALL

Mettre en place un accès sécurisé à travers Internet

Supervision de réseau

Résolution des problèmes de connexion XDMCP aux hôtes UNIX et Linux

Alexis Lechervy Université de Caen. M1 Informatique. Réseaux. Filtrage. Bureau S3-203

Les messages d erreur d'applidis Client

Pare-feu VPN sans fil N Cisco RV120W

État Réalisé En cours Planifié

Installation du SLIS 4.1

Bravo! Vous venez d acquérir un routeur large bande à 4 ports Conceptronic C100BRS4H.

Manuel d utilisation de la plate-forme de gestion de parc UCOPIA. La mobilité à la hauteur des exigences professionnelles

Microsoft Hosted Exchange 2010 DOCUMENT D EXPLOITATION

Routeurs de Services Unifiés DSR-1000N DSR-500N DSR-250N

Documentation : Réseau

Cloud public d Ikoula Documentation de prise en main 2.0

AudiParc Recommandations IMPORTANTES. AudiParc Principe de fonctionnement. AudiParc Installation Déployement

Métrologie des réseaux IP

Performance et usage. La différence NETGEAR - R7000. Streaming HD illimitée

Le générateur d'activités

NetCrunch 6. Superviser

Technologies du Web. Créer et héberger un site Web. Pierre Senellart. Page 1 / 26 Licence de droits d usage

MSP Center Plus. Vue du Produit

Module 8. Protection des postes de travail Windows 7

Formation Iptables : Correction TP

Infocus < >

Le Ro le Hyper V Premie re Partie Configuration et Prise en main du gestionnaire Hyper-V

SDIS 84 PROJET INFOGERANCE PROCEDURE. Procédure

Date : NOM Prénom : TP n /5 DISTANT : CONCEPTS ET DIFFÉRENCES

Chapitre 1 Windows Server

Serveur FTP. 20 décembre. Windows Server 2008R2

Transcription:

ZneTS v1.2 «The NEtwork Trafic Supervisor» Ismael ZAKARI TOURE LPSC IN2P3 53, rue des Martyrs, 38026 Grenoble Cedex Thierry DESCOMBES LPSC IN2P3 53, rue des Martyrs, 38026 Grenoble Cedex contact: info@znets.net Résumé ZNeTS, "The Network Traffic Supervisor", est un outil de surveillance des machines d'un ou plusieurs LANs, développé pour l'in2p3. Ses fonctions sont : - la conservation de plusieurs mois de données de trafic en base de données ; - la recherche et l'extraction de données, grâce à son moteur de recherche intégré ; - la détection d'anomalies provoquant la génération d'alerte et l'envoi éventuel de email ; - le calcul et la visualisation des statistiques horaires et journalières du trafic global et individuel (pour chaque sous-réseau, et machine du LAN). ZNeTS s'adapte à toutes les architectures réseau. Il est capable d'acquérir ses données non seulement à partir des NetFlow (mode netflow), mais aussi directement depuis une interface physique (mode sniffer). Il est capable de décoder la plupart des versions de NetFlow et l'ipfix. Il est compatible IPv4 et IPv6. Des packages ont été construit pour la plupart des distributions Linux. Mots clefs Supervision, surveillance, réseau, LAN, traces, analyse trame, métrologie, détection anomalies, sniffer, NetFlow, IPFIX, sonde, collecteur 1 Généralités ZNeTS, est l'acronyme de "The Network Traffic Supervisor". C'est un outil de surveillance des machines d'un ou plusieurs LANs. Il a été conçu pour satisfaire 4 objectifs : - fournir des traces des flux réseaux entrants et sortants - offrir des outils permettant une analyse fine de ces données - détecter certaines anomalies et lever des alertes - être un outil de métrologie pertinent et fiable ZNeTS est simple à déployer. Il a été développé en C++ et intègre un serveur web implémentant la norme HTTP/1.1(RFC2616). Une authentification par identifiant et mot de passe, ou par certificats X509 est possible. 12/10/2011 1/9 JRES 2011

Une interface web est disponible. Basée sur le framework Dojo1.6, elle est particulièrement ergonomique et permet l'interprétation et la visualisation des données. ZNeTS fonctionne au choix, en mode collecteur de NetFlow (IPFIX), ou capture (sniffer). Dans le premier cas, il reçoit et traite des données de trafic agrégées des routeurs, pare feux, ou d'une sonde logicielle (ZNeTS ou toute autre sonde logicielle capable d'envoyer des NetFlow). En mode sniffer, la sonde acquiert ses données directement d'une de ses cartes réseau. ZNeTS peut fonctionner sur des réseaux IPv4 et Ipv6. Ce logiciel a été développé avec l'objectif d'être à la fois très modulaire et très simple à déployer. Des packages ont été construits pour la plupart des distributions Linux. 2 Les flux réseaux de ZneTS ZNeTS gère une liste de flux bidirectionnels ordonnés chronologiquement. Ces flux sont caractérisés par 1 clé (unique) composée de 5 données : IP local (V4 ou V6) IP externe (V4 ou V6) Protocole de niveau 3 Port Local Port Externe Ils contiennent également : le sens d'établissement de la connexion le nombre de paquets entrants et sortants le nombre d'octets de trafic entrant et sortant un masque des éventuels flags TCP une date de début une date de fin le pays relatif à l'ip externe le numéro de l'as 1 de l'ip externe Tous les flux de ZNeTS sont donc intrinsèquement entrants ou sortants. (Les flux internes sont ignorés) Toutes les dates sont au format UTC, afin de faciliter la gestion des changements d'horaire. L'application web applique le décalage correspondant à la zone géographique dans laquelle est situé votre navigateur. Ce schéma de données offre 2 avantages, par rapport à des flux unidirectionnels classiques. Tout d'abord, ils sont moins nombreux (1 flux bidirectionnel correspond à 2 flux unidirectionnels) et ils sont donc moins volumineux. De plus, ils permettent une indexation facile et naturelle des flux par IP locale. 1 Autonomous System 12/10/2011 2/9 JRES 2011

3. Agrégation des flux ZNeTS agrège ses flux au cours d'un cycle ou «période d'agrégation», dont la durée est paramétrable 2. Plus cette période est longue, moins il y a de flux enregistrés par heure. À la fin de cette période, les flux sont réinitialisés. Les compteurs sont remis à zéro. Les autres paramètres sont conservés. Les flux dont les compteurs étaient déjà à zéro, sont considérés comme terminés et sont supprimés. Ainsi, un flux qui s'étend sur plusieurs cycles aura une entrée par cycle. Les quantités de trafic et de paquets seront propre à un cycle donné. En plus des 5 champs composant la clé (voir ci-dessus), la date de début sera également conservée d'un cycle à l'autre. L'agrégation des ports clients est également possible 3, ce qui permet d'ignorer les ports client. Cette option permet de diminuer, en moyenne, d'un facteur 3 à 4, le nombre de flux. 4. L'acquisition des données L'acquisition des données se fait soit à travers la réception de NetFlow, soit en décodant les trames d'une interface dédiée (mode sniffer). 4.1 Utilisation de la technologie NetFlow ZNeTS est compatible avec la technologie NetFlow, qui est la plus répandue pour l'analyse réseau (notamment supportée par tous les systèmes basés sur l'ios Cisco). Elle est basée sur un algorithme qui agrège, pendant une durée paramétrable, une liste de flux unidirectionnels ordonnés chronologiquement. Les données sont envoyées vers un collecteur selon un modèle «push» (Par défaut, le port 2055 du protocole UDP est utilisé) 10 versions de ce protocole existent. ZNeTS supporte les versions les plus répandues : 1, 3, 5, 6, 7, 9 et IPFIX. Les versions 9 et IPFIX sont basées sur un mécanisme de template, c'est à dire la définition dynamique des modèles de données, par la sonde. Pour que ZNeTS puissent interpréter les NetFlow V9 et IPFIX, les templates doivent contenir les données suivantes : Données indispensables pour les NetFlow V9: ( IPV4_SRC_ADDR ET IPV4_DST_ADDR ) OU (IPV6_SRC_ADDR ET IPV6_DST_ADDR ) PROTOCOL IN_BYTES IN_PKTS L4_SRC_PORT L4_DST_PORT FIRST_SWITCHED LAST_SWITCHED Données facultatives pour les NetFlow V9: TCP_FLAGS OUT_BYTES OUT_PKTS 2 voir man znets.conf - paramètre «nbcollectcycleperhour» 3 voir man znets.conf - paramètres «aggregatetcpclientports» et «aggregateudpclientports» 12/10/2011 3/9 JRES 2011

IN_SRC_MAC OUT_DST_MAC Données indispensables pour IPFIX : ( sourceipv4address ET destinationipv4address ) OU ( sourceipv6address ET destinationipv6address ) protocolidentifier octetdeltacount packetdeltacount sourcetransportport destinationtransportport ( systeminittimemilliseconds ET flowstartsysuptime ET flowendsysuptime ) OU ( flowstartmilliseconds ET flowendmilliseconds ) OU ( flowstartseconds ET flowendseconds ) Données facultatives pour IPFIX : tcpcontrolbits postoctetdeltacount postpacketdeltacount sourcemacaddress postdestinationmacaddress Les NetFlow V9 et IPFIX reçus incomplets sont ignorés. À chaque fin de cycle, un message de statistique informe du nombre de flux reçus, et ignorés (au total, ainsi que pour chaque version du protocole) 4.2 Utilisation d'une interface dédiée (IpSniff) ZNeTS peut aussi acquérir des trames directement depuis une interface dédiée. Ces trames sont alors analysées, et les informations de flux en sont extraites. Actuellement, ZNeTS n'analyse que les entêtes. Le contenu des trames est ignoré. Certaines anomalies des datagrammes sont détectées et génèrent des messages d'information. Les paquets erronés ou incomplets sont ignorés. ZNeTS peut éventuellement être raccordé à un lien vlan trunk. La détection est automatique. À la fin des cycles, un message de statistique informe du nombre de paquets reçus et perdus. NB : L'utilisation d'une interface dédiée sollicite beaucoup plus le CPU et l'utilisation de la mémoire. Son utilisation n'est pas conseillée sur des réseaux très haut débit (plusieurs Gb/s). 4.3 Exporter des NetFlow ZNeTS peut également être configuré pour se comporter comme une simple sonde NetFlow. Ainsi, il est tout à fait envisageable de faire communiquer 2 instances de ZNeTS (pour déporter l'acquisition des données, par exemple), sans qu'aucun autre logiciel ne soit requis. 12/10/2011 4/9 JRES 2011

5. Déploiement ZNeTS a été conçu pour s'adapter à la plupart des architectures réseaux. Avec un routeur compatible NetFlow, le déploiement est simple. ZNeTS devra alors être configuré en mode collecteur de NetFlow 4. Avec un routeur ne supportant pas les NetFlow mais disposant des fonctionnalités de mirroring de ports, ZNeTS pourra être configuré en mode sniffer 5. Si vous ne disposez ni des fonctionalités de NetFlow ni de mirroring, d'autres solutions peuvent encore être envisagées : installation d'un hub, mise en place d'un PC agissant comme un pont transparent, équipé d'une sonde ZNeTS, Avec un ou plusieurs réseaux NATés dans votre LAN, en visualisant les machines avec leurs adresses privées. NetFlow Serveur NAT Équipé d'une sonde NetFlow Réseau public avec accès Wifi Hub / Switch utilisant le mirroring de port ( sans les fonctionnalités NetFlow ) Une solution est de démarrer une Instance ZNeTS en mode sonde NetFlow qui enverra ses données à l'instance ZNeTS principale (sur laquelle, cette nouvelle source de NetFlow, et ce nouveau réseau local auront été déclarés). Il pourra être utile également d'ignorer le trafic du serveur de NAT, afin de ne pas prendre 2 fois en compte le trafic vers ce réseau 6. NB : La technologie Netflow repose sur l'utilisation systématique du protocole UDP pour l'envoi des données. Ce protocole est sensible aux congestions, pertes de paquets, désynchronisations... Il est donc recommandé de mettre le collecteur et le ou les sondes de NetFlow sur un lien dédié suffisamment rapide et non routé. 6. Traitements périodiques ZNeTS effectue, de manière cyclique, plusieurs types de traitement. 1) Le «cyclic collector processing» a lieu à chaque fin de cycle. Au cours de celui-ci, les flux de ZNeTS sont enregistrés (en base de données et sous forme de fichiers). Les alertes sont générées. Éventuellement, si le mode sonde est activé, ZNeTS envoie ses flux vers son collecteur. Une entrée dans les logs est ajoutée à la fin du traitement. Elle précise le nombre de flux ZNeTS, ainsi que 4 voir znets.conf - «usenetflow» 5 voir znets.conf - «usepcap» 6 voir znets.conf - «AddLocalHostToIgnore» 12/10/2011 5/9 JRES 2011

la durée du traitement (total, nécessaire à l'enregistrement en base de données : «recdb», à l'écriture des fichiers«wrfile», à l'envoie sous forme de Netflow «sndnf», et au processing en mémoire «proclh») 2) Le «hourly stats processing» démarre à chaque changement d'heure. Les statistiques pour la métrologie sont calculées et enregistrées en base de données. Une entrée dans les logs est ajoutée à la fin du traitement avec la durée du traitement (total, et nécessaire à l'insertion en base de données «recdb») 3) De manière analogue, un «daily stats processing» démarre à chaque fin de journée (à minuit UTC). 4) Lorsqu'il est activé le «databasedataflowautovacuum» démarre à 4h du matin UTC. Sa fonction est de supprimer les flux, datant de plus d'un nombre paramétrable de jours, puis de mettre à jour les index des tables du SGBD. 7. Détection d'anomalies À chaque fin de cycle, ZNeTS analyse le trafic collecté par machine locale, et génère une alerte dès qu'un comportement anormal est détecté. Une étape d'ajustement des seuils peut parfois être nécessaire (en fonction de la durée des cycles, du type de trafic, ) Les alertes sont relatives au dernier cycle écoulé et sont actuellement de 7 types distincts : une machine locale a communiqué avec plus de X machines externes : permet de repérer l'utilisation de logiciels de type Peer to Peer. une machine locale a scanné une machine externe: suite à plusieurs tentatives de connexions infructueuses sur des ports distincts et éventuellement des protocoles différents. une machine externe a scanné une machine interne : idem une machine locale a eu du trafic SMTP sortant de plus Y KB une machine locale a eu du trafic avec une machine externe définie comme compromise. Le logiciel «znetssuspiciousdl» fait parti de ZNeTS et permet le téléchargement ainsi que la mise à jour de listes de machines suspectes.(serveur botnets, vers, virus, ) une machine locale interroge un serveur DNS externe inconnu. une adresse IP locale est dupliquée Les alertes peuvent être envoyées par mail. Elles sont stockées en base de données. Elles sont activables et désactivables. Il est possible définir des exceptions et des seuils spécifiques. La simplicité de ces algorithmes de détection les rend particulièrement efficaces. 8. Métrologie ZNeTS est un puissant outil de métrologie, permettant de visualiser les statistiques horaires et journalières. Potentiellement, plusieurs mois et années de statistiques sont disponibles et peuvent être consultés. La plupart des statistiques se présente sous forme de graphiques empilés, représentant pour chaque heure ou chaque jour, les 10 plus gros consommateurs (machine locale, service,...) d'une ressource. 33 types de graphique sont disponibles pour l'ensemble du réseau et pour chaque sous-réseau, et 7 types pour chaque machine du réseau local. Les nombreuses interactions Javascript sur les graphiques aident à suivre les évolutions, et à bien interpréter les données. Les clics sur les graphiques pré-remplissent les formulaires de recherche de flux et d'analyse de machines locales. 12/10/2011 6/9 JRES 2011

Exemple d'un graphique de trafic réseau Ces données statistiques (utilisées pour générer tous les graphiques, à l'exception des camemberts), sont stockées indépendamment des données. Les options de nettoyage automatique 7 ne les suppriment pas. (L'espace qu'elles occupent dans la base de données étant insignifiant). 9. Analyse détaillée ZNeTS possède un formulaire de recherche assez complet, qui permet la sélection puis la visualisation des données brutes enregistrées. Les exports au format CSV sont possibles. Les IPs externes sont automatiquement résolues (lorsqu'elles sont survolées par le curseur de la souris) et recopiées (lors d'un clic). De plus, ZNeTS s'interface facilement avec l'utilitaire «whois» 8, et facilite ainsi l'interrogation des registres Internet. 7 Voir man znets.conf paramètres «databasedataflowautovacuum» et «databasedataflowautovacuumsize=nb_days» 12/10/2011 7/9 JRES 2011

10. Performance Le tableau ci-dessous résume les performances de ZNeTS sur 3 sites. Les résultats sont indicatifs et issus de moyennes. Les 3 instances fonctionnent avec des cycles d'un quart d'heure. L'IPNL a fait le choix de ne pas utiliser l'agrégation de port, ce qui explique son nombre de flows plus important.. Site Type de serveur Débit moyen entrant/sortant Nb machines locales Nb Flows par ¼ d'heure Durée d'un «Cycle processing» Durée d'un «Hourly Stats processing» Taille de la BD sur le disque LPSC Dell PE1950 (age > 5ans) 25Mbps / 19Mbps 2530 10900 3s 10s 7Go/mois IPNL Dell PE1950 (age > 5ans) 31Mbps / 26Mbps 2760 24340 1s 12s 15Go/mois Centre Calcul Dell R610 avec 2 disques SSD en stripping 1.3 Gbps / 2.4 Gbps 10430 320000 10s 17s 6Go/jours Plusieurs années de trafic peuvent être stockées en base sans problème (à condition que l'espace disque soit suffisant), mais à l'usage, l'intérêt peut sembler limité. En effet, ces données sont principalement utilisées pour l'analyse fine d'une anomalie, à laquelle on procède généralement, peu de temps après qu'elle se soit produite. L'utilisation de fichiers, pour le stockage, est donc à privilégier 9, conjointement au nettoyage automatique des données en base (dont l''âge maximum est à déterminer à l'usage et en fonction du trafic). 11. Conclusion ZNeTS est un outil complet, fiable et abouti. Il est simple à déployer, et complètement transparent pour le réseau et les machines clientes. Il permet de conserver les traces de tous les flux entrants et sortants, pendant plusieurs mois. Les graphiques de métrologie sont pertinents, interactifs, et facilement interprétables. La sélection et la consultation des trames est aisée : les formulaires sont préremplis automatiquement. Après un incident de sécurité, ou un dysfonctionnement, ZNeTS est l'outil idéal pour visualiser rapidement l'état du réseau, analyser précisément les conséquences d'une attaque, d'un virus, ou de mettre en évidence un vol d'informations. En outre, il permet d'identifier, d'une manière fiable et préventive, des machines locales compromises.* 8 voir man znets.conf - paramètre «whoiscmd» 9 Voir znets.conf - paramètre «savedataflowtofile», qui permet la création de fichier journalier de données au format CSV 12/10/2011 8/9 JRES 2011

12.Bibliographie [1] RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1 [2] RFC2720 - Traffic Flow Measurement: Meter MIB [3] RFC3917 - Requirements for IP Flow Information Export (IPFIX) [4] RFC3954 - Cisco Systems NetFlow Services Export Version 9 [5] RFC3955 - Candidate Protocols for IP Flow Information Export (IPFIX) [6] RFC5101 Specification of the IP Flow Information Export (IPFIX) [7] RFC5102 IPFIX Information Model [8] RFC5470 Architectures for IP Flow Information Export [9] RFC5472 Flow Information Export (IPFIX) Applicability [10] RFC5655 Specification of the IP Flow Information Export (IPFIX) File Format 12/10/2011 9/9 JRES 2011