Les flux réseaux

1 Introduction

Les flux réseau portant sur les dénis de services réseau, voici le sujet abordé ici. En effet, les flux réseau (« net flows ») permettent de détecter de manière très simple les dénis de services mutualisés vu la quantité de flux générés par l’armée de zombies qui vous attaque.

Nous allons nous attacher à vous présenter dans cet article d’autres applications de ces flux réseau : détection d’intrusion ou violation de politique, détection de canaux cachés ou encore prolifération d’un vers pour ne citer que quelques exemples. Alors que la détection de dénis de services mutualisés est quelque chose de relativement spécifique aux opérateurs et fournisseurs de services Internet, les autres applications sont-elles bien adaptées à un réseau interne ?

2 Netflow

Netflow est l’implémentation Cisco de la technologie. A l’origine, Netflow était une technologie de routage qui consistait à « router » par flux qui n’est plus très utilisée de nos jours. Chaque paquet qui traverse un routeur génère soit un nouveau flux, soit fait partie d’un flux existant. Les principales caractéristiques du datagramme IP (au standard de l’époque, ce qui n’est plus forcément le cas aujourd’hui vu que beaucoup d’applications encapsulent dans d’autres protocoles), à savoir adresses IP source et destination, ports source et destination (ou d’autres caractéristiques comme le type de message et le code pour ICMP), le protocole de transport, le ToS (Type of Service) ainsi que l’interface d’entrée forment le sept-tuble de base. Viennent s’ajouter d’autres informations comme les compteurs de données et de paquets, l’interface de sortie, les drapeaux TCP (ici s’arrête les caractéristiques de la version 1), le numéro d’AS (version 5) et l’adresse du prochain saut (i.e. le prochain routeur traversé). La durée de vie d’un flux dans le cache est limitée : sur un routeur, il est détruit après 15 secondes d’inactivité, 30 minutes d’activités, lors d’un RST/FIN TCP ou lorsque le cache est plein. A noter également : un flux est unidirectionnel, une session TCP génère donc deux flux (un entrant, un sortant).
Avec l’apogée des réseaux MPLS, le paquet n’est plus routé mais commuté sur la base de labels. Netflow a été adapté pour permettre la comptabilisation dans de tels environnements (version 9 de Netflow). La version la plus couramment déployée est la version 5. La version 8 ajoute le support de l’agrégation de flux côté routeur, la version 9 quant à elle, outre le support MPLS et une plus grande flexibilité, ajoute le support IPv6 et se rapproche d’IPFIX (pour ne pas dire l’inverse), le standard IETF pour les flux réseau.
Jusqu’à récemment, Netflow était ingress-only, c’est-à-dire que seuls les paquets qui entraient sur une interface étaient comptabilisés. Dans les versions récentes d’IOS (si le matériel le supporte), egress netflow peut-être configuré. Cela permet par exemple de détecter les attaques entrantes et sortantes sans avoir à configurer Netflow sur toutes les interfaces du routeur et avoir à vérifier que l’on ne compte pas le flux plusieurs fois lors de la traversée d’un réseau de taille conséquente.

Il existe trois méthodes d'échantillonnage : « full », « sampled », « random sampled ».

• Full génère pour chaque flux réseau une information qui va être exportée. Cette méthode est la plus ancienne et celle qui est supportée quasiment sur tous les routeurs mais n’est plus très courante chez les opérateurs car la charge routeur et la quantité d’informations de comptabilisation générées tout particulièrement lors d’un déni de service mutualisé sont trop importantes. En revanche, dans le cadre d’un réseau interne, celle-ci est quasiment obligatoire si l’on veut pouvoir détecter des reconnaissances lentes ou des violations de politiques qui essaient de se faire discrètes.
• Sampled permet de définir le pourcentage de flux à exporter sur le nombre total de flux générés. En général les opérateurs se limitent à 1 pour 100, voire 1 pour 1000. Même à 1 pour 1000, un déni de service mutualisé reste relativement facile ä détecter. L’avantage de cette méthode est la réduction de la charge CPU du routeur et de la quantité de Netflow exporté. L’inconvénient est qu’elle n’est pas bonne du point de vue statistique (fonction déterministe).
• Random Sampled a été introduit relativement récemment et sur les plateformes du type 72xx/75xx (alors que sampled n’était disponible que sur les GSR et les 76xx, i.e. les routeurs qui supportent CEF distribué). La différence entre sampled et random sampled est que le deuxième sélectionne un datagramme au hasard parmi les <x> configurés, ce qui est statistiquement meilleur.

Jusqu’à récemment le sampling était par routeur ; dans les versions très récentes d’IOS il est possible de classifier les datagrammes en fonction de différents attributs (champs de l’en-tête IP, NBAR, etc.) et d’avoir des sampling levels par classe.

Les exemples de configuration pour un routeur et un commutateur multi-niveaux sont disponibles dans le numéro 4 de MISC. A noter que dans les versions récentes d’IOS pour les commutateurs de la famille 65xx/76xx les versions 5 et 8 sont supportées (le drapeau TCP n’était entre autres pas présent dans la version 7) mais la configuration, les différences de fonctionnalités en fonction des cartes de supervision et de routage, et le choix du bon IOS restent un peu un casse-tête.

Dans les réseaux sans routeur ou avec des équipements qui ne peuvent générer du Netflow, une alternative est de brancher un PC sur un port en mode écoute (SPAN ou mirror port) est de s’en servir pour exporter des informations Netflow. Une liste d’outils (clients et serveurs Netflow, générateurs PCAP->Netflow) est disponible ici : http://www.switch.ch/tf-tant/floma/software.html. Cette approche ne résiste bien sûr pas vraiment au facteur d’échelle, même sur un réseau interne dès qu’il devient grand et que tout le trafic ne transite pas via un cœur bien défini.

Nous avons discuté des sondes et des sources Netflow, mais qu’en est-il du côté serveur ?

La méthode de stockage (fichier texte, base de données, etc.) et la politique de conservation ont un impact sur la taille des disques dont il faudra disposer, mais un autre élément important est l’agrégation des flux. Cette fonction est également disponible dans la version 8 Netflow et peut donc s’activer à la source, sur le routeur, mais on évitera de l’activer pour ne pas perdre en granularité. Sur le serveur, la politique de consolidation doit tenir compte des flux actifs ou non et du temps : si l’on agrège sur un jour il se pourrait qu’un couple IP source/destination et port source/destination (tout particulièrement si ce sont des services très demandés comme le DNS) apparaissent plusieurs fois et soient consolidés en un seul flux, ce qui serait faux.

3 Netflow ou PCAP ?

La meilleure réponse est sans doute : les deux. En effet, Netflow ignore le contenu applicatif transporté (uniquement des éléments de l’en-tête IP et des en-têtes des protocoles de la couche transport sont traités) alors qu’une trace réseau complète permet elle d’avoir toutes ces informations. Netflow permet d’avoir une vision macroscopique du réseau, la trace PCAP une vision microscopique. A force de vouloir faire dans le microscopique on a bien souvent tendance à oublier la vision globale, surtout dans le cadre de la résolution de problèmes réseau. De plus, comme pour les journaux générés par les systèmes et les applications, il convient de définir une politique de centralisation des « journaux » réseau, c’est un pré-requis pour l’analyste post-mortem d’incidents. Pour des raisons de coût et de gestion, pour ne citer que ces deux facteurs, il devient très vite clair qu’on ne peux pas déployer une sonde en écoute sur tous les commutateurs d’un réseau. Alors pourquoi ne pas faire tout simplement des captures PCAP dans des endroits stratégiques du réseau ? Cette alternative est une approche qui s’avère assez bonne dans bien des cas, mais un problème de taille doit être résolu avant : quelle est la capacité de mon système de stockage ? En effet, une capture complète occupe beaucoup de place et la quantité de Go (ou de To) disponibles (ainsi que leur coût) vont rapidement limiter le nombre de sondes et la durée de conservation…

L’approche la plus intéressante consiste à déployer Netflow sur l’ensemble du réseau et des sondes en écoute au niveau des endroits stratégiques : communication entre l’intérieur et l’extérieur du réseau (accès Internet, télémaintenance, accès VPN, extranet partenaire, etc.), le cœur du réseau (si vous concentrez tout votre trafic sur quelques « gros » commutateurs), en frontal de serveurs critiques, etc. Si vous décidez de centraliser ces informations il faudra également tenir compte du fait que votre trafic réseau va doubler (trafic normal + trafic PCAP entre les sondes et base de stockage), ou monter un réseau dédié à cet effet (ce qui évitera également de re-renifler les traces PCAP).

Rien ne vous empêche de lier ces deux systèmes. Par exemple, il n’est pas inintéressant de connecter un système de détection d’anomalies fondé sur Netflow avec un outil de détection d’intrusion réseau (NIDS). Par cette approche, si Netflow détecte une anomalie vous pouvez soit activer les sondes PCAP pour essayer d’obtenir plus d’informations (si l’événement ou l’attaque est toujours en cours), soit si vous avez un snapshot tournant sur quelques heures stocké dans une base, de lancer une requête. Ou inversement, le NIDS remonte une alerte et vous récupérez un historique Netflow depuis votre base.

4 Détection

Avant de parler de détection il convient d’aborder le sujet de la découverte… Combien d’administrateurs ou de responsables réseau connaissent bien l’architecture de leur réseau et le trafic qu’il transporte ?

4.1 Découverte de son réseau

Une application très intéressante des flux réseau est la découverte du réseau : ils permettent de le cartographier, de découvrir les applications l’utilisant, de caractériser un comportement « habituel » (baseline), etc. Cette étape de découverte engendre souvent une étape de « ménage », voire de définition d’une nouvelle architecture en fonction des besoins de segmentation sécurité (réseaux avec différents niveaux de sensibilité).

4.2 Scan

Un scan (surtout si ce n’est pas un scan lent) est relativement simple à détecter : beaucoup de petits flux vers la même destination (adresse IP ou port) avec, si c’est un scan TCP, peu de sessions établies (en surveillant les drapeaux TCP) et pour un scan UDP, beaucoup de messages ICMP en retour pour signaler que le port est fermé (ou absence de réponse si le pare-feu est de l’hôte est strict).

4.3 Virus et vers

La détection de virus et de vers reste une application relativement simple à mettre en place. En effet, la majorité d’entre eux ne sont pas très discrets et cherchent à se propager très rapidement, le plus souvent soit par tentative d’infection directe, soit après une recherche de ports ouverts. Une même machine infectée générera beaucoup de flux très courts et très petits vers un grand nombre de machines et/ou de ports.

Un grand nombre de vers intègrent un moteur qui va chercher de nouvelles machines à infecter suivant un algorithme plus ou moins aléatoire. Le plus souvent, le préfixe réseau de la machine source est le premier à être scanné, puis le sous-réseau supérieur, et enfin des adresses prises plus ou moins au hasard (pseudo-aléatoire). A ce moment, il se peut que des datagrammes aient comme destination un préfixe réseau dit « bogon » (http://www.cymru.com/Documents/bogon-dd.html#dd-route-non), c’est-à-dire qu’il n’est pas encore alloué ou n’est pas censé être présent dans les tables de routage BGP de l’Internet. Bien souvent, lorsqu’un attaquant décide de lancer un déni de service, il communique aux agents qui font partie de son armée de zombies de forger (spoofer) leur adresse IP source. Si vous voyez des flux sortants avec des adresses source qui ne font pas partie de votre plan d’adressage interne alors la probabilité d’infection est forte.

Pour détecter les virus qui se connectent à des sites (souvent en HTTP) pour récupérer une nouvelle charge (payload), il peut être intéressant de placer dans une règle spéciale tous les sites listés par les éditeurs d’anti-virus dans les descriptions publiques qu’ils mettent à disposition sur leurs sites. Canaux cachés et portes dérobées

Les canaux cachés les plus courants sur les réseaux WiFi reposent sur de l’encapsulation dans ICMP ou DNS. En entreprise, c’est le tunnel sur HTTP qui est le plus courant. Ces flux sont en général depuis et vers les mêmes adresses IP, le port destination est fixe et la taille du flux est importante : un flux ICMP ou DNS qui dure plus de quelques secondes et qui dépasse les quelques kilo-octets est bien vite suspect, de même qu’un flux HTTP relativement symétrique au niveau de sa taille et long (alors qu’un flux HTTP est plutôt court – sauf téléchargement – et très asymétrique – envoi vs. réception). Une porte dérobée quant à elle se traduit très souvent par un flux à destination d’un port non standard sur le système infecté, tout particulièrement si ce flux apparaît à des heures bizarres. Il peut également être intéressant de mettre en place des règles pour détecter les chevaux de Troie qui se mettent en écoute sur leur port par défaut. Un autre type de porte dérobée est l’accès à Internet « alternatif » : dans bon nombre de sociétés la politique de filtrage très stricte n’est plus (du tout) du goût de certaines personnes. Des flux vers ou depuis des adresses IP publiques qui ne transitent pas via votre passerelle d’accès à Internet méritent d’être analysés. Machines compromises et violation de politique

Les machines compromises, et tout particulièrement si ce sont des serveurs, peuvent se détecter lors de la prise de contrôle à distance par l’attaquant : celle-ci se fait souvent via la connexion à un port non standard en écoute. Cependant certains exploits utilisent un mécanisme qui permet de repasser par le même port que celui de l’application, voire d’utiliser la même session. Ceux-ci ne sont pas simples à détecter, mais à moins de mettre en place une porte dérobée, il n’est pas toujours facile de ré-exploiter la même faille plusieurs fois de suite (pour cause de crash lors ou à cause de l’exploitation), et le fait de maintenir la session ouverte pourrait également être détecté.

Il est également important d’observer les drapeaux TCP (attention, il faut vérifier si celui-ci est bien envoyé, ce n’est pas toujours le cas) qui permettent souvent de déterminer le sens de la communication, à savoir quel côté est le client et quel côté serveur. Le fait de définir une politique de flux pour les différents systèmes (clients et serveurs) permet de détecter facilement un événement qui dérive de la baseline. Les systèmes sont groupés en fonction de leur comportement réseau et les différents échanges, soit entre ces groupes (pour une vue grossière), soit entre tous les systèmes (pour une vision très fine). La complexité du système allant grandissant avec le nombre de flux et le nombre de systèmes, il faut en tenir compte lors de la phase de design (complexité de la détection, mais surtout de la définition de la politique).

Pour pousser plus loin, on peut très bien envisager de stocker dans la base de données les couples adresse MAC/port physique@équipement. Ceci permet de suivre les déplacements de ces adresses sur le réseau (portables, WiFI, DHCP, etc.), d’alerter si de nouvelles adresses apparaissent et, couplé aux données historiques Netflow, de détecter des déviations majeures dans le comportement. Il est probable que des informations comme l’adresse MAC et le VLAN ID soient rajoutées aux exports Netflow dans un futur proche ce qui évitera d’avoir à combiner Netflow avec des polls SNMP pour récupérer ces informations.

4.4 Spyware, IM et auto-update

Il peut être intéressant de surveiller les premiers flux qui suivent l’allocation via DHCP des paramètres réseau, l’ouverture de session sur la station ou la première communication sortante : en effet, c’est à ce moment-là que la majorité des « outils espions » et les fonctionnalités de mise à jour ou de reporting des logiciels se mettent à « téléphoner à la maison ». Il est également très courant de voir des flux qui reviennent toutes les <x> secondes ou minutes avec le même couple source/destination (spyware qui récupère un bandeau de publicité à afficher ou cheval de Troie qui envoie les frappes capturées par exemple), mais dans ce cas, le risque de faux positif est fort (rafraîchissement automatique de la page dans un navigateur). Un autre moyen de détecter les spywares et les outils de messagerie instantanée (voire certains clients P2P) consiste à surveiller les changements de protocoles pour un même couple source/destination : ces outils rivalisent d’ingéniosité pour essayer de trouver une faille dans le pare-feu (connexion TCP directe, « connexion » UDP directe, HTTP en direct ou via le proxy configuré pour les navigateurs, encapsulation sur ICMP ou DNS, etc.).

Et même si vous ne déployez pas de solution d’analyse des flux réseau, il est très intéressant de renifler les communications de votre ordinateur tout particulièrement au démarrage. On découvre souvent des choses intéressantes et inattendues.

4.5 FTP, P2P, etc.

Les protocoles et applications qui utilisent des ports dynamiques ou qui reposent sur une connexion de contrôle et une connexion de données ne sont pas simples à traiter. En effet, Netflow ne maintient pas d’état ni de relation entre deux flux, et n’effectue aucune analyse protocolaire qui serait nécessaire pour identifier les connexions de données gérées par une connexion de contrôle. Il est donc possible d’identifier sur la base de flux réseau uniquement les applications P2P qui reposent sur des ports fixes. Pour contourner cette limitation, certains vendeurs ont rajouté une couche qui permet d’identifier le protocole P2P sur la base de signatures, mais cela n’a déjà plus rien à voir avec Netflow. Une fonctionnalité comme NBAR (Network-Based Application Recognition) ou mieux, des équipements dédiés à la gestion de trafic P2P, sont des options possibles.

Les implémentations FTP qui respectent la RFC et quelques applications P2P sont une exception car le port de données et celui de contrôle + ou –1. Donc, même si le serveur écoute sur un autre port que le port standard (21/TCP pour FTP et 20/TCP pour FTP-DATA), il est possible d’identifier le couple contrôle+données.

Historiquement, les groupes qui publient des applications « piratées » génèrent des fichiers d’une taille standard (comme les 1.44 Mo à l’époque où l’on utilisait encore des disquettes) ce qui permet également de renforcer la qualité de la détection en se basant sur la taille du flux.

4.6 Recherche historique

On a souvent tendance à ne regarder que les 10 premiers d’un classement (comme par exemple l’utilisateur qui abuse le plus de la connexion Internet de l’entreprise), mais dans le cadre de la mise en place de mécanismes de recherche dans les données historiques, le top 10 est aussi important que le low 10. Et ceci sur tous les paramètres que permet d’avoir Netflow. De cette façon on peut souvent détecter les flux « perdus » qui peuvent donner des indications intéressantes sur une attaque bien dissimulée ou des reconnaissantes lentes de ports.

Il est également intéressant de noter que, dans certains environnements (et en fonction des lois et des régulations locales), le fait de ne stocker que des informations Netflow ne constitue pas une atteinte à la vie privée. Ce côté moins intrusif permet bien souvent de « vendre » cette solution en interne. Et bien souvent, le flux en dit assez et les données transportées ne sont qu’un « bonus », un peu comme un le sujet d’un e-mail en clair et son contenu chiffré…

Il existe un risque lié à l’injection de faux messages de comptabilisation Netflow. En effet, ils ne sont ni signés ni chiffrés et le seul mécanisme de défense (bien faible) est le numéro de séquence. Il est relativement simple de forger de tels paquets, vu qu’ils sont transportés sur UDP.

5 Conclusion

Nous nous sommes attachés à décrire différentes applications des flux réseau. Comme vous avez pu le constater, leur déploiement sur un réseau interne d’entreprise peut apporter une visibilité sans précédent, tout particulièrement de nos jours où les réseaux sont de plus en plus ouverts et les flux de plus en plus complexes. Un déploiement, même de test, permet de découvrir bien des choses insoupçonnées… Si votre réseau est très segmenté, avec de nombreux pare-feu, le fait d’avoir des sources Netflow dans ces différents segments et un collecteur qui centralise les flux pourra vous aider à valider votre politique de sécurité et surtout son implémentation.

Les différents exemples sont loin d’être une liste exhaustive, à vous de trouver de nouvelles applications et de définir les critères de détection qui correspondent à votre environnement particulier. Et n’oubliez pas que tout comme avec un outil de détection d’intrusion, la qualité des alertes et leur nombre sont fonction du temps passé à fignoler sa configuration.

La prochaine étape consistera peut-être à lier ces mécanismes de détection avec des mécanismes de protection automatiques (désactivation du port sur le commutateur par exemple). Des technologies existent, l’avenir nous dira si elles seront adoptées.

6 Ressources

http://www.unixgarden.com/index.php/administration-reseau/les-flux-reseau