Date: Tue, 01 Oct 2002 17:08:01 -0300 From: "Daniel C. Sobral" <dcs@tcoip.com.br> To: cjclark@alum.mit.edu Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT Message-ID: <3D9A00A1.2070809@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> <20021001195258.GB82099@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Crist J. Clark wrote:
> 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.
This is a 4.7-something. I'd have to search old syslogs to find the
messages, but the reason I think this is happening is simple.
The attack is a Syn Flood. Nothing is affected by the attack except
natd. The symptom with NAT is packet loss (ie, packets enter from one
interface do not exit through the other if they happen to go through
natd). Restarting natd eliminates the symptom immediatly on start (and
then the flood gets to it again). netstat -m shows mbuf clusters peak
equal to maximum, and some hundreds of thousands (maybe more, I don't
recall the exact order, but at least that much) of requests for memory
denied. On syslog, there are messages of packets dropped because of lack
of mbuf clusters.
If the attacker ever went to a host without NAT, we didn't even notice it.
If you have a likelier explanation, I'm all ears.
>
>
>>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.
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo@tco.net.br
Daniel.Sobral@tcoip.com.br
dcs@tcoip.com.br
Outros:
dcs@newsguy.com
dcs@freebsd.org
capo@notorious.bsdconspiracy.net
Exciting plays occur only while you are watching the
scoreboard or out buying a hot dog.
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?3D9A00A1.2070809>