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.
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-188.8.131.52/support/Config/*.conf | cut -d ':' -f 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.