Filter issue

Tue Dec 2 12:05:23 EST 2014

Hey George,
Its possble that your filter is getting some funky result from getaddrinfo() which we started using a while back  to handle IPv6 addresses.  If you compiled with the .debug tagfile to turn on debug support, if you run ra with these options:

   ra -D12 -b - src host x.y.z.w

we may see what is up.

Not sure why you can use the bogus address when you don't specify 'src'.  Does this work with 'dst' in the filter ???

Carter

> On Dec 2, 2014, at 4:04 AM, George Van Osterom <george at effluxsystems.com> wrote:
> 
> 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/20141202/d0ba5318/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2443 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20141202/d0ba5318/attachment.bin>