1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
#
# Copyright (c) 2000 QoSient, LLC
# All rights reserved.
#
# Permission to use, copy, modify, and distribute this software and
# its documentation for any purpose and without fee is hereby granted,
# provided that the above copyright notice appear in all copies and
# that both that copyright notice and this permission notice appear
# in supporting documentation, and that the name of QoSient not be
# used in advertising or publicity pertaining to distribution of the
# software without specific, written prior permission.
#
# QOSIENT, LLC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
# SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
# FITNESS, IN NO EVENT SHALL QOSIENT, LLC BE LIABLE FOR ANY
# SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
# RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
# CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
#
#
#
# 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
|
