Content-type: text/html
The configuration file is structured as a collection of flow descriptors and model definitions. The concept is that one identifies specific Argus Flow Activity Records through specification of an Argus flow descriptor matching statement.
Argus record flow descriptors are compared to the flow descriptor matching statements in sequential, or "fall through", order, much like existing Access Control List definitions supported by routers, switches and firewalls.
The matching statement references a flow model that is used to modify the flow description of each Argus record. Records are aggregated based on the modified flow descriptor that results from applying the flow model that is refererenced in the matching flow descriptor matching statement.
In each flow descriptor matching statement is a TimeOut period, which is how long the aggregator will hold the flow cache before reporting it, and an IdleTimeOut period, which is how long the aggregation process will hold the flow in its cache, if there is no activity.
If a record doesn't match any statement in the configuration, then it is aggregated based on its unmodified flow descriptor. This aggregates flow reports from the same long lived flow.
An Argus flow matching statement specifies values for the fields src and dst IP address, the protocol, and for TCP and UDP, the src and dst port numbers.
Proto field can be any valid IP protocol number, or the keywords, found in the /etc/protocols file. For systems that do not support /etc/protocols, ragator() understands 'tcp', 'udp', 'icmp', and 'igmp' tokens on its own.
Port values can be any valid key word in the /etc/services file, or, of course, numbers.
When the protocol is 'icmp', the values after the Proto field
are valid ICMP type and code values. Valid icmp types are:
echo
unreach
srcquench
redirect
timexed
timestamp
info
address
Numbers can be specified in decimal or as hex with the 0x prefix.
Argus flow matching statements reference a specific aggregation model specifier, which describes how the flow descriptor will be modified prior to aggregation. This entry in the aggregation configuration, specifies what values will be preserved in the flow descriptor, and how they should be modified.
When dealing with IP flows, the source and destination address fields can be modified using mask descriptors. Protocol values and source and destination ports, however, are simply retained, by specifying "yes", or discarded, by specifying "no".
There can be any number of aggregation model specifiers, but they must have a unique Model id number.
#label id SAddr DAddr Proto SPort DPort Model Duration Idle Flow 100 * * * * * 200 21600 43200 #label id SAddrMask DAddrMask Proto SPort DPort Model 200 255.255.255.255 255.255.255.255 yes yes yes
The Flow descriptor matching statement 100 matches all Argus records, because all the flow descriptor fields are wildcarded, using '*'. Each record will be modified using the Model 200 defintion, which preserves all fields, and the resulting aggregate will be held for 21600 seconds, at which time it will be reported.
While this type of configuration is not likely to aggregate many records, it will be very good at aggregating long lived single flows, such as persistant ping sessions between hosts, which can generate a lot of activity data. Since this may be what you are really after, we'll present a more complex example.
#label id SAddr DAddr Proto SPort DPort Model Duration Idle Flow 100 * * icmp echo * 300 21600 43200 Flow 101 * * udp * domain 201 3600 300 Flow 102 10:24 10:24 tcp * 80 201 300 300 Flow 103 10:24 * tcp * 80 230 300 300 Flow 104 * * tcp * 80 210 300 300 Flow 105 * * * * * 241 120 300 #TCP and UDP Flow Model Definitions #label id SAddrMask DAddrMask Proto SPort DPort Model 201 255.255.255.255 255.255.255.255 yes no yes Model 210 255.255.255.255 255.255.255.252 yes no yes Model 230 255.0.0.0 255.255.255.255 yes no yes Model 241 0.0.0.0 0.0.0.0 yes no yes # ICMP Flow Model Definitions #label id SAddrMask DAddrMask Proto Type Code Model 300 255.255.255.255 255.255.255.255 yes yes yes
Argus records are matched in falling order, so you will test all Argus records against flow 103, then 100, then 102, and finally 106. Flow Id numbers are used to report syntax errors in the configuration, and they don't have to be unique.
This configuration is designed to track pings, the clients of tcp services and the server of udp based DNS services. All other traffic is accounted for either by protocol or lumped together. Although not a particularly useful configuration, it is an example of how to architecture your aggregation.
Flow 103 matches all icmp echo (ping) tranactions, and indicates that ragator should use FlowModel 300 to aggregate ping transactions. The aggregate should be held for 43200 seconds (12 hours) and then reported.
Model 300 is designed to aggregate ICMP transactions without modification. The result will be that ragator() will aggregate only echo transactions between the same machines. Very useful for tracking generic connectivity failure between two machines that are pinging one or the other.
Flow 100 matches all destination port 80 tcp connections where the servers are in the 10.23.123 network, and aggregates them based on Model 210, holding the aggregate for 5 minutes and then reporting them. This is an example of an aggregation scheme that will report on HTTP sessions (clumps of TCP connections that occur in a short time range) to a set of 4 load balanced HTTP servers. We use the CIDR address format to get the 4 contiguous addresses in a single statement.
Model 210 is designed to track the clients of services, so the src address
goes unmodified (255.255.255.255), but the servers (dst address) are going
to be modifed to represent a subset of the class C network address
(255.255.255.252). basically mask off the last 2 bits in the address.
The protocol value and the dst port (in this case the service port) will be
preserved, but the src port is removed, so the individual TCP connections
can be matched.
Flow 102 tracks udp based DNS transactions, aggregating them based on Flow
Model 201 and holding the aggregate for an hour (3600 secs). This strategy
reports the aggregate DNS transactions between each client and server pair.
To do this, the Flow Modeler preserves everything except the source port,
which changes on each DNS request.
All other traffic is aggregated based on Flow Model 241 and reported every
12 hours. Flow Model 241 is designed to track just the protocol, so this
will generate Argus Records that have bytes and packets for TCP and UDP and
the other protocols but it will not report the addresses. This can be
useful.