-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Welcome to the openargus clients wiki! Here we'll try to use GitHub to develop some new features.
In preparation for Argus 4.0 we're going to move some of ArgusPro's features to the open source, such as json processing and importing other flow data into the Argus processing system.
Argus 4.0 is focused on generating argus data in as many points in the network as possible, including external and internal high speed links, workgroup edges, endpoints and wireless access points. This is important to getting the granular visibility for effective cyber detection and forensics. Also, there is a very large opportunity to detect sophisticated internal attack strategies by comparing data from multiple points in the network at the same time.
Argus has been ported to most endpoint operating systems and OpenWRT access points, so we have a good start on getting a lot of sensors into an environment. As a part of improving visibility throughout the network, we're also going to import data from other flow systems. Argus already processes NetFlow and IPFIX records, but there are a lot of other flow data strategies out there. In particular, we'll want to import Zeek connection logs, as many organizations generate Zeek data, Google VPC flows, and possibly some of the single letter flows, like Qflow, Jflow, and maybe Kflow records.
Argus 3.0 sensors run great in endpoints today. The open source argus code is very portable, and runs in a number of operating systems, including Linux, and all Linux variants, RHEL, CentOS, Fedora, OpenSUSE, Debian, (and all of these subvariants), Windows, FreeBSD, HPUX, Solaris, IRIX, CrayOS, VxWorks, PSOS, and OpenWRT, so we have a good start. There are specific features that are needed to achieve complete network accountability on endpoints, as there are a lot of interfaces types that exist that we all would like to monitor. BlueTooth interfaces, RadioTaps, USB devices, VPNs, even docker interfaces are fair game for monitoring in an endpoint. And of course there are a lot of different types of endpoints now ... cloud based VMs and containers are a part of the mix.
Argus 4.0 will try to bring the experiences we've had in porting Argus and in trying to come up with some basic zero-configuration strategies for getting complete network accountability.
Argus can natively read Netflow V 4,5 and flow-tools flow formats. And as of argus-clients.3.0.8.4 argus can convert json formatted Zeek conn.logs into Argus binary formats using our existing program raconvert.1 ... Json because we added json processing into the argus client library, but we can just as easily do non-json formats as well.
We extended raconvert.1 to take in a conversion map, using the '-f conversion.map' command-line option. And the specific support for converting zeek con logs is done through the support/Config/raconvert.zeek.conf file. This sample raconvert conversion map, should work for all the basic zeek conn.log variables, and as new are added, this file will need to be updated.
raconvert.1 can convert any json formatted string into a flow record, if it contains a minimum set of flow identifiers. Start time, an IP address or name, some metrics and optionally some metadata, is all that is needed.
This approach should work very well with Google VPC flow logs. If we can find some real examples of VPC flow logs, we can generate a raconvert.google.conf conversion map. Should be pretty easy ...