De-aggragating multiple MAC addresses in flows

[David Edelman via Argus-info]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20151231/485e8c89/attachment.html>