Protection system for a network of interest

Abstract

Protection system for a network of interest. The invention relates to a protection system (10) for at least one network of interest (11) configured to filter network flows between the network of interest (11) and the Internet, comprising at least one local device (Cypro), disposed between said network of interest (11) and the Internet (I), comprising: - a local database (BDDL1) of toxic IP addresses; - a configuration file (Fc1, Fc2); - a filtering device (Det) comprising: - analysis means (20); - comparison means (21); and - filtering means (22); the protection system (10) also comprising a remote device (ICQ) comprising: - a central database (Cerb) of enriched toxic IP addresses; and - enrichment means (Ort); - update means between the local device (Cypro) and the remote device (ICQ). Figure for the abridged version: Fig 1

Description

Title of the invention: System for protecting a network of interest technical field

[0001] The invention relates to a device for protecting a network of interest against toxic flows from the Internet. The network of interest may correspond to a computer network of a company, a community, an association, a group of connected objects or an individual.

[0002] The invention finds a particularly advantageous application for filtering in a personalized and adaptable way network flows containing toxic source or destination IP addresses, and for increasing the computer security of a network of interest connected to the Internet, while consuming few resources within the network of interest to be protected. Previous technique

[0003] A network architecture generally integrates a firewall connected between the Internet and at least one local computer network, called the "network of interest".

[0004] The firewall determines which types of communications are allowed on the network of interest. In effect, the firewall provides the link between the Internet and the network of interest by filtering unwanted network traffic from incoming communications, for example by restricting access to certain ports and, therefore, to certain protocols.

[0005] In addition, a firewall can also be used to filter suspicious and / or malicious, so-called "toxic" network flows, whether they are incoming or outgoing from the network of interest.

[0006] Several criteria exist for filtering toxic network flows; one of these involves analyzing the origin or destination of network flows. To do this, the firewall can be configured to analyze network flows, both incoming and outgoing from the network of interest, and capture the IP addresses of these network flows.

[0007] If a network flow has a source or destination IP address considered toxic, by comparing the IP address with a database of toxic IP addresses, the firewall blocks the associated network flow.

[0008] This database of toxic IP addresses can be static. In this case, toxic IP addresses are added and removed manually via an administration interface by a firewall user. This technique can be time-consuming, labor-intensive, and ineffective for newly detected toxic IP addresses.

[0009] Alternatively, the database of toxic IP addresses can be dynamic. The database is then updated by one or more reliable sources, in particular by subscriptions, or by capturing toxic IP addresses using decoy servers.

[0010] For example, French patent FR 3079642 proposes a computer intrusion detection sensor associated with an application server that retrieves the IP address of hackers attempting to penetrate the decoy server. The IP addresses retrieved by the decoy server are then transmitted to the database of toxic IP addresses.

[0011] Furthermore, it may happen that IP addresses considered toxic are necessary for the proper functioning of the network of interest. For example, cryptocurrency exchange sites need access to TOR nodes, whereas such access is preferentially filtered for e-commerce sites.

[0012] One solution for allowing certain flows that are blocked too severely is the use of a trusted list, also called a "whitelist" in the English-language literature. If the source or destination IP address of a network flow belongs to the trusted list, the IP address is not compared with the database of toxic IP addresses, and the flow is not blocked. The main drawback of this first solution is the need for a second database, the trusted list, which is mostly updated statically. Another drawback of this solution is that each IP address added to the trusted list must be trustworthy, otherwise access to toxic flows will be granted.

[0013] A second solution to this overly strict filtering is the creation of a "specific" database of toxic IP addresses. Starting with this toxic IP address database, the IP addresses are enriched with one or more metadata fields that allow for the categorization of the IP address type. The toxic IP address database, stored in the firewall, then incorporates the toxic IP addresses along with their metadata. Categories of IP addresses are then filtered or not according to a configuration file present in the firewall, which only allows the writing of the categories that one wishes to filter to the "specific" toxic IP address database.

[0014] One category of toxic IP addresses corresponds, for example, to the "TOR node" metadata, which refers to IP addresses identified as TOR exit or entry nodes. Blocking these IP addresses can provide protection against attackers using the TOR network to mask their local IP address.

[0015] The enrichment of the IP addresses obtained for their categorization is carried out by comparing the toxic IP addresses with a database of IP addresses known to correspond to TOR nodes. By iterating through each toxic IP address in the toxic IP address database, it is possible to define the "TOR node" metadata by checking if the IP address is present in the address database. IP addresses known to correspond to TOR nodes. These enriched toxic IP addresses are then stored in the "specific" toxic IP address database if the "TOR node" metadata matches an enabled category in the configuration file.

[0016] Some firewalls perform a series of comparisons between the incoming or outgoing IP address and the IP addresses contained in a "specific" database of toxic IP addresses. The presence of each toxic IP address in this specific database is conditional upon the activation of categories defined within a configuration file. This allows for customized filtering of certain categories of toxic IP addresses, and therefore of toxic traffic.

[0017] This solution has the drawback of using significant firewall resources to analyze and enrich the obtained toxic IP addresses with metadata before deciding whether or not to filter traffic containing these IP addresses. Indeed, the metadata for toxic IP addresses that allows for their categorization can be difficult to access and require significant search and processing time.

[0018] Ideally, the specific database is updated each time a new toxic IP address is detected. However, updating the specific database can involve a large number of new toxic IP addresses, and searching for a large amount of metadata can be a resource-intensive operation. Updating the specific database thus consumes a significant portion of a firewall's resources. This update is typically performed periodically during hours when a low number of network flows pass through the firewall, for example, once a day during the night.

[0019] To update in real time a database of toxic IP addresses of a firewall, document WO 2022 / 165174 proposes the generation of rules in an automated way, allowing proactive detection of threats.

[0020] Rule generation is performed by capturing and then analyzing network traffic. This analysis identifies toxic traffic in order to update the database of toxic IP addresses with the source and / or destination IP addresses of the detected toxic traffic. During the analysis, toxic traffic is characterized according to four risk level categories. It is therefore possible to obtain tailored filtering, equivalent to building a specific database, by filtering one or more of the four categories.

[0021] One of the problems with this solution lies in the difficulty of defining effective automated rules, leading to a risk of poor characterization.

[0022] To go further, some firewalls also incorporate even more complex functions. For example, as described in document WO 2022 / 165174, filtering through real-time detection and response to cybersecurity threats Real-time and retroactive threat detection and response is also possible. In this document, retroactive threat detection and response are achieved by collecting and storing network flows, then enriching this data with resolved domains, user information, and peer groups associated with these network flows. The system then performs behavioral analysis of these flows using categorization and machine learning algorithms to identify toxic flows and their propagation within the network of interest. Anomalies can thus be detected by re-examining historical network flow data, and toxic flows can be traced back to their origin. The system then generates alerts and reports based on the retroactive analysis of this data to enable the creation of corrective measures and improve network security by updating databases of toxic IP addresses.

[0023] Patent WO 2017 / 147411 thus allows an update of the specific database of toxic IP addresses after reactive analysis of network flows.

[0024] Whether it is the proactive detection application solution of document WO 2022 / 165174 or the reactive detection application of document WO 2017 / 147411, these solutions require increasingly significant computing power on firewalls for the management of a network of interest.

[0025] The technical problem of the invention is therefore to provide a protection system for a network of interest with a database of toxic IP addresses dedicated to the network of interest and dynamically updated, while using limited means in the network of interest. Description of the invention

[0026] The invention proposes to address this technical problem by decentralizing part of the intelligence to a remote device whose function is to identify and characterize toxic IP addresses using metadata. Thus, one or more local devices connected to networks of interest can obtain, from this remote device, the toxic IP addresses they wish to block based on a dedicated configuration file whose categories correspond to the metadata of the toxic IP addresses collected at the remote device level.

[0027] The invention therefore relates to a protection system for at least one network of interest comprising at least one local device, disposed between said network of interest and the Internet, comprising: - a local database of toxic IP addresses; - a configuration file allowing at least partial determination of the IP addresses contained in said local database of toxic IP addresses; - a filtering device comprising: - analytical tools configured to capture the IP addresses of incoming and outgoing flows of the network of interest; - comparison tools configured to compare IP addresses captured by the analysis tools to IP addresses contained in said local database of toxic IP addresses; and - filtering means to block the transmission of incoming and / or outgoing network flows from the network of interest when the comparison means detect that an IP address in the network flow corresponds to an IP address contained in said local database of toxic IP addresses.

[0028] The invention is characterized in that the protection system also includes a remote device, comprising: - a central database of toxic IP addresses; each IP address stored in said central database of toxic IP addresses being associated with several metadata; and - Enrichment means configured to receive toxic IP addresses from at least one trusted source and to enrich these toxic IP addresses with metadata before storing them in said central database.

[0029] In addition, the protection system also includes update means configured to transmit to at least one local database the new toxic IP addresses stored in said central database corresponding to categories specified in the configuration file.

[0030] Using a local device and a remote device reduces the resources used by the local device within the network of interest, while simultaneously providing an optimized analysis of incoming and outgoing network flows in terms of data transmission and analysis time. To achieve this, two databases are implemented. The local database, which stores the toxic IP addresses to be filtered, is located in the local device, as close as possible to the network flows, i.e., between the network of interest and the Internet. The central database, which stores and characterizes all the retrieved toxic IP addresses, is located in the remote device to reduce the resource demand within the network of interest.The connection between the central database and each local database is then established by means of updates which take into account the categories specified in the configuration file in order to transmit only the toxic IP addresses to be filtered, and thus reduce the exchange of data between the remote device and the local device.

[0031] According to one embodiment of the invention, at least one reliable source of the enrichment means is implemented by a collection device receiving addresses toxic IPs originating from at least one subscription to at least one external database.

[0032] This collection unit makes it possible to centralize toxic IP addresses obtained by subscribing to external sources of lists of toxic IP addresses such as the French government center for monitoring, alerting and responding to computer attacks, also known by the acronym CERT FR.

[0033] Alternatively, the local protection system includes at least one decoy server that captures IP addresses associated with network traffic destined for said decoy server. This decoy server can be implemented as described in patent FR3079642. The IP address of the decoy server is visible from the Internet as a server belonging to the network of interest, but the decoy server has no outgoing network traffic to the network of interest. Attackers can thus connect to the decoy server believing they are connecting to the network of interest, while keeping the network of interest out of the attackers' reach. The decoy server then retrieves the toxic IP addresses of the attackers who have connected. Consequently, the IP addresses captured by this decoy server constitute at least one trusted source for the enrichment means.This trusted source is more reliable than subscribing to an external database because it allows obtaining the IP addresses of attackers specifically targeting the protected network of interest, and obtaining toxic IP addresses not yet listed in external databases.

[0034] In another embodiment, the protection system includes at least one attacker identification server capable of capturing IP addresses and "sessions," i.e., all actions performed by the attacker on that attacker identification server. This attacker identification server can be implemented, as described in patent EP3644146, on or off the local device and must be accessible from the Internet. This attacker identification server is visible from the Internet as a server of the network of interest in which a remote control service is enabled and can be password-protected, but has no outbound network traffic to the network of interest. This attacker identification server is configured to transmit IP addresses and sessions to the enrichment means and to constitute at least one trusted source of the enrichment means.When an IP address connects to the server without performing malicious actions, for example the IP address of the Google search engine performing an inventory of servers accessible from the Internet, it can thus be characterized as a non-toxic IP address.

[0035] Conversely, when an attacker connects to the server with hacker identification and performs malicious actions, his actions are captured and the toxicity of the IP address can be confirmed.

[0036] The advantage of the hacker identification server is that, like a decoy server, it allows obtaining toxic IP addresses not yet listed in external databases, but also obtaining additional information on toxic IP addresses.

[0037] Indeed, the hacker identification server has the advantage of enriching toxic IP addresses with additional metadata, such as actions performed by an attacker. The toxic IP addresses thus captured can then be stored in the central database, and subsequently analyzed and identified as belonging to groups of attackers whose modus operandi is known through the enrichment methods.

[0038] These toxic IP addresses are thus collected, enriched and then stored in the central database.

[0039] In order to update the local device's database, toxic IP addresses stored in the central database are sent to the local database based on their membership in the categories specified in the local device's configuration file. Preferably, each category has at least three levels of filtering, also specified in the configuration file.

[0040] In this embodiment, the three filtering levels are: - a first level of filtering whereby all IP addresses are filtered; - a second level of filtering according to which none of the IP addresses are filtered; and - a third level of filtering according to which IP addresses are filtered only if the IP address belongs to a category defined by a trusted third party.

[0041] This classification into categories, themselves divided into filtering levels, allows for customizable filtering of toxic IP addresses within the protection system. For example, a category of toxic IP addresses for TOR nodes can be configured at the second filtering level so as not to filter toxic IP addresses corresponding to that category of TOR nodes.

[0042] According to a variant of the protection system, in order to allow this categorization of toxic IP addresses upon capture, the enrichment means of the remote device capture each new toxic IP address. Then, the enrichment means of the remote device enrich each new toxic IP address with metadata. And finally, the enrichment means of the remote device update the central database with each of these new toxic IP addresses as well as their associated metadata. These steps allow for an asynchronous update of the central database.

[0043] The use of centralized enrichment methods that collect new toxic IP addresses and enrich said toxic IP addresses with metadata makes it possible to Maintain a central database that is up-to-date and contains all the metadata necessary to classify each toxic IP address according to the categories defined in the local device's configuration file. Knowing the configuration of the local device's configuration file, the database can then send only the toxic IP addresses to be filtered when the local database is updated.

[0044] Thus, according to one embodiment of the invention, the local database is updated each time a new toxic IP address is received by the filtering device corresponding to at least one category in the configuration file. In this embodiment, the enrichment means are configured to query the central database and then send the toxic IP addresses from the central database, corresponding to the categories, to the filtering device according to two triggers: - during each update of the central database initiated by an update signal from the enrichment means to the filtering device; and / or - during each update of the configuration file, the update of which is initiated by sending a signal containing the new configuration of the configuration file from the local device to the central database.

[0045] The first trigger keeps the local database up to date each time a new toxic IP address is added to the central database. This update can occur instantaneously or during periods of low network traffic analyzed by the local device. This keeps the local database up to date.

[0046] The second trigger allows the local database of toxic IP addresses to be filtered to be updated after a parameter change in the configuration file. Some networks of interest may have filtering needs that change over time, and the adaptability of the configuration file allows the filtering system to adapt to the immediate needs of the network of interest it protects. Typically, a network of interest with an abnormally high number of network flows over a period of time may require stricter filtering of network flows during this period of high network flow density.

[0047] In order to enable efficient updating of the local database by toxic IP addresses belonging to certain specific categories, the local device of the protection system includes a configuration file which preferably has at least two groups of categories.

[0048] These two groups of categories are preferably defined as: - a first group of categories comprising one or more categories corresponding to IP addresses identified as belonging to one or more professional activity domains; and - a second group of categories including at least one category corresponding to at least one trusted source that has classified said IP addresses as toxic.

[0049] The first group of categories corresponding to IP addresses identified as belonging to one or more professional activity domains makes it possible to identify whether a toxic IP address is legitimate on the network of interest to be protected with regard to the professional activity to which the network of interest belongs, or not.

[0050] The second group of categories having the sub-category or sub-categories corresponding to the sources of classification of IP addresses into toxic IP addresses makes it possible to activate or not certain sources having a database of toxic IP addresses unsuitable for effective filtering on the network of interest.

[0051] According to one embodiment of the invention, the system comprises at least two networks of interest, associated with at least two local devices each comprising the same filtering device, a specific configuration file and a specific local database.

[0052] This embodiment allows several local databases to be updated using the same central database. This makes it possible to pool sources of toxic IP addresses, while maintaining customized filtering on each network of interest through the configuration file on each local device. Summary description of the figures

[0053] The manner of implementing the invention and the resulting advantages will become clear from the following embodiments, given by way of example but not limitation, with support from the figures in which:

[0054] [Fig-1] Schematic representation of a protection system for a network of interest according to a first embodiment of the invention;

[0055] [Fig.2] Schematic representation of a two-network protection system of interest according to the first embodiment of the invention;

[0056] [Fig.3] Schematic representation of a protection system integrating a server lure according to a second embodiment of the invention;

[0057] [Fig.4] Schematic representation of a protection system integrating a server decoy, and a pirate identification server according to a third embodiment of the invention;

[0058] [Fig. 5] Schematic representation of a protection system filtering a flow entering from the Internet to the network of interest according to the first embodiment of the invention; and

[0059] [Fig.6] Schematic representation of a protection system filtering a flow outgoing from the network of interest to the Internet according to the first embodiment of the invention. Detailed description of the figures

[0060] Figures 1 to 4 illustrate a protection system 10 of at least one network of interest 11, 11' against toxic network flows originating from or destined for toxic IP addresses.

[0061] As shown in [Fig. 1], the protection system 10 comprises a local Cypro device located between the network of interest 11 and Internet I. The local Cypro device includes a local database BDDL1 of toxic IP addresses and a configuration file Fcl. Both the local database BDDL1 and the configuration file Fcl are configured to receive and transmit data streams with a filtering device Det. The filtering device can be implemented on a circuit board integrating two network ports and a processor or microcontroller. Alternatively, the filtering device can be virtualized on a server. Regardless of the implementation of the filtering device, it is configured to analyze incoming network streams 19a or outgoing network streams 19b and to optionally filter some of these network streams.

[0062] To update the local database BDDL1 used for filtering, the filtering device Det can host an administration interface on which an administrator can modify the configuration file Fcl. When this Fcl file is modified by the administrator, a request can be transmitted by the filtering device Det to the remote device ICQ, containing the new configuration of the Fcl file, and the remote device ICQ then sends the new list of toxic IP addresses to be stored in the local database BDDL1.

[0063] In addition, the Det filtering device is configured to receive the contents of the local database BDDL1 when filtering new incoming network flows 19a and outgoing network flows 19b. The Det filtering device is also configured to send update data to the local database BDDL1.

[0064] The protection system 10 also includes a remote ICQ device comprising a central database Cerb and enrichment means Ort including a microprocessor. The remote ICQ device is configured to receive data streams 29a and send data streams 29b with the local Cypro device.

[0065] Preferably, as illustrated in [Fig. 1], the enrichment means Ort are configured to receive the data streams 29a from the filtering device Det and to transmit the data streams 29b to the filtering device Det. The data streams 29a to the enrichment means enable the enrichment means Ort to receive data relating to the configuration of IP address categories to be filtered, specified in the Fcl, Fc2 configuration file. Similarly, data flows 29a to the Ort enrichment means allow the Ort enrichment means to receive data relating to an update request, sent from the Det filtering device. As for data flows 29b from the Ort enrichment means, they allow a list of toxic IP addresses to be sent to the Det filtering device after querying the central Cerb database.

[0066] In order to retrieve this list of toxic IP addresses to be filtered, the Ort enrichment means are also configured to send and receive data streams with the central Cerb database. Indeed, the central Cerb database contains a list of toxic IP addresses where each stored toxic IP address is associated with one or more metadata fields: Int, Mil, Att, Tor, Sip, Cmd, Cdt, Vid, Cert, Lur, Vek. These metadata fields correspond to the filtering categories specified in the Fcl, Fc2 configuration file. For example, SIP corresponds to a video communication protocol, Cmd corresponds to an IP address known to attempt to control remote servers, and Vid corresponds to an IP address sending video streams related to a camera.The list of toxic IP addresses sent by the Ort enrichment means to the Ort analysis device corresponds to the toxic IP address(es) belonging to the categories specified in the Fcl, Fc2 configuration file and configured to be filtered by filtering levels associated with the categories.

[0067] The central Cerb database is updated by the Ort enrichment means, preferably when they receive toxic IP addresses IPtoxl, IPtox2, IPtox3 from at least one trusted source Lur, Vek, Hyd. The Ort enrichment means then enrich these toxic IP addresses IPtoxl, IPtox2, IPtox3 with the metadata Int, Mil, Att, Tor, Sip, Cmd, Cdt, Vid, Cert, Lur, Vek before storing them in the central Cerb database. This continuous and asynchronous update ensures that the central database remains up-to-date. The reception of new toxic IP addresses can be achieved either through passive listening by the Ort enrichment means for trusted sources, or through a query from the Ort enrichment means to the trusted sources.

[0068] In one variant, the Ort enrichment means also make requests to trusted sources in order to receive metadata associated with the obtained toxic IP addresses.

[0069] Preferably, the configuration file includes categories with at least one ON, OFF, Int filtering level per category, out of three possible ON, OFF, Int filtering levels. During an update of the local database BDDL1 The ON, OFF, Int filtering levels associated with each category specified in the Fcl configuration file are sent by the Det filtering device to the Ort enrichment means.

[0070] The ON, OFF, and Int filtering levels preferably include a first ON filtering level in which all IP addresses in the category are filtered. With this first filtering level, all toxic IP addresses in the central Cerb database are added to the local BDDL1 database. In [Fig. 1], the toxic IP addresses 107.165.21.03, 117.14.125.17, and 62.59.42.160 correspond to a Cmd command category configured in the Fcl and Fc2 configuration files. With this first ON filtering level, they are added to the local BDDL1 database and filtered by the local Cypro device.

[0071] In this variant, the filtering levels include a second OFF filtering level in which no IP address of the associated category is filtered. In [Fig. 1], the toxic IP address 127.53.47.48 corresponds to a TOR node category configured in the Fcl, Fc2 configuration file on the second OFF filtering level; it is therefore not added to the local database BDDL1 and is not filtered by the local Cypro device.

[0072] This variant also preferably includes a third level of Int filtering, in which IP addresses are filtered only if they possess Int intelligence metadata associated with a category defined by a trusted third party or by enrichment through IP address analysis by the Ort enrichment system. The enrichment system can obtain this metadata by querying its trusted sources or through internal intelligence that analyzes the activity history of the obtained toxic IP addresses.

[0073] Thus, a toxic IP address belonging to a category whose filtering level is set to the third filtering level Int and not belonging to any category whose filtering level is set to the first filtering level ON will only be filtered if the value set for the intelligence category is set to 1.

[0074] For example, a toxic IP address belonging to a category whose filtering level is set to the third filtering level, Int, and where the intelligence category is set to 1 will be added to the local database BDDL1. In [Fig. 1], the toxic IP address 112.52.27.59 corresponds to a military category, Mil, configured in the configuration file Fcl at the third filtering level, Int, but also to the intelligence category, Int; it is thus added to the local database BDDL1 and is filtered by the protection system 10.

[0075] As a second example, a toxic IP address belonging to a category whose filtering level is set to the third filtering level Int and where the intelligence category is set to 0, will not be added to the local database BDDL1. In [Fig. 1], the toxic IP address 45.158.157.41 corresponds to a SIP category configured in the Fcl configuration file at the third level of Int filtering, but does not belong to the Int intelligence category; therefore, it is not added to the local database BDDL1. Similarly, the toxic IP address 32.159.210.10 corresponds to the Mil military category configured in the Fcl configuration file at the third level of Int filtering, but does not belong to the Int intelligence category; therefore, it is not added to the local database BDDL1.

[0076] In a third example, a toxic IP address belonging to a category whose filtering level is set to the third filtering level Int and where the toxic IP address belongs to a category whose filtering level is set to the first filtering level ON will be filtered regardless of the value set for the intelligence category.

[0077] The local database BDDL1 is updated for each new toxic IP address received by the Det filtering device.

[0078] According to one embodiment of the invention, the update of the local database BDDL1 is initiated by a modification of the configuration file Fcl. The modification of the configuration file Fcl triggers the sending of a signal containing the updated filtering levels for each filtering category by the filtering device Det to the enrichment means Ort. The enrichment means Ort then query the central database Cerb in order to obtain the toxic IP addresses corresponding to the categories whose filtering level is either set to the first filtering level ON or to the third filtering level Int and whose Intelligence Int category is activated, illustrated by a bit set to 1 in the central database Cerb visible in [Fig. 1].

[0079] According to a second embodiment of the invention, the update of the local database BDDL1 is initiated by adding a new toxic IP address to the central database Cerb using the Ort enrichment means. The Ort enrichment means then send the new toxic IP address to the filtering device if a match is found between the new toxic IP address and at least one of the categories whose filtering level ON, OFF, Int is set either to the first filtering level ON, or to the third filtering level Int, in addition to matching the Intelligence Int category.

[0080] According to a third variant of the invention, the update of the local database BDDL1 is initiated by a periodic update request signal carried out by the filtering device Det, preferably during periods of low density of incoming network flows 19a and outgoing network flows 19d from the internet to the network of interest and of incoming network flows 19b and outgoing network flows 19c from the network of interest to the internet.

[0081] Furthermore, the Fcl configuration file preferably includes at least two groups of categories. A first group comprising categories corresponding to IP addresses identified as belonging to professional activity domains, for example, the military domain (Mil) or the healthcare domain. As well as a second group of categories comprising at least one category corresponding to toxic IP addresses captured by at least one trusted source that has classified said IP addresses as toxic.

[0082] The Fcl configuration file may also include a third group of categories corresponding to categories of IP addresses not to be blocked. This third group of categories includes IP addresses with an Int metadata value of 0, and may be stored in the central Cerb database without being transmitted to the local BDDL1 database.

[0083] As shown in [Fig. 2], the protection system 10 can include at least two separate local databases BDDL1, BDDL2 from two local protection devices Cypro, Cypro' associated with two networks of interest 11, 11'. These two local databases BDDL1, BDDL2 receive updates of toxic IP addresses from the central database Cerb and are associated with two configuration files Fcl, Fc2 whose categories and / or filtering levels associated with the categories are different. Thus, the two databases BDDL1, BDDL2 can receive a different update of toxic IP addresses and contain only the toxic IP addresses to be filtered on their network of interest 11, 11'. This difference in the update settings allows for customized protection through customized filtering depending on the network of interest 11, 11' to which the local protection devices Cypro, Cypro' are associated. In [Fig.[2], the filtering associated with network of interest 11' is less severe than the filtering associated with network of interest 11. Since the filtering levels of the Fc2 configuration file are more flexible than the filtering levels of the Fcl configuration file, the local database BDDL2 contains as many or fewer toxic IP addresses to filter as the local database BDDL1.

[0084] The Ort enrichment means are configured to receive new toxic IP addresses IPtoxl, IPtox2, IPtox3 from at least one trusted source. Furthermore, the Ort enrichment means can also perform a search on these toxic IP addresses to retrieve other metadata related to them, such as origin, country of origin, network type, or the business domain associated with the toxic IP address.

[0085] As illustrated in [Fig. 3], the local Cypro device, Cypro', may include a Hyd collection unit receiving toxic IP addresses IPtoxl from at least one subscription to at least one external database. The Hyd collection unit is then configured to transmit the new addresses to the Ort enrichment means Toxic IP addresses from IPtoxl subscriptions are listed in at least one of its subscriptions. Metadata associated with the name of the trusted source database that may have led to the collection of these toxic IP addresses from IPtoxl subscriptions can then be added to these new toxic IP addresses from IPtoxl subscriptions. For example, the CERT FR categorized under Cert.

[0086] Similarly, as illustrated in Figures 3 and 4, a Lur decoy server capturing IP addresses associated with 19e network flows originating from the Internet and destined for the Lur decoy server can be added as a trusted source for the Ort enrichment means. This Lur decoy server can be placed in the local Cypro device, and the captured IPtox2 IP addresses sent to the remote ICQ device then constitute at least one trusted source for the Ort enrichment means. The toxic IPtox2 IP addresses collected by the Lur decoy server and transmitted to the Ort enrichment means can then be enriched by the Ort enrichment means with Lur metadata, allowing the trusted source that led to the collection of these toxic IPtox2 IP addresses from the Lur decoy server to be traced.

[0087] Finally, as illustrated in [Fig. 4], the protection system 10 can also include a Vek hacker identification server connected to the Internet I, capable of capturing the toxic IP addresses IPtox3 and the sessions of at least one attacker attempting to connect to them. The Vek hacker identification server is configured to transmit the toxic IPtox3 addresses and attacker sessions to the Ort enrichment means, thereby constituting a trusted source for the Ort enrichment means. Analysis of the session associated with a toxic IPtox3 address from the Vek hacker identification server then allows the Ort enrichment means to obtain additional information about the IP address, and thus complete its associated metadata, for example, by recognizing a known attacker's modus operandi and completing metadata related to the attacker Att.The toxic IP addresses IPtox3 collected by the Vek hacker identification server and transmitted to the Ort enrichment means are preferentially enriched by the Ort enrichment means with Vek metadata allowing tracing of the trusted source that may have led to the collection of these toxic IPtox3 IP addresses from the Vek hacker identification server.

[0088] Figures 5 and 6 show the interior of a filtering device Det, Det' respectively during the filtering of an incoming flow 19a or an outgoing flow 19b of the network of interest 11, 11'. Analysis means 20, comparison means 21 and filtering means 22 are included in the filtering device Det, Det'.

[0089] As shown in Figures 5 and 6, the incoming network flows 19a and outgoing network flows 19b of the network of interest 11,11' are captured by the filtering device Det, Det' of the local device Cypro, Cypro' where toxic flows are discriminated and then filtered according to The origin of their source IP addresses S and destination IP addresses D. More precisely, the source IP addresses S and destination IP addresses D of each incoming network flow 19a and outgoing network flow 19b are captured by the analysis means 20 and the filtering means 22. After the network flows 19a, 19b are captured by the analysis means 20, the source IP addresses S and destination IP addresses D of each network flow 19a, 19b are sent to the comparison means 21, allowing the captured IP addresses to be compared with the IP addresses contained in the local database BDDL1, BDDL2 of toxic IP addresses. The analysis means 20 can also be configured to send only the source IP address S of the incoming flows 19a and the destination IP address D of the outgoing flows 19b of the network of interest in order to perform only one comparison per flow with the local database BDDL1, BDDL2.When at least one of the source IP addresses S or destination IP addresses D of a network flow matches at least one IP address contained in the local database BDDL1, BDDL2 of toxic IP addresses, a filtering signal is sent to the filtering means 22. The filtering means 22 then block the transmission of the network flow associated with the detected toxic source IP address S or destination IP address D. This blocking occurs before the network flow 19a, 19b with the toxic IP address enters the network of interest 11, 11' for an incoming flow 19a, or before its exit to Internet I for an outgoing flow 19b. Conversely, if the source IP address S and destination IP address D associated with the toxic flow 19a, 19b do not appear in the local database BDDL1, BDDL2, then the network flow 19a, 19b associated with the captured non-toxic IP address is transmitted by the filtering means 22 to its destination IP address D.These unblocked incoming flows 19c and outgoing flows 19d are respectively represented in figures 5 and 6.

[0090] The decision to filter or not filter the streams captured by the filtering means 22 can be determined, as in Figures 5 and 6, by metadata added to each stream by the comparison means 21. The metadata can then be read by the filtering means 22 in order to determine which streams 19c, 19d to transmit.

[0091] As an alternative to the network flow captures described above, it is possible that the network flows 19a, 19b are transmitted to the analysis means 20. Then by the analysis means 20 to the comparison means 21. And finally from the comparison means 21 to the filtering means 22. As a result, the filtering means can directly transmit the flows discriminated as non-toxic by the comparison means 21 to their destination IP address D.

[0092] In another variant, the comparison means 21 can transmit only the network flows not recognized as toxic 19c, 19d to the filtering means 22. As a result, the filtering means can directly transmit all flows received from the comparison means 21 to their destination IP address D.

[0093] In conclusion, the invention provides a protection system 10 for at least one network of interest 11, 11' with a database of toxic IP addresses BDDL1, BDDL2 dedicated to the network of interest 11, 11' and dynamically updated. The protection system 10 described in the invention also allows integration into a network of interest 11, 11' with limited resources by using a central database BDDC located remotely from the network of interest 11, 11', from which the updates to the local database BDDL1, BDDL2 originate.

Claims

1. Demands Protection system (10) of at least one network of interest (11, 11') comprising at least one local device (Cypro, Cypro'), located between said network of interest (11, 11') and Internet (I), comprising: - a local database (BDDL1, BDDL2) of toxic IP addresses; - a configuration file (Fcl, Fc2) allowing at least partial determination of the IP addresses contained in said local database (BDDL1, BDDL2) of toxic IP addresses; - a filtering device (Det, Det') comprising: - analysis means (20) configured to capture the IP addresses of incoming (19a) and outgoing (19b) flows from the network of interest (11, 11'); - comparison means (21) configured to compare the IP addresses captured by the analysis means (20) with IP addresses contained in said local database (BDDL1, BDDL2) of toxic IP addresses; and - filtering means (22) to block the transmission of incoming (19a) and / or outgoing (19b) network flows from the network of interest (11, 11') when the comparison means (21) detect that an IP address in the network flow corresponds to an IP address contained in said local database (BDDL1, BDDL2) of toxic IP addresses; characterized in that the protection system (10) also includes a remote device (ICQ) comprising: - a central database (Cerb) of toxic IP addresses; each IP address stored in said central database (Cerb) of toxic IP addresses being associated with several metadata (Int, Mil, Att, Tor, Sip, Cdm, Cdt, Vid, Cert, Lur, Vek); and - Enrichment means (Ort) configured to receive toxic IP addresses (IPtoxl, IPtox2, IPtox3) from at least one trusted source (lur, vek, hyd) and to enrich these toxic IP addresses (IPtoxl, IPtox2, IPtox3) with metadata (Int, Mil, Att, Tor, Sip, Cdm, Cdt, Vid, Cert, Lur, Vek) before storing them in said central database (Cerb); - the protection system (10) also including update means configured for: - transmit to at least one local database (BDDL1, BDDL2) the new toxic IP addresses stored in said central database (Cerb) corresponding to categories specified in the configuration file (Fcl, Fc2).

2. A protection system according to claim 1, wherein at least one trusted source (Lur, Vek, Hyd) of the enrichment means (Ort) is realized by a collection organ (Hyd) receiving toxic IP addresses (IPtoxl) from at least one subscription to at least one external database.

3. A protection system according to any one of claims 1 or 2, wherein the local device (Cypro, Cypro') comprises at least one decoy server (Lur) capturing IP addresses related to network flows (19e) destined for said decoy server (Lur), said captured IP addresses (IPtox2) constituting at least one source of trust (Lur, Vek, Hyd) of the enrichment means (Ort).

4. A protection system according to any one of claims 1 to 3, wherein the protection system (10) comprises at least one attacker identification server (Vek) capable of capturing the IP addresses and sessions of at least one attacker on said attacker identification server (Vek), said attacker identification server being configured to transmit said IP addresses and sessions to the enrichment means (Ort) and to constitute at least one source of trust (Lur, Vek, Hyd) of said enrichment means (Ort).

5. A protection system according to any one of claims 1 to 4, wherein toxic IP addresses are filtered according to their membership in categories, specified in the configuration file (Fcl, Fc2), according to at least three levels of filtering per category also specified in the configuration file (Fcl, Fc2): - a first level of filtering (ON) according to which all IP addresses are filtered; - a second level of filtering (OFF) according to which none of the IP addresses are filtered; and - a third level of filtering (Int) according to which IP addresses are filtered only if the IP address belongs to a category (Int) defined by a trusted third party.

6. A protection system according to any one of claims 1 to 5, wherein the enrichment means (Ort) capture each new toxic IP address (IPtoxl, IPtox2, IPtox3), enrich each new toxic IP address (IPtoxl, IPtox2, IPtox3) with metadata, and then update the central database (Cerb) with each of these new toxic IP addresses (IPtoxl, IPtox2, IPtox3) and the metadata associated with them; performing an update of the central database (Cerb) asynchronously.

7. A protection system according to any one of claims 1 to 6, wherein the local database (BDDL1, BDDL2) is updated at each new toxic IP address received by the filtering device (det, det') corresponding to at least one category (Int, Mil, Att, Tor, Sip, Cdm, Cdt, Vid, Cert, Lur, Vek) of the configuration file (Fcl, Fc2), the enrichment means being configured to query the central database (Cerb) and to send the toxic IP addresses from the central database (Cerb) corresponding to said categories (Int, Mil, Att, Tor, Sip, Cdm, Cdt, Vid, Cert, Lur, Vek) to said filtering device (Det, Det'): - at each update of the central database (Cerb);and / or - during each update of the configuration file (Fcl, Fc2), the update of which is initiated by sending a signal containing the new configuration of the configuration file (Fcl, Fc2) from the local device (Cypro, Cypro') to the central database (Cerb).;

8. A protection system according to any one of claims 1 to 7, wherein said configuration file (Fcl, Fc2) has at least two groups of categories: - a first group of categories comprising one or more categories corresponding to IP addresses identified as belonging to one or more business domains; and - a second group of categories comprising at least one category corresponding to toxic IP addresses captured by at least one trusted source that has classified said IP addresses as toxic.

9. A protection system according to any one of claims 1 to 8, wherein the system comprises at least two networks of interest (11, 11'), associated with at least two local devices (Cypro, Cypro') each having the same filtering device (Det, Det'), a specific configuration file (Fcl, Fc2) and a specific local database (BDDL1, BDDL2).

Images