houston on a un problème !

Publiée le 1er avril 2003, la RFC 3514 "The Security Flag in the IPv4 Header" s'inscrivait dans la tradition des canulars humoristiques souvent publiés au sein de la communauté informatique.
Cette RFC ("Requests For Comments") proposait d'indiquer à l'aide d'un bit non utilisé dans l'entête des paquets IPv4, l'aspect malintentionné ou pas de ces paquets afin de simplifier le travail des équipements et logiciels de sécurité informatique.
La proposition "Real-time Inter-network Defense"
Passée l'excitation à l'idée d'une telle implémentation au sein des infrastructures de sécurité des réseaux, il avait fallu se rendre à l'évidence, nous devions nous contenter du canular sans rien espérer de plus.
Durant l'année 2007, deux RFC ont permis de mieux encadrer les formats d'échanges que pourraient utiliser des systèmes de détection d'incidents:

• RFC 4765 - The Intrusion Detection Message Exchange Format
• RFC 5070 - The Incident Object Description Exchange Format

En ce début novembre 2010, l'Internet Engineering Task Force vient de publier deux nouvelles RFC qui pourraient bien modifier la donne en matière de sécurité :

• RFC 6046 - Transport of Real-time Inter-network Defense
  
• RFC 6045 - Real-time Inter-network Defense
  

Contexte d'utilisation
Comme le stipule la RFC 6045 - "Real-time Inter-network Defense (RID)" -, dans le cadre d'une attaque réseau, un opérateur doit pouvoir identifier l'adresse source de l'attaque ou demander l'identification de cette source, ou bien encore stopper l'attaque en amont de son réseau.
Basés sur le format d'échange IODEF (RFC 5070), les messages RID permettent au travers de blocs XML de déterminer quelles actions doivent être entreprises, qu'il s'agisse de stopper l'attaque ou de l'atténuer.
Les principaux destinataires de ces messages seront les opérateurs réseaux et les équipes CSIRT (Computer Security Incident Response Team).
Contexte d'intégration
Que vous soyez opérateurs de réseaux publics ou privés, vous disposez sans doute de systèmes de détection (IDS ou NIDS par exemple), d'analyses ou de filtrage/nettoyage d'attaques. Dotés d'une infrastructure de gestion du réseau (Network Operations Center), il ne vous reste plus qu'à intégrer les couches techniques et organisationnelles via un système de gestion des messages RID.
Les informations de type RID vous permettront :

• d'identifier les systèmes éventuellement compromis,
• de localiser la source possible d'une attaque,
• de lancer une requête d'investigation afin d'obtenir plus d'informations,
• d'informer un CSIRT d'une attaque en cours,
• de solliciter un CSIRT pour investigation sur un incident en cours,
• de mener les actions adéquates pour stopper ou atténuer l'incident
  

Difficultés rencontrées
La prudence doit néanmoins être de mise durant les phases de collecte, de traitement et éventuellement d'actions entreprises lors d'un incident. La RFC 6046 rappelle les difficultés liées à la nature même des attaques qu'un opérateur peut rencontrer.
Qu'il s'agisse de collecter des informations au plus près de la source, d'assurer la véracité des données ou de sécuriser les échanges de ces dernières, l'opérateur doit au préalable garder à l'esprit l'éventualité des conditions suivantes :

• l'attaque émane des sources multiples,
• l'attaque est encapsulée dans une autre (ex: SYN Flood pour augmenter le volume de données à analyser),
• l'attaque cible des services prioritaires (ex: attaque de serveurs DNS ce qui rend plus difficile la communication au sein même de l'opérateur),
• l'attaque utilise plusieurs protocoles IP (ex: TCP, UDP, ICMP, ...),
• l'attaque provient de système "zombies" qui ne sont que les acteurs et non les donneurs d'ordre,
• l'attaque s'inscrit dans la furtivité et son volume de traces est faible mais répété dans le temps

Collaboration entre les acteurs
Les canaux traditionnels de communications, qu'il s'agisse du courrier électronique ou du téléphone, ne sont pas satisfaisants dans un contexte de collaboration temps-réel entre opérateurs, quelque soit leur taille (obligation de disposer d'équipes 24/7) ou leur localisation géographique (problématiques de coopération avec des langues différentes).
Il est donc proposé aux opérateurs de mettre en place des systèmes nommés "Incident Handling System" (IHS), chargés de la gestion des messages RID. Ces systèmes pourraient être interconnectés et accessibles par les CSIRT, permettant ainsi aux opérateurs de confier à une tierce-partie de confiance l'analyse d'un incident.
Un CSIRT pourrait également par l'intermédiaire d'un système IHS déclencher les actions nécessaires à l'arrêt d'une attaque (pose de filtre, mise en place d'un trou-noir) sans avoir accès aux équipements de l'opérateur (ce dernier ayant simplement couplé l'IHS à ses infrastructures de gestion centralisée, un NMS par exemple).

Sécurisation des échanges

Par définition, les canaux de communications associés aux messages RID doivent être fortement sécurisés. Les RFC 6045 et RFC 6046 proposent l'utilisation de canaux ainsi caractérisés :

• dédiés et directs (principe des réseaux Out-Of-Band étendus entre opérateurs),
• contractualisés entre acteurs (procédures d'exploitation, qualité de services, ...),
• authentifiés (l'émetteur des messages étant reconnu par le(s) destinataire(s)),
• cryptés (les détails de l'utilisation de TLS étant précisés dans la RFC 6046)

Utilisation des messages

Les messages "Real-time Inter-network Defense" sont au nombre de six dans la proposition initiale:

• TraceRequest : demande d'investigation sur la source de l'attaque auprès d'un opérateur,
  
• RequestAuthorization : initiation de la communication auprès d'un opérateur,
• Result : résultat d'une requête précisant la source localisée ou l'action suivant demandée,
  
• Investigation : informe l'opérateur au plus près de l'attaque en confirmant celle-ci,
• Report : informe les acteurs lorsqu'aucune action n'est nécessaire (à des fins statistiques par exemple),
• IncidentQuery : demande d'information sur un incident (une réponse "Report" étant attendue)
  

Une majeure partie - environ 60 pages - de la RFC 6045 est réservée aux détails d'implémentation et d'utilisation des messages RID. La présentation complète et détaillée de ces messages dépasse malheureusement le cadre de ce billet et je vous invite donc à lire l'article de Stéphane Bortzmeyer qui aborde ces aspects là.
Conclusion
La sécurité des systèmes et des réseaux repose de nos jours sur les préceptes suivants : sensibilisation, information et plans d'actions. Aborder seule, la sensibilisation ne permet que de réduire le risque d'attaques sur les infrastructures (internes ou externes à son périmètre de responsabilité).
L'augmentation des attaques distribuées (voir nos articles sur les attaques de type DDOS), ainsi que le volume d'informations associé, imposent donc aux opérateurs d'élargir leur périmètre d'analyse, d'investigation et d'intervention :

• le contrôleur de botnet de l'opérateur A
  
• induit l'utilisation de ressources "zombies" de l'opérateur B
  
• qui rendent inopérantes les ressources "victimes" de l'opérateur C

En conséquence, la proposition "Real-time Inter-network Defense" des RFC 6045 et 6046 pourrait très bientôt apporter, avec l'aide de éditeurs et constructeurs de solutions de sécurité, un ensemble de réponses s'inscrivant dans un périmètre "global" et non limité au seul périmètre de l'opérateur de réseaux ou services.