Учет трафика Cisco ASA с помощью NetFlow, nfdump и MySQL на FreeBSD или Linux (Часть 2)

Введение


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

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

Первое, с чего пришлось начать, это с изучения данной статьи — http://habrahabr.ru/post/127613/ (автору gag_fenix большущий респект). Это единственная нормальная и полная статья о том, как можно получить и учитывать трафик на сетевом оборудование Cisco ASA с использованием nfdump. В этой статье отлично описана только реализация о том, как можно настроить оборудование на передачу пакетов NetFlow на хост, а также каким образом можно использовать полученные данные для последующего анализа. Сам же анализ трафика и его учет не рассматривается в статье.

Перед тем, как читать дальше, настоятельно рекомендую хорошо изучить вышеуказанную статью, так как некоторые особенности настройки будут опускаться. В статье рассмотрим такие вопросы о том, как вести учет по NetFlow (используя MySQL на коллекторе), как посчитать VPN трафик, какой тип пакетов учитывать, как избежать «удвоения» и «дублирования» трафика, и как использовать мое приложение.

Что нужно знать о NetFlow, которое используется на оборудование Cisco ASA


Кому теория неинтересна, просто пропустите этот раздел.

Забегая вперед, скажу следующее, что подружить другие "software" маршрутизаторы, которые используют NetFlow, у меня не получилось. Например, у меня не получилось подружить такой маршрутизатор как pfSense, потому что плагин, отвечающий за отправку NetFlow, предоставляет некорректные данные (в моем случае были пакеты, где трафик исчислялся в терабайтах за период в 10 минут).

NetFlow v9 поддерживается оборудованием Cisco начиная с ASA 5505.

Количество NetFlow трафика в компании в среднем будет составлять 10-20 мегабайт в час, поэтому не спешите выделять порт для своего коллектора на свитче в 1 Gbit/s. В моем случае количество трафика составляет не более 15 мегабайт в час с нескольких устройств Cisco ASA.

Теперь начнем с того, какой или какие типы пакетов NetFlow необходимо использовать для учета трафика. Всего их 4 типа: DENIED, CREATED, UPDATED, DELETED (Torn Down). На другом оборудование еще встречается только IGNORED, например в том же pfSense (там NetFlow пакеты никак не различаются по типу).

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

CREATED, UPDATED — пакеты NetFlow, в которых указывается инициализация (CREATED), и периодическое обновление трафика после инициализации (UPDATED), данные типы также не будут учитываться нами для учета трафика (объяснение ниже);

DELETED (Torn Down) — пакеты NetFlow, в которых указана полная информация о трафике, который был завершен, сумма входящего и исходящего трафика «всегда» должна удовлетворять следующей формуле CREATED + UPDATED = DELETED, этот тип мы и будем учитывать.

Для того, чтобы не было "удвоения" трафика, необходимо использовать либо CREATED + UPDATED пакеты, либо только DELETED. Если использовать и то и другое, то ваш реальный трафик будет отображаться как реальный трафик умноженный на два! В идеале нужно учитывать трафик CREATED + UPDATED, так как эти 2 типа дают более точное представление о том, насколько загружен ваш Интернет в текущий момент времени. DELETED — это та информация о трафике, в которой сессия прекратила свое существование, и например, если кто-то в компании поставит загрузку очень большого файла с утра и закончит скачивать его только вечером, то данные о большом трафике отобразятся ТОЛЬКО вечером!

Увы, но пришлось вести учет трафика по типу DELETED, так как имеется баг в связке Cisco NetFlow + nfcapd (nfdump) + UPDATED. Баг заключается в том, что с определенной частотой при парсинге nfdump в пакетах UPDATED, встречается трафик размером 4,3 GB. Мне не удалось выяснить чем вызван этот баг, или реализацией самим оборудованием Cisco, где в пакете содержится какая-то «хитрая» информация, которую не может обработать nfdump, либо баг в самой реализации nfcapd + nfdump. В пакетах DELETED такого бага не было замечено за пару месяцев работы оборудования.

Как вести учет по NetFlow, включая VPN трафик


Кому и эта теория неинтересна, также пропустите этот раздел.

Понятно, что мы хотим считать и учитывать только "реальный" трафик, который поступает ТОЛЬКО от провайдера. И мы не хотим, чтобы к этому трафику добавлялся локальный трафик, например трафик между LAN и DMZ, или трафик между всеми "white" хостами вашей подсети (подсеть IP адресов, выделенная вашим провайдером). Здесь все просто, считаем только такой трафик из NetFlow пакета, где наш какой-либо локальный хост идет куда-либо в Интернет и фильтруем трафик, который идет либо в DMZ, либо на какой-либо ваш "white" IP адрес, либо любую VPN подсеть (почему игнорируем VPN подсети описано ниже).

Вся загвоздка заключается с учетом реального трафика, где используется любой тип VPN. Например такие маршруты VPN трафика: LAN(DMZ)-to-VPN, VPN-to-LAN(DMZ), VPN-to-VPN, VPN-to-INTERNET. Так вот, после долого анализа файлов, с использованием утилиты nfdump, мной были сделаны следующие выводы о том, как учитывать трафик с такими маршрутами. Если вы хотите узнать, сколько потребляется VPN трафика вашими сотрудниками, например LAN(DMZ)-to-VPN, VPN-to-VPN, то вы просто должны учесть это трафик как есть, то есть просто посчитать количество трафика, которое идет из вашей локальной подсети или DMZ на VPN подсети, или VPN-to-VPN (это количество будет почти точно отображать количество потребляемого VPN трафика). Полученное количество VPN трафика нельзя использовать для "реального" учета трафика, так как "реальный" трафик будет отображен между белыми IP адресами, например между вашим IP офиса и IP удаленного клиента, или между белыми IP 2ух офисов. Во-первых, такое количество будет полностью отображать количество VPN трафика между белыми хостами, а во-вторых, это количество будет значительно выше количества трафика ANY-to-VPN, так как в этом количестве будет учитываться такой трафик как VPN-to-INTERNET, а также дополнительный системный трафик.

Таким образом учет трафика необходимо делать по вашим WAN подсетям наравне с LAN. Делаем 2 подсчета трафика: WAN-to-!(LAN, DMZ, VPN, YOUR WAN) и !(LAN, DMZ, VPN, YOUR WAN)-to-WAN. Так мы точно учтем весь "реальный" трафик, а также тот трафик, который инициализируется на самих Cisco ASA, либо приходит из вне. Учет трафика VPN-to-INTERNET учитывается точно также, как и LAN(DMZ)-to-INTERNET.

Итоговая формула подсчета реального трафика по NetFlow: (LOCAL-to-INTERNET) + (INTERNET-to-LOCAL)

LOCAL — это все подсети типа WAN, LAN, DMZ, VPN;
INTERNET — весь остальной трафик, который не относится к WAN, LAN, DMZ, VPN.

На практике при подсчете трафика типа "INTERNET-to-LOCAL" у вас будет считаться только трафик типа "INTERNET-to-WAN", так как других NetFlow данных у вас не будет, например не будет данных по типу "INTERNET-to-(LAN, DMZ, VPN)".

Итоговая формула подсчета VPN трафика по NetFlow: LOCAL-to-VPN

LOCAL — это все подсети типа WAN, LAN, DMZ, VPN

Этот VPN трафик НЕЛЬЗЯ суммировать с реальным трафиком, так как он уже включает в себя полную статистику по всем VPN сессиям между "VPN_REMOTE_HOST-to-WAN", "WAN-to-VPN_REMOTE_HOST". Данный трафик отображает только примерное количество трафика, которое идет по VPN сессиям.

От теории к практики или делаем подготовку сенсора и коллектора


Начну с того, что напишу версии программного обеспечения, с которыми работаю на момент написания статьи:

Cisco ASAASDM 7.1.6, ASA 9.1.5 (http://software.cisco.com/download/type.html?mdfid=279513399)
Коллектор (PC Core2Duo, 2GB RAM, 160GB HDD) — Debian 7.4, MySQL 5.5.35, Apache 2.2.22, PHP 5.4.4-14
nfdump 1.6.12 (http://sourceforge.net/projects/nfdump/files/stable/)

Мы условились, что учитывать будем только пакеты NetFlow с типом DELETED. Поэтому в ASDM выставим отправку только этого типа пакетов.

image

Теперь нам надо подготовить коллектор. Все что нам нужно, это скачать исходники и скомпилировать их c поддержкой NSEL:

  • 1) ./configure --enable-nsel
  • 2) make
  • 3) make install


Подготовка MySQL базы под NetFlow на коллекторе:


  • 1) Создадим базу: CREATE DATABASE NetFlow CHARACTER SET utf8 COLLATE utf8_general_ci;
  • 2) Добавим пользователя netflow: GRANT ALL PRIVILEGES ON NetFlow.* TO 'netflow'@'%' IDENTIFIED BY 'nfpass' WITH GRANT OPTION;
  • 3) Сбрасываем привелегии: FLUSH PRIVILEGES;
  • 4) Импорт чистой базы: mysql -uroot -proot_pass NetFlow < /var/www/netflow/setup/netflow.sql (где root_pass, пароль от вашего сервера MySQL).


Оптимизация MySQL:

В нашем случае понадобится изменение настроек по умолчанию, так как база будет использовать больше ресурсов, чем прописано в дефолтном конфиге MySQL. Например, только один запрос по INSERT может быть несколько мегабайт. Основная задача — это добиться того, чтобы все запросы INSERT проходили, и при этом не терялись данные, как у меня было в самом начале исследования. А также оптимизировать работу запросов SELECT, чтобы база отдавала данные в приемлемое время. У меня не получилось оптимизировать базу под InnoDB, поэтому использую MyISAM.

Напомню, что у меня на коллекторе установлено 2GB RAM, поэтому в вашем случае параметры могут отличаться как в большую, так и в меньшую сторону. Приведу свои настройки, которые мне помогли оптимизировать MySQL:

skip-innodb
default-storage-engine = MyISAM
sort_buffer_size = 4M
myisam_sort_buffer_size = 256M
key_buffer = 256M
max_allowed_packet = 32M
read_rnd_buffer_size = 2M
thread_stack = 2M
thread_cache_size = 16
query_cache_limit = 32M
query_cache_size = 128M

Перегружаем MySQL: /etc/init.d/mysql restart

Если у вас возникнут проблемы с оптимизацией, воспользуйтесь perl-скриптом с сайта http://mysqltuner.com/
Все подробности использования и оптимизации написаны на сайте, а также при выполнении скрипта.

Определяем свои подсети в базе:

Откройте ваш браузер и перейдите по ссылке /netflow/networks
Опишите все ваши локальные подсети по типу LAN, DMZ, WAN, VPN
Далее укажите те подсети, которые относятся к VPN, например подсети удаленного офиса или подсети удаленных клиентов.

Запускаем наш коллектор:

Перед запуском проверте, что у вас установлен плагин php5-mysql или php5-mysqlnd

/usr/local/bin/nfcapd -t 600 -w -p 9995 -l /netflow/nflogs -D -x '/usr/bin/php5 /var/www/netflow/scripts/netflow.php %d/%f'

"/netflow/nflogs" — это путь к логам;
"/usr/bin/php5 /var/www/netflow/scripts/netflow.php %d/%f" — это запуск php-скрипта, после того как файл с логами будет создан.

Этот скрипт "сердце" учета трафика, который собирает статистику каждые 10 минут, обрабатывает ее и кладет в базу данные о трафике, а также чистит устаревшие данные. Скрипт оптимизирован под временной интервал сбора статистики каждые 10 минут, поэтому не меняйте параметр "-t 600".

Если все сделано правильно, то на ваш коллектор будут приходить NetFlow пакеты. Посмотреть можно командой: "tcpdump port 9995". Если пакеты приходят от вашего оборудования на порт, значит все хорошо, иначе вы неправильно настроили свою циску.

Итог


На этом настройка коллектора полностью завершена. Теперь вы можете детально наблюдать за тем, кто и как использует Интернет в вашем офисе. В этом вам помогут 2 дополнительных скрипта, которые находятся в папке "/netflow" и "/netflow/admin". Первым скриптом вы можете пугать своих сотрудников, чтобы они сами смотрели свой трафик, а второй скрипт используйте для административного просмотра всей статистики.

Установка и описание моих скриптов


Скачать приложение можно тут netflow.tar.gz, далее распакуйте и скопируйте папку /netflow в корень вашей WEB директории, например /var/www

В архиве несколько файлов:

\netflow\setup\crontab — в кроне прописан запуск скрипта nfcap.sh каждые 5 минут;
\netflow\setup\nfcap.sh — скрипт, который проверяет живучесть сервиса nfcapd и запускает его, если тот незапущен;
\netflow\scripts\netflow.php — скрипт, который собирает информацию о трафике и кладет его в базу MySQL;
\netflow\index.php — пользовательский скрипт для просмотра своей статистики;
\netflow\admin\index.php — административный скрипт для просмотра всей статистики в офисе;
\netflow\networks\index.php — скрипт, при помощи которого можно управлять подсетями и вести по ним детализацию.

Все файлы следует защитить от пользователей, кроме \netflow\index.php, например через .htaccess

Немного лирики или о том, как работает мое приложение


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

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

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

Для удобства отображения данных были использованы CSS и jQuery скрипты.

В начале разработки мне пришлось встретиться с несколькими глобальными проблемами:
  • 1) Какой NetFlow трафик считать?
  • 2) Как считать трафик и как его учитывать в базе MySQL?
  • 3) Как учитывать статистику TOP-20?
  • 4) Как получить более детализированную статистику?

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

На второй вопрос также ответил в начале этой статьи. Единственное, что пришлось сделать, это оптимизировать сбор данных таким образом, чтобы база не раздувалась до огромных размеров. Поэтому в базе присутствует одна единственная таблица NetFlowData, в которой хранятся все логи за последние 2 дня. Данная таблица легко может прибавить порядка 100 мегабайт в сутки. Поэтому у себя использую эту таблицу для DEBUG'а. Все остальные таблицы оптимизированы при помощи группировки данных.

Перед тем как ответить на 3ий вопрос, скажу, что в TOP-20 собирается только INTERNET трафик, и в него не включаются подсети типа ANY-to-LAN, ANY-to-DMZ, ANY-to-VPN, LOCAL-to-WAN. Долго не мог решить проблему с учетом TOP-20, так как таблица в базе раздувается до больших размеров, порядка 100 тысяч записей каждые 10 минут. В итоге за сутки размер таблицы легко прибавляет на 50 мегабайт. Оптимизировать получилось только одним способом, это собрать полную статистику за сутки, а дальше сгруппировать данные таким образом, где сумма UPLOAD или DOWNLOAD больше 1 мегабайта. Таким образом количество записей в таблице резко упало до нескольких тысяч строк. Даже, если какой-либо трафик не будет учитываться, то TOP-20 все-равно будет адекватно отображать статистику с минимальной погрешностью.

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

И напоследок, привожу несколько скриншотов моего приложения: user.jpg, admin.jpg, top20.jpg, networks.jpg

Всем спасибо за внимание, пользуйтесь на здоровье!
  • +6
  • 26.2k
  • 4
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 4

    0
    > таблица в базе раздувается до больших размеров
    да неужели?
    image
    вот поэтому netflow в sql базах хранят только камикадзе. даю наводку — утилите flow-report из этого набора можно оды писать, настолько она хороша. например, сделать отчёт топ10 из любого объёма netflow данных, использовав во время работы не более 30-40 мегабайт оперативной памяти.
      0
      Когда начинал реализацию данной затеи 3 месяца назад, то не нашел толковых статей про утилиту flow-tools и не нашел ни одной статьи о том, какие типы пакетов есть у NetFlow и как по ним вести учет трафика. Поэтому не смогу сейчас что-либо прокомментировать в работе утилиты flow-tools. О логике учета трафика, используя NetFlow, просто нигде не было ни слова. Везде написано только одно, что приходят пакеты с определенным направлением трафика и его количеством байт, а дальше разбирайтесь сами, либо используйте платный софт, например ManageEngine. Меня такая позиция не устроила в корне и я решил разобраться с учетом трафика, понять логику учета с использованием NetFlow, и по-возможности, и учесть весь "реальный" трафик до байта, тот который идет от всех ваших WAN хостов через шлюз провайдера, исключив при этом полностью локальный трафик, о котором говорил в своей статье.

      Теперь о одах, если вы прекрасно понимаете как использовать flow-tools, то может напишете полную и исчерпывающую статью о том, как вести автоматизированный учет трафика, используя эту утилиту? В своей статье я показал, как использовать утилиту "nfdump" и показал как можно полностью автоматизировать учет трафика в компании, используя понимание логики пакетов NetFlow.

      Что касается больших размеров таблиц в MySQL, используя полный дамп NetFlow. С вами полностью согласен, что это путь камикадзе, но это было всего лирическое отступление в статье, где дальше говорилось об оптимизации такого трафика средствами группировки данных.
      0
      > может напишете полную и исчерпывающую статью
      зачем мне пересказывать man flow-tools и раздел «see also» из него? потешить самомнение я могу и другими способами :)

      программное обеспечение надо изучать с использованием родной документации, а не по чужим how-to, которые очень часто написаны людьми, недостаточно разбирающимися в вопросе.
        0
        Насколько я помню, flow-tools не умеет netflow v9

      Only users with full accounts can post comments. Log in, please.