-
Notifications
You must be signed in to change notification settings - Fork 12
Home
Welcome to the Argus wiki! Here we'll try to use the powers of GitHub to develop and manage new features of Argus data generation. Argus was originally called the "ARGUS - Audit Record Generation and Utilization System" and that is how its reference on sites like Wikipedia. Argus has been grabbed as a name for so many products, services, things, but in 1984 when Argus began, this project was the first use of the term for software in the Internet.
The Argus project is composed of two efforts.
- Network flow data generation
- Network flow data processing
In this wiki we'll talk about network flow data generation, which is referred to as the Argus Server or Sensor. The processing component is referred to as the Argus Clients, and has its own GitHub repo. Over the years, we've moved to referring to the Argus as the network flow sensor, and we'll stick to that convention here.
There are a few basic design concepts that are strictly applied to the Argus:
Comprehensive network accountability - Argus is a comprehensive network sensor, so it will account for every packet that it observes. This is an important goal for cyber security network awareness, and it is a requirement in the US DoD Zero Trust Architecture.
High performance - As a stand-alone network sensor, Argus is designed to "keep up". A part of Argus's development was done at the Naval Research Laboratories Supercomputer Center, so keeping up was job #1. This goal has helped Argus's adoption. It was the primary network sensor for the NSFnet in the 1980's, before it was transitioned as the current Internet. It was used in the Internet core in the 1990's when cyber security monitoring was in its infancy. It was the principle sensor for GLORIAD, the NSF International network, until it was transitioned, and it was the sensor for network ops for a number of research networks using ATM, Infiniband, optical protocols, like those seen in Dragon. Argus is currently in operation at 100Gbps (200 bidirectional) at US Gov't sites and Universities in the US (to our knowledge). High performance also enables the use of Argus in IoT devices, tablets, Android phones, mini-PC computers, laptops, and supercomputers.
Dense Features - Argus has tried to be on the leading edge of network sensor technology by providing the most features of any general purpose network sensor. We currently provide over 250+ network features that range from network object identifiers, metrics, packet dynamic measurements, behavioral data and selective content, in a very compact binary record format.
One criticism of the Argus project is that we haven't been telling people what to do with their data, or how to do it, except through our examples. But the purpose of the project was to create the sensor, in order to enable the industry to rely on high-grade network sensing. We think we have been successful.
Argus V5.0 provides a few key features that enable a very large family of new network sensing features:
In each argus record, there is a data element that identifies the source of the Argus record. When you only have one Argus sensor, the ARGUS_MONITOR_ID doesn't seem too important, but when you have 100,000's of data sources, as you see in large cloud implementations or big enterprises, having a source id in each record is very important. In network forensics analysis, Argus data may sit around for months before an attack is realized, and the data needed to support an investigation may have to come from dozens of sources, in order to understand how an intruder accomplished its campaign.
Argus V5.0 extended the ARUGS_MONITOR_ID from being a 32-bit integer, an IP address, or a 4-byte string, to 128-bits, which enables a UUID, and ethernet address or an IPv6 address to be a source id. The UUID is critical, as each endpoint, asset, component, subsystem seems to have a UUID as an identifier, and Argus data can use these UUIDs as data source identifiers, a part of the zero-configuration strategy for endpoint argus.
Argus data introduced "First X Byte" content capture in the 1990's, a feature that has been critical to identifying covert channels and unknown service discovery in network infrastructure.
In Argus V5.0, the argus.conf file supports identifying protocols that are control planes, and indicating the amount of payload to capture. The intent is to provide complete content capture for control plane and non-IP traffic, in order to provide DHCP, DNS, LDAP, and ARP content capture for network forensics, as well as providing a basic capability for identifying unknown traffic.
This feature enables argus to capture the semantics for all control planes including name resolution, address resolution, address assignment, routing and forwarding, without having to do the actual protocol decoding in the sensor. The ability to use this data is dependent on Argus Client programs to decode the content and provide utility for the capture data.
Argus is designed as an end-to-end transport flow monitor. This means that Argus wants to find the transport protocol (L4) headers in order to report on the classic 5-tuple flow identifiers, (saddr, daddr, proto, sport, dport). In modern networking, that means Argus may need to parse dozens of L2, sub-layer 3, L3, and tunnel protocol headers, in order to get to L4 (ie ppp, tcp, udp, udt). The L4 headers and its content have a large number of key features needed to do operations (reachability, connectivity indicators), performance (sequence numbers, window advertisements, retransmission indications), and security verification (policy enforcement, randomizations, attack indications).
Argus V5.0 has or will add encapsulation discovery and parsing for VxLan, L2TP, GRE, and Geneve (UDP encapsulation), to name only a few.