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
- 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
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
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)
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)
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