argus-clients-3.0.0.rc.14

[Carter Bullard]

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.

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


On Jun 28, 2006, at 11:01 PM, Peter Van Epp wrote:

> 	Time for a feature request :-). There is a neat new feature (not yet
> in the man page) for the argus.conf file:
>
> ARGUS_PACKET_CAPTURE_FILE=/home/vanepp/argus.tcp
>
> which dumps the libpcap data to a file (which can be moved at which  
> point it
> is recreated like the argus file). I just used it to grab the  
> fragmentation
> fault that is causing argus-3.0 to stop on my backbone link. Now  
> what I'd like
> it twofold: for the error to not cause argus to exit (because that  
> provides
> a way to evade argus by continuously sending frags to keep it  
> exited while I
> attack) and instead to write the disagreeable packet in libpcap  
> format to
> a file (ARGUS_PACKET_ERROR_FILE?) so we can see what it was unhappy  
> with and
> then continue in pretty much all cases. That way argus can't be  
> bypassed. With
> sufficient hardware it can do wire speed and there isn't anything  
> an attacker
> can do to not get seen (and we get error packets to look at / fix!).
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>