| Home Prev |  cOS Core 14.00.17 Administration Guide
|
Next |
|---|
A common attack technique is to utilize the distributed topology of the Internet to launch a Denial of Service (DoS) attack resulting in paralyzed web servers that can no longer respond to legitimate connection requests.
To be on the receiving end of a DoS attack is probably the last thing any network administrator wants to experience. Attacks can appear out of thin air and the consequences can be devastating with crashed servers, jammed Internet connections and business critical systems overloaded.
DoS Attack Mechanisms
A DoS attack can be perpetrated in a number of ways but there are three basic types of attack:Consumption of computational resources, such as bandwidth, disk space or CPU time.
Disruption of configuration information, such as routing information.
Disruption of physical network components.
One of the most commonly used method is the consumption of computational resources which means that the DoS attack floods the network and ties up critical resources used to run business critical applications. In some cases, vulnerabilities in the Unix and Windows operating systems are exploited to intentionally crash the system, while in other cases large amounts of apparently valid traffic are directed at sites until they become overloaded and crash.
The cOS Core DoS protection feature works in either or both of two ways:
By examining the source IP for connections being initiated on specified interfaces and then using the IP reputation subsystem to classify the IP as being a known DoS attack source. If it is, the connection is dropped and the source IP added to the blacklist.
By examining the country of origin of the source IP for connections being initiated on specified interfaces and then using an administrator specified list of blocked countries to classify the IP as being a possible DoS attack source. If it is, the connection is dropped and the source IP added to the blacklist.
This feature can be used in conjunction with cOS Core's ability to limit the rate at which new connections on an interface can be opened. Rate limiting is discussed further in Section 7.9, Threshold Rules.
DoS protection is set up with the following steps:
Enable the single DoS Protection object which is predefined in the configuration. Either switch on Enable DoS Blacklist or the Enable Region Blacklist or both to do this.
If Enable Region Blacklist is switched on then select the countries to blacklist.
Specify the interface or interfaces that are to be protected. Normally, only the interfaces connected to the Internet are selected.
When Enable DoS Blacklist is switched on, the DoS protection subsystem functions as follows:
When a connection is initiated on any of the listed interfaces, the source IP is looked up in the blacklist. If it is blacklisted, the connection is dropped.
If not blacklisted, the source IP is looked up in the IP reputation database. If the IP is categorized as being DoS, the connection is silently dropped and the IP is added to the blacklist so that any future connections from that IP will be dropped.
The IP reputation lookup mechanism is discussed further in Section 7.2, IP Reputation.
When Enable Region Blacklist is switched on, the DoS protection subsystem functions as follows:
When a connection is initiated on any of the listed interfaces, the source IP is looked up in the blacklist. If it is blacklisted, the connection is dropped.
If not blacklisted, the source IP is checked against the blacklisted countries. If the IP belongs to a blacklisted country then the connection is silently dropped and the IP is added to the blacklist so that any future connections from that IP will be dropped.
Generated Log Messages
Like similar threat prevention objects, the DoS Protection object only generates a log event message when it triggers and an IP is added to the blacklist. A typical message will have the following form:BLACKLIST prio=2 id=04600006 rev=4 event=host_blacklisted reason="DoS Protection" proto=all srcnet=203.0.113.5 dstnet=0.0.0.0/0 port=all
Example 7.4. Enabling DoS Protection
This example enables DoS protection on the wan interface.
Command-Line Interface
Device:/> set DoSProtection EnableDoSBlacklist=Yes
Interfaces=wanInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Some of the most well-known early DoS attacks during the brief history of the Internet have included the following:
The nature of these classic examples are discussed further in the sections that follow. This section is intended only to illustrate the techniques behind some of the most well known DoS attack types from the past.
This is one of the earliest OSI layer 3/4 attacks in the Internet's history. A simple ways to execute this is to run the console command "ping -l 65510 o.p.q.r" on certain operating systems where o.p.q.r is the IP address of the intended victim. Jolt is the name of one of the purpose-written programs for generating such packets on operating systems whose ping commands refuse to generate oversized packets. Another name for this type of attack is Ping of Death.
The triggering factor is that the last fragment makes the total packet size exceed 65535 bytes, which is the highest number that a 16-bit integer can store. When the value overflows, it jumps back to a very small number. What happens then is a function of how well the victim's IP stack is implemented.
cOS Core will never allow fragments through that would result in the total size exceeding 65535 bytes. In addition to that, there are configurable limits for IP packet sizes in cOS Core's advanced settings.
This type of attack will show up in cOS Core event logs as drops with the IP rule set entry name set to LogOversizedPackets. The sender IP address may be spoofed.
Teardrop and its cousins (including Bonk, Boink, Nestea) are historical examples of Fragment Overlap attacks. Many IP stacks have shown erratic behavior (excessive resource exhaustion or crashes) when exposed to overlapping fragments.
cOS Core protects fully against fragmentation overlap attacks. Overlapping fragments are never allowed to pass through the system.
Teardrop and its followers will show up in cOS Core event logs as drops with the rule name set to IllegalFrags. The sender IP address may be spoofed.
Land and LaTierra are historical examples of attacks that worked by sending a packet to a victim and making the victim respond back to itself, which in turn generates yet another response to itself and so on. This will either slow the victim's machine down or cause it to crash.
The attack is accomplished by using the victim's IP address in the source field of an IP packet as well as in the destination field.
cOS Core protects against this attack by applying IP spoofing protection to all packets. In its default configuration, it will simply compare arriving packets to the contents of the routing table; if a packet arrives on an interface that is different from the interface where the system expects the source to be, the packet will be dropped.
These type of attacks show up in cOS Core event logs as IP rule set drops with the rule name set to AutoAccess, by default, or if the configuration contains custom Access Rule objects, the name of the access rule that dropped the packet. The sender IP address is of no interest since it is always the same as the destination IP address.
WinNuke is an historical example of an attack that worked by connecting to a TCP service that does not have handlers for "out-of-band" data (TCP segments with the URG bit set), but still accepts such data. This will usually put the service in a tight loop that consumes all available CPU time.
One such service was the NetBIOS over TCP/IP service on Windows machines, which gave the attack its name.
cOS Core can protect against this in two ways:
With a careful inbound policy, the attack surface is greatly reduced. Only exposed services could possibly become victims to the attack, and public services tend to be more well-written than services expected to only serve the local network.
By always stripping the URG bit from all TCP segments traversing the system.
This is configurable in the Web Interface by going to:
System > Advanced Settings > TCP Settings > TCP URG.
WinNuke attacks will usually show up in cOS Core logs as normal drops with the name of the IP rule set entry that disallowed the connection attempt.
For connections allowed through the system, "TCP" or "DROP" category (depending on the TCPUrg setting) entries will appear, with a rule name of "TCPUrg". The sender IP address is not likely to be spoofed; a full three-way handshake must be completed before out-of-band segments can be sent.
This category of attacks all make use of "amplifiers" ehich are poorly configured networks that will amplify a stream of packets and send it to the ultimate target. Some historical examples of this include the Smurf, Papasmurf and Fraggle attacks.
The goal with such attacks is excessive bandwidth consumption. That is to say, consuming all of the victim's Internet connection capacity. An attacker with sufficient bandwidth can forgo the entire amplification stage and simply stream enough bandwidth at the victim. However, these kinds of attacks allows attackers with less bandwidth than the victim to amplify their data stream to overwhelm the victim. Techniques include:
Sending ICMP echo packets to the broadcast address of open networks with many hosts, faking the source IP address to be that of the victim. All machines on the open network then "respond" to the victim.
Similar to the above but instead using UDP echo (port 7) to accomplish the task. The amplification can depend on which hosts have the UDP echo service enabled.
Such attacks might show up in cOS Core logs as masses of dropped ICMP Echo Reply packets. The source IP addresses will be those of the amplifier networks used. Others might show up in cOS Core logs as masses of dropped (or allowed, depending on policy) packets. The source IP addresses will be those of the amplifier networks used.
Avoiding Becoming an Amplifier
Even though the full force of the bandwidth stream is at the ultimate victim's side, being selected as an amplifier network can also consume great resources. In its default configuration, cOS Core explicitly drops packets sent to broadcast address of directly connected networks (configurable via System > Advanced Settings > IP Settings > DirectedBroadcasts). However, with a reasonable inbound policy, no protected network should ever have to worry about becoming a smurf amplifier.Amplification Protection on the Victim's Side
Amplification attacks are resource exhaustion attacks in that they try to use up Internet connection capacity. In the general case, the firewall is situated at the "wrong" side of the Internet connection bottleneck to provide much protection against this class of attacks. The damage has already been done by the time the packets reach the firewall.However, cOS Core can still help in preventing attacks from overloading internal servers:
Amplification attacks may be seen as floods of ICMP Echo Responses at the victim side. Unless FwdFast rules are in use, such packets are never allowed to initiate new connections, regardless of whether or not there are rules that allow the traffic.
Packets may arrive at any UDP destination port targeted by an attacker. Tightening the inbound IP rule set can mitigate this risk.
The Traffic Shaping feature in cOS Core can help absorb a packet flood before it reaches protected servers.
TCP SYN flood attacks work by sending large amounts of TCP SYN packets to a given port and then not responding to SYN ACKs sent in response. This will tie up local TCP stack resources on the victim's web server so that it is unable to respond to more SYN packets until the existing half-open connections have timed out.
cOS Core can protect against TCP SYN Flood attacks if the Syn Flood Protection option is enabled in a service object associated with the entry in the IP rule set that triggers on the traffic. This is also sometimes referred to as the SYN Relay option. This option is discussed further in Other Service Properties (including reasons why it may impact performance).
Flood protection is enabled automatically in the predefined services http-in, https-in, smtp-in, and ssh-in. If a new custom service object is defined by the administrator then the flood protection option can be enabled or disabled as desired.
The SYN Flood Defence Mechanism
Syn flood protection works by completing the 3-way handshake with the client before doing a second handshake of its own with the target service. Overload situations have difficulty occurring in cOS Core due to superior resource management and an absence of the restrictions normally placed on other operating systems. While other operating systems can exhibit problems with as few as 5 outstanding half-open connections, cOS Core can fill its entire state table before anything out of the ordinary happens. When the state table fills up, old outstanding SYN connections will be the first to be dropped to make room for new connections.Spotting SYN Floods
TCP SYN flood attacks will show up in cOS Core logs as excessive amounts of new connections (or drops, if the attack is targeted at a closed port). The sender IP address is almost invariably spoofed.ALGs Automatically Provide Flood Protection
It should be noted that SYN Flood Protection does not need to be explicitly enabled on a service object that has an ALG associated with it. ALGs provide automatic SYN flood protection.The Jolt2 type attack works by sending a steady stream of identical fragments at the victim machine. A few hundred packets per second can freeze vulnerable machines completely until the stream is ended.
cOS Core will protect completely against this attack. The first fragment will be queued, waiting for earlier fragments to arrive so that they may be passed on in order, but this never happens, so not even the first fragment gets through. Subsequent fragments will be thrown away as they are identical to the first fragment.
If the attacker chooses a fragment offset higher than the limits imposed by the values specified in System > Advanced Settings > Length Limit Settings, the packets will not even get that far and will be dropped immediately. Jolt2 attacks may or may not show up in cOS Core logs. If the attacker chooses a too-high fragment offset for the attack, they will show up as drops from the rule set to "LogOversizedPackets". If the fragment offset is low enough, no logging will occur. The sender IP address may be spoofed.
A more sophisticated form of DoS is the Distributed Denial of Service (DDoS) attack. These attacks involve breaking into hundreds or thousands of individual computers around the Internet to install DDoS software on them. This allows the hacker to direct the burgled machines to launch coordinated attacks on victim sites. These attacks typically exhaust bandwidth, router processing capacity, or network stack resources, breaking network connectivity to the victims.
Although recent DDoS attacks have been launched from both private corporate and public institutional systems, hackers tend to often prefer university or institutional networks because of their open, distributed nature. Tools used to launch DDoS attacks include Trin00, TribeFlood Network (TFN), TFN2K and Stacheldraht.
