Re: De-aggragating multiple MAC addresses in flows

Ah ha!  That did the trick.


Thanks!
Phil


On Thu, Dec 31, 2015 at 10:38 PM, David Edelman <[email protected]> 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=
> [email protected]] *On Behalf Of *Phillip Deneault via
> Argus-info
> *Sent:* Thursday, December 31, 2015 2:04 PM
> *To:* Argus <[email protected]>
> *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
[email protected]                       Information
Technology
                                                      Boston College
--------------------------------------------------------------------