Date: Thu, 19 Feb 2004 16:50:42 +0300 From: Gleb Smirnoff <glebius@cell.sick.ru> To: Andrew Riabtsev <resident@b-o.ru> Cc: freebsd-net@freebsd.org Subject: Re: ng_netflow: request for feature Message-ID: <20040219135042.GA46475@cell.sick.ru> In-Reply-To: <199102170052.20040219160209@b-o.ru> References: <20040121114502.GC17802@cell.sick.ru> <20040218124958.GB40340@cell.sick.ru> <10796883310.20040219143402@b-o.ru> <20040219121811.GB46148@cell.sick.ru> <199102170052.20040219160209@b-o.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 19, 2004 at 04:02:09PM +0300, Andrew Riabtsev wrote:
A> GS> In most cases the answer is no. In 90 % cases ng_netflow is used on
A> GS> top of ng_ether(4) node, which passes all data coming on wire. All
A> GS> packet filtering with help of ipfw or ipf are done later.
A> GS> You can try some workarounds using ng_bpf(4) just between ng_netflow
A> GS> and ng_tee(4), but I have not tested such configurations.
A>
A> I meen not filtering, sorry, im talking about ability connect ng_netflow
A> direct to ng_ether upper and lower hooks so if something happend with
A> packet and it was not accounted due to memory overflow or something
A> else this packet will not be transfered to the upper layer or to
A> the ethernet.
Currently there are no memory limits in ng_netflow, so every packet gets
accounted. But not every is sent towards collector (see below).
A> GS> Either you have incorrectly described the situation or you are not
A> GS> right at all. The tcpdump you showed is the perfect situation
A> GS> for any traffic accounting soft, because it does not generate any
A> GS> new entries, it just increments byte and packet counters on one entry.
A>
A> sorry this should looks like this:
A>
A> 14:06:31.194057 95.18.81.203 > 81.176.66.50: icmp: echo request
A> 14:06:31.194058 95.18.81.203 > 81.176.66.51: icmp: echo request
A> 14:06:31.194059 95.18.81.203 > 81.176.66.52: icmp: echo request
A> 14:06:31.194060 95.18.81.203 > 81.176.66.53: icmp: echo request
A> 14:06:31.194061 95.18.81.203 > 81.176.66.54: icmp: echo request
A> ^
A> ^
A> i was trying to make tcpdump output by hands and do this mistake.
A> Now for each of this packets creats new record in accounting table
A> ("garbage" i was talking about) and this is not a problem to make
A> a huge amount of this kind of records in a few seconds.
A>
A> Hope now it is clear. The point of exploit is not only lot of
A> packets, but lot of destination address in short time.
Yes, I see. This is well known problem. Netflow protocol itself deals with
such kind of problem better than ip accounting, since accounting data is
not stored in memory for long time. However ng_netflow based accounting will
lose some data in case of such DoS. The problem lives in ng_ksocket(4), which
has too small buffer for data, and when a lot of export datagrams are pushed
to it, it returns ENOBUFS. In next releases I'll try to handle this problem
by giving ng_ksocket some time to send data.
I hope some netgraph developers will add some comments here :)
P.S. You know that under DoS conditions user-level ip accounting software
will screw up, while ng_ipacct and ng_netflow will live for some more time.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040219135042.GA46475>