Some problems (bugs?) with argus

[Carter Bullard]

Hey Martijn,
The key to these flow records is the "f" in the flags field.  These  
are unmapped
fragment flow reports.

Fragments are tracked based on src addr, dst addr and ipid.  The  
initial fragment
packet is the only packet in the fragment stream that has the  
transport identifiers
needed to map the fragment back to the "parent" flow.   If argus()  
never sees the
initial fragment, it can't figure out which flow the fragments belong  
to, so it ends
up as an "orphan".

Orphaned fragment flows are tracked and reported just like any other  
flow.   But
because there is no transport header, we can only report them as if  
they were
uni-directional IP flows.

So, you can get these in asymmetric routed networks, where there is loss
in the network, conditions where argus is dropping packets, the port  
mirror is
dropping packets, in DDOS attacks, attacks on NAT devices or when they  
are
fabricated for scan purposes.  Most are not nefarious.  When you see  
1000's
of these, then you know someone is using them for discovery or some form
of router/NAT cache attack.

Now,...., there are problems with these flows, based on your report.

Inverted addresses are generally a little-endian big-endian issue.
All records written out of argus are suppose to be converted to big- 
endian.
The problem could either be in argus() or the clients() so I'll take a  
look.

Argus does not dictate the direction of a flow, its rules are very  
simple,
so any problems with flow direction reporting are issues in the logic  
for the
client programs.  So I wouldn't modify argus to deal with what would
appear to be a direction issue.  Check out the ArgusReverseRecord()
use in the client library for help there!!!!

Patch is good, I'll put it in!!!!

Let me see what is up.  I think I have packet traces with these types  
of flows
in them.

Carter

On Aug 7, 2009, at 5:49 AM, Martijn van Oosterhout wrote:

> Hi,
>
> I'm having some difficulties with argus 3.0.0. I'm wondering if people
> have some ideas (maybe they're fixed already, but I can't find a
> changelog anywhere):
>
> 1. Sometimes, argus outputs IP addresses in reverse order. So if the
> flow is from a1.b1.c1.d1 to a1.b2.c2.d2, the actual flow record from
> argus displays as
>
> d1.c1.b1.a1 -> d2.c2.b2.a1
>
> Personally, I've started at the code a bit and can't work out how it
> could possibly happen. So far I've not been able to extract a PCAP
> that reproduces it, but it happens maybe a few times in weeks of heavy
> traffic.
>
> 03 Aug 09 08:35:52  e    f    tcp       21.33.xx.yy *         ->
> 20.145.xx.yy *             1       1434   INT
> 03 Aug 09 08:50:07  e    f    tcp       21.33.xx.yy *         ->
> 31.134.xx.yy *             1       1434   INT
>
> So they're not complete flows, but they're odd nontheless. The TCP
> port number is missing also. Has anyone seen this?
>
> 2. If a TCP session is missing the initial SYN packet then the argus
> flow registers as being the wrong way round. For stats this is kind of
> annoying as servers appear as clients. It happens also if a RST or FIN
> shortly preceeds the SYN.
>
> I thought I could fix this by checking ARGUS_REVERSE of the flow
> whenever a SYN packet comes past in ArgusTcp.c, but I'm having
> difficulty determing exactly how to change it. I'm getting lost in the
> DSRS and working out which direction the SYN is actually going. Can
> anyone help here?
>
> 3. Finally, a simple one: when you do a bpf match for "syn" on the
> commandline it also matches flows with synack, which for my purpose is
> undesireable. I fixed this with the patch
>
> --- common/grammar.y    2008-03-20 04:29:14.000000000 +0100
> +++ common/grammar.y.patched    2009-07-30 13:49:36.000000000 +0200
> @@ -306,6 +306,7 @@
>        | SVC                   { $$ = Q_SVC; }
>         | NORMAL               { $$ = Q_NORMAL; }
>         | WAIT                 { $$ = Q_WAIT; }
> +        | SYN                  { $$ = Q_SYN; }
>        | SYNACK                { $$ = Q_SYNACK; }
>        | FINACK                { $$ = Q_FINACK; }
>        | ESTABLISHED           { $$ = Q_ESTABLISHED; }
>
> Seems simple enough for me, what do you think?
>
> Thanks in advance,
> -- 
> Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/
>

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090807/1ca42e95/attachment.bin>