Re: ipnat memory leak?

>
> >  natd chokes on the latest windoze worms and I have implemented some DoS
> >  prevention/worm protection in ipnat but I'm seeing this memory leak
without
> >  my improvements there at all.
> >
> >  If it's in the kernel, ipnat is kept under control when natd would
normally
> >  be sucking the CPU dry and preventing things like remote logins, very
> >  slugish updates, etc...
>
> That seems to be very odd to me.  If anything, putting it in the
> kernel should guarantee that it could runaway with as much memory,
> CPU, etc... as it wanted.
>
> Could you explain a bit more about the added controls you have
> over this process because it's part of the kernel, as opposed to
> operating in user space?
>

OK, fair enough, perhaps I mispoke.  From a system and a control standpoint,
you do technically have more control over a user land process.  The biggest
problem was that I was unable to view the nat table or even really see
anything about what is going on in natd without shutting it down, killing
everyone's connections, fireing it back up and having it spit everything out
at the terminal/session.  Now, doing this remotely with users using the
system get's very very ugly.  natd was spinning out of control and
consequently making the system ultimately completely unresponsive.  I did
not know why and even with it's limited logging capabilities, was having a
difficult time getting at what was going on.

The biggest thing I was after was performance.  I needed more pps throughput
in the system than I was getting with natd.  However, as soon as I put it in
the kernel, ipnat -l and ipnat -t became my best friends.  They are
incredibly useful.

I discovered there are users on our network infected with a variety of the
latest MS worms (and possibly port scanning the internet) and consequently
opening thousands and thousands of connections so the time taking natd to
process a packet was skyrocketing.  It is basically DoS, whether intentional
or not, malicious or not, worm or whatever, it's DoS.

I was quickly able to code up some patches to ip_nat.h, mlfk_ipl.c, and
ip_nat.c to essentially 'rate limit' NAT'd connections so that a few
infected users don't burry my nat box.
BTW, don't worry about the mem leak question...my bad, it was in my patch.
I thought I was using a kernel without my patch when I sent the first
message.  I've added a sysctl value for rate limiting user connections to
prevent DoS such as this when using ipnat.  It works quite well (minus the
mem leak, but I'm working on that!).

Right now it's just a hard limit on max connections while tweaking
fr_defnatage but I will be making it smarter in the future.  I just need
something right now to keep the system from going down.

vec