Netflow

Маршрутизаторы и коммутаторы с поддержкой NetFlow способны собирать статистику по IP-трафику на всех интерфейсах, где NetFlow активирован, а затем экспортировать эти данные в виде NetFlow-записей хотя бы к одному сборщику NetFlow — обычно, это сервер, непосредственно занимающийся анализом трафика.

Стандарт NetFlow версия 5 компании Cisco определяет «поток» как однонаправленную последовательность пакетов, для которых совпадают семь критериев (уникальный ключ потока):^[2]

1. Входящий интерфейс (индекс ifIndex в SNMP)
2. Исходный IP-адрес
3. Адрес назначения IP-адрес
4. Номер IP-протокола (IP protocol number)
5. Исходный порт для UDP или TCP; 0 — для других протоколов
6. Порт назначения для UDP или TCP; тип и код для ICMP, либо 0 — для других протоколов
7. Класс обслуживания IP (Type of Service, ToS)

Следует отметить, что исходящий интерфейс, IP Nexthop или BGP Nexthops не входят в состав ключа потока; эти значения могут быть неверными, если маршрут изменится до окончания потока или когда выполняется балансировка нагрузки по пакетам.

Такая же схема применяется для IPv6, а аналогичные критерии используются для потоков MPLS и Ethernet (уровень 2).

Расширенные реализации NetFlow (например, Cisco Flexible NetFlow) или IPFIX допускают определение пользователем критериев ключа потока.

Типичный вывод команды NetFlow-инструмента из командной строки (nfdump) выглядит так:

 Дата начала потока       Длительность Протокол  Src IP:Порт          Dst IP:Порт           Пакеты  Байты Потоки
 2010-09-01 00:00:00.459   0.000     UDP    127.0.0.1:24920     →   192.168.0.1:22126      1     46    1
 2010-09-01 00:00:00.363   0.000     UDP    192.168.0.1:22126   →   127.0.0.1:24920        1     80    1

Маршрутизатор формирует экспортную запись о потоке после завершения этого потока. Основной механизм — технология aging: при поступлении в поток новых пакетов таймер обнуляется. Завершение TCP-сессии также вызывает экспирацию записи. Возможно также конфигурирование маршрутизатора на экспорт записи через фиксированный интервал — даже если поток ещё активен.

Записи NetFlow традиционно экспортируются с использованием UDP, сбор осуществляется NetFlow-коллектором. Необходимо заданить IP-адрес коллектора и порт UDP (стандартно — 2055, альтернативно — 9555, 9995, 9025 и др.).

Обычно маршрутизатор не отслеживает переданные ранее потоки: если UDP-пакет с NetFlow-записями теряется из-за перегрузки или повреждения, все данные в нём теряются навсегда; UDP не предоставляет механизмов повторной передачи. Это может приводить к существенным искажениям статистики, особенно для NetFlow v8/v9, где возможна агрегация большого числа потоков в один пакет.

Некоторые современные реализации используют SCTP (Stream Control Transmission Protocol), чтобы повысить устойчивость к потерям и гарантировать приём шаблонов NetFlow v9 до экспорта связанных записей. Использование TCP для NetFlow нецелесообразно из-за избыточных задержек, вызванных строгой порядковостью.

Однако SCTP требует двустороннего взаимодействия каждого коллектора с каждым маршрутизатором; это может существенно ограничить масштабируемость системы при большом числе устройств и коллекоров, особенно при отказах или обслуживании.

SCTP неэффективен, если сведения требуется экспортировать нескольким независимым коллекторам (например, тестовым серверам). UDP допускает простое копирование потоков через сетевые TAP или L2/L3-мониторинг; также возможна статeless фильтрация или изменение адреса назначения. Обычно потери минимальны, поскольку экспорт преимущественно идёт по магистральным каналам; наибольший риск потерь возникает между сетью и коллекторами.

Любой NetFlow-пакет начинается с версии-зависимого заголовка, содержащего минимум:

• номер версии (v1, v5, v7, v8, v9),
• порядковый номер пакета (детектирует потери/дубли),
• временные метки экспорта (аптайм системы или абсолютное время),
• число записей (v5/v8) или набор шаблонов и записей (v9).

Запись NetFlow может содержать широкий набор сведений о трафике внутри потока.

NetFlow v5 (самая распространённая версия, далее — v9) включает:

• Индекс входящего интерфейса (ifIndex по SNMP/IF-MIB)
• Индекс исходящего интерфейса или 0 (если пакет отброшен)
• Метки времени начала и окончания потока (миллисекунды после загрузки устройства)
• Число и объём (в байтах) пакетов потока
• Заголовки сетевого уровня (Layer 3):
  • IP-адрес источника и назначения
  • Тип и код ICMP-сообщения
  • IP-протокол
  • Значение ToS
• Порт источника и назначения (TCP, UDP, SCTP)
• Для TCP: объединение всех TCP-флагов за время жизни потока
• Layer 3-маршрутизация:
  • IP-адрес ближайшего hop (не BGP nexthop)
  • Маски источника и назначения (длины префикса по CIDR)

Для ICMP-потоков Source Port = 0, а поле порта назначения кодирует тип и код ICMP-сообщения (port = ICMP-Type * 256 + ICMP-Code).

Поля с номерами автономных систем (AS), согласно настройкам, могут содержать последний AS по пути до назначения или непосредственного соседа; при отсутствии поддержки, неизвестном маршруте или локальном AS поле будет содержать 0. Нет явного способа отличить эти случаи.

NetFlow v9 может содержать все перечисленные поля, а опционально — дополнительные (например, метки MPLS, адреса/порты IPv6).

Анализируя такие записи, можно построить детальную картину сетевого трафика и его объёма. Формат NetFlow-рекордов эволюционировал, отсюда — использование версий; Cisco поддерживает подробные спецификации структур NetFlow всех версий.

NetFlow обычно активируется для отдельных интерфейсов с целью снижения нагрузки на маршрутизатор или уменьшения количества экспортируемых записей.

Чаще всего NetFlow фиксирует все входящие на интерфейс IP-пакеты, однако отдельные реализации допускают фильтрацию пакетов по IP-правилам.

Некоторые реализации поддерживают сбор на выходящих интерфейсах; это требует осторожности, иначе потоки с входящего на выходящий интерфейс с NetFlow могут быть учтены дважды.

Стандартный NetFlow рассчитан на анализ всего IP-трафика интерфейса, однако для магистральных каналов это слишком ресурсоёмко (много параллельных коротких потоков).

В результате Cisco реализовала Sampled NetFlow на маршрутизаторах Cisco 12000; сейчас все современные высокопроизводительные устройства используют выборку.

Обрабатывается лишь каждый n-й пакет; n задаётся в настройках.

Алгоритмы выборки:

• Каждый n-й пакет (детерминированный Sampled NetFlow на Cisco 12000)
• Один случайный из n (Random Sampled NetFlow — современные Cisco)
• Для некоторых устройств поддерживается более сложная, например, выборка на поток Cisco Catalyst.

Скорость выборки зачастую одинакова для всех интерфейсов, но может регулироваться по интерфейсам.

Важно учитывать: предоставленные NetFlow-рекорды при использовании Sampled NetFlow отражают оценку, а не точное измерение объёма переданного трафика.

Параметры выборки записываются в заголовке пакета v5 (общее значение) или, для v9 — в специальных полях записей (по интерфейсам).

NetFlow был изначально реализован Cisco и описан в информационном (не стандартизирующем) документе — RFC 3954 «Cisco Systems NetFlow Services Export Version 9». Сам NetFlow впоследствии был заменён официальным стандартом Internet Protocol Flow Information eXport (англ. IPFIX). Основанный на реализации NetFlow v9, IPFIX стандартизирован и опубликован как RFC 5101 (устарел, заменён на RFC 7011), RFC 5102 (устарел, заменён на RFC 7012) и др. (с 2008 г.).

Ряд других производителей, кроме Cisco, реализуют подобную технологию мониторинга сетевых потоков. Благодаря доминирующей доле Cisco технология NetFlow остаётся самой известной в этой области. NetFlow считается товарным знаком Cisco (по состоянию на март 2012 года в опубликованных регистрациях Cisco такой товарный знак не присутствует^[3]):

• Argus - Audit Record Generation and Utilization System
• Jflow или cflowd для Juniper Networks
• NetStream для 3Com/HP
• NetStream для Huawei Technologies
• Cflowd для Nokia
• Rflow для Ericsson
• AppFlow (Citrix)
• sFlow поддерживает: Alaxala, Alcatel Lucent, Allied Telesis, Arista Networks, Brocade, Cisco, Dell, D-Link, Enterasys, Extreme, F5 BIG-IP, Fortinet, Hewlett-Packard, Hitachi, Huawei, IBM, Juniper, LG-Ericsson, Mellanox, MRV, NEC, Netgear, Proxim Wireless, Quanta Computer, Vyatta, Telesoft, ZTE, ZyXEL^[4]

Программный пакет flow-tools^[5] позволяет обрабатывать и управлять экспортом NetFlow с маршрутизаторов Cisco и Juniper^[6].

С выпуском Cisco ASA 5580 появился режим NetFlow Security Event Logging, который использует поля и шаблоны NetFlow v9 для передачи телеметрии событий безопасности в высоконагруженных средах. Такой подход масштабируется лучше, чем syslog, при аналогичной детализации событий.

В качестве альтернативы сбору данных с маршрутизаторов и коммутаторов, мониторинг потоков NetFlow может вестись на выделенных устройствах-пробах, подключённых прозрачно в разрыв контролируемого канала через TAP или SPAN-порт.

Такая архитектура проще внедряется на специализированной пробе, но имеет недостатки:

• нужно использовать пробу на каждом контролируемом канале, что увеличивает затраты на hardware, внедрение и поддержку;
• такие устройства не выдают раздельные данные о входящем и исходящем интерфейсах (как при сборе с маршрутизатора);
• зачастую возникают сложности с точным заполнением полей NetFlow для данных маршрутизации (номера AS, маски), так как проба не работает с таблицей маршрутов.

Компромиссный вариант — развернуть пробу inline перед маршрутизатором и собирать все его NetFlow-выходы; это позволяет хранить большие объёмы записей (до нескольких лет) без вмешательства в настройки сети.

Подход на выделенных пробах оправдан для мониторинга критичных каналов, а сбор c маршрутизаторов даёт полный обзор для задач учёта, мониторинга производительности или безопасности.

NetFlow был изначально реализован как технология коммутации пакетов на маршрутизаторах Cisco (IOS 11.x, ок. 1996). Первой программной реализацией были Cisco 7000, 7200 и 7500^[19]; решение создавалось как улучшение по сравнению с существующей в то время Cisco Fast Switching. Авторами NetFlow в Cisco считаются Даррен Керр и Барри Бруин^[20] (см. патент США № 6243667).

Первый пакет в потоке инициировал создание записи NetFlow, использовавшейся для всех последующих пакетов данного потока до его окончания. Только первый пакет требовал поиска в таблице маршрутизации — что было ресурсоёмкой операцией для старых программных реализаций, не имевших отдельной базы маршрутизации (Forwarding information base). Фактически, запись NetFlow выступала частным кэшем маршрута (старые версии IOS упоминали такой кэш как ip route-cache).

Это решение было эффективно в локальных сетях (особенно — при использовании ACL, так как прохождение ACL требовалось только для первого пакета потока)^[21].

Однако практика показала, что технология NetFlow как способ коммутации не подходит для магистральных маршрутизаторов (большое число параллельных потоков, множество коротких UDP-транзакций — например, DNS с рандомизацией портов).

В результате в качестве основной технологии коммутации NetFlow был вытеснен (ок. 1995) решением Cisco Express Forwarding (первоначально на Cisco 12000, затем — в IOS для 7200/7500).

По состоянию на 2012 год аналогичные механизмы NetFlow используются в современных файрволах и программных IP-маршрутизаторах, например, в подсистеме conntrack в Netfilter на Linux.

• RFC 3334 — Policy-Based Accounting
• RFC 3917 — Требования к экспорту информации о потоках IP (IPFIX)
• RFC 3954 — NetFlow Version 9
• RFC 3955 — Оценка протоколов-кандидатов для экспорта информации о потоках IP (IPFIX)
• RFC 5101 — Спецификация протокола IPFIX
• RFC 5102 — Информационная модель для IPFIX
• RFC 5103 — Двунаправленный экспорт потоков с помощью IPFIX
• RFC 5153 — Рекомендации по реализации IPFIX
• RFC 5470 — Архитектура IPFIX
• RFC 5471 — Тестирование IPFIX
• RFC 5472 — Возможности применения IPFIX
• RFC 5473 — Снижение избыточности при экспорте потоковой информации и сэмплировании пакетов (PSAMP)
• RFC 5476 — Спецификации протокола PSAMP
• RFC 5477 — Модель данных для экспорта пакетов PSAMP
• RFC 5610 — Экспорт информации о типах элементов IPFIX
• RFC 5655 — Формат файла IPFIX
• RFC 5815 — Модель управляемых объектов для IPFIX
• RFC 5982 — IPFIX Mediation: постановка задачи
• RFC 6183 — IPFIX Mediation: архитектура
• RFC 6235 — Анонимизация потоков
• RFC 6313 — Экспорт структурированных данных в IPFIX
• RFC 6526 — IPFIX Per SCTP Stream
• RFC 6615 — Управляемые объекты IPFIX
• RFC 6645 — Методика учёта и экспорта потоков
• RFC 6727 — Управляемые объекты сэмплирования пакетов
• RFC 6728 — Модель конфигурации для IPFIX и PSAMP
• RFC 6759 — Экспорт данных приложений Cisco в IPFIX
• RFC 7011 — Спецификация протокола IPFIX
• RFC 7012 — Информационная модель для IPFIX
• RFC 7013 — Рекомендации по описанию элементов IPFIX
• RFC 7015 — Агрегация потоков в IPFIX
• RFC 7119 — Использование IPFIX на медиаторах
• RFC 7125 — Ревизия tcpControlBits в IPFIX
• RFC 7133 — Элементы для измерения уровня канала
• RFC 7270 — Cisco-специфичные элементы, используемые в IPFIX
• RFC 7373 — Текстовое представление абстрактных типов IPFIX
• RFC 8038 — Экспорт переменных MIB через IPFIX
• RFC 8158 — Элементы IPFIX для логирования NAT-событий
• RFC 8272 — TinyIPFIX для интеллектуальных счётчиков в ограниченных сетях
• RFC 8549 — Экспорт BGP community в IPFIX