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