Argus Flow reversal with ECRs ??

[Russell Fulton]

On Thu, 17 Feb 2000 06:37:06 -0800 Carter Bullard 
<cbullard at nortelnetworks.com> wrote:


>    The idea was/is that since Echo is a strick
> Request/Response protocol, we should be able to
> infer the correct Src/Dst relationship based on
> this protocol.  Argus does not care, it simply
> tracks based on the first packet seen in a flow.
> Ra() wants to correct the condition where the
> first packet seen was an Echo Reply.  Thats why
> the arrows are drawn in the wrong direction.

Sorry, I though I was saying that the way ra currently handles it is 
OK ;-) From your reply I get the impression that you think I'm still 
complaining <grin>.

I understand what ra is trying to do with its swapping addresses around 
and that's OK by me so long as the arrow and the packet counts 
correctly show the real direction of the packet.  In the version that I 
first tried this on this was not happening so it looked as if the 
packets were incoming when in fact they were not.  The version I got 
yesterday had it right.


> 
>    A fix is to comment out line 675 from
> common/argus_parse.c.  This will remove the
> direction reversal that ra() is doing.  A better
> fix is to test whether there are pkt counts in
> both directions, and reverse the direction then.
> This would be condition where Argus didn't see
> the first Echo Request and started tracking a
> ping flow based on the first packet being an Echo
> Reply.
> 

I think that the best possible solution is to not do the swap unless 
there are ECO packets in the other direction.  That way neophytes won't 
get confused.

Hmmm... what should argus do when it sees a TFN master talking to a 
zombie where (I think) you have a bidirectional flow of ECR?  Sigh...

My guess is that it should report the flow as bidirectional, direction 
based on first packet seen and labeled ECR to distinguish it from a 
normal PING stream.

This stuff gets real messy when trying to record traffic that does not 
follow protocol rules.  I think this is one area that needs a lot of 
thought for the next version.  Many of us are using argus to try and 
find anomolies and protocol violations that argus was never originally 
designed to cope with.   The problem is I think, that argus was 
designed as an audit tool for legitimate traffic and many of us are now 
trying to use it as an intrusion detction tool.

What I would really like is a cross between snort and argus with a perl 
callout ;-) ;-)

i.e. something that leaves an argus-like audit trail for retrospective 
or offline analysis but also has the ability to do limited content 
analysis 'on the fly' and has the ability to capture some packet 
contents in full under program control.

Cheers, Russell.