Filter issue

Mon Dec 1 22:38:59 EST 2014

George,

It might be a good idea to use –X as the very first argument to ra , it ensures that there are no surprises hidden in any of the various rarc files which might have an impact on the determination of source –vs- destination.

  ra –X –Zb –S localhost:1776 – host 192.168.10.50 

might be interesting.

--Dave

From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu] On Behalf Of George Van Osterom
Sent: Monday, December 01, 2014 10:04 PM
To: Carter Bullard
Cc: argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Filter issue

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 <mailto: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 <mailto: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/721928e2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6217 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20141201/721928e2/attachment.bin>