# 
#  Copyright (c) 2000-2002 QoSient, LLC
#  All rights reserved.
# 
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2, or (at your option)
#  any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
# 
#
# Flow Modeler Policy Configuration
#
# Carter Bullard
# QoSient, LLC
#
#
#   This configuration is a ragator(1) flow model configuration file.
#
#   The concept is that one identifies specific Argus Flow Activity
#   Records through specification of an ArgusFlow matching statement.
#   The matching statement references a flow model that is used to
#   modify the flow description of each transaction.   Records are
#   aggregated based on matches of the modified flow description.
#   In each statement is a TimeOut period, which is how long ragator()
#   will hold the aggregated record before reporting it.
#
#   If a record doesn't match any statement in the configuration,
#   then it is aggregated based on its unmodified flow descriptor.
#
#   An ArgusFlow 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.
#
#   '*' denotes 'any' value.
#
#   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.
#
#   Here is a valid configuration:
#
#      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.
#
#      All Model Id numbers must be unique, and references must be to 
#      Model Id numbers that are in this configuration.
#
#      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.
#      
#
# 
#label   id    SrcCIDRAddr        DstCIDRAddr         Proto  SrcPort  DstPort   ModelList  Duration

Flow     103       *                  *               icmp     echo      *         300      43200
Flow     100       *            10.23.123.65:30        tcp      *       www        210        300
Flow     102       *                  *                udp      *      domain      201       3600
Flow     106       *                  *                 *       *        *         241      43200


# TCP and UDP Flow Model Definitions
# label  id      SrcAddrMask     DstAddrMask      Proto  SrcPort  DstPort

Model    200   255.255.255.255  255.255.255.255    yes     yes      yes
Model    201   255.255.255.255  255.255.255.255    yes      no      yes
Model    202   255.255.255.255  255.255.255.255    yes      no       no
Model    203   255.255.255.255  255.255.255.255     no      no       no
 
Model    210   255.255.255.255  255.255.255.252    yes      no      yes
Model    211   255.255.255.255  255.255.255.0      yes      no       no

Model    220   255.255.255.255  255.255.0.0        yes      no      yes
Model    221   255.255.0.0      255.255.0.0        yes      no       no

Model    231   255.0.0.0        255.0.0.0          yes      no       no
Model    232   255.0.0.0        255.0.0.0          no       no       no

Model    241   0.0.0.0          0.0.0.0            yes      no       no
Model    242   0.0.0.0          0.0.0.0            no       no       no


# ICMP Flow Model Definitions
# label  id      SrcAddrMask      DstAddrMask     Proto    Type     Code

Model    300   255.255.255.255  255.255.255.255    yes     yes      yes
Model    301   255.255.255.255  255.255.255.255    yes     yes       no
Model    302   255.255.255.255  255.255.255.255    yes      no       no

Model    310   255.255.0.0      255.255.0.0        yes     yes       no
Model    311   255.255.0.0      255.255.0.0        yes      no       no
Model    312   255.255.0.0      255.255.0.0         no      no       no


