WO2021176166A1 - Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie - Google Patents

Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie Download PDF

Info

Publication number
WO2021176166A1
WO2021176166A1 PCT/FR2021/050338 FR2021050338W WO2021176166A1 WO 2021176166 A1 WO2021176166 A1 WO 2021176166A1 FR 2021050338 W FR2021050338 W FR 2021050338W WO 2021176166 A1 WO2021176166 A1 WO 2021176166A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
address
domain name
server
uncertified
Prior art date
Application number
PCT/FR2021/050338
Other languages
English (en)
Inventor
Bertrand Bouvet
Original Assignee
Orange
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 Orange filed Critical Orange
Priority to EP21714640.6A priority Critical patent/EP4115582A1/fr
Priority to US17/908,083 priority patent/US20230094785A1/en
Publication of WO2021176166A1 publication Critical patent/WO2021176166A1/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/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/457—Network directories; Name-to-address mapping containing identifiers of data entities on a computer, e.g. file names
    • 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
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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

Definitions

  • the invention relates to the general field of telecommunications networks, and more particularly to DNS ("Domain Name System”) technology.
  • DNS Domain Name System
  • an Internet site such as a merchant site
  • the latter will conventionally use an Internet browser present on his terminal.
  • the browser or the terminal can query a domain name server, also called a DNS server (in English "Domain Name System"), in order to establish a correspondence between the URL (in English "Uniform Resource Locator ”) of the merchant site, for example entered by the user, and the IP (Internet Protocol) address of the server that hosts it.
  • DNS resolution This mechanism is called "DNS resolution”. Indeed, on the Internet, it is the IP address that is used to communicate between the various terminals of the network.
  • the messages exchanged with the DNS servers are so-called "unencrypted" messages, that is to say without encryption.
  • This feature enables Internet service providers who operate DNS servers to provide their customers with additional services such as parental control services or malicious website detection services. Concretely, these services are based on URLs for which a match with an IP address is requested, for example to perform URL filtering or to send a particular message to the client.
  • these public DNS servers can also lead to an increase in international IP traffic.
  • these public DNS servers hosted for the most part in the United States, do not allow the use of local “DNS cache” (memory which stores the “Domain names - IP addresses” pairs which have just been resolved, in order to find them more quickly), available for example within the network of an Internet access provider, therefore valid for all of its customers, or even within a domestic gateway of an access provider Internet, therefore valid for all terminals and applications managed by it, which would make it possible to have a substantial reduction in DNS traffic and a lower energy / environmental impact.
  • DNS cache memory which stores the “Domain names - IP addresses” pairs which have just been resolved, in order to find them more quickly
  • the use of Public DNS also poses a problem regarding the protection of personal data. A malicious actor offering such a service could retrieve sensitive user data and resell it without users being aware of it.
  • the invention improves the state of the art and proposes for this purpose a method of notifying, by a notification device, of the use, by at least one terminal, of an uncertified domain name server, the method being characterized in that it comprises: a step of receiving a request from said at least one terminal, said request comprising at least one parameter corresponding to a first address allowing communication with a server;
  • a step of searching for said first address in a list said list comprising at least one address obtained from at least one certified domain name server;
  • the method will be able to detect the use, by a user's terminal, of an uncertified domain name server.
  • the process Upon receipt of a request from the terminal, the process will verify that a DNS resolution has been performed by a certified DNS server.
  • the method will retrieve from the received request, a parameter such as the address of the recipient server and verify that this address is present in a list comprising the addresses provided to the terminal by the certified DNS servers. This list is, for example, filled in over time during DNS resolutions. If the address of the recipient server is not present in the list, then the method will generate a notification informing that the terminal is using an uncertified domain name server. Otherwise, it means that the DNS resolution has been successfully performed by a certified DNS server and no notification is generated.
  • certified DNS server is understood to mean the domain name servers which are said to be "trusted” and selected by an authorized organization such as, for example, the Internet access provider of the user of the terminal.
  • an authorized organization such as, for example, the Internet access provider of the user of the terminal.
  • the selection criteria relating to the concept of trust may be specific to each organization.
  • certified DNS servers may be different depending on the organization.
  • a list is understood to mean a series of elements, ordered or not, distinct or not, making it possible to obtain a structured set such as a list of elements, for example time-stamped, IP address, domain name, address. MAC, port number or protocol.
  • This list is for example a DNS cache capable of storing the “domain name - IP address” pairs which have just been resolved for a terminal or the applications executed on the terminal.
  • address is meant a sequence of characters and / or binary data which is used to identify a terminal or one of its electronic modules such as for example a server, a home gateway, a smartphone (in English “smart phone”), a computer, a connected object, a network card or any other terminal connected to a network such as for example a URI.
  • server any terminal connected to a network such as an Internet server, a smartphone (in English “smart phone”), a computer, a connected object, etc.
  • terminal any terminal connected to a network or application running on a terminal capable of communicating with another terminal.
  • request is meant any message sent by a terminal or by an application running on a terminal to a server such as an HTTP message, an IP packet, etc.
  • domain name server is meant a DNS server (“Domain Name System”) or a so-called “Resolver DNS” server which includes means for periodically consulting the root DNS servers (.org, .corn, .net, etc. ) and those which are under the administrative control of different entities (companies, states, associations, etc.) as well as DNS caching means.
  • DNS server Domain Name System
  • Resolver DNS resolver DNS
  • a method as described above is characterized in that the search and notification steps are conditional on the result of a second search step for said at least a first one. address in a second list, said second list comprising the destination addresses of the requests sent by said at least one terminal.
  • this embodiment makes it possible to condition the search and notification steps to the presence in a list of the destination address of the request sent by the user's terminal.
  • This list can for example be a list of IP addresses already known to a home gateway such as a NAT (“Network Address Translation”) or NAPT (“Network Address Port Translation) table in the case of the use of the. IPV4 protocol or even an IPV6 packet routing table.
  • NAT Network Address Translation
  • NAPT Network Address Port Translation
  • This can also be, for example, a NAPT table of a network equipment of CGN (Carrier Grade NAT) type which provides an IPV4-IPV6 tunnel function.
  • This embodiment of the invention also makes it possible to verify that the destination address of the request sent by the user's terminal, such as for example a IP address, is present in a list stored in digital storage such as a database, file, or memory.
  • digital storage such as a database, file, or memory.
  • the digital storage space can host data linked to uncertified Public DNS servers (blacklist).
  • a method as described above is characterized in that the search step further comprises the search for a second address associated with said first address in said first list , said second address being a parameter of said request and corresponding to an address of said at least one terminal, said first list comprising at least one address of said at least one terminal obtained from said at least one terminal associated with at least one address obtained from said at least one certified domain name server.
  • this embodiment makes it possible to take into account the case where several terminals are managed by the notification device and that for example one of them uses an uncertified DNS server.
  • the resolution of a domain name could be carried out by a certified DNS server on behalf of one of the terminals before a similar request was made by the terminal using the uncertified DNS server. Consequently, we will have in the list, the address of the server corresponding to the domain name sought by the terminal using the uncertified DNS server. The server address is therefore not sufficient in this case to detect the use of an uncertified DNS server. To do this, a second address such as a MAC address or an IP address or a unique identifier of the IMEI (International Mobile Equipment Identifier) type associated with the terminal is necessary. Thus, this second address makes it possible to find in the list the DNS resolutions of a particular terminal.
  • IMEI International Mobile Equipment Identifier
  • a method as described above is characterized in that the search step further comprises the search for 'at least one communication port number associated with said address in said first list, said at least one communication port number corresponding to a parameter of said request, said first list comprising at least one communication port number obtained from said at least one terminal associated with at least one address obtained from said at least one certified domain name server.
  • this embodiment makes it possible to take into account the case where several applications are executed on the terminal of P user with, for example, for one of them the use of an uncertified DNS server. Indeed, the resolution of a domain name could be carried out by a certified DNS server before a similar request was made by the application using the uncertified DNS server.
  • the address of the server corresponding to the domain name sought by the application using the uncertified DNS server is therefore, in this case, not sufficient to detect the use of an uncertified DNS server.
  • the source communication port number corresponding to the application using the uncertified DNS server is required. Indeed, in the case of a TCP / IP communication, the TCP / IP stack of the terminal cannot at the same time assign the same source port number to different applications, otherwise the TCP / IP stack will not know to which application. route incoming IP traffic. The method can thus notify the use by an application of the terminal of an uncertified DNS server.
  • a method as described above is characterized in that the notification step comprises a redirection of said request to at least one Internet page.
  • This embodiment of the invention makes it possible to inform the user via the display of a web page on his terminal that he is using an uncertified domain name server with the risks involved.
  • a method as described above is characterized in that the notification step comprises sending a message to said first terminal.
  • This embodiment of the invention makes it possible to inform the user via for example an SMS, an RCS message, an email or a notification message sent for example by means of an FCM (Firebase Cloud Messaging) type solution which 'he is using an uncertified domain name server with the risks involved.
  • FCM Firebase Cloud Messaging
  • a method as described above is characterized in that the notification step comprises sending a message to an assistance service.
  • This embodiment of the invention makes it possible for example to inform the customer service of the Internet access provider of the user of the first terminal that the latter is using an uncertified DNS server. The customer service technician will then be able to more easily understand the source of a malfunction observed by the user on one of his services based on DNS resolutions such as parental controls and help the user to solve the problem.
  • a method as described above is characterized in that the notification step is followed by a step of filtering requests from said first terminal.
  • This embodiment of the invention allows, when the user of the first terminal uses an uncertified DNS server, to filter the requests sent by the first terminal.
  • the filtering can be partial or total, that is to say that the filtering can block all the requests or let some of them pass, for example those intended for the online assistance of the Internet service provider of the Internet. user of the first terminal.
  • the filtering can also correspond to putting requests on hold for a period of time (for example one second) causing for example a slowing down of Internet flows at the first terminal.
  • a method as described above is characterized in that the notification step is followed by a step of modifying the requests sent by said first terminal.
  • This embodiment of the invention makes it possible, for example, when the user of the first terminal uses an uncertified DNS server, to "mark" the requests sent by the first terminal.
  • the network equipment which receives these requests can then apply specific processing rules such as, for example, accounting, unsupported, blocking, specific routing, or even traffic duplication.
  • the invention also relates to a device for notifying the use by a first terminal of an uncertified domain name server, and characterized in that the device comprises: a module for receiving a request from said at least one terminal, said request comprising at least one parameter corresponding to a first address allowing communication with a server;
  • a module for finding said first address in a list said list comprising at least one address obtained from at least one certified domain name server;
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or more generally. to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the invention also relates to a gateway characterized in that it comprises a device for notifying the use by a first terminal of an uncertified domain name server.
  • a gateway is understood to mean a device making it possible to connect two computer networks of different types, such as, for example, a local network and an Internet network, such as a modem router, a mobile phone with "connection sharing" mode activated, etc.
  • the invention also relates to a server characterized in that it comprises a device for notifying the use by a first terminal of an uncertified domain name server.
  • the invention also relates to a terminal characterized in that it comprises a device for notifying the use by a first terminal of an uncertified domain name server.
  • this embodiment makes it possible to take into account the case where the terminal has, for example, a DNS cache.
  • the invention also relates to a computer program comprising instructions for implementing the above method according to any one of the particular embodiments described above, when said program is executed by a processor.
  • the method can be implemented in various ways, in particular in wired form or in software form.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable form.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the recording media mentioned above can be any entity or device capable of storing the program.
  • the medium may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk.
  • the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded from an Internet-type network.
  • the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.
  • This device of a device for notifying the use by a first terminal of an uncertified domain name server and this computer program have characteristics and advantages similar to those described above in relation to the method of notification of the. use by a first terminal of an uncertified domain name server.
  • FIG. 1 represents the hardware architecture of a device for notifying the use by a first terminal of an uncertified domain name server
  • Figure 2 shows in the form of a flowchart the main steps of a method of notification of use by a first terminal of an uncertified domain name server.
  • Figure 1 shows the hardware architecture of a DNU device for notification of use by a first terminal of an uncertified domain name server according to the invention.
  • this device has the hardware architecture of a computer. It comprises in particular a processor PROC, a random access memory MV, a read-only memory MEM and a non-volatile flash memory MF. Such means are known per se and are not described in more detail here.
  • the read only memory constitutes a recording medium in accordance with the invention, readable by the processor PROC and on which is recorded here a computer program PG in accordance with the invention, this program comprising instructions for implementing the steps of the method of notification of the use by a first terminal of an uncertified domain name server as described above, when the program is executed by the processor PROC.
  • the code instructions of the computer program PG are for example loaded into a memory before being executed by the processor PROC.
  • the processor PROC of the processing unit UT notably implements the steps of the method of notification of the use by a first terminal of a non-certified domain name server according to any one of the particular embodiments described in relation with FIG. 2, according to the instructions of the computer program PG.
  • the DNU device comprises a COM communication module configured to establish communications with, for example, an IP network. This COM communication module is used to receive requests from a user's terminal.
  • This terminal is for example a smartphone (in English "smart phone"), a computer, a tablet, the on-board computer of a connected car or a connected object (IOT for Internet Of Things) or any terminal capable of connecting to a network, for example of the Internet type.
  • a parameter such as for example an address such as an IP address, a MAC address, a communication port number or a transport protocol, which allows communication with a second terminal such as an Internet server hosting services and / or web pages .
  • the DNU device further comprises a RECH module which will search for the address received in a list, for example stored in a database, a file, or a memory.
  • the device further comprises a NOTIF module capable of notifying that a terminal is using an uncertified domain name server if, for example, the address received is not in the list.
  • the RECH module can also be used to search for the address received from a list comprising the addresses of uncertified domain name servers (black list). If the address is present in the list then the user's terminal is using an uncertified domain name server. A notification can then be issued by the device informing about the use by the user terminal of an uncertified domain name server.
  • the device may include a man-machine interface making it possible to render the notification to the user visually or by voice.
  • the RECH module can also be used to search for the address received in a list of NAT or NAPT type in the case of an IPV4 packet or else in a routing list of IPV6 packets for example. hosted within a gateway or more generally a fixed / mobile network access point.
  • the COM module can be used to send the notification to a terminal such as for example the user's terminal.
  • the notification can also be sent internally to the machine hosting the device, for example to a second communication module such as a second network card.
  • the device comprises a database configured to store data such as a source IP address, a source port, the transport protocol, the destination IP address and the destination port. requests sent and received by the COM module.
  • the device comprises a second database configured to store data linked to the name servers of non-certified domain (black list) or data related to certified domain name servers (white list).
  • FIG. 2 consists of a terminal T able to send and receive requests to and from the DNU device and of a server S able to process the requests sent by the terminal T via the DNU device.
  • the DNU device executing the method of notification of use by a first terminal of an uncertified domain name server is a gateway supporting the IPv4 protocol
  • the server S is an uncertified domain name server
  • the terminal T is for example a smartphone (in English “smart phone”), a computer, a tablet, or a connected object (IOT for Internet Of Things) located in the managed local network by the DNU gateway.
  • step E10 an application executed on the terminal T sends a DNS resolution request to the server S with the IP address of the request destination, the IP address of the server S.
  • step E20 the request is received by the gateway via its COM communication module.
  • the destination IP address does not correspond to its IP address space, i.e. to the IP addresses generated for the terminals located locally and managed by the gateway via for example a DHCP module, the request is redirected to an N module of the gateway.
  • the module N makes it possible for example to store in a table or a list located for example in a memory, a file or a database, data such as the source IP address of a request coming from a terminal, c 'i.e.
  • the method can condition the passage to step E21 on the presence of the destination IP address in the table managed by the module N. If this is present, the method then goes to l 'step E26.
  • step E21 the method will search in a list located for example in a memory, a file or a database of the gateway, the destination IP address of the request.
  • This list is for example a DNS cache (CR) which will store all the DNS resolution requests made to certified DNS servers originating from the terminals located in the local network of the gateway.
  • This search can for example be done via a "Whois lookup" type request with the IP address of the S server as a parameter.
  • step E31 the DNS cache (CR) retrieves the search result and sends it to module N in step E32. The result is then recovered and processed by the module N in step E22.
  • IP address of server S is present in the DNS cache, this means that the application has used the FQDN (Fully Qualified Domain Name) address of server S to contact it.
  • FQDN Frully Qualified Domain Name
  • This also indicates that a DNS resolution has previously been carried out by a certified domain name server, for example the domain name server used by the terminal itself.
  • a certified domain name server for example the domain name server used by the terminal itself.
  • special processing of the request such as parental control type filtering, could then be carried out beforehand by the certified domain name server.
  • IP address of server S In the event that the IP address of server S is not present in the DNS cache, it means that no DNS resolution via a certified domain name server has returned the IP address of server S. In d In other words, the IP address was retrieved by the application through an uncertified domain name server. It can also mean that the IP address of the uncertified DNS server is known to the application and in this case DNS resolution is not necessary.
  • the method can, if the request is for example an HTTP / HTTPS type request, go to step E23.
  • the method will then generate an HTTP / HTTPS redirection request via a standardized response code of the 3XX series.
  • the redirection address can for example be an information web page hosted on a server on the Internet or at the gateway. This web page thus makes it possible to notify the user of the use of a DNS not certified by the application. Note that the user can, following consultation of the information web page, deactivate the notification of the use of an uncertified DNS and / or the redirection via for example a parameter of the gateway accessible via a page dedicated web.
  • the method can go to step E23 as a function of a number of requests intended for the server S.
  • the redirection is activated as a function of a number of requests to the server S. For example, every n requests (for example 10) the redirection is activated and then deactivated at the request n + 1. If the redirection is deactivated, then the process goes directly from step E22 to step E26.
  • the redirection can be deactivated for a predetermined period (for example one day / one week / one or more months ). If the redirection is deactivated, then the process goes directly from step E22 to step E26.
  • a message giving information concerning the gateway and / or the terminal T running the application configured to use a non-certified domain name server is sent to a server such as for example a server of the Internet access provider of the user of the terminal T.
  • This message is used to notify a third party of the use of a DNS not certified by the application.
  • the message can contain all kinds of data such as the day, date, MAC address of the terminal and / or the gateway, the IP address assigned to the terminal on the local network, the IP address assigned to the gateway by the Internet service provider, the IP address of the server S, etc.
  • the notification of the use of a DNS not certified by the application is returned by a human interface - bridge machine.
  • This interface is for example a diagram representing the terminals present at the level of the local network managed by the gateway.
  • the diagram can be viewed for example via a screen located on the gateway or via an Internet browser of a terminal connected to the gateway rendering a web page generated at a web server running on the gateway.
  • the method can set up a filtering of the requests sent by the terminal T subsequent to the request sent in step E10.
  • the filtering can be partial or total, that is to say that the filtering can block all the requests or let some of them pass, for example those intended for the online assistance of the Internet service provider of the Internet. user of terminal T.
  • the filtering can also correspond to putting requests on hold for a period of time (for example one second) causing, for example, a slowing down of Internet flows at terminal T.
  • the method can modify the requests sent by the terminal T subsequent to the request sent in step E10 and intended for servers on the Internet network.
  • the modification can for example be a "marking" of all the requests sent by the terminal or only those sent by the application. Marking can be done, for example, by: using the 1st unused bit on the 3 bits of the "Indicator” field of the header of the IPv4 packet corresponding to the request; using one of the 2 unused bits of the IPV4 "Type of Service" header; the creation of a new IP V4 Public DNS option.
  • the servers and / or routers receiving the marked requests will be able to apply specific processing rules for these requests such as, for example, accounting, unsupported, blocking, specific routing, the implementation of quality policies. specific service, or duplication.
  • step E26 the method will modify the request by replacing the source IP address of the terminal by the IP address of the gateway, that is to say the IP address given to the internet gateway by a DHCP server from the Internet service provider and allowing communication with other terminals connected to the Internet network.
  • the source communication port number, i.e. of the terminal T present in the request can also be modified in step E26.
  • the request is then sent to the server S and is received by the latter in step E46.
  • the response follows the reverse path (E47, E27, E28) and is received at step E18 by the terminal T.
  • the method in step E21, can perform a search with the MAC address and / or the IP address of the terminal T as a parameter in addition to the destination IP address of the request. .
  • This embodiment makes it possible to take into account the case where several terminals are present in the local network managed by the DNU gateway. Indeed, the MAC address and / or the IP address will make it possible to determine the terminal which has requested a DNS resolution from a certified domain name server and to ensure that if there has previously been a DNS resolution stored in the CR cache for this IP address, it was indeed performed by this terminal and not another. Obviously this assumes that the MAC address and / or the IP address of the terminal which performs a DNS resolution is saved and associated with the DNS resolution in the CR cache before step E21, for example when requesting DNS resolution .
  • the method can in step E21 carry out a search with as a parameter the number of the communication source port used by an application of the terminal T to communicate in addition to the destination IP address of the request.
  • This embodiment makes it possible to take into account the case where several applications capable of requesting DNS resolutions are executed on the terminal T. Indeed, the communication source port number will make it possible to determine the application which requested a DNS resolution. to a certified domain name server and ensure that if there has previously been a DNS resolution stored in the CR cache for this IP address, it has been performed by this application on terminal T and not another on the same terminal T.
  • the source communication port number of the application which performs DNS resolution is saved and associated with the DNS resolution in the CR cache before step E21, for example when requesting DNS resolution.
  • the method can also use as a search parameter during step E21, the destination communication port number of the request and / or the transport protocol used and / or any data present in the message E10 such as than a level 3 or higher IP data.
  • the module N corresponds to an IPV6 packet routing module of the gateway.
  • the “Next Header” extension fields of the header of the IPv6 protocol can be used to mark the IP requests / packets coming from terminals or applications using a domain name server. not certified.
  • the marking can also be carried out via an “Options” field of the “HopByHopHeader” header or of the “DestinationOptionsHeader” Header for example by using TLV type coding
  • the invention also applies to a mobile access point, for example to a smartphone (in English "smart phone")
  • 4G or 5G acting as a WiFi access point for one or more terminals acting as a WiFi access point for one or more terminals.
  • the invention also applies to a terminal, for example a fixed or mobile terminal having a DNS cache function.
  • the invention also applies to a 4G / 5G mobile core network implemented by the PGW (Packet GateWay) equipment in the case of a 4G core network, or SMF (Session Management Function) / UPF (User Plane Function) in the case of a 5G core network.
  • PGW Packet GateWay
  • SMF Session Management Function
  • UPF User Plane Function
  • a request for example of the “Whois Lookup” type, can be sent by the IP traffic processing module of the PGW or SMF / UPF equipment, that is to say the module N, intended for the DNS CR cache of the PGW or of the SMF / UPF (with more or less parameters in the request to provide targeted information making it possible to detect the DNS resolutions previously operated by a terminal, an application of the terminal, depending on the application protocol, according to the transport protocol, ).
  • the invention also applies to a fixed or mobile access network implemented by the CGN (Carrier Grade NAT) equipment. This is the same process as that presented in support of FIG. 2.
  • the CGN equipment can integrate a DNS cache, the operation of which is identical to that presented previously. Therefore, the same process can be applied.
  • a request for example of the “Whois Lookup” type, can be sent by the IP traffic processing module of the CGN equipment, that is to say the N module, to destination of the DNS CR cache of the CGN (with more or less parameters in the request to provide targeted information making it possible to detect the DNS resolutions previously operated by a terminal, an application of the terminal, according to the application protocol, according to the transport protocol, ).

Landscapes

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

Abstract

L'invention concerne un procédé et un dispositif de notification, par un dispositif de notification, de l'usage, par au moins un terminal, d'un serveur de noms de domaine non certifié, le procédé étant caractérisé en ce qu'il comprend : - une étape de réception d'une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur; - une étape de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié; - une étape de notification, en fonction du résultat de la recherche, de l'usage, par ledit au moins un terminal, d'un serveur de noms de domaine non certifié.

Description

DESCRIPTION
Titre : Procédé et dispositif de détection de l’usage d’un serveur de noms de domaine non certifié.
1. Domaine de l'invention
L’invention se rapporte au domaine général des réseaux de télécommunications, et plus particulièrement à la technologie DNS (en anglais « Domain Name System »).
2. Art Antérieur
Lorsqu’un utilisateur souhaite accéder à un site Internet, comme par exemple un site marchand, celui-ci va classiquement utiliser un navigateur Internet présent sur son terminal. Pour accéder au site marchand, le navigateur ou le terminal peut interroger un serveur de noms de domaine, également appelé serveur DNS (en anglais « Domain Name System »), afin d'établir une correspondance entre l’URL (en anglais « Uniform Resource Locator ») du site marchand, par exemple saisie par l’utilisateur, et l’adresse IP (Internet Protocol) du serveur qui l’héberge. Ce mécanisme est appelé « résolution DNS ». En effet, sur Internet, c’est l’adresse IP qui est utilisée pour communiquer entre les différents terminaux du réseau.
Les messages échangés avec les serveurs DNS sont des messages dits « en clair », c’est-à- dire sans chiffrage. Cette caractéristique permet aux fournisseurs d’accès à Internet qui opèrent les serveurs DNS de proposer à leurs clients des services additionnels tels que des services de contrôle parental ou des services de détection de sites Internet malveillants. Concrètement, ces services se basent sur les URL pour lesquelles une correspondance avec une adresse IP est demandée pour par exemple réaliser un filtrage de l’URL ou envoyer un message particulier au client.
Depuis quelques années, certains acteurs proposent des serveurs DNS publics qui se substituent à ceux mis historiquement en place par les fournisseurs d’accès à Internet. A date près de 50% des résolutions DNS sont réalisées via ces serveurs DNS publics. Ce pourcentage est de plus en augmentation avec l’usage accru de protocole DNS sécurisé de type DoH (DNS over HTTP S avec la REC IETL 8484) ou DoT (DNS over TLS). En effet, certains navigateurs Internet permettent l’utilisation de ces protocoles avec par défaut la configuration possible par son utilisateur d’un serveur DNS public.
Si ces services de résolution DNS publics sont dans certains cas pertinents pour les utilisateurs (meilleur temps de réponse annoncé par exemple pour des jeux en réseau, chiffrement des requêtes et réponses DNS pour une meilleure sécurité, etc...), ils entraînent cependant la perte de certains services proposés par les fournisseurs d’accès à Internet. En effet, les serveurs DNS du fournisseur d’accès à Internet n’étant pas utilisés par les terminaux des utilisateurs, les services basés sur les résolutions DNS comme par exemple le contrôle parental, ne fonctionneront plus. Cela peut par exemple engendrer des insatisfactions utilisateur et des coûts de services après-vente importants pour les fournisseurs d’accès à Internet. En effet, il peut être assez difficile à un conseiller du service d'assistance téléphonique de déterminer que le problème provient de l’utilisation d’un serveur DNS public par un terminal ou une application exécutée sur le terminal.
De manière plus générale, l’utilisation de ces serveurs DNS publics peut également engendrer une augmentation du trafic IP international. En effet, ces serveurs DNS publics, hébergés pour la plupart aux Etats-Unis, ne permettent pas l’utilisation de « cache DNS » local (mémoire qui stocke les paires « Noms de domaine - adresses IP » qui viennent d’être résolues, afin de les retrouver plus rapidement), disponible par exemple au sein du réseau d’un fournisseur d’accès Internet, donc valable pour l’ensemble de ses clients, ou bien au sein d’une passerelle domestique d’un fournisseur d’accès à Internet, donc valable pour l’ensemble des terminaux et applications gérés par celle-ci, qui permettrait d’avoir une réduction substantielle du trafic DNS et un impact énergétique/environnemental plus faible. L’utilisation de DNS Publics pose également un problème concernant la protection des données à caractère personnel. Un acteur malveillant qui proposerait un tel service pourrait récupérer des données sensibles des utilisateurs et les revendre sans que les utilisateurs en aient conscience.
3. Exposé de l'invention
L’invention vient améliorer l’état de la technique et propose à cet effet un procédé de notification, par un dispositif de notification, de l’usage, par au moins un terminal, d’un serveur de noms de domaine non certifié, le procédé étant caractérisé en ce qu’il comprend : - une étape de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur ;
- une étape de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié ;
- une étape de notification, en fonction du résultat de la recherche, de l’usage, par ledit au moins un terminal, d’un serveur de noms de domaine non certifié.
Avantageusement, selon l'invention, le procédé va pouvoir détecter l’usage, par un terminal d’un utilisateur, d’un serveur de noms de domaine non certifié. A la réception d’une requête émise par le terminal, le procédé va vérifier qu’une résolution DNS a bien été effectuée par un serveur DNS certifié. Pour cela, le procédé va récupérer dans la requête reçue, un paramètre tel que l’adresse du serveur destinataire et vérifier que cette adresse est présente au sein d’une liste comprenant les adresses fournies au terminal par les serveurs DNS certifiés. Cette liste est par exemple remplie au fil de l’eau lors des résolutions DNS. Si l’adresse du serveur destinataire n’est pas présente dans la liste, alors le procédé va générer une notification informant que le terminal utilise un serveur de noms de domaine non certifié. Dans le cas contraire, cela signifie que la résolution DNS a bien été réalisée par un serveur DNS certifié et aucune notification n’est générée.
A noter que ce procédé est applicable quel que soit le protocole DNS utilisé, même pour les protocoles DoH/DoT dans lesquels les échanges DNS entre le terminal et un server DNS non certifié sont cryptés de bout en bout grâce au protocole HTTPS/TLS.
On entend par serveur DNS certifié, les serveurs de noms de domaine qui sont dits « de confiance » sélectionnés par une organisation habilitée comme par exemple le fournisseur d’accès à Internet de l’utilisateur du terminal. Bien entendu, les critères de sélection relatifs à la notion de confiance peuvent être propres à chaque organisation. Ainsi, les serveurs DNS certifiés peuvent être différents selon les organisations.
On entend par liste une suite d’éléments ordonnés ou non, distincts ou non, permettant d’obtenir un ensemble structuré tel qu’une liste d’éléments, par exemple horodatés, d’adresse IP, de nom de domaine, d’adresse MAC, de numéro de port ou bien de protocole. Cette liste est par exemple un cache DNS apte à stocker les paires « noms de domaine - adresses IP » qui viennent d'être résolues pour un terminal ou les applications exécutées sur le terminal. On entend par adresse une suite de caractères et/ou de données binaires qui sert à identifier un terminal ou un de ses modules électroniques comme par exemple un serveur, une passerelle domestique, un smartphone (en anglais « téléphone intelligent »), un ordinateur, un objet connecté, une carte réseau ou tout autre terminal connecté à un réseau comme par exemple une URI.
On entend par serveur tout terminal connecté à un réseau tel qu’un serveur Internet, un smartphone (en anglais « téléphone intelligent »), un ordinateur, un objet connecté, etc.
On entend par terminal tout terminal connecté à un réseau ou application s’exécutant sur un terminal apte à communiquer avec un autre terminal.
On entend par requête tout message envoyé par un terminal ou par une application s’exécutant sur un terminal à destination d’un serveur comme par exemple un message HTTP, un paquet IP, etc.
On entend par serveur de noms de domaine un serveur DNS (« Domain Name System ») ou un serveur dit « Resolver DNS » qui inclut des moyens de consultation périodique des serveurs DNS racine (.org, .corn, .net,...) et ceux qui sont sous le contrôle administratif de différentes entités (entreprises, états, associations, etc....) ainsi que des moyens de cache DNS.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que les étapes de recherche et de notification sont conditionnées au résultat d’une deuxième étape de recherche de ladite au moins une première adresse dans une deuxième liste, ladite deuxième liste comprenant les adresses de destinations des requêtes émises par ledit au moins un terminal.
Avantageusement, ce mode de réalisation permet de conditionner les étapes de recherche et de notification à la présence dans une liste de l’adresse de destination de la requête émise par le terminal de Tutilisateur. Cette liste peut par exemple être une liste d’adresses IP déjà connues d’une passerelle domestique telle qu’une table de NAT (« Network Address Translation ») ou NAPT (« Network Address Port Translation) dans le cas de l’usage du protocole IPV4 ou bien encore une table de routage de paquets IPV6. Cela peut encore être par exemple une table NAPT d’un équipement réseau de type CGN (Carrier Grade NAT) qui assure une fonction de tunnel IPV4-IPV6.
Ce mode de mise en œuvre de l'invention permet également de vérifier que l’adresse de destination de la requête émise par le terminal de Tutilisateur, comme par exemple une adresse IP, est présente dans une liste stockée dans un espace de stockage numérique tel qu’une base de données, un fichier, ou une mémoire. L’espace de stockage numérique peut par exemple héberger des données liées aux serveurs DNS Publics non certifiés (liste noire).
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’étape de recherche comprend en outre la recherche d’une seconde adresse associée à ladite première adresse dans ladite première liste, ladite seconde adresse étant un paramètre de ladite requête et correspondant à une adresse dudit au moins un terminal, ladite première liste comprenant au moins une adresse dudit au moins un terminal obtenue depuis ledit au moins un terminal associée à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.
Avantageusement, ce mode de réalisation permet de prendre en compte le cas où plusieurs terminaux sont gérés par le dispositif de notification et que par exemple l’un d’entre eux utilise un serveur DNS non certifié.
En effet, la résolution d’un nom de domaine a pu être réalisée par un serveur DNS certifié pour le compte d’un des terminaux avant qu’une demande similaire ne soit faite par le terminal utilisant le serveur DNS non certifié. Par conséquent, on aura dans la liste, l’adresse du serveur correspondant au nom de domaine recherché par le terminal utilisant le serveur DNS non certifié. L’adresse du serveur n’est donc, dans ce cas, pas suffisante pour détecter l’usage d’un serveur de DNS non certifié. Pour ce faire, une deuxième adresse telle qu’une adresse MAC ou une adresse IP ou un identifiant unique de type IMEI (International Mobile Equipement Identifier) associée au terminal est nécessaire. Ainsi, cette deuxième adresse permet de trouver dans la liste les résolutions DNS d’un terminal en particulier.
Selon un mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de recherche comprend en outre la recherche d’au moins un numéro de port de communication associé à ladite adresse dans ladite première liste, ledit au moins un numéro de port de communication correspondant à un paramètre de ladite requête, ladite première liste comprenant au moins un numéro de port de communication obtenu depuis ledit au moins un terminal associé à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié. Avantageusement, ce mode de réalisation permet de prendre en compte le cas où plusieurs applications s’exécutent sur le terminal de P utilisateur avec par exemple pour l’une d’entre elles l’utilisation d’un serveur DNS non certifié. En effet, la résolution d’un nom de domaine a pu être réalisée par un serveur DNS certifié avant qu’une demande similaire ne soit faite par l’application utilisant le serveur DNS non certifié. Par conséquent, on aura dans la liste, l’adresse du serveur correspondant au nom de domaine recherché par l’application utilisant le serveur DNS non certifié. L’adresse du serveur n’est donc, dans ce cas, pas suffisante pour détecter l’usage d’un serveur de DNS non certifié. Pour ce faire, le numéro du port de communication source correspondant à l’application utilisant le serveur DNS non certifié est nécessaire. En effet, dans le cas d’une communication TCP/IP, la pile TCP/IP du terminal ne peut pas affecter au même moment le même numéro de port source à différentes applications sans quoi la pile TCP/IP ne saurait pas vers quelle application router le trafic IP entrant. Le procédé peut ainsi notifier de l’usage par une application du terminal d’un serveur de DNS non certifié.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’étape de notification comprend une redirection de ladite requête vers au moins une page Internet.
Ce mode de mise en œuvre de l’invention permet d’informer l’utilisateur via l’affichage d’une page internet au niveau de son terminal qu’il utilise un serveur de noms de domaine non certifié avec les risques encourus.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’étape de notification comprend l’envoi d’un message à destination dudit premier terminal.
Ce mode de mise en œuvre de l’invention permet d’informer l’utilisateur via par exemple un SMS, un message RCS, un courriel ou un message de notification envoyé par exemple grâce à une solution de type FCM (Firebase Cloud Messaging) qu’il utilise un serveur de noms de domaine non certifié avec les risques encourus.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’étape de notification comprend l’envoi d’un message à destination d’un service d’assistance. Ce mode de mise en œuvre de l'invention permet par exemple d’informer le service client du fournisseur d’accès à Internet de l’utilisateur du premier terminal que celui-ci utilise un serveur DNS non certifié. Le technicien du service client pourra alors plus facilement comprendre d’où vient un défaut de fonctionnement constaté par l’utilisateur sur un de ses services basés sur les résolutions DNS tel que le contrôle parental et aider l’utilisateur à résoudre le problème.
Selon un mode de mise en œuvre particulier de l’invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’étape de notification est suivie d’une étape de filtrage des requêtes en provenance dudit premier terminal.
Ce mode de mise en œuvre de l'invention permet, lorsque l’utilisateur du premier terminal utilise un serveur DNS non certifié, de procéder à un filtrage des requêtes émises par le premier terminal. Le filtrage peut être partiel ou total, c’est-à-dire que le filtrage peut bloquer toutes les requêtes ou en laisser passer une partie comme par exemple celles à destination de l’assistance en ligne du fournisseur d’accès à Internet de l’utilisateur du premier terminal. Le filtrage peut aussi correspondre à une mise en attente des requêtes pendant une durée (par exemple une seconde) provocant par exemple un ralentissement des flux Internet au niveau du premier terminal.
Selon un mode de mise en œuvre particulier de l’invention, un procédé tel que décrit ci- dessus est caractérisé en ce que l’étape de notification est suivie d’une étape de modification des requêtes émises par ledit premier terminal.
Ce mode de mise en œuvre de l’invention permet par exemple, lorsque l’utilisateur du premier terminal utilise un serveur DNS non certifié, de « marquer » les requêtes émises par le premier terminal. Les équipements réseaux qui reçoivent ces requêtes peuvent alors appliquer des règles de traitement spécifiques comme par exemple la comptabilisation, la non prise en charge, le blocage, le routage spécifique, ou bien la duplication du trafic.
L'invention concerne également un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié, et caractérisé en ce que le dispositif comprend : - un module de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur ;
- un module de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié ;
- un module de notification, en fonction du résultat de la recherche, de l’usage par ledit au moins un terminal d’un serveur de noms de domaine non certifié.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L’invention concerne également une passerelle caractérisée en ce qu’elle comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
On entend par passerelle un dispositif permettant de relier deux réseaux informatiques de type différent, comme par exemple un réseau local et un réseau Internet, telle qu’un modem- routeur, un téléphone mobile avec le mode « partage de connexion » activé, etc.
L’invention concerne également un serveur caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
L’invention concerne également un terminal caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
Avantageusement ce mode de réalisation permet de prendre en compte le cas où le terminal dispose par exemple d’un cache DNS. L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé ci-dessus selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus. Les supports d’enregistrement mentionnés ci-avant peuvent être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D’autre part, les supports d’enregistrement peuvent correspondre à un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens. Les programmes selon l’invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, les supports d’enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé en question.
Ce dispositif de dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : [Fig 1] La figure 1 représente l’architecture matérielle d’un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié ;
[Fig 2] La figure 2 présente sous forme d’organigramme les principales étapes d’un procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
5. Description d'un mode de réalisation de l'invention
La figure 1 représente l’architecture matérielle d’un dispositif DNU de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié conforme à l’invention.
Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC, une mémoire vive MV, une mémoire morte MEM et une mémoire flash non volatile MF. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré ici un programme d’ordinateur PG conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d’être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié selon l’un quelconque des modes particuliers de réalisation décrits en relation avec la figure 2, selon les instructions du programme d’ordinateur PG. Le dispositif DNU comprend un module de communication COM configuré pour établir des communications avec par exemple un réseau IP. Ce module de communication COM est utilisé pour recevoir des requêtes en provenance d’un terminal d’un utilisateur. Ce terminal est par exemple un smartphone (en anglais « téléphone intelligent »), un ordinateur, une tablette, l’ordinateur de bord d’une voiture connectée ou un objet connecté (IOT pour Internet Of Things) ou tout terminal apte à se connecter à un réseau par exemple de type Internet. Ainsi, lors de la réception de la requête par le module COM, le procédé va récupérer un paramètre comme par exemple une adresse telle qu’une adresse IP, une adresse MAC, un numéro de port de communication ou un protocole de transport, qui permet la communication avec un deuxième terminal tel qu’un serveur Internet hébergeant des services et/ou des pages web.
Le dispositif DNU comprend de plus un module RECH qui va rechercher l’adresse reçue dans une liste par exemple stockée dans une base de données, un fichier, ou une mémoire.
Le dispositif comprend de plus un module NOTIF apte à notifier qu’un terminal utilise un serveur de noms de domaine non certifié si par exemple l’adresse reçue n’est pas dans la liste.
Selon un mode particulier de réalisation de l'invention, le module RECH peut également être utilisé pour rechercher l’adresse reçue dans une liste comprenant les adresses des serveurs de noms de domaine non certifiés (liste noire). Si l’adresse est présente dans la liste alors le terminal de l’utilisateur utilise un serveur de noms de domaine non certifié. Une notification pourra alors être émise par le dispositif informant sur l’usage par le terminal utilisateur d’un serveur de noms de domaine non certifié.
Selon un mode particulier de réalisation de l’invention, le dispositif peut comprendre une interface homme -machine permettant de restituer à l’utilisateur visuellement ou vocalement la notification.
Selon un mode particulier de réalisation de l'invention, le module RECH peut également être utilisé pour rechercher l’adresse reçue dans une liste de type NAT ou NAPT dans le cas de paquet IPV4 ou bien dans une liste de routage de paquets IPV6 par exemple hébergée au sein d’une passerelle ou plus généralement d’un point d’accès réseau fïxe/mobile.
Selon un mode particulier de réalisation de l’invention, le module COM peut être utilisé pour envoyer la notification à un terminal comme par exemple le terminal de l’utilisateur.
L’envoi de la notification peut également être réalisé en interne à la machine hébergeant le dispositif, par exemple vers un deuxième module de communication tel qu’une deuxième carte réseau.
Selon un mode particulier de réalisation de l’invention, le dispositif comprend une base de données configurée pour stocker des données telles qu’une adresse IP source, un port source, le protocole de transport, l’adresse IP destination et le port de destination des requêtes émises et reçues par le module COM.
Selon un mode particulier de réalisation de l’invention, le dispositif comprend une seconde base de données configurée pour stocker des données liées aux serveurs de noms de domaine non certifiés (liste noire) ou des données liées aux serveurs de noms de domaine certifiés (liste blanche).
En référence à la figure 2, nous allons maintenant décrire les principales étapes d’un procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
La figure 2 est constitué d’un terminal T apte à émettre et recevoir des requêtes vers et depuis le dispositif DNU et d’un serveur S apte à traiter les requêtes émises par le terminal T via le dispositif DNU. Dans l’exemple décrit à l’appui de la fïgure2, le dispositif DNU exécutant le procédé de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié est une passerelle supportant le protocole IPv4, le serveur S est un serveur de noms de domaine non certifié et le terminal T est par exemple un smartphone (en anglais « téléphone intelligent »), un ordinateur, une tablette, ou un objet connecté (IOT pour Internet Of Things) situé dans le réseau local géré par la passerelle DNU.
A l’étape E10 une application exécutée sur le terminal T émet une requête de résolution DNS à destination du serveur S avec pour adresse IP de destination de la requête, l’adresse IP du serveur S. A l’étape E20 la requête est reçue par la passerelle via son module de communication COM. L’adresse IP de destination ne correspondant pas à son espace d’adressage IP, c’est-à-dire aux adresses IP générées pour les terminaux situés en local et gérés par la passerelle via par exemple un module DHCP, la requête est redirigée vers un module N de la passerelle. Le module N permet par exemple de stocker dans une table ou une liste située par exemple dans une mémoire, un fichier ou une base de données, des données telles que l’adresse IP source d’une requête en provenance d’un terminal, c’est-à- dire l’adresse IP utilisée au sein du réseau local par le terminal ayant émis la requête, le numéro de port source contenu dans la requête émise et associé à l’application, le protocole de transport utilisé par la requête (UDP, TCP, SCTP,...), l’adresse IP de destination (l’adresse IP du serveur DNS non certifié) et le numéro de port de destination contenu dans la requête). Selon un mode de réalisation particulier, le procédé peut conditionner le passage à l’étape E21 à la présence de l’adresse IP de destination dans la table gérée par le module N. Si celle- ci est présente, le procédé passe alors à l’étape E26.
A l’étape E21, le procédé va rechercher dans une liste située par exemple dans une mémoire, un fichier ou une base de données de la passerelle, l’adresse IP de destination de la requête. Cette liste est par exemple un cache DNS (CR) qui va stocker toutes les demandes de résolution DNS réalisées auprès de serveurs DNS certifiés provenant des terminaux situés dans le réseau local de la passerelle. Cette recherche peut par exemple se faire via une requête de type « Whois lookup » avec comme paramètre l’adresse IP du serveur S.
A l’étape E31, le cache DNS (CR) récupère le résultat de la recherche et l’envoie au module N à l’étape E32. Le résultat est ensuite récupéré et traité par le module N à l’étape E22.
Dans le cas où l’adresse IP du serveur S est présente dans le cache DNS, cela signifie que l’application a utilisé l’adresse FQDN (Fully Qualifïed Domain Name) du serveur S pour le contacter. Cela indique également qu’une résolution DNS a préalablement été réalisée par un serveur de noms de domaine certifié comme par exemple le serveur de noms de domaine utilisé par le terminal lui-même. Le procédé passe alors à l’étape E26. A noter que dans ce cas, un traitement particulier de la requête tel qu’un filtrage de type contrôle parental, a alors pu être réalisé au préalable par le serveur de noms de domaine certifié.
Dans le cas où l’adresse IP du serveur S n’est pas présente dans le cache DNS, cela signifie qu’aucune résolution DNS via un serveur de noms de domaine certifié n’a retournée l’adresse IP du serveur S. En d’autres mots, l’adresse IP a été récupérée par l’application via un serveur de noms de domaine non certifié. Cela peut également signifier que l’adresse IP du serveur DNS non certifié est connue de l’application et dans ce cas la résolution DNS n’est pas nécessaire.
Selon un mode particulier de réalisation de l’invention, le procédé peut, si la requête est par exemple une requête de type HTTP/HTTPS passer à l’étape E23. Le procédé va alors générer une requête de redirection HTTP/HTTPS via un code réponse standardisé de la série 3XX. L’adresse de redirection peut par exemple être une page web d’information hébergée sur un serveur du réseau Internet ou au niveau de la passerelle. Cette page web permet ainsi de notifier l’utilisateur de l’usage d’un DNS non certifié par l’application. A noter que l’utilisateur peut, suite à la consultation de la page web d’information, désactiver la notification de l’usage d’un DNS non certifié et/ou la redirection via par exemple un paramètre de la passerelle accessible via une page web dédiée.
Selon une première variante de ce mode particulier de réalisation de l’invention, le procédé peut passer à l’étape E23 en fonction d’un nombre de requêtes à destination du serveur S. En d’autres mots, la redirection est activée en fonction d’un nombre de requêtes à destination du serveur S. Par exemple, toutes les n requêtes (par exemple 10) la redirection est activée puis désactivée à la requête n+1. Dans le cas où la redirection est désactivée alors le procédé passe directement de l’étape E22 à l’étape E26.
Selon une deuxième variante de ce mode particulier de réalisation de l’invention, si l’application relance une requête à destination du serveur S alors la redirection peut être désactivée pour une période prédéterminée (par exemple un jour / une semaine/ un ou plusieurs mois). Dans le cas où la redirection est désactivée alors le procédé passe directement de l’étape E22 à l’étape E26.
Selon un mode particulier de réalisation de l’invention (non représenté ici) qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, un message donnant des informations concernant la passerelle et/ou le terminal T exécutant l’application configurée pour utiliser un serveur de noms de domaine non certifié, est envoyé à destination d’un serveur comme par exemple un serveur du fournisseur d’accès à Internet de l’utilisateur du terminal T. Ce message permet de notifier un tiers de l’usage d’un DNS non certifié par l’application. Le message peut contenir toutes sortes de données telles que le jour, la date, l’adresse MAC du terminal et/ou de la passerelle, l’adresse IP attribuée au terminal sur le réseau local, l’adresse IP attribuée à la passerelle par le fournisseur d’accès à Internet, l’adresse IP du serveur S, etc.
Selon un mode particulier de réalisation de l’invention (non représenté ici) qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, la notification de l’usage d’un DNS non certifié par l’application est restituée par une interface homme- machine de la passerelle. Cette interface est par exemple un schéma représentant les terminaux présents au niveau du réseau local géré par la passerelle. Le schéma peut être visualisé par exemple via un écran situé sur la passerelle ou via un navigateur Internet d’un terminal connecté à la passerelle restituant une page web générée au niveau d’un serveur web s’exécutant sur la passerelle. Selon un mode particulier de réalisation de l’invention le procédé peut mettre en place un filtrage des requêtes émises par le terminal T subséquentes à la requête émise à l’étape E10. Le filtrage peut être partiel ou total, c’est-à-dire que le filtrage peut bloquer toutes les requêtes ou en laisser passer une partie comme par exemple celles à destination de l’assistance en ligne du fournisseur d’accès à Internet de l’utilisateur du terminal T. Le filtrage peut aussi correspondre à une mise en attente des requêtes pendant une durée (par exemple une seconde) provocant par exemple un ralentissement des flux Internet au niveau du terminal T.
Selon un mode particulier de réalisation de l’invention le procédé peut modifier les requêtes émises par le terminal T subséquentes à la requête émise à l’étape E10 et à destination de serveurs du réseau Internet. La modification peut par exemple être un « marquage » de l’ensemble des requêtes émises par le terminal ou seulement celles émises par l’application. Le marquage peut être réalisé par exemple via : l’utilisation du 1er bit non utilisé sur les 3 bits du champ « Indicateur » de l’en-tête du paquet IPv4 correspondant à la requête ; l’utilisation d’un des 2 bits non utilisés de l’en-tête IPV4 « Type de service » ; la création d’une nouvelle option IP V4 DNS Public. Par exemple en utilisant une classe d’option réservée pour une utilisation ultérieure (classes 1 et 3) et créer une option « DNS public » dans l’une de ces classes ou créer l’option « DNS public» dans une des classes existantes 0 ou 2. Le codage de l’option « DNS public » pourrait par exemple être définie en numéro d’option 10 dans la classe d’options 0 et son codage pourrait être du type TLV (Type, Longueur, Valeur).
Ainsi, les serveurs et ou les routeurs recevant les requêtes marquées pourront appliquer des règles de traitement spécifiques de ces requêtes comme par exemple la comptabilisation, la non prise en charge, le blocage, le routage spécifique, la mise en place de politiques de qualité de service spécifique, ou bien la duplication.
A l’étape E26, le procédé va modifier la requête en remplaçant l’adresse IP source du terminal par l’adresse IP de la passerelle, c’est-à-dire l’adresse IP donnée à la passerelle internet par un serveur DHCP du fournisseur d’accès à Internet et permettant de communiquer avec les autres terminaux connectés au réseau Internet. Optionnellement le numéro de port de communication source, c’est-à-dire du terminal T, présent dans la requête peut également être modifié à l’étape E26. Le requête est ensuite envoyée au serveur S et est reçue par celui-ci à l’étape E46. De manière connue, la réponse suit le chemin inverse (E47, E27, E28) et est reçue à l’étape E18 par le terminal T.
Selon un mode particulier de réalisation de l’invention le procédé peut à l’étape E21 faire une recherche avec en paramètre l’adresse MAC et/ou l’adresse IP du terminal T en plus de l’adresse IP de destination de la requête. Ce mode de réalisation permet de prendre en compte le cas où plusieurs terminaux sont présents dans le réseau local géré par la passerelle DNU. En effet, l’adresse MAC et/ou l’adresse IP va permettre de déterminer le terminal qui a demandé une résolution DNS à un serveur de noms de domaine certifié et de s’assurer que s’il y a eu précédemment une résolution DNS mémorisée dans le cache CR pour cette adresse IP, elle a bien été réalisée par ce terminal et pas un autre. Bien évidement cela suppose que l’adresse MAC et/ou l’adresse IP du terminal qui effectue une résolution DNS soit sauvegardée et associée à la résolution DNS dans le cache CR avant l’étape E21, par exemple lors de la demande de résolution DNS.
Selon un mode particulier de réalisation de l’invention qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le procédé peut à l’étape E21 faire une recherche avec en paramètre le numéro de port source de communication utilisé par une application du terminal T pour communiquer en plus de l’adresse IP de destination de la requête. Ce mode de réalisation permet de prendre en compte le cas où plusieurs applications aptes à demander des résolutions DNS sont exécutées sur le terminal T. En effet, le numéro de port source de communication va permettre de déterminer l’application qui a demandé une résolution DNS à un serveur de noms de domaine certifié et de s’assurer que s’il y a eu précédemment une résolution DNS mémorisée dans le cache CR pour cette adresse IP, elle a bien été réalisée par cette application du terminal T et pas une autre du même terminal T. Bien évidement cela suppose que le numéro de port source de communication de l’application qui effectue une résolution DNS soit sauvegardé et associé à la résolution DNS dans le cache CR avant l’étape E21, par exemple lors de la demande de résolution DNS. Alternativement ou cumulativement, le procédé peut également utiliser comme paramètre de recherche lors de l’étape E21, le numéro de port de communication de destination de la requête et/ou le protocole de transport utilisé et/ou toute donnée présente dans le message E10 telle qu’une donnée de IP de niveau 3 ou de niveau supérieur. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention. Selon d'autres modes particuliers de réalisation de l'invention, l'invention s'applique également à une passerelle utilisant un protocole IPv6. Dans ce cas, le module N correspond à un module de routage de paquets IPV6 de la passerelle. A noter que dans ce mode de réalisation particulier les champs d’extensions « Next Header » de l’en-tête du protocole IPv6 peuvent être utilisés pour marquer les requêtes/paquets IP en provenance des terminaux ou applications utilisant un serveur de noms de domaine non certifié.
Le marquage peut également être réalisé via un champ « Options » du header « HopByHopHeader » ou du Header « DestinationOptionsHeader » par exemple en utilisant le codage de type TLV
Selon un autre mode de réalisation de l’invention, l’invention s’applique également à un point d’accès mobile, par exemple à un smartphone (en anglais « téléphone intelligeant »)
4G ou 5G jouant le rôle de point d’accès WiFi pour un ou plusieurs terminaux.
Selon un autre mode de réalisation de l’invention, l’invention s’applique également à un terminal, par exemple un terminal fixe ou mobile disposant d’une fonction de cache DNS.
Selon un autre mode particulier de réalisation de l'invention, l'invention s'applique également à un réseau cœur mobile 4G/5G mise en œuvre par l’équipement PGW (Packet GateWay) dans le cas d’un réseau cœur 4G, ou SMF (Session Management Function)/UPF (User Plane Function) dans le cas d’un réseau cœur 5G. Il s’agit du même procédé que celui présenté à l’appui de la figure 2. En effet, l’équipement PGW ou SMF/UPF peut intégrer un cache DNS CR dont le fonctionnement est identique à celui présenté précédemment. Par conséquent, le même procédé peut s’appliquer. A chaque nouveau flux ou requête IP détecté, une requête, par exemple de type « Whois Lookup », peut être émise par le module de traitement du trafic IP de l’équipement PGW ou SMF/UPF, c’est-à-dire le module N, à destination du cache DNS CR du PGW ou du SMF/UPF (avec plus ou moins de paramètres dans la requête pour fournir des informations ciblées permettant de détecter les résolutions DNS opérées auparavant par un terminal, une application du terminal, selon le protocole applicatif, selon le protocole de transport,...). Selon un autre mode particulier de réalisation de l'invention, l'invention s'applique également à un réseau d’accès fixe ou mobile mise en œuvre par l’équipement CGN (Carrier Grade NAT). Il s’agit du même procédé que celui présenté à l’appui de la figure 2. En effet, l’équipement CGN peut intégrer un cache DNS dont le fonctionnement est identique à celui présenté précédemment. Par conséquent, le même procédé peut s’appliquer. A chaque nouveau flux ou requête IP détecté, une requête, par exemple de type « Whois Lookup », peut être émise par le module de traitement du trafic IP de l’équipement CGN, c’est-à-dire le module N, à destination du cache DNS CR du CGN (avec plus ou moins de paramètres dans la requête pour fournir des informations ciblées permettant de détecter les résolutions DNS opérées auparavant par un terminal, une application du terminal, selon le protocole applicatif, selon le protocole de transport,...).

Claims

REVENDICATIONS
1. Procédé de notification, par un dispositif de notification, de l’usage, par au moins un terminal, d’un serveur de noms de domaine non certifié, le procédé étant caractérisé en ce qu’il comprend :
- une étape de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur ;
- une étape de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié ;
- une étape de notification, en fonction du résultat de la recherche, de l’usage, par ledit au moins un terminal, d’un serveur de noms de domaine non certifié.
2. Procédé selon la revendication 1 dans lequel les étapes de recherche et de notification sont conditionnées au résultat d’une deuxième étape de recherche de ladite au moins une première adresse dans une deuxième liste, ladite deuxième liste comprenant les adresses de destinations des requêtes émises par ledit au moins un terminal.
3. Procédé selon la revendication 1 dans lequel l’étape de recherche comprend en outre la recherche d’une seconde adresse associée à ladite première adresse dans ladite première liste, ladite seconde adresse étant un paramètre de ladite requête et correspondant à une adresse dudit au moins un terminal, ladite première liste comprenant au moins une adresse dudit au moins un terminal obtenue depuis ledit au moins un terminal associée à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.
4. Procédé selon la revendication 1 dans lequel l’étape de recherche comprend en outre la recherche d’au moins un numéro de port de communication associé à ladite adresse dans ladite première liste, ledit au moins un numéro de port de communication correspondant à un paramètre de ladite requête, ladite première liste comprenant au moins un numéro de port de communication obtenu depuis ledit au moins un terminal associé à au moins une adresse obtenue depuis ledit au moins un serveur de noms de domaine certifié.
5. Procédé selon la revendication 1 dans lequel en ce que l’étape de notification comprend une redirection de ladite requête vers au moins une page Internet.
6. Procédé selon la revendication 1 dans lequel l’étape de notification comprend l’envoi d’un message à destination dudit premier terminal.
7. Procédé selon la revendication 1 dans lequel l’étape de notification comprend l’envoi d’un message à destination d’un service d’assistance.
8. Procédé selon la revendication 1 dans lequel l’étape de notification est suivie d’une étape de filtrage des requêtes en provenance dudit premier terminal.
9. Procédé selon la revendication 1 dans lequel l’étape de notification est suivie d’une étape de modification des requêtes émises par ledit premier terminal.
10. Dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié, et caractérisé en ce que le dispositif comprend :
- un module de réception d’une requête en provenance dudit au moins un terminal, ladite requête comprenant au moins un paramètre correspondant à une première adresse permettant la communication avec un serveur ;
- un module de recherche de ladite première adresse dans une liste, ladite liste comprenant au moins une adresse obtenue depuis au moins un serveur de noms de domaine certifié ;
- un module de notification, en fonction du résultat de la recherche, de l’usage par ledit au moins un terminal d’un serveur de noms de domaine non certifié.
11. Passerelle caractérisée en ce qu’elle comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
12. Serveur caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
13. Terminal caractérisée en ce qu’il comporte un dispositif de notification de l’usage par un premier terminal d’un serveur de noms de domaine non certifié.
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 9, lorsque le programme est exécuté par un processeur.
PCT/FR2021/050338 2020-03-03 2021-02-26 Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie WO2021176166A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21714640.6A EP4115582A1 (fr) 2020-03-03 2021-02-26 Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie
US17/908,083 US20230094785A1 (en) 2020-03-03 2021-02-26 Method and device for detecting the use of an uncertified domain name server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2002111A FR3108007A1 (fr) 2020-03-03 2020-03-03 Procédé et dispositif de détection de l’usage d’un serveur de noms de domaine non certifié.
FR2002111 2020-03-03

Publications (1)

Publication Number Publication Date
WO2021176166A1 true WO2021176166A1 (fr) 2021-09-10

Family

ID=71111549

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/050338 WO2021176166A1 (fr) 2020-03-03 2021-02-26 Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie

Country Status (4)

Country Link
US (1) US20230094785A1 (fr)
EP (1) EP4115582A1 (fr)
FR (1) FR3108007A1 (fr)
WO (1) WO2021176166A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114124547A (zh) * 2021-11-26 2022-03-01 中国电信股份有限公司 认证控制方法、装置、存储介质及电子设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140282816A1 (en) * 2013-03-14 2014-09-18 Fortinet, Inc. Notifying users within a protected network regarding events and information
EP3591932A1 (fr) * 2018-07-02 2020-01-08 Juniper Networks, Inc. Procédés et dispositifs de blocage, de détection et/ou de prévention de trafic malveillant

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140282816A1 (en) * 2013-03-14 2014-09-18 Fortinet, Inc. Notifying users within a protected network regarding events and information
EP3591932A1 (fr) * 2018-07-02 2020-01-08 Juniper Networks, Inc. Procédés et dispositifs de blocage, de détection et/ou de prévention de trafic malveillant

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114124547A (zh) * 2021-11-26 2022-03-01 中国电信股份有限公司 认证控制方法、装置、存储介质及电子设备
CN114124547B (zh) * 2021-11-26 2023-11-28 中国电信股份有限公司 认证控制方法、装置、存储介质及电子设备

Also Published As

Publication number Publication date
EP4115582A1 (fr) 2023-01-11
US20230094785A1 (en) 2023-03-30
FR3108007A1 (fr) 2021-09-10

Similar Documents

Publication Publication Date Title
CA2393089C (fr) Procede d'adressage d'un terminal mobile
EP3087720B1 (fr) Technique de contrôle du routage d'une requête relative a un service
EP1965559B1 (fr) Procédé de sécurisation d'un flux de données
FR3076141A1 (fr) Procede de traitement de requetes et serveur proxy
WO2021176166A1 (fr) Procede et dispositif de detection de l'usage d'un serveur de noms de domaine non certifie
EP2031836B1 (fr) Procédé et système d'adressage de dispositifs de restitution numérique
EP3216189A1 (fr) Délégation d'intermédiation sur un échange de données chiffrées
EP3560163A1 (fr) Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu
WO2007003818A1 (fr) Procede de filtrage par couplage multi-protocolaire sur la base du protocole dns.
EP1139637A2 (fr) Procédé et système d'octroi de privilèges par un gestionnaire d'accèss au sein d'un réseau de communication
EP3754956B1 (fr) Méthode, dispositif et programme d'ordinateur pour déterminer l'usurpation de l'identifiant de l'appelant
FR2872363A1 (fr) Procede et systeme de certification de l'identite d'un utilisateur
WO2020229219A1 (fr) Procede et dispositif de traitement d'une demande d'anonymisation d'une adresse ip source, procede et dispositif de demande d'anonymisation d'une adresse ip source
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
EP3788762A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
FR3023098A1 (fr) Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication.
WO2020128238A1 (fr) Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication
WO2023083772A1 (fr) Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés
FR3079642A1 (fr) Capteur d'intrusion informatique et procede de creation d'un capteur d'intrusion
WO2017220884A1 (fr) Procédé et dispositif de contrôle de flux de données transmis selon le protocole dns (domain name system)
FR3120268A1 (fr) Procédé et dispositif de détection du caractère frauduleux d’un courriel.
WO2024121281A1 (fr) Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés
EP3820112A1 (fr) Procédé de configuration d accès à un service internet
WO2018234662A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
EP4128717A1 (fr) Délégation d'une fonction de résolution d'identifiants de nommage

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21714640

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021714640

Country of ref document: EP

Effective date: 20221004