25/4/2000
                 Netkill - generic remote DoS attack tool

Details
By exploiting features inherent to the TCP protocol, remote attackers can perform Denial of
Service attacks on a wide range of target operating systems. The attack is most efficient against
HTTP servers.
What Netkill isn't:
- Netkill is not a connect() flood. The latter establishes connections and holds them open,
forcing the server to maintain them using a large number of file descriptors.

- Netkill is not a SYN flood. The latter doesn't establish any TCP connections, but instead
attempts to overwhelm the server with connections in SYN_RCVD state.

- Netkill is not a network bandwidth flood. The latter attempts to eat all available bandwidth
with uninteresting packets.

- Netkill is not 3wahas. The latter behaves in much the same way as a connect() flood, and is
simply a bit faster for daemons that do not print banners (HTTP). 3wahas works like netkill in
"process saturation" mode against HTTP when used against services that do print banners
(SMTP, FTP, etc.). It never works like netkill in "mbuf exhaustion" mode. 

What Netkill is:
Netkill has two variations:

The first variation:
* A connection is established to the target and an HTTP request is sent;
* A process on the target accepts the connection;
* It reads the request;
* It writes some data (up to 16 or 48KB depending on OS) in response;
* It closes the file descriptor;
* The process that handled the connection now exits or moves on.

The net result is that tens of kilobytes of data are held in kernel space, in non-pageable RAM
until the connection (which is in FIN_WAIT_1 state) times out, which takes tens of minutes.
This connection is not associated with any file descriptor or any process.

The RAM used to hold the data is wasted. When we reach a kernel-imposed limit on RAM
utilization for network purposes, or when we fill all RAM if no such limit exists in the kernel, the
machine panics or locks down (This was tested against large boxes running Linux and
FreeBSD).

The second variation:
Netkill lets the processes hang around, thus making this more of a familiar user-space problem
and a configuration issue. Which of the scenarios will unfold depends on the size of the
requested file (mbufs saturation if it's less than an OS-specific limit).

Background:
When the machine performs TCP communication, each TCP connection allocates some
resources. By repeatedly establishing a TCP connection and then abandoning it, a malicious
host can tie up significant resources on a server.

A Unix server may dedicate a number of mbufs (kernel data structures used to hold
network-traffic-related data) or even a process to each of those connections. It'll take time
before the connection times out and resources are returned to the system.

If there are many outstanding abandoned connections of such sort, the system may crash,
become unusable, or simply stop serving a particular port.

Affected systems:
Any system that runs a TCP service that sends out data can be attacked this way. The
efficiency of such attack varies greatly depending on a very large number of factors.

Web servers are particularly vulnerable to this attack because of the nature of the protocol
(short request generates an arbitrarily long response).

Impact:
Remote users can make certain TCP services (such as HTTP) unavailable.

For many operating systems, the servers can be crashed.

Tell-Tale signs:
It is prudent to implement some of the suggestions from the "workarounds" session even if you
are not under attack and do not expect an attack. However, if service is interrupted the
following signs will help identify that a tool similar to netkill is used against you:

* Your HTTP servers have hundreds or thousands of connections to port 80 in FIN_WAIT_1
state.

* The ratio (number of outgoing packets/number of incoming packets) is unusually high.

* There's a large number of connections to port 80 in ESTABLISHED state, and most of them
have the same length of send queue (or, there are large groups of connections sharing the same
non-zero value of the length of send queue).

Workarounds:
There can be several strategies. None gives you complete protection, but they can be
combined.
* Identify offending sources as they appear and block them at your firewall.
* Don't let strangers send TCP packets to your servers. Use a hardware reverse proxy. Make
sure the proxy can be rebooted very fast.
* Have a lot of memory in your machines. Increase the number of mbuf clusters to a very large
number.
* If you're using a Cisco Local Director, enable the "sticky" option. That's not going to help
much against a distributed attack, but would limit the damage done from a single IP.
* If you have a router or firewall that can throttle per-IP incoming rates of certain packets, then
something like "one SYN per X seconds per IP" might limit the damage. You could set X to 1
by default and raise it to 5 in case of an actual attack. Image loading by browsers that don't do
HTTP Keep-alives will be very slow.
* You could fake the RSTs. Set up a BSD machine that can sniff all the HTTP traffic. Kill
(send RST with the correct sequence number) any HTTP connection such that the client has
not sent anything in last X seconds. You could set X to 60 by default and lower it to 5 in case
of an actual attack.

A combination of these might save your service. The first method, while being most labor and
time-consuming is probably the most efficient. It has the added benefit that the attackers will be
forced to reveal more and more machines that they control. You can later go to their
administrators and let them know. The last two methods might do you more harm than good,
especially if you misconfigured something. But the last method is also the most efficient.

Netkill source code in Related > Programming > Sources