BRPI0318587B1 - Method and system for preventing intrusion in communication traffic with a set of machines in a network, and, telecommunications network - Google Patents

Description

Field of the Invention [0001] The present invention relates to techniques for preventing intrusion and deflection.

[0002] The present invention has been designed with particular attention paid to the possible application in securing telecommunications networks. Description of Related Art Typically »there are two types of intrusion detection systems currently in existence.

[0004] A first type of intrusion detection system (commonly referred to herein as a network intrusion detection system or “IDS”) essentially monitors traffic on a given network segment; A second type of intrusion detection system (often referred to as the main computer's IDS) is adapted to monitor events that occur in a specific system.

Both systems analyze data while seeking attacks or acts of policy violation. This is done by exploiting the knowledge and recognition algorithms available to signal or alarm when a match is found. Both approaches have advantages and shortcomings.

The arrangement disclosed in US-A-6 279 113 is exemplary of a network IDS.

As shown in Figure 1, in such an arrangement »an internal or internal network 130 including a set of" machines "such as» for example »internal servers» is protected by an intrusion detection system including a sensor 121. Sensor 121 is adapted to monitor, via an interface 122a, traffic to and from internal network 130 and an external network 110. The system monitors within the data stream those attack configurations that are known and are contained in a database 123. In the event of such an occurrence, a corresponding alarm is issued. A control system 124 of the intrusion detection architecture is also provided and takes care of collecting alarms and presenting them to the end operator, while also managing the entire system. In the arrangement shown in Figure 1, only one sensor is shown. This is a purely exemplary representation in that an intrusion detection network typically includes several sensors located at critical points in the network. Also, on more complex architectures including a large number of sensors, that management system 124 can actually be "hosted" on multiple machines.

In the arrangement as illustrated in Figure 1, the detection role is assigned to a network sensor 121, usually hosted on apparatus which may be a generic computer or a specialized application. The sensor intercepts traffic on a section of the network. This usually analyzes traffic against a set of signatures collected from a 123 database. These need to be updated periodically, and this operation needs to be done on time by the manufacturer / operator whenever new types of attacks occur. become known. Otherwise, the detection system will lose its effectiveness. The signatures under discussion usually include an attack configuration: so even though there is a relatively minor change in configuration, this makes recognition impossible. For this reason, the most sophisticated sensor types usually perform a flow normalization operation of those most common protocols in order to create the best conditions for verification. Certain types of network IDS combine such a configuration match with certain mechanisms for analyzing anomalies, namely variations with respect to the expected behavior of a given protocol. These techniques follow the approach commonly referred to as protocol anomaly detection.

Such a system has a number of advantages.

As the first point, a large network can be monitored through a few properly located network sensors.

Additionally, such a system has minimal impact on the network. The sensors are located at critical points in the network where they monitor traffic without negatively affecting performance.

[00012] Implementation effort is minimal. Said sensors are separate entities with respect to monitored machines and therefore are also independent of them. The same sensor is then adapted to protect machines with different operating systems, providing different services, and so on.

Additionally, said sensors may be made totally undetectable with respect to that network being monitored, based on what is commonly referred to as a covert configuration. Usually, the network sensor is provided with two communication interfaces: a first one (122a-see again Figure 1) is configured in a mixed manner to intercept traffic; the second (122b) is traditionally configured to allow management operations. The monitoring interface is not provided with an IP address, and therefore cannot be addressed. The absence of such an IP address makes it practically invisible to a possible end.

[00014] The major disadvantage of such network-based IDS is that it does not have an accurate knowledge of the state (services offered, software used, actual vulnerability, and so forth) of those machines from network segment 130. being controlled. Said activity of that system is limited to monitoring traffic for attack configuration, not knowing whether they pose a real threat to the systems to be protected.

This results in reduced detection efficiency and increases the number of false alarms. Any time an attack configuration is detected, such a system sounds an alarm, typically having a varying degree of seriousness, depending on the type of attack. This approach produces a large amount of signaling (on a large network, a single sensor can generate a thousand such alarms per day), making it very difficult, if not impossible, to manage such a tool. Additionally, a good number of alarms are indeed false alarms: in reality, the network sensor does not operate intelligently and also alarms when the dangerous packet is addressed to a non-existent machine (the latter being a typical situation generated by tools adapted to automatically generate attacks) or when the machine is not vulnerable to a given attack because it does not provide a specific service or is equipped with an updated and protected software version. This leads to the processing of large amounts of highly irrelevant data, which can, however, be reported with a high degree of severity, with the risk of somehow hiding real alarms and diverting time and resources from tackling real problems.

Another intrinsic limitation of a network-based IDS system is related to insertion and evasion processes as described, for example, by TH Ptacek and TN Newsham in "Insertion, evasion and denial of Service: eluding network intrusion detection", Secure NetWork Inc., January 1998, this being a reference text for intrusion detection systems.

In fact, the IP protocol provides the possibility for certain packets to be fragmented, that is, split into smaller packets before being sent over the network. The maximum size of an IP packet being 65,546 bytes (approximately 64 KB) is poorly adapted to be transmitted over different networks. For example, the maximum size of an Ethernet frame is 1,500 bytes; In case of a Token-Ring network such size is 4KB. In general, the maximum transmission unit (MTU), namely the minimum packet size that can be transmitted at the data link level, can vary significantly from network to network. Therefore, it is clear that such a parameter should limit the maximum size of the IP packet to be transmitted. Fragmentation is therefore provided in the IP protocol, in order to allow data to be carried across different types of networks in a direct transparent manner with respect to higher level and end user protocols.

Within a header of an IP packet, there are essentially two fields for proper management fragmentation: the Fragment Offset field and the More Fragment Marking (MF) field. The offset field identifies the position of the transmitted packet within the data stream, making it possible to reconstruct the correct order of the packets, while the MF mark distinguishes the last fragment from the others. Packages are therefore reassembled by the end user using this information.

It is therefore of utmost importance for the intrusion detection system and protected machines to exhibit the same behavior with respect to incoming fragmented IP packets. In this way, it is possible to avoid the so-called insertion and avoidance phenomenon that can strongly compromise the effectiveness of an intmsion detection system.

[00020] An insertion takes place when IDS accepts and considers as valid certain packets that should have been dropped by the end system to which they are sent, while evasion occurs when IDS does not take into account packets that would be accepted by the end system. In fact, if intmsion detection and the final system to which data is addressed are exposed to different traffic flows, there is a risk that an attack may not be observed by the detection system while reaching the final target.

The same timing issues arise when there is a need to rebuild Transmission Control Protocol (TCP) level data streams. TCP does not implement a fragmentation function, but provides the upper layer with an abstraction that is similar to a continuous stream of characters from a file, while ensuring the order and integrity of this data. These functions are implemented through an interrupt and relay mechanism.

[00022j Each TCP connection is identified by a sequence number. That number is chosen based on the operating system-dependent criterion of the device starting the connection and is incremented by an amount equal to the number of bytes received and acknowledged by means of an acknowledgment indicator (ACK). The sequence number contained in the TCP header is the only data item that makes it possible to identify the status of a given connection and identify and sort the data within the stream being transmitted.

However, it is possible for a packet to be retransmitted when the ACK packet is not received within a certain time, or if an error has occurred during transmission. Relaying reconstructs traffic flow through a more complex intrusion detection system because a packet being resent is intercepted by IDS more than once. The intrusion detection system sees two identical packets being transmitted without, however, being in a position to say which one was actually accepted by the recipient.

[00024] A network-based intrusion detection system, in fact, has no guarantee and no way to verify whether a given packet has been accepted or waived by the final system being monitored. Again, the phenomenon of insertion (IDS accepts and considers valid packets that are waived by the end system) and evasion (IDS does not take into account packets that are accepted by the end system) results in a strong limitation on the detection effectiveness of systems. .

[00025] In both IP and TCP protocols there are other fields that can be manipulated for insertion and evasion purposes (in this respect reference can be made again to the Ptacek article already cited above), thus annihilating the efficiency of an IDS. network based.

Briefly, the basic problem that makes a network-based IDS vulnerable to insertion and evasion is that the IDS and the end system may, in certain contexts, be exposed to two different data streams as they are separate machines with distinct operating systems as well as TCP / IP stack implementations. An attacker can then take advantage of this situation to trigger an attack that is invisible to the protection system.

This limitation, and the aforementioned shortcomings, limit the detection capability of a network-based IDS and derive essentially from the limited knowledge available to the intrusion detection system regarding state and configuration (operating system, software used, services offered, real vulnerability, and so on) of the machines, coming from the network segment being controlled.

A substantially different approach, which dispenses with such limitations, is represented by a master computer-based IDS as shown in Figure 2. An example of such a master computer-based intrusion detection system is described in the document. US-A-5,557,742.

In this case, intrusion detection facilities are no longer a separate entity from the machines being protected. Specifically, on each machine 131 of that internal network 130 to be protected, a sensor 132 is installed which controls the state of the associated machine, for example monitoring the file system, network activity and resource level or utilization. . Typically, a database 133 is provided containing known attack signatures and their policies, as well as a control system 134 which takes care of collecting and processing the alarms generated by the individual sensors, while also managing said entire system.

Again, the real solution may be based on more complex architectures.

Intrusion detection techniques based on a main computer do indeed come from the use of special programs 132a, 132b, ..., which are installed and run directly on the systems being monitored 131 and are adapted to operate at the core or security level. application, for example, to intercept system calls.

Essentially, a main computer-based IDS has a “local” view and controls the state of the machine on which it is “hosted”, for example by monitoring file system, network activity, and usage level. of resources. Said system thus provides definitely improved performance when detecting attacks, having an impact or leaving a trace on the system. Additionally, it can detect non-network attacks such as, for example, intrusions through a console, acquiring higher privileges by a user, typically an organization person, or application attacks.

In order to provide a truly effective main computer-type intrusion detection system, the detection component needs to be installed on the systems being protected. Consequently, the software is specialized for the types of operating systems on which it needs to be installed; There are therefore specialized solutions for Microsoft, Solaris, Unix, and so on.

[00033] Being directly hosted on that controlled system, a host computer based system (HIDS) is open to attack and risks being disabled as is the case with any other programs running on the same machine. A host computer-based intrusion detection system can then be disabled through certain denial of service attacks. Indeed, such a sensor is sensitive to such commands just like the host system.

[00034] The basic limitation of this system is consequently related to its highly invasive character. In order to provide a main computer-based intrusion detection system, a specific software component needs to be installed on each monitored machine, which may also be low level working software (for example, a core module in a Unix system). This can lead to reduced machine performance or even worse conflict with other applications already installed. Additionally, machine-specific settings are required to adjust detection and improve detection effectiveness. This consequence becomes even more critical when "production" machines are considered, offering critical services whose configuration cannot be changed to avoid the risk of making them unstable.

Additionally, a good protection system needs to be in a position to block detected attacks before they can damage the protected systems. Most of these traditional systems are not able to provide active responses in the face of a detected attack; they merely perform their role by providing a more or less detailed alarm (depending on the administrator's specifications and tool lockability) through different communication channels (starting from the flickering signal on a console for an e-mail message). personal email).

Thus there are conventional techniques which also provide an active response, namely, implying a real action aimed at stopping the flow of dangerous traffic towards those interior network systems. These include elimination and immediate update of protective barrier rules sessions.

Session deletion is the most common and simplest way to react to a detected intrusion: a network error message (such as an unreachable destination ICMP packet or a TCP protocol restart included in the RST tag) received by the TCP / IP stack causes said communication to be closed. In the event of a detected attack, the IDS system sends properly spoofed TCP, RST, or ICMP packets to make the machine being attacked unreachable by the attack itself, thereby blocking the dangerous session.

Such a technique needs to be implemented in such a way as to be rapid: if the system does not react promptly, it may not be able to block the flow of dangerous traffic or may eventually intervene when damage has already occurred. One should simply think of an attack whose dangerous content is limited to a single packet: this is a borderline case where a countermeasure as described is totally useless.

[00039] An arrangement that is made use of in some intrusion detection systems to react to an attack then provides cooperation with a protective barrier by modifying its rules in real time. In this way, the intrusion detection system “teaches” the protective barrier to break all connections coming from a detected attacker's IP address to block the flow of dangerous traffic. Depending on the different implementations the added rule (s) may be canceled after a given period of time or several attacks are required to isolate a certain IP address.

However, this technique may not be exempt from the same limitations affecting the other techniques previously considered. It is effective for attacks exploiting a shell obtained through an exploit (in which case the exploit is executed, but the shell obtained is no longer reachable) but becomes useless for those attacks such as attacks (DOS) services that exhaust their contents in a few packages or even in only one package.

An intrinsic limitation of these techniques is that they are not prevention techniques, as they do not act before the package reaches the target. In fact, they react only after an event has occurred and the even quick reaction always follows the occurrence of a suspicious event, such as the transit of a given packet. The only acceptable way to overcome this limitation is to integrate a protective barrier function into the intrusion detection system by performing a "line" intrusion detection system.

Such an arrangement is described, for example, in US-A-6 513 122 and is generally depicted in the block diagram of Figure 3.

Specifically, the block diagram of Figure 3 shows the architecture of an inline intrusion detection system 310, where the internal network 130 is separated from the external network 110. Such a system can be seen as an evolution of the system based on network shown in Figure 1, where the network sensor becomes a bridge separating the network to be protected from the external network.

The system typically includes three network interfaces, two of which (311a and 311b) operate at the second level (“level 2”) of the TCP / IP stack, enabling the device to act as a bridge while maintaining invisibility at the level. from the Web. These interfaces monitor all traffic in transit from and towards internal network 130. A third interface 311c manages the system. The device collects all traffic to and from internal network 130 and detects via known intrusion detection components 312b the known attack configurations contained in database 313. In the presence of an attack via the intrusion barrier component protection 312a, the system can prevent single dangerous packets from traversing the device and reaching the target, thereby implementing an intmsion prevention action. Reference 314 designates a system management module.

Again, the typical block diagram shown in Figure 3 corresponds to a simplified architecture: real situations may in fact involve more complex architectural solutions.

Compared to the more traditional arrangements previously discussed, the arrangement shown in Figure 3 operates as a kind of bridge between the external network 110 and the network to be protected 130, acting as a connection point for the internal network. Operating at level 2 with 311 interfaces, it maintains the IP invisibility typical of a network-based system. Additionally, the intrusion detection system 310 shown in Figure 3 collects, acting as a connection point for the internal network, all traffic from and towards the network, managing it through protective barrier functions. (312a) and intrusion detection functions (312b). This way, the system can analyze traffic for 'suspicious' packets. Upon detecting an intrusion (via component 312b), it can then block the intrusion by means of protective barrier component 312a, preventing it from passing to the other interface.

[000471 This reaction technique acts before a suspicious packet reaches the target. thereby implementing true prevention mechanics. The limitations of the prior art arrangement considered above are then overcome, with the possibility of detecting and blocking attacks eaten in a single package as well. [00048J] However, even the arrangement shown in Figure 3 still suffers from the previously described and related shortcomings as the case of network-based systems for the lack of precise knowledge of the state of the machines coming from network segment 130 being controlled. In fact, also the arrangement shown in Figure 3 limits your intervention to monitoring traffic while looking for attack configurations, without knowing however whether this could pose a real threat to protected systems.

Purpose and Summary of the Invention The object of the invention is therefore to provide an arrangement to protect intrusion systems and networks, adapted to detect dangerous packets before they can reach the machines on a protected network.

Particularly, the present invention aims to provide a system adapted to address the problem also with "unknown" attacks, while ensuring the security of, for example, production machines where dedicated software is not currently installed.

"Unknown" attacks are generally referred to as attacks that have not been previously tried by the system and / or for which no information has been previously stored in the system.

According to the present invention, that object is achieved by a method having the characteristics reported in the following claims. The invention also relates to a corresponding system, a network equipped with such a system, as well as a computer program product, loadable into the memory of at least one computer and including portions of code and software for performing the steps of the method. invention when the product runs on a computer. As used herein, reference to such computer program product is intended to be equivalent to reference to a computer readable medium containing instructions for controlling a computer system to coordinate the performance of the method of the invention. The reference to "at least one" computer is of course intended to highlight the feasibility of the arrangement of the invention to be implemented in a decentralized manner.

A preferred embodiment of the invention therefore avoids intrusion on communication traffic with a set of machines in a network, traffic comprising communication entities identified by their configurations. A test system including test facilities replicating at least one of the machines in the set is provided, and at least a portion of the communication entities in said traffic are directed to the test system where test facilities are performed to detect possible effects. adverse effects on the test system. In the presence of an adverse effect, the reporting entities leading to the adverse effect are blocked. In the absence of an adverse effect, communication with the set of protected machines is allowed to the communication entities and no longer leads to an adverse effect.

Communication entities directed to the test system include communication entities obtained from the traffic boundary towards and / or from the protected machine pool.

[00055] The arrangement described here then achieves protection by "virtualizing" the actual protected machines on a set of test machines.

[00056] The arrangement described here is particularly suitable for use in association with a protected network, subdivided into areas grouping similar systems, each area being protected by an inline system that includes intrusion detection, intrusion deflection and test system components. .

In a preferred embodiment, the system recognizes dangerous, "harmful" communication entities (eg, packets) and permitted, "harmless" packets by blocking the former and allowing the latter to pass: this is based on the respective identifier settings stored in two databases. The intrusion deflection component deflects in the direction of the test component those packages whose nature and possible defects in protected machines are unknown (that is, not known with sufficient reliability). The test component system where internal network systems and services (ie protected machines) are replicated, "executes" the communication entity and then verifies its actual effect on the replicated system.

If the test shows a dangerous negative effect, the packet is not returned to the deflection system and therefore cannot reach the protected machines on the internal network. If the packet that is found to represent a “good” packet, it is redirected to the intmsion deflection component to be sent to those machines on the internal network.

In either case, the respective identifier settings (that is, signatures) can be used to update the databases possibly present in the intrusion detection component.

In addition, the arrangement described herein provides an architecture that retains the advantages of all prior art arrangements while dispensing with the intrinsic deficiencies of those (network-based) intrusion detection systems having insufficient available knowledge of the systems. finals. The arrangement described herein also avoids the intrinsic intrinsic nature of a main computer-based intrusion detection system, while ensuring that potentially dangerous traffic is blocked and its propagation is not allowed to protected machines.

BRIEF DESCRIPTION OF THE ATTACHED DRAWINGS [00060] The invention will now be described, by way of example only, with reference to the figures included in the drawings, where: Figures 1 to 3, related to the prior art, have been described previously, a block diagram showing the general layout of an arrangement as described herein; and Figures 5 and 6 are typical operating flow charts of the arrangement described herein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION As indicated previously, the typical arrangement described herein provides network protection through the joint action of the two basic components, namely a network component that collects and analyzes network traffic through a network element. interior line, and a component that, although different from end machines, operates on a local level, [00062] In most instances, the servers to be protected are production machines whose settings are not adapted to be modified, and where new Software components are not suitable to be installed in order to avoid service instability.

[00063] The arrangement described here therefore creates a test environment where services and machine configurations on the internal network are replicated. The test environment allows the effect of any potential hazardous communication entity (for example, a packet) to be tested before it actually achieves the actual service. If the package is found to be good, it is redirected to the machines on the internal network. Otherwise, this is blocked. Thus, an intrusion prevention architecture is provided, where attacks are detected and blocked before they can reach the target, thus significantly reducing the number of false positive alarms, packets being blocked only after verifying that they are truly dangerous. Additionally, the arrangement described here is also effective for detecting unknown attacks, namely attacks for which a subscription is not yet available.

Specifically, the block diagram of Figure 4 shows an internal network 130 separated from the external network 110 by an inline component 410. That component includes four network interfaces, two of which (those indicated by 411a and 411b) operate at level 2, allowing the device to act as a bridge while maintaining network-level invisibility and also monitoring all traffic in transit from and towards the internal network 130.

A third interface 411c provides system management while a fourth 41 ld interface connects the inline component to the test environment 420.

The inline component analyzes all traffic to and from internal network 130. Through intrusion detection component 412b it detects any “illegal” or “harmful” attack configurations of a known type (ie that is, those communication entities whose signatures are contained in database 415). In the event of such an occurrence, the system prevents, via protective barrier component 412a, that single hazardous packets pass through the device and reach the target, thereby performing an intrusion prevention action.

Conversely, traffic recognized as “legal” or “harmless” (ie those communication entities whose signatures are contained in database 416) is allowed to traverse the inline component 410 and then reach the servers in the internal network. 130

When the inline component 410 receives packets that are not recognizable as legal or illegal based on the signatures contained in databases 415 and 416, the concerned packets are redirected to the test environment or environment 420 via interface. 41 ld.

Test environment 420 is comprised of one or more test machines 421 that replicate the servers or, less preferably, part of the servers (definitely even a single server) on the internal network 130 and a system 422 adapted to check status. to detect possible attacks. In a minimal implementation system 422 may coincide with a main computer based intrusion detection system as shown in Figure 2.

After testing, those packets kept as legal are given back to the inline component 410 which redirects them to the servers on the internal network 130, while the illegal packets are blocked.

[00071] The test environment is also connected to management network 414 to allow updating of information contained in databases 415 and 416.

[00072] In more detail, each single packet is analyzed through joint action of the protective barrier module 412a and the intrusion detection module 412b.

In the first instance, the protection barrier module 412a verifies the legal nature of the packet: for example, this is done by performing packet filtering based on source and destination addresses and ports, while blocking potentially illegal packets. Subsequently, the intrusion detection module 412b analyzes the packet application contents based on the database contents 415 containing the known attack configurations to be blocked, and the database 416 containing those configurations included in the traffic. allowed explicitly.

If component 412b detects an attack, it is blocked before it can reach systems on the internal network. Conversely, if an explicitly permitted traffic entity is detected, such traffic is allowed to traverse the system and reach network 130 via interface 411b.

[00075] The rest of the traffic, which is neither explicitly legal nor explicitly illegal, is viewed as “suspicious” traffic.

It will be appreciated that the prior art systems of Figures 1 to 3 do not handle such "suspicious" traffic: as a function of the occurrence, it is processed as legal and allowed to pass or as illegal and then blocked. This mode of operation increases the risk of generating both false negative alarms (illegal traffic that is processed as legal traffic) and false positive alarms (legal traffic that is processed as illegal traffic).

Conversely, in the arrangement described here, suspicious traffic is diverted towards test system 420 via interface 41 ld. Test machines 412 receive all suspicious traffic collected by interface 411a and process each single packet in the same manner as such packets would be processed by actual machines on the internal network 130.

In practice, the 422 system checks the status of machines by detecting intrusion at the local level of detail (which would be unrealistic for a network-based sensor), while also having the ability to check the effect of each single packet, or even every single command on the machines themselves. In this way all suspicious traffic is processed and, depending on the result of such processing, is finally classified by the test system 422 as legal or illegal, without possibility of errors.

[00079] If a suspicious packet is found to be legal, it is redirected to the system's inline component 410, which in turn sends it to the end user, who can then continue communication. Conversely, if a suspicious packet is considered illegal it is not sent to the inline system nor any response from test machines 421 is sent towards the external network 110. The packet is blocked and the corresponding alarm reaches the operator via management system 417. .

It will be found that by exploiting the cooperation of two different types of intrusion detection arrangements, one of network type 412b, included in an inline element 410 and one main computer based type component, integrated into the test system. 420, the arrangement described here overcomes the intrinsic limitations of traditional approaches by dispensing with one side of the false alarm problem, while on the other hand solving the problem related to the invasive nature of the main computer-based system.

The arrangement operation, as shown in Figure 4, will now be described with specific reference to the flow charts of Figures 5 and 6.

In a step 510, each received packet is processed by the protective barrier element 412a operating at the network level and transport level. Therefore, header data at levels 3 and 4 are analyzed in step 520 to verify the legal nature of traffic from and towards certain specific IP addresses and ports and the possibility of blocking - in step 521 - illegal traffic .

Subsequently, in a step 530, the packet is parsed by the intrusion detection element 412b which detects attacks based on the signatures contained in database 415. An attack can be conducted by one or more level 3 packets (eg example a so-called “Ping of Death”) at level 4 (eg “SYN FloocT) and the application level (eg a so-called“ Buffer Overflow ”).

[00084] When an attack is detected, the corresponding packet is blocked in step 531 and is not redirected to interface 411b. Consequently, it does not reach the servers on the internal network 130, while a corresponding alarm is issued in a step 532, which reaches the network administrator via management system 417.

If no attack is detected, a similar configuration matching process is started in step 540 to verify the possibly explicit legal application contents of the package. The corresponding signatures are contained in database 416 and are typically signatures reporting the legal request settings that the servers obtained from their clients.

Accordingly, these configurations are heavily dependent on the application services provided by the machines on the internal network 130. If explicitly legal or permitted, each single packet is redirected to the end servers in one step 541 via interface 411b. Servers handle packet processing, which generally involves issuing, in one step 542, a response to clients on the external network 110.

If the packet does not match any of the signatures in database 416 and database 415, then it must be arranged with an “unknown” element that is neither explicitly illegal nor explicitly legal or permissible. Such a package is therefore processed as a suspicious element.

Specifically, such suspicious traffic is deflected towards test system 420 via interface 411b, which occurs in a step 550. Test environment 420 receives 1 1 suspect packets and processes them as shown in Figure 6.

Each packet received in step 610 is processed by test machines 421 in step 620. Specifically, test machines 421 replicate the servers on internal network 130: a test system 422, which - as indicated - can correspond in A minimal implementation of a main computer-based intrusion detection system as shown in Figure 2 checks the state of the machines 421 to detect possible intrusion in a step 630. The detection system 422 operates at a local level of detail and, therefore, you can check the effect of each single package, or each single command, on the machines themselves.

If a suspicious packet is considered legal, in step 640 it is redirected via interface 41 ld to the inline component 420 of the system which in turn sends it to the end systems in internal network 130. These can therefore , continue, in one step 641, communication with clients on external network 110. Alternatively, the packet may be redirected to inline component 410 via management network 414.

Conversely, if a suspicious packet is considered illegal, in a step 631 it is blocked so that it is not redirected to the inline component, nor is any possible response sent from test machines 421 to external network 110.

Additionally, a set of parallel independent actions is performed in step 632 to 635.

First, an alarm is generated in step 632, which reaches the network administrator via management system 417.

[00094] A reboot action is also performed in a step 633 for the possibly compromised test machine (s). Such a step may consist, for example, of restoring a partition on a disk based on a previously generated disk image stored on system 422 which, by controlling the test machines, manages the entire environment 420.

In addition, using traditional techniques, the elimination of the session in progress can be performed in step 634 once the illegal nature of the communication is established.

[00095] The described arrangement performs a step 635 to update the rules contained in database 415. This is intended to progressively improve the effectiveness of detection. Once the hazardous nature of a given traffic flow has been verified, the test system 422 may revise the rules contained in database 415 governing the behavior of the inline component 410 in the system such that if said traffic flow traffic manifests again, it is immediately blocked without being redirected to the test system.

Additionally, the system may include a mechanism for transmitting, in one step 636, the update information towards other intrusion detection systems, possibly of a traditional type, such that these systems may exploit the new signatures. to detect intrusion. Thus, an effective approach is implemented to automatically generate signatures in the presence of new attacks.

Similarly, if the package is considered legal, in one step 650 the rules in database 416 are correspondingly updated.

This synergy of the main computer-based component and inline component in the system, which leads to improved detection effectiveness, is realized through the 414 management network, to which both 422 and 416 inline component test systems. belong.

In this way, the described system issues, in steps 532 and 632, alarms only on the occurrence of a real intrusion, that is, only in the presence of packets that, overcoming the protective barrier 412a, would reach the systems in the internal network. with a possibility of negatively affecting their operation.

This signaling action has a purely informational value, since any dangerous attack has already been blocked by components in systems, such as inline component 410 or test environment 420.

In fact, those machines on the internal network 130 are addressed only traffic which: - in step 541, is kept as explicitly legal because their signatures are contained in database 416, or - has been positively tested without causing any damage on the test machines - at step 640.

[000102] Dangerous traffic is then prevented from reaching the internal network, thereby giving rise to an intrusion prevention situation.

In addition, all traffic from and towards internal network 130 is analyzed in the system, inline component 410 and possibly in the main computer-based component integrated in test system 420.

[000104] An attack is acknowledged blocked by inline component 410 (if its signature is present in database 415) or by test system 420 (which in turn updates signatures in database 415).

Conversely, legal traffic is recognized by the inline component (if explicitly allowed by a policy in database 416), otherwise it traverses the test system before reaching the destination server. Also in the latter case, the auto-update mechanism of policies in database 416 increases the effectiveness of detection as it reduces cases of suspicious traffic being deflected towards the test system.

In fact, the system processes as suspicious traffic, to be diverted towards test system 420, all those packages / commands that are not explicitly prohibited or explicitly allowed, depending on the rules in databases 415 and 416.

[000107] These are typically attacks whose outcome cannot be predicted except at the local level. This is for example the case that: - attacks that do not compromise true endpoint vulnerabilities or that end servers are in a position to avoid, being provided with proper repairs that would most likely generate false alarms, - attacks that are not only real testing performed on single machines can detect, or - traffic fragments - at any level - that cannot be correctly reconstructed, thereby avoiding dropout and insertion problems as described above, other than operating at the local level at a specific machine.

It will be appreciated that the fragmentation problem described above referring primarily to level 3 and a TCP stream also exists at the application level. At this level, the elementary communication entity or unit is the single command and this can also be arranged in such a way as to bring an attack. Typically, an application command is contained in a single package, but if this were not the case, the intrusion detection system must be in a position to correctly reconstruct it to detect possible attacks on it.

[000109] A very simple example of application level fragmentation is represented by a generic text-type protocol such as HTTP or SMTP. Usually, interaction with the web server or mail server is done by sending full command characters in a single package. This significantly increases network efficiency. However, it is possible to use the various independent packages to send the same request. For example, any time an attacker directly queries the web server or mail server of an interactive tool (for example, TELNET) the request sent to the server is fragmented into multiple packets, each containing a single character once This is the logic commonly used by interactive applications. If the intrusion detection system is not in a position to rebuild the total conversation and performs configuration matching only at the level of a single packet, such manipulation would be sufficient to invalidate the detection mechanism.

[000110] For example, the following HTTP request exploits a well-known phf program vulnerability to access the password file on a Unix system: GET / cgi-bin / phf Qalias = x% 0a / bin / cat% 20 / etc / passwd [000111] If an interactive tool is used to enter such a request, 50 (fifty) separate packets are generated, each including a single character. The intrusion detection system can detect this attack only by completely rebuilding the data stream. In order to do this, however, the intrusion detection system needs to be able to understand when a request is terminated. Additionally, you need to keep track of ongoing sections and use interruptions to avoid exhaustion of the resources required to keep track of all separate conversations. Additionally, each time traffic flows must be rebuilt, the intrusion detection system is exposed to the evasion and insertion problems where described earlier.

[000112] A traditional intrusion detection system is not able to cope effectively with this problem.

Conversely, the arrangement described here has the advantage that traffic is not reconstructed by the sensor although this reconstruction action is performed by the 420 test system. In fact, all traffic that is not explicitly prohibited, or explicitly permitted by policies in databases 415 and 416 are handled as suspicious and deflected towards test system 420.

Consequently, if the previously reported command is fragmented into 50 packets, the first packet, including the single character G, cannot be resolved correctly and is redirected to test system 420.

The single package does not contain any illegal payload, nor can it compromise test machine 421. As a result, detection system 422 redirects it to the final system without risk. Similarly, each single package included in the total command is redirected by the inline component 410 toward test machines 421; detection system 422 verifies the nature of single packets and redirects them to the end systems.

When the detection system 422 detects the dangerous nature of the command being formed, it immediately stops its flow. This can occur, for example, by appearing the: cgi-bin / phf character included in a given signature.

Consequently, the system preserves its effectiveness also in the event that the "unknown" nature of the attack relies on such an attack being provided in an evasion / insertion attempt, for example by fragmenting it into several packages / entities that - per se - they are “innocent”. As shown in the considered example, the dangerous nature of the command is in any case verified when the last packet (the 51st) is sent, including the ENTER character, beginning the execution of the entire command.

At that point, the test environment intrusion detection system 422 detects the anomalous behavior of system 421 that attempts to access the password file, detects such behavior as illegal, and therefore blocks 51st packet transmission in the direction of the final systems. In this way the execution of the command is avoided and the attack made debatable.

Additionally, an alarm may be issued to provide evidence of the danger avoided and update database 415 to allow inline component 416 to detect the future command (if sent in a single packet) and automatically blocking its transmission.

Thus, hazardous command is not performed on end systems on internal network 130, and communication with the hazardous user is interrupted by traditional methods of “eliminating” the section while the interrupted current section is annihilated by application.

The relay mechanism described leads to test machines 421 never actually providing any response to user requests, since there is no communication between test environment 420 towards external network 110. This practically means that Testing machines 421 in test environment 420 are inhibited from providing traffic responses: in fact, communication with users is always closed only by servers on the internal network.

Also, the arrangement described herein is adapted to operate also on communication entities obtained from the distant traffic of the machine set comprising the internal network 130, in order to possibly direct any unknown entity towards the test environment 420.

These provisions lead to additional enhanced security against those attacks, possibly relying on any kind of information coming from internal network 130 and / or the ability to intercept responses from servers on internal network 130 to maintain synchronization at the network level. TCP.

Those skilled in the art will readily verify that this is not necessary for the 420 test machines to be a complete, full copy of the machines (servers) on the internal network 130. Essentially, the 420 test machines reproduce the software configuration of the servers. internal network such as operating systems, software versions used, services offered. This allows intrusions to be properly detected.

However, it is not necessary for test machines 420 to fully reproduce servers on internal network 130 as far as application content is concerned.

[000126] The mechanism just described is particularly suitable to be applied when the internal network 130 is made up of machines offering homogeneous services. This facilitates the establishment of the test environment 420 and makes detection really effective right from the start.

[000127] Such a situation is common in so-called server farms, large Internet service providers, or data processing departments of large companies. There, in order to enable easier and more effective management in terms of software upgrades and global management, there is a tendency to group those machines offering homogeneous services or similar software configurations into common areas.

By implementing the relay mechanism described at the single packet level, the problem of fragmentation at level 3 as well as at the application level can be completely resolved as described in the previous example.

In the sense of being fully assured of problems related to TCP flow level fragmentation, all sessions are preferably mapped, diverting any TCP packets, namely those directed to the internal network 130, to the test system. from interface 411a and the corresponding responses provided by the servers on network 130 passing over interface 411b. Thus, the test environment 420 may not lose sight of all active sessions on the end systems, and are therefore perfectly matched with respect to system state.

[000130] Those attacks exploiting evasion and insertion situations at TCP levels are very difficult to interpret. Accordingly, test environment 420 may not be required to include resources at a very high level as required to detect such really unlikely attacks. Consequently, a judicious balance can be balanced by adjusting the traffic diversion mechanism towards the test environment in such a way as to avoid such a really costly and predictably unnecessary intervention.

Of course, without prejudice to the fundamental principles of the invention, the details and embodiments may also vary appreciably with reference to what has been described by way of example only, without departing from the scope of the invention as defined by the appended claims. .

Claims (35)

Method for preventing intrusion into communication traffic with a set of machines (130) in a network, said traffic comprising communication entities, characterized in that the fetus comprises the steps of: - providing a test system (420) including testing facilities. (421) replicating at least one of said machines in said assembly (130), - directing at least part of said communication entities in said traffic towards said test system (420), and - i) in the presence of a adverse effect, blocking the communication entities leading to said adverse effect, and - ii) in the absence of an adverse effect, permitting communication with said set of machines (130) to said communication entities no longer leading to said adverse effect. * Method according to claim 1, characterized in that at least parts of said communication entities directed to said test system (420) include communication entities from the limited traffic towards said assembly (130). machines, Method according to claim 1, characterized in that at least parts of said communication entities directed to said test system (420) include communication entities from the traffic coming from said set of machines (130). Method according to claim 1, characterized in that it includes the steps of: - providing a database (415) which includes representative configurations of prohibited communication entities for communication with said set of machines (130) blocking (412a) prohibited communication entities in said traffic as identified by their respective configurations included in said database (415). Method according to claim 1, characterized in that it includes the steps of: - providing a database (416), which includes representative configurations of communication entities allowed for communication with said set of machines (130) permitting communication of the communication entities allowed in said traffic as identified by their respective configurations included in said additional database (416). Method according to claim 4, characterized in that it includes the steps of: - detecting unknown communication entities in said traffic as identified by the respective unknown configurations not included in said database (415), and - directing the entities unknown communication signals in said traffic as identified by respective unknown configurations not included in said database (415) towards said test system (420) to be performed on those test facilities (421) to detect possible adverse effects on said system (420). Method according to claim 6, characterized in that it includes, in the presence of said adverse effect, the step of adding to said database (415) its respective configuration identifying the communication entity leading to said adverse effect. A method according to claim 5, comprising the steps of: - detecting unknown communication entities in said traffic as identified by their unknown configuration not included in said additional database (416), and - directing the unknown communication entities in said traffic as identified by their unknown configurations not included in said additional database (416) towards said test system (420) to be performed on those test facilities (421) to detect possible adverse effects on the said test system (420). Method according to claim 8, characterized in that, in the absence of said adverse effect, it includes the step of adding to said additional database (416), the respective configuration identifying the communication entity no longer leading to said adverse effect. Method according to claim 1, characterized in that it includes, in the presence of said adverse effect, the step of subjecting to a reset step those among said test facilities (421) in said test system (420) affected by said adverse effect. A method according to claim 1, characterized in that the machines in said assembly (130) including facilities exposed to said adverse effect, as well as additional contents, include the step of configuring said test facilities (421) in replicating said facilities exposed to said adverse effect on the machines in said assembly (130). A method according to claim 1, characterized in that it includes the step of inhibiting said test machines (421) in said test system (420) of providing responses to said traffic. Method according to claim 1, characterized in that it includes the steps of: - providing an in-line component (410) ensuring said traffic with said set of machines (130), and - providing at least one interface ( 411 d) interfacing said inline component (410) with said test system (420). A method according to claim 13, characterized in that it includes the step of providing feedback from said test system (420) to said in-line component (410) via said at least one interface (411 d ). A method according to claim 13, comprising the steps of: - providing a management network (414) for managing said test system (420), and - providing feedback from said test system. (420) to said in-line component (410) via said management network. Method according to claim 7, characterized in that it includes the steps of: - providing a parallel intrusion prevention arrangement, including a respective database including the representative configurations of the respective prohibited communication entities, for communication. with a respective set of machines, - in the presence of said adverse effect, transmitting to said parallel intrusion prevention arrangement for inclusion in the respective database their respective configuration identifying the communication entity leading to said adverse effect. Method according to claim 9, characterized in that it includes the steps of: - providing a parallel intrusion prevention arrangement including respective additional database including representative configurations of the respective communication entities allowed for communication with a respective set of machines, - in the absence of said adverse effect, transmit to said parallel intrusion prevention arrangement, for inclusion in its additional database, its configuration identifying the reporting entity no longer leading to said adverse effect. 18. A system for preventing intrusion into communication traffic with a set (130) of machines in a network, said traffic comprising communication entities, comprising: - a test system (420) including replicating test facilities (421) at least one of said machines in said assembly (130), - a communication module (410) configured to direct at least part of said communication entities in said traffic towards said test system (420), wherein said communication entities directed to said test system (420) are adapted to be performed on said test facilities (421) to detect possible adverse effects on said test system (420), said communication module (410) being additionally configured for - i) in the presence of an adverse effect, block the reporting entities leading to such adverse effect, and - ii) in the absence of an adverse effect adversely, permits communication with said set of machines (130) to the communication entities by failing to lead to said adverse effect. System according to claim 18, characterized in that said communication module (410) is configured to include in said at least part of the communication entities directed to said test system (420), communication entities to from limited traffic towards said machine assembly (130). A system according to claim 18, characterized in that said communication module (410) is configured to include in said at least part of the communication entities directed to said test system (420), communication entities to from the traffic from said set of machines (130). System according to claim 18, characterized in that it includes: - a database (415) including representative configurations of communication entities prohibited for communication with said set of machines (130), - a barrier module of protection (412a) configured to block prohibited communication entities in said traffic as identified by their respective configurations included in said database (415). System according to claim 18, characterized in that it includes: - an additional database (416) which includes representative configurations of communication entities allowed for communication with said set of machines (130); communication module (410) configured to allow communication of communication entities permitted in said traffic as identified by their respective configurations included in said additional database (416). A system according to claim 21, characterized in that said communication module (410) is configured to: - detect unknown communication entities in said traffic as identified by their unknown configurations not included in said database ( Directing the unknown communication entities in said traffic as identified by their unknown configurations not included in said database (415) towards said test system (420) to be performed in said test facilities (421). ) to detect possible adverse effects on said test system (420). A system according to claim 23, characterized in that said communication module (410) is configured to add to said database (415), in the presence of said adverse effect, its configuration, identifying the transmission entity. communication leading to such adverse effect. A system according to claim 22, characterized in that said communication module (410) is configured to: - detect unknown communication entities in said traffic as identified by their unknown configuration not included in said additional database. (416), and - directing the unknown communication entities in said traffic as identified by their unknown configurations not included in said additional database (416) towards said test system (420) to be performed in said test facilities. (421) to detect possible adverse effects on said test system (420). A system according to claim 25, characterized in that such communication module (410) is configured to add to said additional database (416), in the absence of said adverse effect, its configuration identifying the transmission entity. failure to lead to such adverse effect. System according to claim 18, characterized in that said test facilities (421) in said test system (420) are configured to withstand reboot following said adverse effect. A system according to claim 18, characterized in that the machines in the assembly (130) include facilities exposed to the adverse effect as well as additional contents, while the test facilities (421) replicate the facilities exposed to the adverse effect. machines in said assembly (130). A system according to claim 18, characterized in that the test machines (421) in said test system (420) are inhibited from providing responses to said traffic. System according to claim 18, characterized in that it includes: - an in-line component in the communication module (410), ensuring said traffic with said set of machines (130), and - at least one interface ( 411 d) interfacing said in-line component (410) with said test system (420). System according to claim 30, characterized in that the test system (420) is configured to provide feedback to said in-line component (410) via said at least one interface (41 ld). A system according to claim 30, characterized in that it includes a management network (414) for managing said test system (420) and said test system (420) is configured to provide feedback to said component in line 410 via said management network. A system according to claim 24, characterized in that it includes an associated parallel intrusion prevention arrangement including a respective database including representative configurations of the respective communication entities prohibited for communication with a respective set of machines, and said communication module (410) is configured to transmit, in the presence of said adverse effect, to said parallel intrusion prevention arrangement, for inclusion in its database, its configuration identifying the communication entity leading to said adverse effect. A system according to claim 25, characterized in that it includes an associated parallel intrusion prevention arrangement, which includes a respective additional database, including representative configurations of the respective communication entities allowed for communication with a respective set of machines, and said communication module (410) is configured to transmit, in the absence of said adverse effect, to said parallel intrusion prevention arrangement, for inclusion in its additional database, its configuration identifying the communication entity no longer driving said adverse effect. Telecommunication network (110,130), characterized in that it includes the system as defined in any one of claims 18 to 34.