Brevet FR2852754A1 — publié le 20040924

Domaine technique La présente invention concerne de façon générale les réseaux de transmissions dans lesquels un problème crucial est dû aux attaques de déni de service et a trait en particulier à un système et une méthode de protection d'un réseau de transmission contre les attaques de déni de service. Etat de la technique Parmi les attaques contre les réseaux de transmission dans lesquelles une pluralité d'utilisateurs peut accéder à une pluralité de serveurs, le déni de service (DoS) devient de plus 15 en plus dangereux pour les réseaux de type IP. Une attaque DoS est caractérisée par des tentatives explicites dues à des pirates dans le but d'empêcher les utilisateurs légitimes d'un service d'utiliser ce service. De telles tentatives comprennent la tentative d'inonder un réseau de 20 manière à empêcher le trafic de réseau légitime de se faire correctement, la tentative de perturber les connexions entre deux machines de manière à empêcher l'accès à un service, la tentative d'empêcher un utilisateur particulier d'accéder à un service et la tentative de perturber un service fourni à un système ou une 25 personne spécifique. Les attaques de déni de service peuvent être classées par le résultat de l'attaque qui peut être la consommation de ressources rares, limitées ou non renouvelables, la destruction ou l'altération d'une information de configuration ou la destruction 30 ou altération de composants du réseau. Elles peuvent aussi être classées par la méthode utilisée. Les deux principales méthodes utilisées concernent les attaques par "paquet magique" et les attaques par "épuisement des ressources". Les attaques par "paquet magique" exploitent habituellement un vulnérabilité du système d'exploitation ou de l'application en envoyant un ou plusieurs paquets particuliers et résultent en général en une réponse très anormale, une utilisation CPU excessive ou une 5 destruction complète du système. Les horribles attaques "Ping of Death" ou "WinNuke" sont de cette catégorie. Les attaques par épuisement des ressources ne s'appuient pas sur la vulnérabilité, mais tirent avantage d'un fait basique qui est que les ressources de calcul sont finies. Le serveur a 10 seulement tant de RAM, peut servir seulement tant de clients et peut traiter seulement tant d'octets par seconde au travers des réseaux connectés. Une DoS par épuisement des ressources se produit lorsqu'un pirate tente volontairement de s'approprier le plus de ressources possible, au détriment des autres 15 utilisateurs. Les attaques DoS sont très faciles à réaliser et presque impossibles à contrer. La raison est due à la structure d'Internet et de ses protocoles. Internet a été conçu dès le départ pour être robuste et fournir des messages sans se 20 préoccuper du reste. Il y a des défenses spécifiques contre ces attaques. Spécifiquement, il est nécessaire de maintenir le logiciel à jour, de prévoir des corrections o c'est possible, et de restreindre autant que possible l'accès aux services. La sécurité physique est aussi importante. Filtrer et analyser le 25 contenu est obligatoire. Ceci peut aller de la simple utilisation d'un pare-feu à l'utilisation de serveurs proxy d'analyse de virus et de systèmes de détection d'intrusion. Mais les méthodes courantes qui implémentent un filtrage important présentent des inconvénients du fait qu'elles réduisent 30 la performance dans la mesure o le traitement est activé en permanence et coûte cher puisque tout le trafic doit être filtré. Des dispositifs spécifiques ont été conçus pour détecter différents types connus d'intrusion tels que les systèmes de détection d'intrusion (IDS) . Un IDS est un système de détection des intrusions provenant de pirates informatiques, mais pas 5 seulement pour le DoS mais aussi pour quatre types d'intrusion. Un IDS surveille les paquets sur le réseau sur lequel il est connecté et essaie de découvrir si un pirate tente de pénétrer dans le système ou de provoquer une attaque de déni de service. Un exemple typique est un système qui surveille un grand nombre 10 de requêtes de connexion TCP vers beaucoup de ports différents sur une machine, pour découvrir si quelqu'un tente un balayage d'un port TCP. Un IDS peut fonctionner soit avec une machine cible qui surveille son propre trafic tel qu'un pare-feu, soit avec une machine indépendante surveillant tout le trafic réseau 15 (routeur, hub ou sonde). Les attaques DoS sont des techniques qui ne nécessitent pas d'espionnage mais seulement l'usurpation pour être moins visibles même pour l'IDS et difficiles à éliminer. Ainsi, les attaques DoS qui s'appuient sur des paquets modifiés de protocoles sans 20 établissement de connexion peuvent utiliser l'usurpation IP de manière à masquer la véritable origine des paquets. Ceci signifie que, même s'il est possible de détecter l'attaque, il n'est pas possible de la suivre ou de la stopper puisque l'attaquant n'attend pas de réponse de la cible. De façon à détecter et stopper les attaques, beaucoup de compagnies mettent en oeuvre des systèmes de détection d'intrusion (IDS). Cependant, un problème avec les systèmes IDS est qu'ils doivent faire un grand nombre d'analyses intensives et avec contrôle d'état. Les paquets sont formés de manière à utiliser 30 une quantité maximale des ressources IDS. En utilisant un grand nombre d'adresses IP usurpées et en utilisant ceci pour créer le plus possible d'objets d'état sur le système IDS, de manière à réaliser le maximum d'analyse de protocole, il sera possible, dans la plupart des cas, d'augmenter le temps d'attente de la détection IDS dans une mesure telle que l'attaque puisse être réalisée avant que l'IDS soit capable de détecter l'attaque. Dans beaucoup de cas, les systèmes IDS et pare-feu seront capables de détecter rapidement les attaques, surtout les attaques connues. Un parefeu peut le faire en bloquant les adresses IP suspectes pendant une période de temps. Cependant, le problème de l'usurpation est tel que peu d'administrateurs 10 choisissent d'implémenter cette solution. Si un pare-feu bloque un paquet IP qui met en oeuvre une attaque, un attaquant qui usurperait une grande quantité d'adresses IP pourra laisser le pare-feu devenir un outil DoS parce que le pare-feu ralentira tout le trafic. En fait, ceci 15 signifie qu'il y a un choix difficile pour le réseau entre être potentiellement pénétrable ou être très vulnérable au DoS lorsque un filtrage plus complexe est implémenté pour lutter contre les adresses usurpées. En outre, il est bien connu que la plupart des fournisseurs 20 de services et fabricants ne prennent pas suffisamment de mesures anti- usurpation parce que celles-ci présentent des inconvénients pour l'efficacité. Le résultat est qu'il y a une grande sousestimation du risque d'usurpation aussi bien du côté des administrateurs que du côté des fabricants de dispositifs. Une solution au problème DoS pourrait être de mettre en oeuvre un mécanisme pour détecter sur un noeud d'entrée à la frontière du réseau la survenance d'actions répétitives et alors d'effectuer une vérification croisée avec un autre noeud d'entrée si la même action est détectée. Mais cette solution a 30 l'inconvénient d'analyser en permanence beaucoup de trafic à la limite du réseau et de fournir une protection des routeurs de réseau et non pas seulement de serveurs définis bien que les attaques DoS sont faites généralement contre des serveurs. Implémenter une telle solution nécessiterait de nouvelles ressources pour analyser tout le trafic plus importantes que celles qui sont nécessaires pour simplement acheminer le trafic, 5 et aurait pour résultat un impact important dû à une analyse permanente et un coût accrû et une complexité du réseau due aux équipements supplémentaires et non indispensables. Exposé de l'invention En conséquence, le but de l'invention est conformément à ce qui vient d'être dit, de fournir un mécanisme dans un système de réseaux qui détecte dans le trafic à partir d'une pluralité de sources une attaque de déni de service et mettre en place des actions appropriées pour éliminer l'attaque sans arrêter 15 l'utilisation normale du réseau et sans impacter la performance du réseau dans des conditions de fonctionnement normales. L'objet de l'invention est donc un système de transmission de données comprenant au moins un réseau de transmission de données, au moins un serveur, une pluralité d'utilisateurs 20 pouvant se connecter audit serveur de façon à obtenir des données, et au moins un utilisateur pouvant initialiser une attaque de déni de service, le système comprenant en outre un gestionnaire de sécurité du réseau et au moins un dispositif de détection pour détecter des conditions de fonctionnement 25 anormales par rapport à un fonctionnement du système défini par des paramètres prédéterminés et transmettre des messages de détection au gestionnaire de sécurité du réseau activant des actions de filtrage à la réception des messages de détection. Selon un autre aspect, l'invention concerne un procédé 30 consistant à détecter au moyen de dispositifs de détection des conditions de fonctionnement anormales d'un réseau de transmission de données, transmettre un message de détection à partir du dispositif de détection ayant détecté les conditions de fonctionnement anormales à un gestionnaire de sécurité du réseau, analyser le message de détection reçu pour déterminer s'il y a une attaque DoS et de quelle source cette attaque provient, et 5 activer par le gestionnaire de sécurité du réseau des actions appliquées aux dispositifs du système qui sont sur le chemin de données entre la source et le dispositif attaqué. Description brève des dessins Les buts, objets et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description qui suit faite en référence aux dessins dans lesquels: * la figure 1 est un bloc-diagramme représentant un premier mode de réalisation d'un système de transmission de données 15 implémentant l'invention, * la figure 2 est un bloc-diagramme représentant un second mode de réalisation d'un système de transmission de données implémentant l'invention, * la figure 3 est un diagramme représentant les différents 20 messages de détection et les actions qui sont échangés entre les dispositifs de détection et le gestionnaire de sécurité du réseau, et * la figure 4 est un organigramme des étapes mises en oeuvre dans le gestionnaire de sécurité du réseau à la réception 25 d'un message de détection provenant d'un dispositif de détection. Description détaillée de l'invention Selon un mode de réalisation préféré décrit en référence à 30 la figure 1, un système de transmission de données dans lequel l'invention peut être mise en oeuvre comprend un réseau de transmission de données public tel qu'Internet 10 et un réseau Intranet 12 reliés au moyen d'un pare-feu 14. Une pluralité d'utilisateurs 16, 18, 20 est connectée au réseau 10 et également un dispositif lançant une attaque DoS sur le système. Le réseau 5 Intranet 12 est relié au moyen d'un routeur 24 à un LAN 26 auquel est connecté un serveur 28 qui peut faire l'objet de requêtes provenant des utilisateurs 16, 18 et 20 de manière pour ceux-ci à obtenir des informations. En supposant que le mécanisme selon l'invention n'est pas 10 utilisé, la première façon de stopper une attaque DoS d'un attaquant 22 est simplement, lorsque l'attaque est détectée, d'arrêter tout trafic relatif au serveur 28 dans le pare-feu 14. Ce dernier peut être équipé pour filtrer des protocoles non essentiels comme le protocole de messages de contrôle Internet 15 (ICMP), mais réduire le protocole de contre de transmission TCP ou de le protocole de paquets d'utilisateur (UDP) peut impacter ou même arrêter le trafic normal. Si une attaque provient d'un ordinateur hôte ou d'un petit nombre d'ordinateurs hôtes, en opposition à l'usurpation au 20 hasard, un dispositif qui traque les adresses sources IP sera capable d'atteindre les attaquants spécifiques et d'arrêter tout le trafic provenant de ces ordinateurs hôtes. Cependant, viser toute adresse source IP est----, exigeant une grande quantité de mémoire. Par conséquent, une solution est de diviser Internet en 25 zones plus petites et plus gérables. Bien que cette façon de faire permette aux dispositifs de déterminer l'origine générale d'une attaque, le blocage de zones d'Internet, en particulier si ce sont de larges zones telles que des segments du type câblemodem ou des proxys America Online, gêne le trafic normal. 30 Cependant, ce peut être encore une forme effective de limitation d'attaque. De plus en plus, des paquets DoS proviennent d'adresses source usurpées et, par conséquent, les paquets ne proviennent pas des adresses IP indiquées dans les paquets. Si, en plus, la valeur de l'adresse est établie au hasard, il n'y a aucune façon de filtrer en se basant sur l'adresse source IP. Une méthode de limitation connue est l'approche par 5 limitation de trafic. Ceci signifie que le service élimine la plupart du trafic, mais laisse passer occasionnellement de petites quantités de trafic pendant une courte période. Ce trafic comprend vraisemblablement du trafic normal et du trafic d'attaque. Dans cette situation, le flux de paquets est réduit à 10 des trames plus petites, empêchant le système d'être surchargé alors qu'il essaie de traiter le trafic normal. Une dernière tactique de limitation connue, développée récemment, consiste à analyser le trafic à l'aide d'un filtrage sélectif. Dans ce cas, le dispositif détermine réellement les 15 caractéristiques du trafic pour trouver une caractéristique commune de manière à distinguer (et ainsi filtrer) le trafic d'attaque. Naturellement, ceci est plus facilement dit que fait et dépend d'une caractéristique commune et unique d'attaque du trafic. Des exemples sont la TTL (durée de vie) statique, le 20 numéro de séquence, le port source ou l'identification IP. Heureusement, beaucoup d'outils d'attaque DoS disponibles produisent un tel phénomène, de sorte que cette approche ne semble être effective que pour le moment. Ce type de méthode est mis en oeuvre dans des dispositifs spécifiques comme des pare-feu 25 qui sont complexes et coûteux mais n'est pas disponible dans des routeurs. Ceci signifie que les capacités de filtrage principales sont situées à la limite du réseau et non dans le réseau Intranet. Les possibilités de combattre des attaques DoS dans le réseau Intranet ou dans le LAN 15 o il y a des serveurs sont 30 très difficiles. Peu de règles peuvent être implémentées dans les routeurs internes tels que le routeur 24. Selon l'invention, un gestionnaire de sécurité du réseau (SNM) 30 est connecté à Intranet 12 et est adapté pour identifier les causes d'un mauvais fonctionnement qui peut être dû à une possible attaque DoS et définir les actions appropriées. Le SNM 5 reçoit en permanence des informations des dispositifs de détection qui sont des pare-feu tels que le pare-feu 14, des routeurs (ou des dispositifs de commutation) comme le routeur 24, des serveurs tels que le serveur 32 et même des stations de travail. Il peut être approprié d'utiliser comme dispositifs de détection, des sondes spécifiques telles que la sonde 32 configurée pour fournir une analyse détaillée du trafic du serveur 28. Dans ce cas, la sonde 32 est configurée pour analyser tous les paquets provenant du serveur 28 mais peut agir comme 15 dispositif proxy pour récolter les évènements du serveur 28. Une telle sonde connectée au LAN 26 peut être une sonde de surveillance de réseau éloignée (RNM) qui est un dispositif de mise sur écoute qui se connecte aux réseaux d'ordinateurs et espionne le trafic du réseau. Elle permet l'analyse du trafic 20 pour le segment de réseau relié. Elle peut fournir l'utilisation de la bande passante, l'identification des principaux utilisateurs, des statistiques de bout en bout, et des informations sur l'activité critique du réseau. Elle peut aussi prélever des paquets et analyser des protocoles et des sous25 protocoles (tous ou choisis), observer le fonctionnement d'un routeur ou d'un serveur web, ou se focaliser sur des dispositifs spécifiques pour une analyse en profondeur. Une telle sonde peut aussi être utilisée pour découvrir les adresses MAC et les surnoms pour les adresses IP et la résolution des noms DNS. Par conséquent, c'est aussi une moyen pour détecter l'usurpation ARP (protocole de résolution d'adresse) ou DNS (serveur de nom de domaine). Une telle sonde est simplement un dispositif passif qui ne modifie pas les paquets. Sa seule actions est d'informer d'autres dispositifs tels que le gestionnaire de sécurité du réseau SNM que quelque chose a été détectée. L'avantage du SNM 30 par rapport à un simple IDS est qu'il effectue la corrélation des événements et des alarmes provenant de plusieurs dispositifs tels que les sondes de sécurité, les pare-feu, les routeurs, les dispositifs de commutation et les serveurs dans un but de sécurité. La connaissance globale de 10 l'attaque permet de définir les règles les plus appropriées dans chaque dispositif de filtrage en réponse à l'attaque sans affecter le trafic normal. Dans un tel environnement, par exemple SNM définira des règles pour le routeur 24 et le pare-feu 14. Une règle pour le routeur 24 pourrait être de re-router tout 15 le trafic du serveur 28 vers un pare-feu connecté au routeur 24. Comme des règles complexes peuvent être appliquées dans un parefeu mais pas dans un routeur, il est effectivement plus efficace de re-router le trafic d'un routeur à un pare-feu pour le trafic douteux que d'appliquer des règles plus sophistiquées dans le 20 routeur lui-même. Le trafic filtré par le pare-feu 34 peut alors être transmis au serveur 28. Des règles similaires peuvent être appliquées dans le pare-feu 14 pour combattre les attaques du réseau 10. Placer un pare-feu à chaque point de la frontière du réseau est la méthode courante qui a l'inconvénient d'impacter la 25 performance et le coût et ne fournit pas d'actions corrélées. Lorsqu'une attaque potentielle est détectée en raison d'un nombre d'accès similaires au serveur 28 qui sont enregistrés par le serveur lui-même ou par la sonde de sécurité 32, les adresses source sont identifiées ou, si possible, le chemin à partir du 30 noeud d'entrée du réseau. Si une adresse source d'entrée est usurpée, le SNM 30 demande à chaque dispositif à la frontière du réseau tel que le pare-feu 14 d'identifier les paquets entrants ayant des caractéristiques communes et dont la destination est le serveur attaqué. Puis, des règles sont appliquées à tous les dispositifs de frontière correspondants pour lesquels des attaques sont détectées par le SNM 30. Les dispositifs qui ne 5 transmettent pas de trafic DoS n'ont pas besoin d'être modifiés dans un tel modèle. Il est aussi possible qu'un serveur connecté au LAN 26 comprenne son propre par-feu tel que le serveur 33. Dans un tel cas, une solution recommandée est de mémoriser et de maintenir 10 la configuration du parefeu associé dans la sonde de sécurité 32 de façon à éviter au serveur 33 de faire l'objet d'une intrusion lorsque la configuration du pare-feu est mise à jour. Dans une telle implémentation la configuration du pare-feu dans la sonde de sécurité est mise à jour par le gestionnaire de sécurité du 15 réseau lorsque c'est nécessaire. Régulièrement, le pare-feu dans le serveur 33 interroge la sonde de sécurité 32 pour déterminer si sa configuration a été modifiée. Dans les sondes locales telles que la sonde 32, seulement un balayage de sécurité est effectué, la plus grande part de 20 l'activité de sécurité étant effectuée dans le SNM 30. L'avantage est d'effectuer le filtrage dans les dispositifs d'entrée seulement quant une attaque DoS est détectée sur les dispositifs du réseau de sorte qu'il n'a pas d'impact sur la performance. Le filtrage est aussi effectué à l'intérieur de l'Intranet dans des 25 routeurs tels que le router 24 et des pare-feu tels que le parefeu 34 de façon à ne pas propager l'attaque dans le réseau Intranet si le DoS garde le contrôle des dispositifs internes tels que les serveurs et les stations de travail. A noter qu'une plate-forme de gestion de réseau (NM) 31 30 connectée au réseau Internet 10 est utilisée comme infrastructure standard des fournisseurs de réseau extérieurs à partir desquels les attaques peuvent provenir. Des messages sont transmis du SNM au NM 31 chaque fois qu'une attaque potentielle a été détectée. Si un dispositif à l'intérieur du réseau est identifié comme étant lourdement chargé, ce qui correspond au début d'une attaque 5 DoS ou DoS distribuée, alors des règles sont appliquées et seulement sur des dispositifs d'entrée à partir desquels du trafic DoS est détecté par des sondes. Ceci permet de prendre des mesures avant le pic effectif de l'attaque DoS et la surcharge du serveur ou du dispositif de réseau. Le fait que des mesures de 10 filtrage importantes sont prises après la détection d'une attaque DoS n'empêche pas d'implémenter des règles de sécurité basiques à la frontière dans des pare-feu tels que le pare-feu 14. Un avantage d'un tel mécanisme distribué est qu'il réagira aussi bien aux attaques DoS inconnues. En plus du filtrage dans un dispositif d'entrée et du filtrage interne, des informations DoS sont fournies par le SNM aux réseaux voisins pour prendre des actions appropriées. Par exemple, le SNM 30 informe la plateforme de gestion de réseau NM 21 quant une attaque DoS est détectée en provenance d'Internet. 20 Ceci permet de propager des mesures aux différents fournisseurs. Des serveurs tels que le serveur 28 peuvent recevoir des recommandations et des règles à appliquer à partir du SNM 30 Pour améliorer leur protection et, du côté opposé, peuvent envoyer des alertes à la sonde de sécurité 32 ou au SNM 30 en se basant sur 25 des alarmes locales et des informations de sécurité. La figure 2 illustre un mode de réalisation o le réseau Intranet 12 est connecté à d'autres réseaux privés tels que NETl 36 et NET2 38 au moyen des routeurs 40 et 42 respectivement. Aucun pare-feu permanent n'est implémenté pour protéger cette 30 interconnexion qui présente normalement moins de risques que le réseau Internet. Dans une attaque distribuée DDoS importante, des ordinateurs hôtes tels que les hôtes 44 et 46 peuvent devenir des stations pirates. Des attaques DoS complexes peuvent ne pas être correctement filtrées par les routeurs 40 et 42 même si elles sont correctement détectées par des sondes de sécurité telles que la sonde 32 ou dans le cas d'un serveur attaqué tel que le serveur 28. Comme il a été fait en référence à la figure 1, le procédé est de reconfigurer dynamiquement les routeurs 40 et 42 pour établir des tunnels qui sont des liaisons logiques point à point à l'aide d'un pare-feu comme le pare-feu 48 qui peuvent être 10 partagés par plusieurs routeurs. Les routeurs re-routent le trafic qui est potentiellement un trafic DoS vers le pare-feu partagé qui prendra des mesures de filtrage. Ce pare-feu peut avoir une connexion directe sur le réseau Intranet pour transmettre le trafic filtré de façon à éviter qu'il soit 15 retourné au routeur d'origine. En plus, il est aussi possible d'établir un tunnel entre le pare-feu 34 et le pare-feu 48 pour le trafic relatif au serveur 28 de façon à isoler ce trafic. Selon l'importance du serveur et son trafic correspondant, 20 il est aussi possible de reclasser une partie ou la totalité du trafic allant vers ou provenant du serveur 28, par exemple utiliser une classe inférieure CoS (Classe de Service) de façon à ne pas impacter le trafic réseau restant même si ce serveur est lourdement chargé. Un rejet au hasard qui est une des mesures 25 appropriées est appliquée à un tel trafic de classe inférieure en cas de congestion. En référence à la figure 3, les dispositifs de détection mettent à jour le SNM 30 régulièrement et/ou en cas d'événement important. Par exemple, la sonde 32 met à jour le SNM 30 au moyen 30 de "LSTAT" fournissant des statistiques du LAN. Si la sonde 32 est configurée pour fournir une analyse détaillée du serveur 28, elle analyse tous les paquets provenant du ou allant au serveur 28 mais peut aussi agir comme un dispositif proxy pour collecter les évènements provenant du serveur 28. Mais des alertes transmises par le serveur 28 doivent être transmises directement au SNM 30 de façon à économiser du temps puisque les sondes sont généralement interrogées par le SNM. Comme déjà mentionné, les routeurs, les pare-feu et les dispositifs de commutation (non montrés) sont aussi des dispositifs de détection et peuvent fournir des statistiques "WSTAT" au SNM ou la détection d'intrusion en utilisant des 10 messages de détection. Le SNM analyse les évènements, calcule le risque, identifie le type d'attaque et d'o elle vient et définit ensuite la nouvelle configuration pour chaque dispositif de protection. Les flux de sortie comprennent des messages de configuration aux routeurs et des dispositifs de commutation et 15 des messages de filtrage pour les pare-feu. En outre, le SNM peut transmettre son analyse de l'attaque à un système gestionnaire de réseau voisin tel NM 31 de manière à ce qu'il prenne des actions additionnelles. La méthode selon l'invention est maintenant décrite en 20 référence à la figure 4. Le SNM attend en permanence un message provenant des dispositifs de détection. Ce peut être un message provenant de la sonde de sécurité, une alerte provenant du serveur 28, un message du réseau tel qu'un message de congestion ou de surcharge sur une interface, un message d'un pare-feu qui a 25 détecté une intrusion. La première étape lorsqu'un message est reçu est d'effectuer l'authentification à l'étape 58. La pire chose serait pour le SNM 30 d'être usurpé et attaqué de sorte qu'il doit être protégé pour accepter seulement des messages d'une adresse IP connue avec le 30 bon protocole. Le SNM est situé dans Intranet sans connexion directe avec Internet, mais ceci n'est pas suffisant. Une authentification plus sérieuse basée sur des certificats est recommandée. Après cette étape préliminaire, soit le message est une alerte ou non. Ceci est vérifié à l'étape 60. Cette information 5 est incluse dans le message lui-même. S'il s'agit seulement d'informations de statistiques sur le réseau ou d'évènements à l'étape 62, les informations contenues dans le message sont ajoutées dans la base de données DB 64 du SNM. Si c'est une alerte, le SNM 66 procède à l'identification du 10 style d'attaque à l'étape 66. Le SNM connaît toutes les attaques classiques et essaie d'identifier à quel type elle appartient. Lorsqu'un serveur vient a être attaqué, il est important de reconnaître le style d'attaque. Quelquefois, c'est une combinaison de plusieurs styles. Quatre type principaux d'attaque 15 sont les plus communs. La première attaque est l'inondation par messages utilisant le protocole de contrôle Internet (ICMP). Un message "ping" sur un serveur engendre une réponse en écho pour confirmer la présence du serveur. Lorsque suffisamment de "pings" sont envoyés, le serveur cible ne fait rien d'autre que de 20 répondre aux requêtes. Le second type est une attaque "smurf". Elle a pour origine la propre adresse IP du serveur cible ou un autre endroit du réseau. Si l'attaque est ciblée correctement, elle peut inonder le réseau avec des pings et des réponses multiples. Le troisième type estl'inondation par "protocole de 25 paquet d'utilisateur" (UDP). Les services de diagnostic UDP génèrent des caractères qui donnent lieu à des réponses en retour de l'extrémité qui reçoit à l'ordinateur hôte. Ceci peut inonder le réseau avec des données inutiles. Le quatrième type concerne l'inondation par messages de protocole de contrôle de 30 transmission (TCP). De multiples requêtes usurpées pour les connexions TCP forcent le serveur à garder les ports ouverts, en attendant des réponses. Ces quatre types d'attaque concernent le trafic entrant. Après cette identification et cette classification de l'attaque, le SNM peut procéder à l'étape 68 à une analyse en 5 profondeur en récupérant des évènements de la base de données 64 de façon à effectuer une corrélation entre les évènements précédents et cette attaque de façon à avoir une vue plus poussée de l'attaque, comme à partir de quels dispositifs dans le réseau Intranet elle a été lancée tels que des routeurs et des pare-feu. 10 Puis, on détermine si l'attaque est bien identifiée à l'étape 70, c'est à dire si toutes les informations collectées sont suffisantes pour comprendre l'attaque, comment la combattre et avec quels dispositifs. Puis, le procédé passe de l'étape 70 à l'étape 72 pour définir les mesures à prendre, ou ce n'est pas 15 assez clair et le SNM a besoin de plus d'informations pour comprendre l'attaque. Dans ce cas, le procédé passe à l'étape 74. Il y a une troisième option qui est en fait une combinaison des deux. Le SNM peut avoir défini des règles pour certains dispositifs mais a besoin d'informations pour améliorer sa 20 connaissance et définir des règles additionnelles. Par conséquent, un premier ensemble d'actions est défini aux étapes 72 à 80. Mais, en parallèle, des mesures et analyses supplémentaires sont requises aux étapes 74 et 82. Le processus d'action commence à l'étape 72 o les mesures 25 sont définies: il comprend, pour les routeurs et les pare-feu, le filtrage jusqu'au rejet, la mise en tunnel, la classification. Puis, les routeurs (et les dispositifs de commutation) sont reconfigurés à l'étape 76, par exemple pour re-router une partie du trafic. Le SNM peut définir une nouvelle configuration mais 30 peut demander à une autre configuration outil de s'appliquer réellement à la configuration du routeur (non montré). De façon similaire, de nouvelles règles sont appliquées aux pare-feu pour le filtrage et aussi pour le balayage des données à l'étape 78 et finalement d'autres entités de gestion de réseau sont observées à l'étape 80. Si plus d'informations sont nécessaires, le SNM définit à 5 l'étape 74 quels dispositifs sont les plus appropriés pour effectuer cette analyse comme les pare-feu à la frontière du réseau ou les sondes de sécurité le plus souvent. Normalement, le SNM n'effectue pas d'analyse pour lui-même, mais seulement pour éviter d'être détecté. Une requête possible est par exemple de vérifier si les adresses source sont valides ou non. Ceci est normalement effectué par les pare-feu en utilisant des pings. Un bon moyen est d'évaluer le TTL trouvé par l'analyse avec le TTL utilisé dans les paquets DoS. Si l'adresse source est réellement dans le 15 réseau à partir duquel le paquet est transmis, alors elle n'a pas été usurpée et le TTL des paquets devrait être très proche du TTL du paquet ping avec un écart possible dû à la valeur par défaut du TTL de départ dans le dispositif transmetteur qui peut avoir certaines valeurs de base. Sinon, l'adresse IP est usurpée. 20 Naturellement si l'adresse IP ne correspond a aucun type de ping (ICMP, UDP, TCP), il y a une forte probabilité que l'adresse source soit usurpée. La réception des paquets avec une adresse source usurpée signifie que c'est certainement une attaque DoS et des mesures importantes doivent être prises en utilisant d'autres 25 paramètres trouvés dans les paquets pour les identifier. Bien que l'invention a été décrite selon un mode de réalisation préféré, d'autres modes de réalisation et modifications peuvent être mis en oeuvre par l'homme du métier sans sortir du cadre de l'invention. REVEYNDICATIONS 1. Système de transmission de données comprenant au moins un réseau de transmission de données (10, 12), au moins un serveur (28), une pluralité d'utilisateurs (16, 18, 20) pouvant se connecter audit serveur de façon à obtenir des données, et au moins un utilisateur (22) pouvant initialiser une attaque de déni de service, ledit système comprenant en outre un gestionnaire de sécurité du réseau (30) et au moins un dispositif de détection pour détecter des conditions de fonctionnement anormales par rapport à un fonctionnement du système défini par des paramètres prédéterminés et transmettre des messages de détection audit gestionnaire de sécurité du réseau activant des actions de filtrage à la réception desdits messages de détection. 2. Système de transmission de données selon la revendication 1, comprenant le réseau Internet (10) auquel sont connectés lesdits utilisateurs (16, 18, 20) et au moins un premier réseau privé (12) auquel est connecté ledit gestionnaire de sécurité du réseau (30), et un réseau local (26) auquel est connecté ledit serveur (28). 3. Système de transmission de données selon la revendication 2, dans lequel ledit réseau Internet (10) et ledit premier réseau privé (12) sont interconnectés par un pare-feu (14), et ledit premier réseau privé et ledit réseau local(26) sont interconnectés par un routeur (24) ; ledit serveur (28), ledit pare-feu et ledit routeur étant des dispositifs de détection transmettant des messages de détection audit gestionnaire de sécurité du réseau (30) lorsqu'ils détectent des conditions de fonctionnement anormales. 4. Système de transmission de données selon la revendication 3, comprenant en outre une sonde de sécurité (32) connectée audit réseau local (26), ladite sonde de sécurité étant utilisée comme dispositif de détection pour analyser le trafic transporté dans ledit réseau local et fournir des statistiques audit gestionnaire de sécurité du réseau (30). 5. Système de transmission de données selon la revendication 4, dans lequel ledit serveur (33) connecté audit réseau local (26) comprend son propre pare-feu, la configuration dudit pare-feu étant dans ladite sonde de sécurité (32) et étant mis à jour par ledit gestionnaire de sécurité du réseau (30). 6. Système de transmission de données selon la revendication 5, comprenant en outre un second réseau privé (36, 38) connecté audit premier réseau privé (12) au moyen d'un routeur (40, 42), tout le trafic transporté entre ledit premier réseau privé et ledit second réseau privé étant rerouté vers un pare-feu spécifique connecté audit premier réseau privé. 7. Procédé pour protéger un système de transmission de données contre une attaque de déni de service, ledit système de transmission de données comprenant au moins un réseau de transmission de données (10, 12), au moins un serveur (28), une pluralité d'utilisateurs (16, 18, 20) pouvant se connecter audit serveur de façon à obtenir des données, et au moins un utilisateur (22) pouvant initialiser une attaque de déni de service, ledit procédé comprenant les étapes de -détecter au moyen de dispositifs de détection des conditions de fonctionnement anormales dudit système de transmission de données, -transmettre un message de détection à partir dudit dispositif de détection ayant détecté lesdites conditions de fonctionnement anormales à un gestionnaire de sécurité du réseau (30). -analyser le message de détection reçu pour déterminer s'il y a une attaque DoS et de quelle source cette attaque provient, et -activer par ledit gestionnaire de sécurité du réseau lesdites actions appliquées aux dispositifs du système qui sont sur le chemin de données entre ladite source et le dispositif attaqué. 8. Procédé selon la revendication 7, dans lequel ledit message de détection est un message d'alerte lorsque ledit dispositif de détection est un serveur. 9. Procédé selon la revendication 7, dans lequel ledit message de détection est un message de statistiques (LStat) lorsque ledit dispositif de détection est une sonde de sécurité. 10. Procédé selon la revendication 7, dans lequel ledit message de détection est un message de statistiques (WStat) lorsque ledit dispositif de détection est un routeur. 11. Procédé selon la revendication 8, comprenant en outre l'étape d'identification du type d'attaque lorsque ledit message de détection est un message d'alerte, de manière à ce que ledit gestionnaire de sécurité du réseau puisse activer des actions appropriées. 21 2852754 12. Procédé selon la revendication il, dans lequel lesdites actions appropriées consistent à re-configurer les routeurs dudit réseau de transmission de données. 13. Procédé selon la revendication 11, dans lequel lesdites actions appropriées consistent à transmettre de nouvelles règles de filtrage aux pare-feu dudit système de transmission de données. 14. Procédé selon la revendication 9 or 10, dans lequel les informations contenues dans ledit message de statistiques est mémorisées dans une bas de données dudit gestionnaire de sécurité du réseau.