WO2006040201A1

WO2006040201A1 - Method and apparatus for denial of service defense

Info

Publication number: WO2006040201A1
Application number: PCT/EP2005/053758
Authority: WO
Inventors: John Kevin Brown
Original assignee: Siemens Aktiengesellschaft
Priority date: 2004-09-02
Filing date: 2005-08-02
Publication date: 2006-04-20

Abstract

Data flow regulation is achieved for a telecommunications network having at least one host for providing a source of 5 data and a server for routing and regulating telecommunications. A detector detects a data flow of a particular data source positioned to detect the data flow at the host or emitting from the host. A mechanism causes the data flow of the particular data source to be regulated when 10 the data flow detected by the detector exceeds a data flow rate threshold.

Description

Tit le

Method and Apparatus for Denial of Service Defense

Description

A Denial of Service attack is an attempt to saturate the network resources of a network device, rendering it inaccessible and, in some cases, inoperable. Faulty equipment can also be responsible for similar network overloading. Malicious Call attacks or faulty equipment can cause excessive traffic and can seriously impact the performance of a server/host machine. In the worst case scenario, an overloading of the network could cause a system crash.

While the system can be made more secure at the user/application level, hardening a system at the network level can often be more problematic. It is possible to "lock a door" to prevent access to the physical machine, but the network access will always be accessible. In the past, networks were 'protected' by a firewall or using layer 3 switch. High end switches may have a rate control function to protect against overloading.

However, the previous solutions were not adequate. For cases in which client computers connect via layer 2 switches or hubs, for example, firewalls and layer 3 switches are ineffective. The potential aggressor simply avoids the protective layer by accessing the layer 2 switch. In the matter of High end layer 3 switches, they are expensive and, as in the layer 3 switch, assumes that there is some 'box' between clients and the host to be protected.

In client/server based environments, the server is a 'weak link' in a network. As shown above, this 'weak link' is a prime target for network attacks. The previous solutions are insufficient to protect against such attacks. In addition, Denial of Service attacks can be difficult to detect by pattern checkers as there is no set ^Λpattern' for the data.

What is needed is a method and apparatus that effectively combats and protects from Denial of Service attacks. And, in addition, protects against overloading due to network or equipment failures.

SUMMARY

A method and apparatus are provided for regulating the data flow of a telecommunications network having at least one host for providing a source of data and a server for routing and regulating telecommunications. A detector detects a data flow of a particular data source positioned to detect the data flow at the host or emitting from the host. A mechanism causes the data flow of the particular data source to be regulated when the data flow detected by the detector exceeds a data flow rate threshold.

In an environment in which real time traffic monitoring at the router level is not practical, the present invention allows a linux or Solaris box to act as a monitor on traffic rates .

In the case of a Denial Of Service attack, the present invention blocks any further packets from the offending source IP address automatically by tracking the traffic rate per IP address. This will prevent a single malicious source from utilizing costly resources or, in extreme cases, bringing down a host system due to exhaustion of resources.

As packets enter the system, the invention tracks the flow rate of predetermined IP addresses and, if configured threshholds are exceeded by the source IP address, the IP address source is blocked. In one case, a firewall system is called (ipf or iptables) to block that IP address. This may be done for a particular length of time, which may be configurable.

The monitoring device may be a preprocessor plugin, such as, for example Snort. Snort is an existing open source

Intrustion Detection System. Although, it is not important to the invention which device monitors the packet flow. For example, for purposes of traffic rate/DoS attacks, tcpdump or similar methods of packet sniffing can be alternatively used.

Advantageously, the present invention provides a cost effective solution to the DoS problem. No special hardware is required with the present invention.

Further, the invention provides a flexible solution to the problem of DoS. By providing that the protection mechanism is provided by the host, such a self-protection system reduces the dependency on certain router types, or even using a firewall/router device at all for DoS.

On the contrary, the invention may be used on hosts or dedicated firewall/lDS systems alike and is not necessarily limited to host systems.

The invention further provides minimal performance overhead on the host. In testing, the present invention resulted in an average of 3% CPU usage and 12MB of memory at peak.

DETAILED DESCRIPTION

The present invention was developed in response, in part, to actual DoS attack. In that instance, a customer attempted to ^Λbreak' a Siemens HiQ ™ Softswitch by saturating the network with UDP packets targeting the ports. As a result, the device went down.

An investigation following the attack led to the discovery that packet flow analysis is done inconsistently and may be performed only on a few routers/firewalls. It is noted that many providers at present maintain their systems in this way. In fact, Microsoft, SCO, and others at present lose their servers periodically. In some cases, the reason was due to a DoS attack. In others, the problem was a system failure. In any event, there are no solutions, until now, that fit a cross platform environment.

As mentioned above, a problem in the past was that the attackers can bypass the protection mechanisms because there is no intermediary router or firewall. Since it is possible that in some environments and for some applications there might not be an intermediary between the clients and the servers, a host based solution would be desirable. Hereinafter, a host based system shall also be referred to as a Self-Protection system.

In the present invention, a monitoring system was decided for and, more particularly, a packet monitoring mechanism is employed to monitor the packets. In one aspect of the invention, the system utilizes a packet sniffer, for example, Snort, tcpdump, etc, to listen in on the IP data stream in parallel to the application level.

The Intrusion Detection System called Snort was selected and tested. Snort is an open source application and runs on many platforms. It allows for easy creation of preprocessors, and is an excellent DoS framework. Alternatively, tcpdump libraries could be used and extended to provide the same functionality.

The sniffer is allocated to a localized or host network. This prevents aggressors from bypassing the protection system because the monitor is directly located at the source.

In the invention, the source of the packets is monitored to determine an amount of data coming from a particular source. This may be done, for example, using an IP/hash index method along with the localized packet sniffer. In particular, a subset of the IP address can be used as a hash table index in which a counter is pegged for each packet that corresponds to the monitored IP address. If the number of data packets emitting from a particular source exceeds preset thresholds, the system could be triggered to halt further data packet flows from that source.

In one aspect of the invention, the monitoring of a particular packet source is time limited. This may be done, for example, by periodically clearing the table index. For example, a table entry for a particular data packet source may be cleared. In effect, this would control, or limit, a rate of the data packets from a certain source.

It would also account for DHCP clients which may have their IP address changed. In other words, it would not be advisable to monitor only a particular client, because that client's address may change. Rather, it is advisable to watch data sources that have a history of sending data packets .

It shall be appreciated that this solution could be used in virtually any system to protect itself against external as well as internal attacks.

Figure 1 illustrates the typical network flow 100. An IP packet 102 is transmitted and is forwarded through a network card 104, is placed as part of a kernel 106 and placed on a stack. Eventually, the packet is transmitted by the application 110.

Figure 2 illustrates a DoS protected network flow 200. As in the previous figure, an IP packet 202 is transmitted and is forwarded through a network card 204, is placed as part of a kernel 206 and placed on a stack. Eventually, the packet is transmitted by the application 210. Here, a rate monitor 212, which may be a preprocessor, detects the rate of packets or data. Here shown detecting data from the IP stack, although anywhere in the flow of data is possible. The data rate is recorded in a log, such as the syslog 214 shown. The data rate is also sent to the firewall device 216 which then regulates, or halts, the data flow in order to prevent overloading of the network.

As earlier discussed, the invention may include a table 300 according to Figure 3 that tabulates the data flow rates. In one aspect, the table includes an IP address 304.

Optionally, the time may be added into a time column 306.

The number of packets counted is entered into the packets column 308. The IP address 310 is inserted into the IP address column 304 and may be segmented by an array index

312.

An operation of the invention with reference to Figure 3 may be given as follows. As shown in the figure, a packet 314 has a particular address, here 165.218.204.123, which may be inserted into the IP address 304 column. The time is noted, here 100000, in column 306. And the number of packets, here 1, is entered into the packets column 308.

Referring again to Figure 2, the rate monitor 212 detects the flow rates of packets corresponding to a particular address. As noted above, the address detected may be a portion of the address, such as the root address. This is done in order to detect DoS attackers who may have alternate sub-root addresses. The rate monitor 212 then enters, or sends the detected rate to be entered, into a storage area, such as the table mentioned above. If the data rate of a particular source address exceeds a predetermined threshold, then the firewall 216 causes the data flow to be reduced or halted.

As earlier mentioned, the detection mechanism may employ a sniffer, such as the known Snort open-source application. Of course, the invention may also employ other sniffer applications or mechanisms as mentioned above.

The detector, as earlier mentioned, is preferably positioned to detect the data flow at the host. This is to defeat the ability of aggressors to access the network through the Layer 2, thus bypassing firewalls or other protection schemas. Of course, the invention may be positioned elsewhere in the network.

The threshold will depend in the invention on the particular network resources and capacity and will be different for each network. Therefore, a particular threshold shall not be given here. Although, suffice it to say that it is well known how to determine an appropriate threshold for a particular system and need not be discussed here.

As mentioned above, the time of the data packets may be monitored. In this way, a frequency of the packets is also detected. If the number of packets over a period of time is high, i.e., a high frequency of packets, from a particular source, then the invention may also decide that there are too many packets within that time interval. In this way, the invention may also detect and defend against quick bursts of attacks.

Also, the invention may use the timing of the data packets in order to decide when to reset the counter. In other words, and as mentioned above, the count of the data packets is reset to, for example, 0. This is done in order to allow legitimate data flows to proceed without disruption. The timing of the reset is also a matter of particular network character and a specific number shall not be mentioned here. That is, any and all time periods for resetting the counter are possible within the invention.

The log 214 may be used for administrative and evidentiary purposes. A system administrator desiring to overview the activities of the network may be able to do so by examining the syslog. In addition, DoS attacks which are illegal may be proven to convict aggressors using this log, as the log establishes an automatic and objective recording of the data flows of the network.

The invention is contemplated to be used with dedicated firewall systems to dynamically react to network flooding.

In addition, the invention may be used with hosts/servers, particularly those with no external protection from network flooding or DoS attack. The technique of the invention can be used on any server or network device to protect itself from

'network overload' .

The invention may be implemented as a software solution. Hence, a dedicated firewall/IDS system with this software could be applied. Another application may be a server running such software.

Claims

1. A data flow regulation apparatus for a telecommunications network having at least one host for providing a source of data and a server for routing and regulating telecommunications, comprising:

a detector for detecting a data flow of a particular data source positioned to detect the data flow at the host or emitting from the host,

a mechanism for causing the data flow of the particular data source to be regulated when the data flow detected by the detector exceeds a data flow rate threshold.

2. The apparatus according to the previous claims, wherein the detector detects data packets.

3. The apparatus according to the previous claims, further comprising a table for tabulating results of the detector.

4. The apparatus according to the previous claims, wherein the detector detects a timing of the data flow.

5. The apparatus according to the previous claims, further comprising a counter for counting a number of data packets from the particular source.

6. The apparatus according to previous claim 5, further comprising a reset mechanism for resetting the counter.

7. The apparatus according to the previous claims, further comprising a log for recording the activity of the telecommunications network detected by the detector.

8. The apparatus according to the previous claims, wherein the detector is a sniffer application.

9. A method for regulating a data flow for a telecommunications network having at least one host for providing a source of data and a server for routing and regulating telecommunications, comprising the steps of:

detecting a data flow of a particular data source positioned to detect the data flow at the host or emitting from the host,

causing the data flow of the particular data source to be regulated when the data flow detected by the detector exceeds a data flow rate threshold.

10. The method according to the previous claim 9, further comprising the step of halting the data flow when the data flow detected by the detector exceeds a data flow rate threshold.

11. The method according to the previous claims 9-10, further comprising the step of formulating a table for tabulating the results of the detecting.

12. The method according to the previous claims 9-11, further comprising the step of timing the data flow.

13. The method according to the previous claims 9-12, further comprising the step of counting the instances of the data emitted by the particular source.

14. The method according to the previous claim 13, further comprising the step of resetting the counting.

15. The method according to the previous claims 9-14, wherein the data are data packets.