- Clavister CorePlus 8.x, 9.x
- Clavister cOS Core 10.x
This article explains the mode of operation of a number of denial-of-service tools, how Clavister Security Gateway may be used to protect against them, and how they may be detected in logs.
- The Ping of Death / Jolt attacks
- Fragmentation overlap attacks: Teardrop / Bonk / Boink / Nestea
- The Land and LaTierra attacks
- The WinNuke attack
- Amplification attacks: Smurf, Papasmurf, Fraggle
- The TCP SYN Flood attack
- The Jolt2 attack
The "ping of death" is one of the earliest layer 3/4 attacks. One of the simplest ways to execute it is to run "ping -l 65510 220.127.116.11" on a Windows system where 18.104.22.168 is the IP address of the intended victim. "Jolt" is simply a purpose-written program for generating such packets on operating systems whose ping commands refuse to generate oversized packets.
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.
Clavister Security Gateway 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 the "Advanced Settings" section. The largest default value is for UDP: 60000 bytes.
Ping of death will show up in Clavister Security Gateway logs as drops with the rule name set to "LogOversizedPackets". The sender IP address may be spoofed.
Fragmentation overlap attacks: Teardrop / Bonk / Boink / Nestea
Teardrop and its followers are fragment overlap attack. Many IP stacks have shown erratic behavior (excessive resource exhaustion or crashes) when exposed to overlapping fragments.
Clavister Security Gateway protects fully against fragmentation overlap attacks. Overlapping fragments are never allowed to pass through the Security Gateway.
Teardrop and its followers will show up in Clavister Security Gateway logs as drops with the rule name set to "IllegalFrags". The sender IP address may be spoofed.
The Land and LaTierra attacks
The Land and LaTierra attacks works by sending a packet to a victim and making the victim respond back to itself, which in turn generates yet another response to itself, etc etc. This will either bog the victim's machine down, or make it 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.
Clavister Security Gateway 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 Security Gateway expects the source to be. Land and LaTierra attacks will show up in Clavister Security Gateway logs as drops with the rule name set to "Dropped by Default_Access_Rule" by default, of, if you have written custom Access rules, the name of the Access rule that dropped the packet. The sender IP address is of no interest; it is always the same as the destination IP address.
Note that appyling wide-open "Accept" rules in the "Access" section will disable this protection.
The WinNuke attack
The WinNuke attack works 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.
Clavister Security Gateway protects 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 stripping the URG bit by default from all TCP segments traversing the Security Gateway (configurable via Advanced Settings -> TCP -> TCPUrg).
Amplification attacks: Smurf, Papasmurf, Fraggle
This category of attacks all make use of "amplifiers": poorly configured networks who amplify a stream of packets and send it to the ultimate target. The goal is excessive bandwidth consumption - 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 attacks allows attackers with less bandwidth than the victim to amplify their data stream to overwhelm the victim.
- "Smurf" and "Papasmurf" send ICMP echo packets to the broadcast address of open networks with many machines, faking the source IP address to be that of the victim. All machines on the open network then "respond" to the victim.
- "Fraggle" uses the same general idea, but instead using UDP echo (port 7) to accomplish the task. Fraggle generally gets lower amplification factors since there are fewer hosts on the Internet that have the UDP echo service enabled.
Fraggle attacks will show up in Clavister Security Gateway 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 brunt of the bandwidth stream is at the ultimate victim's side, being selected as an amplifier network can also consume great resources. In its defalt configuration, Clavister Security Gateway explicitly drops packets sent to broadcast address of directly connected networks (configurable via Advanced Settings -> IP -> DirectedBroadcasts). However, with a reasonable inbound policy, no Security Gateway-protected network should ever have to worry about becoming a smurf amplifier.
Protection at the ultimate victim side
Smurf, and its followers, are resource exhaustion attacks. More specifically: they exhaust your Internet connection. In the general case, the Security Gateway 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 Security Gateway.
However, Clavister Security Gateway may be of some help in keeping the load off of internal servers, making them available for internal service, or perhaps service via a secondary Internet connection not targeted by the attack.
- Smurf and Papasmurf floods will be seen as 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.
- Fraggle packets may arrive at any UDP destination port of the attacker's discretion. Tightening ones inbound ruleset may help.
- Traffic Shaping may also help absorb some of the flood before it reaches protected servers.
The TCP SYN Flood attack works 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 machine until it is unable to respond to more SYN packets until the existing half-open connections have timed out.
Clavister Security Gateway will protect against TCP SYN Flood attacks if "SynRelay" is enabled in the rule or service allowing the traffic. By default, this is the case for the "http-in", "https-in", "smtp-in", and "ssh-in" services.
The "SynRelay" 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 do not occur nearly as easily in Clavister Security Gateway due to much better resource management and lack of restrictions normally placed upon a full-blown operating system.
While a normal operating system can exhibit problems with as few as 5 outstanding half-open connections, Clavister Security Gateway can fill its entire state table (thousands or millions of connections, depending on your Security Gateway model), before anything out of the ordinary happens. When the state table fills up, old outstanding SYN connections will be among the first to be dropped to make room for new connections.
TCP SYN Flood attacks will show up in Clavister Security Gateway 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, but if you can find a reasonable number of subnets as source address, you can setup Access Rules to block incoming traffic from those hosts.
The Jolt2 attack
The Jolt2 attack works by sending a steady stream of identical fragments at the victim machine. A few hundred packets per second will freeze vulnerable machines completely until the stream is ended.
Clavister Security Gateway will protect completely against this attack. The first fragment will be enqueued, 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 Advanced Settings -> LengthLim, the packets will not even get that far; they will be dropped immediately.
Jolt2 attacks may or may not show up in Clavister Security Gateway logs. If the attacker chooses a too-high fragment offset for the attack, they will show up as drops with the rule set to "LogOversizedPackets". If the fragment offset is low enough, no logging will occur. The sender IP address may be spoofed.
There are many more denial-of-service tools in the wild. Many are combination ("swiss army knife") attacks, and many are simply renamed versions of those described above.
We have chosen to present what we believe are relevant and representative forms of denial-of-service attacks. If you believe that there are one or more tools that should be in this list, please contact email@example.com and tell us the names of the tools that you would like to see explained here.