argus-clients-3.0.0.rc.14

[Peter Van Epp]

On Fri, Jun 30, 2006 at 09:47:04AM -0400, Carter Bullard wrote:
> Hey Peter,
> Good point, but, we need to fix the fragment problem so you can't attack
> argus that way, first.   So I have corrected the issue with argus  
> exiting,
> and I've made it a condition that you can monitor when debug
> is turned on.
> 
> I'll think about writing offending packets to a file, I''m afraid  
> that that
> in itself is a way to attack argus, so ..., I'll think about it.

	Yes, I hadn't thought of a DOS from that source but you are right.
Perhaps a rate limit (1 packet per second to the output file)? In the normal
case this should be rare and we want the packet for debugging, in the case of
a DOS attempt we don't care about all the packets but probably want to be 
alerted. I also didn't consider this will be doing disk writes on the sensor
machine so I expect writing to a memory file system (to avoid bus contention
issues) will be the preferred method. 

> 
> The problem that you are seeing is that you have the same flow
> going past the probe twice, but in different vlans.  Because the vlan
> tag is not a part of the flow key, the flow is tracked using a single  
> flow
> cache, and so every packet is basically a duplicate.   When we get
> fragmentation in a this scenario, it gets a bit complicated, as  we
> start tracking fragment reassembly with duplicated packets, and thats
> a bit messy.  A part of the problem occurs with the first 'fragment
> completion' packet, where we know that we've seen all the frags
> and its time to update the parent flow with the fragment assembly
> performance stats (argus has that data :o).  The parent flow has a
> reverse pointer to all of its fragment control block, so we can clean up
> stray fragment reassembly buffers, if there is loss, and the flow times
> out.    When we know that the fragmentation tracking is done, we
> deallocate the parents reference to the fragment, update its stats,
> and put the fragment on the general flow timeout queue, so the
> frag control block is still around, but the parent has forgotten about
> it.   When the duplicate 'frag completion' packet comes by, we
> find the correct fragment control block, we know we're done with
> it, we have the pointer to the parent, but the parent doesn't
> have a reference to it, so .....  internal consistency problem.
> 
> OK, the big issue here is that you have the same flow going by
> in different tunnels, and argus thinks its a single flow.  Until I fix
> that, which is a big fix, you will get single flows that are double
> counted, and you won't necessarily see any tracking of the second
> vlan tunnel.
> 
> Carter
> 

	This may get more and more common as the thin client / distributed 
radio central controller wireless becomes more popular or it just may be the
odd configuration of our wireless network at the moment :-). I'll look at the
raw packet log because the VLAN tagging is port based (at least on our switches
I'm not sure what the wireless switch is doing) and this may be the result of
a bug somewhere else :-).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada