From owner-freebsd-net@FreeBSD.ORG Thu Feb 19 03:32:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C91F316A4CE for ; Thu, 19 Feb 2004 03:32:14 -0800 (PST) Received: from mail.butovo-online.ru (mail.b-o.ru [212.5.78.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FB5943D1D for ; Thu, 19 Feb 2004 03:32:14 -0800 (PST) (envelope-from resident@b-o.ru) Received: from [192.168.92.185] (helo=192.168.92.185) by mail.butovo-online.ru with esmtp (Exim 4.24) id 1AtmYr-0005i3-Jd; Thu, 19 Feb 2004 14:41:45 +0300 Date: Thu, 19 Feb 2004 14:34:02 +0300 From: Andrew Riabtsev X-Mailer: The Bat! (v1.62i) Business X-Priority: 3 (Normal) Message-ID: <10796883310.20040219143402@b-o.ru> To: Gleb Smirnoff In-Reply-To: <20040218124958.GB40340@cell.sick.ru> References: <20040121114502.GC17802@cell.sick.ru> <20040218124958.GB40340@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: ng_netflow: request for feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew Riabtsev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2004 11:32:14 -0000 Hi Gleb, Wednesday, February 18, 2004, 3:49:58 PM, you wrote: GS> Dear collegues, GS> a port of ng_netflow has been just commited to ports GS> tree. It builds both on STABLE and CURRENT, and was tested GS> to work on really busy routers. GS> As before, I'd be glad for any kind of feedback: ideas, GS> patches and else. Thanks. GS> (Also crossposted to -net). Few requests: 1. Is it possible to include ability in that module to turn on rule: (accounted = passed) or other words (not accounted = not passed)? 2. And there is one possible vulnerability. I've tryed ng_ipacct befor, as I undestand ng_netflow source code based on ng_ipacct, and found the following problem. No matter how much free mem has kernel soon or later all mem will be filled with "garbage" if "smart" host generates the following trafic, for example: 14:06:31.194057 95.18.81.203 > 81.176.66.50: icmp: echo request 14:06:31.194058 95.18.81.203 > 81.176.66.50: icmp: echo request 14:06:31.194059 95.18.81.203 > 81.176.66.50: icmp: echo request 14:06:31.194060 95.18.81.203 > 81.176.66.50: icmp: echo request 14:06:31.194061 95.18.81.203 > 81.176.66.50: icmp: echo request ... and so on ... It could be icmp request, or tcp syn, or udp or anything else, the point is to generate as much outgoing packets as it possible, sometimes it does few hosts. The result is huge lag (huge accounting hash table each packet going throw) and very soon box becomes unavalible to do any tasks even routing. Is it possible to include ability to limit amount of records in accounting hash table for src addr? With policy (not accountes = not passed) it will protect box from this kind of attacks. Limiting amount of memory used by accounting table to not let it grow into huge laggy monster leads to fill with "garbage" account table and no more traffic accounting till new check point comes. Or maybe there is other solve of this problem using other networking tools and tricks? -- Andrew mailto:resident@b-o.ru