Быстрый анализ транзитного трафика

Перед любым системным администратором рано или поздно возникает задача количественного анализа трафика (откуда / куда, по каким протоколам / портам, в каких объемах и т. п.), проходящего по его сети. Особенно неприятно, когда эта задача возникает спонтанно, как побочный результат DDoS-а, а денег на серьезные решения от Cisco или Arbor, как обычно, нет. И хорошо еще, если шлюзом для сети выступает сервер, на котором можно запустить tcpdump или wireshark, но что делать если:

  • шлюзом выступает устройство провайдера, а в сети есть только файл-сервер;
  • данные о трафике нужны не постоянно, а от времени к времени;
  • устройство не поддерживает возможность запуска на нем сторонних программ;
  • трафика столько, что сервер после запуска tcpdump-а «клеит ласты»;
  • или наоборот, настолько мало, что его уровень сравним с долей (хотя и значительной) обычного трафика?

Дополнительную ложку дегтя в эту «бочку меда» задачи добавляет еще и отсутствие как у tcpdump, так и у tshark чудесного ключа «сгруппировать, просуммировать / усреднить и отсортировать».

Так что, при всем нежелании изобретать велосипед, пришлось закатить рукава и написать инструмент, удовлетворяющий следующим требованиям:

  • источником данных выступает маршрутизатор или коммутатор, поддерживающий протокол sFlow;
  • коллектор (tcpdump, tshark или sflowtool) данные в формате PCAP либо пишет в файл, либо передает на STDOUT;
  • соответсвтенно, исходные данные могут быть вычитаны инструментом либо из файла, либо с STDIN-а;
  • базовой единицей для анализа является пакет, а не соединение;
  • результат должен включать информацию о направлении трафика, количестве прошедших пакетов, объеме трафика и среднем размере пакета;
  • должна быть предусмотрена возможность базовой группировки и сортировки результата;
  • ну и разные попутные мелочи;
  • и при всем этом этот инструмент не должен дублировать функционал существующих общеизвестных инструментов.

Вот исходя из этого и был написан PCAParse — максимально простой инструмент для получения обобощенной информации о проходящем по сети трафике. Для его использования, в простейшем случае, достаточно коммутатора типа D-Link DGS-3XXX или аналога других производителей и запущенного на вышеупомянутом файл-сервере sflowtool либо tcpdump-а на офисном шлюзе. Как показывает практика, эти устройства давным давно утратили статус экзотических и встретить их можно даже в небольших офисах.

Для того, чтобы было понятно, о чем идет речь, приведу небольшой пример:

Пример вывода скрипта
$ tshark -c 100 -w - | pcaparse
Filename:                   -
File size:                  -
Parsed:                     100 samples in 4.90 seconds
Matched:                    100 samples / 104.21kB
  tcp:                      20 samples / 2.04kB
  udp:                      76 samples / 101.79kB
  icmp:                     4 samples / 392B
  other:                    0 samples / 0B

                            Samples    Summary    Average
Destination                   count       size       size
212.XX.XXX.XX                    86   102.43kB     1.19kB
  tcp:                           10       660B        66B
  udp:                           76   101.79kB     1.34kB
  icmp:                           0         0B         0B
  other:                          0         0B         0B
212.XX.XXX.XX                     5       550B       110B
212.XX.XXX.XX                     5       878B       176B
212.XX.XXX.XXX                    4       392B        98B


Разумеется, сразу же бросается в глаза несуразное время работы, но на самом деле это — результат tshark-а, а не скрипта. Реальная его производительность на AMD A8-6600K @ 3,9 ГГц / 8 ГБ RAM составляет 15-25 килопакетов/с в зависимости от источника данных (чтение из файла, sFlow и т. д.).

Более требовательные пользователи могут затребовать более развернутую информацию:

Развернутый пример вывода скрипта
$ tcpdump -w - | pcaparse -f - -d 212.XX.XX.XX
Filename:                   -
File size:                  32.65MB
Parsed:                     280692 samples in 27.58 seconds
Matched:                    4383 samples / 3.75MB
  tcp:                      4 samples / 513B
  udp:                      4378 samples / 3.75MB
  icmp:                     0 samples / 0B
  other:                    0 samples / 0B

                            Samples    Summary    Average
Destination                   count       size       size
212.XX.XX.XX                  4.38k     3.75MB       897B
  tcp:                            4       513B       128B
    80 (http)                     4       513B       128B
  udp:                         4378     3.75MB       898B
    7 (echo)                   2819     2.82MB     1.02kB
    3389 (ms-wbt-server)        659   670.15kB     1.02kB
    5538                        273    86.15kB       323B
    9584                         87    24.62kB       290B
    18002                        92    26.55kB       295B
    27186                       167    55.68kB       341B
    32302                       279    89.50kB       328B
  icmp:                           0         0B         0B
  other:                          0         0B         0B


Если принять во внимание, что дамп для примера взят для обычного web-сервера, эта информация позволяет судить о наличии атаки DoS / DDoS по udp:* на ресурс. Ну, а это знание, позволяет уже принять какие-то адекватные меры. Для удобства дальнейшей обработки данных предусмотрен parser-friendly вывод:

Parser-friendly вывод
$ pcaparse -f tcpdump-212-XX-XX-XX -d 212.XX.XX.XX -p
212.XX.XX.XX    total                   4382      3931684        897
212.XX.XX.XX    tcp                        4          513        128
212.XX.XX.XX    tcp:80                     4          513        128
212.XX.XX.XX    udp                     4378      3931171        897
212.XX.XX.XX    udp:7                   2819      2955528       1048
212.XX.XX.XX    udp:3389                 659       686237       1041
212.XX.XX.XX    udp:5538                 273        88222        323
212.XX.XX.XX    udp:9584                  87        25208        289
212.XX.XX.XX    udp:18002                 92        27185        295
212.XX.XX.XX    udp:27186                167        57019        341
212.XX.XX.XX    udp:32302                279        91644        328
212.XX.XX.XX    icmp                       0            0          0
212.XX.XX.XX    other                      0            0          0

Скрипт написан на perl-е с использованием модулей Net::PCAP и NetPacket::*, что обеспечивает достаточную производительность и кроссплатформенность. По крайней мере, на свежих linux-ах и FreeBSD проблем с запуском и работой не возникало.

Из известных минусов:

  • отсутствие поддержки IPv6 (надеюсь, пока — над этим ведется работа);
  • проверка диапазонов IP-адресов с использованием Data::Validate::IP (опять же, надеюсь, временно);
  • отсутствие опции «сделать хорошо» у tcpdump или tshark (но, надеюсь, в будущем она может там появиться, если скрипт понравится авторам и контрибьюторам упомянутых инструментов и его функционал будет туда спортирован).

P.S. постфактум оказалось, что существует аналогичный инструмент — Fastnetmon, но он, все-таки, ориентирован под «стационарное» использование, поскольку подразумевает использование коллектора данных, с которым и взаимодействует клиентская часть.

Ссылки:

Similar posts

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

More

Comments 21

    0
    Буквально только что думал о том, что хочу sampled pcap, ваш вариант очень близок.
      0
      Ну что ж, могу сделать вывод, что раз хотелось аналогичного, значит какая-то перспектива у проекта светится…
      +1
      Давно хожу вокруг, да около fastnetmon, всё руки никак не дойдут потестить плотно. Кто-нибудь может описать опыт работы с ним?
        +1
        В общем и целом работает. Из весьма полезных фич — прием данных по NetFlow, с mirror-портов и «родная» сигнализация на тему DoS/DDoS. Поскольку тоже perl-овый и подерживает плагины, весьма просто допилить под свои нужды, хотя, конечно, он потолще одного скрипта получается.
          0
          Почему perl-овый? fastnetmon написан на C++. Или я вас неправильно понял?
          github.com/pavel-odintsov/fastnetmon/tree/master/src
            0
            Да нет, все правильно. Крутил с пол-года тому, запамятовал. Посыпаю голову пеплом.
              0
              Ага, FNM на плюсах писан, полноценные плагины к нему только на С++ получится писать, но есть поддержка lua — для фильтров sflow / netflow (ну, скажем, отсечь заданные интерфейсы или размеры пакетов или что-то более сложное) :)
          +1
          У нас уже больше года отлично работает.
          PCAP — далеко не лучший выбор при большом количестве PPS.
          Мы зеркалируем трафик на машину с Linux, на которой модуль ядра ipt_netflow считает трафик, и передаёт статистику для fastnetmon в формате NetFlow.
            0
            Большое количество — это сколько? При прочих равных sFlow на несколько порядков менее прожорлив, а потрафиковых тарифов я уже и не упомню, чтобы нужно было туда-сюда с точностью до байта считать.
              +1
              Когда счёт идёт на сотни тысяч PPS.

              Вот в чём дело:
              «Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

              Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

              Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.»

              habrahabr.ru/post/261161
                +1
                Фишка в том, чтобы пакеты обрабатывались еще на уровне ядра, а не в user space, как это происходит в случае с PCAP.
                  0
                  IMHO NetFlow обладает слишком большим оверхедом для задач оценки трафика. Для оценки достаточно объема информации, предоставляемой sFlow / jFlow. Количество пакетов, требующих обработки, в этом случае получается кардинально меньшим, нежели в схеме mirror/SPAN + linux box с ipt_netflow + коллектор. Схема сети получается более гибкая, по сравнению с mirror/SPAN, поскольку коллектор никак не привязывается к конкретному коммутатору. Да и в bottleneck SPAN-интерфейса мы никак не упираемся. И в производительность процессора для разбора PCAP.

                  КМК, для каждой задачи — свой инструмент. И, опять же, КМК, для оценки профиля трафика, NetFlow — не лучший выбор.
                    0
                    Если аппаратура сама умеет считать и отправлять куда нужно статистику, то конечно же всё будет хорошо.
                    Я про подсчёт сырого трафика средствами PCAP.
                    Вы ведь писали: «или tcpdump-а на офисном шлюзе».
                    Для малого офиса прокатит, а вот для большой сети вряд ли.
                    Также вангую, что если малый офис подвергнется DDoS атаке типа NTP amplification, то шлюз с запущенным tcpdump сразу склеит ласты.
                    Также, при определённых условиях любой из сотрудников малого офиса может положить торрентом шлюз с запущенным tcpdump.
                      +1
                      Кстати, да, я больше люблю sflow v5 :) Но хорошего агента к нему для линукса нету (бесплатного), только коммерческие реализации. sflow хорош тем, что дает payload пакета и это дает очень большой простой для анализа, что же там внутри. Кроме этого, у него нету задержки (и аггрегации).

                      Хотя недавно мелькала тема, что можно сделать так, чтобы в NetFlow укладывались сэмплы (куски) пакетов, но как конкретно такое сделать на джуниере / циске — не особо ясно.

                      Если кто-то исследует вопрос — замутим такое дело в FNM ;)
            0
            Есть еще один прекрасный проект на эту тему: http://gul-tech.livejournal.com/5959.html
              0
              Не уверен, что Паша его еще поддерживает.
                0
                он просто работает :)
              0
              Совсем недавно столкнулись с подобным.
              Получили DDOS порядка 1,5Гбит/с (550k pps). Шлюз (Linux) колом становился. Запустить что-то для анализа на нем было нереально.
              Пришлось пропустить аплинки через D-Link DGS***, включить на нем sFlow. Сбор и анализ при помощи nfsen (благо уже был развернут).
              В результате, при очередной атаке сразу получили все нужные данные. Ну и попросили вышестоящего провайдера заблокировать.
              )) Убедились, что анализировать трафик на аплинках необходимо.

              ИМХО. Nfsen — вполне достаточный для подобных задач инструмент. Ну и точность sFlow достаточна для оценки трафика. Плюс к этому можно настроить всевозможные алармы на почту. К тому-же самодостаточный — включает в себя и коллектор, и анализатор, и веб-морду.
              Думаю, NetFlow для подобного будет сильно избыточный.
                0
                А чем не устроил nfsen собранный с поддержкой sflow? Ну в вашем решении не вижу прикручивания к стороннему мониторингу, а nfdump+nfsen уже имеют простенькую морду и просто гору плагинов по анализу проходящего трафика, включая определение простых ДДоС как по конкретным атакующим хостам так и по геораспределенности. Ну и простенький генератор алярм в комплекте, как раз подходит для эпизодического использования.
                  0
                  Кто сказал, что не устроил? Просто ниша моего решения несколько другая — хотелось консольное приложение, которое бы позволило быстро получить обощенную информацию либо по уже существующему PCAP-файлу, который собран чем-то другим (типа sflowtools — путем скармливания файла с данными непосредственно приложению), либо аналогично быстро обобщить данные того же tcpdump-а (e. g. tcpdump -n -c 1000 -i eth0 -w — | сумматор). Честно говоря, меня бы гораздо больше устроило, если бы у tcpdump-а появилась фича выдачи обобщенной информации — тогда бы мне не пришлось ничего писать :)

                  Я в самой статье этот момент, к сожалению, упустил — хотелось именно а) консольное, б) заточенное под максимально распространенный и поддерживаемый коллекторами формат данных и в) без лишних свистелок. Так, чтобы можно было зайти на сервер с мобильного устройства в консоль 80x25 и получить необходимые данные.

                  Впредь буду формулировать мысли аккуратнее.
                    0
                    Исчерпывающе, в таком формате — согласен просто и удобно.

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