Швидкий аналіз транзитного трафіку

Перед будь-яким системним адміністратором рано чи пізно постає завдання кількісного аналізу трафіку (звідки / куди, за якими протоколами / портів, у яких обсягах тощо), що проходить по його мережі. Особливо неприємно, коли ця задача виникає спонтанно, як побічний результат 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 seconds 4.90
Matched: 100 samples / 104.21 kB
tcp: 20 samples / 2.04 kB
udp: 76 samples / 101.79 kB
icmp: 4 samples / 392B
other: 0 samples / 0B

Samples Summary Average
Destination count size size
212.XX.XXX.XX 86 102.43 kB 1.19 kB
tcp: 10 660B 66B
udp: 76 101.79 kB 1.34 kB
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.65 MB
Parsed: 280692 samples in seconds 27.58
Matched: 4383 samples / 3.75 MB
tcp: 4 samples / 513B
udp: 4378 samples / 3.75 MB
icmp: 0 samples / 0B
other: 0 samples / 0B

Samples Summary Average
Destination count size size
212.XX.XX.XX 4.38 k 3.75 MB 897B
tcp: 4 513B 128B
80 (http) 4 513B 128B
udp: 4378 3.75 MB 898B
7 (echo) 2819 2.82 MB 1.02 kB
3389 (ms-wbt-server) 659 670.15 kB 1.02 kB
5538 273 86.15 kB 323B
9584 87 24.62 kB 290B
18002 92 26.55 kB 295B
27186 167 55.68 kB 341B
32302 279 89.50 kB 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, але він, все-таки, орієнтований під «стаціонарне» використання, оскільки передбачає використання колектора даних, з якими взаємодіє клієнтська частина.

Посилання:


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.