Date: Thu, 19 Sep 1996 01:10:53 -0700 From: FreeBSD Security Officer <security-officer@freebsd.org> To: freebsd-security-notifications@freebsd.org Cc: security@freebsd.org Message-ID: <199609190810.BAA15858@precipice.shockwave.com>
next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
DRAFT
DRAFT Wed Sep 18 23:22:44 PDT 1996
DRAFT
DRAFT Distribution unlimited, however there are likely to be errors or
DRAFT ommissions in this text. This will be incorporated into a formal
DRAFT FreeBSD Security Advisory as soon as this document has been reviewed
DRAFT and more experience with the system tuning parameters is available.
DRAFT -- pst 18sep96
DRAFT
"Some comments from the FreeBSD Security Officer
regarding recent SYN flooding attacks."
Paul Traina
FreeBSD, Inc.
courtesy of
Juniper Networks, Inc.
How to detect and tune FreeBSD systems to resist SYN flooding attacks.
----------------------------------------------------------------------
(1) How do I know if I'm under attack?
The attack will cause one of the TCP statistics counters in FreeBSD
to increment. Under normal circumstances, this counter will rarely,
if ever, increment, however if connection queues are being overflowed,
we will register this event.
% netstat -s | grep "listen queue overflows"
0 listen queue overflows
If this value is growing rapidly over time, you may be under
at that moment.
If you suspect you are a likely target, we suggest that you
write a script to periodicly check this counter and notify the
appropriate folks if you see it rise rapidly over several polling
periods.
(2) How do I make my FreeBSD system invulnerable to this attack?
The only sure way to stop the attack is to turn off the services that
the attacker is attempting to thwart. Clearly, there are some services
that can easily be eliminated (e.g. the echo and discard services),
but this "cure" is worse than the disease if your service is fundamental
to your endeavors (such as a HTTP server or SMTP server).
There is no sure way of stopping the SYN flood attack. The packets
that are sent appear to be legitimate connection attempts, and as
such, any filter put in place on the destination host designed to
eliminate these requests would deny desired services.
An attacker with a high-bandwidth path to a target host is virtually
unstoppable. We can tune the system to make it resistant to the SYN
flood attack, but a suitably malicious character with significant
resources can cause denial of service attacks several ways (including
tricking the system administrator to inadvertently mis-tune their system
so that legitimate connection attempts now fail).
(3) What can I do about this attack?
First off, there is a bug in the BSD TCP implementation that
causes the system to hold onto resources longer than it should.
Specificly, under some circumstances, the system will hold onto
half-open connections for up to 12 minutes, instead of the anticipated
75 seconds. This bug is documented in Stevens volume 3.
The first thing anyone should do is apply the provided patches to
your FreeBSD system to eliminate this bug.
In addition to fixing this TCP implementation bug, we have added
the ability to tune the kernel on the fly, should an attack be
discovered in progress.
We do not recommend tuning the kernel under normal circumstances.
The default values are perfectly reasonable.
The variables are modified using the sysctl(1) program.
kern.somaxconn - maximum number of entries allowable
in the listen queue per socket
kern.sominqueue - minimum configurable queue length
(override the value passed to the
kernel in the listen() system call)
net.inet.tcp.keepinit - maximum time to wait for connection
to move to established state
You need to be reasonably intelligent when setting these values.
You're "tuning" your system. When a system is under attack, the
nature of the service you are providing and the aggressiveness of
the attack dictate the settings of these parameters. Remember,
it's possible to mis-tune your system so that you will deny
legitimate connection attempts, which means you're doing your
attacker's job.
net.inet.tcp.keepinit
The net.inet.tcp.keepinit variable controls the time the system will
wait for a SYN ACK before tossing away a connection. Since the SYN
flood attack relies on filling up a connection queue until the entries
in the queue are aged out, reducing the time an entry may remain in
the queue will effectively strengthen your system. The default value
of 75 seconds was chosen as a "worst case" where a connection attempt
was started over a high delay link and an acknowledgment or two were
lost along the way, causing one or both sides to retransmit.
Common wisdom today is that this timer may be set as low as 15 seconds
without significantly affecting most legitimate connection attempts.
If you set this timer too short, only "nearby" hosts with highly
reliable links will be able to connect to your services.
kern.somaxconn
The kern.somaxconn variable is a high-water limit on the maximum
number of pending connections a server may request. When a server
is started under BSD, it will request a maximum number of pending
connections. Most servers request "0" which means use the system
maximum (which is controlled by kern.somaxconn). The default value
under FreeBSD is 128 connections. This means that unless a server
requests otherwise, we'll allow up to 128 "pending" connections
on a given tcp port (plus a little fudge factor).
By increasing the maximum length of the connection queue, you
allow more half-open connections to remain active (until they are
expired). Remember though, that each half-open connection requires
the system to maintain some state. If you set the connection queue
length too large, an attacker can run your system out of memory.
Some FreeBSD users have raised this limit to 10000 when under attack
(and restarted their servers so the new limit takes affect) and have
not reported problems.
kern.sominqueue
A given server may request fewer than the system maximum queue
limit. This is usually done in cases where a service is provided
where low response latency is key. If a transaction has sat around
in a queue for a long time, there's no point in completing the
transaction. This isn't the typical case.
If you have such a server, and you are unable to change the code
to eliminate this artificial limitation, there's one thing you can
try. The kern.sominqueue variable overrides any minimum queue
length requests made by the server. The default for this variable
is 0, which means that a server may request a tiny queue and that
request will be respected.
There really should be no reason to override the minimum queue value.
If you do raise it, you may inadvertently affect the operation of
other services operating on the local machine. Basicly, this is a
sledge-hammer approach to tuning the system when no other option is
available.
(4) How do we fix this once and for all?
Unfortunately, this is a vulnerability in the design of TCP. A fair
number of protocol experts are musing over ways to fix this.
The best solutions to date require an authenticated IP layer.
There are changes being made to the Internet infrastructure which will
make it more difficult for attackers to operate without detection, but
for the time being, without a change to the TCP protocol or the addition
of authentication below TCP, there simply is no "solution" that isn't as
bad as the problem itself, despite the claims of "anti-SYN" product
vendors.
(5) Where do I get these patches?
These patches have been incorporated into FreeBSD 2.1-STABLE and
FreeBSD 2.2-CURRENT as of 19-Sep-1996. Updating your source tree
from those code bases and recompiling your kernel will get you the
new code.
Also available are patches relative to the FreeBSD 2.1.5 release.
These patches will be incorporated into an official FreeBSD security
advisory when complete, but for now, you can find them at:
ftp://freebsd.org/pub/CERT/patches/syn-flooding-prerelease/tcp-patches.215
-rw-r--r-- 1 pst security 10142 Sep 19 00:58 tcp-patches.215
MD5 (tcp-patches.215) = f6167c50b8d3302156fc0f9d609e89a7
DRAFT
DRAFT End of draft
DRAFT
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMkD/mlUuHi5z0oilAQGAOwP/SHPTXoPb2uCc/Cx+BdDkoXVNTYbkJWOR
wdM6mnq/oZDUqZpyqZ1q2EZDIjhWgqecioPNg0uFuJHfyx15uQQbDepfW3l4luik
PXhdCR1G8vbAgQKHPVXhRi4dCkhTb7RQLSlZf6+sj7n4JyLSliztFzNxk1Goo5Fs
x5Mbx7aB7ig=
=oOo2
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609190810.BAA15858>