ng_netflow: request for feature

[Andrew Riabtsev]

Привет Gleb,

Thursday, February 19, 2004, 4:50:42 PM, you wrote:

GS> 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.

GS> Currently there are no memory limits in ng_netflow, so every packet gets
GS> 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.

GS> Yes, I see. This is well known problem. Netflow protocol itself deals with
GS> such kind of problem better than ip accounting, since accounting data is
GS> not stored in memory for long time. However ng_netflow based accounting will
GS> lose some data in case of such DoS. The problem lives in ng_ksocket(4), which
GS> has too small buffer for data, and when a lot of export datagrams are pushed
GS> to it, it returns ENOBUFS. In next releases I'll try to handle this problem
GS> by giving ng_ksocket some time to send data.
GS> I hope some netgraph developers will add some comments here :)

GS> P.S. You know that under DoS conditions user-level ip accounting software
GS> will screw up, while ng_ipacct and ng_netflow will live for some more time.


Thats why im using ipfw-like (only src addr and bytes in/out)
accounting as backup accounting system. Have to as there is one or maybe
two clients in local network who writes modifyed worms which gets into
other clients boxes using 135ish port vulnerability in winXP. And start
spaming accounting system from this not hostile clients boxes. :(

-- 
С наилучшими пожеланиями,
 Andrew                            mailto:resident at b-o.ru