Operating principles

The main program of complex NeTAMS consists of the following parts, which work in parallel and simultaneously, and called the services:



Service main is the main flow, from performance of which begins work the program. It determines the basic properties of system, it reads and investigates configurative file, starting other services, and it falls into the sleep to the completion of work NeTAMS. During the supplying of commands kill, shutdown, reload, appearance of critical failure or obtaining of signal SIGQUIT service main is spilled and attempts to stop all other services in order to correctly shut the data bases and to remove the interceptors of packets.

Service processor is nucleus NeTAMS, since precisely in it is determined the list of objects, on which will be produced the calculation, and very rules of calculation. All components of system are exchanged between themselves communications, for example by demands to BD or data about the traffic for the certain time interval. Processor ensures the dispatcher system of communications. Is possible only one copy of service processor program.

Service server provides the possibility to be joined to the working program through tcp-soket; control of program and output of statistics is possible with the aid of the commands.

Service data-source ensures the entering of the data about the traffic inside the program. As the sources of the data about IP- traffic can come out the means of the interception of the packets of systems FreeBSD (divert socket) Linux (module ip_.queue of system iptables), hearings of net interface (libpcap), statistics NetFlow of version 5, which is necessary from marshrutizatorov Cisco or from any other collector.

Service storage determines the data base, in which will remain the statistics and the part of the configuration of system. This can be standard Berkley DB UNIX hash, which there is in any system, or SQL the data base, located on the local or on the adjacent machine.

Service alerter makes possible for administrator to organize sending to itself or to the users of report about the passed and taken into account traffic, the information about the activity of system and so forth, etc.

Service scheduler accomplishes the assigned commands in the planned time. This is "virtual" service, since it is started always automatically and does not require konfigurirovaniya.

Service html organizes the automatic periodic creation of static html- pages, which contain information about the passed traffic, about the work of system, the state of the subsystems of quotas, billinga, loginov, the current configurative file etcetera. It is necessary to dispose local vebserver so that it would safely show these pages to administrator and users.

Service monitor organizes the detailed monitoring of traffic of assigned yunitov for the subsequent "selection".

Each object in the system (policy, it yunit and so forth.) has its unique number, so called OID, object identificator, which is key in the data base. It is generated automatically randomly with the creation of unit, so that do not forget to preserve configurative file after changes by command save. Identifier is represented in the form of the hexadecimal number, recorded by six symbols. For example, record for yunita of the type user appears approximately thus:

unit user oid 02628C name r556-2 ip 10.208.209.40
   email anton@localhost parent LAN1 acct-policy ip www rus

Each yunit besides identifier OID, and name, has information about the belonging by any group (it also it can not belong to any group), about its parameters (IP- address or, for example, the mask of network), list the politician of calculation and filtration of traffic, system policy, belonging with that determined data-source and it is other.

While predecessor NeTAMS (aaa+.fw) considered only ip-only traffic, now there is the possibility to divide data according to other signs. They are determined with the task of policy, policy. Politics can determine the rules of filtration and calculation. In any event besides the name and OID, is indicated the type of policy and target, i.e., principle according to which will be carry ouied calculation. For example:

policy oid 146633 name all-icmp target proto icmp
policy oid 1574B0 name web target proto tcp ports 80 81 3128
policy oid 153333 name server target units oid 0346E8

With working of packet by system the following sequence of events occurs:

1. If service data-source is disposed so that this packet "is turned up" into the program, then the title of the packet is analyzed
   
2. It is checked, to what yunitu from the configuration corresponds packet, via the comparison of entire table with fields ip_.src and ip_.dst title of packet. One and the same packet can correspond to several stock-taking units, and relate to several inserted groups.
   
3. For each yunita is checked the value of the established system policy
   
4. For each yunita consecutively moves the chain of those established politician on the filtration of traffic, is checked it does correspond packet to the established policy. If after the sequential sorting of entire list packet "is passed", analogously moves the chain of the established rules of calculation (acct-policy), and if packet falls under the appropriate rule, for this yunita occurs an increase in appropriate of this policy of counter, i.e., bytes in/out. Packet returns to nucleus OS (data-source ip-traffic) or is destroyed (data-source libpcap or netflow).
   
5. If packet is not passed by rule fw-policy or sys-policy, it silently is rejected and the calculation of traffic on it is not conducted.

The data about the traffic are accumulated in the form of the "flows" (flows), which periodically (for this it answers parameter flow-lifetime of service processor) they are discarded into the base of data (table raw), additionally in the system are supported the values of counters about the passed traffic since the beginning of the present hour, day, week and month for each combination it yunit + the policy of calculation. After the appropriate time interval the data about the traffic for passed interval nevertheless remain in the base (table summary), providing reliability and integrity of data to the period random or the planned reloadings of system.

Information about the current and passed traffic can be obtained, after being connected to the program through telnet and after collecting the commands:

• show list full
• send report to {user_.name} on {unit_.name} (with the disposed service alerter)
• html (with the disposed service html - and this the best version)