Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Mar 1999 14:26:55 +0100
From:      Eivind Eklund <eivind@FreeBSD.ORG>
To:        Erwan Arzur <erwan@netvalue.fr>
Cc:        security@FreeBSD.ORG
Subject:   Re: natd + nmap ?
Message-ID:  <19990323142655.D40692@bitbox.follo.net>
In-Reply-To: <36F66F86.88FA36E3@netvalue.fr>; from Erwan Arzur on Mon, Mar 22, 1999 at 05:27:50PM %2B0100
References:  <36F66F86.88FA36E3@netvalue.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 22, 1999 at 05:27:50PM +0100, Erwan Arzur wrote:
> I just tried to scan a FreeBDS3.0 w/ natd, and it appears that using the
> -sU flag with nmap seems to completely lock natd at 100% cpu. Thus,
> there is no way to send any packet in or out of the gateway.

And -sU does what?

There are two possibilities: A genuine bug in libalias or natd making
it just spin, or a total overload of libalias.

My very first suspicion would be that this sends a gazillion SYN
packets, and that the active connections table in libalias get
clogged.  If this is the case, fixing it require re-writing a bit of
the data structure handling code for libalias.  I started this about a
year ago, but I dropped finishing it because it seemed pretty useless
- a pure optimization against a piece of software that I'd never seen
be a significant piece of the load on a machine.  I still have the
code, however, if somebody else is interested in finishing it (or
testing/debugging it once I get the time to do the finishing - I do
not have a practical setup for testing libalias at the moment.)

> I am right assuming this is a kind of DOS attack ? Is there any way to
> prevent this kind of thing to happen, like an option to natd to make it
> drop incoming packets when reaching a given load ?

Not with the present code base.

Eivind.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990323142655.D40692>