Нестандартный подход к задачам классическим может привести к рождению инновационной идеи. Привычный инструмент (например, сниффер), который позволяет нам решать какую-либо задачу (анализ траффика), при взгляде на него с другой позиции дает шанс разработчику получить на выходе нечто принципиально новое. Рассмотрим формулу «сниффер+распределение» и докажем, что ее результат – не просто «распределенный сниффер». Ниша сетевых анализаторов плотно занята продуктами с самым разнообразным функционалом и вряд ли очередной самодельный сниффер будет выделяться своей оригинальностью. Среди бесплатных аналогов, пожалуй, флагманом является мультиплатформенный Wireshark: продвинутые фильтры по протоколам, гибкие средства автоматизации анализа протоколов и восстановления TCP-потоков, средства фильтрации и поиска пакетов по множеству параметров и формирования статистических данных и прочие функции делают этот сетевой анализатор на голову выше своих бесплатных конкурентов. Среди платных ему не уступает, а в ряде случаев, превосходит платный продукт CommView. Выбор конкретного инструмента прежде всего зависит от задачи, которая с помощью него решается. Wireshark для обеспечения своей работоспособности использует библиотеку PCAP (Packet Capture), что в ряде случаев может не дать нужного результата. Например, при изучении сетевой активности вредоносного программного обеспечения, установленного в систему на уровне драйвера. В данном случае на помощь исследователю может прийти CommView, который устанавливает в систему собственный NDIS-драйвер, что позволяет ему работать с пакетами на самом низком уровне. Новому продукту в этой сфере трудно удержаться на плаву, когда повсеместно распространенные конкуренты обладают столь широким функционалом и постоянно обновляются. Вряд ли разработчику удастся привнести кардинальные изменения в индустрию сетевых анализаторов, если его идеи будут ограничены рамками идей других коллег. Чтобы твой продукт заметили необходимо, как минимум, со своим программным обеспечением привнести что-либо инновационное, то, что до тебя либо еще не придумали, либо не реализовали. Конвертация мысли в инновацию Нестандартные идеи и подходы рождаются с нестандартными взглядами на привычные вещи. Вдоволь наигравшись сниффером, вдоль и поперек изучив сетевую активность операционной системы, перехватив всевозможные собственные или несобственные пароли наталкиваешься на мысль, а ведь неплохо было бы, если таким же образом можно было использовать этот инструмент на хосте, находящимся в другом сегменте сети или в локальной сети, находящейся за тысячи километров, отделенной от внешнего мира маршрутизатором и доступной только через Интернет. С позиции системного администратора такая возможность удаленного сетевого анализа траффика своих серверов полностью абстрагировала бы его от их местоположения. Единожды расставив некий модуль на ключевые компьютеры в сегментах сети, которые требуют пристального наблюдения, он будет получать актуальную информацию и сможет в реальном времени проанализировать траффик, который циркулирует в этих сегментах. С точки зрения аудитора безопасности возможность удаленного мониторинга траффика позволяет значительно упростить процесс аудита, так как модули сниффера в параллельном режиме независимо друг от друга собирают все необходимые пакеты и формирую отчет на специальном сервере аудитора, что в последствии позволит ему ознакомиться с общей картиной исследуемой инфраструктуры, сетевых процессов и отследить перемещение критичной информации. В свою очередь, хакер получает оригинальный инструмент, представляющий собой подобие троянского программного обеспечения за тем исключением, что указанный модуль может быть полезной нагрузкой какого-нибудь руткита и пассивно собирать информацию о паролях к сервисам, которые использует пользователь, и прочим конфиденциальным данным. Затем формировать отчет и при первой удачной возможности отправлять его на сервис хакера, который отображает информацию в удобочитаемом виде. А может быть, злоумышленник получил доступ к одному из хостов исследуемой подсети и желает иметь представление о том, куда попал, что тут происходит и какая ценная сетевые пакеты в сегменте сети могут представлять ценность. Позиция разработчика этого программного обеспечения помимо оригинальной идеи содержит еще ряд неочевидных «полезностей», которые мы будем выявлять по мере исследования концепции распределенного сниффера. Распределение + сниффер = На выходе этой простой формулы может получиться трудно предсказуемый результат. Во-первых, все зависит от того какой сетевой анализатор траффика будет распределяться: - имеет ли он дружественный интерфейс пользователя; - на каком уровне работает с пакетами (использует библиотеку PCAP или собственный драйвер); - поддерживает ли плагины (модульная архитектура); - моно или мультиплатформенный; - количество поддерживаемых декодировщиков протоколов; - прочие возможности, от наличия которых зависит интерес пользователей к снифферу. Задача не состоит в написании конкурентноспособного сетевого анализатора трафика (в журнале неоднократно публиковались материалы о написании сниффера с использованием разных инструментов и подходов, поэтому советую поднять подшивку или ознакомиться с содержимым ссылок, приложенных к статье). По этой причине предлагаю абстрагироваться от программной составляющей снифера и сконцентрироваться на процессе его распределения, тем самым поддерживая основную идею и увеличивая значимость полученного концепта. Во-вторых, что понимать под распределением, ведь непосредственно отсутствует какая-либо трудоемкая задача и нет никакой параллельной вычислительной системы? Если смотреть реальности в глаза, сам по себе сетевой анализатор, компоненты-сенсоры которого исследуют разные и даже независимые друг от друга части сети, является распределенной системой. И, наконец, в-третьих, формирование отчета на стороне серверной части и его предоставление в удобочитаемом виде реципиенту в нашем лице также может осуществляться произвольным образом, на усмотрение программиста. Совокупность вышеперечисленных факторов позволяет разработчику системы подойти к ее проектированию с разных позиций и в разной степени акцентировать внимание на разработке той или иной части. Анализируй это К распределению сетевого анализатора будем подходить с точки зрения спектра технологий Windows Communication Foundation (детальный обзор WCF ты можешь найти в статье http://defec.ru/wtf_wcf ), которые любезно предоставляет .NET Framework. По этой причине после непродолжительных поисков в Сети у меня на руках оказались исходные коды простого сниффера, написанного на C#. Чтобы понять, с какой стороны подойти к наращиванию нужного нам функционала, необходимо в общих чертах ознакомиться с устройством «подопытного» приложения. Имеющийся в наличии сниффер разбирает пакеты наиболее распространенных протоколов: • TCP; • UDP; • IP; • DNS. Напомню, что протоколы типа HTTP, SMTP, FTP и прочие инкапсулируются в TCP, который, в свою очередь, инкапсулируется в IP, поэтому, если у тебя вдруг появится желание «допилить» имеющийся снифер, рекомендую начать с парсинга популярных высокоуровневых сетевых протоколов. Процесс перехвата пакетов осуществляется с помощью так называемого сырого сокета (raw socket), то есть манипулирует пакетами непосредственно на уровне их непосредственного «конструирования». Сокет привязывается к IP-адресу и затем вызывается метод IOControl со специальным кодом управления «ReceiveAll», который указывает сокету на то, что все входящие и исходящие пакеты должны быть перехвачены. Code: //создание 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. Code: public classIPHeader { /*список членов, каждый из которых отвечает за конкретное поле заголовка IP-пакета*/ … /*конструктор класса, в качестве параметров использует массив принятых байтов*/ public IPHeader(byte[] byBuffer, int nReceived) { … } } Аналогичным образом происходит разбор заголовков TCP и UDP: их содержимое читается с той позиции, в который заканчивается содержимое IP-заголовка. Разобравшись со структурой одного из предоставленных классов без в практически полной аналогии можно написать парсер какого-либо специфичного протокола, имея на руках устройство его заголовка (как правило, описывается в спецификации протокола – документ RFC). Добавляя новые декодировщики протоколов можно составить конкуренцию большинству имеющихся решений. Наращиванием функционала программы в виде плагинов (соответственно, после проектирования интерфейса их подключения) обеспечивается ее расширяемость и гибкость, а там уже и пользовательский интерфейс в виде плагина не за горами… Распределяй и властвуй И вот, допустим, у нас на операционном столе пациент, представляющий собой полнофункциональный сетевой анализатор трафика, который ждет хардкорного имплантирования свежей идеи в виде распределения. Определяем область имплантирования. Для этого найдем место, где собранные данные фиксируются и отправляются на вывод в пользовательский интерфейс: Code: /*вспомогательная функция, которая возвращает информацию, содержащуюся в заголовке IP-пакета*/ private TreeNode MakeIPTreeNode(IPHeader ipHeader) { //инициализация узла – записи в общем дереве TreeNode ipNode = new TreeNode(); //формирование записи … return ipNode; } Далее в пошаговом режиме исполнения приложения определяем положение инструкции вывода сформированных данных в область пользовательского интерфейса: Code: AddTreeNode addTreeNode = new AddTreeNode(OnAddTreeNode); Именно в это место производим вставку «имплантанта» в виде распределяющего кода. Для этого нам потребует вспомнить архитектуру клиент-серверного приложения на основе технологии .NET Remoting. Сэмпл простейшей «распределенки» ищи здесь – именно его мы сейчас соответствующим образом адаптируем к нашему снифферу. Так как наше исходное приложение представляет собой ничто иное, как упоминавшийся модуль-сенсор, который предназначен для сбора пакетов и их отправки в реальном времени серверу, то найденную процедуру вывода собранных в пользовательский интерфейс заменим кодом отправки этих данных на сервер: Code: /*создание и регистрация клиентского канала с помощью конфигурационного файла*/ RemotingConfiguration.Configure("Client.exe.txt"); //создание объекта удаленного класса Test test = new Test(); //обновление общего спула логов test.SendLog(rootNode); В свою очередь, метод удаленного класса SendLog() должен добавлять к содержимому общего отчета, находящегося на стороне сервера, данные типа rootNode. Для наглядности примера предположим, что общий отчет хранится в строковой переменной Result, тогда обновление отчета происходи следующим образом: Code: public void SendLog(string SensorLog) { //добавления лога сенсора в общий отчет Result = Result + SensorLog; } Используя этот же класс на своей стороне, сервер в реально времени может просматривать общий отчет, хранящийся в переменной Result, форматируя ее вывод произвольным образом. Code: //вывод отчета на стороне сервера test.Show() где Show() – метод удаленного класса, который осуществляет вывод переменной Result в удобочитаемой форме. Метод Show() представляет собой некую абстракцию: он может быть банальным выводом результата в консоль сервера с помощью пары инструкций, может являться выводом в специфичное хранилище логов (например, база данных) из которого впоследствии формируется вывод данных, отсортированных строго по определенным критериям и предоставленный пользователям твоего веб-сервиса. Есть идея? Значит делай! До полноценного инновационного продукта предстоит осуществить еще несколько шагов: написать полнофункциональный и конкурентноспособный сетевой анализатор траффика, распределить его в соответствии с тем подходом, который описан в статье, реализовать в виде онлайн-сервиса удобную серверную часть, которая в реальном времени обрабатывает непрерывный поток отчетов с сенсоров и представляет статистику пакетов в надлежащем виде. Однако, уже имея за спиной нестандартную мысль, воплощенную в оригинальную и яркую идею, любые шаги к инновации меркнут на фоне ожидаемых результатов. Как гласит слоган одной крупной компании: "Просто возьми и сделай!". (c) c0n Difesa (defec.ru)
уже реализовали твой подход, http://www.searchinform.ru/main/full-text-search-information-security-product.html правда цену у них явно кусаются
Прочитал [qoute]... разбирает пакеты наиболее распространенных протоколов: • TCP; • UDP; • IP; • DNS. [/qoute] Дальше мозг выключился чтобы не поломаться.
