EP1766934A1 - Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service. - Google Patents

Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service.

Info

Publication number
EP1766934A1
EP1766934A1 EP05788506A EP05788506A EP1766934A1 EP 1766934 A1 EP1766934 A1 EP 1766934A1 EP 05788506 A EP05788506 A EP 05788506A EP 05788506 A EP05788506 A EP 05788506A EP 1766934 A1 EP1766934 A1 EP 1766934A1
Authority
EP
European Patent Office
Prior art keywords
server
client
service
intermediate equipment
agreement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05788506A
Other languages
German (de)
English (en)
Inventor
Yannick Carlinet
Yvon Gourhant
Patrick Trabe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1766934A1 publication Critical patent/EP1766934A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service

Definitions

  • a method, computer program, device and system for protecting a server against denial of service attacks is a method, computer program, device and system for protecting a server against denial of service attacks.
  • the invention relates to such a method in which, during recovery of a communication session between a client and the server, recovery of this session being required by the customer for the provision of a service, at least a part following data is exchanged:
  • the server receives a service provision request sent by the client; the server returns a service provision agreement to the client;
  • the server In a predetermined time by the server, it waits for an acknowledgment of receipt of the agreement, from the customer.
  • the server is able to handle multiple service provision requests.
  • it includes a buffer memory in which it stores the requests it receives, pending the corresponding acknowledgments that must reach it before the expiration of the predetermined time. This time runs from the sending of the service provisioning agreement by the server.
  • the buffer has a predetermined size and can therefore store a predetermined maximum number of service provision requests.
  • a malicious user can synchronously transmit a large number of denial of service attacks to the server, from one or more client terminals called “zombies", so as to quickly fill the server buffer .
  • the server is then no longer able to receive new requests for service provision, for example from other well-intentioned users, and can no longer fulfill its function of providing service.
  • a first preventative type solution to protect a server against such attacks is to increase the size of its buffer or reduce the delay predetermined by the server during which it waits for the acknowledgment to be issued by the client.
  • Another reactive solution to protect a server against such attacks is to divert all data addressed to the attacked server to another server generally called "black hole", as soon as attacks to this server are detected, so that it is the black hole that receives all attacks rather than the server itself.
  • black hole The function of the black hole is to receive the data and destroy it without processing it.
  • this solution does not allow to treat differently the malicious attacks and the real requests of service provision emitted by legitimate customers.
  • this solution when this solution is applied, it can be considered that the attack has worked since the attacked server is no longer able to provide the service.
  • the invention aims to improve existing methods of protecting a server against denial of service attacks by providing a method capable of protecting a server against such attacks at least as efficiently as in the US document 2004/0015721, without requiring the management of two communication sessions.
  • the invention therefore relates to a method of protecting a server against denial of service attacks using a protocol according to which an establishment of a communication session between a client and the server is required by the client for the provision of services.
  • a service comprising the following steps: a) interception of a service provision request issued by a client and intended for the server, the request not being transmitted to the server; b) verification if the client is present in a table of customers deemed reliable; c) if the client is present in the table, transmission of the request to the server; d) if the customer is absent from the table, implement the following steps: e) sending a service provision agreement to the customer; f) upon receipt of an acknowledgment of the agreement from the customer under predetermined conditions, entry of the customer in the table and sending to the customer a signal informing him that the establishment of the communication session failed.
  • the intermediate equipment maintains a table with a list of customers deemed reliable.
  • the intermediate equipment does not interrupt the establishment of a session required by this customer.
  • the customer is not registered in the table, that is to say if it is not considered reliable by the intermediate equipment, the establishment of the session is automatically interrupted.
  • the predetermined conditions are that the acknowledgment is received within a predetermined time after sending the service provision agreement.
  • the client is entered in the table by the intermediate equipment for example if, during a previous session establishment, the customer has returned a service delivery agreement acknowledgment of receipt issued by the customer.
  • intermediate equipment within the predetermined time by the server.
  • each first attempt to establish a communication session by a client with the server fails due to the intermediate equipment has not yet registered this client in the table.
  • this first session setup attempt is a test run by the staging equipment to verify that the client is sending an acknowledgment within the time required by the server. If the customer returns the acknowledgment in time, he is then considered to be a reliable customer and is entered in the table by the intermediate equipment.
  • the criterion predetermined by the intermediate equipment is a waiting time of the acknowledgment of the agreement weaker than that predetermined by the server.
  • This embodiment is particularly interesting when service provisioning requests are issued by clients whose access to the server is made via a high-speed network, that is to say in time of delay weaker than the Internet. Indeed, in this case, the delay to return an acknowledgment of receipt of the agreement may be lower. The fact that this lower delay is imposed by the intermediate equipment and not by the server allows the latter to receive any other requests for service provision from other customers with access to lower data rates. .
  • the predetermined conditions are that the acknowledgment contains a value equal to a unique key previously introduced in the service provisioning agreement.
  • the unique key is customer-specific and is calculated a first time at the time of sending the service provisioning agreement and a second time at the time of receipt of the acknowledgment.
  • This embodiment is particularly advantageous since it is not necessary for the intermediate equipment to keep in its buffer memory, for a predetermined duration, service supply requests, while waiting. corresponding acknowledgments. Indeed, in this embodiment, the intermediate equipment sends to the customers who have issued a request for service provision, a service provision agreement without storing the original request. It is only when he receives an acknowledgment of a service provision agreement that he compares the value contained in this acknowledgment with a key that he calculates. Thus, this intermediate server is much less vulnerable to denial of service attacks since its processing capacity is not limited by its buffer memory.
  • the invention also relates to a device for protecting a server against denial of service attacks using a protocol in which an establishment of a communication session between a client and the server is required by the client for the provision of services.
  • a service the device comprising means for implementing steps b) to f) previously defined.
  • the means for implementing steps b) to f) comprise a computer program according to the invention.
  • the invention also relates to a system for protecting a server against denial of service attacks using a protocol in which an establishment of a communication session between a client and the server is required by the client for the providing a service, the system comprising a server adapted for providing a service that may be required by a customer, characterized in that the system comprises an intermediate device formed by a protection device as defined above.
  • a protection system of a server according to the invention may further include the feature that the intermediate equipment is a firewall disposed between the server and a client access network to the server.
  • FIG. 1 shows schematically the general structure of an installation comprising a system according to a possible embodiment of the invention
  • FIG. 2 represents the successive steps of a method for protecting a server according to a first embodiment of the invention
  • FIG. 3 represents the successive steps of a method according to a second embodiment of the invention.
  • FIG. 4 represents the successive steps of a method according to a third embodiment of the invention.
  • the installation represented in FIG. 1 comprises a first server 10 adapted for the provision of a predetermined service to different clients.
  • the server 10 is connected to a high-speed network 12, for example an ADSL link which is itself connected to an operator network 14.
  • Intermediate equipment 16 can be arranged at the interface of the operator network 14 and the network This intermediate equipment 16 is for example a firewall.
  • the installation comprises a second server 18 also adapted for providing a predetermined service to different customers.
  • This server 18 is connected to a private local area network 20, itself connected to the operator network 14.
  • An intermediate equipment 22, as well as a router 24, can be arranged at the interface of the operator network 14 and the high-speed network 12.
  • the intermediate equipment 22 is for example a firewall, as the intermediate equipment 16.
  • the installation represented in FIG. 1 further comprises a first client terminal 26 capable of requiring the provision of a service on the part of the server 10 or the server 18.
  • This client terminal 26 is connected to a high-speed network 28, for example identical to the high-speed network 12, that is to say an ADSL link.
  • This high-speed network 28 is itself connected to the operator network 14 via intermediate equipment 30, such as a firewall.
  • the installation includes a second client terminal 32, also likely to require the provision of a service from the server 10 or the server 18. It is connected to a packet data transmission network 34, such as than the Internet.
  • the Internet network 34 is itself connected to the operator network 14 via a router 36 directly connected to a control platform 38 and an intermediate equipment 40.
  • the intermediate equipment 40 is for example a firewall, as the intermediate equipment 16, 22 and 30.
  • the set of intermediate equipment 16, 22, 30 and 40 is managed by a conventional system 42 under the control of the operator of the network 14.
  • the server 10 comprises means for establishing a communication session with remote terminals.
  • the server 10 comprises means 43 for receiving a service provision request issued by any client. It further comprises means 44 for issuing a service provision agreement to the customer who transmitted the request. Finally, it comprises means 45 for triggering a predetermined delay waiting for an acknowledgment of the agreement it has issued, this acknowledgment must be from the client who transmitted the request.
  • the server 18 also includes the same means 43, 44 and 45 as the server 10.
  • the intermediate equipment 16, 22, 30 and 40 include means 46 for interrupting the establishment of a session. required by a client, if a predetermined criterion by these intermediate equipment is verified during the data exchange necessary for the establishment of the session.
  • the criterion predetermined by an intermediate device is a waiting time for an acknowledgment lower than that predetermined by the server 10 or 18.
  • the intermediate equipment concerned comprises means 47 for triggering this weak delay.
  • the waiting time implemented on a server such as the server 10 or 18 is of the order of a few tens of seconds, while the low delay of an intermediate device can be set to only 3 seconds.
  • This criterion can be implemented on each intermediate equipment 16, 22, 30 and 40.
  • the terminal 32 returns an acknowledgment of the agreement it has received.
  • the terminal 32 includes in its acknowledgment the sequence number of the service provision agreement. However, this sequence number corresponds to the value equal to the unique key.
  • this acknowledgment is redirected to the intermediate equipment 40 by the router 36 under the control of the control platform 38.
  • the intermediate equipment 40 On receipt of this acknowledgment, the intermediate equipment 40 extracts the IP address of the client terminal 32 and the value it contains.
  • the intermediate equipment 40 calculates a key from the IP address it has extracted from the acknowledgment, and then compares the extracted value with the newly calculated key. If these two keys are identical, the intermediate equipment considers that the client terminal 32 is reliable and can then trigger the registration of the client terminal 32 in the updated table. This registration of the client terminal 32 in the table of the intermediate equipment 40 attests that this client terminal 32 has issued a service provision request that was not a denial of service attack.
  • the intermediate equipment can test the reliability of a client terminal 32 that has issued a request for service provision without having to temporarily fill its buffer.
  • the intermediate equipment 40 sends to the client terminal 32 a signal informing the client terminal 32 that the connection has failed.
  • the client terminal 32 issues a second service provision request to the server 10.
  • this request will be transmitted to the server 10 which will accept the establishment of the session.
  • the following steps are identical to those described in the second embodiment.
  • the server 10 is protected by the intermediate equipment since it is not requested at all for a denial of service attack.
  • this intermediate equipment can not also be the victim of a denial of service attack since it does not keep the requests for service provision in memory.
  • the method of not storing service provisioning requests may further be implemented directly on the server. Indeed, the server is no longer likely to see its buffer quickly filled and is thus protected against denial of service attacks. In this case, by exception to the general definition of the invention, the request is actually transmitted to the server but the latter only takes it into account from the step of transmitting the request to the server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne notamment un procédé de protection d'un serveur (10) contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client (26) et le serveur (10) est requis par le client pour la fourniture d'un service. Un équipement intermédiaire (30) intercepte la requête de service émise par le client (26) et vérifie si le client (10) est présent dans le tableau de clients jugés fiables. Si le client (10) n'est pas présent dans le tableau, l'équipement intermédiaire (30) répond à la requête et inclut dans la réponse un identifiant. Si le client (10) envoie un accusé de réception dans un délai prédéterminé incluant l'identificateur, le client (10) est inclus dans le tableau de clients jugés fiables.

Description

Procédé, programme d'ordinateur, dispositif et système de protection d'un serveur contre des attaques de déni de service.
La présente invention concerne un procédé, un programme d'ordinateur, un dispositif et un système de protection d'un serveur contre des attaques de déni de service.
Plus précisément, l'invention concerne un tel procédé dans lequel, lors de rétablissement d'une session de communication entre un client et le serveur, rétablissement de cette session étant requis par le client pour la fourniture d'un service, au moins une partie des données suivantes est échangée :
- le serveur reçoit une requête de fourniture de service émise par le client ; le serveur renvoie un accord de fourniture de service au client ;
- dans un délai prédéterminé par le serveur, celui-ci attend un accusé de réception de l'accord, en provenance du client. En général, le serveur est capable de gérer plusieurs requêtes de fourniture de service. Pour cela, il comporte une mémoire tampon dans laquelle il stocke les requêtes qu'il reçoit, dans l'attente des accusés de réception correspondants qui doivent lui parvenir avant l'expiration du délai prédéterminé. Ce délai court à partir de l'envoi de l'accord de fourniture de service par le serveur. La mémoire tampon a une taille prédéterminée et peut donc stocker un nombre maximal prédéterminé de requêtes de fourniture de service.
Une attaque de déni de service consiste à utiliser le protocole d'établissement d'une session de communication avec le serveur, tel qu'il a été décrit précédemment, pour :
- transmettre une requête de fourniture de service à destination du serveur que l'on souhaite attaquer ;
- recevoir l'accord de fourniture de service de la part du serveur ; et
- ne pas renvoyer l'accusé de réception attendu par le serveur.
Ainsi, un utilisateur mal intentionné peut émettre de façon synchronisée un grand nombre d'attaques de déni de service à destination du serveur, à partir d'un ou plusieurs terminaux clients appelés "zombies", de manière à remplir rapidement la mémoire tampon du serveur. Le serveur n'est alors plus capable de recevoir de nouvelles requêtes de fourniture de service, par exemple de la part d'autres utilisateurs bien intentionnés, et ne peut plus remplir sa fonction de fourniture de service.
Une première solution de type préventif pour protéger un serveur contre de telles attaques consiste à augmenter la taille de sa mémoire tampon ou à réduire le délai prédéterminé par le serveur pendant lequel celui-ci attend l'accusé de réception devant être émis par le client.
L'augmentation de la taille de la mémoire tampon n'est pas une solution satisfaisante puisque la taille de cette mémoire tampon est elle-même limitée par la mémoire globalement disponible sur le serveur. De même, le fait de réduire le délai prédéterminé d'attente de l'accusé de réception n'est pas satisfaisant puisque cela est susceptible de nuire à des utilisateurs, pourtant bien intentionnés et désireux de requérir réellement un service auprès du serveur, mais ne disposant pas d'une connexion à débit suffisant pour pouvoir renvoyer au serveur un accusé de réception dans un délai trop court.
Une autre solution de type réactif pour protéger un serveur contre de telles attaques consiste à dévier toutes les données adressées au serveur attaqué vers un autre serveur généralement appelé "trou noir", dès que des attaques vers ce serveur sont détectées, de manière que ce soit le trou noir qui reçoive toutes les attaques plutôt que le serveur lui- même. La fonction du trou noir est de recevoir les données et de les détruire sans les traiter.
Cependant, cette solution ne permet pas de traiter différemment les attaques malveillantes et les réelles requêtes de fourniture de service émises par des clients légitimes. De plus, lorsque cette solution est appliquée, on peut considérer que l'attaque a fonctionné puisque le serveur attaqué n'est plus capable de fournir le service.
Une autre solution est décrite dans le document US 2004/0015721 et consiste à utiliser un équipement intermédiaire disposé entre le client et le serveur. Cet équipement intermédiaire a pour fonction de se comporter comme le serveur vis-à-vis du client et comme le client vis-à-vis du serveur. De la sorte, le client établit en fait une première session de communication avec l'équipement intermédiaire, puis l'équipement intermédiaire établit une seconde session de communication avec le serveur si la première session est correctement établie.
L'effet de cette solution est que c'est, non plus le serveur, mais l'équipement intermédiaire, qui reçoit les attaques de la part d'un client malveillant, mais que l'on doit en contrepartie gérer deux sessions de communication, l'une entre le client et l'équipement intermédiaire, l'autre entre l'équipement intermédiaire et le serveur, au lieu d'une seule session de communication entre le client et le serveur.
L'invention vise à améliorer les procédés existants de protection d'un serveur contre des attaques de déni de service en fournissant un procédé capable de protéger un serveur contre de telles attaques au moins aussi efficacement que dans le document US 2004/0015721, sans pour autant nécessiter la gestion de deux sessions de communication.
L'invention a donc pour objet un procédé de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client et le serveur est requis par le client pour la fourniture d'un service, ce procédé comprenant les étapes suivantes : a) interception d'une requête de fourniture de service émise par un client et destinée au serveur, la requête n'étant pas transmise au serveur ; b) vérification si le client est présent dans un tableau de clients jugés fiables ; c) si le client est présent dans le tableau, transmission de la requête au serveur ; d) si le client est absent du tableau, mise en œuvre des étapes suivantes : e) envoi d'un accord de fourniture de service au client ; f) en cas de réception d'un accusé de réception de l'accord provenant du client dans des conditions prédéterminées, inscription du client dans le tableau et envoi au client d'un signal l'informant que l'établissement de la session de communication a échoué.
Les étapes b) à f) de ce procédé sont par exemple mise en oeuvre par un équipement intermédiaire.
Dans ce cas, l'équipement intermédiaire tient à jour un tableau comportant une liste de clients jugés fiables. Lorsqu'un client est inscrit dans le tableau, l'équipement intermédiaire n'interrompt pas l'établissement d'une session requis par ce client. En revanche, si le client n'est pas inscrit dans le tableau, c'est-à-dire s'il n'est pas jugé fiable par l'équipement intermédiaire, l'établissement de la session est automatiquement interrompu.
Ainsi, on ne gère qu'une seule session de communication à établir entre le client et le serveur, l'équipement intermédiaire n'intervenant que pour éventuellement interrompre rétablissement de cette session requis par le client. On notera que lorsque les conditions prédéterminées par l'équipement intermédiaire sont vérifiées, l'établissement de la session est interrompu par l'équipement intermédiaire, et non pas dévié vers un autre terminal. Les attaques de déni de service sont donc sans effet sur le serveur ni sur aucun autre terminal.
Selon un mode de réalisation particulier de l'invention, les conditions prédéterminées consistent en ce que l'accusé de réception est reçu dans un délai prédéterminé après l'envoi de l'accord de fourniture de service. -A-
Dans ce mode de réalisation, le client est inscrit dans le tableau par l'équipement intermédiaire par exemple si, lors d'un établissement de session précédent, le client a renvoyé un accusé de réception d'accord de fourniture de service émis par l'équipement intermédiaire dans le délai prédéterminé par le serveur. Dans ce cas, chaque première tentative d'établissement d'une session de communication par un client avec le serveur échoue du fait de l'équipement intermédiaire n'a pas encore inscrit ce client dans le tableau. En fait, cette première tentative d'établissement de session est un test géré par l'équipement intermédiaire pour vérifier que le client envoie bien un accusé de réception dans le délai requis par le serveur. Si le client renvoie à temps l'accusé de réception, il est alors considéré comme étant un client fiable et est inscrit dans le tableau par l'équipement intermédiaire. Le fait que le client renvoie à temps l'accusé de réception prouve que le client n'utilise pas une adresse IP usurpée (technique couramment employée dans une attaque). Ainsi, lors d'une seconde tentative d'établissement d'une session de communication par ce client avec le serveur, l'équipement intermédiaire n'interrompra pas cet établissement de session, conformément à l'invention.
De préférence, le critère prédéterminé par l'équipement intermédiaire est un délai d'attente de l'accusé de réception de l'accord plus faible que celui prédéterminé par le serveur. Ce mode de réalisation est particulièrement intéressant lorsque les requêtes de fourniture de service sont émises par des clients dont l'accès au serveur est réalisé par l'intermédiaire d'un réseau à haut débit, c'est-à-dire à temps de délai plus faible que le réseau Internet. En effet, dans ce cas, le délai pour renvoyer un accusé de réception de l'accord peut être plus faible. Le fait que ce délai plus faible soit imposé par l'équipement intermédiaire et non pas par le serveur permet à ce dernier de recevoir quand même d'autres requêtes de fourniture de service de la part d'autres clients ayant accès à des débits moins élevés.
Selon un autre mode de réalisation de l'invention, les conditions prédéterminées consistent en ce que l'accusé de réception contient une valeur égale à une clé unique préalablement introduite dans l'accord de fourniture de service.
De préférence, la clé unique est fonction du client et est calculée une première fois au moment de l'envoi de l'accord de fourniture de service et une seconde fois au moment de la réception de l'accusé de réception.
Ce mode de réalisation est particulièrement avantageux puisqu'il n'est pas nécessaire pour l'équipement intermédiaire de conserver dans sa mémoire tampon, pendant une durée prédéterminée, les requêtes de fourniture de service, dans l'attente des accusés de réception correspondants. En effet, dans ce mode de réalisation, l'équipement intermédiaire envoie aux clients qui ont émis une requête de fourniture de service, un accord de fourniture de service sans conserver en mémoire la requête initiale. C'est uniquement lorsqu'il reçoit un accusé de réception d'un accord de fourniture de service qu'il compare la valeur contenue dans cet accusé de réception avec une clé qu'il calcule. Ainsi, ce serveur intermédiaire est bien moins vulnérable à des attaques de déni de service puisque sa capacité de traitement n'est pas limitée par sa mémoire tampon.
Grâce à ces équipements intermédiaires, le serveur distant est moins sollicité puisque la charge de calcul nécessaire à la vérification de la fiabilité des clients est répartie sur différents équipements intermédiaires. En outre, ces équipements intermédiaires sont de préférence situés à proximité des clients de sorte que le réseau reliant le serveur distant aux équipements intermédiaires n'est pas encombré par les différents messages émis lors d'une attaque de déni de service.
L'invention a également pour objet un programme d'ordinateur de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client et le serveur est requis par le client pour la fourniture d'un service, le programme contenant des instructions pour la mise en œuvre des étapes b) à f) précédemment définies.
L'invention a également pour objet un dispositif de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client et le serveur est requis par le client pour la fourniture d'un service, le dispositif comprenant des moyens pour la mise en oeuvre des étapes b) à f) précédemment définies.
De manière optionnelle, les moyens pour la mise en oeuvre des étapes b) à f) comprennent un programme d'ordinateur selon l'invention.
Enfin, l'invention a également pour objet un système de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client et le serveur est requis par le client pour la fourniture d'un service, le système comportant un serveur adapté pour la fourniture d'un service susceptible d'être requis par un client, caractérisé en ce que le système comporte un équipement intermédiaire formé par un dispositif de protection tel que défini précédemment.
Un système de protection d'un serveur selon l'invention peut en outre comporter la caractéristique selon laquelle l'équipement intermédiaire est un pare-feu disposé entre le serveur et un réseau d'accès du client au serveur. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels :
- la figure 1 représente schématiquement la structure générale d'une installation comportant un système selon un mode de réalisation possible de l'invention ; - la figure 2 représente les étapes successives d'un procédé de protection d'un serveur selon un premier mode de réalisation de l'invention ;
- la figure 3 représente les étapes successives d'un procédé selon un second mode de réalisation de l'invention ;
- la figure 4 représente les étapes successives d'un procédé selon un troisième mode de réalisation de l'invention.
L'installation représentée sur la figure 1 comporte un premier serveur 10 adapté pour la fourniture d'un service prédéterminé auprès de différents clients.
Le serveur 10 est connecté à un réseau à haut débit 12, par exemple une liaison ADSL elle même connectée à un réseau d'opérateur 14. Un équipement intermédiaire 16 peut être disposé à l'interface du réseau d'opérateur 14 et du réseau à haut débit 12. Cet équipement intermédiaire 16 est par exemple un pare-feu.
L'installation comporte un deuxième serveur 18 également adapté pour la fourniture d'un service prédéterminé auprès de différents clients.
Ce serveur 18 est connecté à un réseau local privé 20, lui-même relié au réseau d'opérateur 14. Un équipement intermédiaire 22, ainsi qu'un routeur 24, peuvent être disposés à l'interface du réseau d'opérateur 14 et du réseau à haut débit 12. L'équipement intermédiaire 22 est par exemple un pare-feu, comme l'équipement intermédiaire 16.
L'installation représentée sur la figure 1 comporte en outre un premier terminal client 26 susceptible de requérir la fourniture d'un service de la part du serveur 10 ou du serveur 18. Ce terminal client 26 est connecté à un réseau à haut débit 28, par exemple identique au réseau à haut débit 12, c'est-à-dire une liaison ADSL. Ce réseau à haut débit 28 est lui-même connecté au réseau d'opérateur 14 via un équipement intermédiaire 30, tel qu'un pare-feu. Enfin, l'installation comporte une second terminal client 32, lui aussi susceptible de requérir la fourniture d'un service de la part du serveur 10 ou du serveur 18. Il est connecté à un réseau 34 de transmission de données en mode paquets, tel que le réseau Internet. Le réseau Internet 34 est lui-même connecté au réseau d'opérateur 14 par l'intermédiaire d'un routeur 36 directement relié à une plate-forme de commande 38 et à un équipement intermédiaire 40. L'équipement intermédiaire 40 est par exemple un pare- feu, comme les équipements intermédiaires 16, 22 et 30. -T-
L'ensemble des équipements intermédiaires 16, 22, 30 et 40 est géré par un système 42 classique sous le contrôle de l'opérateur du réseau 14.
Pour permettre la fourniture d'un service à des terminaux clients demandeurs, tels que les terminaux 26 et 32, le serveur 10 comporte des moyens permettant l'établissement d'une session de communication avec des terminaux distants.
Plus précisément, le serveur 10 comporte des moyens 43 de réception d'une requête de fourniture de service émise par un client quelconque. Il comporte en outre des moyens 44 d'émission d'un accord de fourniture de service au client qui lui a transmis la requête. Enfin, il comporte des moyens 45 de déclenchement d'un délai prédéterminé d'attente d'un accusé de réception de l'accord qu'il a émis, cet accusé de réception devant provenir du client qui lui a transmis la requête. Le serveur 18 comporte lui aussi les mêmes moyens 43, 44 et 45 que le serveur 10.
Pour permettre la protection des serveurs 10 et 18 contre des attaques de déni de service pouvant provenir des terminaux clients 26 et 32, les équipements intermédiaires 16, 22, 30 et 40 comportent des moyens 46 d'interruption de l'établissement d'une session requis par un client, si un critère prédéterminé par ces équipements intermédiaires est vérifié lors de l'échange de données nécessaire à l'établissement de la session.
Par exemple, le critère prédéterminé par un équipement intermédiaire est un délai d'attente d'un accusé de réception plus faible que celui prédéterminé par le serveur 10 ou 18. Pour ce faire, l'équipement intermédiaire concerné comporte des moyens 47 de déclenchement de ce faible délai.
En général, le délai d'attente implémenté sur un serveur tel que le serveur 10 ou 18 est de l'ordre de quelques dizaines de secondes, alors que l'on peut régler le faible délai d'un équipement intermédiaire à seulement 3 secondes.
Ce critère de faible délai est avantageusement implémenté sur des équipements intermédiaires situés à l'interface de réseaux à temps de délai faible ou peu chargés car il imposent un temps de réponse plus court de la part d'un client. En revanche un équipement intermédiaire situé à l'interface de deux réseaux dont au moins un est à un débit comparable au réseau Internet ne devrait pas appliquer ce critère pour interrompre des établissements de session.
C'est pour cette raison que dans le mode de réalisation représenté sur la figure 1 , chacun des équipements intermédiaires 16, 22, et 30 comporte des moyens 47 de déclenchement d'un faible délai, mais pas l'équipement intermédiaire 40. Le critère prédéterminé par un équipement intermédiaire peut aussi être l'absence d'un client d'un tableau tenu à jour par cet équipement intermédiaire lorsque celui-ci intercepte une requête de fourniture de service de la part de ce client. Dans ce cas, un tel tableau est stocké dans des moyens de stockage 48 qui sont régulièrement mis à jour par l'équipement intermédiaire concerné.
Ce critère peut être implémenté sur chaque équipement intermédiaire 16, 22, 30 et 40.
Dans un mode de réalisation préféré qui sera décrit plus précisément en référence à la figure 3, le client est inscrit dans le tableau par l'équipement intermédiaire si, lors d'un établissement de session précédent, le client a renvoyé un accusé de réception d'accord de fourniture de service émis par l'équipement intermédiaire dans le délai prédéterminé par le serveur dont le client à requis la fourniture d'un service.
Un premier mode de réalisation d'un procédé de protection du serveur 10 ou 18 selon l'invention va maintenant être décrit en référence à la figure 2, dans le cadre d'un échange de données entre le client 26 et le serveur 10. Ce procédé est avantageusement mis en œuvre par l'équipement intermédiaire 30 situé à l'interface du réseau d'opérateur 14 et du réseau à haut débit 28.
Conformément à ce procédé, lors d'une première étape 50, le terminal client 26 transmet, via le réseau à haut débit 28, une requête de fourniture de service destinée au serveur 10. Cette requête est interceptée par l'équipement intermédiaire 30 puis traverse le réseau d'opérateur 14 et le réseau à haut débit 12, pour parvenir au serveur 10 lors d'une étape 52.
Lors de l'étape 54 suivante, le serveur 10 renvoie un accord de fourniture de service à destination du terminal client 26. L'émission de cet accord active les moyens 45 de déclenchement du délai prédéterminé par le serveur 10, lors d'une étape 56. L'accord de fourniture de service émis par le serveur 10 est intercepté par l'équipement intermédiaire 30, ce qui déclenche l'activation des moyens 47 de déclenchement du faible délai prédéterminé par l'équipement intermédiaire, lors d'une étape 58. Une fois ce délai d'attente plus faible déclenché par l'équipement intermédiaire 30, l'accord de fourniture de service parvient au terminal client 26, via le réseau à haut débit 28, lors d'une étape 60.
Si à l'expiration du faible délai déclenché par l'équipement intermédiaire 30, celui-ci n'a toujours pas reçu un accusé de réception devant être émis par le terminal client 26, l'équipement intermédiaire 30 interrompt l'établissement de la session requise par le terminal client 26, lors d'une étape 62 au cours de laquelle il transmet au serveur 10 un signal l'informant de cette interruption. Ainsi, le serveur 10, qui avait stocké la requête de fourniture de service du terminal client 26 dans sa mémoire tampon, peut libérer celle-ci avant l'expiration de son propre délai d'attente. Les attaques de déni de service éventuellement émises depuis le terminal 26 sont donc neutralisées par l'équipement intermédiaire 30, sans affecter le serveur 10, qui peut recevoir d'autres requêtes de fourniture de service, de la part d'autres terminaux clients.
Bien sûr, si suite à l'étape 60, lors de laquelle le terminal client 26 reçoit l'accord de fourniture de service, celui-ci renvoie un accusé de réception au serveur 10 avant l'expiration du faible délai imposé par l'équipement intermédiaire 30, l'établissement de la session de communication requis par le terminal client 26 n'est pas interrompu.
Un deuxième mode de réalisation d'un procédé de protection du serveur 10 ou 18 selon l'invention va maintenant être décrit en référence à la figure 3, dans le cadre d'un échange de données entre le client 32 et le serveur 10. Ce procédé est avantageusement mis en œuvre par l'équipement intermédiaire 40 situé à l'interface du réseau d'opérateur 14 et du réseau Internet 34.
Conformément à ce procédé, le terminal client 32 émet une première requête de fourniture de service destinée au serveur 10. Cette première requête de fourniture de service est émise lors d'une étape 70. Elle est transmise par le réseau Internet 34 et parvient au routeur 36 qui, sous le contrôle de la plate-forme de commande 38 la redirige vers l'équipement intermédiaire 40 pour que celui-ci puisse l'intercepter. L'équipement intermédiaire 40 reçoit cette requête de fourniture de service et vérifie si le numéro d'identification correspondant au terminal client 32 est absent d'un tableau qu'il tient à jour.
C'est le cas puisque cette requête est la première que le terminal client adresse au serveur 10. L'équipement intermédiaire 40 intercepte donc l'établissement de la session requise par le terminal client 32 et répond à la requête, à la place du serveur 10, lors d'une étape 72 de renvoi au terminal client 32 d'un accord de fourniture de service. L'équipement intermédiaire intercepte la requête en empêche sa transmission au serveur 10. Le renvoi de l'accord de fourniture de service par l'équipement intermédiaire 40 déclenche un délai d'attente, prédéterminé par l'équipement intermédiaire, d'un accusé de réception de l'accord, correspondant au délai d'attente du serveur 10.
Lors de l'étape 76 suivante, le terminal client 32 renvoie un accusé de réception de l'accord qu'il a reçu. De même que précédemment, cet accusé de réception est redirigé vers l'équipement intermédiaire 40 par le routeur 36 sous le contrôle de la plate-forme de commande 38. Si cet accusé de réception parvient à l'équipement intermédiaire 40 avant l'expiration du délai d'attente déclenché à l'étape 74, cela déclenche l'inscription du terminal client 32 dans le tableau tenu à jour par l'équipement intermédiaire 40. Cette inscription du terminal client 32 dans le tableau de l'équipement intermédiaire 40 atteste que ce terminal client 32 a émis une requête de fourniture de service qui n'était pas une attaque de déni de service. Ce terminal client est donc considéré comme un terminal de confiance par l'équipement intermédiaire 40. L'inscription dans le tableau de l'équipement intermédiaire 40 peut être temporaire, c'est-à-dire elle-même soumise à un délai.
Après avoir reçu l'accusé de réception émis par le terminal client 32 lors de l'étape 76, l'équipement intermédiaire 40 interrompt l'établissement de la session qu'il a établie avec le terminal client à la place du serveur 10 et renvoie un signal informant le terminal client 32 que la connexion a échoué, lors d'une étape 78. En effet, cette session ne peut pas être reprise par le serveur 10, puisque pour l'établissement d'une session de communication entre le terminal client 32 et le serveur 10, le serveur 10 doit avoir généré lui-même le numéro de séquence de l'accusé de réception qu'il reçoit, lors de l'émission de l'accord.
Plus tard, le terminal client 32 émet une seconde requête de fourniture de service destinée au serveur 10. Cette requête de fourniture de service est émise par le terminal clients 32 lors d'une étape 82. Cette requête de fourniture de service est interceptée par l'équipement intermédiaire 40 qui vérifie, comme précédemment, si le terminal client 32 est absent du tableau qu'il tient à jour. Ce n'est pas le cas, donc la requête de fourniture de service émise par le terminal client 32 lors de l'étape 82 est transmise et reçue par le serveur 10 lors d'une étape 84. Ensuite, lors d'une étape 86, le serveur 10 renvoie un accord de fourniture de service au terminal client 32, et déclenche lors d'une étape 88 un délai d'attente d'un accusé de réception en provenance du terminal client 32.
Si, comme illustré sur le figure 3, le terminal client 32 renvoie avant l'expiration du délai imposé par le serveur 10 un accusé de réception lors d'une étape 90, rétablissement de la session de communication entre le terminal client 32 et le serveur 10 peut se poursuivre sans être interrompu par l'équipement intermédiaire 40. Dans ce second mode de réalisation d'un procédé selon l'invention, on notera que le serveur protégé par l'équipement intermédiaire n'est pas du tout sollicité lorsqu'il est victime d'une attaque de déni de service.
Un troisième mode de réalisation d'un procédé de protection du serveur 10 ou 18 selon l'invention va maintenant être décrit en référence à la figure 4, dans le cadre d'un échange de données entre le client 32 et le serveur 10. Ce procédé est avantageusement mis en œuvre par l'équipement intermédiaire 40 situé à l'interface du réseau d'opérateur 14 et du réseau Internet 34.
Conformément à ce procédé, le terminal client 32 émet une première requête de fourniture de service destinée au serveur 10. Cette première requête de fourniture de service est émise lors d'une étape 100. Elle est transmise par le réseau Internet 34 et parvient au routeur 36 qui, sous le contrôle de la plate-forme de commande 38 la redirige vers l'équipement intermédiaire 40 pour que celui-ci puisse l'intercepter. L'équipement intermédiaire 40 reçoit cette requête de fourniture de service et vérifie si le numéro d'identification correspondant au terminal client 32 est absent d'un tableau qu'il tient à jour. C'est le cas puisque cette requête est la première que le terminal client adresse au serveur 10. L'équipement intermédiaire 40 intercepte donc l'établissement de la session requise par le terminal client 32.
La requête de fourniture de service émise par le client 32 comprend un identifiant de ce client, par exemple son adresse IP. Alors, à la réception de cette requête de fourniture de service, l'équipement intermédiaire 40 calcule, au moyen d'un algorithme prédéfini, une clé qui est fonction de l'adresse IP du client 32. On utilise pour cela un algorithme secret si bien que seul l'équipement intermédiaire 40 est capable de calculer cette clé. Au cours d'une étape 102 suivante, l'équipement intermédiaire 40 répond à la requête, à la place du serveur 10 en renvoyant au terminal client 32 un accord de fourniture de service. Cet accord de fourniture de service contient une valeur égale à la clé que l'équipement intermédiaire a calculé. Par exemple, l'équipement intermédiaire 40 peut inclure la valeur dans l'accord de fourniture de service sous la forme d'un numéro de séquence. Ce numéro de séquence est un champ classiquement utilisé dans les protocoles de transmission de données par paquets tel que le protocole TCP. A la différence du mode de réalisation précédemment décrit, l'équipement intermédiaire 40 ne garde pas en mémoire la requête de fourniture de service et ne déclenche aucune temporisation. Ainsi, il ne remplit pas sa mémoire tampon.
Lors d'une étape 104 suivante, le terminal 32 renvoie un accusé de réception de l'accord qu'il a reçu. De façon à préciser le numéro du paquet que le terminal client a reçu, il inclut dans son accusé de réception le numéro de séquence de l'accord de fourniture de service. Or, ce numéro de séquence correspond à la valeur égale à la clé unique.
De même que précédemment, cet accusé de réception est redirigé vers l'équipement intermédiaire 40 par le routeur 36 sous le contrôle de la plate-forme de commande 38.
A la réception de cet accusé de réception, l'équipement intermédiaire 40 en extrait l'adresse IP du terminal client 32 ainsi que la valeur qu'il contient.
Au cours d'une étape suivante, l'équipement intermédiaire 40 calcule une clé à partir de l'adresse IP qu'il a extrait de l'accusé de réception il compare ensuite la valeur extraite avec la clé nouvellement calculée. Si ces deux clés sont identiques, l'équipement intermédiaire considère que le terminal client 32 est fiable et qu'il peut alors déclencher l'inscription du terminal client 32 dans le tableau tenu à jour. Cette inscription du terminal client 32 dans le tableau de l'équipement intermédiaire 40 atteste que ce terminal client 32 a émis une requête de fourniture de service qui n'était pas une attaque de déni de service.
Ainsi, dans ce mode de réalisation, l'équipement intermédiaire peut tester la fiabilité d'un terminal client 32 qui a émis une requête de fourniture de service sans pour autant avoir besoin de remplir temporairement sa mémoire tampon.
Ensuite, lors d'une étape 106, l'équipement intermédiaire 40 envoie au terminal client 32 un signal informant le terminal client 32 que la connexion a échoué.
Plus tard, le terminal client 32 émet une seconde requête de fourniture de service destinée au serveur 10. Comme le terminal client 32 a été ajouté dans le tableau tenu à jour par l'équipement intermédiaire 40, cette requête sera transmise au serveur 10 qui acceptera l'établissement de la session. Les étapes suivantes sont identiques à celles décrites dans le deuxième mode de réalisation.
Dans ce troisième mode de réalisation, on notera que le serveur 10 est protégé par l'équipement intermédiaire puisqu'il n'est pas du tout sollicité d'une attaque de déni de service. De plus, on notera que cet équipement intermédiaire ne peut non plus pas être victime d'une attaque de déni de service puisqu'il ne garde pas en mémoire les requêtes de fourniture de service.
Le procédé consistant à ne pas garder en mémoire les requêtes de fourniture de service peut par ailleurs être mis en œuvre directement sur le serveur. En effet, le serveur ne risque plus de voir sa mémoire tampon rapidement remplie et est donc ainsi protégé contre des attaques de déni de service. Dans ce cas, par exception à la définition générale de l'invention, la requête est effectivement transmise au serveur mais ce dernier ne la prend en compte qu'à partir de l'étape de transmission de la requête au serveur.
Il apparaît clairement qu'un système et un procédé selon l'invention permettent de protéger efficacement un serveur contre des attaques de déni de service, sans nécessiter pour autant la gestion de plusieurs sessions de communication

Claims

REVENDICATIONS
1. Procédé de protection d'un serveur (10, 18) contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client (26, 32) et le serveur est requis par le client pour la fourniture d'un service, ce procédé comprenant les étapes suivantes : a. interception d'une requête de fourniture de service émise par un client et destinée au serveur (10), la requête n'étant pas transmise au serveur ; b. vérification si le client est présent dans un tableau de clients jugés fiables ; c. si le client est présent dans le tableau, transmission de la requête au serveur ; d. si le client est absent du tableau, mise en œuvre des étapes suivantes : e. envoi (72) d'un accord de fourniture de service au client ; f. en cas de réception d'un accusé de réception de l'accord provenant du client dans des conditions prédéterminées, inscription du client dans le tableau et envoi (78) au client d'un signal l'informant que l'établissement de la session de communication a échoué.
2. Procédé selon la revendication 1 , dans lequel les conditions prédéterminées consistent en ce que l'accusé de réception est reçu dans un délai prédéterminé après l'envoi de l'accord de fourniture de service.
3. Procédé selon la revendication 1 , dans lequel les conditions prédéterminées consistent en ce que l'accusé de réception contient une valeur égale à une clé unique préalablement introduite dans l'accord de fourniture de service.
4. Procédé selon la revendication 3, dans lequel la clé unique est fonction du client et est calculée une première fois au moment de l'envoi de l'accord de fourniture de service et une seconde fois au moment de la réception de l'accusé de réception.
5. Programme d'ordinateur de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client et le serveur est requis par le client pour la fourniture d'un service, le programme contenant des instructions pour la mise en œuvre des étapes b) à f) de la revendication 1.
6. Dispositif de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client et le serveur est requis par le client pour la fourniture d'un service, le W 2
-14-
dispositif comprenant des moyens pour la mise en oeuvre des étapes b) à f) de la revendication 1.
7. Dispositif selon la revendication 6, dans lequel les moyens pour la mise en œuvre des étapes b) à f) comprennent un programme d'ordinateur selon la revendication 5.
8. Système de protection d'un serveur contre des attaques de déni de service utilisant un protocole selon lequel un établissement d'une session de communication entre un client (26, 32) et le serveur est requis par le client pour la fourniture d'un service, le système comportant un serveur (10, 18) adapté pour la fourniture d'un service susceptible d'être requis par un client (26, 32), caractérisé en ce que le système comporte un équipement intermédiaire (16, 22, 30, 40) formé par un dispositif de protection selon la revendication 6 ou 7.
9. Système de protection d'un serveur selon la revendication 8, dans lequel l'équipement intermédiaire (16, 22, 30, 40) est un pare-feu disposé entre le serveur (10, 18) et un réseau (28, 34) d'accès du client (26, 32) au serveur.
EP05788506A 2004-07-08 2005-07-08 Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service. Withdrawn EP1766934A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0407642A FR2872980A1 (fr) 2004-07-08 2004-07-08 Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service
PCT/FR2005/001776 WO2006013291A1 (fr) 2004-07-08 2005-07-08 Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service.

Publications (1)

Publication Number Publication Date
EP1766934A1 true EP1766934A1 (fr) 2007-03-28

Family

ID=34950537

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05788506A Withdrawn EP1766934A1 (fr) 2004-07-08 2005-07-08 Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service.

Country Status (4)

Country Link
US (1) US20080052402A1 (fr)
EP (1) EP1766934A1 (fr)
FR (1) FR2872980A1 (fr)
WO (1) WO2006013291A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8387143B2 (en) * 2009-11-30 2013-02-26 Citrix Systems, Inc. Systems and methods for aggressive window probing
US9602330B1 (en) * 2013-05-23 2017-03-21 Amazon Technologies, Inc. Two-stage TCP handshake
US10977457B2 (en) * 2015-01-30 2021-04-13 Sony Corporation Information processing system and method, and information processing device and method

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5826014A (en) * 1996-02-06 1998-10-20 Network Engineering Software Firewall system for protecting network elements connected to a public network
US6738814B1 (en) * 1998-03-18 2004-05-18 Cisco Technology, Inc. Method for blocking denial of service and address spoofing attacks on a private network
US6725378B1 (en) * 1998-04-15 2004-04-20 Purdue Research Foundation Network protection for denial of service attacks
US7162740B2 (en) * 2002-07-22 2007-01-09 General Instrument Corporation Denial of service defense by proxy

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006013291A1 *

Also Published As

Publication number Publication date
WO2006013291A1 (fr) 2006-02-09
US20080052402A1 (en) 2008-02-28
FR2872980A1 (fr) 2006-01-13

Similar Documents

Publication Publication Date Title
EP1733533B1 (fr) Procede et systeme de gestion d'autorisation d'acces d'un utilisateur au niveau d'un domaine administratif local lors d'une connexion de l'utilisateur a un reseau ip
US6816910B1 (en) Method and apparatus for limiting network connection resources
EP1774751A1 (fr) Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns
US20050144441A1 (en) Presence validation to assist in protecting against Denial of Service (DOS) attacks
FR2844941A1 (fr) Demande d'acces securise aux ressources d'un reseau intranet
JP2004507978A (ja) ネットワークノードに対するサービス拒絶アタックに対抗するシステム及び方法
EP2210396B1 (fr) Système d'interconnexion entre au moins un appareil de communication et au moins un système d'information distant et procédé d'interconnexion
US7970878B1 (en) Method and apparatus for limiting domain name server transaction bandwidth
EP1766934A1 (fr) Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service.
EP3568964B1 (fr) Procédé de transmission d'une information numérique chiffrée de bout en bout et système mettant en oeuvre ce procédé
EP3087719B1 (fr) Procédé de ralentissement d'une communication dans un réseau
WO2004086719A2 (fr) Systeme de transmission de donnees client/serveur securise
EP1902564A2 (fr) Mecanisme de protection des reseaux h.323 pour les fonctions d'etablissement d'appel
EP1142182A2 (fr) Dispositf et procede de traitement d'une sequence de paquets d'information
EP2494801A1 (fr) Procédé d'établissement d'une session applicative, dispositif et notification correspondante
EP1471713B1 (fr) Procédé et système de contrôle d'accès à des sites internet au moyen d'un serveur cache
CN108833329B (zh) 一种在线网络数据缓存转发方法及系统
EP2109284A1 (fr) Mécanisme de protection contre les attaques de refus de service par réacheminement de trafic.
WO2008031967A2 (fr) Procédé de supervision d'une session d'accès a un service établie par un terminal client au moyen d'un protocole de configuration dynamique
FR2843508A1 (fr) Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local
EP2011273B1 (fr) Procede et dispositif d'adaptation d'un protocole de communication point a point dans un reseau de telecommunications
WO2005064886A1 (fr) Procede de detection et de prevention des usages illicites de certains protocoles de reseaux sans alteration de leurs usages licites
FR3112002A1 (fr) Procédé et dispositif de détection d'une faille de sécurité.
FR2881592A1 (fr) Procede et dispositif de detection d'usurpations d'adresse dans un reseau informatique
FR2899752A1 (fr) Procede, dispositif et programme de detection d'usurpation d'adresse dans un reseau sans fil

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17P Request for examination filed

Effective date: 20070205

RIN1 Information on inventor provided before grant (corrected)

Inventor name: GOURHANT, YVON

Inventor name: CARLINET, YANNICK

Inventor name: TRABE, PATRICK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20101202

RTI1 Title (correction)

Free format text: METHOD, COMPUTER PROGRAM, DEVICE AND SYSTEM FOR PROTECTING A SERVER AGAINST DENIAL-OF-SERVICE ATTACKS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111117