Date: Tue, 1 Oct 2002 12:52:58 -0700 From: "Crist J. Clark" <crist.clark@attbi.com> To: "Daniel C. Sobral" <dcs@tcoip.com.br> Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT Message-ID: <20021001195258.GB82099@blossom.cjclark.org> In-Reply-To: <3D99EEBE.2010403@tcoip.com.br> References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> <3D998142.8070005@tcoip.com.br> <20021001174546.GB81932@blossom.cjclark.org> <3D99EEBE.2010403@tcoip.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 01, 2002 at 03:51:42PM -0300, Daniel C. Sobral wrote:
> Crist J. Clark wrote:
> >
> > [diet quote]
> >
> >Sure, but even if you do everything in the kernel, you're still using
> >some mbufs. Could you be more specific about how one would DoS a
> >machine running with natd(8) and divert(4) that would not affect a
> >machine doing some type of NAT in the kernel? Just saying, "it uses
> >mbuf clusters," isn't enough for me to understand what type of
> >resource exhaustion you are talking about and how it can be
> >exploited. Please draw me a picture. I'm a bit slow today.
>
> All I know is that the machine, running simply as a firewall/router,
> does not suffer from mbuf cluster exaustion. Does not come even close to
> it. Does not even notice a DoS in progress. As soon as there is a
> network connection _to_ the firewall, in this case the natd divert
> socket, this memory starts to get used and, during a DoS, exausted.
But that's what I'm saying, there is not a network connection _to_ the
firewall by an attacker. There are no addtional sockets are created by
an attacker, there is nothing consumed socket-wise. There is a single
socket opened when natd(8) starts up and it is the only socket ever
used (well, there are are some cases where natd(8) can consume more
sockets, but you'd actually have to turn this behavior on). If you
were to throw an attack at a ipfw(8)-natd(8) box, the first thing you
are probably going to start to feel is natd(8) slowing down. If you
are using dynamic rules in ipfw(8), they might cause issues in the
kernel, but NAT'ing actually doesn't consume any kernel memory
resources since it is all done in userland.
It may be possible to cause a d(enial|egredation) of service in a
ipfw(8)-natd(8) firewall through various attacks, but consuming
sockets, and therefore kernel memory associated with a socket, is not
a mechanism.
It sounds like you are actually getting attacked and seeing problems?
Could you show us the data that makes you think that this is related
to socket-mbuf problems? There could easily be some obvious mechanism
that I'm not seeing. What type of attacks are these?
Oh, and what version of FreeBSD is this machine running. There used to
be problems with natd(8) trying to resend data when sendto(2) failed
rather than dropping.
> How's and Why's are really beyond me. It's just a matter of what I see
> happening.
>
> >Also, remember that when you push NAT into the kernel, you now need to
> >find some place in kernel memory to jam the NAT state table. It opens
> >up lots of new problems too. NAT in kernel or userland has lots of
> >pros and cons each way.
>
> Now go back to the subject and read it again. Static nat does not have a
> state table. It need not keep state because it is, well, static.
natd(8) always has a state table. NAT code that simply rewrote the
destination address on incoming packets to a certain IP and the source
on the ones going out from that IP would not be very useful to most
people. If that's all you are going to do, why not just really put the
address on the destination machine and just route the packets normally?
So, one could do this, but the code wouldn't be useful to very many
people.
> It isn't much different, really, from fwd. fwd changes the next hop,
> static nat changes one ip address and possibly the next hop.
But you have the traffic going back out too. And natd(8) and most
other NAT implementations assume that there will be other traffic
going back out as well.
> >>>If you don't want to do natd(8) and divert(4), you can do ipfw(8)
> >>>'fwd' on each machine.
> >>
> >>No, fwd is not nat. I need nat.
> >
> >Nope, 'fwd' is not NAT, but you can get arbitrary packets from the
> >network in front of machine A to a socket on machine B with two
> >'fwd's. Depending on your needs, that may or may not be
> >sufficient. (One big trip-up is if machine B is not FreeBSD for
> >example.)
>
> I need fake ip servers being visible from outside. I need to change
> destination addresses which are routed to through OSPF, _after_ the
> firewall. Neither of these are possible with fwd.
Right, the other big trip-up that I was thinking of adding seems to
be yours. 'fwd' is only useful if the target machine is one hop away.
I've got some generic code that would be easy to modify to do what you
want, but it to uses a divert(4) socket. If you're convinced that
divert(4) is the problem, then it wouldn't be any help.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021001195258.GB82099>