Re: netkill - generic remote DoS attack

[shalunov () ATT COM (stanislav shalunov)]

It seems many people have found my explanation too long to be read.
This is a shorter summary of what it is not and what it is.

        ------------------------------------------------------------

Netkill is not a connect() flood.  The latter establishes connections
and holds them open, making the server to maintain them with a file
descriptors associated with them.

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.  (Thanks to Mixter for pointing out this tool.)
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 (3wahas is) used against services that do print banners (SMTP,
FTP, etc.).  It never works like netkill in "mbuf exhasution" mode.
My analysis of 3wahas sent in response to Mixter's post (don't know if
it made it to the list) is incorrect and should be disregarded.

        ------------------------------------------------------------

Netkill has two variations.  In the one I call "mbufs exhaustion" in
my original posting, the following happens in a loop:

* 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 real 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.  (Tested against large boxes running Linux and
FreeBSD.)

The other variation is less severe and more boring and mundane.  I
call it "process saturation".  It 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).

--
stanislav shalunov,     WHPD,   shalunov () att com     732-576-3252
11:08AM  up 190 days, 31 mins, 6 users, load averages: 0.01, 0.02, 0.03

If you think the problem is bad now, just wait until we've solved it.
                -- Arthur Kasspe