Date: Tue, 23 Mar 1999 15:30:00 +0100 From: Erwan Arzur <erwan@netvalue.fr> To: Eivind Eklund <eivind@FreeBSD.ORG> Cc: security@FreeBSD.ORG Subject: Re: natd + nmap ? Message-ID: <36F7A568.4ACDBDE4@netvalue.fr> References: <36F66F86.88FA36E3@netvalue.fr> <19990323142655.D40692@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Eivind Eklund wrote:
> 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.
-sU UDP scans: This method is used to determine which
UDP (User Datagram Protocol, RFC 768) ports are
open on a host. The technique is to send 0 byte
udp packets to each port on the target machine. If
we receive an ICMP port unreachable message, then
the port is closed. Otherwise we assume it is
open.
Some people think UDP scanning is pointless. I usu-
ally remind them of the recent Solaris rcpbind
hole. Rpcbind can be found hiding on an undocu-
mented UDP port somewhere above 32770. So it
> 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 can setup my own computer to test your code, if you wish ... One can still
prevent this kind of attack by trusting (divert to natd) only a limited range
of UDP ports, but this would make natd pretty useless, anyway ...
Thanks
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?36F7A568.4ACDBDE4>