Argus Flow reversal with ECRs ??
r.fulton at auckland.ac.nz
Thu Feb 17 15:52:12 EST 2000
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
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
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
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.
More information about the argus