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', 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)