Конфигурирование NetFlow для IPv6

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

Вот, пытаемся сделать учет IPv6-трафика с использованием NetFlow. Стандартная схема: сенсоры — это роутеры Cisco, коллекторы работают под BSD или Debian.

Настройка первого сенсора

В соответствии с «фирменной» документацией, поддержка Netflow для IPv6 появилась в версиях Cisco IOS, начиная с 12.2(33), правда в некоторых источниках упоминается, что на самом деле это началось с 12.4(20). То есть лучше всего заранее проверить, есть ли такая возможность в установлнных IOS-ах.

Итак, начинаем с 7206, версия 12.4(24). Вообще-то там была 12.4(15), но по совету друзей мы сделали апгрейд.

Набор команд, которыми нужно пользоваться, не так уж и велик:

ipv6 cef                                           # (без этого не работает NetFlow)
ipv6 flow-export version 9                         # в 5й версии нет IPv6
ipv6 flow-export destination 192.168.123.45 9876   # (аналогично 4й версии протокола)

Вся прелесть — в последней команде: можно отправлять v4 и v6 трафик на один коллектор, но на разные порты, чтобы складывать его в разные файлы — это очень удобно для анализа, особенно в начале работы. А также можно отправлять коллектору статистику раздельно: используя NetFlow5 для IPv4 и NetFlow9 для IPv6, что мы и сделали. А еще прикольно то, что отправка статистики по IPv6 осуществляется только на IPv4-адрес коллектора. Без вариантов!

Кстати, команда ipv6 flow-export version 9 в конфигурационном файле не появилась, так как 9 версия используется по-умолчанию.

Ну, и на нужных интерфейсах следует дать команды

ipv6 flow ingress
ipv6 flow egress

или одну, или обе — вопрос вашей схемы учета.

Затем можно наблюдать за результатами: для начала убеждаемся, что статистика по IPv4 продолжает отправляться, а затем смотрим, идет ли процесс сбора статистики по IPv6.

gw-0#sh ipv6 flow export

(Показать результат) Судя по всему, процесс идет. Смотрим дальше:

gw-0#sh ipv6 flow cache

…и много-много строк…

Ура! Процесс пошел! Можно переходить к коллектору!

Настройка первого коллектора.

Сейчас (2012г.) сбор данных IPv4-NetFlow5 идет на машине под ОС FreeBSD при помощи пакета flow-tools. Пакет хороший, стабильно работающий, но очень старый, и разработчики давным-давно перестали обновлять его. Начинаем искать замену.

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

• работает и с NetFlow9, и с IPv6
• существует package для FreeBSD и OpenBSD
• работает под Debian
• прост, состоит из 2 утилит и 1 конфигурационного файла

Устанавливаем его. В конфигурационном файле достаточно прописать два вида параметров:

• ip-адреса и порты, с которых будет приниматься трафик
• путь к файлу, куда будет записываться статистика.

Путь к файлу должен существовать, так как пакет не умеет его создавать. И, естественно, flowd должен иметь право записи в этом месте.

Перед запуском при помощи tcpdump убеждаемся, что пакеты со статистикой поступают на машину:

tcpdump -n -i em0 port 9876

Вроде работает, пакеты прилетают. Запускаем flowd:

/usr/local/sbin/flowd -f <path_to_config_file>

Для отладки есть два ключа: -d (генерировать вспомогательную информацию) и -g (не переходить в фоновый режим).

ОК, файл со статистикой появился и начал расти.

В отличие от flow-tools здесь нет «естественного» механизма ротации файлов, но в мануале сказано, что при получении сигнала SIGUSR1 происходит закрытие файла с логом и открытие его заново. Это свойство позволяет написать несложный скрипт, который осуществляет ротацию файлов. Вообще-то, достаточно трех строк:

DATE=date +%Y%m%d%-H%M%S
mv /opt/netflow6/gw-core/ipv6-flow /opt/netflow6/gw-core/$DATE-ipv6-flow
kill -SIGUSR1 cat /var/run/flowd.pid

Осталось только сделать вызов такого скрипта из cron с заданным интервалом. По аналогии с flow-tools делаем интервал равным 15 мин.

Просматриваем файлы, очень любопытно, что в них. Оказалось, что практически весь трафик — это ICMP-пакеты и DNS запросы и ответы. Интересно, когда появится первое обращение к www-серверу?

Тремя днями позже

Обьединить файлы со статистикой за одни сутки очень просто. Поскольку они имеют вид filename-yyyymmddhhmmss, то достаточно такой команды:

flowd-reader -q -o ./daily/daily-yyyymmdd filename-yyyymmdd*

(ключ -о задает результирующий файл)

после чего исходные файлы можно удалить

rm filename-yyyymmdd*

Поработаем с суточным файлом, для чего переходим в ./daily и для начала экспортируем в ascii-вид:

flowd-reader daily-yyyymmdd > daily-yyyymmdd.txt

Разумеется, комбинацию yyyymmdd следует заменить на реальные данные.

Для начала — самое любопытное: смотрим, были ли (вообще) обращения к веб-серверам:

grep «]:80 » daily-yyyymmdd.txt

Увы, пока не было. А вот

grep «]:25 » daily-yyyymmdd.txt

показывает, что почтовый обмен (точнее — его попытки) были, и не одна. При рассмотрении почтовых логов выяснилось, что нас пытались посетить несколько спамеров (и были отсеяны еще на сетевом уровне), а пара нормальных почтовых сессий была отвергнута по причине отсутствия реверсных записей IPv6 у почтовиков. То есть кто-то настроил почтовик (и ОС, под которой он работает) для работы с IPv6, а созданием реверсной записи не удосужился. Вот, почта и не пошла..
Итоги: 18 апреля 2011 года нас навестил первый IPv6-спамер.

Ещё один коллектор

Второй коллектор был собран с использованием nfdump. Весь пакет состоит из шести утилит для сбора, фильтрации, ретрансляции и чтения-конвертации данных.

Утилита-коллектор называется nfcapd и запускается с такими параметрами:

-p - UDP порт, на котором принимать данные от сенсоров (не забыть разрешить его на файерволе)
-n - метка, присваиваемая данному flow, так как коллектор может принимать сразу несколько, ip-адрес сенсора и директория куда складывать файлы. Таких наборов с параметром -n может быть несколько.
-S код формата поддиректорий, куда будут складываться файлы
-t интервал, по истечению которого будет создаваться файл
-T сохранять расширеннй набор данных в файлах (или наоборот сократить его)
-w закрывать файлы по границе 5 минут (то есть 30-минутные файлы будут сохраняться в 00 и 30 минут каждого часа)
-D работать в фоновом режиме
-x запускать скрипт по событию закрытия файла

Есть много других ключей, см.официальную документацию. Коллектор по умолчанию слушает данные по IPv4 (именно слушает, а сохраняет ВСЕ, что приходят от сенсора, независимо от протокола)

Пример:

nfcapd -p 5432 -n ROUTER1 192.168.123.45 /opt/flow/v6/ROUTER1
            -n ROUTER2 172.16.213.245 /opt/flow/v6/ROUTER2
            -S 1 -t 900 -T -1,-2 -w -D 
            -x "/scripts/convert_data.sh %d %f"

Здесь коллектор принимает данные по UDP:5432 от двух сенсоров ROUTER1 ROUTER2 с указанными адресами и складывает файлы в соответствующие ПОДДИРЕКТОРИИ приведенных директорий. Код формата -S 1 - это %Y/%m/%d year/month/day , то есть иерархия поддиректорий будет год-месяц-день, файлы формируются каждые 15 минут (-t 900), в файлы не будут сохраняться данные об интерфейсах коллектора и номера AS (-T -1, -2), файлы будут формироваться в 00 15 30 и 45 минут каждого часа, всё будет работать в фоновом режиме, а по закрытию очередного файла будет запускаться скрипт convert_data.sh, которому передадутся параметры - директория где этот файл и имя файла. Данный скрипт может использоваться, например, для отправки письма о нормальной работе коллектора, или для поиска аномалий в свежем файле, или для сбора текущей статистики.

Вторая полезная утилита в этом пакете - это nfdump, которая преобразует двоичные файлы в текстовый вид и имеет очень богатый выбор настроек для фильтрации, построения статистики и форматирования вывода. Но на этом экране слишком мало места, чтобы описать её возможности.

(впервые написано в 2012 году, изменено и дополнено в 2024)

А как обстоит дело сейчас, в 2024 году?

Ну, в новых версиях всё стало немного по-другому

• сначала конфигурируется экспортёр
• затем создаётся монитор, к которому прикрепляется экспортёр или экспортёры
• а монитор приписывается к интерфейсу в нужном направлении или во всех направлениях