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