ARGUS.CONF(5)

📦
version 5.0.2 · 4 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 argus.conf(5) — the manual page, but make it make sense 💖

okay bestie, welcome to argus.conf(5), aka the resource file for argus, aka where you tell argus how to behave. pull up a chair, we're doing this properly. 🫶

✨ NAME ✨

argus.conf — the argus resource file. that's it. that's the name. iconic.

🌈 SYNOPSIS 🌈

argus.conf

Copyright (c) 2000-2024 QoSient, LLC All rights reserved.

💅 DESCRIPTION 💅

so this is the canonical argus configuration file. every single option argus supports can be turned on or tweaked using this format. no cap.

argus will go looking for a system /etc/argus.conf file, open it up, and use it to seed all configuration options.conf. ✨

heads up bestie: previous versions of argus used to search for argus.conf in $ARGUSPATH, $ARGUSHOME, $ARGUSHOME/lib, $HOME, and $HOME/lib — but that support is deprecated. we don't do that anymore. 💀

every value in this file can be overridden by command line options, or by other configuration files of this same format when you pass them in using the -F option.

argus will read any number of configuration files using the -F option, and command-line order is very important. fr fr. order matters.

🌸 Variable Syntax 🌸

variable assignments have to look like this:

  VARIABLE=value
  VARIABLE="compound values"

with no white space between the VARIABLE and the = sign. literally none. quotes are optional for string arguments, but if you wanna embed comments, then the quotes are required.

🦋 Comments 🦋

comments are supported using a # as the first character in the string — like this string that you're reading right now. slay.

embedded comments are supported, preceded by a " //", exactly like you'd see in C. and the preceding white space is very important. the space or tab is absolutely required to delimit the end of the variable values and the beginning of the comment. without that space, the comment gets swallowed up as part of the configuration variable. 😭

   VARIABLE=value // comment
   VARIABLE="compound values" // comment

👑 ARGUS_FLOW_TYPE / ARGUS_FLOW_KEY 👑

argus can be configured to support a large number of flow types. argus can provide either type — meaning uni-directional or bi-directional flow tracking — and the flow can be further defined by specifying the key.

argus supports a set of well known key strategies, such as 'CLASSIC_5_TUPLE', 'LAYER_3_MATRIX', 'LAYER_2_MATRIX', 'MPLS', and/or 'VLAN', or you can configure argus to formulate key strategies from a list of the specific objects that argus understands. see the man page for a complete description. iykyk.

the default is the classic 5-tuple IP flow, CLASSIC_5_TUPLE. periodt.

there is no commandline equivalent.

ARGUS_FLOW_TYPE="Bidirectional"
ARGUS_FLOW_KEY="CLASSIC_5_TUPLE"

🧚 ARGUS_DAEMON 🧚

argus is capable of running as a daemon, doing all the right things that daemons do. 💅 when this configuration is used for the system daemon process — say, for /etc/argus.conf — this variable should be set to "yes".

in the examples you'll see in the ./support/Startup/argus scripts, this value is set to "yes", because the system startup strategy requires the program to daemonize itself, returning a value to the system, hopefully quickly. some systems, however, want to daemonize the tasks themselves — and in those cases, the value must be set to "no".

which requires that this variable be set to "yes".

the default value is to not run as a daemon.

commandline equivalent: -d

ARGUS_DAEMON=no

⭐ ARGUS_MONITOR_ID ⭐

argus Monitor Data is uniquely identifiable based on the source identifier that's included in each output record. this exists so you can work with Argus Data from multiple monitors at the same time. 🌈

the ID for argus v5 is 128 bits long, and 32 bits for argus v1,2,3. with 128 bits, argus can support a number of formats as legitimate values. argus and argus clients support unsigned ints, IPv4 and IPv6 addresses, 4 byte strings (legacy) and UUIDs as values.

the formats are discerned from the values provided in the configuration. double-quoted values are treated as strings, and are truncated to 4 characters. non-quoted values get tested for whether they're hostnames, and if not, then they get tested for whether they're numbers conforming to any of the supported formats.

the configuration allows you to use host names, however — do have some understanding of how a FQDN, or the special keyword hostname, will be resolved by the nameserver before committing to this strategy completely. 🙈

for convenience, argus supports the notion of "hostname" and "hostuuid" for assigning the probe's id. this is to support general management of larger deployments, so you can have one argus.conf file that works for a lot of probes. obsessed.

the use of hostuuid is targeted at Windows, Linux and Apple computers, that have a UUID assigned to the machine.

with Argus V5 (gargoyle), the srcid formats are extended to include 128-bit values, designed primarily to support host UUIDs, and to add 4 bytes interface identifiers, to create a compound source identifier.

the actual interface name, reduced to a 4 byte string, can be added to the srcid, through static specification, or automatically, when the keyword "inf" is added to the ARGUS_MONITOR_ID specifier.

for security: argus does not rely on system programs, like hostname.1. it implements the logic of hostname itself, so don't try to run arbitrary programs using this method, because it shouldn't work. 💀

the syntax for the monitor id, srcid, is:

     [type:/]sid[/inf]
        where type can be:
           int, str, ipv4, ipv6, uuid

        where sid can be:
           int, "string", ipv4, ipv6, uuid

        where inf is:
           char[4]

examples include:

  fe80::1
  192.168.8.68
  2345/en0
  ipv4:/192.168.8.68/en1
  5E487EDE-B311-5E80-B69F-967E5E6C7A9F/en0
  uuid:/5E487EDE-B311-5E80-B69F-967E5E6C7A9F

commandline equivalent: -e

ARGUS_MONITOR_ID=5E487EDE-B311-5E80-B69F-967E5E6C7A9F            // UUID
ARGUS_MONITOR_ID=uuid:/5E487EDE-B311-5E80-B69F-967E5E6C7A9F      // type:UUID
ARGUS_MONITOR_ID=uuid:/5E487EDE-B311-5E80-B69F-967E5E6C7A9F/en0  // type:UUID/inf
ARGUS_MONITOR_ID=`hostuuid`                                      // UUID
ARGUS_MONITOR_ID=`hostname`                                      // IPv4 address returned
ARGUS_MONITOR_ID=10.2.45.3                                       // IPv4 address
ARGUS_MONITOR_ID=ipv4:/10.2.45.3                                 // IPv4 address
ARGUS_MONITOR_ID=ipv4:/10.2.45.3/arg0                            // type:IPv4 address/inf
ARGUS_MONITOR_ID=2435                                            // Number
ARGUS_MONITOR_ID="en0"                                           // String

🍓 ARGUS_MONITOR_ID_INCLUDE_INF 🍓

with Argus V5 (gargoyle), the srcid formats are extended to include 160-bit values (128-bit sid + 32-bit inf), designed primarily to provide support for 128-bit uuid's and IPv6 addrs for zero-configuration support. V5 also extends the srcid to include the monitored interface (inf). ✨

interface string extensions are not added to the actual ARGUS_MONITOR_ID specifier (sid), unless you're hard coding the interface name for a specific observation domain — that's done in the ARGUS_INTERFACE specification.

to add the semantic that the default "mon0" is a part of this MONITOR_ID, set the new ARGUS_MONITOR_ID_INDLUCE_INF to "yes". to turn it off, set it to "no". "No" is the default behavior.

commandline equivalent: there is no commandline equivalent

ARGUS_MONITOR_ID_INCLUDE_INF=yes

🦄 ARGUS_ACCESS_PORT 🦄

argus monitors can provide a real-time remote access port for collecting Argus data. this is a TCP based port service and the default port number is tcp/561, the "experimental monitor" service. this feature is disabled by default, and can be forced off by setting it to zero (0).

when you do want to enable this service, 561 is a good choice, because all ra* clients are configured to try this port by default. 💅

commandline equivalent: -P

ARGUS_ACCESS_PORT=561

another port, such as 562, would be used, if radium.1 is used to provide argus data access on port 561.

💜 ARGUS_BIND_IP 💜

when remote access is enabled (see above ⬆️), you can specify that Argus should bind only to a specific IP address. this is useful, for example, in restricting access to the local host, or binding to a private interface while capturing from another. 🌸

you can provide multiple addresses, separated by commas, or on multiple lines.

the default is to bind to any IP address.

commandline equivalent: -B

ARGUS_BIND_IP="::1,127.0.0.1"
ARGUS_BIND_IP="127.0.0.1"
ARGUS_BIND_IP="192.168.0.68"

ARGUS_INTERFACE 🌐

okay so bestie, here's the tea ☕ — if you give Argus zero configuration, it's just gonna open the first appropriate interface it bumps into. For a lil system with one single NIC? literally perfect, no notes. 💅

But the second there's more than one suitable interface kicking around, you're probably gonna need to tell Argus which interface(s) it should be reading packets from. You do that either on the command line or right here in this file. 🫶

Argus can track packets from any or all interfaces, concurrently. And the interfaces can be tracked as:

  1. independant — this is where argus tracks flows from each interface totally independant of the packets seen on any other interface. Super useful for hosts/routers rockin' full-duplex interfaces where you wanna distinguish flows based on their interface. When you're running argus on modern end-systems, where there can be dozens of physical, wired and wireless, and virtual interfaces active at any time, it is important to keep track of which interface a particular packet was seen. 👀 There is an option to specify a distinct srcid to each independant modeler.
  2. duplex — where argus tracks packets from 2 interfaces as if they were two half duplex streams of the same link. Because there is a single processing thread and memory cache tracking the 2 interfaces, there can be a single srcid that can be used to identify the flows, as an option.
  3. bonded — where argus tracks packets from multiple interfaces as if they were from a single packet source (interface). Again, because there is a single processing thread and memory cache tracking the multiple interfaces, there can be a single srcid that can be passed as an option.

Interfaces can be specified as groups using '[',']' notation, to build flexible definitions of packet sources. ✨ However, each interface should be referenced only once (this is due to performance and OS limitations restricting how many readers can open an interface at one time, but if your OS has no problem with multiple readers of the same packet, go ahead).

The lo (loopback) interface will be included only if it is specifically indicated in the option. no sneaky loopback, bestie. 🙈

The syntax for specifying this either on the command line or in this file:

   -i ind:all
   -i ind:any/srcid
   -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')

In all cases, if there's a -e srcid provided, that gets used as the default. And 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.

Srcid substitution is used when the srcid field is empty (//), in which case the argus-wide ARGUS_MONITOR_ID is used. Interface substitution is used when the inf extension keyword is used in the srcid specification. This is a convenience for the "any" interface specification, so that the actual interface name is used as a part of the srcid. Normally, when a combination interface is specified, an allocated interface name, such as "arg0", is used in the srcid.

Commandline equivalent -i

ARGUS_INTERFACE=en0
ARGUS_INTERFACE=any
ARGUS_INTERFACE=ind:all
ARGUS_INTERFACE=ind:any//inf
ARGUS_INTERFACE=ind:en0/192.168.0.68,en2/192.168.2.1
ARGUS_INTERFACE=ind:en0//en0,en2//en2
ARGUS_INTERFACE=ind:en0/"en0",en2/19234

ARGUS_INTERFACE_SCAN_INTERVAL ⏰

This is the number of seconds between checks for changes in the available network interfaces, and it determines the upper bound on the time until a new interface is discovered by Argus. Must be a positive integer less than or equal to 60. The default value is 1. 🦋

ARGUS_INTERFACE_SCAN_INTERVAL=1

ARGUS_GO_PROMISCUOUS 👀

By default, Argus will put its interface in promiscuous mode in order to monitor all the traffic that can be collected. Ngl, this can put an undo load on systems. 😭

If your intent is to monitor only the network activity of the specific system — say, to measure the performance of an HTTP service or DNS service — you'll wanna turn promiscuous mode off.

The default value goes into promiscuous mode.

Commandline equivalent -p

ARGUS_GO_PROMISCUOUS=yes

ARGUS_CHROOT_DIR 🏠

Argus supports chroot(2) in order to control the file system that argus exists in and can access. Generally used when argus is running with privileges, this limits the negative impacts that argus could inflict on its host machine. 🛡️

This option will cause the output file names to be relative to this directory, and so consider this when trying to find your output files. (fr fr, don't come crying to me when your log isn't where you left it. 💀)

Commandline equivalent -c dir

ARGUS_CHROOT_DIR=/chroot_dir

ARGUS_CAPTURE_FULL_CONTROL_DATA 🎀

Argus can be configured to capture the complete packet contents of protocols of interest, to enable a detailed control plane flow monitoring capability for specific control plane protocols. The concept is that argus-clients will be able to parse the packet contents to provide utility. ✨

This feature requires full packet capture for all traffic from monitored interfaces in order to capture the complete control plane protocol. As a result, it will have a performance impact on the sensor, especially in high performance environments (> 100G). 😬

The default is to not turn this feature on.

Commandline equivalent -C

ARGUS_CAPTURE_FULL_CONTROL_DATA="yes"

ARGUS_CONTROLPLANE_PROTO 🧚

When ARGUS_CAPTURE_FULL_CONTROL_DATA is enabled, you can specify what protocols are control plane protocols. This is whatever you want to specify. The feature assumes non-IP traffic is a control plane protocol; for IP traffic, you can specify protocols, as seen in the /etc/services file, that should be considered control plane. 🦋

The example below is just a suggestion. 💅

No commandline equivalent

ARGUS_CONTROLPLANE_PROTO="sip,udp:name,udp:nicname,udp:domain,udp:netbios-ns,xns-time,udp:ntp,udp:router,udp:ripng,timed,mdns,mdnsresponder,bootps,bootpc"

ARGUS_SETUSER_ID 🙋‍♀️

Argus can be directed to change its user id using the setuid() system call. This can be used when argus is started as root, in order to access privileged resources, but then after the resources are opened, this directive will cause argus to change its user id value to a 'lesser' capable account. Recommended when argus is running as daemon. 🔐

Commandline equivalent -u user

ARGUS_SETUSER_ID=user

ARGUS_SETGROUP_ID 👯

Argus can be directed to change its group id using the setgid() system call. This can be used when argus is started as root, in order to access privileged resources, but then after the resources are opened, this directive can be used to change argus's group id value to a 'lesser' capable account. Recommended when argus is running as daemon. 🔐

Commandline equivalent -g group

ARGUS_SETGROUP_ID=group

ARGUS_OUTPUT_FILE 📁

Argus can write its output to one or a number of files — default limit is 5 concurrent files, each with their own independant filters. 💅

The format is:

ARGUS_OUTPUT_FILE=/full/path/file/name
ARGUS_OUTPUT_FILE=/full/path/file/name "filter"

Most sites will have argus write to a file, for reliability and performance. The example file name is used here as supporting programs, such as ./support/Archive/argusarchive are configured to use this file. 🫶

Commandline equivalent -w

ARGUS_OUTPUT_FILE=/var/log/argus/argus.out

ARGUS_OUTPUT_STREAM 📡

Argus can write its output to one or a number of remote hosts. The default limit is 5 concurrent output streams, each with their own independant filters. ✨

The format is:

ARGUS_OUTPUT_STREAM="URI [filter]"
ARGUS_OUTPUT_STREAN="argus-udp://host:port 'tcp and not udp'"

Most sites will have argus listen() for remote sites to request argus data, but for some sites and applications sending records without registration is desired. This option will cause argus to transmit records that match the optional filter, to the configured targets using UDP as the transport mechanism.

Commandline equivalent -w argus-udp://host:port

ARGUS_OUTPUT_STREAM=argus-udp://224.0.20.21:561

ARGUS_SET_PID 🆔

When Argus is configured to run as a daemon, with the -d option, Argus can store its pid in a file, to aid in managing the running daemon. However, creating a system pid file requires privileges that may not be appropriate for all cases. 😬

When configured to generate a pid file, if Argus cannot create the pid file, it will fail to run. This variable, and the directory the pid is written to, is available to override the default, in case this gets in your way. 🙈

The default value is to generate a pid. The default path for the pid file is /var/run.

No Commandline equivalent

ARGUS_SET_PID=yes
ARGUS_PID_PATH=/var/run

ARGUS_FLOW_STATUS_INTERVAL ⏱️

Argus will periodically report on a flow's activity every ARGUS_FLOW_STATUS_INTERVAL seconds, as long as there is new activity on the flow. This is so that you can get a view into the activity of very long lived flows. The default is 60 seconds, but this number may be too low or too high depending on your uses. 👑

The default value is 60 seconds, but argus does support a minimum value of 1. This is very useful for doing measurements in a controlled experimental environment where the number of flows is < 1000. 🧪

Commandline equivalent -S

ARGUS_FLOW_STATUS_INTERVAL=60

ARGUS_MAR_STATUS_INTERVAL 💗

Argus will periodically report on its own health, providing interface status, total packet and bytes counts, packet drop rates, and flow oriented statistics. 📊

These records can be used as "keep alives" for periods when there is no network traffic to be monitored.

The default value is 300 seconds, but a value of 60 seconds is very common.

Commandline equivalent -M

ARGUS_MAR_STATUS_INTERVAL=300

ARGUS_FLOW_TIMEOUTs ⌛

Argus has a number of flow state timers that specify how long argus will 'remember' the caches of specific flows after they have gone idle. 🧠

The default values have been chosen to aggressively timeout flow caches to conserve memory utilization. Increasing values can have an impact on argus memory use, so take care when modifying values. 😭

The maxium value for any timeout is 65534 seconds.

If you think there is a flow type that doesn't have appropriate timeout support, send email to the developer's list, we'll add one for you. 💌

ARGUS_IP_TIMEOUT=30 ARGUS_TCP_TIMEOUT=60 ARGUS_ICMP_TIMEOUT=5
ARGUS_IGMP_TIMEOUT=30 ARGUS_FRAG_TIMEOUT=5 ARGUS_ARP_TIMEOUT=5
ARGUS_OTHER_TIMEOUT=30

🌸 ARGUS_DEBUG_LEVEL 🌸

If it got compiled to support this option, Argus can churn out a ton of debug info. Like, so much.

The default value is zero (0).

Commandline equivalent: -D

ARGUS_DEBUG_LEVEL=0

✨ ARGUS_GENERATE_RESPONSE_TIME_DATA ✨

You can set Argus up to report on flows in a way that gives you the best possible info for calculating application response times and network round trip times. It's giving ✨analytics✨.

Default is to not generate this data, bestie.

Commandline equivalent: -R

#ARGUS_GENERATE_RESPONSE_TIME_DATA=no

🎀 ARGUS_GENERATE_PACKET_SIZE 🎀

Argus can generate packet size info on a per-flow basis, which hands you the max and min packet size seen. The default is to not generate this data.

Commandline equivalent: -Z

ARGUS_GENERATE_PACKET_SIZE=yes

📊 ARGUS_PACKET_SIZE_HISTOGRAM 📊

Okay so Argus can generate packet size info per flow. But this one goes further — it can generate a logorithmic frequency distribution histogram of the packet sizes it saw. Every argus client can print that distribution as a hex number, where each nibble is one of the columns of the logarithmic histogram, and the relative values run from 0-15. A 1 generally means a packet was seen, and 15 handles all packets up and above the last column range.

The default value is to not generate this data.

No commandline equivalent.

ARGUS_PACKET_SIZE_HISTOGRAM=no

🌈 ARGUS_GENERATE_JITTER_DATA 🌈

Argus can generate packet jitter info on a per-flow basis. The default is to not generate this data.

Commandline equivalent: -J

ARGUS_GENERATE_JITTER_DATA=no

💬 ARGUS_LOG_DISPLAY_PRIORITY 💬

This one sets the log level for messages going to your terminal. The value must be an integer in the range 0..7. These correspond to the eight syslog levels LOG_EMERG through LOG_DEBUG. The default level is LOG_WARNING.

Commandline equivalent: -k

ARGUS_LOG_DISPLAY_PRIORITY=4

🦋 ARGUS_GENERATE_MAC_DATA 🦋

Argus can be configured to not provide MAC addresses in its audit data. This is available if MAC address tracking and audit is not a requirement, iykyk.

The default value is to not generate this data.

Commandline equivalent: -m

ARGUS_GENERATE_MAC_DATA=no

💜 ARGUS_GENERATE_APPBYTE_METRIC 💜

Argus can be configured to generate metrics that include the application byte counts, plus the packet count and byte counters. Extra numbers, extra slay.

Commandline equivalent: -A

ARGUS_GENERATE_APPBYTE_METRIC=no

🔥 ARGUS_GENERATE_TCP_PERF_METRIC 🔥

By default, Argus generates extended metrics for TCP that include the connection setup time, window sizes, base sequence numbers, and retransmission counters. You can suppress all this detailed info using this variable.

No commandline equivalent.

ARGUS_GENERATE_TCP_PERF_METRIC=yes

⭐ ARGUS_GENERATE_BIDIRECTIONAL_TIMESTAMPS ⭐

By default, Argus generates a single pair of timestamps — for the first and last packet seen on a given flow, during the observation period. For bi-directional flows, that means you lose some info, lowkey tragic. But set this variable to 'yes' and argus will store start and ending timestamps for both directions of the flow. 💅

No commandline equivalent.

ARGUS_GENERATE_BIDIRECTIONAL_TIMESTAMPS=no

🍓 ARGUS_CAPTURE_DATA_LEN 🍓

Argus can be configured to capture a number of user data bytes from the packet stream.

The default value is to not generate this data.

Commandline equivalent: -U

ARGUS_CAPTURE_DATA_LEN=0

🧚 ARGUS_ENCAPS_CAPTURE 🧚

Argus can also capture the encapsulation packet headers that it parses. This supports the ability to realize and debug unknown/unexpected encapsulation headers, plus it lets you do client based extensions to encapsulation header processing.

The default is to not turn this feature on.

ARGUS_ENCAPS_CAPTURE="no"

🌸 ARGUS_FILTER_OPTIMIZER 🌸

Argus uses the packet filter capabilities of libpcap. If there's a need to not use the libpcap filter optimizer, you can turn it off right here. The default is to leave it on.

Commandline equivalent: -O

ARGUS_FILTER_OPTIMIZER=yes

✨ ARGUS_FILTER ✨

You can drop a filter expression here if you like. Heads up though — it should be limited to 2K in length. The default is to not filter.

No commandline equivalent.

ARGUS_FILTER=""

🎀 ARGUS_PACKET_CAPTURE_FILE 🎀

Argus lets you capture packets in tcpdump() format, as long as the source of the packets is a tcpdump() formatted file or a live packet source.

Use this configuration variable to specify the path to the packet capture file. Argus will generate the file if it doesn't exist. ✨manifesting✨

ARGUS_PACKET_CAPTURE_FILE="/var/log/argus/packet.out"

📊 ARGUS_PACKET_CAPTURE_ON_PROTO 📊

When an ARGUS_PACKET_CAPTURE_FILE is specified, argus lets you capture packets in tcpdump() format based on the protocol headers parsed in the packets.

Use this directive to specify the list of protocols of interest. It's a comma separated list of protocol types found in the encapsulation protocols supported in ./include/encapsulations, the protocols seen in /etc/protocols, and the tunnel protocols that can be discovered using the ARGUS_TUNNEL_DISCOVERY directives.

ARGUS_PACKET_CAPTURE_ON_PROTO="gre,vxlan,l2tp"

🌈 ARGUS_PACKET_CAPTURE_ON_ERROR 🌈

When an ARGUS_PACKET_CAPTURE_FILE is specified, argus lets you capture packets in tcpdump() format when there's a header parsing error in the argus header logic. This is designed to support the development of argus when you're adding new packet headers parsing to the suite of headers — but ngl, it's useful in many other conditions too.

ARGUS_PACKET_CAPTURE_ON_ERROR="no"

💬 ARGUS_SSF 💬

Argus supports the use of SASL to provide strong authentication and confidentiality protection. 👑

The policy argus uses is controlled through a minimum and maximum allowable protection strength, which is standard for SASL based applications. Set these variables to control that policy. The default is no security policy.

ARGUS_MIN_SSF=0
ARGUS_MAX_SSF=0

🦋 ARGUS_PCAP_BUF_SIZE 🦋

Argus supports setting the pcap buffer size. You can use the abbreviations K, M, G to specify thousands, millions or billions of bytes.

ARGUS_PCAP_BUF_SIZE=1G

💜 ARGUS_PCAP_DISPATCH_NUM 💜

Argus supports setting the number of packets pcap_dispatch() should ask for with each call. -1 is documented as pcap_dispatch() asking for a complete input buffer of packets. The default number of packets is 1.

ARGUS_PCAP_DISPATCH_NUM=1

🔥 ARGUS_ENV 🔥

Argus supports setting environment variables to enable functions required by the kernel or shared libraries. This feature is intended to support libraries such as the net pf_ring support for libpcap, as supported by code at http://public.lanl.gov/cpw/

Setting environment variables this way does not affect internal argus variables in any way. As a result, you can't set ARGUS_PATH using this feature.

Care must be taken to assure that the value given the variable conforms to your system's putenv.3 system call. You can have as many of these directives as you like. 💅

The example below is intended to set a libpcap ring buffer length to 300MB, if your system supports this feature.

ARGUS_ENV="PCAP_MEMORY=300000"

⭐ ARGUS_TUNNEL_PARSING ⭐

How Argus processes tunnel headers is configurable. By default, Argus will parse any tunnel header that it encounters, and continue until it reaches an outermost L4 header — the end-to-end headers.

Some users may need argus to stop at the first tunnel, or at a specific tunnel protocol. This option, if set to "no", will stop processing at the first tunnel protocol header encountered.

The default is to turn this feature on.

ARGUS_TUNNEL_PARSING="yes"

🍓 ARGUS_TUNNEL_INFORMATION 🍓

When Argus is configured to parse through tunnels, it can be configured to capture tunnel features, such as L3 addresses. When this is set to "yes", argus will formulate a flow spec for each tunnel encountered, and store it in a tunnel specific DSR.

The default is to not turn this feature on.

ARGUS_TUNNEL_INFORMATION="no"

🧚 ARGUS_TUNNEL_DISCOVERY 🧚

Argus can be configured to discover tunneling protocols above the UDP transport header, specifically Teredo (IPv6 over UDP). The algorithm is simple, and so having this on by default may generate false tunnel matching. 🫠

The default is to not turn this feature on.

ARGUS_TUNNEL_DISCOVERY=no

🌸 ARGUS_TRACK_DUPLICATES 🌸

Argus can be configured to identify and track duplicate packets as a separate metric. While the algorithms are traffic type specific, you can use this strategy to identify problems within your packet collection infrastructure. 🕵️

The default is to not turn this feature on, but for some this feature is invaluable.

ARGUS_TRACK_DUPLICATES="no"

✨ ARGUS_SELF_SYNCHRONIZE ✨

Argus can be configured to be self synchronizing with other argi. This involves using state from packet contents to synchronize the flow reporting. Iconic behavior fr fr.

This adds additional complexity for deciding when to export flow records, and could unnecessarily increase the number of argus records generated. We recommend that you use this feature when you really need to.
ARGUS_SELF_SYNCHRONIZE=yes

✨ ARGUS_EVENT_DATA ✨

ok so bestie, Argus can literally spawn host-originated processes to go gather extra data and stats for you 🫶. we're talking periodic processes that poll for SNMP data (as one example), or that collect host statistics by reading procfs(). and also single-run programs that fire off at a specified time, or under certain conditions.

Events are programs that get run from argus itself, and their output gets wrapped in an Argus Event message header and sent on to the output collection. iconic behaviour honestly 💅

When these programs actually run is a whole configuration moment, and the basic strategies are:

  1. single shot, and
  2. periodically.

Some types of events are best run based on state changes — especially the ones that provide network status awareness. Events that just provide information, like what our current BSSID network is (argus-airport), or what our external IP address is (argus-extip), can run periodically, but they'd be best run when there are network transitions, such as new interface availability, or a new network association. vibe check: don't spam what you can trigger 🌸

These argus events get generated from the complete list of ARGUS_EVENT_DATA directives that you specify here.

The syntax is:

Syntax is: "method:path|prog:interval[:postproc]"
    Where:  method = [ "file" | "prog" ]
          pathname | program = "%s"
          interval = %d[smhd] [ zero means run once ]
          postproc = [ "compress" | "compress2" ]

and here are the examples, verbatim, no notes:

ARGUS_EVENT_DATA="prog:/usr/local/bin/argus-vms:20s:compress"
ARGUS_EVENT_DATA="prog:/usr/local/bin/argus-snmp:1m:compress"
ARGUS_EVENT_DATA="file:/proc/vmstat:30s:compress"
ARGUS_EVENT_DATA="prog:/usr/bin/uptime:30s"
ARGUS_EVENT_DATA="prog:/usr/local/bin/argus-lsof:30s:compress"
ARGUS_EVENT_DATA="prog:/usr/local/bin/argus-extip:60s:compress"

✨ ARGUS_KEYSTROKE ✨

This version of Argus supports keystroke detection and counting for TCP connections, with specific algorithmic support for SSH connections. yes, really, it's watching the vibes of your typing 🔥

The ARGUS_KEYSTROKE variable turns the feature on. Values for this variable are:

  • ARGUS_KEYSTROKE="yes" — turn on TCP flow tracking
  • ARGUS_KEYSTROKE="tcp" — turn on TCP flow tracking
  • ARGUS_KEYSTROKE="ssh" — turn on SSH specific flow tracking
  • ARGUS_KEYSTROKE="no" — [default]

The algorithm uses a number of variables, all of which can be modifed using the ARGUS_KEYSTROKE_CONF descriptor, which is a semicolon (';') separated set of variable assignments. Here is the list of supported variables:

  • DC_MIN — (int) Minimum client datagram payload size in bytes
  • DC_MAX — (int) Maximum client datagram payload size in bytes
  • GS_MAX — (int) Maximum server packet gap
  • DS_MIN — (int) Minimum server datagram payload size in bytes
  • DS_MAX — (int) Maximum server datagram payload size in bytes
  • IC_MIN — (int) Minimum client interpacket arrival time (microseconds)
  • LCS_MAX — (int) Maximum something - Not sure what this is
  • GPC_MAX — (int) Maximum client packet gap
  • ICR_MIN — (float) Minimum client/server interpacket arrival ratio
  • ICR_MAX — (float) Maximum client/server interpacket arrival ratio

All variables have default values, this variable is used to override those values. The syntax for the variable is:

ARGUS_KEYSTROKE_CONF="DC_MIN=20;DS_MIN=20"
ARGUS_KEYSTROKE="no"
ARGUS_KEYSTROKE_CONF=""

✨ ARGUS_OS_FINGERPRINTING ✨

This version of Argus supports operating system fingerprinting through the inclusion of ARGUS_TCP_INIT DSRs in tcp flow reports. Now here's the tea 🍓 — Argus itself does not do the fingerprinting. The ra* clients use the ARGUS_TCP_INIT DSR to fingerprint using pf.os or nmap like algorithms. team effort, no cap.

ARGUS_OS_FINGERPRINTING="no"

✨ ARGUS_GENERATE_HASH_METRICS ✨

This version of Argus supports exporting hash values for each flow. she's giving data, she's giving receipts 💜

ARGUS_GENERATE_HASH_METRICS="yes"

✨ ARGUS_HASHTABLE_SIZE ✨

This version of Argus supports modifing the default flow classification hash table size using this configuration file. Larger hash table sizes will improve sensor performance by reducing the 'big O' complexity of looking up cached flow records. algorithm girlies know 👑

The default value of 4096 is designed for endpoint sensing, where the number of flows should be < 1M per day. For high performance sensors (40-100G) we recommend > 10M (0x1000000) for the hash table.

ARGUS_HASHTABLE_SIZE=4096

🌈 SEE ALSO 🌈

ok that's the whole page bestie, you made it to the end 🎀 this was argus.conf 5.0.2, dated 17 November 2024, and it's the ARGUS.CONF(5) manual page 💖 go forth and configure, you absolute icon ✨

📦 where this page comes from