NetFlow — замечательные протокол от Cisco Systems, который удобно использовать для учета сетевого трафика. Суть работы проста: на определенном интерфейсе (сенсоре) собирается статистика по трафику проходящему через этот интерфейс в определенном направлении (inbound или outbound) и отправляется на некую систему мониторинга (коллектор), которая эти данные собирает, парсит, анализирует и представляет в удобном для администратора виде, все красиво и понятно. Сбор статистики осуществляется на основе записей. Под записью в протоколе NetFlow (v9 или v5) понимается набор данных, в котором указано количество байт, переданных/принятых в рамках одного определенного соединения в определенном направлении.
Например в ходе http сессии между клиентом с IP 10.200.0.1:1921/tcp и сервером с IP 10.200.100.4:80/tcp от сервера до клиента (именно в этом направлении, а не весь трафик в рамках соединения) было передано 1200 кБайт вебтраффика. Получим такую NetFlow запись:
=============================
1. ipv4 tos: 0
2. ipv4 protocol: tcp
3. ipv4 source address: 10.200.100.4
4. ipv4 destination address: 10.200.0.1
5. transport source-port: 80
6. transport destination-port: 1921
7. interface: gig 0/1
Количество байт: 1200000.
============================
Поля, пронумерованные от 1 до 7 называются ключевыми полями и по ним оценивается, принадлежит ли трафик тому или иному потоку/записи. Т.е. пошли через интерфейс пакеты у которых эти семь параметров совпадают — берем и начинаем их считать, пока соединение не закроется или таймаут не истечет. Если, например, тот же хост откроет другое соединение с тем же сервером, у него скорее всего src port будет уже другим, и сервер, отвечая ему будет слать данные уже не на 1921 а, скажем, на 1412. В этом случае сформируется отдельная запись. После того как запись «готова»/закрыта (т.к. закрылось соединение или истек таймаут), информация о ней отправляется на коллектор (ту самую станцию мониторинга) которая все учтет и на своем графике дорисует, например, что в эту единицу времени через интерфейс прошло 1200 кбайт вебтрафика (плюс к тому, что уже было собрано за это время). В итоге мы имеем хорошую статистическую информацию о том, какого рода трафик в нашей сети имеет место быть, какие клиенты/участники межсетевого взаимодействия наиболее активны и в какое время суток, кто из сотрудников использует торрент, скайп и когда они это делают и все что угодно. Для лучшего восприятия, вот графическая интерпритация механизма работы NetFlow:
Простой пример — нужно на граничном, смотрящем в интернет, маршрутизаторе предприятия (в данном случае Cisco 2951) собрать статистику по входящему трафику (кто, сколько, какие протоколы) через интерфейс смотрящий в сторону провайдера (пусть GigabitEthernet 0/0). Т.е. нужно как-то классифицировать трафик, прилетающий от ISP (его PE-роутера) на интерфейс Gig0/0 Cisco 2951. Что для этого делаем? Понадобится всего две синтаксических конструкции и несколько простых шагов.
1. Flow Exporter. Это такая вещь, в которой указано, где находится станция мониторинга и на какой IP+порт ей нужно слать собираемые данные. Выглядит так:
flow exporter EXPORTER_TO_MONITOR
destination 10.200.115.133 //IP станции мониторинга
source GigabitEthernet0/0 //Интерфейс, с которого будет отправляться статистика
transport udp 9999 //порт, на котором станция мониторинга будет слушать прилетающий трафик (Netflow записи).
2. Flow Monitor. Конструкция, которая определяет параметры мониторинга/сбора статистики. В простейшем случае, как здесь, она просто ссылается на exporter, нарисованный на предыдущем шаге.
flow monitor OUTSIDE_IN //Название говорит, что мониторим трафик, прилетающий во внешний интерфейс (OUTSIDE) во входящем направлении (IN)
description Inside traffic on outside interface
record netflow-original
exporter EXPORTER_TO_MONITOR
cache timeout active 300
!
Здесь мы указали, что для формировании записей будут использоваться стандартные семь ключевых полей (см. выше) и добавили cache timeout active, который говорит о том, что если соединение активно больше 300 секунд, информацию о нем нужно все равно отправить на станцию мониторинга, несмотря на то, что оно (соединение) еще не закрылось (трафик после 300 секунд будет уже считаться отдельным потоком). Самое важное здесь — это ссылка на ранее созданный exporter.
Далее просто берем и вешаем этот самый монитор на заранее оговоренный интерфейс Gig0/1:
interface GigabitEthernet0/1
description Link to ISP 1
ip flow monitor OUTSIDE_IN input //Смотрим на трафик, входящий в интерфейс (т.е. если в рамках соединения было передано 500 кБайт а получено 4500 кБайт, то будут учтены только полученные 4500).
Все. С этого момента NetFlow на интерфейсе активирован и работает. Кроме того, статистика вовсю отправляется на некий адрес 10.200.115.133, где ее кто-то должен слушать, но пока этого не делает. Прежде чем установим настроим нечто, что будет собирать прилетающую статистику, посмотрим что видно на самом роутере:
BorderRouter#sh flow monitor OUTSIDE_IN cache format record
Cache type: Normal
Cache size: 4096
Current entries: 878
High Watermark: 4294967295
Flows added: 254391855
Flows aged: 254390917
— Active timeout ( 300 secs) 219181486
— Inactive timeout ( 15 secs) 35177601
— Event aged 0
— Watermark aged 22490
— Emergency aged 9340
IPV4 SOURCE ADDRESS: 93.153.132.236
IPV4 DESTINATION ADDRESS: 91.231.141.8
TRNS SOURCE PORT: 53455
TRNS DESTINATION PORT: 1195
INTERFACE INPUT: Gi0/1
FLOW SAMPLER ID: 0
IP TOS: 0x00
IP PROTOCOL: 6
ip source as: 8359
ip destination as: 0
ipv4 next hop address: 91.231.141.244
ipv4 source mask: /0
ipv4 destination mask: /25
tcp flags: 0x18
interface output: Gi0/0
counter bytes: 165070
counter packets: 1498
timestamp first: 17:18:21.637
timestamp last: 17:22:48.685
IPV4 SOURCE ADDRESS: 93.153.192.254
IPV4 DESTINATION ADDRESS: 91.231.141.244
TRNS SOURCE PORT: 55965
TRNS DESTINATION PORT: 4500
INTERFACE INPUT: Gi0/1
FLOW SAMPLER ID: 0
IP TOS: 0x00
IP PROTOCOL: 17
ip source as: 8359
ip destination as: 0
ipv4 next hop address: 91.231.141.244
ipv4 source mask: /0
ipv4 destination mask: /28
tcp flags: 0x00
interface output: Gi0/0
counter bytes: 32463
counter packets: 190
timestamp first: 17:18:24.098
timestamp last: 17:22:50.458
…………………………………………………
………………………………………………….
и так далее.
Т.е. тут уже видно записи, которые еще не отправлены и статистика по которым собирается в данный момент. По строке Current entries видно, что таких записей сейчас 878 (тут показаны первые две). Посмотрим вторую. Видно, что между хостами 93.153.192.254 и 91.231.141.244 передается IPSec-траффик (IP PROTOCOL:17 — это UDP, TRNS DESTINATION PORT: 4500 — это Nat-T). На данный момент было передано 32463 байт (counter bytes) или 190 пакетов (counter packets). Т.е. понятно что NetFlow работает и все прекрасно считается.
Убедимся еще что работает и сам Exporter, ответственный за то, чтобы статистика отсылалась наружу:
ir4#sh flow exporter EXPORTER_TO_MONITOR statistics
Flow Exporter EXPORTER_TO_MONITOR:
Packet send statistics (last cleared 19w2d ago):
Successfully sent: 11043916 (14061156222 bytes)
Adjacency failure: 10 (8038 bytes)
No destination address: 3 (2859 bytes)
Client send statistics:
Client: Flow Monitor OUTSIDE_IN
Records added: 254429471
— sent: 254429282
— failed to send: 177
Bytes added: 13484761963
— sent: 13484751946
— failed to send: 9381
И тут все Ок. Да, в моем случае NetFlow уже активирован достаточно давно, поэтом такаие цифры, но это не принципиально.
Теперь настроим ту самую станцию мониторинга (коллектор+анализатор). Для целей исследования возьмем триальную версию PRTG Network Monitor, которая даже после завершения триального периода позволит полноценно наблюдать за десятью сенсорами (сейчас нам достаточно одного сенсора). Устанавливаем все в режиме Next->Next->Finish, запускаем сервер, подключаемся к нему по http через любой удобный браузер. Далее нужно просто создать устройство (Devices/Add Device) и для этого устройства добавить сенсор (Sensors/Add Sensor), выбрать NetFlow v9, заполнить нужные поля. Сенсор в терминологии PRTG — это нечто, что собирает прилетающий на порт 9990 траффик. Понятно, что таких сенсоров может быть множество. Можно, например, добавить еще один сенсор, который будет слушать порт 9991 и роутер будет слать на него трафик с того же Gig0/1 интерфейса, но уже в исходящем направлении (OUTSIDE_OUT).
Итак, коллектор был настроен, прошло некоторое время. Посмотрим теперь, к примеру, что насобиралось за двухчасовой период с 15.05 по 17.05 27.02.2014. В самом общем виде имеем такую картину:
Видно, что средняя (Average) скорость входящего в Gig0/1 трафика за данный промежуток времени составила 1979 кбит/с, всего (Total) было принято 1,7 ГБайт. Львиная доля трафика — это http (на графике розовым), было немного RDP или его аналогов, совсем чуть-чуть smtp, ftp, и т.д.
Можно также посмотреть в виде таблиц и графиков какие именно IP с какими типами трафика работают и в каком количестве, в тот или иной промежуток времени и т.д., взять один конкретный IP и понаблюдать за тем, какую часть входящей полосы пропускания он занимал в течение недели и что это был за трафик, etc. Здесь я скриншоты подобных с подобными сведениями из соображений конфиденциальности приводить не буду.
Нужно отметить, что это не реклама PRTG и что существует множество бесплатных opensource продуктов, прекрасно реализующих функции NetFlow коллекторов (например nfsen), которые могут рабоать в промышленных масштабах. PRTG здесь приводится исключительно потому, что новичок может установить и настроить его за 5 минут и получить видимый результат, поэкспериментировать.
В современных устройствах Cisco реализована технология т.н. Flexible NetFlow, основное отличие которой от классических (v5, v9) версии в том, что набор ключевых полей, на основе которых собирается статистика не фиксирован и его можно задавать самостоятельно, равно как и самостоятельно определить какие данные будут считаться (помимо просто числа байт/пакетов). Но, дабы не перегружать статью, более подробно о Flexible NetFlow в следующий раз.
Добавить комментарий