Протокол сетевой статистики NetFlow: Экспорт и анализ трафика

Введение

Протокол связи NetFlow — это функция, представленная в маршрутизаторах Cisco примерно в 1996 году, которая позволяет собирать IP-сетевой трафик при его входе или выходе из интерфейса. Анализируя данные, предоставляемые NetFlow, сетевой администратор может определить такие параметры, как источник и назначение трафика, класс обслуживания и причины возникновения заторов. Типичная система мониторинга потоков (с использованием NetFlow) состоит из трех основных компонентов:

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

Описание протокола

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

Экспорт записей

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

Протокол транспортировки пакетов

Записи NetFlow традиционно экспортируются с использованием протокола пользовательских данных (UDP) и собираются с помощью коллектора NetFlow. IP-адрес коллектора NetFlow и порт UDP назначения должны быть настроены на отправляющем маршрутизаторе. Распространенным значением является порт UDP 2055, но также могут использоваться другие значения, такие как 9555 или 9995, 9025, 9026 и т. д. В целях эффективности маршрутизатор традиционно не отслеживает уже экспортированные записи потоков, поэтому, если пакет NetFlow теряется из-за перегрузки сети или повреждения пакета, все содержащиеся в нем записи теряются безвозвратно. Протокол UDP не сообщает маршрутизатору о потере, чтобы он мог повторно отправить пакеты. Это может стать серьезной проблемой, особенно с NetFlow v8 или v9, которые могут объединять большое количество пакетов или потоков в одну запись. Потеря одного UDP-пакета может оказать существенное влияние на статистику некоторых потоков. Поэтому в некоторых современных реализациях NetFlow используется протокол управления потоком передачи (SCTP) для экспорта пакетов, чтобы обеспечить некоторую защиту от потери пакетов и гарантировать получение шаблонов NetFlow v9 перед экспортом какой-либо связанной записи. Следует отметить, что TCP не подходит для NetFlow, поскольку строгий порядок пакетов приведет к чрезмерной буферизации и задержкам. Проблема с SCTP заключается в том, что он требует взаимодействия между каждым коллектором NetFlow и каждым маршрутизатором, экспортирующим NetFlow. Могут возникнуть ограничения производительности, если маршрутизатору приходится работать со многими коллекторами NetFlow, а коллектору NetFlow – со многими маршрутизаторами, особенно если некоторые из них недоступны из-за сбоев или технического обслуживания. SCTP может быть неэффективным, если NetFlow необходимо экспортировать в несколько независимых коллекторов, некоторые из которых могут быть тестовыми серверами, которые могут выйти из строя в любой момент. UDP позволяет просто дублировать пакеты NetFlow с помощью сетевых TAP или зеркалирования L2 или L3. Простое оборудование, не сохраняющее состояние, также может фильтровать или изменять адрес назначения пакетов NetFlow UDP при необходимости. Поскольку экспорт NetFlow в основном использует магистральные сетевые каналы, потеря пакетов часто будет незначительной. Если это произойдет, то в основном это будет на канале между сетью и коллекторами NetFlow.

NetFlow records are traditionally exported using User Datagram Protocol (UDP) and collected using a NetFlow collector. The IP address of the NetFlow collector and the destination UDP port must be configured on the sending router. A common value is UDP port 2055, but other values like 9555 or 9995, 9025, 9026 etc. can also be used. For efficiency reasons, the router traditionally does not keep track of flow records already exported, so if a NetFlow packet is dropped due to network congestion or packet corruption, all contained records are lost forever. The UDP protocol does not inform the router of the loss so it can send the packets again. This can be a real problem, especially with NetFlow v8 or v9 that can aggregate a lot of packets or flows into a single record. A single UDP packet loss can cause a huge impact on the statistics of some flows. That is why some modern implementations of NetFlow use the Stream Control Transmission Protocol (SCTP) to export packets so as to provide some protection against packet loss, and make sure that NetFlow v9 templates are received before any related record is exported. Note that TCP would not be suitable for NetFlow because a strict ordering of packets would cause excessive buffering and delays. The problem with SCTP is that it requires interaction between each NetFlow collector and each router exporting NetFlow. There may be performance limitations if a router has to deal with many NetFlow collectors, and a NetFlow collector has to deal with many routers, especially when some of them are unavailable due to failure or maintenance. SCTP may not be efficient if NetFlow must be exported toward several independent collectors, some of which may be test servers that can go down at any moment. UDP allows simple replication of NetFlow packets using Network taps or L2 or L3 Mirroring. Simple stateless equipment can also filter or change the destination address of NetFlow UDP packets if necessary. Since NetFlow export almost only use network backbone links, packet loss will often be negligible. If it happens, it will mostly be on the link between the network and the NetFlow collectors.

Интерфейсы

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

Версии

VersionCommentv1Первая реализация, теперь устаревшая и ограниченная IPv4 (без маски IP-адресов и номеров AS). v2Внутренняя версия Cisco, никогда не выпускалась. v3Внутренняя версия Cisco, никогда не выпускалась. v4Внутренняя версия Cisco, никогда не выпускалась. v5Наиболее распространенная версия, доступная (по состоянию на 2009 год) на многих маршрутизаторах различных производителей, но ограниченная потоками IPv4. v6Больше не поддерживается Cisco. Информация об инкапсуляции (?). v7Подобна версии 5 с добавлением поля исходного маршрутизатора. Используется (вероятно, только) на коммутаторах Cisco Catalyst. v8Несколько форм агрегации, но только для информации, уже содержащейся в записях версии 5. v9Основана на шаблонах, доступна (по состоянию на 2009 год) на некоторых современных маршрутизаторах. В основном используется для отчетов о потоках, таких как IPv6, MPLS или даже обычный IPv4 с BGP next hop. v10Используется для идентификации IPFIX. Хотя IPFIX в значительной степени основан на NetFlow, версия 10 не имеет отношения к NetFlow.

NetFlow и IPFIX

NetFlow был первоначально реализован компанией Cisco и описан в "информационном" документе, не предназначенном для стандартизации: RFC 3954 – Cisco Systems NetFlow Services Export Version 9. Сам протокол NetFlow устарел и был заменен протоколом Internet Protocol Flow Information eXport (IPFIX). IPFIX, основанный на реализации NetFlow версии 9, проходит процедуру стандартизации в IETF в соответствии с RFC 5101 (заменен RFC 7011), RFC 5102 (заменен RFC 7012) и другими документами, опубликованными в 2008 году.

Поддержка

Продавец и тип Модели NetFlow Версия Реализация Комментарии Cisco IOS XR маршрутизаторы CRS, ASR9000 старые 12000 v5, v8, v9 Программное обеспечение, работающее на CPU линейной карты Полная поддержка IPv6 и MPLS Cisco IOS маршрутизаторы 10000, 7200, старые 7500 v5, v8, v9 Программное обеспечение, работающее на маршрутном процессоре. Поддержка IPv6 или MPLS требует последних моделей и IOS Cisco Catalyst коммутаторы 7600, 6500, 4500 v5, v8, v9 Специализированное аппаратное обеспечение TCAM, также используемое для ACL. Поддержка IPv6 на высококлассных моделях RSP720 и Sup720, но не более 128K или 256K потоков на карту PCF. Cisco Nexus коммутаторы 5600, 7000, 7700 v5, v9 Специализированный аппаратный TCAM, также используемый для ACL. До 512K потоков. Поддержка IPv4/IPv6/L2. MPLS не поддерживается Juniper старые маршрутизаторы M серия, T серия, MX серия с DPC v5, v8 Программное обеспечение, работающее на Routing Engine, называется software jflow. IPv6 и MPLS не поддерживаются Juniper старые маршрутизаторы M серия, T серия, MX серия с DPC v5, v8, v9 Программное обеспечение, работающее на service PIC, называется hardware jflow или sampled. IPv6 или MPLS поддерживаются на MS DPC, MultiService PIC, AS PIC2 Juniper маршрутизаторы MX серия с MPC 3D, FPC5 для T4000 v5, IPFIX Аппаратное обеспечение (trio chipset), называется inline jflow. IPv6 требует JUNOS 11.4R2 (back port target), поддержка MPLS неизвестна, MPC3E исключена до версии 12.3, некорректное поле start time вызывает некорректный результат пропускной способности данных Nokia маршрутизаторы 7750SR v5, v8, v9, v10 IPFIX Программное обеспечение, работающее на Central Processor Module. IPv6 или MPLS с использованием IOM3 линейных карт или лучше Huawei маршрутизаторы NE5000E NE40E/X NE80E v5, v9 Программное обеспечение, работающее на сервисных картах. Поддержка IPv6 или MPLS неизвестна Enterasys коммутаторы S серия и N серия v5, v9 Специализированное аппаратное обеспечение. Поддержка IPv6 неизвестна Flowmon зонды Flowmon Probe 1000, 2000, 4000, 6000, 10000, 20000, 40000, 80000, 100000 v5, v9, IPFIX Программное или аппаратное ускорение. Полная поддержка IPv6 и MPLS, скорость обработки данных на уровне проводной линии Nortel коммутаторы Ethernet Routing Switch 5500 Series (ERS5510, 5520 и 5530) и 8600 (Chassis based) v5, v9, IPFIX Программное обеспечение, работающее на CPU линейной карты. Полная поддержка IPv6 PC и Серверы Linux FreeBSD NetBSD OpenBSD v5, v9, IPFIX Программное обеспечение, такое как fprobe, ipt netflow, pflow, flowd, Netgraph ng netflow или softflowd. Поддержка IPv6 зависит от используемого программного обеспечения VMware серверы vSphere 5.x v5, IPFIX (>5.1) Программное обеспечение. Поддержка IPv6 неизвестна Mikrotik RouterOS RouterOS 3.x, 4.x, 5.x, 6.x v1, v5, v9, IPFIX (>6.36RC3) Программное обеспечение и Routerboard аппаратное обеспечение. IPv6 поддерживается с использованием v9. В настоящее время RouterOS не включает номера BGP AS.

Vendor and type Models NetFlow Version Implementation Comments Cisco IOS XR routers CRS, ASR9000 old 12000 v5, v8, v9 Software running on line card CPU Comprehensive support for IPv6 and MPLS Cisco IOS routers 10000, 7200, old 7500 v5, v8, v9 Software running on Route Processor support for IPv6 or MPLS require recent model and IOS Cisco Catalyst switches 7600, 6500, 4500 v5, v8, v9 Dedicated hardware TCAM, also used for ACLs. Support for IPv6 on high end models RSP720 and Sup720, but at most 128K or 256K flows per PCF card. Cisco Nexus switches 5600, 7000, 7700 v5, v9 Dedicated hardware TCAM, also used for ACLs. Up to 512K flows. Support IPv4/IPv6/L2. MPLS not supported Juniper legacy routers M series, T series, MX series with DPC v5, v8 Software running on Routing Engine, called software jflow IPv6 and MPLS not supported Juniper legacy routers M series, T series, MX series with DPC v5, v8, v9 Software running on service PIC, called hardware jflow or sampled IPv6 or MPLS supported on MS DPC, MultiService PIC, AS PIC2 Juniper routers MX series with MPC 3D, FPC5 for T4000 v5, IPFIX Hardware (trio chipset), called inline jflow IPv6 requires JUNOS 11.4R2 (back port target), MPLS support unknown, MPC3E excluded until 12.3, incorrect start time field causing incorrect data throughput result Nokia routers 7750SR v5, v8, v9, v10 IPFIX Software running on Central Processor Module IPv6 or MPLS using IOM3 line cards or better Huawei routers NE5000E NE40E/X NE80E v5, v9 Software running on service cards Support for IPv6 or MPLS is unknown Enterasys Switches S Serie and N Serie v5, v9 Dedicated hardware IPv6 support is unknown Flowmon Probes Flowmon Probe 1000, 2000, 4000, 6000, 10000, 20000, 40000, 80000, 100000 v5, v9, IPFIX Software or hardware accelerated Comprehensive support for IPv6 and MPLS, wire speed Nortel Switches Ethernet Routing Switch 5500 Series (ERS5510, 5520 and 5530) and 8600 (Chassis based) v5, v9, IPFIX Software running on line card CPU Comprehensive support for IPv6 PC and Servers Linux FreeBSD NetBSD OpenBSD v5, v9, IPFIX Software like fprobe, ipt netflow, pflow, flowd, Netgraph ng netflow or softflowd IPv6 support depend on the software used VMware servers vSphere 5. x v5, IPFIX (>5.1) Software IPv6 support is unknown Mikrotik RouterOS RouterOS 3. x, 4. x, 5. x, 6. x v1, v5, v9, IPFIX (>6.36RC3) Software and Routerboard hardware IPv6 is supported using v9. Currently RouterOS does not include BGP AS numbers.

Запись событий безопасности NetFlow от Cisco

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

Мониторинг на основе автономных зондов

Сбор потоков NetFlow с использованием автономных зондов NetFlow является альтернативой сбору потоков с маршрутизаторов и коммутаторов. Этот подход позволяет преодолеть некоторые ограничения мониторинга NetFlow, основанного на маршрутизаторах. Зонды прозрачно подключаются к контролируемому каналу связи как пассивное устройство, используя TAP или SPAN-порт. Исторически, мониторинг NetFlow проще реализовать в выделенном зонде, чем в маршрутизаторе. Однако этот подход также имеет недостатки: зонды необходимо развертывать на каждом канале, который требуется контролировать, что влечет за собой дополнительные затраты на оборудование, настройку и обслуживание. Зонды не будут предоставлять отдельные данные для входящего и исходящего интерфейсов, как это делает маршрутизатор. Кроме того, зонды могут испытывать трудности с надежным отчетом по полям NetFlow, связанным с маршрутизацией, таким как номера AS или маски IP, поскольку вряд ли они будут использовать точно такую же информацию о маршрутизации, как и маршрутизатор. Самый простой способ устранить эти недостатки – использовать устройство захвата пакетов, установленное непосредственно перед маршрутизатором, для перехвата всего вывода NetFlow от маршрутизатора. Этот метод позволяет хранить большие объемы данных NetFlow (обычно данные за несколько лет) и не требует перенастройки сети. Сбор NetFlow с выделенных зондов хорошо подходит для мониторинга критически важных каналов, в то время как NetFlow на маршрутизаторах обеспечивает общесетевое представление трафика, которое можно использовать для планирования пропускной способности, учета, мониторинга производительности и обеспечения безопасности.

История

NetFlow изначально была технологией коммутации пакетов Cisco для маршрутизаторов Cisco, реализованной в IOS 11.x примерно в 1996 году. Первоначально это была программная реализация для Cisco 7000, 7200 и 7500, задуманная как улучшение по сравнению с Cisco Fast Switching того времени. NetFlow был изобретен Дарреном Керром и Барри Бруином из Cisco (патент США № 6,243,667). Идея заключалась в том, что первый пакет потока создавал бы запись коммутации NetFlow. Эта запись затем использовалась бы для всех последующих пакетов того же потока до истечения срока действия потока. Только первый пакет потока требовал бы анализа таблицы маршрутизации для поиска наиболее подходящего маршрута. Это дорогостоящая операция в программных реализациях, особенно в старых, не имеющих базы информации о пересылке. Запись коммутации NetFlow фактически являлась своего рода записью кэша маршрутов, и в старых версиях IOS кэш NetFlow по-прежнему называют кэшем ip-маршрутов. Эта технология была выгодна для локальных сетей, особенно если часть трафика требовала фильтрации с помощью ACL, поскольку только первый пакет потока должен был быть проверен ACL. Вскоре коммутация NetFlow оказалась непригодной для больших маршрутизаторов, особенно для магистральных маршрутизаторов Интернета, где количество одновременных потоков было гораздо важнее, чем в локальных сетях, и где некоторые типы трафика генерировали множество короткоживущих потоков, например, запросы системы доменных имен (порт-источник которых случайный в целях безопасности). Как технология коммутации, NetFlow была заменена примерно в 1995 году Cisco Express Forwarding. Она впервые появилась на маршрутизаторах Cisco 12000, а затем заменила коммутацию NetFlow в расширенных версиях IOS для Cisco 7200 и Cisco 7500. По состоянию на 2012 год технологии, аналогичные коммутации NetFlow, все еще используются в большинстве межсетевых экранов и программных IP-маршрутизаторов, например, функция conntrack в структуре Netfilter, используемой Linux.