Нестандартный подход к классическим задачам может привести к рождению инновационной идеи. Привычный инструмент (например, снифер), который позволяет нам решать какую-либо задачу (анализ трафика), при взгляде на него с другой позиции дает шанс разработчику получить на выходе нечто принципиально новое. Рассмотрим формулу «снифер+распределение» и докажем, что ее результат – не просто «распределенный снифер».

Ниша сетевых анализаторов плотно занята продуктами с самым разнообразным функционалом и вряд ли очередной самодельный снифер будет выделяться своей оригинальностью. Среди бесплатных аналогов, пожалуй, флагманом является мультиплатформенный Wireshark: продвинутые фильтры по протоколам, гибкие средства автоматизации анализа протоколов и восстановления TCP-потоков, средства фильтрации и поиска пакетов по множеству параметров и формирования статистических данных и прочие функции делают этот сетевой анализатор на голову выше своих бесплатных конкурентов. Среди платных ему не уступает, а в ряде случаев и превосходит его платный продукт CommView.

Выбор конкретного инструмента, прежде всего, зависит от задачи, которая с его помощью решается. Wireshark для обеспечения своей работоспособности использует библиотеку PCAP (Packet Capture), что в ряде случаев может не дать нужного результата. Например, при изучении сетевой активности вредоносного программного обеспечения, установленного в систему на уровне драйвера. В данном случае на помощь исследователю может прийти CommView, который устанавливает в систему собственный NDIS-драйвер, что позволяет ему работать с пакетами на самом низком уровне.

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

 

Конвертация мысли в инновацию

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

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

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

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

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

 

Распределение + снифер = ?

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

Во-первых, все зависит от того, какой сетевой анализатор трафика будет распределяться:

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

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

Во-вторых, что понимать под распределением, ведь здесь формально отсутствует какая-либо трудоемкая задача, и нет никакой параллельной вычислительной системы? Если смотреть реальности в глаза, то сам по себе сетевой анализатор, компоненты-сенсоры которого исследуют разные и даже независимые друг от друга части сети, является распределенной системой.

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

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

 

Анализируй это

К распределению сетевого анализатора будем подходить с точки зрения спектра технологий Windows Communication Foundation (детальный обзор WCF ты можешь найти в позапрошлом выпуске журнала в статье «WTF WCF?! Windows Communication Foundation: искусство скоростного создания сложных транзакционных систем»), которые любезно предоставляет .NET Framework. По этой причине после непродолжительных поисков в Сети у меня на руках оказались исходные коды простого снифера, написанного на C#.
Чтобы понять, с какой стороны подойти к наращиванию нужного нам функционала, необходимо в общих чертах ознакомиться с устройством «подопытного» приложения.

Имеющийся в наличии снифер разбирает пакеты наиболее распространенных протоколов:

  • TCP;
  • UDP;
  • IP;
  • DNS.

Напомню, что протоколы типа HTTP, SMTP, FTP и прочие инкапсулируются в TCP, который, в свою очередь, инкапсулируется в IP, поэтому, если у тебя вдруг появится желание «допилить» имеющийся снифер, рекомендую начать с парсинга популярных высокоуровневых сетевых протоколов.

Процесс перехвата пакетов осуществляется с помощью так называемого сырого сокета (raw socket), то есть манипулирует пакетами непосредственно на уровне их «конструирования». Сокет привязывается к IP-адресу, затем вызывается метод IOControl со специальным кодом управления «ReceiveAll», который указывает сокету на то, что все входящие и исходящие пакеты должны быть перехвачены.

 

Организация процесса перехвата сетевых пакетов

//создание raw-сокета
mainSocket = new Socket( AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.IP);
//привязка созданного сокета к выбранному IP-адресу
mainSocket.Bind(newIPEndPoint(IPAddress.Parse(cmbInterfaces.Text),0));
/включение IP-заголовка в данные и перевод сокета в режим приема всех пакетов/
mainSocket.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.HeaderIncluded, true);
mainSocket.IOControl(
IOControlCode.ReceiveAll,
byTrue, //входные данные, необходимые для операции
byOut);//выходные данные, возвращенные операцией
//непосредственно асинхронный перехват пакетов
mainSocket.BeginReceive(byteData, 0, byteData.Length, SocketFlags.None, newAsyncCallback(OnReceive), null);

Процедуры парсинга заголовков протоколов описаны в соответствующих классах: IPHeader, DNSHeader, TCPHeader. В качестве примера рассмотрим структуру класса IPHeader.

 

Структура класса IPHeader

public classIPHeader
{
/список членов, каждый из которых отвечает за конкретное поле заголовка IP-пакета/
…
/конструктор класса, в качестве параметров использует массив принятых байтов/
public IPHeader(byte[] byBuffer, int nReceived)
{
…
}
}

Аналогичным образом происходит разбор заголовков TCP и UDP: их содержимое читается с той позиции, в который заканчивается содержимое IP-заголовка. Разобравшись со структурой одного из предоставленных классов, можно написать парсер какого-либо специфичного протокола, имея на руках устройство его заголовка (как правило, описывается в спецификации протокола – документ RFC).

Добавляя новые декодировщики протоколов, можно составить конкуренцию большинству имеющихся решений. Наращиванием функционала программы в виде плагинов (соответственно, после проектирования интерфейса их подключения) обеспечивается ее расширяемость и гибкость, а там уже и пользовательский интерфейс в виде плагина не за горами…

 

Распределяй и властвуй

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

Определяем область имплантирования. Для этого найдем место, где собранные данные фиксируются и отправляются на вывод в пользовательский интерфейс:

/вспомогательная функция, которая возвращает информацию, содержащуюся в заголовке IP-пакета/
private TreeNode MakeIPTreeNode(IPHeader ipHeader)
{
//инициализация узла – записи в общем дереве
TreeNode ipNode = new TreeNode();
//формирование записи
…
return ipNode;
}

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

AddTreeNode addTreeNode = new AddTreeNode(OnAddTreeNode);

Именно в это место производим вставку «имплантанта» в виде распределяющего кода. Для этого нам потребует вспомнить архитектуру клиент-серверного приложения на основе технологии .NET Remoting. Сэмпл простейшей «распределенки» ищи на диске – именно его мы сейчас соответствующим образом адаптируем к нашему сниферу.

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

/создание и регистрация клиентского канала с помощью конфигурационного файла/
RemotingConfiguration.Configure("Client.exe.txt");
//создание объекта удаленного класса
Test test = new Test();
//обновление общего спула логов
test.SendLog(rootNode);

В свою очередь, метод удаленного класса SendLog() должен добавлять к содержимому общего отчета, находящегося на стороне сервера, данные типа rootNode. Для наглядности примера предположим, что общий отчет хранится в строковой переменной Result, тогда обновление отчета происходит следующим образом:

public void SendLog(string SensorLog)
{
//добавления лога сенсора в общий отчет
Result = Result + SensorLog;
}

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

//вывод отчета на стороне сервера
test.Show()

Здесь Show() – метод удаленного класса, который осуществляет вывод переменной Result в удобочитаемой форме.

Метод Show() представляет собой некую абстракцию: он может быть банальным выводом результата в консоль сервера с помощью пары инструкций, может являться выводом в специфичное хранилище логов (например, база данных) из которого впоследствии формируется вывод данных, отсортированных строго по определенным критериям и предоставленный пользователям твоего веб-сервиса.

 

Есть идея? Значит, делай!

До реализации полноценного инновационного (Денис, сколько можно употреблять это слово, по-моему, тебя перекупила партия власти 🙂 - прим.ред.) продукта предстоит осуществить еще несколько шагов: написать полнофункциональный и конкурентноспособный сетевой анализатор трафика, распределить его в соответствии с тем подходом, который описан в статье, реализовать в виде онлайн-сервиса удобную серверную часть, которая в реальном времени обрабатывает непрерывный поток отчетов с сенсоров и представляет статистику пакетов в надлежащем виде. Однако, уже имея за спиной нестандартную мысль, воплощенную в оригинальную и яркую идею, любые шаги к инновации меркнут на фоне ожидаемых результатов. Как гласит слоган одной крупной компании: "Просто возьми и сделай!".

 

WWW

 

DVD

На диске находятся исходные коды подопытного снифера и сэмпл простейшего приложения на основе .NET Remoting.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии