Date: Thu, 19 Feb 2004 14:34:02 +0300 From: Andrew Riabtsev <resident@b-o.ru> To: Gleb Smirnoff <glebius@cell.sick.ru> Cc: freebsd-net@freebsd.org Subject: ng_netflow: request for feature Message-ID: <10796883310.20040219143402@b-o.ru> In-Reply-To: <20040218124958.GB40340@cell.sick.ru> References: <20040121114502.GC17802@cell.sick.ru> <20040218124958.GB40340@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10796883310.20040219143402>