kornix Apr 5 2016 at 14:43

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

4 min

17K

Перед любым системным администратором рано или поздно возникает задача количественного анализа трафика (откуда / куда, по каким протоколам / портам, в каких объемах и т. п.), проходящего по его сети. Особенно неприятно, когда эта задача возникает спонтанно, как побочный результат 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, но он, все-таки, ориентирован под «стационарное» использование, поскольку подразумевает использование коллектора данных, с которым и взаимодействует клиентская часть.

Ссылки:

PCAParse — github.com/kornix/pcaparse ;
Fastnetmon — n0where.net/high-performance-dos-analyzer-fastnetmon ;
DDS — gul-tech.livejournal.com/5959.html ;
NFDUMP — nfdump.sourceforge.net ;
NfSen — nfsen.sourceforge.net

Tags:

Hubs:

Perl