NeTAMS
Network Traffic Accounting and Management System
(c) 1998-2003 Anton Vinokurov(c) 2003 NeTAMS Development Team
All rights reserved. See 'Copying' file included in distribution.
For latest version and more info, visit this project web page located at http://www.netams.com
Document version 1.6 / Software version 3.1(1554) / Document date 16-05-2003
Contents:
- What is NeTAMS
- Installation
- Basic principles
- Configuring and first run
- Command list
- Typical configuration and tuning
- Some words on traffic diversion rules, data-source service
- Subdivision of Russian/International traffic based on prefix files
- What is no-local-pass
- What is break flag [%]
- Samples for different environment
- Traffic monitoring
- OID automatic generation and reloads
- System policy
- NeTAMS API for Perl srcipts and CGI
- Web logins service
- Bug reporting and bug sources
- OS setup for non-interruptuble NeTAMS
- Security
- Additional notes
1. What is NeTAMS
NeTAMS is the network traffic control and accounting software.There are no universal traffic accounting software exist. A lot of programs and scripts can be easily found in Internet, but they can do a very limited, specific set of tasks. Such a solutions are not scalable, not extendable, easy to set up but hard to manage. It is practically impossible to get a little bit more from this program rather author built in. The major part of "scrips" do not survive server reload and barely could provide a day-before-yestarday traffic information. NeTAMS pretends to accomplish for you what was very expensive for customers lately. This program registers IP-traffic flows going through Unix router, including address translation, saves statistics in database, provides access control for individual computers, networks and computer groups.
NeTAMS collects traffic information, for instance, by capturing packets going via network interface (libpcap), divert socket (ipfw divert), NetFlow flow or any other module. After data processing and summarizing information is stored in database from which statistics might be retrieved by direct query or web interface. At the same time access control, quotas, user rights can be accomplished. The program controlled by telnet connection to given TCP server port or command line utility. Statistics can be displayed by web interface or e-mail reports.
2. Installation
To perform successful installation and configuration administrator is supposed to have at least basic knowlege about Unix OS and TCP/IP. But in any case one is better read this document to the end in order to perform all configuration correct.Unpack the archive to the /usr/local/netams directory:
tar zxvf netams.tar.gz /usr/local
Edit the Makefile for path, database and operating system type. Configuration script is under constraction and will be provided later. Also you can change default configuration and log file paths. Default values are:
PATH_TO_CONFIG="/root/netams/netams.cfg"
PATH_TO_LOG="/var/log/netams.log"
System requirements:
- If you have FreeBSD (recommended version at least is 4.3, since previous releases contain ugly version of pthreads), your kernel configuration must have:
options IPFIREWALL
options IPDIVERT
othewise you will be not able to pass data packets to the program. Type dmesg and have a look. - If you have Linux, you must use kernels 2.4.х or upper, and iptables. Nexy, your system must have netfilter package and libipq library properly installed, they are typically not in a default installation. You should visit http://www.netfilter.org site, read the documentation, download, install it and rebuild a kernel.
- In case of NetFlow accounting, you do not need in previous features.
- For a serious work, install the SQL database, http://www.mysql.com, and do not use unix hash database from libdb (also supported by NeTAMS). You can also run PostgreSQL (www.postgresql.com), make sure you have "tcpip_socket = true" in you postgresql.conf and "host all all 127.0.0.1 255.255.255.255 trust" in pg_hba.conf
make
In a success case you should have netams executable in current directory. If you encounter an error during compilation process, see section 7 of this documentation.
Command line control utility, netamsctl, will be build also. Arguments are:
netamsctl [-f path_to_rcfile] cmd
where:
path_to_rcfile - optional, path to netamsctl profile (see below)
cmd - netams command, possible in several words. Do not forget to backslash quotes (\"something\")
Configuration profile expecting to be in:
~/.netamsctl.rc
.netamsctl.rc
/usr/local/etc/.netamsctl.rc
/etc/.netamsctl.rc
It consists of several lines with key=value pairs, possible keys are:
login=... - log in user name
password=.. - user's password
host=... - host name to connect, default is localhost
port=... - TCP port number, default is 20001
Now you should create a first-run configuration file. For success, it is important to understand how NeTAMS works.
3. Basic principles
NeTAMS daemon is a С++ multithreaded application. Each thread performs a separate task of its own: process the traffic flowing the router, stores traffic information into database, answers to extermal requests and commands, and so one. Internals design chart is following.
Each thread names "service" and defines in configuration file. There are two basic services: main (not needed to be defined in config file, but some global commands affecting its functionality) и processor (should be defined)main service is a general thread from which program starts. It defines general process properties, read and parse the configuration file, starts another services and sleeps until program end. On kill, shutdown, reload commands to be send, critical failure or SIGQUIT signal it wakes up, trying to stop all other services for graceful database connection shutdown and packets intercepr rules and all sockets removing.
processor service is a NeTAMS kernel, because it handles all accounting objects and policies tree. All system components speaks each other by some sort of messages, like database queries or traffic data for a given period of time. Processor is a messages dispatcher. Only one processor service instance per daemon is possible.
server service provides TCP connections gateway for external management and obtaining the statistics data.
Traffic data flows are collected by program via data-source service. Up to date only IP traffic information is accepted, but with existing software design it is theoretically possible to write any other modules, for example for e-mail messages, proxy server or voice calls accountin. FreeBSD divert, Linux ip_queue, libpcap/bpf, Cisco NetFlow are used as data sources. You can also write your own module.
storage service defines a database for storing statistics information. It can be standart UNIX hash, which exist anywhere, or SQL database residing on local or remote host. There are two data formats, raw and summary, you can hold either each format or both in the same database.
alerter service lets the administrator to send to himself or to the users traffic or system activity reports and so one.
scheduler service maintains executing given commands intime. This is a "virtual" service, it is starting automatically and does not need to be configured at all.
html service periodically creates a static html pages at a given path with traffic or system activity information. These pages (having a web server properly configured) can be browsed by administrator or a client, without program interruption.
monitor service collects packets information for specified units.
Each system object has a unique number, so-called OID, an object identificator, which also acts as a database key. It automatically generates on object creation, so do not forget to save configuration file after the first run or modifications. Indexing on objects names is noneffective from performance viewpoint, and renaming would result in old statistics lost. Identificators are represented in hexadecimal numbers written by six digits. Their actual values are not essential except the first byte shows an object type.
The NeTAMS initial design was oriented to account everything, from IP traffic to system logins, chche hit ratio or mail queue length. Now only IP traffic accounting is implemented. Main accounting unit is unit, or NetUnit, which is defined in processor service configuration. Units can be:
- host (single host), having one IP-address
- net (subnetwork), having network address and subnet mask
- cluster (cluster), e.g. host with several IP-addresses
- group (group), the union of other groups, hosts, networks and clusters
Examples:
|
unit group oid 056255 name MYNET unit host oid 02238E name gate ip 195.208.22.1 acct-policy all-ip all-web unit cluster oid 0346E8 name srv ip 195.208.22.2 ip 212.192.24.27 unit net oid 043D1B name net1 ip 195.208.22.0 mask 255.255.255.0 parent MYNET |
Each unit, in addition of unique identifier (OID) and name, has optional group membership information, parameters (IP-address, subnet etc.), and accounting and filtering policies list.
While NeTAMS predecessor (aaa+fw) accounted only ip traffic without protocol/port subdivision, now such things became possible. Rules are set while policy defines. Policy can be accounting or firewalling by nature. In any case, in addition to name and OID, policy type (acct or fw) should be set, and rule also, named as a target. For example:
|
policy acct oid 146633 name all-icmp target icmp policy fw oid 1574B0 name all-web target tcp-http policy fw oid 153333 name server target units oid 0346E8 |
Here is a list of packet processing steps:
- If data-source service (see below) is set up, packet is copied from the kernel to NeTAMS process, and its header is analyzed
- All units table searched for a match (by ip_src and ip_dst fields). One packet can corresponds to several units simultaneously, for example to host, subnet, group, and upper-level group
- For each matched NetUnit, all firewalling rules chain is looked over one by one, and target matching is performed. If packed is "passed" after such a filtering, all accounting rules chain is looked over, and on match, corresponding acct-policy counters are increased in in/out (send/recv) directions
- In successfull firewalling chain pass, after an accounting, packet is copied back to the kernel. Otherwise, packet is silently dropped
Traffic data are collected in form of (flows), which are pariodically (time period is defined by flow-lifetime variable in processor service) flushes to database (raw table). In addition, counter values starting this hour, day, week, month and from unit+policy pair first definition moment are supported. After each interval ends, counters are stored into summary table, then resets. More exactly, periodic data are frequently re-saved in order to maintain database consistency.
Current traffic information can be obtaining by connection to NeTAMS daemon process via telnet command and typing commands:
show list full
send report to {user_name} on {unit_name}
For fore details, see command reference following.
4. Configuring and first run
Make a first a simple configuration file named /usr/local/etc/netams.cfg
# configuration file example 1 begin debug none user name admin real-name Admin email root@localhost password 123 permit all service server 0 login any listen 20001 max-conn 6 # configuration file example 1 end |
Run:
./netams -ld
There will be no accounting at all now, you can only log in and run some commands.
Next, read all this documentation carefully, and write your own config file. You should have something like this:
# configuration file example 2 begin debug none user name admin real-name Admin email root@localhost password 123 permit all service server 0 login any listen 20001 max-conn 6 service processor 0 lookup-delay 2 flow-lifetime 5 policy acct name all-ip target ip unit group name ALL acct-policy all-ip unit host name server ip 192.168.1.1 parent ALL acct-policy all-ip storage 1 all service storage 1 type hash path /tmp service data-source 1 type ip-traffic source divert 199 rule 10 "ip from any to any via rl0" service alerter 1 report oid 06100 name rep1 type traffic period day detail simple smtp-server localhost # configuration file example 2 end |
5. Command list
Information on commands and their parameters is grouped by service nameAll these command can be used in configuration file set up. Same time, almost all of them can be used in interactive configuration process, and no restart is neccessary. Exception is database definition, for example.
You can always get a help on commands by typing ? ; on parameters type command_name ? . You should have shomething like:
>?
top level commands
data | send raw data to processor service
debug | turning on or off debugging on some action
exit | finish this client session and disconnect
kill | kill the daemon very quickly, with last data loss
mode | switch the client operation mode
read | get raw data from processor service
reload | gracefully shutdown and restart the daemon
save | write the running config to a file
service | set up service
show | shows various system parameters
shutdown | gracefully shut down the daemon
user | users management
schedule | schedule an action to do it intime
>show ?
shows various system parameters
config | running configuration
connections | active connections to server
list | NetUnits list with applied policy list
policy | policy list
processor | processor service status
units | NetUnits list
users | users list
version | software version and current status
schedule | active scheduled actions
Each command is processing by a corresponding service.
Need to be set up first, main service defines NeTAMS system administrator and users. Also debugging level and sheduler tasks are set.|
service: main, runtime: yes user [oid OID] name user_name [real-name user_human_name] [email email_addr] [password pass] [permit permit_state] user and his rights definition oid OID - unique user identificator, generates automatically if omitted name user_name - user login real-name user_human_name - user real name, can be quoted email email_addr - e-mail address password pass - unencrypted user's password cryted cpass - encrypted user's password, encryption will be done automatically permit permit_state - user rights, from none to all no user {oid OID} | {name user_name} delete a user service: main, runtime: yes debug deb_str [deb_str ...] enables debugging of following (space separated) identifiers deb_str - debug type identifier: none - no debug at all command - commands entered and processed parse - commands parse sleep - services synchronization mechanisms server - server service proc_mux - processor service messages multiplexer ds_ip - data-source service, IP packet processing storage - storage service alert - alerter service scheduler - scheduler service netflow - data-source service, netflow packet processing monitor - packet header data for specified units all - all debugging is on no debug deb_str [deb_str ...] disables debugging of following identifiers service: main, runtime: yes schedule [oid OID] time time_period action requested_action set up a schedule on which given command will be executed oid OID - unique task identificator, generates automatically if omitted time time_period - execution time or time interval: {hourly|daily|weekly|monthly}, command will be executed in a first second of a given interval, regardless of actual entering time. For example schedule time weekly action save will automatically save configuration file at the each monday's first second. at-XX:XX, command is scheduled for a given time. For example, schedule time at-22:00 action save If '+' or '-' sign is placed immediately (no spaces!) after a time_period word, this command will be executed in ten seconds after or before actual time_period specified action requested_action - command to be scheduled - any possible with a valid syntax. If it contains several words, you can quote it, if you need to use quotes(") in a command also, use apostrophe('). no schedule oid OID cancel a scheduled task show schedule displays all task currently scheduled |
Other services are configured separately in any order. Each service starts by following:
service XXX N
where N is the service instance number. It should be non-zero short integer value. Theoretically, there are several instance of each service type is possible, although this can be useful for data-source and storage services only. Exceptions are main and processor services, only single instance of them is allowed. Services order is not significant, but it is recommended to use next declaration sequence:
- server
- processor
- storage
- data-source
- alerter
- html
- quotactl
- weblogin
- monitor
|
service: server, runtime: no listen XXXX defines the TCP port number, on which NeTAMS will wait for incoming telnet connections for remote management. XXXX - TCP port number from range (1...65535), 20001 is the default value service: server, runtime: yes max-conn XXXX defines maximum simultaneous connections number. XXXX - connections number, default is 6 service: server, runtime: yes login {any|localhost} defines the possibility to connect to NeTAMS from anywhere or local machine, for security reasons it is better to use localhost. any - conection is allowed from any remote host localhost - connection is allowed only from localhost (127.0.0.1) |
processor service defines NeTAMS kernel objects and accounting functionality
|
service: processor, runtime: yes lookup-delay XXXX defines time interval on which service will check its NetUnit list to age time-outed flows and flush them to database. as small the value, the accounting precision is better, but database load increases (witout storage size increase) XXX - time in seconds, default is 10. service: processor, runtime: yes flow-lifetime XXXX defines flow life time. after the period specified, flows are zeroed and flushed to database. as small the value, the accounting precision is better, but database load increases (and storage size increases) XXX -time in seconds, default is 600. service: processor, runtime: yes policy {acct|fw} [oid OID] name NAME target TARGET defines accounting or filtering policy acct - accounting policy keyword fw - filtering (firewalling) policy keyword oid OID - unique policy identificator, generates automatically if omitted name NAME - policy name (2-8 symbol string) target TARGET - policy rule (packet match target) Let's describe policy targets in more details. Target definitions are hard-coded into NeTAMS binary, there are several variants possible: ip accounts all IP traffic icmp accounts all ICMP protocol traffic tcp accounts all TCP protocol traffic udp accounts all UDP protocol traffic tcp-http TCP traffic with src or dst port numbers=80,808,81,3128,443 tcp-ports {s|d|}num {s|d|}num ... and udp-ports {s|d|}num {s|d|}num ... TCP or UDP with corresponding ports match. ports list are space separated numbers with optional one-letter prefix. if letter is s - match is estimeted when only source port matches, d - matches in destination, no letter - SRC or DST. example: target tcp-ports 25 defines target with all SMTP (mail) traffic, target tcp-ports s80 s81 s8080 - applied to client netunit, policy with that target accounts all incoming web traffic. port list is limited to 10 numbers, port range is not allowed. units oid XXXX all traffic with other speaking side matches NetUnit with OID XXXX file YYYY matches if others side (via IP header) is from prefix file YYYY Prefix file has following structure: A.B.C.D /N where: A.B.C.D - network address, example: 212.67.32.0 N - number of '1' bits in network mask, example 24 (255.255.255.0) There are ru-networks.txt file in NeTAMS distribution, it contains all Russian networks list from RIPE database. See section 6.2 for more details on prefix file accounting. service: processor, runtime: yes restrict all {drop|pass} local {drop|pass} set traffic filtering policy for units with fw-policy unset (like default fw policy) all - for all packets (all IP src/dst pairs) local - for packets destined to units defined in configuration file drop - drop packet pass - pass packet Default value is restrict all drop local pass and leads to packet, with both src or dst address not from current configuration file, be dropped. In reality, NeTAMS will pass only packets to hosts (or other units) defined in config. In case of restrict local drop you must define fw-policy !something for each unit! service: processor, runtime: yes unit {host|group|cluster|net|user} [oid OID] name NAME [parameters] [parent GROUP] [no-local-pass] [email addr] [acct-policy [!]p_name [p_name] ...] [fw-policy [!]p_name [p_name] ...] [ds-list 1,2,3...] defines accounting object (NetUnit), on which accounting will be done. host - host, only one IP address allowed group - group (possibly empty) cluster - host with seleral IP addresses net - subnetwork with network address and mask oid OID - unique unit identificator, generates automatically if omitted name NAME - название объекта в виде строки (2-8 символов) parameters - some netunit specific data: for host: ip A.B.C.D - address of this host for group: none for cluster: ip A.B.C.D [ip A.B.C.E [..]] - addresses list for net: ip A.B.C.D mask E.F.G.H - subnetwork address and mask parent GROUP - name of the parent (to this object) group no-local-pass - with this keyword, an ip packet matched will be not distinguished as 'local', it will be filtered as 'restrict all', not 'restrict local' (good for subnets) (see. 6.3.) email addr - e-mail address of responsible person, effective for unit type of 'user', useful for quotactl and weblogin services sys-XXXX - "system policy", see. 6.8. possible values: sys-allow, acct-policy [!][%]p_name - space separated accounting policy list If you put asterisk sign BEFORE policy name (without a space), for example !all-icmp, then match/no match of this policy will be INVERTED, so in this case all non-icmp traffic will be accounted. Note that you cannot define two policies with same name simultaneously, like policy acct name all-tcp target tcp unit ... acct-policy all-tcp !all-tcp That is because policy numbers are match. Instead, you should use: policy acct name all-tcp target tcp policy acct name i_all-tcp target tcp unit ... acct-policy all-tcp !i_all-tcp If you put percent sign BEFORE policy name (without a space), then on policy match no further policy lookup will be performed, and accounting process will be finished. (see. 6.4.) fw-policy [!][%]p_name - space separated firewalling policy list If you put percent sign BEFORE policy name (without a space), then on policy match no further policy lookup will be performed, and filtering decision will be made immediately. (see. 6.4.) ds-list no,[no,no,…] - allowed data source list number, by default all data-source can use this unit (and modify traffic counters) service: processor, runtime: no storage N {all|raw|summary} defines traffic information storage direction and stored information type for processor service. there are several storages can be used same time N - storage service number, this storage is allowed not to be started yet raw - data will be saved as 'raw', without time period aggregation summary - summary (time period aggregated) data will be saved, starting from current hour, day, week, month and total all - all types will be saved, a combination ow raw + summary |
Сервис storage определяет базу данных или хранилище, где будет сохраняться информация о стастистике по траффику.
|
service: storage, runtime: no type {hash|mysql|postgres} определение типа базы данных hash - UNIX hash (файлы .db) mysql - MySQL (www.mysql.com) postgers - PostgreSQL (www.postgresql.com) работа с другими базами данных не оформлена в виде кода, но при желании может быть легко добавлена service: storage, runtime: no path определяет каталог в системе, где будут создаваться и храниться файлы базы данных при использовании hash в качестве хранилища данных. при использовании MySQL/PostgreSQL не имеет смысла service: storage, runtime: no user username имя пользователя для подключению к MySQL/PostgreSQL. по умолчанию root service: storage, runtime: no password password пароль для подключения к MySQL/PostgreSQL, по умолчанию отсутствует service: storage, runtime: no host hostname имя хоста где установлен MySQL/PostgreSQL |
Сервис data-source служит источником информации о траффике, который считается программой
|
service: data-source, runtime: no type {ip-traffic|netflow|libpcap} задает тип источника данных ip-traffic - данные берутся путем перехвата ip-пакетов из ядра через divert socket (FreeBSD) или netfilter (Linux 2.4.x) netflow - данные о прошедшем траффике приходят от маршрутизатора Cisco, отдающего поток информации в пакетах NetFlow libpcap - данные берутся путем перехвата пакетов с помощью библиотеки libpcap, которая копирует в программу проходящие через ядро системы определенные пакеты. так же работает, например, tcpdump. см. раздел 6.5.с service: data-source, runtime: no source {tee|divert|A.B.C.D XXX|ifname} задает источник данных tee XXX - пакеты будут копироваться в программу и параллельно обрабатываться системой, номер divert-порта XXX, для Линукса не имеет смысла divert XXX - пакеты будут заворачиваться в программу и она может отдать или не отдать их системе обратно, номер divert-порта XXX, для Линукса не имеет смысла A.B.C.D. XXX - поток NetFlow будет идти с хоста с IP-адресом A.B.C.D на локальный UDP-порт XXX ifname - имя локального сетевого интерфейса, на котором будут захватываться проходящие пакеты service: data-source, runtime: yes rule ID rule_string задает системное правило, по которому данные будут попадать в программу ID - номер правила rule_string - правило в виде текстовой строки, которое будет передано системе (Linux или FreeBSD) для установки перехватчика пакетов. См. раздел 6.1. service: data-source, runtime: yes no rule ID отмена правила ID - номер правила |
Сервис alerter занимается рассылкой информации о статистике и о работе системы по почте
|
service: alerter, runtime: yes report [oid 06100] name rep1 type traffic period day detail simple ненастраиваемый в настоящее время параметр отправки сообщений service: alerter, runtime: yes smtp-server smtp_server_name smtp_server_name - имя почтового сервера, через который отправится почта |
Сервис html позволяет автоматически создавать статические HTML-страницы с отчетами о траффике и о работе программы
|
service: html, runtime: yes language { ru | en } выбор языка, на котором пишутся отчеты. пока действует только английский service: html, runtime: yes run time_interval интервал времени, в формате задачи планировщика, в который будет выполняться генерация страниц. по умолчанию time_interval=hourly, т.е. страницы будут создаваться за 10 секунд до начала каждого часа, и содержать статистику о предыдущем часе. service: html, runtime: yes path /path/to/html/root путь дло каталога, в котором будут создаваться файлы. |
Сервис quotactl позволяет устанавливать и проверять квоты по потреблению траффика для указанных юнитов
|
service: quotactl, runtime: yes quota QOUTA_NAME policy POLICY_NAME set SYS_POLICY_NAME {hour SH1 soft-in H1 in SH2 soft-out SH soft-sum H2 out H sum day ... D1 in D2 out В sum week ... W1 in W2 out W sum month ... M1 in M2 out M sum total ... T1 in T2 out T sum } определение квоты с именем QOUTA_NAME policy POLICY_NAME - имя политики, которая будет применяться при подсчете траффика и данной квоты. эта политика должна присутствовать для того юнита, который проверяется данной квотой. set SYS_POLICY_NAME - имя системной политики, которая установится для указанного юнита при превышении квоты. кроме того, при этом будет сделана запись в лог-файле. hour SH1 soft-in H1 in SH2 soft-out H2 out SH soft-sum day ... D1 in D2 out S sum week ... W1 in W2 out month ... M1 in M2 out M sum total ... T1 in T2 out T sum - список обычных и софт-квот для указанных интервалов времени. возможно задавать значения по-отдельности, например "hour 10M in week 20G out". величины траффика можно задавать как в байтах, так и указывая множители килобайтов (К), мегабайтов (M) и гигабайтов (G). service: quotactl, runtime: yes bind quota QUOTA_NAME to {UNIT UNIT ...} привязка квоты QUOTA_NAME к списку конкретных юнитов. UNIT - имя или OID юнита, который будет проверяться на совпадение указанной квоты. service: quotactl, runtime: yes alert soft-reach [<user> | USER_NAME] при превышении софт-квоты отправляет пользователю USER_NAME письмо на его e-mail; если определана константа <user>б то и на адрес e-mail параметров юнита, если юнит имеет тип user. alert hard-reach [<user> | USER_NAME] при превышении квоты отправляет пользователю USER_NAME письмо на его e-mail; если определана константа <user>б то и на адрес e-mail параметров юнита, если юнит имеет тип user. alert reset-back [<user> | USER_NAME] при восстановлении доступа по квоте отправляет пользователю USER_NAME письмо на его e-mail; если определана константа <user>б то и на адрес e-mail параметров юнита, если юнит имеет тип user. lookup-delay seconds интервал времени между актами проверки квот, по умолчанию 53 секунды. КОММЕНТАРИЙ Сервис quotactl проверяет переполнение квот каждые lookup-delay секунды. При превышении квоты для заданного периода для юнита в системной политике выставляется значение, определенное в описании квоты (set SYS_POLICY_NAME). При окончании временного интервала системная политика сбрасывается. Например, указав "quota ...set sys-deny-quota hour in 1M" каждый час данный юнит сможет скачать мегабайт, после чего он блокируется (sys-deny-quota), но при смене часа эта системная политика сбрасывается на sys-allow. О системных политиках см. также раздел 6.8. Можно определить так называемые софт-квоты, когда при превышении такой квоты будет отправлено сообщение по почте, но отключения не произойдет. Например, можно написать: "quota ... day 30M soft-in 40M in month 1G soft-in 1.2G in". Квоты должны работать для всех типов юнитов, но чтобы иметь возможность отправлять пользователю письмо и не создавать для каждого хоста соответствующего пользователя, рекомендуется использовать тип unit user. Фактически, это тот же тип unit host, но с дополнительными параметрами email и real_name. Чтобы настроить отсылку уведомлений о наступлании софт-квоты и отменене квоты обратно для данного пользователя, и при переполнении квоты пользоватею и администратору, напишите: alert soft-reachСм. также пример конфигурационного файла: netams-quotactl.cfg service: quotactl, runtime: yes show quota [name XXX [oid YYY]] текущее состояние проверки квот. см. 5.4.14. |
Сервис weblogin позволяет осуществлять открытие доступа к заданному юниту и установление тайм-аута на его работу. Для реализации этого механизма используется скрипт веб-интерфейса, который и запускает соответствующие команды на открытие. Тайм-аут бывает двух типов: абсолютный, когда независимо от активности данного юнита после его открытия время работы четко фиксировано, или тайм-аут неактивности, когда блокировка юнита происходит после того, как в течение заданного времени траффик от/к этому юниту был нулевым.
|
service: weblogin, runtime: yes user USER_NAME { time TIME_STRING | inact TIME_STRING } [set SYS_POLICY_NAME] [multi] open UNIT_NAME [UNIT_NAME] ... - определение пользователя, таймаутов и списка юнитов user USER_NAME - имя пользователя, логин и пароль которого будет проверяться при авторизации на открытие юнита. такой пользователь должен уже быть определен в программе глоюальной командой user. time TIME_STRING inact TIME_STRING - определение временного интервала, после которого будет произведена блокировка юнита. формат строки TIME_STRING такой же, как при описании задачи планировщика schedule, например 5min или 2hour. ключевое слово time задает абсолютный таймаут, слово inact - таймаут неактивности. set SYS_POLICY_NAME - имя системной политики, которая установится для указанного юнита при наступлании таймаута. по умолчанию имя - sys-deny-auth. кроме того, при этом будет сделана запись в лог-файле. multi - ключевое слово, которое показывает что данный пользователь имеет право открыть не один, а сразу несколько юнитов open UNIT_NAME - задает список юнитов, которые может открыть указанный пользователь, и к которым применятся определенные здесь же величины таймаутов. service: main, weblogin, runtime: yes auth user USER_NAME password PASSWORD [from A.B.C.D [open UNIT_NAME]] - процесс аутентификации клиента и открытия соответствующего юнита. user USER_NAME - имя пользователя password PASSWORD - его пароль from A.B.C.D - IP-адрес, с которого работает пользователь. подставляется сюда скриптом веб-интерфейса. open UNIT_NAME - имя юнита, который надо открыть service: weblogin, runtime: yes show timeout - текущее значение активных счетчиков timeout. см. 5.4.15. Более подробно о применении веб-логинов см. 6.10. |
Сервис monitor позволяет осуществлять запись данных из заголовков пакетов, относящихся к указанным units.
|
service: monitor, runtime: yes monitor to {storage N | file XXXX} задает направление вывода информации и мониторинге. мониторинг позволяет собирать в текстовом файле или базе данных информацию о каждом IP-пакете или NetFlow-записи, обработанной NeTAMS. эту детальную информацию можно затем обработать для составления специфических отчетов. storage N - идентификатор хранилища, куда пойдет запись. должен иметь тип SQL file XXXX - имя (путь) до текстового файла с выводом мониторинга, относительно каталога лог-файла. service: monitor, runtime: yes monitor unit {N | XXXX} определяет юнит, который необходимо мониторить. N - идентификатор (OID) юнита XXXX - имя юнита no monitor unit {N | XXXX} отменяет мониторинг указанного юнита no monitor to отменяет мониторинг совсем show monitor отображает текущее состояние мониторинга см. также замечания в разделе 6.6. относительно применения мониторинга |
Набор команд show служит для извлечения информации о работе программы, списке политик, юнита и наконец - собственно о статистике про траффику.
Набор команд rotate служит для осуществления ротации лог файлов и логов сервиса monitor.
|
service: none, runtime: yes rotate log перемещает лог-файл в файл с расширением, указывающим на время ротации: "%Y-%m-%d_%H:%M" и открывает новый. rotate monitor N для сервиса monitor:N, в случае если используется monitor to file, перемещает файл мониторинга в новый с расширением, указывающем на время ротации: "%Y-%m-%d_%H:%M" и открывает новый. |
6. Типичные конфигурации и тонкая настройка
-
Несколько слов о задании правил заворачивания траффика для data-source
В случае использование FreeBSD правила должны выглядеть следующим образом:
Случай использования "честных" адресов
rule number "ip from any to any via ifname"
где number - относительно любой номер правила в таблице ipfw, например 100
ifname - название внешнего интерфейса, через который траффик идет к провайдеру
Случай использования "левых" адресов и их трансляции
rule number1 "ip from any to any via ifname"
rule number2 "ip from any to any via ifname"
где number1 и number2 - номера правил в таблице ipfw, так чтобы ваше правило по трансляции адресов (заворот пакетов в divert socket NATD) имело номер МЕЖДУ НИМИ.
ifname - название внешнего интерфейса, через который траффик идет к провайдеру
Это сделано для того, чтобы учитывать траффик на неоттранслированные адреса.
В случае Linux, независимо от наличия трансляции адресов (маскарадинга), правила имеют вид:
rule number1 "INPUT -p all -j QUEUE"
rule number2 "FORWARD -p all -j QUEUE"
rule number3 "OUTPUT -p all -j QUEUE"
причем номера number1, 2 и 3 совершенно произвольные так как никак не используются.
Этими действиями выполняется следующее: вы задаете правила для ipfw/iptables, по которым пакеты ядром направляются пихаются в некую виртуальную трубу (которая называется queue), откуда их потом берет программа, прокачивает через себя (смотря на заголовки и делая подсчет) и отдает обратно в систему, после чего они спокойно идут себе дальше.
ВАЖНО!!!
Если вы остановили программу так что она не смогла после себя убрать эти поставленные правила (через kill -9) или она сама неожиданно померла, то все пакеты по прежнему система будет заворачивать туда откуда их никто не заберет, и они пропадут. С точки зрения системы это будет выглядеть как полная потеря работы с сетью. НИКОГДА не экспериментируйте с этим сидя за удаленной машиной. Тренируйтесь непосредственно за консолью, или в крайнем случае на icmp-траффике. Исключение - FreeBSD с source tee или любая система с NetFlow.
-
Разделение российского и зарубежного траффика на базе файла префиксов
Для начала необходимо пояснить суть проблемы и рассказать, зачем такой учет вообще необходим.
Зачастую бывает, что ваш провайдер выставляет вам счет за пользование интернетом, состоящий из двух цифр: стоимость российского траффика и стоимость зарубежного, т.е. результат обмена информацией с зарубежными серверами. Дело в том, что сам провайдер каким-либо образом покупает траффик у более крупных, магистральных провайдеров которые не связываются с мелкими клиентами. При этом, обмен данными с российскими серверами ведется по одним каналам связи, а для общения с зарубежными серверами используются немногочисленный зарубежные каналы. Надо сказать, что суммарная полоса пропускания данных всех российских провайдеров "за рубеж" составляет всего несколько сот мегабит на всю страну, и таких каналов не так и много (десяток, наверное). Естественно, аренда этих каналов стоит существенно дороже по сравнению с внутрироссийскими и внутримосковскими каналами. Представьте на секунду, сколько стоит проложить трансатлантический подводный оптоволоконный кабель на несколько тысяч километров? Это вам не витую пару через этаж кинуть! :) Вот почему зарубежный траффик стоит дороже российского. Вообще, процентов 80 российского траффика прокачивается через АТС номер 9, что на ул.Губкина, в Москве.
Теперь надо определить, как отличить "российский" и "зарубежный" траффик, и как это делает ваш провайдер. Все основано на глобальной маршрутизации в Интернете, которая осуществляется по протоколу BGP. Грубо говоря, все сети, подключенные к интернету, принадлежат некоей Автономной Системе (AS), которая представляет собой набор IP-сетей (адресных пространств), находящихся под единым управлением. Владелец и руководитель автономной системы определяет политику маршрутизации своих подсетей через своих соседей-провайдеров или крупных организаций, имеющих свои автономные системы. Все такие системы соединены логическими связями друг с другом так, что любая машина в интернете может быть связана с любой другой машиной посредством нескольких (3-7) автономных систем, каждая из которых образована несколькими маршрутизируемыми сетями. Более того, протокол позволяет выбирать оптимальный путь пользуясь большим количеством передаваемой между автономными системами вспомогательной информации, и т.д. Возвращаясь к нашему случаю, ваш провайдер определил маршрутизацию российского траффика (т.е. сетей, принадлежащих российским AS, их список известен) через один канал, а всего остального - через другой, и за другие деньги. Соответственно, и со своих клиентов взимается разная плата.
Теперь, если вы хотите у себя учитывать разделение траффика так, как это делает у себя ваш провайдер, вам по-хорошему надо бы поднять у себя маршрутизатор (Cisco, FreeBSD/Zebra,...), поднять на нем сессию iBGP с провайдером, получать от него таблицу роутинга (она часто меняется) и импортировать ее в вашу программу учета траффика. Это реально, но тяжело, в NeTAMS такая функциональность будет встроена только в случае существенного спонсирования проекта. Вместе с тем, существует возможность пользоваться менее точной, но более короткой базой ru-networks.txt, построенной на основании таблицы выделенных организациям блоков IP-адресов, которую у себя поддерживает RIPE. В настоящий момент она содержит в себе список около 400 сетей, которые можно назвать "Российскими". Никто не гарантирует, что ваш провайдер будет получать траффик от некоторых таких сетей не через зарубежные каналы, однако я надеюсь, что точность такого разделения будет вполне приемлемой. Если вы сможете предоставить мне ваши статистические данные - я буду рад.
Некоторые разъяснения о том, что же на самом деле считается
+ означает выполнение действия.Unit
MATCH_NONEUnit
MATCH_SRCUnit
MATCH_DSTUnit
MATCH_BOTHPrefix
MATCH_NONE- - - - Prefix
MATCH_SRC- - + + Prefix
MATCH_DST- + - + Prefix
MATCH_BOTH- + + +
Например:
для fw-policy + означает блокировку пакета, а для acct-policy - подсчет данного пакета.
Чтобы подсчитать RU траффик необходимо прописать:
policy acct oid 146EFF name russian target file /usr/home/anton/netams/ru-networks.txt
unit host oid 022EB1 name myhost ip 192.168.1.10 acct-policy russian
ВНИМАНИЕ!!! C версии 1516 изменилась логика работы с политикой префиксов.
-
Зачем нужно no-local-pass
Этот параметр при конфигурировании юнита был сделан для того, чтобы предотвратить ненужную маркировку пакета как "локального", если по замыслу он таковым не является. Рассмотрим случай, когда у вас есть некая локальная сеть с непрерывным диапазоном адресов, но вы хотите разрешить пользоваться сервером только тем компьютерам сети, которые определены в конфигурационном файле. При этом хочется считать траффик для всей подсети вцелом. Вот типичная конфигурация:
service processor
policy fw name all-ip target ip
restrict all drop local pass
unit net name LAN ip 192.168.1.0 mask 255.255.255.0 acct-policy all-ip
unit host name USER1 ip 192.168.1.10
unit host name USER2 ip 192.168.1.12
unit host name USER3 ip 192.168.1.13
В таком случае, машина из локальной сети с адресом 192.168.1.20 сможет пройти наружу, так как она попадает в сеть LAN (unit net name LAN) и пакеты маркируются локальными (restrict local pass). Вы можете избежать этого, создав группу и пометив все указанные компьютеры из этой подсети как принадлежащие группе, однако есть более красивое решение:
unit net name LAN ip 192.168.1.0 mask 255.255.255.0 no-local-pass acct-policy all-ip
-
Зачем нужен break flag [%] при описании fw-policy:
Если вы задаете последовательность из нескольких политик фильтрации траффика подряд, то по умолчанию их действие суммируется, т.е. в случае
service processor
policy fw name all-ip target ip
policy fw name tcp target tcp
unit host name HOST1 ip 192.168.1.5 fw-policy !tcp all-ip
вы все равно не сможете открыть для этой машины ТОЛЬКО TCP-траффик, на следующем совпавшем правиле all-ip пакет зарежется. Для того чтобы после совпадения политики дальнейший поиск прекратился, поставьте
unit host name HOST1 ip 192.168.1.5 fw-policy !%tcp all-ip
Зачем нужен break flag [%] при описании acct-policy:
Если вы задаете последовательность из нескольких политик подсчета траффика подряд, то по умолчанию подсчет ведется для каждой политики, т.е. в случае
service processor
policy fw name ip target ip
policy fw name tcp target tcp
policy fw name tcp target udp
unit host name HOST1 ip 192.168.1.5 acct-policy tcp udp ip
вы все равно не сможете явно посчитать для этой машины весь не udp и не tcp траффик, так как пакет все равно посчитается по политике ip. Чтобы при совпадении политики дальнейший подсчет прекратился, поставьте
unit host name HOST1 ip 192.168.1.5 acct-policy %tcp %udp ip
-
Примеры использования и настройки в различных окружениях
А) Анализ и учет проходящего через UNIX-роутер траффика
Наверное, это наиболее часто использующийся способ. Он основан на том, что проходящие через ваш UNIX-маршрутизатор пакеты проходят по цепочке правил ipfw/iptables, в которой можно поставить специальное правило, перенаправляющее пакеты внутрь программы. Если NeTAMS их выпускает обратно, то процесс обработки пакетов ядром продолжается. На базе этого и можно фильтровать траффик по заданным критериям. Настройка проста: вы должны подготовить систему к работе с "заворачиванием" пакетов (см. выше), и настроить соответствующий сервис data-source:
service data-source 1
type ip-traffic
source divert 199
rule 100 "ip from any to any via fxp0"
После этого ваш вывод ipfw list (FreeBSD) будет содержать строку
100 divert 199 ip from any to any via fxp0
Помните, что при некорректном завершении программы (через kill -9 или из-за внутренней ошибки) правило остается висеть в системе, что блокирует доступ к машине по сети.
В) Анализ и учет потока NetFlow от маршрутизатора Cisco Systems
Маршрутизаторы производства Cisco Systems, в современных версиях операционной системы IOS, поддерживают новый метод управления маршрутизацией пакетов, называемый NetFlow. Помимо всего прочего, это дает возможность собирать информацию о статистике и передавать ее внешнему устройству для обсчета. Более подробная информация о NetFlow содержится тут. Маршрутизатор посылает UDP-пакеты со статистикой на некий IP-адрес/порт, где NeTAMS может собрать информацию и обработать ее. Фильтрация траффика в таком случае невозможна, так как пересылку данных осуществляет внешнее устройство. О конкретной настройке netflow export можно почитать тут. Приведем пример команд маршрутизатора:
ip flow-cache timeout inactive 60
ip flow-cache timeout active 10
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip route-cache flow
!
ip flow-export version 5
ip flow-export destination 192.168.1.254 20001
Обработчик data-source настраивается следующим образом:
service data-source 1
type netflow
source 192.168.1.1 20001
Предполагается, что UDP-пакеты NetFlow идут с маршрутизатора, имеющего IP-адрес 192.168.1.1, и поступают на локальный UDP-порт номер 20001 (его и слушает NeTAMS)
ВАЖНО!
По определению, NetFlow учитывает только входящий на роутер траффик. Это вызывает проблемы учета при использовании трансляции адресов. Действительно, пакеты от машин внутренней сети приходят на роутер и учитываются верно, но обратные ответы извне поступают с адресом dst внешнего интерфейса. Поскольку трансляция адресов происходит после учета, то статистика всего входящего траффика будет содержать сумму всего траффика, пришедшего на адрес внешнего интерфейса, и нули для адресов внутренней локальной сети. Для корректного учета, вам необходимо использовать policy routing. Установленная на роутере операционная система должна поддерживать эту функцию. Вот пример конфигурации для Cisco 2514:
interface Loopback0
ip address 192.168.10.1 255.255.255.0
ip route-cache policy
ip route-cache flow
!
interface Ethernet0
ip address 195.200.200.1 255.255.255.0
ip nat outside
ip route-cache policy
ip route-cache flow
ip policy route-map MAP
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip route-cache policy
ip route-cache flow
!
ip nat inside source list 1 interface Ethernet0 overload
ip classless
ip flow-export version 5
ip flow-export destination 192.168.1.254 20001
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 101 permit ip any 192.168.1.0 0.0.0.255
route-map MAP permit 10
match ip address 101
set interface Loopback0
ВАЖНО!
На практике возник один тяжелый случай, который хотелось бы разобрать.
Дана конфигурация, в которой два маршрутизатора Cisco, находящиеся по разные стороны Serial канала, должны присылать свою статистику NetFlow на юникс-сервер с работающей программой NeTAMS, который находится в ethernet-сегменте одного из маршратизаторов. Первоначально конфигурационные файлы были таковыми:
Это приводило к появлению в лог-файле множественных сообщений вида:NETAMS: netams.cfg (фрагмент) CISCO: running-config (фрагмент) service data-source 1 type netflow source 212.xxx.xxx.1 20001 service data-source 2 type netflow source 212.xxx.xxx.2 20001
interface Loopback0 ip address 212.xxx.xxx.1 255.255.255.252 ip flow-export source Loopback0 ip flow-export version 5 ip flow-export destination 212.xxx.xxx.59 20001
interface Loopback0 ip address 212.xxx.xxx.2 255.255.255.252 ip flow-export source Loopback0 ip flow-export version 5 ip flow-export destination 212.xxx.xxx.59 20001
13.06.2002 15:12:05.1944 data-source-4: NF awaited seq 7791483 mismatch received 52066956 (44275473 flows are lost)
13.06.2002 15:12:05.6004 data-source-4: NF awaited seq 52067106 mismatch received 7791483 (-44275623 flows are lost)
13.06.2002 15:12:06.1998 data-source-4: NF awaited seq 7791543 mismatch received 52067136 (44275593 flows are lost)
13.06.2002 15:12:06.2013 data-source-4: NF awaited seq 52067166 mismatch received 52067106 (-60 flows are lost)
13.06.2002 15:12:06.2073 data-source-4: NF awaited seq 52067136 mismatch received 52067166 (30 flows are lost)
13.06.2002 15:12:06.2085 data-source-4: NF awaited seq 52067196 mismatch received 52067226 (30 flows are lost)
13.06.2002 15:12:06.2144 data-source-4: NF awaited seq 52067256 mismatch received 52067196 (-60 flows are lost)
13.06.2002 15:12:06.6014 data-source-4: NF awaited seq 52067226 mismatch received 7791543 (-44275683 flows are lost)
Причина явления в том, что каждый из маршрутизаторов шлет в пакетах netflow порядковый номер записи. Поскольку сервис data-source один, то он не может распознать от какого из маршрутизаторов пришли данные, и ругается. Необходимо было добавить еще один сервис и изменить конфигурационные файлы:
Фактически, каждый роутер присылает поток netflow своему собственному сервису, каждый из которых слушает на своем UDP-порту. Однако проблему это не решило:NETAMS: netams.cfg (фрагмент) CISCO: running-config (фрагмент) service data-source 1 type netflow source 212.xxx.xxx.1 20001 service data-source 2 type netflow source 212.xxx.xxx.2 20002
interface Loopback0 ip address 212.xxx.xxx.1 255.255.255.252 ip flow-export source Loopback0 ip flow-export version 5 ip flow-export destination 212.xxx.xxx.59 20001
interface Loopback0 ip address 212.xxx.xxx.2 255.255.255.252 ip flow-export source Loopback0 ip flow-export version 5 ip flow-export destination 212.xxx.xxx.59 20002
18.06.2002 14:00:57.6291 data-source-4: NF:2 awaited seq 86683836 mismatch received 86683776 (-60 flows are lost)
18.06.2002 14:00:57.6319 data-source-4: NF:2 awaited seq 86683806 mismatch received 86683866 (60 flows are lost)
18.06.2002 14:00:57.6352 data-source-4: NF:2 awaited seq 86683896 mismatch received 86683836 (-60 flows are lost)
18.06.2002 14:00:58.5939 data-source-4: NF:2 awaited seq 86683866 mismatch received 14644284 (-72039582 flows are lost)
18.06.2002 14:00:58.6269 data-source-4: NF:2 awaited seq 14644314 mismatch received 86683896 (72039582 flows are lost)
18.06.2002 14:00:59.5948 data-source-4: NF:2 awaited seq 86684016 mismatch received 14644314 (-72039702 flows are lost)
Видно, что ошибку создает поток, приходящий на сервис data-source:2 с удаленной части сети. При этом четко выражены две особенности: небольшой сбой в последовательности, и большой сбой.
Первый факт, как оказалось, связан с тем что последовательность UDP-пакетов, приходящих в программу, меняется из-за низкой скорости канала и работы средств обработки очередей пакетов на выходе из удаленного маршрутизатора. На этот факт можно не обращать внимания.
Более детальный анализ приходящих пакетов выявил следующую особенность:
21.06.2002 13:22:32.2210 data-source-4: NF:2 awaited seq 108867336, received 108867366 from 00 (30 flows are lost)
21.06.2002 13:22:32.2253 data-source-4: NF:2 awaited seq 108867396, received 108867336 from 00 (-60 flows are lost)
21.06.2002 13:22:32.2268 data-source-4: NF:2 awaited seq 108867366, received 108867396 from 00 (30 flows are lost)
21.06.2002 13:22:32.8192 data-source-4: NF:2 awaited seq 108867426, received 19232583 from 02 (-89634843 flows are lost)
21.06.2002 13:22:33.2718 data-source-4: NF:2 awaited seq 19232613, received 108867426 from 00 (89634813 flows are lost)
21.06.2002 13:22:33.8377 data-source-4: NF:2 awaited seq 108867576, received 19232643 from 02 (-89634933 flows are lost)
21.06.2002 13:22:33.8394 data-source-4: NF:2 awaited seq 19232673, received 19232613 from 02 (-60 flows are lost)
21.06.2002 13:22:34.2750 data-source-4: NF:2 awaited seq 19232643, received 108867576 from 00 (89634933 flows are lost)
21.06.2002 13:22:35.2897 data-source-4: NF:2 awaited seq 108867816, received 108867846 from 00 (30 flows are lost)
Указанные номера (from 00 и 02)- это не что иное как engine_id, т.е. номер выполняющей процесс экспорта NetFlow железки в пределах одного роутера. Разбирательство показало, что на удаленной стороне установлен маршрутизатор Cisco 7505, который наряду с Cisco 12000 характеризуется т.н. распределенной архитектурой. Процесс свитчинга (пересылки) пакетов в нем выполняют интерфейсные процессоры независимо друг от друга (dCEF), и отсылают потоки о траффике через NetFlow тоже независимо. Естественно, номера последовательностей будут разными.
После выяснения данных обстоятельств было решено, что в конечном итоге, несмотря на неправильную последовательность прихода данных, суммарная информация о статистике собирается верно, и следует просто отключить вывод предупреждающей информации комментированием соответствующей строки в файле ds_netflow.c и пересборкой программы.
С) Анализ и учет проходящего мимо/через интерфейс траффика
NeTAMS может использоваться как программа, собирающая проходящий "мимо" траффик, пользуясь библиотекой libpcap. Через эту библиотеку работают многие программы, например tcpdump. Она позволяет "перехватывать" в пользовательскую программу проходящие через сетевой интерфейс пакеты, при этом передается также link level заголовок, т.е. все содержимое ethernet-кадра. Как вы понимаете, фильтрация траффика в этом случае исключается, так как не NeTAMS принимает решение о пропуске или блокировке IP-пакета, а другое устройство. Такое решение может быть полезным, если маршрутизацию осуществляет другое устройство, не поддерживающее само по себе выдачу статистики, например программный маршрутизатор на основе Windows. Вы должны каким-либо образом перенаправить весь поток данных, проходящих по сети, на сетевой интерфейс, на котором работает service data-source типа libpcap. Для этого вы можете использовать хаб (концентратор), который копирует все пакеты между портами без разбора. Правда, в этом случае производительности сети будет сильно ограничена суммарной производительностью хаба (10 мегабит), в такой сети будет плохо с распределением нагрузки и безопасностью. Гораздо более приемлемым решением может стать применение на опорном узле сети коммутатора (свитча) производства Cisco, с использованием технологии мониторинга портов и виртуальных сетей (SPAN). Фактически, это позволяет копировать весь траффик между портами или внутри одного VLAN'а в некий ethernet-порт, к которому подключена сетевая плата сервера NeTAMS. Учтите, что этот порт работает только на запись, т.е. вы не сможете управлять сервером через него.
Для начала, рекомендую прочитать обзор технологии Cisco Catalyst Switched Port Analyzer (SPAN). Для ее настройки применительно к конкретным коммутаторам, обращайтесь: серия Catalyst 2900xl и 3500xl, серия Catalyst 2950 и 3550, серия Catalyst 6000. Для настройки NeTAMS необходимо определить сервис data-source (в этом примере захват пакетов действует аналогично команде tcpdump -i fxp1 net 192.168):
service data-source 1
type libpcap
source fxp1 # interface name
rule 1 "net 192.168"
ВАЖНО!
При использовании данного метода захвата траффика (data-source libpcap) вы можете встретиться с двумя побочными явлениями:
1. Из-за встроенной в libpcap буферизации пакеты могут приходить в программу не сразу, а через некоторое время, по мере наполнения буфера. Иногда задержка может составлять несколько секунд, а количество пакетов в буфере - несколько сотен. Причина такого плохого поведения мне не известна.
2. В данный момент поддерживается только первое правило в списке rule для этого data-source; это ограничение библиотеки.
-
Применение мониторинга траффика
Начиная с версии 1120.5 NeTAMS поддерживает мониторинг заданных юнитов для сбора информации по относящемуся к ним траффику. и начиная с версии 1490 мониторинг реализован как сервис.
Для включения этой функции необходимо задать сервис monitor и направление вывода статистики. Она может сохраняться как в текстовом файле, так и в базе данных, определенной одним из сервисов storage. Для включения мониторинга необходимо задать команду
service monitor NN monitor to file /path/to/output/file
или
monitor to storage N, где N - номер соответствующего сервиса storage
После этого задайте список юнитов, траффик которых вы хотите записывать. Можно указывать как имя юнита, так и его номер (OID), каждый юнит определяется отдельной командой на своей строке. Например:
monitor unit server_1
monitor unit net_real
monitor unit 02ffad
В результате мониторинга с выводом в текстовый файл создаются записи вида:29.04.2002 22:27:27.4898 user_1 041BEF 06 s:172.16.0.1:2174 d:172.16.13.1:23 60 29.04.2002 22:27:30.4800 user_1 041BEF 06 s:172.16.0.1:2174 d:172.16.13.1:23 60 30.04.2002 10:37:55.9553 user_1 041BEF 01 s:172.16.13.2 d:172.16.0.1 84 30.04.2002 10:39:43.4137 user_1 041BEF 17 s:172.16.13.2:1031 d:212.69.119.4:53 59 30.04.2002 10:39:43.4146 user_1 041BEF 17 s:212.69.119.4:53 d:172.16.13.2:1031 145 30.04.2002 10:39:43.4424 user_1 041BEF 06 s:172.16.13.2:1032 d:213.180.194.129:80 48 30.04.2002 10:39:43.4512 user_1 041BEF 06 s:213.180.194.129:80 d:172.16.13.2:1032 44
Первое - второе поля: дата и время, после точки - доли секунды
Третье - четвертое поля: имя юнита и его OID
Пятое поле - номер протокола (01-icmp, 06 - tcp, 17 - udp)
Шестое - седьмое поля: IP-адрес и номер порта src и dst полей пакета
Восьмое поле: длина пакета в байтах
Вы можете использовать NeTAMS как сборщик детальной информации о траффике или записей NetFlow, применив упрощенную для этого случая конфигурацию:
# configuration file example 3 begin debug none user name admin real-name Admin email root@localhost password 123 permit all service server 0 login any listen 20001 max-conn 6 service processor 0 lookup-delay 20 flow-lifetime 120 policy acct name ip target ip unit net name u_all ip 0.0.0.0 mask 0.0.0.0 acct-policy ip service data-source 1 type netflow source 192.168.0.254 20001 service monitor 1 monitor to file /var/netflow.log monitor unit u_all # configuration file example 3 end
Вы также можете записывать данные о проходящем траффике в SQL-базу. Для этого вы должны указать направление вывода мониторига командой monitor to storage N. Если вы уже используете NeTAMS к моменту реализации этой функции (версия программы 3.1(1142), 31 мая 2002г.), то вам необходимо будет вручную создать таблицу monitor в вашем MySQL-сервере:unix_router# mysql netams mysql> CREATE TABLE monitor ( time TIMESTAMP NOT NULL KEY, # время прохождения пакета, в формате unix timestamp, секунды с начала 1970 года msec INT UNSIGNED, # то же для миллисекунд, первые 4 значащие цифры name VARCHAR(32), # имя юнита oid INT UNSIGNED, # OID юнита proto TINYINT UNSIGNED, # IP-протокол пакета, от 0 до 255 (1:icmp, 6:tcp, 14:udp), /etc/protocols src INT UNSIGNED NOT NULL, # IP-адрес источника пакета, в формате long int. для перевода в человеческий формат # с точками используйте функцию MySQL INET_NTOA() srcport SMALLINT UNSIGNED, # локальный порт источника пакета, /etc/services , для ICMP не имеет смысла dst INT UNSIGNED NOT NULL, # IP-адрес получателя пакета dstport SMALLINT UNSIGNED, # локальный порт получателя пакета, len SMALLINT UNSIGNED # длина пакета в байтах );
-
OID, автоматическая генерация и перезагрузки
Ко мне поступил такой вопрос:
Хотел узнать по поводу БД, в таблице хранится oid пользователя, будет ли он после reboot сервера другим? Если да, то как мне присвоить oid пользователям, в смысле номер случайный или есть какая-то система?
А вот и ответ:
При создании конфига вручную oid можно не указывать. При этом значение oid генерируется автоматически, так что если после старта набрать show config, значения oid там уже будут. Естественно, в базу пишутся записи именно с этими oid. Чтобы после рестарта программы oid остались теми же, необходимо после редактирования конфига или любых изменений в нем через интерфейс программы набирать save, тогда конфигурационный файл перезапишется на тот, что выполняется в данный момент, вместе со значениями oid, и после рестарта статистика продолжит собираться и суммироваться правильно.
-
Системные политики
Для обеспечения работы внутренних сервисов программы, таких как квоты, контроль MAC-адресов, веб-логина и т.д. начиная с версии 3.1(1182.281) был реализован механизм так называемых "системных политик". Их действие фактически эквивалентно установке fw-policy для указанного юнита, при этом если системная политика установлена, то происходит полное блокирование траффика невзирая на остальные установленные значения fw-policy (как будто применена политика all-ip и установлен break flag). Собственно само значение (название) системной политики роли не играет, оно лишь помогает администратору понять, по какой причине программа установила данную политику. Исключения составляют политики sys-allow и sys-allow-auth.
Возможны системные политики вида sys-XXX и sys-XXX-YYY. При этом значение XXX определяет действие и может быть:- allow - данная политика пропускает траффик. при этом YYY или отсутствует, или принимает значение auth
- deny - данная политика блокирует траффик
- local - данная политика пропускает траффик, только если данный юнит общается с любым другим юнитом из конфигурационного файла
- NNNNNN - данная политика пропускает траффик, только если данный юнит общается с юнитом, имеющим OID=NNNNNN (например это локальная группа, или юнит, соответствующий локальному вебсерверу)
- (отсутствие) - причина блокировки не указана
- money - кончились деньги на счету клиента
- quota - превышена квота
- macviol - юнит нарушил предписания систему контроля MAC-адресов
- auth - юнит требует процесса внешней аутентификации (логина)
Надо отметить, что в настоящий момент используются только sys-allow (что соответствует отсутствию системной политики вообще, по умолчанию) и sys-deny-quota
Пример использования: контроль квот. Предположим, что юнит HOST1 имеет право скачивать не более 10 мегабайт в день, и не более 100 мегабайт за месяц. При превышении лимита хост может работать только с локальным сервером. Для этого вам надо установить сервис quotactl:
... service processor policy acct name all-ip target ip unit host name SRV oid 0246E8 ip 192.168.0.1 unit host name HOST1 oid 0246EF ip 192.168.0.100 acct-policy all-ip ... service quotactl 1 quota QU1 policy all-ip set sys-0246E8-quota day 10M in month 100M in bind quota QU1 to HOST1 ...
Когда квота для этого хоста превысится, вывод команды show config покажет:
unit host name HOST1 oid 0246EF sys-0246E8-quota ip 192.168.0.100 acct-policy all-ip
При сохранении конфига, равно как и без сохранения, и перезапуске NeTAMS, даже если изначально системная политика для квот будет установлена неверно, при очередном просмотре своих таблиц сервисом quotactl правильное значение системной политики будет восстановлено.
-
API для работы с NeTAMS через Perl-скрипты и CGI-вебинтерфейс
NeTAMS представляет собой достаточно гибкий инструмент учета траффика и установки некоторых органичений на работу пользователей. Круг задач, которые можно решить с использованием данной программы, чрезвычайно широк, и у каждого администратора есть свои пожелания по организации работы программы и тому, как она взаимодействует с пользователями. Для облегчения задачи настройки и использования NeTAMS под ваши конкретные задачи был создан интерфейс в виде ряда функций, который позволяет управлять программой и получать от нее данные из ваших написанных самостоятельно Perl-скриптов и CGI-программ.
Для применения интерфейса вы должны включить в начало вашей программы строку:
require "netams_api.pl"
Вот список функций, которые определены в этом интерфейсе:- $result=netams_login($hostname, $port, $username, $password); -
осуществляет соединение с программой, используя указанные параметры. Если $result начинается со слов "Welcome", то соединение прошло успешно
- netams_send($command); - отправляет команду $command на исполнение
- $result=netams_read(); - считывает в переменную $result результат выполнения команды
- $result=netams_readline(); - то же самое, но программа ожидает вывода признака конца строки (перевод строки, "\n"). использовать не рекомендуется
- netams_logout(); - осуществляет разрыв соединения.
netams_example.cgi - выводит результат выполнения команды show version в виде cgi-программы. после небольшой модификации превращается в утилиту командной строки.
weblogin.cgi - интерфейс к сервису weblogin. рассмотрен в разделе 6.10
netams_graph.cgi - программа, динамически создающая картинки в формате PNG с графическим отображением статистики для заданного юнита и всех его политик учета, за последние неделю или месяц. параметры вызова (метод GET):
unit=UNIT_NAME - обязательный параметр, определяет имя юнита, для которго будет рисоваться картинка
policy=POLICY_NAME - имя политики, которая будет отображаться. при отсутствии параметра policy будут отрисованы все активные политики.
prefix=PREFIX - буква, определяющая временной период графика, W (неделя) или M (месяц) соответственно, по умолчанию =W
nolegend=FLAG - при любом установленном значении запрещает отрисовку легенды с отображением цвета, которым будет отрисовываться данные о политике.
Данный скрипт использует модули GD.pm и библиотеку libgd. Для FreeBSD вам надо выполнить что-то вроде cd /usr/ports/graphics/p5-GD ; make install. В текущем каталоге необходимо иметь файл lucon.ttf, это TrueType-шрифт Lucida Console из дистрибутива WindowsXP, который включен в дистрибутив NeTAMS: без него не будет надписей на картинке.
- $result=netams_login($hostname, $port, $username, $password); -
осуществляет соединение с программой, используя указанные параметры. Если $result начинается со слов "Welcome", то соединение прошло успешно
-
Применение сервиса веб-логинов
Это сервис был разработан для того, чтобы дать возможность клиентам в локальной сети открывать доступ к своим машинам извне/доступ за пределы сети на базе процедуры "логина" в некую систему через веб-интерфейс. Это сделано для предотвращения несанкционированного доступа, более точного учета работы пользователей в сети и разграничении полномочий. Надо отметить, что данная реализация является только пробной и наверняка не учитывает ваших конкретных потребностей. Если вам необходима какая-то другая (но близкая) функциональность от данного сервиса, обращайтесь к разработчику (т.е. ко мне :))
Как настроить этот сервис? Пусть, для примера, в вашей подсети есть пять компьютеров и пять пользователей. Необходимо обеспечить доступ следующим образом:- Пользователи user1, user2, user3, user4 и user5 могут работать только с хостов host1, host2, host3, host4 и host5 соответственно
- Пользователь user1 имеет право при помощи своего логина и пароля открывать доступ (сидя за любым активным хостом) для любого другого хоста
- Для пользователя user1 установлен тайм-аут неактивной работы в 10 минут (если за 10 минут хост не проявил активности, он отключается)
- Для остальных пользователей установлен таймаут в 4 часа (по истечении этого времени процедуру логина надо проходить заново)
- При всех условиях пользователи всегда имеют доступ к серверу server, на которов установлен NeTAMS и веб-сервер
user oid 01643C name web password WebLoginPWD permit sysaction user name user1 password USER1PWD permit weblogin user name user2 password USER2PWD permit weblogin user name user3 password USER3PWD permit weblogin user name user4 password USER4PWD permit weblogin user name user5 password USER5PWD permit weblogin service processor policy acct name all-ip target ip unit host name server oid 020000 ip 192.168.0.1 unit host name host1 oid 020001 ip 192.168.0.11 sys-020000-auth acct-policy all-ip unit host name host2 oid 020002 ip 192.168.0.12 sys-020000-auth acct-policy all-ip unit host name host3 oid 020003 ip 192.168.0.13 sys-020000-auth acct-policy all-ip unit host name host4 oid 020004 ip 192.168.0.14 sys-020000-auth acct-policy all-ip unit host name host5 oid 020005 ip 192.168.0.15 sys-020000-auth acct-policy all-ip service weblogin 1 user user1 inact 10min set sys-020000-auth multi open host1 host2 host3 host4 host5 user user2 time 4hour set sys-020000-auth open host2 user user3 time 4hour set sys-020000-auth open host3 user user4 time 4hour set sys-020000-auth open host4 user user5 time 4hour set sys-020000-auth open host5
Далее, на сервере 192.168.0.1 в каталоге, для которого разрешено исполнение CGI-скриптов (с расширением .cgi), должны быть установлены три файла, weblogin.cgi, weblogin.tem и netams_api.pl. Первый является собственно самим скриптом веблогина, второй - это текстовый файл шаблона html-страницы (его можно редактировать под свои нужды) и третий - общий для всех Perl-скриптов интерфейс (API) работы с NeTAMS по сети (подробнее про Perl API см. 6.9).
В начале скрипта weblogin.cgi вы должны определить пользователя, под именем которого будет осуществляться вход в программу собственно самим скриптом. В нашем случае это пользователь web с паролем WebLoginPWD.
Каждый из пользователей на каждой из машин должен иметь на своем рабочем столе Windows (или в закладках internet explorer) ссылку на скрипт:
http://192.168.0.1/cgi-bin/weblogin.cgi
При переходе на эту ссылку клиент увидит страницу вроде этой:
Возможны два варианта: пользователи user2 ... user5 имеют возможность только ввести свой логин и пароль, при этом доступ для данного хоста (откуда они осуществляют логин) будет открыт автоматически при совпадении прав (логин-пароль-имя_хоста). Например:
Web Login
calling from: 192.168.0.11
user user2 is opening unit host2
calling from: 192.168.0.12
host2 (020002) opened 0 sec. ago, last used -1 sec. ago absolute timeout at 14400 sec, inactivity at -1 sec.
В случае пользователя user1, который имеет право открыть доступ любому хосту, вид окна буде другим:
Please specify a host
calling from: 192.168.0.12
После выбора необходимого хоста и нажания кнопки login процедура будет завершена.
Вы также в любой момент можете просмотреть список действующих в данный момент таймаутов, он всегда выводится внизу таблички веб-логина. Это делается командой show timeout (см. 5.4.15)
7. Как сообщить об ошибках и откуда они могут возникнуть
Ошибки могут возникнуть и проявиться на стадии:А) распаковки, конфигурирования, сборки, первого старта
Б) в процессе эксплуатации
Причинами ошибок являются:
А) ошибки в моей программе и скриптах
Б) ошибки сисадмина вследствие его кривых рук
Я сразу предупреждаю, что НЕ ЗАНИМАЮСЬ БЕСПЛАТНЫМИ КОНСУЛЬТАЦИЯМИ ПО НАСТРОЙКЕ ВАШЕГО ЮНИКСА, СЕНДМАИЛА, ТРАНСЛЯЦИИ АДРЕСОВ И ПРОЧЕГО. Я буду отвечать только на письма, непосредственно связанные с моей программой. Если вы не уверены в своих способностях по администрированию вашего сервера, по всей видимости, грамотно поставить и настроить мою программу самостоятельно вам не удастся. В то же время, я оказываю КОММЕРЧЕСКУЮ поддержку и консультации. Поймите меня правильно: эту программу я пишу в свободное от других дел время, один, и у меня НЕТ ФИЗИЧЕСКОЙ ВОЗМОЖНОСТИ помочь всем сразу с их бедами.
Если вы абсолютно уверены в том, что нашли баг в работе моей программы, и что проблема вызвана не опечаткой в конфиге, присылайте мне:
- Подробное описание проблемы
- Версию программы
- Файл конфигурации
- Ключи запуска
- Лог-файл
- Результат gdb netams netams.core , если core-файл создался, не удаляйте его!!!
- Тип и версию операционной системы (uname -a)
- Вывод ipfw show (iptables -l для линукса)
- ifconfig -a
- netstat -rn и правила трансляции адресов, если есть.
8. Настройка операционной системы для бесперебойной работы NeTAMS
В дистрибутиве находится стартап-скрипт, netams-startup.sh. В качетсве параметров он воспринимает ключи start и stop, запуск без параметров эквивалентен start. В первых строчках скрипта необходимо определить параметры и пути:
debug=1 # выводить ли отладочную информацию? log=1 # создавать ли лог-файл? configfile=/usr/home/anton/netams/netams.cfg # путь до конфигурационного файла appfile=/usr/home/anton/netams/netams # путь до исполняемого файла logfile=netams.log # имя лог-файла path=/tmp # путь, в котором будет создаваться log-файл, core-файл и результат обработки core отладчиком |
Поместите этот скрипт в /usr/local/etc/rc.d/ для FreeBSD или в /etc/init.d для Linux, с соответствующими ссылками из /etc/rcX.d/
9. Безопасность
Поскольку NeTAMS запускается с правами root, и отвечает за подсчет небесплатного траффика, безопасность всей системы является очень важным фактором. Существует несколько потенциально небезопасных направлений:- Взлом всей системы через программу
- Взлом защиты самой программы
- Действия, приводящие к неверному учету траффика
| Автор программы не несет никакой ответственности за ее использование и за тот ущерб, который (явно или неявно) может быть нанесен кому-либо в результате работы этой программы или ее компонентов. Если вы несогласны с этим утверждением, деинсталлируйте программу и все ее компоненты немедленно! |
При написании NeTAMS не предпринималось никаких попыток установить компоненты, позволяющие создателю или кому-либо осуществить несанкционированный доступ в систему с работающей программой. Вместе с тем, в результате неизбежных ошибок программирования, такая возможность может потенциально существовать. На данный момент ни одного случая взлома программы зарегистрировано не было.
Несанкционированный доступ к программе может быть получен путем узнавания пароля и присоединения к программе через telnet. Это особенной актуально при использовании генератора статистики HTML. Для уменьшения риска:
- Установите права на чтение конфигурационного файла и лог-файлов только для пользователя root
- Отмените права на чтение локальных файлов HTML-статистики тем, кому не нужно
- Установите (средствами http-сервера) права на просмотр статистики "извне" только тем, кому нужно
- Отмените возможность логина в программу не с локальной машины:
service server 0
login localhost
- Отрежьте правилами firewall вашей системы нелокальное подключение к программе:
ipfw add 100 allow ip from any to any via lo0
ipfw add 110 deny tcp from any to me 20001
Неправильный учет траффика возможен при неверном расположении правил ipfw/iptables и при получении статистики netflow от неизвестного источника. Для избежания этого:
- Подумайте, как данные ходят по вашей сети
- Нарисуйте схему сети с именами интерфейсов
- Выпишите список имеющихся правил ipfw/iptables и придумайте номер (место) вашего правила, через которое будет осуществляться "заворачивание" траффика
- Если вы используете трансляцию адресов или bridging, подумайте еще раз
- Если вы используете прозрачный http-прокси, подумате снова
- Если вы используете подсчет потока NetFlow, ОБЯЗАТЕЛЬНО укажите ip-адрес присылающего статистику роутера в описании соответствующего сервиса data-source.
999. Разное
2. Формат базы данных | |
|
Для начала я расскажу, почему мне не очень хочется говорить о том, в каком виде данные присутствуют в базе. Дело в том, что aaa+fw и NeTAMS изначально задумывались как гибкие программы, где пользователь не был бы ограничен операционной системой, методом сбора траффика, его природой, и базой данных в которой лежала бы статистика. Кому-то нравится MySQL, кому-то Postgres, кто-то хочет только попробовать программу в работе и с БД связываться не хочется (тогда ему прямая дорога использовать unix hash). Привязка к БД привела бы к невозможности все это реализовать более-менее прозрачно. Я придерживаюсь мнения, что весь обмен данными о статистике между "внешним миром" и собственно хранилищем должен производиться через саму программу, которая выступает в роли слоя абстракции. Тем самым ваш PHP-скрипт логина в систему или отображения статистики одинаково работал бы независимо от типа реально БД, более того он бы и не знал о нем и легко переносил возможные в будущем изменения формата базы и ее принципа работы. Однако жестокая реальность не дает мне времени грамотно реализовать такой слой абстракции и снабдить потенциальных писателей расширений к моей программе неким API, по которому бы и велась работа с базой. Поэтому я расскажу о структуре данных, которые программа пишет в БД, на примере MySQL, наиболее широко используемой в данной задаче СУБД. Вся информация помещается в таблицы raw и summary:
mysql> describe raw;
+------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+----------------+
| unit_oid | int(10) unsigned | | MUL | 0 | |
| policy_oid | int(10) unsigned | | MUL | 0 | |
| t_from | int(10) unsigned | YES | | NULL | |
| t_to | int(10) unsigned | YES | | NULL | |
| bytes_in | bigint(20) unsigned | YES | | NULL | |
| bytes_out | bigint(20) unsigned | YES | | NULL | |
| id | bigint(20) unsigned | | PRI | NULL | auto_increment |
| hostname | varchar(32) | YES | | NULL | |
+------------+---------------------+------+-----+---------+----------------+
mysql> describe summary;
+------------+---------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------------+------+-----+---------+-------+
| prefix | enum('T','M','W','D','H') | | | T | |
| unit_oid | int(10) unsigned | | MUL | 0 | |
| policy_oid | int(10) unsigned | | MUL | 0 | |
| t_from | int(10) unsigned | | MUL | 0 | |
| bytes_in | bigint(20) unsigned | YES | | NULL | |
| bytes_out | bigint(20) unsigned | YES | | NULL | |
+------------+---------------------------+------+-----+---------+-------+
В таблице raw сохраняются сырые данные в виде потоков траффика, для каждого конкретного юнита и политики учета, с указанием времени начала (t_from) и конца (t_to) потока. Это время задается в стандартном формате UNIXTIME, т.е. числа секунд, прошедших с начала 1970 года. Вы можете преобразовать эти числа в нормальное человеческое время и наоборот:
mysql> select UNIX_TIMESTAMP('2002-03-20 22:31:48');
+---------------------------------------+
| UNIX_TIMESTAMP('2002-03-20 22:31:48') |
+---------------------------------------+
| 1016652708 |
+---------------------------------------+
mysql> select FROM_UNIXTIME(1016652708);
+---------------------------+
| FROM_UNIXTIME(1016652708) |
+---------------------------+
| 2002-03-20 22:31:48 |
+---------------------------+
В таблице summary сохраняются суммарные данные о траффике для заданного юнита и политики, приведенные для конкретного периода времени. Префикс (prefix) определяет, что это за период:T total, "всего", т.е. с момента заведения данной комбинации unit+policy в базе M month, с начала месяца W week, с начала недели D day, с начала дня H hour, с начала часапри этом поле (t_from) определяет момент, с которого начался подсчет для соответствующей записи. Например, если в базе содержится строка +--------+----------+------------+------------+----------+-----------+ | prefix | unit_oid | policy_oid | t_from | bytes_in | bytes_out | +--------+----------+------------+------------+----------+-----------+ | D | 149240 | 1339391 | 1016139600 | 579459 | 475384 | +--------+----------+------------+------------+----------+-----------+ и select FROM_UNIXTIME(1016139600) выдает "2002-03-15 00:00:00"то она описывает суммарный траффик для данного unit+policy за день, который начался 15 марта 2002 года. | |
3. Ссылки (с комментариями) | |
|
http://www.atlant-inform.ru "АТЛАНТ" Продукт предназначен для корпоративных пользователей Интернет, использующих выделенный канал связи. Использование системы позволяет контролировать трафик Интернет с необходимой степенью детализации. Биллинговая система может быть полезна как крупным компаниям, имеющим несколько выделенных линий для доступа к Интернет от разных провайдеров, так и небольшим организациям, пользующимся линиями других фирм. Система может оказаться весьма удобной при ее совместном использовании компаниями, имеющими выход в Интернет через общий выделенный канал. "АТЛАНТ-ВК" представляет собой клиент-серверную информационную систему. Серверная часть системы функционирует на платформе Sybase Adaptive Server Anywhere (ASA) или Sybase Adaptive Server Enterprise (ASE) под ОС Linux, Windows 9х, 2000, NT. http://www.servocomp.ru "АСР Абсолют" Интегрированная автоматизированная система для учета услуг и расчетов с клиентами компаний, предоставляющих услуги доступа к сети Интернет. "Абсолют" обрабатывает потоки учетных данных в режиме реального времени. Гибкий учет дифференцированного трафика с настраиваемой функцией агрегации предоставляют широкие возможности провайдеру для моделирования и развития новых видов услуг. Конфигурируемые модули сбора трафика обеспечивают оптимизацию нагрузки по тарификации и управления услугами в зависимости от состояния лицевого счета клиентов. Встроенные функции формирования наборов услуг и правил тарификации позволяют легко конструировать многочисленные и сложные схемы тарификации. "Абсолют" производит генерацию, печать и рассылку клиентских счетов. Обеспечивается взаиморасчеты Интернет - провайдеров с поставщиками конечных услуг PSTN при оказании уcлуг VoIP. Дружественные графические интерфейсы пользователя и позволяют операторам и администраторам быстро приобретать необходимые навыки, чтобы справляться с возрастающими рабочими нагрузками. Модули телекоммуникаций, биллинга и управления услугами Интернет интегрированы в одну систему, что позволяет строить развитую распределенную систему на различных платформах. http://www.ietf.org/rfc/rfc2722.txt Traffic Flow Measurement: Architecture Это явно составляли теоретики, а не практики. http://ing.ctit.utwente.nl/WU5/D5.2/index.html The Internet NG Project/Work Unit 5/Internet Accounting/Internet Accounting Architecture Теоретическое изложение того, каким должен быть аккаунтинг в сети. Неплохие примеры, но документ выложен неполностью. http://www.anr.mcnc.org/~divert/index.shtml Divert Sockets for Linux Divert sockets enable both IP packet interception and injection on the end-hosts as well as on routers. Interception and injection happen at the IP layer. The intercepted packets are diverted to sockets in the user space, thus they will not be able to reach their destination unless they are reinjected by the user space sockets. This allows different tricks (e.g., routing and firewall) to be played, outside the operating system kernel, in between the packet interception and reinjection. for 2.0.x, if you need a 2.2.x example, see HOWTO, 2.4.х не поддерживается http://sbilling.lrn.ru Simple Billing System Простая биллинговая система. Предназначена для подсчета сетевого трафика. Выполнена в виде биллинг сервера с которым взаимодействуют клиенты (proxy сервера или специальные демоны передающие информацию о проходящем трафике) . Сервер биллинга хранит все данные в базе mysql. На данный момент sbilling сервер работает только с socks proxy сервером. http://skycat.pp.ru/projects/fdcd.html FDCD Маленький UNIX демон для сбора NetFlow информации. http://www.netfilter.org Netfilter The netfilter/iptables project is the Linux 2.4.x / 2.5.x firewalling subsystem.It delivers you the functionality of packet filtering (stateless or stateful), all different kinds of NAT (Network Address Translation) and packet mangling. If you are running a recent Linux system (Kernel 2.4.x or above) on a router, you can use netfilter/iptables for all kinds of firewalling, NAT or other advanced packet processing. The major part of netfilter/iptables (doing all the hard work) is included in the standard Linux Kernel. In order to do your runtime configuration of the firewalling subsystem, you will need the iptables userspace command, which can be downloaded from here. Note that in most cases, the vendor of your Linux distirbution (Debian, RedHat, SuSE, Conectiva, Mandrake, ...) will already provide you with a pre-built version of this tool. http://www.snort.org The Open Source Network Intrusion Detection System Наилучшая из существующих бесплатных систем обнаружения сетевых атак. Анализирует проходящий через UNIX/Windows маршрутизатор или мимо него траффик, сопоставляя его с обширной и все время пополняющейся базой данных известных атак. Требует (как и любая другая IDS-система) очень тщательной настройки, но результат оправдывает себя. Очень бы хотелось интегрировать обработку траффика, проходящего через NeTAMS, с помощью компонентов Snort. http://www.agarev.pp.ru/billing.html Система учета трафика клиентов сегмента сети через шлюз Система предназначена для учета трафика клиентов сети, проходящего через шлюз на базе Unix FreeBSD машины. Cостоит из нескольких программых модулей. Часть из них запускается на сервере. Написаны они на С/C++. Есть оболочка администратора системы, написанная на Дельфи для Windows. И, наконец, на данный момент имеется единственный пока модуль cgi служащий для просмотра пользователями своей статистики через WWW. Пользователь системы идентифициется по его IP адресу, в соответствие которому ставится его nick-name. Таким образом любителям dhcp ЭТО не подойдет. В системе можно "жестко" привязать MAC адрес карточки клиента к его IP адресу. Однако это, как заметит просвященный читатель, не является панацеей от "умных узеров", которые умеют его менять. Однако, в большинстве случаев этого вполне достаточно. В систему встроены механизмы квотирования. Возможно задание "тотального" (то есть на все время существования данного клиента) и месячного лимитов входящего к клиенту трафика. По превышению оных клиент выключается. Система пока не оперирует с денежными единицами и не ведет "счетов" клиентов. В случае, если учета MAC адресов вести физически не возможно (сервер и клиенты находятся в разных сетях и статические arp записи не спасут положения) то разумнее всего предложить клиентам работать через VPN. Для этого на сервере настраивается и поднимается pptpd , использующий user-lever ppp и несколько видоизменяется политика учета таких пользователей (об этом позднее). Пользователи авторизуются в системе по логину и паролю, получают назначенный IP (прописывается каждому VPN пользователю в качестве адреса VPN адаптера). Из предыдущего пункта следует, что с неменьшим успехом система может учитывать трафик удаленных пользователей, подключенных через user - level ppp по модемам. Отчеты могут генерироваться системой как в оболочке администратора, так и с использованием cgi приложения. Последнее предназначено исключительно для пользователей. Управление же пользователями ведется пока только из оболочки администратора http://www.nf.ru/billing/ NF Billing Система NF Billing представляет собой программный комплекс, ориентированный на сбор данных о проходящем через Linux/Free BSD/OpenBSD маршрутизатор трафике, на котором установлено ПО NF Billing. Система предоставляет администратору статистику об использовании канала интернет потребителями внутренней сети (или сетей) организации в количественном выражении. http://www.unixfaq.ru/cgi-bin/showq.pl?id=330 Каким софтом можно считать траффик под FreeBSD? ipfw count (в составе ОС). Кто-то (либо руками) генерирует кучу правил типа ipfw add 100 count ip from any to ${local_ip_1} in , условие in желательно, поскольку без него траффик будет считаться 2 раза. trafd aka bpft, Vladimir Vorobyev. Оно использует bpft для считания траффика, умеет работать в promisc mode, поэтому подходит для считания траффика не проходящего непосредственно через роутер ipacctd, Roman V. Palagin. ipacctd слушает на каком-нибудь порту. Весь траффик надо туда либо дивертить (divert), либо тиить (tee). ng_ipacct, Roman V. Palagin. Подгpужаемый модуль ядpа, pаботает чеpез netgraph ipcad, Lev Walkin. Еще есть в портах ipcad, работает через bpf/pcap, выдает свои данные через rsh в виде совместимым с cisco ip accounting. Умеет сохранять и восстанавливать свою базу аккаунтинга в/из файлов http://robert.cheramy.net/ipfm/ ipfm IP Flow Meter is a bandwidth analysis tool, that measures how much bandwidth specified hosts use on their Internet link. http://www.haskell.ru/~pooh/netfltools.html Netflow processing tools Набор утилит для сбора и отображения статистики NetFlow, приходящей от маршрутизаторов Cisco. К сожалению, не поддерживает сохранение информации в БД. http://www.tcpdump.org/ libpcap Библиотека, обеспечивающая перехват (точнее, копирование) пакетов (вместе с data-link level заголовком) в пользовательскую программу для дальнейшего анализа. Пример программы, которая ее использует - tcpdump. Данная библиотека используется в data-source libpcap http://traflinux.sourceforge.net talinux http://www.netup.ru NetUP UserTrafManager Биллинговая система NetUP UserTrafManager v.3.0 предназначена для сбора информации о трафике, прошедшем через PC- или Cisco-роутер и ведения личных счетов пользователей. Система производит снятие денег со счета в соответствии с выбранным тарифным планом. Можно создавать любые тарифные планы. Есть возможность определять трафик в различные классы, что позволяет разделять его по сетям и задавать различную стоимость. Например, можно определить в отдельный класс трафик с провайдером, с которым у вас есть пиринговое соглашение. Можно задавать любое количество классов трафика. Наличие т. н. Агента Безопасности (UTM Secure Agent), позволяеющего отключать интернет пользователю, который потерял связь с сервером. Это нужно для предотвращения воровства трафика. Оптимизированная база данных позволяет хранить и обрабатывать детальную статистику за большие промежутки времени (многие месяцы). Интерфейс системы полностью построен на темплейтах, что позволяет изменять его вид под нужды конкретного дизайнера. Его можно "заточить" под любой сайт. Поддержка любого количества языков. Множество других функций. http://www.univ.kiev.ua/~roman/soft/flowc Flowc Flowc is a tool for gathering, storing and analyzing traffic accounting for CISCO routers with NetFlow enabled switching (version 5). This package could be used by ISP for planning, analysis and billing procedures. | |