De-aggragating multiple MAC addresses in flows
Carter Bullard via Argus-info
argus-info at lists.andrew.cmu.edu
Fri Jan 1 17:08:33 EST 2016
Hey Phillip,
You can also add the VLAN tag to the flow key, that may give you scoping for the flow definition you're looking for. Try "CLASSIC_5_TUPLE+VLAN" and "CLASSIC_5_TUPLE+LAYER_2+VLAN" as they can do different things. With LAYER_2, you may not get bi-directional closure, if you have weird asymmetry, and the VLAN addition maybe all that you need.
Carter
> On Jan 1, 2016, at 11:31 AM, Phillip Deneault via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
>
> 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 Analyst
> phillip.deneault at bc.edu Information Technology
> Boston College
> --------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20160101/3e40f881/attachment.html>
More information about the argus
mailing list