From owner-freebsd-current@FreeBSD.ORG Thu Oct 9 17:38:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C496316A4B3 for ; Thu, 9 Oct 2003 17:38:10 -0700 (PDT) Received: from mail.anteva.net (smtp.anteva.net [209.63.222.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DD5243FE0 for ; Thu, 9 Oct 2003 17:38:09 -0700 (PDT) (envelope-from freebsd@itpsg.com) Received: from localhost (fury.anteva.net [127.0.0.1]) by localhost (Postfix) with ESMTP id 4252F83084 for ; Thu, 9 Oct 2003 18:38:09 -0600 (MDT) Received: from mail.anteva.net ([209.63.222.5]) by localhost (fury.anteva.net [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 02605-07 for ; Thu, 9 Oct 2003 18:38:08 -0600 (MDT) Received: from VECTOR (unknown [204.176.204.140]) by mail.anteva.net (Postfix) with SMTP id 60F5483083 for ; Thu, 9 Oct 2003 18:38:08 -0600 (MDT) Message-ID: <02de01c38ec6$a89ebcf0$f501a8c0@VECTOR> From: "Vector" To: References: <008401c38e21$0eb936b0$6afea8c0@VECTOR> <002101c38e2a$fda426f0$8d00a8c0@marcos1> <003001c38e32$87214780$f501a8c0@VECTOR> Date: Thu, 9 Oct 2003 18:37:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at anteva.net Subject: Re: ipnat memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 00:38:11 -0000 > > > 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