ИССЛЕДОВАНИЕ СТАТИСТИКИ ТРАФИКА

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

NETFLOW

      Часто статистика ведется по формату «netflow». Он предусматривает запись сведений о каждом «потоке» (flow), то есть серии пакетов, объединенных совокупностью IP-адресов, портов и номером протокола.
      По такой статистике можно установить:
● факт обращения определенного узла (компьютера, идентифицированного IP адресом) к другому узлу;
● время обращения с точностью до интервала дискретизации (от 5 минут до 1 часа);
● количество переданного и полученного трафика;
● протокол;
● номера портов с обеих сторон (для TCP и UDP).

ПРИМЕР

      Приведем пример, как при помощи статистики трафика можно получить ценную оперативную информацию Потерпевшим было получено сообщение электронной почты, отправленное злоумышленником через анонимайзер «remailer@aarg.net».
        Анонимайзер – это сервер электронной почты, который специально предназначен для сокрытия отправителя (подробнее об анонимайзерах – ниже, в параграфе «Анонимные ремейлеры»). Служебные заголовки сообщения не содержали никакой полезной информации. Логи анонимайзером не ведутся из принципа.
       Для вычисления отправителя можно воспользоваться статистикой трафика.
      Для начала сделаем следующие предположения: отправитель находится в России, и он отправил свое сообщение на этот анонимайзер непосредственно, а не через другой анонимайзер. При таких условиях можно попытаться вычислить отправителя.
IP-адрес анонимайзера «remailer@aarg.net» – 206.132.3.41.
       Письмо к потерпевшему пришло 20 января вечером. Значит, отправлено было, скорее всего, в этот же день, поскольку, хотя анонимайзер предусматривает задержку в доставке сообщений, но вводить слишком большую задержку бессмысленно. Будем искать в статистике российских магистральных операторов связи все обращения на IP-адрес 206.132.3.41, совершенные в течение суток 20.01.07 по протоколу SMTP. Для просмотра статистики используем набор утилит «flow tools».
      Итак, для начала, проверим, на какие IP-адреса были обращения за нужную дату по протоколу TCP, на порт 25 (SMTP). Нижеприведенная команда берёт хранящуюся на сервере статистику (flow-cat), отфильтровывает из нее протокол TCP (flow-filter -r6), отфильтровывает трафик, направленный на порт 25 (flow-filter -P 25), и агрегирует данные по IP адресу назначения (flow-stat -f8).

     В списке DST адресов (адресов назначения) мы видим интересующий нас адрес 206.132.3.41 (пятая строка снизу), причем на него зафиксировано 2 обращения (flow), всего 38 пакетов, 27995 байт. Такое небольшое количество пакетов за целые сутки неудивительно. Анонимайзерами пользуются нечасто, поскольку это хоть и относительно безопасно, но не слишком удобно.
     Выше мы запрашивали статистику за сутки. Поскольку статистика собирается с интервалом в 15 минут, поинтересуемся, в какой именно интервал времени в течение суток были зафиксированы эти обращения. Поищем их в каждом из четвертьчасовых файлов. То есть произведем поиск, аналогичный предыдущему, но не для всей суточной статистики, а для каждого из 15 минутных интервалов (команда «for f in … do»).

 

       Упоминание искомого IP-адреса нашлось в 2 из 96 файлов. Оказалось, что обращения происходили в интервале 9:30 9:45 и 14:30 14:45, причем во втором случае было передано лишь 2 пакета, а этого недостаточно для полноценной SMTP-сессии. Таким образом, все данные следует искать в файле, содержащем статистику за 9:30 9:45.

       Выберем из полной статистики за указанный интервал те пакеты, которые относятся к интересующему нас анонимайзеру. Для этого вместо упорядочивания данных по IP-адресу назначения, как в предыдущих случаях (flow-stat -f8), запросим полную статистику (flow-print) и выделим из нее утилитой «grep» те потоки, которые относятся к адресу анонимайзера 206.132.3.41.

      Мы видим, что у всех относящихся к делу пакетов один и тот же source-адрес – 81.16.118.238. Это, скорее всего, и есть IP-адрес отправителя. Переданный объем информации, 27899 байт, примерно соответствует (с учетом служебных заголовков и шифрования) длине сообщения, полученного потерпевшим, что косвенно подтверждает правильность нашего вывода.
     Вот таким образом заурядная статистика провайдера позволила нам раскрыть инкогнито злоумышленника, понадеявшегося на анонимный ремейлер.
     Другая задача, выполняемая при помощи статистики трафика, это обнаружение источника DoS-атаки или иной атаки с подделанными адресами источника (source IP). По статистике видно, из какого интерфейса пришел на маршрутизатор такой пакет, то есть каков был предыдущий узел в его пути. Обратившись к статистике этого предыдущего узла, мы можем узнать предпредыдущий узел и так далее. К сожалению, это задача непростая, придется устанавливать контакт с несколькими провайдерами. Если один из них откажется сотрудничать или не сохранит статистику, то цепочка оборвется.

ШИФРОВАННЫЙ ТРАФИК

     Некоторая часть трафика может оказаться зашифрованной. Это касается таких протоколов, как HTTPS, SSH, SMTP/TLS, IPSec и других. В некоторых случаях весь трафик между определенными узлами или сетями подвергается шифрованию – это называется VPN-туннель. Во всех протоколах, даже простейших, сейчас используются стойкие алгоритмы шифрования, дешифровать которые без знания ключа не стоит даже пытаться.
      Столкнувшись с зашифрованным трафиком, можно узнать немногое: установить сам факт сетевой активности, ее приблизительный объем, а также установить IP-адреса взаимодействующих узлов (кроме случая VPN-туннеля).
    Для решения указанной задачи следует установить, где именно производится шифрование, и перехватывать трафик в том месте, где он идет открытым.
Например, производя перехват трафика на внешнем интерфейсе «vr0» сервера доступа, мы увидели следующую картину:

 

       По контенту пакетов очевидно, что мы имеем дело с шифрованным трафиком. Это подтверждается характерным номером порта (5000), который часто используется для организации VPN-туннелей. Перехватывать такой VPN-трафик бессмысленно. Нужно перехватывать его до входа в туннель или после выхода из него. В данном случае, поскольку туннель терминируется на этом же компьютере, достаточно изменить интерфейс перехвата – вместо физического интерфейса «vr0» взять виртуальный интерфейс «tun0», соответствующий программному VPN-туннелю. То есть запустить снифер «tcpdump» с параметром «-i tun0».

 

       И мы увидим тот же трафик, но уже вне VPN-туннеля. Из шести видимых пакетов 3-й относится к протоколу NETBIOS, 4-й – к протоколу ICMP, 5-й и 6-й пакеты – к протоколу SMTP. А контент первых двух пакетов по прежнему зашифрован: эти пакеты относятся к протоколу SSH со встроенным шифрованием. Получить их в открытом виде перехватом трафика в ином месте нельзя, поскольку шифрование здесь происходит на более высоком уровне.
     Кстати, этот пример еще раз подтверждает высказанный ранее тезис, что при перехвате сетевого трафика необходимо знать сопутствующую конфигурацию оборудования. В данном примере – конфигурацию интерфейсов сервера доступа. Только благодаря знанию этой конфигурации мы определили, где следует перехватывать трафик, чтобы получить его в нешифрованном состоянии.

ОРГАНИЗАЦИЯ ПЕРЕХВАТА ТРАФИКА

      Ясно, что трафик, относящийся к определенному узлу, проще всего перехватывать вблизи этого узла. По мере удаления от него возрастает техническая сложность перехвата, но зато снижается организационная сложность. По мере удаления от узла падает надежность и, возможно, полнота перехвата трафика, но зато повышается скрытность. Место перехвата трафика в значительной мере определяется наличием возможностей у органа, ведущего ОРД. Для определения мест и методов возможного перехвата обязательно привлечение технического специалиста.
     При этом распространенной ошибкой является привлечение специалиста по аппаратуре телефонной связи. Такой специалист, конечно, доступнее, чем ИТ специалист того же уровня. «Телефонист» лучше разбирается в оборудовании, технологиях и протоколах связи 1-го и 2-го уровня (физический и канальный). Но работать на более высоких уровнях сетевых протоколов (3 7) он не способен. А как раз на этих уровнях лежит большинство возможностей перехвата трафика.
      Различных мест и методов для перехвата сетевого трафика слишком много, чтобы перечислить их здесь. Выделим лишь организационные варианты:
● перехват при помощи имеющейся аппаратуры СОРМ;
● перехват средствами оператора связи;
● перехват собственными средствами.
    В подавляющем большинстве случаев в перехватываемом трафике может содержаться тайна связи или тайна частной жизни. Поэтому необходимо получать судебное решение. Без судебной санкции возможен перехват своего собственного трафика потерпевшим либо с его письменного разрешения.
        Перехват трафика может быть реализован на разных уровнях.
● На физическом уровне:
❍ при помощи электрических и оптических разветвителей;
❍ при помощи бесконтактных датчиков;
❍ при помощи перехвата радиосигнала (для Wi-Fi и других беспроводных протоколов).
● На канальном уровне:
❍ при помощи подключения к концентратору (хабу);
❍ при помощи функции зеркалирования порта на коммутаторе (свиче);
❍ при помощи ARP-атак и проксирования трафика;
❍ при помощи установки снифера на целевом или транзитном узле.
● На сетевом уровне:
❍ при помощи изменения маршрутизации и проксирования трафика;
❍ при помощи встроенных функций межсетевого экрана или системы обнаружения атак (IDS).
● На прикладном уровне:
❍ анализом трафика на прокси-сервере (для http-трафика);
❍ анализом трафика на сервере электронной почты (для SMTP-трафика).
      Формулируя техническое задание для перехвата трафика, следует непременно прикинуть объем информации. При слишком широких условиях соответствующий трафик может достигнуть астрономических величин. Большой объем не уместится на носителе и поэтому не поддастся последующему анализу.
      Например, нас интересуют действия пользователя, работающего за домашним компьютером, который подключен к Интернету через местную домовую сеть. В его трафике мы хотели бы найти доказательства неправомерного доступа к удаленным узлам. Было бы ошибкой ставить задачу так: «перехват исходящего и входящего трафика компьютера с IP-адресом 10.0.0.6». Помимо неправомерного доступа подозреваемый также занимается и другой деятельностью. На его компьютере стоит клиент файлообменных сетей со средним суммарным трафиком 6 кбайт/с (500 Мбайт за сутки, 50 входящего и 450 исходящего). Кроме того, в домовой сети расположен файловый сервер с набором музыки и фильмов. Поскольку внутренний трафик для пользователей бесплатен и не ограничен, подозреваемый скачивает 1-2 фильма в день и немного музыки (1 Гбайт за сутки). Внутрисетевой служебный трафик составляет за сутки еще порядка 2 Мбайт. Причем все перечисленное – в автоматическом режиме, независимо от присутствия подозреваемого дома. На этом фоне суточные 10 Мбайт веб-трафика, 0,5 Мбайт электронной почты и 0,2 Мбайт по протоколу ICQ просто теряются. А доказательства неправомерного доступа содержатся лишь в последнем пункте. Перехват всего перечисленного трафика (1,5 Гбайт в сутки) за несколько дней потребует диска очень большой емкости, которого может и не оказаться в распоряжении специалиста. И потом найти в этой куче полезные 0,013% будет нелегко.
     Если же мы, чтобы исключить внутрисетевой трафик, велим специалисту перехватывать информацию за пределами домовой сети, на выходе из нее, то допустим иную ошибку. Поскольку домовая сеть подключена к Интернету не напрямую, а через устройство, осуществляющее трансляцию IP-адресов (NAT), то в этой точке мы не сможем отличить трафик подозреваемого от трафика всех других пользователей той же домовой сети.
       В описанной ситуации правильная формулировка задания должна выглядеть примерно так: «перехват исходящего и входящего трафика компьютера с MAC адресом 00:15:f2:20:96:54, относящегося к протоколам HTTP, telnet, SMTP, POP, IMAP, ICQ и имеющего в качестве IP-адреса назначения (destination) или происхождения (source) какие-либо внешние IP-адреса, то есть, IP-адреса кроме 10.0.0.0/8».
       Анализ и интерпретация перехваченного трафика должны производиться экспертом в ходе КТЭ. Вместо экспертизы можно оформить это как очередное ОРМ, но тогда доказательством в суде перехваченный трафик не будет.
    К перехваченному трафику для его анализа необходимо приложить некоторую информацию о конфигурации и состоянии коммуникационного оборудования, чтобы в ходе КТЭ содержимое трафика можно было интерпретировать уверенно, без предположений. Например, в вышеописанном случае для интерпретации понадобится конфигурация коммутатора домовой сети, MAC-таблица на соответствующем его порту, а также конфигурация устройства, производящего трансляцию адресов (NAT).

Скачать бесплатно А.А. Садердинов, В.А. Трайнев, А.А. Федулов Информационная безопасность предприятия