Анализ трафика · 6 min read · Dec 14, 2025

Анализ трафика с использованием Debian Lenny

Анализ трафика с использованием Debian Lenny

Используя мое устройство для мониторинга сети, мы заметили, что одна из линий в MRTG всегда находится под высокой нагрузкой. На этой линии агрегируется много различного трафика, поэтому мы решили проанализировать, из каких количеств протоколов и, следовательно, приложений состоит совокупный трафик.

Как вы можете легко увидеть, трафика много в каждый день, кроме выходных и праздников.

Одним из OSS приложений, которое может это сделать, является ntop. Отрывок с www.ntop.org:

"ntop — это зонд сетевого трафика, который показывает использование сети, аналогично тому, как это делает популярная команда top в Unix. ntop основан на libpcap и написан в переносимом виде, чтобы фактически работать на каждой платформе Unix и на Win32. Пользователи ntop могут использовать веб-браузер (например, netscape), чтобы просматривать информацию о трафике ntop (который действует как веб-сервер) и получать дамп состояния сети. В последнем случае ntop можно рассматривать как простой агент, подобный RMON, с встроенным веб-интерфейсом."

Предварительные сведения и отказ от ответственности

Пожалуйста, имейте в виду, что юридические права в некоторых странах могут запрещать выполнение действий, подобных тем, что упоминаются в этой статье, и вы не должны нарушать юридические права. Также имейте в виду, что следующий рецепт описывает способ, которым мы реализовали наше решение, я не даю никаких гарантий, что оно сработает для вас.

1. Линия

Линия имеет скорость 10 Мбит/с и является маршрутизирующим шлюзом между 2 сайтами, расположенными в нескольких километрах друг от друга. Краткий расчет того, сколько данных проходит по этой линии, показал, что это должно быть в диапазоне ~25 Гигабайт/день. С одной стороны линии находится примерно 2000 систем, с другой стороны около 200, и около дюжины коммуникационных связей между обеими сторонами, представляющих интерес для нас. Позже мы заметили, что около 40-50 миллионов пакетов проходит по этой линии каждый день с 7 утра до 5 вечера.

Поскольку ntop анализирует весь трафик и показывает коммуникационные связи, например, в виде топ-говорящих и подобного, мы предположили, что ntop будет использовать много оперативной памяти для построения таблиц о всех коммуникационных связях, и мы подумали, что зонд должен иметь как можно больше оперативной памяти.

2. Зонд

Мы решили использовать старый неиспользуемый компьютер, сделать минимальную установку Debian Lenny и использовать его в качестве зонда ntop. Мы сделали только минимальную установку, потому что не хотели тратить драгоценную оперативную память на X11 или другие бесполезные приложения, бесполезные для этого случая. Мы решили использовать Debian, потому что он легко адаптируется к нашим потребностям и известен своей стабильностью. Но вы можете построить зонд, как описано здесь, с любой другой дистрибуцией Linux, с которой вы знакомы, также *BSD могут быть хорошей основой.

Мы решили разместить этот зонд рядом с маршрутизатором, который обрабатывает эту линию, и настроить зеркальный порт, чтобы получить доступ ко всему трафику, проходящему по этой линии.

Мы оснастили зонд второй сетевой картой, потому что нам нужна одна сетевая карта для захвата трафика и мы хотели иметь возможность удаленно администрировать зонд по SSH. Первая сетевая карта (eth0) была настроена без IP-адреса, потому что она используется только для захвата трафика с зеркального порта маршрутизатора и не для какой-либо активной связи. Кроме того, eth0 должна быть переведена в режим прослушивания (чтобы видеть весь трафик), что выполняется с помощью libpcap. Вторая сетевая карта (eth1), которая используется только для удаленного администрирования, была настроена с фиксированным IP-адресом.

К счастью, старый компьютер, который использовался в качестве зонда, был оснащен 2 ГБ оперативной памяти (что было достаточно), процессором AMD Athlon(tm) 64 Processor 3800+ и локальным диском на 80 ГБ. Диск был разделен следующим образом:

# fdisk -l
Диск /dev/sda: 80.0 GB, 80026361856 байт  
255 голов, 63 секторов/дорожка, 9729 цилиндров  
Единицы = цилиндры по 16065 * 512 = 8225280 байт  
Идентификатор диска: 0x37aa37aa  
  
   Устройство Загрузка      Начало         Конец      Блоки   Id  Система  
/dev/sda1               1         131     1052226   83  Linux  
/dev/sda2              132         162      249007+  82  Linux swap / Solaris  
/dev/sda3              163        9729    76846927+   5  Расширенный  
/dev/sda5              163        9729    76846896   83  Linux

/dev/sda1 — это раздел на 1 ГБ для Lenny, /dev/sda2 — небольшой раздел подкачки, а /dev/sda5 будет использоваться для файлов захвата. Файловые системы — ext3, но xfs также может быть хорошим кандидатом для таких больших файлов.

3. Оффлайн-отчетность

ntop способен анализировать трафик в реальном времени или также может читать pcap-файлы для последующего анализа и отчетности.

Мы решили сначала использовать оффлайн-метод, чтобы захватывать трафик на линии с помощью tcpdump с 7 утра до 5 вечера с помощью короткого шелл-скрипта, управляемого cron, и провести анализ на втором этапе.

Шелл-скрипт выглядит как Sys-V initscript:

#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin

do_start() {
        ifconfig eth0 up;
        tcpdump -i eth0 -w /media/capture/`date +%F_%R`_tcpdump.pcap &
}

do_stop() {
        pkill -SIGTERM tcpdump;
        ifconfig eth0 down;
}


case "$1" in
    start)
        do_start 2>&1
        ;;
    stop)
        do_stop
        ;;
    *)
        echo "Использование: $0 start|stop" >&2
        exit 3
        ;;
esac

Захват трафика с 7 утра до 5 вечера производит файлы размером ~30 ГБ:

-rw-r--r-- 1 root root 32725662515 Янв 14 17:00 2020-01-14_07:00_tcpdump.pcap

Чтение файла захвата выполняется с помощью

ntop -m 10.80.192.0/18,10.81.20.0/24 -f /media/capture/2010-01-13_10\:30_tcpdump.pcap -n -4 -w3000 --w3c -p /etc/ntop/protocol.list

Для подробного объяснения параметров командной строки ntop, пожалуйста, обратитесь к его справочной странице и настройте их в соответствии с вашими потребностями.

Вы можете затем просмотреть отчет ntop в веб-браузере на порту 3000 системы, где работает ntop.

4. Онлайн-отчетность

Еще одна возможность использования ntop заключается в том, что ntop сам захватывает трафик на eth0 и делает онлайн-отчет в реальном времени, так что вы можете видеть, что происходит через несколько секунд, и (с активированным плагином rrd) получать действительно красивые, удивительные (дружественные к управлению!) графики, где вы можете увеличивать масштаб с помощью мыши.

5. Первые выводы

Как и ожидалось, мы увидели, что примерно 70% всего трафика вызвано одной системой, интернет-прокси. Трафик, связанный с продуктивными приложениями, составил около 3-5%. Чтобы усугубить ситуацию, этот продуктивный трафик связан с интерактивными приложениями, такими как Citrix, Telnet и SAP. Мы решили, что следующим шагом должно быть приоритизирование/формирование трафика с помощью (например) diffserv или TOS mangling.

6. ngrep

Теперь мы решили проанализировать трафик, связанный с прокси, какие веб-сайты будут самыми посещаемыми. Такой более глубокий анализ невозможен с помощью ntop, но с помощью ngrep легко захватить только трафик, который (например) идет к одной системе или приходит/уходит к одному порту, или гораздо больше. Ngrep также способен искать выражения в полезной нагрузке, поэтому следующим шагом было использовать ngrep для захвата только трафика, связанного с интернет-прокси, и дальнейшего его анализа.

Это просто делается с помощью

ngrep -d eth0 host 10.89.1.17 -O /media/capture/snap.pcap

Не нужно говорить, что этот простой способ захвата также можно выполнить с помощью tcpdump.

Когда это делается с 7 утра до 5 вечера, это может произвести файл размером ~14 ГБ:

-rw-r--r-- 1 root root 14223354675 Янв 25 16:26 snap.pcap

Теперь этот файл должен быть проанализирован. Идея заключается в том, чтобы

  • прочитать файл с помощью tcpdump, вывести его на stdout,

  • grep для “get http://“,

  • вырезать FQDN сайтов,

  • выбросить дублированные записи, которые находятся в коротких сериях (потому что они могут принадлежать одному клику в браузере, что приводит к строке последовательных get),

  • и подсчитать и отсортировать эти данные в соответствии с их частотой.

Это можно сделать в нескольких шагах, используя промежуточные файлы, или одной командой, где несколько инструментов командной строки соединены вместе:

tcpdump -r snap.pcap -A | grep -i "get http://" | awk '/http/ { print $2 }' | cut -d/ -f1-3 | grep http | sed '$!N; /^\(.*
\
\\1$/!P; D' | sort | uniq -c | sort -r > urls.txt

Это выполняется некоторое время, и вы получаете файл, отсортированный в порядке убывания, как часто сайты, найденные в файле захвата, посещаются. Я не на 100% уверен, что все наши предположения, сделанные выше, обработаны правильно, но цифры в файле выглядят правдоподобно.

  13418 http://www.gxxxxx.dx
  10184 http://www.gxxxxx-axxxxxxxx.cxx
   8281 http://www.fxxxxxxx.dx
   5470 http://www.bxxx.dx
   4269 http://www.sxxxxxx.dx
   2550 http://www.gxxx.cxx
   2047 http://www.bxxxxxxx-zxxxxxx.dx
   2044 http://www.fxxxxxxx.cxx
   1618 http://www.exxxxxxx.dx
   1410 http://www.lx-bx.dx
   ....

Другой способ получить отчет о посещенных веб-сайтах — это интерпретировать журнал интернет-прокси, возможно, с помощью Calamaris (в случае Squid или прокси, который производит журналы, обрабатываемые Calamaris). Без журнала прокси я не знаю, как такой отчет можно было бы составить.

Наконец, мы настоятельно подчеркиваем, что в этом проекте не были оценены никакие пользовательские данные.

7. URL-адреса

Debian

Устройство мониторинга сети

MRTG

Ntop

tcpdump + libpcap

RRD

ngrep

Squid

Calamaris

AWK 1 Liners

SED 1 Liners

Share: X/Twitter LinkedIn
#Анализ трафика

Get new posts in your inbox

No spam. Unsubscribe anytime.