Filter issue

[George Van Osterom]

The packets are SYN packets crafted using the 'mz' packet generator.

#ra -z -S localhost:1776 - host 192.168.10.50

         StartTime      Flgs  Proto            SrcAddr  Sport
Dir            DstAddr  Dport  TotPkts   TotBytes State
   18:55:34.154520  * s         tcp      192.168.10.50           ->
192.168.10.20.tcpmux        2        152     s
   18:55:34.154578  *           arp      192.168.10.20          who
192.168.10.50               4        248   INT
   18:55:34.154601  * s         tcp      192.168.10.50           ->
192.168.10.20.2             2        152     s
   18:55:34.154609  * s         tcp      192.168.10.50           ->
192.168.10.20.3             2        152     s


#ra -Zb -S localhost:3333 - host 192.168.10.50

         StartTime      Flgs  Proto            SrcAddr  Sport
Dir            DstAddr  Dport  TotPkts   TotBytes State
   18:57:18.987684  * s         tcp      192.168.10.50           ->
192.168.10.20.tcpmux        2        152    S_
   18:57:18.987694  *           arp      192.168.10.20          who
192.168.10.50               2        124   INT
   18:57:18.987719  * s         tcp      192.168.10.50           ->
192.168.10.20.2             2        152    S_
   18:57:18.987727  * s         tcp      192.168.10.50           ->
192.168.10.20.3             2        152    S_

 I didn't think it relevant earlier (sorry!), but in this case .10.50 is a
bogus IP that doesn't exist on the network, so the three-way handshake
never completes. *After testing using valid IPs, src host does indeed work
as intended. *

 So my NEW question, why does this happen? I would think that the SYN by
itself is detectable by argus. Or does it require a valid established
socket before it tracks/reports? If so, why does using just 'host' report
right away?

 I'm doing a fair amount of work involving crafted packets using
non-existent IPs (to eliminate other normal traffic from my test traffic),
so I'd love to hear any thoughts as to the reasons behind the missing
records, so that I can adjust my methods as needed.

 Thanks for taking a look at this!
-George

On Mon, Dec 1, 2014 at 2:09 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey George,
> Flow filter semantics are different from packet filter semantics, 'src
> host' relates to the originator of the flow not the packet source.  We try
> to be honest about what we see on the wire, but there are lots of reasons
> to change the flow direction when printing.  Not sure any of this applies
> to your example, but need to mention it.
>
> Since you aren't printing all the key fields, not sure what maybe
> reversing your flow semantics.  Are you hand crafting these packets ??  Are
> you post processing the flows with racluster() or ranonymize() for any
> reason ???
>
> TCP flags can modify the flow direction on printing.  Print your flows
> with the -z option to see what the TCP state is.  And -Zb may give some
> insight.
>
> When you use ' dst host x.y.z.w ' are the flows matching ???
>
> Are you using any of the .rarc variables that modify the direction of
> flows ??  Such as RA_PORT_DIRECTION or RA_LOCAL_DIRECTION ??  These rules
> are applied after input flow filtering, and so you may be being fooled ????
>
> Carter
>
> On Nov 30, 2014, at 7:46 PM, George Van Osterom <george at effluxsystems.com>
> wrote:
>
> Hi Carter,
>
>
>
> I’m seeing some discrepancies with how the ra filtering is working… do you
> have any ideas as to the root cause, or a possible fix?
>
>
>
> You can see here that using ‘host 192.168.10.50’ works fine, it catches
> the three packets I’m sending
>
>
>
> # ra -S localhost:3333 - host 192.168.10.50
>
>
>
>          StartTime      Flgs  Proto            SrcAddr  Sport
> Dir            DstAddr  Dport  TotPkts   TotBytes State
>
>    13:28:45.013039  * s         tcp      192.168.10.50           ->
> 192.168.10.20.tcpmux        2        152   REQ
>
>    13:28:45.013050  *           arp      192.168.10.20          who
> 192.168.10.50               4        248   INT
>
>    13:28:45.013074  * s         tcp      192.168.10.50           ->
> 192.168.10.20.2             2        152   REQ
>
>    13:28:45.013082  * s         tcp      192.168.10.50           ->
> 192.168.10.20.3             2        152   REQ
>
>
>
> Now, the same packets being sent, adding a ‘src’ to the filter:
>
>
>
> # ra -S localhost:3333 - src host 192.168.10.50
>
>
>
> <<No records>>
>
>
>
> I’ve tried a few different variations, to include ()s and other logic, but
> can’t seem to get any results. Additionally, running the same ‘src host’
> bpf with tcpdump appears to work just fine. Any light you could shine on
> this would be appreciated, thank you!
>
>
>
> -George
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20141201/46710f54/attachment.html>