RU2820803C1 - Method and system for tunneling traffic in distributed network - Google Patents

Abstract

FIELD: computer security.

SUBSTANCE: method of routing traffic within a distributed network comprises steps of adding an emitter and a gateway to the IP address neighbor table using a computing device, where the emitter is a distributed network peer, configured to analyze malicious content, as well as receive data packets encapsulated at the WireGuard level and at the GRE level, gateway is a distributed network peer, configured to NAT packets of outgoing traffic and de-NAT packets of incoming traffic; sending to the gateway an IP address of the corresponding emitter neighbor table; sending to the emitter the IP address of the corresponding gateway neighbor table; in response to receiving the outgoing traffic packet from the emitter, the outgoing traffic packet is decapsulated; identifying the IP address of the gateway specified as the recipient data at the WireGuard level; encapsulating the outgoing traffic packet at the WireGuard level and the GRE level, where the IP address specified at the WireGuard level is different from the IP address specified at the GRE level; packet of outgoing traffic is forwarded to gateway for NAT.

EFFECT: implementation of multilevel tunneling for traffic transfer within a distributed network.

6 cl, 5 dwg

Description

TECHNICAL FIELD

This technical solution relates to the field of computer technology, namely to methods and systems for tunneling traffic in a distributed network to detonate malicious software (malware).

BACKGROUND OF THE ART

This technical solution relates to the field of computer technology, namely to methods and systems for tunneling traffic in a distributed network to detonate malicious software.

Cybersecurity experts predict that the number and technical sophistication of cybercrimes will continue to increase. Attackers quickly adapt malware to increase its effectiveness and overcome known methods of combating malware. In response to the technical development of malware, technical means to counteract malware are being developed, thus creating a kind of “arms race.” The method proposed for patenting is the next iteration in the aforementioned “arms race” from the side that counteracts attackers, and allows for the implementation of an improved type of sandbox.

It has long been known about the use of sandboxes in the field of cybersecurity, that is, special isolated environments for detonating and analyzing software and identifying its harmfulness. Sandboxes are described in more detail in the article https://ru.wikipedia.org/wiki/Sandbox_(security). In response to the creation of sandboxes, attackers implemented more complex types of malware. Such malware, for example, is capable of analyzing the environment in which it enters. If malware gets into a sandbox, its behavior may differ from its behavior in a non-sandboxed environment.

It is known that some malware manages to overcome static software analysis, which is performed by analyzing various resources of the executable file without executing it and studying each of its components separately. And some malware even manage to remain undetected after dynamic analysis. Dynamic analysis is performed by observing the behavior of the malware while it is actually running in a sandbox. Some malware manages to escape sandboxes undetected due to the fact that they do not contain malicious code. Instead, they download malicious code from a remote server, but only if the malware ends up on the client's network. For example, attackers preparing a targeted attack on a specific organization can configure a remote server in such a way that it sends malicious code only if the request comes from one of the corporate subnets belonging to the organization that is the victim of the attack. If the remote server receives a request from any IP address that does not belong to the organization’s corporate subnet, then the remote server, imitating a regular web server, will send a non-malicious response.

An obvious solution for this situation may seem to be the technology of replacing the IP address with the desired one, for example, natting. Natating also has a second name - masquerading. Natating is a method of network address translation in which the sender's IP address is assigned dynamically depending on the IP address assigned to the interface. Natting is described in more detail here https://ru.wikipedia.org/wiki/Masquerading and here https://ru.wikipedia.org/wiki/NAT.

Unfortunately, the simplest implementation of natification, in which the IP address of a sandbox that is not located in the corporate subnet will simply be replaced with the IP address of the corporate subnet, will not work. The attacker's remote server, having received a request from the corporate subnet, will send a response to the IP address of the corporate subnet. The corporate subnet will most likely ignore the incoming packet received as a response from the attacker server, since it did not send a request to the remote attacker server. In order for the corporate subnet to forward the incoming packet received in response from the attacker’s server to the sandbox, the sandbox must actually be located in the corporate subnet, which is technically more difficult to implement and, in addition to technical difficulties in implementation, is resource-intensive.

One example of a solution where the sandbox is located on a corporate subnet and the router natifies outgoing traffic, replacing the local IP address of the sandbox with the public IP address of the corporate subnet, is a virtual private network or VPN.

VPN is a generic name for technologies that allow one or more network connections to be made over another network, such as the Internet. Read more about VPN here https://ru.wikipedia.org/wiki/VPN. Each network participant, peer, has its own local IP address. Each peer's routing is configured in such a way that it forwards packets to the Internet through a server. So, for each outgoing data packet passing through the server, natification is performed. And for each incoming packet, denetting is performed - the public IP address is replaced with the local IP address of the peer. If the sandbox is one of the peers and is located in the corporate VPN network, the nat technology will work and will solve the problem of IP address spoofing. However, this solution is not optimal and has a number of disadvantages. One of them is a client-server architecture, which requires keeping a large number of connections up to date. This is resource intensive.

Traffic tunneling technology is also known from the prior art. Traffic tunneling is a process that creates a logical connection between two endpoints through encapsulation. Tunneling is a method of building networks in which one network protocol is encapsulated into another, that is, the data transmitted through the tunnel is “packed” along with service fields into the payload area of the carrier protocol. Tunneling is described in more detail here https://en.wikipedia.org/wiki/Tunneling_protocol.

Various traffic routing protocols are known from the prior art, including the distributed network traffic routing protocol Next Hop Resolution Protocol, hereinafter called NHRP for brevity (https://en.wikipedia.org/wiki/Next_Hop_Resolution_Protocol). NHRP is an extension of the ATM ARP routing mechanism that is sometimes used to improve the efficiency of routing computer network traffic over non-broadcast, multi-access networks. This protocol is defined by IETF standard RFC 2332 and further described by RFC 2333. It can be used by a sender to determine the route with the fewest hops to a recipient. The protocol differs from protocols like ARP in that it allows for optimized routing between multiple IP subnets.

Since in a distributed network using the NHRP routing protocol there is no central server that would store information about the IP addresses of subnets, traffic routing requires public IP addresses for each subnet.

In a distributed network implemented using the method proposed for patenting, information about the IP addresses of subnets is stored on a central server, this allows subnet participants not to have public IP addresses and to be behind NAT.

At the same time, the solution US 20050086367 A1 (Alex Conta et al., Methods and apparatus for implementing multiple types of network tunneling in a uniform manner, published 04.21.2005. class G06F 15/173) is known from the prior art, in which describes a method for implementing support for multiple traffic tunneling protocols using a router. It is proposed to implement traffic tunneling simultaneously using the IP-IP and IP-over-MPLS protocols.

The described method, in addition to the fact that it differs in implementation from the point of view of the network architecture and the tunneling protocols used, is more resource-intensive, since it requires the router to support a separate interface for each peer that sends requests to the router to use it as an IP-IP router. In other words, to use the router as a router for two peers, it is necessary to ensure that this router supports four interfaces. The solution proposed for patenting allows routing between thousands of peers using just two interfaces. Implementing routing using just two interfaces requires significantly less computing resources and less effort to configure. To configure the proposed solution, there is no need to configure the provider's routers; the network configuration on the end device (peer) is sufficient.

As previously mentioned, solutions for detonation and investigation of malicious software, so-called sandboxes, are known in the prior art. There are also various ways to organize sandbox environments in order to make it difficult for an attacker and his software to detect sandboxes. One example of such a solution is US 10404661 B1 (Taylor Ettema et al., Integrating a honey network with a target network to counter IP and peer-checking evasion techniques, publ. 03/09/2019. class G06F 9/455, H04L 29/06 ), which describes how to integrate a honey pot network into a target network environment (such as a corporate network) for IP spoofing and methods to evade peer inspection. In some embodiments, a system for integrating a honey pot network with a target network includes a device profile data store that includes a plurality of attributes of each of a plurality of devices in the target environment: a virtual copy manager that creates a virtual copy of one or more devices in the target network based on one or more attributes of the target device in the device profile data store; and a honey pot network policy that is configured to route external communication from the virtual copy to the target device in the honey pot network to the external device across the network environment. This solution does not mention a single method of tunneling traffic and replacing the sandbox IP address with the IP address of a corporate network using traffic tunneling protocols.

This solution is designed to solve the problems identified during the analysis of the state of the art and create an improved, comprehensive method for routing traffic in a distributed network.

SUMMARY OF THE INVENTION

For the purposes of this specification, unless specifically stated at the point of use, the following specific terms are used with the following meanings:

central server - a server in a distributed network that is used to configure routing and issue IP addresses within the network; the central server stores a table of neighbors;

gateway - a distributed network peer implemented for natating outgoing traffic packets;

emitter - a distributed network peer on which one or more sandboxes are installed;

peer - a participant in a distributed network, for example, a gateway or emitter;

nating - network address translation, a mechanism in networks at the transport level that allows you to convert IP addresses of transit packets.

Tunneling is a process that creates a logical connection between two endpoints by encapsulating different protocols. Tunneling is a networking technique in which one network protocol is encapsulated within another. The essence of tunneling is to “pack” the transmitted portion of data, along with service fields, into the payload area of the carrier protocol packet.

Encapsulation is a method of constructing modular network protocols in which logically independent network functions are abstracted from underlying mechanisms by embedding or encapsulating those mechanisms in higher-level objects.

neighbor table - a table in the OS network stack that stores records of the mapping of IP addresses at the GRE level to IP addresses at the WireGuard level. An analogue of the neighbor table is the ARP table, which stores records of the correspondence of IP addresses to MAC addresses. The OS accesses these tables when routing packets to obtain the destination address at the underlying network layer.

interface - here means the interface for interacting with Wireguard or GRE software;

test site - a set of isolated environments for detonation and analysis of potentially harmful content

The technical problem to be solved by the claimed technical solution is the creation of a computer-implemented method and system for tunneling traffic within a distributed network, which are described in independent claims. Additional embodiments of the present solution are presented in the dependent claims.

The technical result consists in the implementation of multi-level tunneling for transmitting traffic within a distributed network, which may be required, for example, for analyzing suspicious traffic.

In a preferred embodiment, a computer-implemented method for routing traffic within a distributed network for analysis of potentially malicious content contains steps in which, using a computing device, at least one emitter and at least one gateway are added to a table of neighbors of IP addresses, where at least at least one emitter is a distributed network peer configured to analyze malicious content, as well as receive data packets encapsulated at the WireGuard level and at the GRE level, at least one gateway is a distributed network peer configured to parse at least one outgoing packet traffic and denaturing at least one packet of incoming traffic; sending to at least one gateway the IP addresses corresponding to it in the table of neighbors of at least one emitter; sending to at least one emitter the IP address corresponding to it in the table of neighbors of at least one gateway; decapsulating, in response to receiving at least one outgoing traffic packet from the at least one emitter, the at least one outgoing traffic packet; identify the IP address of the gateway specified as recipient data at the Wireguard level; encapsulate an outgoing traffic packet at the WireGuard layer and the GRE layer, where at least one IP address specified at the WireGuard layer is different from at least one IP address specified at the GRE layer; forwarding at least one outgoing traffic packet to at least one gateway for nating. The way IP addresses include: Internet IP addresses, Wireguard level IP addresses, GRE level IP addresses. The method further includes registering the at least one emitter and the at least one gateway with the at least one central server by issuing a configuration file.

In an alternative embodiment, the method may be performed by an emitter, the method comprising the steps of: sending at least one outgoing traffic packet by at least one emitter to at least one central server, wherein the at least one outgoing traffic packet contains at least two layers of encapsulation on top of the transport protocol implemented to forward the outgoing traffic packet by at least one central server to at least one gateway for natification; extracting, in response to receiving at least one incoming traffic packet from at least one central server, potentially malicious content from the at least one incoming traffic packet, where the at least one incoming traffic packet has previously been received by at least one central server from at least one gateway; analyze potentially harmful content and ensure its detonation. The method further includes a preparatory step in which the at least one emitter receives a configuration file from at least one central server. A method that also includes configuration of interfaces at the WireGuard level and GRE level using the resulting configuration file. A method comprising obtaining IP addresses of at least one gateway from at least one central server. The method includes setting up at least one route through at least one gateway.

In another particular embodiment of a method for routing traffic within a distributed network to detonate malicious content, the method is performed on the gateway as follows: decapsulates, in response to receiving at least one packet of outgoing traffic from at least one central server, at least one packet outgoing traffic; identifying the external server data specified as recipient data at the GRE level; encapsulating at least one outgoing traffic packet by at least one gateway; nat at least one packet of outgoing traffic with the IP address of the gateway; sending at least one dated outgoing traffic packet to an external server; denetizing, in response to receiving at least one incoming traffic packet from the external server, at least one incoming traffic packet; encapsulate at least one incoming traffic packet at the WireGuard layer and the GRE layer, where at least one IP address specified at the WireGuard layer is different from at least one IP address specified at the GRE layer; sending at least one incoming traffic packet to at least one central server. The method includes a preparatory stage, in which at least one gateway receives a configuration file from at least one central server. Additionally, at least one gateway interface is configured at the WireGuard level and the GRE level using the resulting configuration file. The method also includes a preparatory step in which the IP addresses of at least one emitter are obtained from at least one central server.

The stated solution is also implemented through a traffic routing system within a distributed network for analyzing potentially malicious content, where the distributed network is implemented through two-level tunneling, including: the WireGuard level and the GRE level. The system is represented by at least one central server that performs the steps of: adding at least one emitter and at least one gateway to the neighbor table of IP addresses, where at least one emitter is a distributed network peer capable of analyzing malicious content, as well as receiving data packets encapsulated at the WireGuard level and at the GRE level, and at least one gateway is a distributed network peer configured to nat at least one packet of outgoing traffic and denature at least one packet of incoming traffic, send to at least one gateway of the IP address corresponding to it in the neighbor table of at least one emitter, send to at least one emitter of the IP address corresponding to it in the neighbor table of at least one gateway, decapsulate, in response to receiving at least one outgoing traffic packet from at least one emitter, at least one outgoing traffic packet, identifying the IP address of the gateway specified as recipient data at the Wireguard layer, encapsulating the outgoing traffic packet at the WireGuard level and the GRE layer, where at least one IP -the address specified at the WireGuard layer is different from at least one IP address specified at the GRE layer, forward at least one outgoing traffic packet to at least one gateway for nating. In this system, IP addresses include: Internet IP addresses, Wireguard level IP addresses, GRE level IP addresses. The presented system registers at least one emitter and at least one gateway on at least one central server by issuing a configuration file.

The traffic routing system is alternatively implemented by at least one emitter, the system performing the steps of: sending at least one outgoing traffic packet by the at least one emitter to at least one central server, where at least one outgoing traffic packet contains at least two layers of encapsulation over a transport protocol implemented to forward an outgoing traffic packet by at least one central server to at least one gateway for natification are retrieved in response to receiving at least one incoming traffic packet from at least one central servers, from at least one packet of incoming traffic potentially malicious content, where at least one packet of incoming traffic was previously received by at least one central server from at least one gateway, analyze the potentially malicious content and achieve its detonation. A system that receives, by at least one emitter, a configuration file from at least one central server. A system that configures interfaces at the WireGuard level and GRE level using the resulting configuration file; A system that obtains IP addresses of at least one gateway from at least one central server. The system also configures at least one route through at least one gateway.

The system for routing traffic within a distributed network to detonate malicious content can additionally be implemented by at least one gateway. The system performs the steps of: decapsulating, in response to receiving at least one outgoing traffic packet from at least one central server, at least one outgoing traffic packet, identifying the external server data specified as recipient data at the GRE level, encapsulate at least one outgoing traffic packet by at least one gateway, tag at least one outgoing traffic packet with the IP address of the gateway, send at least one natified outgoing traffic packet to an external server, denature, in response to receiving at least one packet of incoming traffic from an external server, at least one packet of incoming traffic, encapsulate at least one packet of incoming traffic at the WireGuard layer and the GRE layer, where at least one IP address specified at the WireGuard layer is different from at least one The IP addresses specified at the GRE layer send at least one incoming traffic packet to at least one central server. The system includes a preparatory stage, in which at least one gateway receives a configuration file from at least one central server. The system configures at least one gateway interface at the WireGuard level and the GRE level using the resulting configuration file. The system contains a long-term memory configured to store used files and data, a computing device configured to perform the described method.

DESCRIPTION OF DRAWINGS

The implementation of the invention will be described further in accordance with the accompanying drawings, which are presented to explain the essence of the invention and in no way limit the scope of the invention. The following drawings are attached to the application:

Fig. 1 illustrates a general diagram of a distributed network.

Fig. 2 illustrates the general addressing scheme of a distributed network with subnetworks implemented in it.

Fig. 3 illustrates the preparatory stage of the method.

Fig. 4A illustrates the transmission of outgoing traffic in the work stage.

Fig. 4B illustrates the transmission of incoming traffic in the work stage.

Fig. 5 illustrates a diagram of a computing device,

DETAILED DESCRIPTION

The following detailed description of the invention sets forth numerous implementation details designed to provide a clear understanding of the present invention. However, it will be apparent to one skilled in the art how the present invention can be used with or without these implementation details. In other cases, well-known methods, procedures and components have not been described in detail so as not to obscure the features of the present invention.

In addition, from the above discussion it will be clear that the invention is not limited to the above implementation. Numerous possible modifications, alterations, variations and substitutions, while retaining the spirit and form of the present invention, will be apparent to those skilled in the art.

The solution proposed for patenting makes it possible to implement tunneling of traffic in a distributed network in such a way that, at the exit from this distributed network, packets of outgoing traffic are natified and these packets are forwarded to an external IP address, while a specified IP address is indicated as the sender address, which is different from the real address of the device that sent the traffic packets.

Let's look at an example. Bank "X" approached company "G" with a request to provide services in the field of cybersecurity, namely, outsourced analysis of suspicious content coming from external resources. In this case, company "G" can provide the bank with the opportunity to use its landfill. Company "G" provides one or more sandboxes within the polygon to service Bank "X"'s request. The polygon's distributed network is designed in such a way that, upon request from bank "X", a route is built to one or more isolated environments located in the polygon, and suspicious traffic from bank "X" is analyzed in these isolated environments. Tunneling within a distributed network is implemented in such a way that at the exit from this network, each packet of outgoing traffic is natified and the IP address of bank “X” is indicated as the sender. Thus, an attacker who sent malicious content to bank “X”, for example, a malicious file or a link to a malicious site, as a result of analysis and detonation (triggering) of this file or clicking on the link, will see a request to his server from the bank’s IP address "X" rather than from the polygon's IP address.

As previously mentioned, a test site includes many isolated environments organized in a distributed network. Isolated environments can be distributed among multiple clients, one of which is bank "X". At the exit from the distributed network, the data packet originating from each of the isolated environments is natified and sent to an external server with an IP address corresponding to the addresses of the network infrastructure of a given company, for example, in this case, bank "X".

Next, the implementation method will be described in detail using the example of the interaction of one isolated environment installed on one emitter and one gateway. But you need to understand that in a real operating test site, many emitters and many gateways can be implemented, capable of performing the actions described below for many client companies.

In this example, the central server and emitter, part of the infrastructure of company "G", routes and analyzes potentially malicious traffic entering the local network of company "X". As part of the local network infrastructure of company "X" there is a device - a gateway, made with the ability to forward all or part of the traffic for analysis to the infrastructure of company "G". Traffic forwarding is implemented by routing it through a central server. In a distributed network, the central server is the gateway for peers. The gateway is used by peers to forward packets to a destination whose IP address they do not know. Thus, when a gateway from the local network of company "X" needs to send a data packet for analysis on one of the devices included in the infrastructure of company "G", it forwards the packet to the central server, which, in turn, is configured to forward the received package to the emitter corresponding to the given gateway. Packet forwarding is implemented through tunneling in any well-known manner.

In FIG. 1 shows a diagram of a possible implementation of the described technology. As shown in FIG. 1, the malicious content analysis site 110 contains a plurality of emitters, such as emitter 115. A central server 101 stores a table of neighbors 102. The table of neighbors 102 contains information necessary to construct routes between peers; it may be implemented in a generally known manner, as a database of any suitable format, such as a MAC address table. In one example implementation, neighbor tables may also be stored on gateways 120 and emitters, such as emitter 115.

It should be noted that the exchange of information between all devices of the distributed network 100 is carried out through a computer network, such as the Internet. In a similar way, information can be exchanged between devices of the distributed network 100 and any external (relative to the distributed network 100) computing devices, such as, for example, an external server 130.

The peers in this distributed network are emitters and gateway 120. At each emitter, in particular at emitter 115, as previously mentioned, an isolated environment for detonation of suspicious content (not shown in the drawing) can be installed. Gateway 125 is a computing device that is located on the client company's local network 122; it is designed with the ability to replace the sender's IP address with the client's IP address.

Routing in a distributed network is configured in such a way that no gateway, such as Gateway 125, can communicate with other gateways. Likewise, no emitter can communicate with any other emitter. In this case, from each of the emitters it is possible to create a route to each of the gateways and back through the central server 101.

In the example used, routing is configured so that gateway 125, located in the local network 122 of bank "X", is not able to exchange data with other gateways, which, in particular, may belong to other companies. In general, gateway 125 technically has the ability to send and receive data from any emitter and from the central server 101. However, in the described solution 100, the route is always configured between one emitter and one gateway. Therefore, in this non-limiting example, the route for gateway 125 of bank "X" is configured such that data is transferred from emitter 115 first to central server 101, then to gateway 125.

It is important to note that in order to implement the described invention, the central server 101 must have a public IP address. Moreover, gateway 125 may be behind gateway 121 and not have a public IP address. Likewise, emitter 115 may be behind node 116 and not have a public IP address.

In an alternative implementation, both gateway 125 and emitter 115 may have their own public IP addresses and not be behind a network.

The following will describe in detail the route along which data packets may be transmitted in the distributed network 100 during the implementation of the above example with bank "X" and company "G".

The emitter 115 may generate a request to an external server 130 that is located outside the distributed network 100. This request to the external server may be, for example, following an external link from an email received in an isolated environment installed on the emitter 115, and the external server 130 may be the attacker's command and control server. Emitter 115 sends a request in the form of an outgoing data packet to the central server 101. Central server 101 forwards the outgoing data packet to gateway 125. Gateway 125 replaces the sender's IP address with the IP address of the local network 122 in which this gateway is located and forwards the packet to external server 130. Due to the described substitution, the address of the sender of the packet (which can be analyzed by the attacker’s program on external server 130) will have nothing in common with the address of the emitter 115, so the attacker will not know that the opening of the letter and clicking on the link occurred in an isolated environment , and not on one of the devices of the attacked local network 122.

Thus, when the external server 130 receives the packet, it is the IP address of the local network 122 that will be determined as the source address. Thanks to the substitution of the IP address, the distributed network 100 will imitate the local network of the client 122 for the attacker. The external server 130, if it belongs to the attackers, in response to a request (following a link) sends malicious content, for example, the download of the malicious program that was directed to link. An incoming traffic packet containing malicious content is sent to gateway 125. Gateway 125 forwards the packet to central server 101. Central server 101 forwards the packet to emitter 115. Thus, emitter 115 receives the packet containing malicious content. Emitter 115 unpacks the received packet in an isolated environment and analyzes it.

In the example above, the following happens. On the local network of bank "X" they receive an email from an unknown sender. The letter contains a link to download the file. The letter is redirected for analysis to an isolated environment installed on the emitter. On the emitter, they follow the link contained in the letter, that is, a request to an external server to download the file. The request is automatically sent first to the central server, then to the gateway. The gateway installed on the attacked local network replaces the emitter's IP address with the IP address of the local network of bank "X" and forwards the packet to an external server, possibly belonging to the attacker.

The external server in the received packet determines the IP address as the local network address of bank "X" specified as the sender. And in response to the received request, it sends a packet containing a potentially malicious file. The incoming data packet is received at the gateway and sent back to the emitter, but not directly, but through the gateway, the functions of which are performed by the central server.

The forwarding of packets between network actors: emitter 115, central server 101 and gateway 125 occurs thanks to tunneling, repackaging the packet at several data transfer levels. The proposed technology implements two data transfer interfaces over an Internet connection - Wireguard and GRE. Wireguard and GRE are both communication protocols and software for implementing these protocols. Both types of software have interfaces through which their configuration occurs.

This method will be described in detail below.

The method consists of two stages: preparatory and working. At the preparatory stage, interfaces are configured and routes are configured between the emitter 115 and the corresponding gateway 125; the IP addresses of the emitter 115 and the corresponding gateway 125 are registered in the table of neighbors 102 on the central server 101.

The preparation stage 300 is shown in FIG. 3. It begins with step 310, in which two interfaces are created on the central server, in this example, on the central server 101: Wireguard and GRE. For the GRE interface, it is indicated that it runs on top of the Wireguard interface. With this setting, packets in the configured distributed network will be encapsulated in the following order: UDP, Wireguard, GRE. The listed actions can be performed in any well-known manner. This completes step 310 and the method proceeds to step 320.

At step 320, a private key is generated on the central server 101 on the Wireguard interface. This can be done in any generally known manner. This completes step 320 and the method proceeds to step 330.

At step 330, on the central server 101, a listening port is set for the Wireguard interface using the appropriate command, that is, they indicate which server port will listen for incoming connections. This can be done in any generally known manner. This completes step 330 and the method proceeds to step 340.

At step 340, configuration files are generated on the central server 101 for the server itself, as well as for all emitters and all gateways with which this central server must work. In particular, in the example under consideration, configuration files are generated for emitter 115 and gateway 125.

The central server IP addresses are added to the central server configuration file for the Wireguard and GRE interfaces. As shown in FIG. 2, at the Wireguard level, the central server has two IP addresses, one of its IP address 210 is intended for interaction with gateways, and the second IP address 220 is for interaction with emitters. From Fig. 2 it can be seen that in the example under consideration at the Wireguard level, the central server 101 is assigned the IP address 10.100.0.1/17 for interaction with the emitter subnet 230, which has the address 10.100.128.0/17, at the same time the IP address is 10.100.128.1/17 assigned to the central server 101 for interaction with the gateway subnet 240, which has the address 10.100.0.0/17.

It should be noted that devices, which are, for example, gateways, located at the Wireguard level in the same subnet 240, may physically be located in different cities or even different countries. Likewise, emitters located at the Wireguard level on the same subnet 230 can be located in arbitrary locations around the globe.

Subnets are also specified in the central server configuration file. Subnets are lists of IP addresses from which peers, that is, emitters and gateways, will be assigned IP addresses during their subsequent configuration. Specifying subnets in the central server configuration file determines the central server's ability to receive packets from a given subnet and send or forward packets to given subnets. It is important to note that emitters and gateways belong to different subnets at the Wireguard level. As can be seen in Fig. 2, emitters belong to one subnet 230, and gateways belong to another subnet 240. Issuing different IP addresses from non-overlapping subnets for emitters and gateways at the Wireguard level by the central server allows you to configure routes so that emitters can transmit packets to gateways and cannot transmit packages to other emitters. For the same reason, gateways will be able to transmit packets to emitters and will not be able to transmit packets to other gateways. This is necessary so that different owners of different local networks, for example, competing banks, cannot access each other’s local network and perform natification through competitors’ gateways.

In the same way, subnets are specified in the configuration files for emitters and for gateways, and the subnets specified in the configuration files of emitters differ from the subnets specified in the configuration files of gateways. The configuration file also specifies the UDP port on which the central server listens for incoming Wireguard packets.

The listed actions can be performed in any well-known manner. This completes step 340 and the method proceeds to step 350.

At step 350, routes are configured at the central server 101, at the Wireguard level, and also at the GRE level. Moreover, the GRE layer within this solution works on top of the Wireguard layer, which, in turn, works on top of the UDP layer. This means that all packets are first processed at the UDP level, then at the Wireguard level, and only then processed at the GRE level.

As shown in FIG. 2, at the Wireguard layer, the routes on the central server 101 are configured so that all packets that the central server 101 sends to the emitter subnet 230 are sent from IP address 220. Likewise, all packets that the central server 101 sends to the gateways subnet 240 , must be sent from IP address 210.

At the GRE level (not shown in Fig. 2), the central server 101 is assigned one IP address, one address is assigned to each of the gateways and emitters, and at this level the IP addresses of the gateways and emitters are not separated into different subnets, they are all located in one subnet.

The above steps can be performed in any well-known manner. This completes step 350 and the method proceeds to step 360.

At step 360, peers, that is, emitters and gateways, are registered by sending requests to the control interface. The management interface is an interaction interface for managing peers in the distributed network 100: it allows you to add them, delete them, and also obtain information about current peers. In the process of registering each peer through the control interface on the central server 101, the following actions are performed:

- generate a private key for a given peer,

- generate a public key based on the private key,

- allocate (reserve) IP addresses for peers at the Wireguard level,

- add pairs from the public key and the peer’s IP address to the Wireguard interface,

- allocate (reserve) IP addresses for peers at the GRE level,

- add matches of peer IP addresses at the Wireguard and GRE levels to the neighbor table,

- add public key IP addresses to the database at the Wireguard and GRE levels.

The listed actions can be performed by running a configuration file on the server, for example, according to a predefined schedule.

The response to a request to register a peer on a central server is a configuration file containing a private key, a pair of IP addresses at the Wireguard and GRE levels, information about the central server including its public key, and the address and UDP port on which the central server is listening incoming Wireguard packets. Having received the configuration file, it is transmitted in any well-known manner to the peer to be configured via a closed communication channel. This completes step 360 and the method proceeds to step 370.

At step 370, the peers, that is, the emitters and gateways, are configured. To do this, launch the wg-quick utility through a script, which brings up the WireGuard interface and configures it in accordance with the settings saved in the configuration file.

Below is an example of an emitter configuration file, such as emitter 115.

The following is an example of a gateway configuration file, such as Gateway 125.

When applying the emitter configuration file using the wg-quick utility, perform the following actions:

- create a Wireguard interface,

- assign it the private key specified in the configuration file,

- assign an IP address to the Wireguard interface,

- add as a peer the central server 101, located at the IP address 220 specified in the configuration file, with the specified public key and the allowed subnet of IP addresses;

- create a GRE interface that runs on top of the Wireguard interface created earlier.

- assign the specified IP address to the GRE interface,

- add to the neighbor table a correspondence between the IP addresses of the central server at the Wireguard and GRE levels,

- establish routes to all addresses in the GRE subnet through the gateway (central server 101),

- add firewall rules that allow packets to be received and sent through the created Wireguard and GRE interfaces

To configure an emitter, the configuration file is run on the computing device, such as a server, that plays the role of emitter 115.

The gateway configuration process looks similar, but one more step is added: adding firewall rules that nat packets coming from the GRE subnet. When configuring a gateway, the configuration file is launched on the local network of the client 122, on the computing device, for example a laptop, that plays the role of gateway 125.

All of the above steps can be performed in any manner known to those skilled in the subject matter.

This completes step 370 and preparatory stage 300. The method proceeds to execution of operating step 400.

Operational step 400 will be described in relation to FIG. 4A using the example of sending a request from the emitter 115 to the external server 130 and in relation to FIG. 4B using the example of receiving a response from an external server 130 on an emitter 115. This sequence is given for illustrative purposes only and does not limit the described solution; a specialist in the subject area understands that in different situations the order of requests and responses may be different.

Operational step 400 begins as shown in FIG. 4A, from step 410. At step 410, an outgoing traffic packet is transmitted from the emitter 115 to the central server 101. This outgoing traffic packet contains a payload that is intended for the external server 130. The emitter 115 encapsulates the packet before transmitting it, so that that the package looks like this:

- payload level;

- GRE level: the sender’s IP address is the emitter’s IP address at the GRE level, the recipient’s IP address is the external server’s IP address;

- Wireguard level: the sender IP address is the emitter IP address at the Wireguard level, the recipient IP address is the gateway IP address at the Wireguard level;

- UDP level. In UDP packets, the WireGuard port of the emitter is indicated in the sender field of the header, the WireGuard port of the central server is indicated in the recipient field,

- Internet connection level: the local IP address of the emitter is indicated as the sender’s IP address, the public IP address of the central server is indicated as the recipient’s IP address.

In one possible implementation, as shown in FIG. 1, emitter 115 may be behind node 116 and not have its own public IP address. In this case, in the packet at the Internet connection level, the local IP address of the emitter 115 is specified as the sender's IP address. And when sending the packet, the local IP address of the emitter 115, specified as the sender's IP address at the Internet connection level, is also natted. , are replaced with the public IP address of the emitter.

In another possible implementation, emitter 115 may have a public IP address. In this case, this public IP address is specified as the sender at the Internet connection level and natification is not performed.

All of the above actions are performed in any generally known manner.

This completes step 410 and the method proceeds to step 415.

In the example under consideration, the emitter 115 performs analysis of data received from the local network (122, in accordance with Fig. 1) of bank "X". An e-mail sent by an unknown sender to an employee of bank "X" is redirected for analysis to company "G", namely in an isolated environment on the emitter 115. At the emitter 115, a link is followed (a request) to an external server 130, and the execution of this request can means downloading a potentially malicious file from server 130. In order for a potentially malicious file transmitted in response to a request from an external server 130 to arrive at the emitter 115, which is capable of analyzing such files, and not to the user’s machine on the local network 122, this request to the external server 130 is generated at the emitter 115.

At step 415, the central server 101 receives a data packet from the emitter 115. In response to receiving the packet, the central server 101 decapsulates it and identifies the recipient's IP address at the Wireguard level. In other words, at step 415, the central server of company "G" receives the next data packet from the emitter that was previously configured to analyze suspicious traffic coming from the local network 122 of bank "X".

All of the above actions are performed in any generally known manner.

This completes step 415 and the method proceeds to step 420.

At step 420, in response to the discovery, at step 415, as a Wireguard recipient of the IP address of gateway 125, a packet is forwarded from the central server 101 to gateway 125. At the central server 101, the packet is encapsulated so that the packet is as follows: :

- payload level;

- GRE level: the IP address of the emitter 115 at the GRE level is indicated as the sender's IP address, the IP address of the external server 130 is indicated as the recipient's IP address;

- Wireguard level: the sender IP address is the emitter IP address 115 at the Wireguard level, the recipient IP address is the gateway IP address 125 at the Wireguard level;

- Internet connection level: the public IP address of the central server 101 is indicated as the sender’s IP address, and the IP address of the gateway 125 is indicated as the recipient’s IP address.

In one possible implementation, as shown in FIG. 1, gateway 125 may be behind gateway 121 and not have its own public IP address. In this case, in the packet at the Internet connection level, the public IP address of gateway 125 is indicated as the recipient’s IP address, and when the packet is transmitted, denetting is performed.

In another possible implementation, gateway 125 could have a public IP address. In this case, this public IP address is indicated as the sender at the Internet connection level and no denetting is performed.

In other words, at step 420, the central server of company "G" redirects the request received from the emitter, which was configured to work with suspicious traffic of bank "X", to the gateway of bank "X", located on the local network 122 of this bank, for spoofing IP addresses.

All of the above actions are performed in any generally known manner.

This completes step 420 and the method proceeds to step 425.

At step 425, gateway 125 receives a packet from central server 101. In response to receiving the packet, gateway 125 decapsulates, identifies the recipient IP address at the Wireguard layer, and also identifies the recipient IP address at the GPvE layer.

In the example shown, at step 420, on gateway 125 located in the local network 122 of bank "X", data is received from the central server 101 of company "G" containing both the payload (request to the external server 130) and the recipient's IP addresses and sender at the Wireguard and GRE levels, and also identify these addresses.

All of the above actions are performed in any generally known manner.

This completes step 425 and the method proceeds to step 430.

In response to the discovery, at step 425, as the GRE recipient of the IP address of the external server 130, at step 430, the packet is forwarded from the gateway 125 to the external server 130. At the same time, the gateway 125 performs natification of the packet such that the packet has the following form:

- payload level;

- Internet connection level: the IP address of gateway 125 is indicated as the sender’s IP address, the IP address of the external server 130 is indicated as the recipient’s IP address.

In one of the possible implementation methods, gateway 125 may be located behind gateway 126 and not have its own public IP address. In this case, in the packet at the Internet connection level, the local IP address of gateway 125 is indicated as the recipient's IP address, and natification is performed when transmitting the packet.

In another possible implementation, gateway 125 could have a public IP address. In this case, this public IP address is specified as the sender at the Internet connection level and natification is not performed.

In other words, at step 425, natification is performed on a gateway 125 installed in the local network 122 of bank "X". As a result of natification, instead of the IP address of company "G", on the emitter 115 of which the original request was generated, the packet will contain the IP address of gateway 125, which belongs to the address space of the local network 122 of bank "X". Thus, the external malicious server 130, upon receiving the packet, will identify the IP address of the gateway 125 as belonging to the attacked local network 122 and will produce the expected effect, for example, sending potentially malicious content, such as a malicious file.

All of the above actions at this step are performed in any well-known manner.

This completes step 430 and the method proceeds to step 435, described below with reference to FIG. 4B.

At step 435, gateway 125 receives an incoming traffic packet from external server 130. The incoming traffic packet is as follows:

- payload level;

- Internet connection level: the IP address of external server 130 is specified as the sender’s IP address, and the IP address of gateway 125 is specified as the recipient’s IP address.

The packet is received using any well-known method.

After receiving the packet, step 435 ends and the method proceeds to step 440.

At step 440, the packet received at step 435 is forwarded to the central server 101. To this end, gateway 125 queries the routing table and obtains the GRE gateway IP address, that is, the GRE IP address of central server 101. Next, a neighbor table is accessed to obtain the IP address 210 of the central server 101 at the WireGuard level. All these actions are performed in a well-known manner, using standard means of the operating system used on the Gateway 125.

After the packet has been forwarded, step 440 ends and the method proceeds to step 445.

At step 445, the received packet is sent from the central server 101 to the emitter 115. To do this, the packet is encapsulated in such a way that it looks like this:

- payload level;

- GRE level: the IP address of the external server 130 is indicated as the sender's IP address, the IP address of the emitter 115 at the GRE level is indicated as the recipient's IP address;

- Wireguard level: the sender IP address is the IP address of gateway 125 at the Wireguard level, the recipient IP address is the emitter IP address 115 at the Wireguard level;

- Internet connection level: the IP address of the central server 101 is indicated as the sender’s IP address, the public IP address of the emitter 115 is indicated as the recipient’s IP address.

All of the above actions at this step are performed in any well-known manner.

In the given example, at steps 435-445, a potentially malicious file received from external server 130 will be received by gateway 125 and sent to test site 110 of company "G" for analysis, for which it will first be sent from gateway 125 to central server 101, and then from central server 101 to emitter 115.

This completes step 445 and the method proceeds to step 450.

At step 450, the incoming traffic packet is received at emitter 115 and the contents of the payload are analyzed. In particular, in one possible implementation, the analysis may involve detonating (triggering) a malicious file contained in the payload of packets, identifying and studying the actions performed by the launched file, etc.

In the example implementation shown, a potentially malicious file is received at emitter 115 and executed in a sandboxed environment. A sandboxed environment can analyze a downloaded file to determine whether it is malicious or benign. Further, if the analysis showed that the file is safe, then the email in which the link to download this file was received can be marked as safe and delivered to the recipient, an employee of company “X”. All of these actions can be performed by any means well known to one skilled in the art.

This completes step 450 and method 400.

In a preferred embodiment, the central server 101 and emitter 115 may be implemented as a computing device, in particular as a server, a mainframe, or a cloud infrastructure, that is, a collection (cluster) of servers. Alternative implementations are also possible in which the central server 101 and emitter 115 can be implemented like any other computing devices capable of performing the functions described above.

It will be obvious to a specialist that gateway 125 can be implemented as any computing device located in the client’s local network and allowing the implementation of the routing functions described above, for example, as a personal computer, mainframe, server, server cluster, thin client, smartphone, laptop, tablet, etc. etc.

In FIG. 5 will further present a general diagram of a computing device 500 that provides the data processing necessary to implement the claimed solution.

In general, device 500 includes components such as: one or more processors 501, at least one memory 502, data storage means 503, input/output interfaces 504, I/O means 505, data transfer means 506.

The device processor 501 performs basic computing operations necessary for the operation of the device 500 or the functionality of one or more components thereof. The processor 501 executes the necessary machine-readable instructions contained in the main memory 502.

Memory 502 is typically in the form of RAM and contains the necessary software logic to provide the required functionality of the device.

The data storage medium 503 can be in the form of HDD, SSD drives, raid array, network storage, flash memory, optical storage devices (CD, DVD, MD, Blue-Ray disks), etc. The data storage medium 503 allows for long-term storing various types of information, for example, the above-mentioned configuration files, intermediate data, computer-readable program instructions for execution by the processor 501, databases, and the like.

504 interfaces are standard means for connection and operation, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire, etc.

The choice of interfaces 504 depends on the specific implementation of the device 500, which may be a personal computer, mainframe, server, server cluster, thin client, smartphone, laptop, etc.

The data I/O means 505 may be a keyboard. In addition to the keyboard, I/O data tools can also include: joystick, display (touch display), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.

Network interaction means 506 are selected from devices that provide network reception and transmission of data, for example, an Ethernet card, WLAN/Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc. Using tools 506, the organization of data exchange is ensured over a wired or wireless data transmission channel, for example, WAN, PAN, LAN, Intranet, Internet, WLAN, WMAN or GSM.

The components of device 500 are interfaced via a common data bus 510.

In these application materials, options for the preferred disclosure of the implementation of the claimed technical solution were presented, which should not be used as limiting other, private embodiments of its implementation, which do not go beyond the scope of the requested scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims (36)

1. A method of routing traffic within a distributed network, where the distributed network is implemented through two-level tunneling, including: - WireGuard level; - GRE level; a method performed by at least one central server, the method comprising the steps of: - add at least one emitter and at least one gateway to the IP address neighbor table, where - at least one emitter is a peer of a distributed network, configured to analyze malicious content, as well as receive data packets encapsulated at the WireGuard level and at the GRE level; - at least one gateway is a peer of a distributed network, configured to nat at least one packet of outgoing traffic and denatify at least one packet of incoming traffic; - send to at least one gateway the IP addresses corresponding to it in the table of neighbors of at least one emitter; - send to at least one emitter the IP address corresponding to it in the table of neighbors of at least one gateway; - decapsulating, in response to receiving at least one outgoing traffic packet from at least one emitter, at least one outgoing traffic packet; - identify the IP address of the gateway specified as recipient data at the Wireguard level; - encapsulate an outgoing traffic packet at the WireGuard layer and the GRE layer, where at least one IP address specified at the WireGuard layer differs from at least one IP address specified at the GRE layer; - forwarding at least one outgoing traffic packet to at least one gateway for nating. 2. Method according to claim 1, where the IP addresses include: - IP address on the Internet; - IP address at the Wireguard level; - IP address at the GRE level. 3. The method according to claim 1, including registering at least one emitter and at least one gateway on at least one central server by issuing a configuration file. 4. A traffic routing system within a distributed network, where the distributed network is implemented through two-level tunneling, including: - WireGuard level; - GRE level; a system represented by at least one central server that performs steps in which: - add at least one emitter and at least one gateway to the IP address neighbor table, where - at least one emitter is a peer of a distributed network, configured to analyze malicious content, as well as receive data packets encapsulated at the WireGuard level and at the GRE level; - at least one gateway is a peer of a distributed network, configured to nat at least one packet of outgoing traffic and denatify at least one packet of incoming traffic; - send to at least one gateway the IP addresses corresponding to it in the table of neighbors of at least one emitter; - send to at least one emitter the IP address corresponding to it in the table of neighbors of at least one gateway; - decapsulating, in response to receiving at least one outgoing traffic packet from at least one emitter, at least one outgoing traffic packet; - identify the IP address of the gateway specified as recipient data at the Wireguard level; - encapsulate an outgoing traffic packet at the WireGuard layer and the GRE layer, where at least one IP address specified at the WireGuard layer differs from at least one IP address specified at the GRE layer; - forwarding at least one outgoing traffic packet to at least one gateway for nating. 5. The system according to claim 4, where the IP addresses include: - IP address on the Internet; - IP address at the Wireguard level; - IP address at the GRE level. 6. The system according to claim 4, registering at least one emitter and at least one gateway on at least one central server by issuing a configuration file.