Ah ha! That did the trick.
Thanks!
Phil
On Thu, Dec 31, 2015 at 10:38 PM, David Edelman <dedelman at iname.com> wrote:
> The argus.conf file (move it from the distribution’s /support/Config
> directory to /etc has this component:
>
>
>
> #
>
> # The Argus can be configured to support a large number of
>
> # flow types. The Argus can provide either type, i.e.
>
> # uni-directional or bi-directional flow tracking and
>
> # the flow can be further defined by specifying the key.
>
> # The argus supports a set of well known key strategies,
>
> # such as 'CLASSIC_5_TUPLE', 'LAYER_2', 'LAYER_2_MATRIX',
>
> # 'LAYER_2_MATRIX', 'MPLS', and/or 'VLAN', or the argus can
>
> # be configured to # formulate key strategies from a list of
>
> # the specific objects that the Argus understands. See the
>
> # man page for a complete description.
>
> #
>
> # The default is the classic 5-tuple IP flow, CLASSIC_5_TUPLE.
>
> #
>
>
>
> ARGUS_FLOW_TYPE="Bidirectional"
>
> ARGUS_FLOW_KEY="CLASSIC_5_TUPLE"
>
> #ARGUS_FLOW_KEY="CLASSIC_5_TUPLE+LAYER_2"
>
>
>
> It sounds like the last (commented out) option might do what you need. It
> adds the layer 2 (MAC information) to the classic 5-tupple (protocol,
> source address, source port, destination address, and destination port [all
> at layer 3]) to form the aggregation key.
>
>
>
> Otherwise, I agree with Peter, use two interfaces on the box running Argus
> and connect the passive taps to that box. If you do this, look at the entry
> in the configuration file that specifies the interfaces:
>
>
>
> # The syntax for specifying this either on the command line or in this
> file:
>
> # -i ind:all
>
> # -i dup:en0,en1/srcid
>
> # -i bond:en0,en1/srcid
>
> # -i dup:[bond:en0,en1],en2/srcid
>
> # -i en0/srcid -i en1/srcid (equivalent '-i
> ind:en0/srcid,en1/srcid')
>
> # -i en0 en1 (equivalent '-i bond:en0,en1')
>
> # -i en1(dlt)/srcid -i en1(dlt)/srcid
>
> #
>
> # In all cases, if there is a "-e srcid" provided, the srcid provided is
> used
>
> # as the default. If a srcid is specified using this option, it overrides
>
> # the default.
>
> #
>
> # Srcid's are specified using the notion used for ARGUS_MONITOR_ID, as
> above.
>
> #
>
> # Commandline equivalent -i
>
> #
>
>
>
> #ARGUS_INTERFACE=any
>
> #ARGUS_INTERFACE=ind:all
>
> #ARGUS_INTERFACE=ind:en0/192.168.0.68,en2/192.168.2.1
>
> #ARGUS_INTERFACE=ind:en0/"en0",en2/19234
>
> #ARGUS_INTERFACE=en0
>
>
>
> If you specify the srcid for each one (the /192.168.0.68. /“en0”, or /
> 192.168.2.1) you can use the srcid as well as smac and dmac when you
> analyze the flows with the clients. If you use something besides an IPv4
> address or a unsigned 32-bit integer , enclose the string in quotes and
> limit it to four or fewer ASCII characters.
>
>
>
> If you are using Cisco ACLs as your firewall, take a look at rapolicy()
> which can ingest an ACL and a flow then label each flow with its outcome as
> well as the specific ACL entry that caused the outcome.
>
>
>
> If there is a call for a more generic version of rapolicy() taking it
> beyond pure Cisco ACL based filter analysis, I would be happy to look into
> making the changes as time allows.
>
>
>
> --Dave
>
>
>
>
>
>
>
>
>
> *From:* Argus-info [mailto:argus-info-bounces+dedelman=
> iname.com at lists.andrew.cmu.edu] *On Behalf Of *Phillip Deneault via
> Argus-info
> *Sent:* Thursday, December 31, 2015 2:04 PM
> *To:* Argus <argus-info at lists.andrew.cmu.edu>
> *Subject:* [ARGUS] De-aggragating multiple MAC addresses in flows
>
>
>
> Hello all,
>
>
> I've been experimenting with using argus to debug firewall traffic
> patterns. In my scenario, I have passive taps on either side of the
> firewall which have both sets of traffic aggregated into the same physical
> sniffing port. That port has argus listening to it with MAC address data
> turned on (-m) and is generating flows to a file. Both src and dst IPs lie
> in VLANs the firewall is moving files between.
>
> When ra is reading back the records, it puts a 'M' in the flgs field,
> which is correct, because both sides of the firewall would be passing the
> same traffic (ideally) and so the same IP layer, would have different MAC
> addresses (one packet from the src to the firewall, and the same packet
> from the firewall to the dst).
>
> Is it possible to de-aggragate the MAC addresses so that I can be sure
> that I can see packets from both sides of the firewall? Or is that data
> lost when Argus processes the packets and generates the flow record?
>
> This scenario is a little odd, I admit. I need two fields for each flow
> to determine the correct 'position' and 'direction' of each packet. The
> src VLAN tells me what side of the firewall the packet is on and the src
> and dst MAC addresses tell me the direction its headed. The IP layer tells
> me only the _intended_ direction of each packet (which is useful, because
> that's how the firewall rules are built, but that's not my problem right
> yet).
>
> I'm hoping that in de-aggragating the MAC addresses, it also would also
> correctly populate the src VLAN ids at the same time and I would get the
> flow 'resolution' I need to perform the debugging. Otherwise... its back
> to packet-level processing! :-/
>
> Thanks,
>
> Phil
>
--
--------------------------------------------------------------------
Phil Deneault Principle Information Security
Analystphillip.deneault at bc.edu Information
Technology
Boston College
--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20160101/38014d8e/attachment.html>