filter expressions and flows

[Carter Bullard]

Hey Jose,
   Sorry for the delay in responding!  The filters do
have a personality of their own, but the rules are pretty
simple.  Since the starting base for the filter compiler
was tcpdump, there are a lot of similarities, but the
ra* programs have a different abstraction to work with,
so there are some real differences.

   The filter expression "host x.y.z.w" implies "ip host
x.y.z.w", that is why "arp and host x.y.z.w" is going to
give you an expression error.  But "arp host x.y.z.w"
is stating that you want the host value returned in an
arp request, so the and is ok!

   The filter wants to fill in the blanks, if any are
left out, such as "host x.y.z.w".  What kind of host?
protocol? version?  Without this info, it has to fill
in the blanks.  Now the error "ip proto tcp" comes from
the fact that "tcp" generates "ip proto tcp" in the
lexical analyzer, which then generates "ip proto ip proto
tcp".  This should be fixed, but since tcpdump generates
the same error here, suggests that there is a fundamental
problem with the compiler strategy.  But I'll look into
it.

You ask,

> It seems that using the host particle alone is the same as 
> "ip host" and
> again this is different from tcpdump.

   but the tcpdump() man page states:

     tcp, udp, icmp
        Abbreviations for:
             ip proto p or ip6 proto p
        where p is one of the above protocols.

so I think we're pretty safe there.

Ok for your last question, you ask:

> When using ragator:
> 
> #ragator -n -r argus.data.gz -s  proto startime saddr daddr mac - arp
> host 10.229.128.2
> 
>  arp 09 May 03 12:08:49   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
> 
> 
> Shouldn't it be two different flows? one for destination address
> Broadcastand another for destination 0:50:73:6b:c9:f5
> 
   
The mac addresses are not a part of the flow descriptor
in argus data, although there is some mac address tracking.
So the flow above is cool, as the proto and the IP addresses
are the same.  The arp flow is an interesting flow type, as
the request is broadcasted, but the response is directed
to the sender.  The argus flow here is a "Type-P1-P2" flow,
where the broadcast and the responder are wildcarded.

Hope this has been helpful!!!  If you have anyother questions,
don't hesitate to send mail!

Carter




> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Jose Jerez
> Sent: Wednesday, May 21, 2003 6:50 AM
> To: argus-info at lists.andrew.cmu.edu
> Subject: filter expressions and flows
> 
> 
> I have been learning and working with argus for the last months and I
> havefound some strange behavior in the way the filter expressions work
> andthe way ragator builds up some flows.  
> 
> The version of argus is 2.0.5 beta 5 from the debian distribution, and
> the version of the clients is 2.0.6 beta 38. 
> 
> Let's see some examples:
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - arp
> 
>  arp 09 May 03 12:00:02   10.229.136.64   10.229.136.16 
> 0:80:c8:65:a8:53      Broadcast
>  arp 09 May 03 12:00:04   10.229.136.16   10.229.136.145
> 0:8:c7:d:f2:2         Broadcast
>  arp 09 May 03 12:00:05   10.229.136.76   10.229.136.18 
> 0:c0:f0:40:91:7f      Broadcast
>  arp 09 May 03 12:00:08   10.229.136.72   10.229.136.16 
> 0:10:b5:3c:b6:7c      Broadcast
>  arp 09 May 03 12:00:08   10.229.136.64   10.229.136.3  
> 0:80:c8:65:a8:53  0:60:fd:a7:a1:83
>  arp 09 May 03 12:00:10   10.229.136.16   10.229.136.70 
> 0:8:c7:d:f2:2         Broadcast
>  -----and more-------
> 
> No problems here, but:
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - arp and
> host 10.229.128.2
> 
>  ArgusAlert: ra[2751]: ArgusFilterCompile: expression rejects all
> packets
> 
>  ArgusError: ra[2750]: ra: arp and host 10.229.128.2 error
> 
> We get an error here while this expression works with tcpdump. On the
> other hand:
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - arp host 
> 10.229.128.2
> 
>  arp 09 May 03 12:08:49   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21   Broadcast
> 
> This last one works without the "and", isn't it strange?.  Two more
> failing filter expressions
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - 
> ether proto
> arp
> 
>     or
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - ip proto
> tcp
> 
>  ArgusError: ra[2760]: parse error
> 
> 
> Another extrange behavior that I found was when using the 
> particle host:
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - host
> 10.229.128.2
> 
> I don't get any data, but we saw in a previous example that there are
> data:
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - arp host
> 10.229.128.2
> 
>  arp 09 May 03 12:08:49   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21   Broadcast
> 
> 
> It seems that using the host particle alone is the same as 
> "ip host" and
> again this is different from tcpdump. 
> 
> 
> Last but no least I detected another unexpected result with ragator,
> using
> a ra command like this:
> 
> #ra -n -r argus.data.gz -s  proto startime saddr daddr mac - arp host
> 10.229.128.2
> 
>  arp 09 May 03 12:08:49   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
>  arp 09 May 03 12:19:00   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
>  arp 09 May 03 12:29:16   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
>  arp 09 May 03 12:34:20   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21  0:50:73:6b:c9:f5
>  arp 09 May 03 12:36:23   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21  0:50:73:6b:c9:f5
>  arp 09 May 03 12:46:36   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
>  arp 09 May 03 12:56:47   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
> 
> 
> When using ragator:
> 
> #ragator -n -r argus.data.gz -s  proto startime saddr daddr mac - arp
> host 10.229.128.2
> 
>  arp 09 May 03 12:08:49   10.229.136.31    10.229.128.2 
> 0:d0:c9:56:16:21         Broadcast
> 
> 
> Shouldn't it be two different flows? one for destination address
> Broadcastand another for destination 0:50:73:6b:c9:f5
> 
> 
> This is all, thank you.
> 
> 
>