FreeBSD Manual Pages

home | help

ARGUS.CONF(5) File Formats Manual ARGUS.CONF(5)

NAME
argus.conf - argus resource file.

SYNOPSIS
argus.conf

DESCRIPTION
This is the canonical argus configuration file. All options that argus
supports can be turned on or modified using this configuration format. Ar-
gus 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 sup-
ported 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 op-
tional 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_TU-
PLE', '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 daemo-
nize 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 sup-
port a number of formats as legitimate values. Argus and argus clients sup-
port 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 charac-
ters. 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 re-
solved 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 inter-
face 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 pro-
grams 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 spe-
cific observation domain, this is done in the ARGUS_INTERFACE specifica-
tion.

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 ar-
gus 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 spec-
ify 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 in-
terfaces 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 in-
terface.

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 sin-
gle
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 op-
tion.

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 re-
stricting 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 in-
dicated 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 de-
fault. If a srcid is specified using this option, it overrides the de-
fault.

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 combina-
tion 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 sys-
tem, 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 ex-
ists in and can access. Generally used when argus is running with privi-
leges, 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 direc-
tory, 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 proto-
cols of interest to enable a detailed control plane flow monitoring capa-
bility 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 pro-
tocols 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 privi-
leged 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 direc-
tive can be used to change argu's group id value to a 'lesser' capable ac-
count. 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 ./sup-
port/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 fil-
ters.

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 mech-
anism.

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_STA-
TUS_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 de-
pending 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 AR-
GUS_IGMP_TIMEOUT=30 ARGUS_FRAG_TIMEOUT=5 ARGUS_ARP_TIMEOUT=5 AR-
GUS_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 equiva-
lent -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 dis-
tribution 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 con-
nection 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-di-
rectional 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/un-
expectred 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 de-
fault 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 lim-
ited 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/proto-
cols, and the tunnel protocols that can be discovered using the ARGUS_TUN-
NEL_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 ar-
gus header logic. This is designed to support the development of argus
when adding new packet headers parsing to the suite of headers, but is use-
ful in many other conditions.

ARGUS_PACKET_CAPTURE_ON_ERROR="no"

ARGUS_SSF
Argus supports the use of SASL to provide strong authentication and confi-
dentiality 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 ap-
pliations. 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 li-
braries 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 fea-
ture.

Care should must be taken to assure that the value given the variable con-
form'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 con-
tinue 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, tun-
nel 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 match-
ing.

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 sepa-
rate metric. While the algorithms are traffic type specific, you can use
this strategy to identify problems within your packet collection infra-
structure.

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 in-
volves 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 addi-
tional 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 AR-
GUS_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 fin-
gerprint 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 look-
ing up cached flow records.

The default value of 4096 is designed for endpoint sensing, where the num-
ber 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

Header And Logo

Peripheral Links

Site Navigation

FreeBSD Manual Pages

Header And Logo

Peripheral Links

Search

Site Navigation

FreeBSD Manual Pages