WO2006013292A1 - Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns - Google Patents

Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns Download PDF

Info

Publication number
WO2006013292A1
WO2006013292A1 PCT/FR2005/001777 FR2005001777W WO2006013292A1 WO 2006013292 A1 WO2006013292 A1 WO 2006013292A1 FR 2005001777 W FR2005001777 W FR 2005001777W WO 2006013292 A1 WO2006013292 A1 WO 2006013292A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
dns
protecting
service attacks
attacks
Prior art date
Application number
PCT/FR2005/001777
Other languages
English (en)
Inventor
Patrick Trabe
Yvon Gourhant
Yannick Carlinet
Original Assignee
France Telecom
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 filed Critical France Telecom
Priority to EP05788637A priority Critical patent/EP1774751A1/fr
Priority to US11/631,673 priority patent/US20080028073A1/en
Publication of WO2006013292A1 publication Critical patent/WO2006013292A1/fr

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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • 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

  • the present invention relates to a method, a device and a system for protecting a server against DNS denial of service attacks.
  • the invention relates to such a method in which: DNS denial of service attacks targeting the server are detected; - intermediate equipment intercepts data to the server;
  • a DNS (Domain Name Service) service makes it possible to provide an IP (Internet Protocol) address corresponding to a symbolic name such as a URL address or a domain name. It is a service that is provided by a DNS system adapted to respond to specific requests for DNS service delivery issued from client terminals.
  • IP Internet Protocol
  • a DNS service provisioning request is therefore a request whose function is to obtain from a DNS system the IP address of a server whose known symbolic name is known. It comprises, among other things, a first information field called “source address” or “identification field” in which the IP address of the sender of this request is recorded and which is used by the DNS system to send a response to the request. client terminal sending the request. It also includes a second information field called “requested address” in which is inscribed the symbolic name of the server whose issuer of the request wishes to have the IP address.
  • a DNS service is essential for the establishment of communications between different terminals connected to each other via an IP type network such as the Internet, since it allows the terminals to be located between them without having to remember their respective IP addresses, but simply by knowing their symbolic names. Web site visits or email transmission are examples of actions that require the solicitation of a DNS service.
  • a DNS system generally consists of a hierarchical set of DNS servers, each DNS server being associated with a specific part of the symbolic names managed by the system. Specifically, a DNS server has correspondence tables between the symbolic names that it manages and corresponding IP addresses.
  • a first DNS server receives the request. If it is not competent to answer, it sends back to the client terminal a response in which it provides the IP address of a second server DNS system likely to respond to this request. The client terminal therefore sends its request to the second DNS server which can also, if it is not competent to answer, provide the IP address of a third DNS server. The client terminal renews its request as many times as necessary to reach the competent DNS server to respond.
  • a first DNS server receives the request. If he is not competent to answer, he himself transmits the request to a second DNS server. If the second DNS server is not competent to respond either, it itself transmits the request to a third DNS server. Recursively, the DNS servers transfer the request issued by the client terminal as many times as necessary so that it can reach the appropriate DNS server to respond. The response provided by the competent server is then transmitted in the opposite direction until it reaches the first requested DNS server, which in turn transmits it to the client terminal.
  • a single request issued from the client terminal causes the generation of a plurality of requests transmitted from one server to another DNS system.
  • a DNS denial of service attack consists in generating a fraudulent DNS service provisioning request, that is to say a request whose form reproduces the form of the DNS service provisioning requests, but which is not motivated by obtaining a DNS service.
  • a fraudulent DNS service provisioning request that is to say a request whose form reproduces the form of the DNS service provisioning requests, but which is not motivated by obtaining a DNS service.
  • a first method consists in sending, from a client terminal, a fraudulent request in which the source address is not that of the client terminal but that of a server that the user of the client terminal wishes to attack. .
  • a second method called a "recursive attack" consists of transmitting from a client terminal a fraudulent request in which the requested address is a symbolic name managed by a DNS server that the user of the client terminal wishes to attack. This type of attack exploits the recursive mode of the DNS system.
  • the client terminal transmits this request to any of the servers of the DNS system, but it will reach the attacked DNS server without further intervention of the client terminal.
  • the source address in the request is that of the issuer or not. It can be totally wacky, but it can also match that of the transmitter, it does not stop to harm.
  • a malicious user sends from his client terminal a large number of fraudulent DNS service provisioning requests, so that the attacked server receives a very large number of messages (requests in the case of recursive attacks, responses in the case of simple attacks). This has the effect of making the attacked server unable to provide the service for which it is programmed.
  • simple attacks target all types of servers while recursive attacks exclusively target DNS servers.
  • a first solution for protecting a server against such DNS denial of service attacks is to create access control lists, these access control lists comprehensively defining client terminals authorized to transmit requests for provision of services. DNS service to specific DNS servers. Thus, if a request to a DNS server is issued from a client terminal that does not belong to the access control list of this DNS server, it is not processed.
  • the queries can have all the appearance of normal queries, since the source address of the request can actually be the address of the sender and the requested address is not a wacky address. . In this case, this solution may have some efficiency. But it is very easy to circumvent if we know at least one IP address of a client terminal authorized to query the DNS server that we want to attack. In this case, simply enter this IP address in the source address of fraudulent requests.
  • the aim of the invention is to improve the existing methods of protecting a server against DNS denial of service attacks by providing a method capable of protecting a server against such attacks and which makes it possible to sort the data transmitted to an attacked server so that those who are not involved in these attacks can be treated so that the operation of the attacked server is as undisturbed as possible.
  • the invention therefore relates to a method for protecting a server against DNS denial of service attacks, in which:
  • intermediate equipment intercepts data packets to the server; characterized in that: the intermediate equipment analyzes the intercepted data packets;
  • the intermediate equipment interrupts the transmission of this data packet to the server.
  • a method of protecting a server according to the invention may further include one or more of the following features:
  • the predetermined criterion is linked to the emitter of the intercepted packet
  • the predetermined criterion is linked to a requested address in the intercepted packet, if it concerns a request for DNS service provisioning;
  • the predetermined criterion is linked to the absence of a transaction number of the intercepted packet in a list of request transaction numbers issued by the server, this list being maintained by the intermediate equipment; - during the detection step of DNS denial of service attacks:
  • the subject of the invention is also a device for protecting a server against DNS denial of service attacks, comprising means for intercepting data packets destined for the server, characterized in that it furthermore comprises:
  • means for analyzing the intercepted data packets means for interrupting the transmission to the server of a data packet among the intercepted data packets, if a criterion predetermined by the protection device is verified following the analysis of this data packet.
  • the invention also relates to a system for protecting a server against DNS denial of service attacks, comprising a server that may be attacked by a client, characterized in that it comprises an intermediate device formed by a protection device as described 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 illustrates the successive steps of a method for protecting a server according to a possible 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.
  • this server 10 is a DNS server belonging to a set of servers of a DNS system.
  • the server 10 may be any server suitable for providing any service.
  • the server 10 is connected to a high-speed network 12, for example an ADSL link, itself connected to an operator network 14.
  • Intermediate equipment 16 may be disposed at the interface of the operator network 14 and the ADSL broadband network. This intermediate equipment 16 is for example a firewall.
  • the installation includes a second server 18 also adapted to provide a predetermined service to different customers.
  • This server 18, as well as the server 10, can be a DNS server or any other type of server. It is connected to a private local area network 20, itself connected to the operator network 14.
  • 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, such as the equipment intermediate 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 comprises 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 to intermediate equipment 40.
  • Intermediate equipment 40 is for example a firewall, such as 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 operator network 14.
  • DNS shown in Figure 2 comprises a first step 100 of detecting an anomaly.
  • one of the elements of the installation of FIG. 1 detects an abnormal traffic towards the server 10 or 18. This detection is for example carried out by the intermediate equipment 16 (for the server 10) or the intermediate equipment 22 (for the server 18).
  • the traffic related to the DNS service provisioning requests and the corresponding responses is UDP-transmitted traffic which normally represents less than 10% of the overall traffic of a packet data network.
  • the detection of an abnormal traffic may therefore consist in the detection of an abnormal quantity of UDP packets going to the server 10 or 18, that is to say greater than a predetermined threshold.
  • the management system 42 is informed of this anomaly by the intermediate equipment 16 or 22.
  • the intermediate equipment 16 or 22 having detected the anomaly, or the possibly attacked server 10 or 18 analyzes the nature of the packets likely to participate in DNS denial of service attacks.
  • the purpose of this verification step is to determine whether the packets actually relate to the provision of a DNS service.
  • step 108 end of the process. Otherwise, we go to a step 110 of protection of the attacked server.
  • the management system deviates all the traffic destined for the server considered as being attacked to an intermediate device of the installation.
  • This intermediate equipment may be, depending on the case, the intermediate equipment 16, 22, 30 or 40.
  • a step 112 of analysis of the content of this packet is carried out. According to case, this analysis can lead to determine a specific transaction number which is associated with this packet, the source address and / or the actual transmitter of this packet, and possibly, if this packet concerns a DNS request, the address requested in this request.
  • the intermediate equipment checks whether a criterion it has predetermined is filled, based on the information from the analysis of step 112. This criterion will be detailed later, according to different possible configurations of attacks.
  • this packet If the predetermined criterion is checked for this packet, we go to a step 116 of interruption of the transmission of this packet to the attacked server. In practice, this package can be deleted by the intermediate equipment. Otherwise, we go to a step 118 of transmission of this packet to the attacked server.
  • a test step 120 is made in which the intermediate equipment checks whether it has received a new data packet for the attacked server. In this case, we return to step 112. Otherwise, we go to a step 122 end of the process.
  • the server 10 via the high-speed network 28, the operator network 14 and the high-speed network 12, and
  • the server 18 via the high-speed network 28, the operator network 14 and the private local network 20. It is therefore connected to the servers 10 and 18 via a data transmission network on which the management system 42 has full visibility.
  • the client terminal 32 is connected:
  • the server 10 via the Internet network 34, the operator network 14 and the high-speed network 12, and
  • the client terminal is connected to the server via a network on which the management system 42 has full visibility, and DNS denial of service attacks are simple;
  • the client terminal is connected to the server via a network on which the management system 42 has full visibility, and DNS denial of service attacks are recursive;
  • the client terminal is connected to the server via a network on which the management system 42 does not have full visibility, and DNS denial of service attacks are simple;
  • the client terminal is connected to the server via a network on which the management system 42 does not have full visibility, and DNS denial of service attacks are recursive.
  • the method according to the invention does not apply, since at each transmission of a request for DNS service provision the installation is able to check itself that the address source indicated in this request corresponds to the IP address of its issuer. This verification is carried out by a server, known as the BRAS ("BRoadband Access Server") server, located in particular in the high-speed network 28 and the data of which the operator's management system 42 has access.
  • BRAS BRoadband Access Server
  • step 104 for each data packet destined for the server possibly attacked and intercepted by the intermediate equipment, it is checked: - the source port number;
  • both the source port number and the destination port number are 53, which is the port value used for forwarding packets for DNS services, and if the protocol used at the application layer level is identified as the DNS protocol, so it is decided that the target server is the victim of DNS denial of service attacks. Since we are in a configuration of recursive attacks, the packets participating in these attacks involve fraudulent requests for DNS service provisioning.
  • Steps 104 and 106 are executed by the intermediate equipment 16 if the attacked server is the server 10 and by the intermediate equipment 22 if the attacked server and the server 18.
  • the intermediate equipment having carried out the verification step 104 and the test step 106 identifies the issuer of the fraudulent DNS queries and possibly the requested address in these requests, and then transmits these data to the management system 42. This issuer and this requested address are therefore filed by the management system 42
  • the predetermined criterion used by the intermediate equipment during the test step 114 to interrupt the transmission of a data packet for the attacked server is linked to the identity of the sender of the intercepted packet and possibly to the requested address which is the subject of the request. If the intercepted packet is sent by the transmitter stored by the management system 42 and possibly if it concerns the requested address stored by the management system 42, the transmission of this packet of data is interrupted. Otherwise, it reaches the recipient.
  • step 104 for each data packet destined for the server possibly attacked and intercepted by the intermediate equipment, it is checked:
  • next test step 106 if the source port number is set to 53 and if the protocol used at the application layer is identified as the DNS protocol, then it is decided that the target server is the victim of the problem. DNS denial of service attacks. Since we are in a configuration of simple attacks, the packets participating in these attacks involve responses to fraudulent requests for DNS service provision.
  • Steps 104 and 106 are executed by the intermediate equipment 16 if the attacked server is the server 10 and by the intermediate equipment 22 if the attacked server and the server 18.
  • the intermediate equipment having carried out the verification step 104 and the test step 106 identifies the transaction numbers of each DNS request sent by the attacked server and transmits these transaction numbers.
  • the management system 42 which manages a list of transaction numbers of requests issued by the attacked server.
  • the transaction numbers in this list correspond to legitimate request numbers issued by the attacked server.
  • the list is stored and maintained by the management system or the intermediate equipment. Thus, this list evolves according to the legitimate requests emitted by the server.
  • the predetermined criterion used by the intermediate equipment during the test step 114 to interrupt the transmission of a data packet for the attacked server is related to the transaction number of the intercepted packet. If the intercepted packet has a transaction number that is in the list of transaction numbers managed by the management system 42, it is transmitted to the attacked server, since it is then a legitimate response to a request issued by this last. Otherwise the transmission of this data packet is interrupted.
  • step 104 for each data packet destined for the server possibly attacked and intercepted by the intermediate equipment, it is checked:
  • Step 106 if the source port number is set to 53 and if the protocol used at the application layer is identified as the DNS protocol, then it is decided that the target server is the victim. DNS denial of service attacks. Since we are in a configuration of recursive attacks, the packets participating in these attacks involve fraudulent requests for DNS service provisioning. Steps 104 and 106 are executed by the intermediate equipment 16 if the attacked server is the server 10 and by the intermediate equipment 22 if the attacked server and the server 18.
  • the intermediate equipment having carried out the verification step 104 and the test step 106 identifies the requested address in the fraudulent requests, then transmits these data to the management system 42.
  • This requested address which is an address managed by the attacked server, is therefore stored by the management system 42.
  • the predetermined criterion used by the intermediate equipment during the test step 114 to interrupt the transmission of a data packet intended for the attacked server is linked to the requested address which is the subject of the request of the intercepted packet. If the intercepted packet concerns the requested address stuck by the management system 42, the transmission of this data packet is interrupted. Otherwise, it reaches the recipient. It is clear that a protection method as described above effectively protects an attacked server against DNS denial of service attacks, without neutralizing it.

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)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (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, 18) contre des attaques de déni de service DNS, dans lequel : - on détecte (100, 102, 104) des attaques de déni de service DNS visant le serveur, - on intercepte (110) les paquets de données à destination du serveur. Si un paquet intercepté a un numéro de transaction qui n'est pas dans une liste de numéros de transaction de requêtes émises par le serveur, alors on interrompt (116) la transmission de ce paquet de données vers le serveur.

Description

Procédé, dispositif et système de protection d'un serveur contre des attaques de déni de service DNS
La présente invention concerne un procédé, un dispositif et un système de protection d'un serveur contre des attaques de déni de service DNS.
Plus précisément, l'invention concerne un tel procédé dans lequel : on détecte des attaques de déni de service DNS visant le serveur ; - un équipement intermédiaire intercepte des données à destination du serveur ;
Un service DNS ( de l'anglais "Domain Name Service") permet de fournir une adresse IP (de l'anglais "Internet Protocol") correspondant à un nom symbolique tel qu'une adresse de type URL ou un nom de domaine. C'est un service qui est fourni par un système DNS adapté pour répondre à des requêtes spécifiques de fourniture de service DNS émises depuis des terminaux clients.
Une requête de fourniture de service DNS est donc une requête qui a pour fonction d'obtenir auprès d'un système DNS l'adresse IP d'un serveur dont on connaît le nom symbolique. Elle comporte entre autres un premier champ d'information appelé "adresse source" ou "champ d'identification" dans lequel est inscrite l'adresse IP de l'émetteur de cette requête et qui est utilisé par le système DNS pour envoyer une réponse au terminal client émetteur de la requête. Elle comporte également un second champ d'informations appelé "adresse demandée" dans lequel est inscrit le nom symbolique du serveur dont l'émetteur de la requête souhaite avoir l'adresse IP. On comprend qu'un service DNS est indispensable pour l'établissement de communications entre différents terminaux reliés entre eux via un réseau de type IP tel que le réseau Internet, puisqu'il permet aux terminaux de se localiser entre eux sans avoir besoin de retenir leurs adresses IP respectives, mais simplement en connaissant leurs noms symboliques. La visite de sites Web ou la transmission de courriers électroniques sont des exemples d'actions qui requièrent la sollicitation d'un service DNS.
Un système DNS est en général constitué d'un ensemble hiérarchisé de serveurs DNS, chaque serveur du système DNS étant associé à une partie bien précise des noms symboliques gérés par le système. Concrètement un serveur DNS comporte des tables de correspondance entre les noms symboliques qu'il gère et des adresses IP correspondantes.
Lorsqu'un terminal client transmet une requête de fourniture de service DNS à un système DNS, pour obtenir une adresse IP à partir d'un nom symbolique, deux procédés différents peuvent être mis en œuvre par le système DNS du fait de sa structure hiérarchique.
Selon un premier procédé, que l'on appellera par la suite "mode non récursif", un premier serveur DNS reçoit la requête. S'il n'est pas compétent pour y répondre, il renvoie au terminal client une réponse dans laquelle il fournit l'adresse IP d'un deuxième serveur du système DNS susceptible de répondre à cette requête. Le terminal client renvoie donc sa requête au deuxième serveur DNS qui peut lui aussi, s'il n'est pas compétent pour y répondre, fournir l'adresse IP d'un troisième serveur du système DNS. Le terminal client renouvelle sa requête autant de fois que nécessaire pour parvenir à atteindre le serveur DNS compétent pour y répondre.
Selon un second procédé, que l'on appellera par la suite "mode récursif", un premier serveur DNS reçoit la requête. S'il n'est pas compétent pour y répondre, il transmet lui-même la requête à un deuxième serveur du système DNS. Si le deuxième serveur DNS n'est pas compétent pour y répondre non plus, il transmet lui-même la requête à un troisième serveur du système DNS. De façon récursive, les serveurs du système DNS transfèrent la requête émise par le terminal client autant de fois que nécessaire pour qu'elle parvienne à atteindre le serveur DNS compétent pour y répondre. La réponse fournie par le serveur compétent est ensuite transmise en sens inverse jusqu'à ce qu'elle parvienne au premier serveur DNS sollicité, qui la transmet à son tour au terminal client.
On remarque que selon le mode récursif de traitement de la requête DNS, une unique requête émise à partir du terminal client provoque la génération d'une pluralité de requêtes transmises d'un serveur à l'autre du système DNS.
Une attaque de déni de service DNS consiste à générer une requête de fourniture de service DNS frauduleuse, c'est-à-dire une requête dont la forme reproduit la forme des requêtes de fourniture de service DNS, mais qui n'est pas motivée par l'obtention d'un service DNS. Il existe deux procédés connus pour générer une telle requête frauduleuse.
Un premier procédé, appelé "attaque simple", consiste à émettre, depuis un terminal client une requête frauduleuse dans laquelle l'adresse source n'est pas celle du terminal client mais celle d'un serveur que l'utilisateur du terminal client souhaite attaquer.
Ainsi, tout se passe comme si l'émetteur de la requête était en fait le serveur attaqué. Le système DNS renverra donc sa réponse au serveur attaqué, quel que soit son mode de fonctionnement (récursif ou non récursif) puisque c'est l'adresse IP du serveur qui est inscrite dans l'adresse source de la requête. On notera qu'il est indifférent que l'adresse demandée dans la requête existe ou non. Celle-ci peut être totalement farfelue. Un second procédé, appelé "attaque récursive", consiste à émettre depuis un terminal client une requête frauduleuse dans laquelle l'adresse demandée est un nom symbolique géré par un serveur DNS que l'utilisateur du terminal client souhaite attaquer. Ce type d'attaque exploite le mode récursif du système DNS. En effet, le terminal client transmet cette requête à n'importe lequel des serveurs du système DNS, mais celle-ci parviendra au serveur DNS attaqué sans autre intervention du terminal client. On notera qu'il est indifférent que l'adresse source dans la requête soit celle de l'émetteur ou non. Celle-ci peut être totalement farfelue, mais elle peut également correspondre à celle de l'émetteur, cela ne l'empêche pas de nuire. Dans la pratique, un utilisateur malveillant envoie depuis son terminal client un grand nombre de requêtes de fourniture de service DNS frauduleuses, de manière que le serveur attaqué reçoive un très grand nombre de messages (des requêtes dans le cas d'attaques récursives, des réponses dans le cas d'attaques simples). Ceci a pour effet de rendre le serveur attaqué incapable de fournir le service pour lequel il est programmé. On remarquera que les attaques simples visent tous types de serveurs alors que les attaques récursives visent exclusivement des serveurs DNS.
Une première solution pour protéger un serveur contre de telles attaques de déni de service DNS, consiste à créer des listes de contrôle d'accès, ces listes de contrôle d'accès définissant de façon exhaustive des terminaux clients autorisés à transmettre des requêtes de fourniture de service DNS à des serveurs DNS spécifiques. Ainsi, si une requête, destinée à un serveur DNS, est émise à partir d'un terminal client qui n'appartient pas à la liste de contrôle d'accès de ce serveur DNS, elle n'est pas traitée.
Dans le cas d'attaques récursives, les requêtes peuvent avoir toutes les apparences de requêtes normales, puisque l'adresse source de la requête peut effectivement être l'adresse de l'émetteur et que l'adresse demandée n'est pas une adresse farfelue. Dans ce cas, cette solution peut avoir une certaine efficacité. Mais elle est très facile à contourner si l'on connaît au moins une adresse IP d'un terminal client autorisé à interroger le serveur DNS que l'on souhaite attaquer. Dans ce cas, il suffit d'inscrire cette adresse IP dans l'adresse source des requêtes frauduleuses.
De même, dans le cas d'attaques simples, il suffit que l'on connaisse un serveur DNS qui comporte dans sa liste de contrôle d'accès l'adresse IP du serveur que l'on souhaite attaquer. On inscrit alors un nom symbolique géré par ce serveur DNS dans l'adresse demandée des requêtes frauduleuses. Une deuxième solution, uniquement pour contrer les attaques récursives, est de supprimer ce mode de fonctionnement d'un système DNS. Evidemment, cette solution -A-
n'a aucun impact sur les attaques simples. De plus, elle pénalise l'ensemble des utilisateurs du système DNS pour lequel ce mode de fonctionnement est supprimé, en empêchant celui-ci de fonctionner selon le mode récursif.
Enfin, une autre solution pour protéger un serveur contre des attaques de déni de service DNS, de type réactif, consiste à dévier toutes les requêtes à destination d'un serveur attaqué, dès que l'on a détecté que ce serveur était attaqué, vers un autre serveur généralement appelé "trou noir", de façon 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 fait pas la distinction entre les différentes données transmises au serveur attaqué. De plus, dans ce cas, on peut considérer que l'attaque a réellement fonctionné puisque le serveur n'est plus capable de fournir le service pour lequel il est programmé.
L'invention vise à améliorer les procédés existants de protection d'un serveur contre des attaques de déni de service DNS en fournissant un procédé capable de protéger un serveur contre de telles attaques et qui permette de trier les données transmises à un serveur attaqué pour que celles qui ne sont pas impliquées dans ces attaques puissent être traitées de sorte que le fonctionnement du serveur attaqué soit le moins perturbé possible. L'invention a donc pour objet un procédé de protection d'un serveur contre des attaques de déni de service DNS, dans lequel :
- on détecte des attaques de déni de service DNS visant le serveur ;
- un équipement intermédiaire intercepte des paquets de données à destination du serveur ; caractérisé en ce que : l'équipement intermédiaire analyse les paquets de données interceptés ;
- pour chaque paquet de données intercepté, si un critère prédéterminé par l'équipement intermédiaire est vérifié suite à l'analyse de ce paquet de données, l'équipement intermédiaire interrompt la transmission de ce paquet de données vers le serveur.
Ainsi, les requêtes et/ou les réponses à des requêtes de type DNS, relatives à un serveur qui est attaqué sont déviées vers un équipement intermédiaire qui comporte ses propres critères de tri des paquets de données destinés au serveur attaqué. Ce système de filtre, implémenté dans un équipement intermédiaire différent du serveur attaqué permet à ce dernier de continuer à fournir le service pour lequel il est programmé sans ressentir les effets nuisibles des attaques. Un procédé de protection d'un serveur selon l'invention peut en outre comporter l'une ou plusieurs des caractéristiques suivantes :
- le critère prédéterminé est lié à l'émetteur du paquet intercepté ;
- le critère prédéterminé est lié à une adresse demandée dans le paquet intercepté, si celui-ci concerne une requête de fourniture de service DNS ;
- le critère prédéterminé est lié à l'absence d'un numéro de transaction du paquet intercepté dans une liste de numéros de transaction de requêtes émises par le serveur, cette liste étant tenue à jour par l'équipement intermédiaire ; - lors de l'étape de détection des attaques de déni de service DNS :
• on détecte un trafic anormal à destination du serveur, notamment un trafic anormal utilisant le protocole UDP (de l'anglais User Datagram Protocol) ;
• on extrait un numéro de port source contenu dans des paquets de données interceptés ;
• on détermine la nature du protocole utilisé au niveau de la couche application dans les paquets de données interceptés ;
- lors de l'étape de détection des attaques de déni de service DNS on extrait un numéro de port destination contenu dans les paquets de données interceptés ;
L'invention a également pour objet un dispositif de protection d'un serveur contre des attaques de déni de service DNS, comportant des moyens d'interception de paquets de données à destination du serveur, caractérisé en ce qu'il comporte en outre :
- des moyens d'analyse des paquets de données interceptés ; - des moyens d'interruption de la transmission vers le serveur d'un paquet de données parmi les paquets de données interceptés, si un critère prédéterminé par le dispositif de protection est vérifié suite à l'analyse de ce paquet de données.
Enfin l'invention a également pour objet un système de protection d'un serveur contre des attaques de déni de service DNS, comportant un serveur susceptible d'être attaqué par un client, caractérisé en ce qu'il comporte un équipement intermédiaire formé par un dispositif de protection tel que décrit 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 ; et
- la figure 2 illustre les étapes successives d'un procédé de protection d'un serveur selon un mode de réalisation possible 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.
Par exemple, ce serveur 10 est un serveur DNS appartenant à un ensemble de serveurs d'un système DNS. De façon alternative, le serveur 10 peut être un serveur quelconque adapté pour la fourniture d'un service quelconque.
Le serveur 10 est connecté à un réseau à haut débit 12, par exemple une liaison ADSL, elle-même reliée à un réseau 14 d'opérateur. Un équipement intermédiaire 16 peut être disposé à l'interface du réseau 14 d'opérateur et du réseau à haut débit ADSL. Cet équipement intermédiaire 16 est par exemple un pare-feu.
L'installation comporte un deuxième serveur 18 également adapté pour fournir un service prédéterminé auprès de différents clients. Ce serveur 18, de même que le serveur 10, peut être un serveur DNS ou tout autre type de serveurs. Il est connecté à un réseau local privé 20, lui-même relié au réseau 14 d'opérateur. 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 un 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.
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 d'opérateur 14. Le procédé de protection d'un serveur contre des attaques de déni de service
DNS représenté sur la figure 2 comporte une première étape 100 de détection d'une anomalie.
Lors de cette étape 100 de détection d'une anomalie, l'un des éléments de l'installation de la figure 1 détecte un trafic anormal à destination du serveur 10 ou 18. Cette détection est par exemple réalisée par l'équipement intermédiaire 16 (pour le serveur 10) ou l'équipement intermédiaire 22 (pour le serveur 18).
Le trafic lié aux requêtes de fourniture de service DNS et aux réponses correspondantes est un trafic transmis selon le protocole UDP qui normalement représente moins de 10% du trafic global d'un réseau de transmission de données en mode paquets. La détection d'un trafic anormal peut donc consister en la détection d'une quantité anormale de paquets UDP transitant à destination du serveur 10 ou 18, c'est-à- dire supérieure à un seuil prédéterminé.
Lors de l'étape 102 d'alerte suivante, le système de gestion 42 est informé de cette anomalie par l'équipement intermédiaire 16 ou 22. Puis, lors d'une étape 104 de vérification, l'équipement intermédiaire 16 ou 22 ayant détecté l'anomalie, ou bien le serveur 10 ou 18 éventuellement attaqué analyse la nature des paquets susceptibles de participer à des attaques de déni de service DNS. Cette étape de vérification a pour fonction de déterminer si les paquets concernent effectivement la fourniture d'un service DNS. Ensuite, lors d'une étape de test 106, on décide, à la lumière des résultats des étapes 100 et 104 si le serveur concerné est effectivement victime d'attaques de déni de service DNS. C'est par exemple le cas si le nombre de paquets UDP est supérieur au seuil prédéterminé et si ces paquets concernent effectivement un service DNS.
Si ce n'est pas le cas, on passe à une étape 108 de fin de procédé. Sinon, on passe à une étape 110 de protection du serveur attaqué. Lors de cette étape, le système de gestion dévie tout le trafic à destination du serveur considéré comme attaqué vers un équipement intermédiaire de l'installation. Cet équipement intermédiaire peut être, selon les cas, l'équipement intermédiaire 16, 22, 30 ou 40.
Ensuite, dès que l'équipement intermédiaire vers lequel sont déviées les données destinées au serveur attaqué reçoit un paquet de données à destination du serveur attaqué, on passe à une étape 112 d'analyse du contenu de ce paquet. Selon les cas, cette analyse peut conduire à déterminer un numéro de transaction spécifique auquel est associé ce paquet, l'adresse source et/ou l'émetteur réel de ce paquet, et éventuellement, si ce paquet concerne une requête DNS, l'adresse demandée dans cette requête. On passe ensuite à une étape de test 114. Lors de cette étape, l'équipement intermédiaire vérifie si un critère qu'il a prédéterminé est rempli, sur la base des informations issues de l'analyse de l'étape 112. Ce critère sera détaillé par la suite, en fonction de différentes configurations possibles d'attaques.
Si le critère prédéterminé est vérifié pour ce paquet, on passe à une étape 116 d'interruption de la transmission de ce paquet à destination du serveur attaqué. Dans la pratique, ce paquet peut être supprimé par l'équipement intermédiaire. Sinon, on passe à une étape 118 de transmission de ce paquet au serveur attaqué.
Suite aux étapes 116 et 118, on passe à une étape de test 120 lors de laquelle l'équipement intermédiaire vérifie s'il a reçu un nouveau paquet de données destiné au serveur attaqué. Dans ce cas, on revient à l'étape 112. Sinon, on passe à une étape 122 de fin de procédé.
Ce procédé de réaction à des attaques de déni de service DNS, décrit précédemment de façon assez générale, ne s'applique pas obligatoirement dans toutes les configurations d'attaques auxquelles peut être confrontée l'installation, et peut comporter certaines variations selon les configurations.
Notamment, il convient de distinguer les configurations d'attaques simples des configurations d'attaques récursives.
En outre, il convient de distinguer les configurations d'attaques émises à partir d'un terminal client relié au serveur qu'il souhaite attaquer par l'intermédiaire d'un réseau de transmission de données sur lequel le système de gestion 42 du réseau d'opérateur 14 a une complète visibilité, des configurations d'attaques émises à partir d'un terminal client relié au serveur qu'il souhaite attaquer par l'intermédiaire d'un réseau de transmission de données sur lequel le système de gestion 42 du réseau d'opérateur 14 n'a pas une complète visibilité. Par exemple dans le cas de la figure 1 , le terminal client 26 est relié :
- au serveur 10 par l'intermédiaire du réseau à haut débit 28, du réseau d'opérateur 14 et du réseau à haut débit 12, et
- au serveur 18 par l'intermédiaire du réseau à haut débit 28, du réseau d'opérateur 14 et du réseau local privé 20. II est donc relié aux serveurs 10 et 18 par l'intermédiaire d'un réseau de transmission de données sur lequel le système de gestion 42 a une complète visibilité. En revanche, le terminal client 32 est relié :
- au serveur 10 par l'intermédiaire du réseau Internet 34, du réseau d'opérateur 14 et du réseau à haut débit 12, et
- au serveur 18 par l'intermédiaire du réseau Internet 34, du réseau d'opérateur 14 et du réseau local privé 20.
Il est donc relié aux serveurs 10 et 18 par l'intermédiaire d'un réseau de transmission de données sur lequel le système de gestion 42 n'a pas une complète visibilité, à cause du réseau Internet 34.
Il est donc possible de distinguer quatre configurations d'attaques de déni de service DNS :
- première configuration : le terminal client est relié au serveur par l'intermédiaire d'un réseau sur lequel le système de gestion 42 a une visibilité complète, et les attaques de déni de service DNS sont simples ;
- deuxième configuration : le terminal client est relié au serveur par l'intermédiaire d'un réseau sur lequel le système de gestion 42 a une visibilité complète, et les attaques de déni de service DNS sont récursives ;
- troisième configuration : le terminal client est relié au serveur par l'intermédiaire d'un réseau sur lequel le système de gestion 42 n'a pas une visibilité complète, et les attaques de déni de service DNS sont simples ; et
- quatrième configuration : le terminal client est relié au serveur par l'intermédiaire d'un réseau sur lequel le système de gestion 42 n'a pas une visibilité complète, et les attaques de déni de service DNS sont récursives. Dans la première configuration d'attaques, le procédé selon l'invention ne s'applique pas, puisqu'à chaque émission d'une requête de fourniture de service DNS l'installation est capable de vérifier d'elle-même que l'adresse source indiquée dans cette requête correspond bien à l'adresse IP de son émetteur. Cette vérification est réalisée par un serveur, connu sous le nom de serveur BRAS (de l'anglais "BRoadband Access Server"), disposé notamment dans le réseau à haut débit 28 et aux données duquel le système de gestion 42 de l'opérateur a accès.
Dans la deuxième configuration d'attaques, on applique le procédé précédemment décrit en référence à la figure 2.
De façon plus précise, lors de l'étape 104, on vérifie pour chaque paquet de données destiné au serveur éventuellement attaqué et intercepté par l'équipement intermédiaire : - le numéro de port source ;
- le numéro de port destination ;
- la nature du protocole utilisé au niveau de la couche application.
Lors de l'étape 106 de test suivante, si le numéro de port source et le numéro de port destination ont tous les deux la valeur 53, qui est la valeur de port utilisée pour Ia transmission de paquets relatifs à des services DNS, et si le protocole utilisé au niveau de la couche application est identifié comme étant le protocole DNS, alors on décide que le serveur visé est bien victime d'attaques de déni de service DNS. Puisqu'on est dans une configuration d'attaques récursives, les paquets participant à ces attaques concernent des requêtes frauduleuses de fourniture de service DNS.
Les étapes 104 et 106 sont exécutées par l'équipement intermédiaire 16 si le serveur attaqué est le serveur 10 et par l'équipement intermédiaire 22 si le serveur attaqué et le serveur 18.
Dans cette deuxième configuration d'attaques également, l'équipement intermédiaire ayant procédé à l'étape de vérification 104 et à l'étape de test 106 identifie l'émetteur des requêtes frauduleuses DNS et éventuellement l'adresse demandée dans ces requêtes, puis transmet ces données au système de gestion 42. Cet émetteur et cette adresse demandée sont donc fichés par le système de gestion 42
Dans ce cas, le critère prédéterminé utilisé par l'équipement intermédiaire lors de l'étape de test 114 pour interrompre la transmission d'un paquet de données destiné au serveur attaqué est lié à l'identité de l'émetteur du paquet intercepté et éventuellement à l'adresse demandée faisant l'objet de la requête. Si le paquet intercepté est émis par l'émetteur fiché par le système de gestion 42 et éventuellement s'il concerne l'adresse demandée fichée par Ie système de gestion 42, la transmission de ce paquet de données est interrompue. Sinon, il parvient à son destinataire.
Dans la troisième configuration d'attaques, on applique le procédé précédemment décrit en référence à la figure 2.
De façon plus précise, lors de l'étape 104, on vérifie pour chaque paquet de données destiné au serveur éventuellement attaqué et intercepté par l'équipement intermédiaire :
- le numéro de port source ;
- Ia nature du protocole utilisé au niveau de la couche application.
Lors de l'étape 106 de test suivante, si le numéro de port source a la valeur 53 et si le protocole utilisé au niveau de la couche application est identifié comme étant Ie protocole DNS, alors on décide que Ie serveur visé est bien victime d'attaques de déni de service DNS. Puisqu'on est dans une configuration d'attaques simples, les paquets participant à ces attaques concernent des réponses à des requêtes frauduleuses de fourniture de service DNS.
Les étapes 104 et 106 sont exécutées par l'équipement intermédiaire 16 si le serveur attaqué est le serveur 10 et par l'équipement intermédiaire 22 si le serveur attaqué et le serveur 18.
Dans cette troisième configuration d'attaques également, l'équipement intermédiaire ayant procédé à l'étape de vérification 104 et à l'étape de test 106 identifie les numéros de transaction de chaque requête DNS émise par le serveur attaqué et transmet ces numéros de transaction au système de gestion 42 qui gère une liste de numéros de transaction de requêtes émises par le serveur attaqué.
Les numéros de transaction de cette liste correspondent à des numéros de requêtes légitimes émises par le serveur attaqué.
La liste est mémorisée et tenue à jour par le système de gestion ou l'équipement intermédiaire. Ainsi, cette liste évolue en fonction des requêtes légitimes émises par le serveur.
Dans ce cas, le critère prédéterminé utilisé par l'équipement intermédiaire lors de l'étape de test 114 pour interrompre la transmission d'un paquet de données destiné au serveur attaqué est lié au numéro de transaction du paquet intercepté. Si le paquet intercepté a un numéro de transaction qui est dans la liste des numéros de transaction gérés par le système de gestion 42, il est transmis au serveur attaqué, puisqu'il s'agit alors d'une réponse légitime à une requête émise par ce dernier. Sinon la transmission de ce paquet de données est interrompue.
Dans la quatrième configuration d'attaques, on applique le procédé précédemment décrit en référence à la figure 2.
De façon plus précise, lors de l'étape 104, on vérifie pour chaque paquet de données destiné au serveur éventuellement attaqué et intercepté par l'équipement intermédiaire :
- le numéro de port source ; - la nature du protocole utilisé au niveau de la couche application.
Lors de l'étape 106 de test suivante, si le numéro de port source a la valeur 53 et si le protocole utilisé au niveau de la couche application est identifié comme étant le protocole DNS, alors on décide que le serveur visé est bien victime d'attaques de déni de service DNS. Puisqu'on est dans une configuration d'attaques récursives, les paquets participant à ces attaques concernent des requêtes frauduleuses de fourniture de service DNS. Les étapes 104 et 106 sont exécutées par l'équipement intermédiaire 16 si le serveur attaqué est le serveur 10 et par l'équipement intermédiaire 22 si le serveur attaqué et le serveur 18.
Dans cette quatrième configuration d'attaques également, l'équipement intermédiaire ayant procédé à l'étape de vérification 104 et à l'étape de test 106 identifie l'adresse demandée dans les requêtes frauduleuses, puis transmet ces données au système de gestion 42. Cette adresse demandée, qui est une adresse gérée par le serveur attaqué, est donc fichée par le système de gestion 42.
Dans ce cas, le critère prédéterminé utilisé par l'équipement intermédiaire lors de l'étape de test 114 pour interrompre la transmission d'un paquet de données destiné au serveur attaqué est lié à l'adresse demandée faisant l'objet de la requête du paquet intercepté. Si le paquet intercepté concerne l'adresse demandée fichée par le système de gestion 42, la transmission de ce paquet de données est interrompue. Sinon, il parvient à son destinataire. II apparaît clairement qu'un procédé de protection telle que décrit précédemment permet de protéger efficacement un serveur attaqué contre des attaques de déni de service DNS, sans pour autant neutraliser celui-ci.

Claims

REVENDICATIONS
1. Procédé de protection d'un serveur (10, 18) contre des attaques de déni de service DNS, dans lequel : - on détecte (100, 102, 104) des attaques de déni de service DNS visant le serveur,
- on intercepte (110) les paquets de données à destination du serveur, caractérisé en ce que si un paquet intercepté a un numéro de transaction qui n'est pas dans une liste de numéros de transaction de requêtes émises par le serveur, alors on interrompt (116) la transmission de ce paquet de données vers le serveur.
2. Procédé de protection d'un serveur (10, 18) selon la revendication 1 , dans lequel lors de l'étape (100, 102, 104) de détection des attaques de déni de service DNS :
- on détecte (100) un trafic anormal à destination du serveur ;
- on extrait (104) un numéro de port source contenu dans des paquets de données interceptés ;
- on détermine (104) la nature du protocole utilisé au niveau de la couche application dans les paquets de données interceptés.
3. Procédé de protection d'un serveur (10, 18) selon la revendication 2, dans lequel, lors de l'étape (100, 102, 104) de détection des attaques de déni de service DNS, on extrait (104) un numéro de port destination contenu dans les paquets de données interceptés.
4. Dispositif (16, 22, 30, 40) de protection d'un serveur (10, 18) contre des attaques de déni de service DNS, comportant des moyens d'interception de paquets de données à destination du serveur, caractérisé en ce qu'il comporte en outre des moyens d'interruption de transmission d'un paquet de données intercepté vers le serveur si le paquet intercepté a un numéro de transaction qui n'est pas dans une liste de numéros de transaction de requêtes émises par le serveur.
5. Système de protection d'un serveur (10, 18) contre des attaques de déni de service DNS, comportant un serveur susceptible d'être attaqué par un client (26, 32) et au moins un équipement intermédiaire (16, 22, 30, 40), caractérisé en ce l'équipement intermédiaire (16, 22, 30, 40) est formé par un dispositif de protection selon la revendication 4.
6. Système de protection d'un serveur selon la revendication 5, comprenant des moyens (42) de gestion de la liste de numéros de transactions, les numéros de transaction étant transmis par chaque dispositif de protection selon la revendication 4.
7. Système de protection d'un serveur selon la revendication 5 ou 6, dans lequel l'équipement intermédiaire (16, 22, 30, 40) est un pare-feu disposé entre le serveur (10, 18) et un réseau d'accès du client au serveur.
PCT/FR2005/001777 2004-07-09 2005-07-08 Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns WO2006013292A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05788637A EP1774751A1 (fr) 2004-07-09 2005-07-08 Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns
US11/631,673 US20080028073A1 (en) 2004-07-09 2005-07-08 Method, a Device, and a System for Protecting a Server Against Denial of DNS Service Attacks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0407705 2004-07-09
FR0407705 2004-07-09

Publications (1)

Publication Number Publication Date
WO2006013292A1 true WO2006013292A1 (fr) 2006-02-09

Family

ID=34950826

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/001777 WO2006013292A1 (fr) 2004-07-09 2005-07-08 Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns

Country Status (3)

Country Link
US (1) US20080028073A1 (fr)
EP (1) EP1774751A1 (fr)
WO (1) WO2006013292A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101184094B (zh) * 2007-12-06 2011-07-27 北京启明星辰信息技术股份有限公司 一种适于局域网环境的网络节点扫描检测方法和系统

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007050244A2 (fr) 2005-10-27 2007-05-03 Georgia Tech Research Corporation Procede et systeme pour detecter et reagir a des attaques de reseaux
US7970878B1 (en) * 2005-11-16 2011-06-28 Cisco Technology, Inc. Method and apparatus for limiting domain name server transaction bandwidth
US8874723B2 (en) * 2006-12-28 2014-10-28 Nec Corporation Source detection device for detecting a source of sending a virus and/or a DNS attack linked to an application, method thereof, and program thereof
US10027688B2 (en) * 2008-08-11 2018-07-17 Damballa, Inc. Method and system for detecting malicious and/or botnet-related domain names
US8868707B2 (en) * 2009-06-16 2014-10-21 Oracle International Corporation Adaptive write-back and write-through caching for off-line data
US8489637B2 (en) * 2009-11-19 2013-07-16 International Business Machines Corporation User-based DNS server access control
US8578497B2 (en) 2010-01-06 2013-11-05 Damballa, Inc. Method and system for detecting malware
US8826438B2 (en) 2010-01-19 2014-09-02 Damballa, Inc. Method and system for network-based detecting of malware from behavioral clustering
US9634993B2 (en) 2010-04-01 2017-04-25 Cloudflare, Inc. Internet-based proxy service to modify internet responses
US9049247B2 (en) 2010-04-01 2015-06-02 Cloudfare, Inc. Internet-based proxy service for responding to server offline errors
US9516058B2 (en) 2010-08-10 2016-12-06 Damballa, Inc. Method and system for determining whether domain names are legitimate or malicious
WO2012094675A2 (fr) * 2011-01-07 2012-07-12 Seven Networks, Inc. Système et procédé de réduction du trafic sur les réseaux de mobiles utilisé pour les requêtes aux systèmes de noms de domaine (dns)
US8631489B2 (en) 2011-02-01 2014-01-14 Damballa, Inc. Method and system for detecting malicious domain names at an upper DNS hierarchy
US10547674B2 (en) 2012-08-27 2020-01-28 Help/Systems, Llc Methods and systems for network flow analysis
US10084806B2 (en) 2012-08-31 2018-09-25 Damballa, Inc. Traffic simulation to identify malicious activity
US9680861B2 (en) 2012-08-31 2017-06-13 Damballa, Inc. Historical analysis to identify malicious activity
US9166994B2 (en) 2012-08-31 2015-10-20 Damballa, Inc. Automation discovery to identify malicious activity
US9894088B2 (en) 2012-08-31 2018-02-13 Damballa, Inc. Data mining to identify malicious activity
US20140282867A1 (en) * 2013-03-15 2014-09-18 Hewlett-Packard Development Company, L.P. Device local reputation score cache
US9571511B2 (en) 2013-06-14 2017-02-14 Damballa, Inc. Systems and methods for traffic classification
US9930065B2 (en) 2015-03-25 2018-03-27 University Of Georgia Research Foundation, Inc. Measuring, categorizing, and/or mitigating malware distribution paths
US10623425B2 (en) 2017-06-01 2020-04-14 Radware, Ltd. Detection and mitigation of recursive domain name system attacks
US10938851B2 (en) 2018-03-29 2021-03-02 Radware, Ltd. Techniques for defense against domain name system (DNS) cyber-attacks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0743777A2 (fr) * 1995-05-18 1996-11-20 Sun Microsystems, Inc. Système pour filtrage de paquets de données dans un interface de réseau d'ordinateurs
US20010052007A1 (en) * 2000-01-21 2001-12-13 Nec Corporation DNS server filter
WO2002037755A2 (fr) * 2000-11-02 2002-05-10 Asta Networks, Inc. Détection et prévention de l'utilisation d'un domaine de réseau comme source pour un trafic réseau indésirable
US20020083175A1 (en) * 2000-10-17 2002-06-27 Wanwall, Inc. (A Delaware Corporation) Methods and apparatus for protecting against overload conditions on nodes of a distributed network

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6775704B1 (en) * 2000-12-28 2004-08-10 Networks Associates Technology, Inc. System and method for preventing a spoofed remote procedure call denial of service attack in a networked computing environment
US7958237B2 (en) * 2001-01-23 2011-06-07 Pearl Software, Inc. Method for managing computer network access
US6907525B2 (en) * 2001-08-14 2005-06-14 Riverhead Networks Inc. Protecting against spoofed DNS messages
US7626940B2 (en) * 2004-12-22 2009-12-01 Intruguard Devices, Inc. System and method for integrated header, state, rate and content anomaly prevention for domain name service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0743777A2 (fr) * 1995-05-18 1996-11-20 Sun Microsystems, Inc. Système pour filtrage de paquets de données dans un interface de réseau d'ordinateurs
US20010052007A1 (en) * 2000-01-21 2001-12-13 Nec Corporation DNS server filter
US20020083175A1 (en) * 2000-10-17 2002-06-27 Wanwall, Inc. (A Delaware Corporation) Methods and apparatus for protecting against overload conditions on nodes of a distributed network
WO2002037755A2 (fr) * 2000-11-02 2002-05-10 Asta Networks, Inc. Détection et prévention de l'utilisation d'un domaine de réseau comme source pour un trafic réseau indésirable

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101184094B (zh) * 2007-12-06 2011-07-27 北京启明星辰信息技术股份有限公司 一种适于局域网环境的网络节点扫描检测方法和系统

Also Published As

Publication number Publication date
EP1774751A1 (fr) 2007-04-18
US20080028073A1 (en) 2008-01-31

Similar Documents

Publication Publication Date Title
WO2006013292A1 (fr) Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service dns
US9444835B2 (en) Method for tracking machines on a network using multivariable fingerprinting of passively available information
EP1733539B1 (fr) Dispositif et procédé de détection et de prévention d'intrusions dans un réseau informatique
US7428590B2 (en) Systems and methods for reflecting messages associated with a target protocol within a network
US7478429B2 (en) Network overload detection and mitigation system and method
EP2526670B1 (fr) Procede et systeme de prevention d'empoisonnement de caches dns
US7818565B2 (en) Systems and methods for implementing protocol enforcement rules
US20180159825A1 (en) Network host provided security system for local networks
US20040088423A1 (en) Systems and methods for authentication of target protocol screen names
US20040109518A1 (en) Systems and methods for a protocol gateway
FR2844941A1 (fr) Demande d'acces securise aux ressources d'un reseau intranet
JP2010508598A (ja) ストリング分析を利用する１つまたは複数のパケット・ネットワークでの望まれないトラフィックを検出する方法および装置
FR2852754A1 (fr) Systeme et methode de protection d'un reseau de transmission ip contre les attaques de deni de service
EP1902563A2 (fr) Detection d une intrusion par detournement de paquets de donnees dans un reseau de telecommunication
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
EP2807815B1 (fr) Système et procédö de controle d'une requête dns
WO2004086719A2 (fr) Systeme de transmission de donnees client/serveur securise
WO2007003818A1 (fr) Procede de filtrage par couplage multi-protocolaire sur la base du protocole dns.
EP3087719B1 (fr) Procédé de ralentissement d'une communication dans un réseau
EP1766934A1 (fr) Procede, programme d'ordinateur, dispositif et systeme de protection d'un serveur contre des attaques de deni de service.
WO2015197978A1 (fr) Procede de protection d'un routeur contre des attaques
FR2800224A1 (fr) Procede et systeme de mise en antememoire de donnees http transportees avec des donnees de socks dans des datagrammes ip
EP1471713B1 (fr) Procédé et système de contrôle d'accès à des sites internet au moyen d'un serveur cache
Wood et al. Intrusion detection: Visualizing attacks in ids data
EP1704682A1 (fr) Systeme de communication entre reseaux ip prives et publics

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005788637

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 11631673

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2005788637

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11631673

Country of ref document: US