Home > Uncategorized > Configuring argus clients with .conf and .rarc, understanding argus and argus-clients

Configuring argus clients with .conf and .rarc, understanding argus and argus-clients

There are two ways to configure ra* clients: using the -f argument, and using an .rarc file located within the user’s $HOME.

This article falls into better context when referencing Configuring argus clients to have access to country code.


Carter doesn’t seem to be a fan of failing processes when “useless data” is provided at command line. So, when I start ra as follows, the process does not fail, even though there is no known database path for GeoIP country code database:

ra -S localhost:561 -M dsrs=cocode

For instance, in order to have ralabel report sco, you must either configure the .conf file or an .rarc file for all clients to use.  If you opt to use a .conf file, you must use the -f argument to direct the ra* client to the conf file.

Command line passed arguments supercede .conf, .conf supercede .rarc.

Reviewing the man page of ra, you can see a reference to the rarc man page for configuration options.

Create the .conf/.rarc file as follows (ra- rc, get it?):

The .rarc file is located in users’ $HOME.

Within the source tree of argus, you can review the example .conf files for the variety of environmental variables that can be loaded by the ra* clients:

grep -r = /root/argus-clients-3.0.6.2/support/Config/*.conf | cut -d ':' -f 2

You can review the available environmental variables as of today for argus-clients 3.0.6.2.

Does it work on all ra* clients?
As documented, the dsr ‘cocode’ should provide the country code information within the returned flow data; but from my testing it doesn’t.

Unfortunately, it doesn’t appear that rasqlinsert allows dsrs as ralabel does straight from the argus source, therefore the following doesn’t appear to store the source country code (sco) and destination country code (dco) (from tha local ARIN database) as additional records:

rasqlinsert -S localhost:561 -m none -d -s stime dur flgs proto saddr sport dir daddr dport spkts dpkts sbytes dbytes state sco dco -w mysql://argus:SQLPASS@localhost/argus/argustable_%Y%m%d -M time 1d

You can however, consider ralabel, as well as other ra* clients, as the middle man to generate more information on flow records.

This proves what Carter describes in this thread for the architecture of the argus project (while bluntly accusing me of trolling :'( ).

  • The argus process should always be very fast and light, and it’s one purpose is to be a probe that creates records.
  • Any additional processing or more extrapolating/creating more information about flow records is the job of various clients.
Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: