[ARGUS] Argus v5.0.0 and Locality

[Carter Bullard]

Gentle Persons,
As a part of our endpoint based NDR, anomaly detection and AI/ML support, we have added quite a bit of IP address classification and metadata to argus v5.0, both clients and data generators.
As you know, many sites store argus data for extended periods of time, in order to do forensics analysis after the fact, and, of course, AI/ML development and training.  Sites also use streaming real-time argus data for intrusion and anomaly detection, and active cyber defense.  One of the goals of the Argus Project is to generate useful, feature dense data that can support lots of different kinds of analysis.  As a result, we strive to keep argus as feature rich as we can, and provide example analytics to demonstrate how you can use the data.

Argus v.5 continues this effort.  I would like to introduce argus-clients v5.0.0 support for IP Address Locality;  a simple 8-bit score of the locality of an IP address, relative to a specific sensor.

The locality score is designed to answer simple questions like, is this IP address on the same box as the sensor, is it on the same LAN, is it in the same organization or enterprise,  is this IP address in the same LAN, but remote,  is this address in the big bad wild internet.

Locality scores are generated by argus clients based on a reference configuration (./support/Config/ralocality.conf).  All clients can determine a locality score if one is not in the flow record, but only flow labelers (radium, ralabel, etc) can modify records to insert locality scores into flow records.   Radium.1 is our best labeler, and it can label flows with locality scores, as well as geo, dns, classification ...

All the examples of locality in the v.5 distribution use this type of locality classification, but you can invent your own system
   0 - Unspecified
   1 - Internet
   2 - External Organization (Org outward facing IP addresses)
   3 - Internal Enterprise
   4 - Local Area Network
   5 - Self
   
The values are stored in the ‘local’ DSR, so you can strip it out if you don’t need it, or want to get rid of it.

The configuration is an IANA style address configuration file, here is an example:

./support/Config/ralocality.conf
#  This configuration is a ralabel(1) address configuration file.
#
#  It is designed to specify dot notation IP addresses, CIDR addresses, or
#  ranges of either address type, and to provide locality values that
#  will be assigned to those addresses.
#
#     IP Address   Locality_Score (0-255)  AS_Number(int) (optional)
#
#
#  Locality scores are 8-bit unsigned integers, allowing 0-255 as values.
#  Higher value scores indicate greater locality, such that the highest
#  number references within the end system, and 0 is considered the most
#  remote value possible.
#
RALABEL_LOCAL_INTERFACE_IS_ME=yes
RALABEL_LOCALITY_OVERWRITE=no
#   
#  Local Address Classifications
#   
0.0.0.0/8-192.167.255.255/32    1
192.168.0.0/24                  3       1       // Wired
192.168.0.67                    4       1       // SMTP
192.168.1.0/24                  3       1       // Switzerland
192.168.2.0/24                  3       1       // Wireless
207.237.36.98                   2       1       // QoSient.com
192.168.3.0/24-223.0.0.0/8      1

224.0.0.0/24                    4       1       // local subnetwork Multicast
224.0.1.0/24                    3       1       // internetwork Multicast
224.0.2.0-224.0.255.255         1       1       // Globally routed Multicast
224.3.0.0-224.4.255.255         1       1       // Globally routed Multicast

232.0.0.0/8                     3       1       // Source-specific Multicast
233.0.0.0/8                     1       1       // GLOP Addressing
234.0.0.0/8                     1       1       // Global Unicast-Prefix Multicast Addressing

239.0.0.0/8                     3       1       // Private use within an organization


I’ll be adding IPv6 support soon after release.
You can chose any system you like, of course.

The idea is that every sensor has its own definition of what is local.   The source would label the flows, using a local radium.1, adding the sensor specific locality score.
For fixed link flow monitors, it is pretty simple.  For mobile devices, the ralocality.conf should reflect the mobile devices home network.  This way, you can write clients that can realize that this device is not in its home network, by correlating with other data, and modifying the locality score.

There are other ways to determine locality, but the configuration file is a straight forward step to getting started with this metric.

All argus clients can filter on the locality score that has been added to the flow:
   % ra -S localhost - src loc lt 4 and src addr 1.2.3.4

When aggregating flows that have locality information, the highest number will be retained.

As mentioned, this type of support is important for mobile flow sensors.  We encourage you to consider adding argus flow sensing to your mobile devices, and thinking of how do you know what was local for this device, last Tue at 4pm …

Hope all is most excellent,
   
Carter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20240603/05923ea6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1385 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20240603/05923ea6/attachment-0001.bin>