Provided by: argus-server_5.0.2-3_amd64 
NAME
argus.conf - argus resource file.
SYNOPSIS
argus.conf
COPYRIGHT
Copyright (c) 2000-2024 QoSient, LLC All rights reserved.
DESCRIPTION
This is the canonical argus configuration file. All options that argus supports can be turned on or
modified using this configuration format. Argus will search for a system /etc/argus.conf file and will
open it and use it to seed all configuration options.conf. Previous versions of Argus supported
searching for argus.conf in $ARGUSPATH, $ARGUSHOME, $ARGUSHOME/lib, $HOME, and $HOME/lib, but this
support is deprecated. All values in this file can be overriden by command line options, or other
configuration files of this format when specified in using the -F option.
Argus will read any number of configuration files using the -F option, and command-line order is very
important.
Variable Syntax
Variable assignments must be of the form:
VARIABLE=value
VARIABLE="compound values"
with no white space between the VARIABLE and the '=' sign. Quotes are optional for string arguments, but
if you want to embed comments, then quotes are required.
Comments
Comments are supported using a '#' as the first character in the string, such as this string that you are
reading.
Embedded comments are supported preceeded by a " //" as you see in the C language. The preceeding 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 the space, the comment will be included as a part of
the configuration variable.
VARIABLE=value // comment
VARIABLE="compound values" // comment
ARGUS_FLOW_TYPE / ARGUS_FLOW_KEY
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_3_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.
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 seen in the ./support/Startup/argus scripts, this value is set to "yes", as the system
startup strategy requires the program to daemonize themselves, returning a value to the system, hopefully
quickly. Some systems, however, want to daemonize the tasks themselves, and 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 is included in each
output record. This is to allow you to 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 are tested for whether they are
hostnames, and if not, then they are tested wheter they are numbers conforming to any of the support
formats.
The configuration allows for you to use host names, however, do have some understanding how a FQDN, or
the special keyword `hostname` will be resolved by the nameserver before commiting 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.
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 to 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 are
hard coding the interface name for a specific observation domain, this is 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, as 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
By default (ie when no configuration is provided) Argus will open the first appropriate interface on a
system that it encounters. For systems that have only one network interface, this is a very reasonable
thing to do. But, when there are more than one suitable interface, you may need to specify the
interface(s) that Argus will read packets from. You do this either on the command line or in this file.
Argus can track packets from any or all interfaces, concurrently. The interfaces can be tracked as:
1. independant - this is where argus tracks flows from each
interface independant of the packets seen on any other
interface. This is useful for hosts/routers that have full-duplex
interfaces, and you want to distinguish flows based on their interface.
When using argus in 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.
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 is a "-e srcid" provided, this 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.
Srcid subsitution 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" inteface 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
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. This can put an undo load on systems.
If the 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 want to turn promiscuous mode off.
The default value goes into prmiscuous 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.
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 is can 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 is can 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 argu'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 reliablity 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 a 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 aggresively 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 compiled to support this option, Argus is capable of generating a lot of debug information.
The default value is zero (0).
Commandline equivalent -D
ARGUS_DEBUG_LEVEL=0
ARGUS_GENERATE_RESPONSE_TIME_DATA
Argus can be configured to report on flows in a manner than provides the best information for calculating
application reponse times and network round trip times.
# The default value is to not generate this data. # # Commandline equivalent -R #
#ARGUS_GENERATE_RESPONSE_TIME_DATA=no
ARGUS_GENERATE_PACKET_SIZE
Argus can be configured to generate packet size information on a per flow basis, which provides the max
and min packet size seen . The default value is to not generate this data.
Commandline equivalent -Z
ARGUS_GENERATE_PACKET_SIZE=yes
ARGUS_PACKET_SIZE_HISTOGRAM
Argus can be configured to generate packet size information on a per flow basis. This includes the
ability to generate a logorithmic frequency distribution histogram of the packet sizes seen. All argus
clients can print the distribution as a hex number, where each nibble is one of the columns of the
logarithmic histogram, and the relative values are from 0-15. 1 generally means that 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 be configured to generate packet jitter information on a per flow basis. The default value is
to not generate this data.
Commandline equivalent -J
ARGUS_GENERATE_JITTER_DATA=no
ARGUS_LOG_DISPLAY_PRIORITY
Specify the log level when sending messages to the 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 it audit data. This is available if MAC address
tracking and audit is not a requirement.
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 as well as the
packet count and byte counters.
Commandline equivalent -A
ARGUS_GENERATE_APPBYTE_METRIC=no
ARGUS_GENERATE_TCP_PERF_METRIC
Argus by default, generates extended metrics for TCP that include the connection setup time, window
sizes, base sequence numbers, and retransmission counters. You can suppress this detailed information
using this variable.
No commandline equivalent
ARGUS_GENERATE_TCP_PERF_METRIC=yes
ARGUS_GENERATE_BIDIRECTIONAL_TIMESTAMPS
Argus by default, generates a single pair of timestamps, for the first and last packet seen on a given
flow, during the obseration period. For bi-directional flows, this results in loss of some information.
By setting this variable to 'yes', 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 be configured to capture the encapsulation packet headers that it parses. This supports
the ability to realize and debug unknown/unexpectred encapsulation headers, as well as provide 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 is a need to not use the libpcap filter
optimizer, you can turn it off here. The default is to leave it on.
Commandline equivalent -O
ARGUS_FILTER_OPTIMIZER=yes
ARGUS_FILTER
You can provide a filter expression here, if you like. It should be limited to 2K in length. The
default is to not filter.
No Commandline equivalent
ARGUS_FILTER=""
ARGUS_PACKET_CAPTURE_FILE
Argus allows you to capture packets in tcpdump() format if the source of the packets is a tcpdump()
formatted file or live packet source.
Use this configuration variable to pecify the path to the packet capture file. Argus will generate the
file if it doesn't exist.
ARGUS_PACKET_CAPTURE_FILE="/var/log/argus/packet.out"
ARGUS_PACKET_CAPTURE_ON_PROTO
When an ARGUS_PACKET_CAPTURE_FILE is specified, argus allows you to 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. This is 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 allows you to capture packets in tcpdump() format
when there is a header parsing error in the argus header logic. This is designed to support the
development of argus when adding new packet headers parsing to the suite of headers, but is useful in
many other conditions.
ARGUS_PACKET_CAPTURE_ON_ERROR="no"
ARGUS_SSF
Argus supports the use of SASL to provide strong authentication and confidentiality protection.
The policy that argus uses is controlled through the use of a minimum and maximum allowable protection
strength, which is standard for SASL based appliations. Set these variable to control this 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 in this way does not affect internal argus variable in any way. As a
result, you can't set ARGUS_PATH using this feature.
Care should must be taken to assure that the value given the variable conform's to your systems 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.
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 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 parser 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 packets
contents to synchronize the flow reporting.
# 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
Argus supports the generation of host originated processes to gather additional data and statistics.
These include periodic processes to poll for SNMP data, as an example, or to collect host statistics
through reading procfs(). Or single run programs that run at a specified time, or under certain
conditions.
Events are programs that are run from argus itself, and its output is wrapped by an Argus Event message
header and sent to the output collection.
When these programs are run is a matter of configuration, and the basic strategies are 1) single shot and
2) periodically. Some types of events are best run based on state changes. In particular are the events
that provide network status awareness. Events that provide information, such as what is our current
BSSID network (argus-airport), or what is our external IP address, (argus-extip), these can run
periodically, but they would be best if run when there are network transitions, such as new interface
availability, or a new network association.
These argus events, are generated from the complete list of ARGUS_EVENT_DATA directives, that are
specified 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" ]
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.
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. Argus itself does not do the fingerprinting, ra* clients use the
ARGUS_TCP_INIT DSR to fingerprint using pf.os or nmap like algorithms.
ARGUS_OS_FINGERPRINTING="no"
ARGUS_GENERATE_HASH_METRICS
This version of Argus supports exporting hash values for each flow.
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.
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
argus(8)
argus.conf 5.0.2 17 November 2024 ARGUS.CONF(5)