[Previous] [Contents] [Next]

4. Filter

Correctly configured filter provides with all required information. That depends on reasonableness of the filter, how much useful and sufficient information will stand out.

There are calculating of traffic for each rule and direction of transfer. I.e. data of a source and the receiver undertake and are checked through the filter from the next packet, at corresponding rules the "direct" statistics changes. Then, data of a source and the receiver vary places and this information is repeatedly checked through the filter, at corresponding rules the "return" statistics changes. I.e. each rule has two counters of bytes ("sent" - it is sent and "recv" - is received).

It is necessary for transferring to tv3 after preparation of the filter by means of a rexx-script <tv3 directory>\REXX\setfilter.cmd:

setfilter.cmd file_name

It is possible to make the same through the WEB-interface (see XML-source). Installation of the new filter does not demand tv3 reboots.

The easiest way to understand logic of work of the filter is to see the example.

4.1. An example of the filter

Let's see a simple task of calculation of traffic the Internet-gate, having mail service (smtp) and a proxy-server. It is necessary to count up statistics of each user of a proxy-server and the traffic coming on mail service from the Internet. Let's the address of a local network - 192.168.33.0 mask of a network - 255.255.255.0, the address of a gateway in a local network - 192.168.33.1, the real address of a gate from the Internet - 195.72.224.229, port smtp - 25, proxy - 8080. Users: 192.168.33.2, 192.168.33.3, 192.168.33.4. Schematically rules of our filter will be as follows:

As we see, the rule 2 has the enclosed rules, it is made to not specify the address and port of destination for each user: the enclosed rules will be looked through only if conditions of a parental rule were satisfied. It not only simplifies the task of rules, but also raises productivity of work of the filter: Rules of users will not be looked through in general if the packet is not inquiry to a proxy-server from an internal network.

XML for this filter can be written as:

<?xml version="1.0" encoding="utf-8"?>
<filter>
<rule stop="Y">
<path>Internet/SMTP</path>
<dst>195.72.224.229/32</dst>
<proto name="tcp">any:25</proto>
</rule>
<rule>
<src>192.168.33.0/255.255.255.0</src>
<dst>192.168.33.1/255.255.255.255</dst>
<proto name="tcp">any:8080</proto>
<rule stop="Y">
<path>PROXY/Boss</path>
<src>192.168.33.2/32</src>
</rule>
<rule stop="Y">
<path>PROXY/workstation A</path>
<src>192.168.33.3/32</src>
</rule>
<rule stop="Y">
<path>PROXY/workstation B</path>
<src>192.168.33.4/32</src>
</rule>
</rule>
</filter>

4.2. The description of filter elements

rule - a rule of the filter, attributes: stop (Y/N) - if the rule has worked, to summarize statistics and to stop viewing corrected the given level of an enclosure. dataonly (Y/N) - to count up the general length of a packet, including heading of the report (N), or only the size of data (Y). A situation when it is necessary to consider only volume of data transferred by the report is specific enough and in practice is seldom used. The real traffic in some conditions (bad communication lines, not optimum adjustment of network services) can exceed considerably volume of data due to a fragmentation of packets.

path - this element does not influence on filter work, however it is used by clients for statistics display in the tree-form structure. Units of a target tree that is under construction on the basis of elements path, are divided by a symbol "/". So, the following evident structure will be given to the user from our filter:

Internet
SMTP statistics
PROXY
Boss statistics
workstation A statistics
workstation B statistics

If the element "path" is not specified - the statistics of the given rule to the user is not displayed, further will be shown as it can be used.

src/dst - addresses, accordingly, a source and the receiver in the form of: the IP-address/IP-mask. If the mask is not specified, its value is accepted equal 255.255.255.255. The mask can be set or in the form of 4 numbers divided by dot, or in the form of one number specifying quantity of bits of the mask. It is possible to setup several addresses (up to 255) of sources and-or receivers in one rule. There are two keywords can be used: HOST - any IP-address of local station, OTHER - any other (not local station's address). You can use MAC-address also (for ex. 00:15:f2:d6:fa:f5). In this case IP-addresses will be detected via local ARP-table. If the element src (dst) is not specified, packets with any addresses of a source (receiver) are accepted.

proto - the protocol and ports of a source and the receiver (UDP, TCP), or type of the report (ICMP). The attribute name specifies the protocol and can accept values UDP, TCP, ICMP, OTHER (any of previous three) or ANY (any). Value of an element - lists of ports of a source and the receiver, divided by a symbol ":". Lists can be specified as set of ports through a comma: 25,110,80 and-or ranges: 100-3000. Also logic values can be written as more/less/not suffixes, accordingly "gt","lt","!". Instead of the instruction of ports of a source or the receiver it is possible to use value "any" or "*" (any).

For example:

<proto name="tcp">gt1023:25,110</proto> - the TCP-packet from port of a source is more then 1023 on port of the receiver 25 or 110

<proto name="udp">!gt1024:100-3000,3050</proto> - a UDP-packet from port of a source 1024 or less on port of the receiver from 100 up to 3000 inclusive, or 3050

<proto name="icmp">0,9:0,9</proto>

It is separately necessary to note, that both values before and after a divider ":" should be identical for the instruction of type (number) of report ICMP. For type OTHER both values should be "*" (or ANY).

There can be specified some elements proto in a rule. If there are no proto elements - there will be checking of packets of any protocols.

4.3. Rules - "traps"

Let's return to our filter in the first part of the given section. We shall assume a situation when there will be routing between internal and external interfaces, and in a local network there can be mobile users of our mail server in a local network who address to SMTP-service to the address of the external interface.

Any packet sent from such user from a local network to post service will correspond to the first rule, but the problem consisted in calculation external Internet-traffic on service SMTP. We shall copy the first rule in the form of a rule with two enclosed for exception of this situation:

<rule>
<dst>195.72.224.229/32</dst>
<proto name="tcp">any:25</proto>
<rule stop="Y">
<src>192.168.33.0/255.255.255.0</src>
</rule>
<rule>
<path>Internet/SMTP</path>
</rule>
</rule>

Thus, all packets on port 25 from a local network on the address of the external interface of our server will get in the first enclosed rule, and packets from the Internet - in the second. We shall pay attention that the element "path" is set only in one rule, it is only conducts calculation of the statistics necessary to us. The statistics of the parental and first enclosed rule does not interest us, therefore to set "path" there does not work and it will not be displayed by clients tv3.

4.4. Debugging of the filter - "observer"

It is necessary to learn that particularly packets get in this or that rule at construction of the filter periodically. It is convenient to apply to such situations "promiscuous" rules. Any rule can be switched to a mode when data of packets changed statistics of a rule are remembered. This can be done only by administrators.

It is the most convenient to make it through the WEB-interface: pass in section "Filter" (see View) and click on heading of an definite rule. There will be a window in that, after authorization, each 5-10 seconds the information on the several last packets that have got in a rule (a direction of transfer, the address of a source and the receiver, the length of a packet) will be displayed.

If any record in this list has a direction "both" is means, that the corresponding packet has affected both "straight line", and on "return" statistics of a rule that cannot be in correctly constructed filter.

For reception of these data from a command line script <tv3 directory>\observer.cmd .


[Previous] [Contents] [Next]