RU107616U1 - Система быстрого анализа потока данных на наличие вредоносных объектов - Google Patents

Abstract

1. Система проверки потока данных на наличие вредоносных объектов, содержащая: ! (а) средство разбиения исходного потока данных на множество вторичных потоков данных; ! (б) средство хранения множества потоковых буферов, каждый из которых накапливает данные соответствующего вторичного потока данных из упомянутого множества вторичных потоков данных; ! (в) средство обработки, представляющее множество потоковых обработчиков, анализирующих данные, накапливаемые соответствующими потоковыми буферами из упомянутого множества потоковых буферов, где каждый потоковый обработчик выполнен с возможностью работы в определенном режиме обработки данных и, по меньшей мере, один из упомянутых потоковых обработчиков предназначен для анализа соответствующего ему вторичного потока данных на наличие вредоносного программного обеспечения. ! 2. Система по п.1, в которой каждый потоковый буфер имеет индивидуально настраиваемую политику буферизации, определяемую при создании экземпляра потокового буфера. ! 3. Система по п.2, в которой политика буферизации включает в себя информацию, такую как максимальный размер потокового буфера, достаточный для полной буферизации вторичного потока данных; размер зоны полностью обработанных данных, необходимой для использования данных в последующей обработке, а также для частичной очистки потокового буфера в случае недостаточного для буферизации объема памяти; ! 4. Система по п.1, в которой потоковый обработчик предназначен для обнаружения во вторичном потоке данных запакованных файлов, являющихся приложением к соответствующему электронному письму, и идентификации паролей в процессе синт

Description

Настоящая полезная модель относится к системам управления и обработки потоков данных и, более конкретно, к системам обнаружения в потоках данных вредоносных объектов.

Уровень техники

В настоящее время при построении комплексных систем антивирусной защиты широко применяются антивирусы, внедряемые на уровень защиты шлюзов. Существующие реализации позволяют проверять данные, поступающие по таким протоколам, как HTTP, FTP, SMTP, POP3. Важным моментом, связанным с работой антивирусов для шлюзов, является необходимость загрузки на шлюз проверяемых объектов (например, файлов, HTML-страниц, сообщений электронной почты и т.д.) целиком в рамках одного соединения. Однако возможность буферизации объектов данных целиком зависит от конкретного решения, так как объем памяти, необходимой для загрузки объектов может, значительно увеличиваться в системах, работающих с большим количеством подключений и поддерживающих проверку объектов больших размеров.

Для решения данной проблемы были разработаны системы «потокового антивирусного сканирования». Такие системы обрабатывают содержимое потока данных сегмент за сегментом без необходимости загрузки передаваемого объекта данных целиком. Различные стадии обработки потоковых данных, например, декомпрессия, синтаксический анализ MIME заголовков, сканирование на наличие вредоносных объектов, могут проводиться параллельно и чередоваться, снижая тем самым временные затраты на обработку каждого сегмента. В некотором оборудовании стадии обработки могут быть аппаратно реализованы для увеличения производительности. К примерам традиционных систем потокового антивирусного сканирования относятся SonicWall Deep Packet Inspection Engine (http://www.sonicwall.com), CP Secure stream anti-virus processors (http://www.cpsecure.com) и др.

На Фиг.1 изображена структура традиционной системы потокового антивирусного сканирования 101, которая включает в себя модуль продвижения данных 102 и анализатор 103. В момент времени 1 (на Фиг.1 обозначен цифрой «1», заключенной в окружность) система 101 получает входящий пакет 104 через входящее соединение 105. В момент времени 2 содержимое входящего пакета 104 помещается в очередь пакетов 106 и становится доступным анализатору 103 для обработки. В процессе обработки анализатор 103 в зависимости от алгоритма антивирусного анализа может выполнять буферизацию данных, используя внутренний буфер 107. В момент времени 3 анализатор 103 отправляет уведомление на модуль продвижения данных 102 о готовности к отправке через исходящее соединение 109 некоторого количества данных, характер которых не является вредоносным по результатам проведенной проверки. В момент времени 4 модуль продвижения данных 102 формирует и отправляет исходящий пакет 108 через исходящее соединение 109 и удаляет содержимое пакета из очереди пакетов 106.

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

Отметим, что данные, передаваемые по сети, часто подвергаются дополнительной обработке, такой как шифрование, сжатие, добавление специальных заголовков и т.д. Дополнительная обработка обычно применяется при передаче данных с использованием таких протоколов, как HTTP, SMTP и т.д. Таким образом, системам потокового антивирусного сканирования необходимо иметь специальные средства извлечения данных для проведения антивирусной проверки такого рода объектов.

На Фиг.2 изображен пример анализа потока данных, содержащего сообщение электронной почты в формате RFC822, применяемом в основном при передаче сообщений по стандартным почтовым протоколам, таким как SMTP, POP3 и IMAP. Входящий поток данных 201 состоит из набора битов и содержит в себе сообщение электронной почты (сообщение), передаваемое по почтовому протоколу, которое обрабатывается синтаксическим анализатором 202 в соответствии с форматом сообщения (в данном случае формат RFC822/MIME). Синтаксический анализатор 202 определяет структуру сообщения электронной почты и разбивает его на части, к примеру, тело сообщения 203 (в данном примере передается в формате HTML) и вложение 204 (в данном примере архив в формате ZIP).

Данные, содержащиеся в теле сообщения 203, обрабатываются HTML анализатором 205, основной функцией которого является проверка частей сообщения, представленных в формате HTML, на наличие вредоносных объектов. Вложение 204 первоначально подвергается обработке модулем распаковки ZIP-архивов 206, который извлекает из архива содержимое (в данном примере исполняемый файл 207 и документ Microsoft Word 208). Содержимое исполняемого файла 207 обрабатывается посредством соответствующего анализатора исполняемых файлов 209, а содержимое документа Microsoft Word 208 отправляется на проверку файловому анализатору 210, который производит синтаксический анализ документов в формате OLE2. Анализаторы 208 и 210 осуществляют антивирусную проверку содержимого файлов, используя базы сигнатур вирусов, а также специальные инструменты проверки, применяемые к определенным форматам файлов.

В традиционных системах потокового антивирусного сканирования модули анализа (в данном примере, анализаторы 202, 205, 206, 209 и 210) применяются для обработки данных объекта, передаваемого по сети, непрерывно, часть за частью, без необходимости буферизация данных объекта целиком. Это связано, прежде всего, с текущими возможностями электронной почты, позволяющими передавать во вложении к почтовому электронному сообщению файлы довольно больших размеров. Размер вложений в несколько мегабайт стал привычным для пользователей, а необходимость передачи вложений размером в десятки мегабайт (или вложений, имеющих в совокупности размер в десятки мегабайт) становится регулярным явлением. Поэтому конструкция систем потокового антивирусного сканирования должна быть приведена в соответствие с современными требованиями.

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

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

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

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

Раскрытие полезной модели

Настоящая полезная модель предназначена для обработки циркулирующих в сети потоков данных с целью обнаружения в них вредоносных объектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

Фиг.1 изображает структуру традиционной системы потокового антивирусного сканирования.

Фиг.2 показывает пример функционирования традиционной системы потокового антивирусного сканирования.

Фиг.3А показывает принципиальную архитектуру системы потоковой антивирусной обработки.

Фиг.3Б показывает один из вариантов применения менеджера потоковой обработки в рамках данной полезной модели.

Фиг.4А показывает логическую структуру потока данных и потоковых обработчиков на примере обработки потока данных, закодированного в HTML формат, в одном из вариантов осуществления данной полезной модели.

Фиг.4Б показывает структуру аналогичную изображенной на Фиг.4А применительно к варианту потоковой антивирусной обработки HTML страницы.

Фиг.5 изображает потоковый обработчик.

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

Фиг.7 показывает пример инициализации нового потокового обработчика.

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

Фиг.9 показывает пример архитектуры потокового буфера.

Фиг.10 показывает блок-схему одного из вариантов осуществления данной полезной модели.

Описание вариантов осуществления полезной модели

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

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

Средства обеспечения сетевой безопасности, позволяющие производить антивирусное сканирование циркулирующих в сети данных, обычно принимают информацию в форме сетевых пакетов (например, пакеты IP-протокола). Для проверки пакетов на наличие вредоносных объектов необходимо из содержимого пакетов, передаваемых по транспортному протоколу в рамках соединения между компьютерными системами, сформировать (собрать) «поток». Сканеры сетевых протоколов выполняют такую задачу, используя процесс известный как сборка («TCP stream reassembly»). Результирующий поток далее будем называть исходным потоком данных. Содержимое исходного потока данных представлено в одном из известных форматов протоколов передачи данных, таких как HTTP, SMTP и т.п. Упомянутый в тексте процесс формирования (сборки) исходного потока осуществляется модулем продвижения данных 102. Содержимое исходного потока поступает часть за частью на анализатор 103 для проведения антивирусного сканирования. Модуль продвижения данных 102 может выполнять дополнительную обработку протоколов, например, разделять данные, поступающие по протоколу SMTP, на последовательность сообщений в формате RFC822. В этом случае на анализатор 103 поступит несколько исходных потоков, каждый из которых будет относиться к отдельному сообщению.

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

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

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

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

На Фиг.3А изображена принципиальная архитектура одного из вариантов осуществления полезной модели. Система обработки потока 350 включает в себя менеджер потоковой обработки 301, множество потоков данных 302, каждый из которых ассоциирован с соответствующим ему потоковым буфером, и множество обработчиков данных 306. Каждый поток данных 302 может ассоциироваться с одним или несколькими обработчиками данных 306. В процессе функционирования система 350 может создавать новые потоки данных 302 и обработчики данных 306, удалять существующие, а также ассоциировать и деассоциировать потоки данных 302 и обработчики данных 306.

На Фиг.3Б изображен один из вариантов применения менеджера потоковой обработки в рамках данной полезной модели. Система потоковой обработки 350, являющаяся частью анализатора 103, изображенного на Фиг.1, состоит из:

(а) менеджера потоковой обработки 301, контролирующего процесс обработки потока и управляющего другими структурами данных.

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

(в) многочисленных обработчиков данных 306 таких, что каждый поток данных 302 может иметь несколько обработчиков данных, ассоциированных с ним.

Менеджер потоковой обработки 301 получает данные, относящиеся к исходному потоку данных 304, от сетевого модуля, управляющего потоком (например, модуля продвижения данных 102, изображенного на Фиг.1). В процессе антивирусной обработки система 350 формирует на выходе множество системных сообщений (нотификаций) 312. Системные сообщения 312 направляются в модуль продвижения данных 102, в основном, в форме вызовов процедур или функций. Системные сообщения 312 содержат информацию о том, какая часть исходного потока данных 304 может быть отправлена получателю в форме исходящего пакета 108. В случае если будет зафиксирован факт обнаружения вредоносного объекта, системное сообщение 312 будет сгенерировано с учетом этого обстоятельства - в таком случае модуль продвижения данных 102 может выполнять заранее определенные для такого случая действия, такие как разрыв соединения с получателем, отсылка предупредительного сообщения и т.п.

Как уже говорилось ранее, исходный поток данных может быть поделен на несколько логических (вторичных) потоков данных, таким образом, чтобы каждый из вторичных потоков данных представлял собой интерпретируемую часть исходного потока данных или результат некоторой трансформации данных потока. Рассмотрим подробнее, на примере, процедуру обработки потока данных. В момент времени 1 (на Фиг.3Б обозначен цифрой «1», заключенной в окружность) принимается часть данных из исходного потока данных 304 (например, при помощи модуля продвижения данных 102). В момент времени 2 менеджер потоковой обработки 301 помещает принятую часть данных в поток данных 302А, который ассоциируется с потоковым буфером 303А. В момент времени 3 исходный поток данных 304, помещенный в потоковый буфер 303А, анализируется потоковым обработчиком 306А.1, ассоциированным с потоком данных 302А (см. 305). В момент времени 4 потоковый обработчик 306А.1 (например, распаковщик сжатых данных) осуществляет распаковку части данных потока (см. 307) и передает их во вторичный поток данных 302Б, который ассоциирован с потоковым буфером 303Б. В момент времени 5 информация из потокового буфера ЗОЗБ, ассоциированного с потоком данных 302Б, передается потоковому обработчику 306Б.1, который выполняет анализ на наличие вредоносных объектов во вторичном потоке данных (307) и отправляет системные сообщения 312 менеджеру потоковой обработки 301. В момент времени 6 менеджер потоковой обработки 301 отправляет соответствующее системное сообщение 312 на внешний модуль (например, модуль продвижения данных 102).

В одном из вариантов осуществления данной полезной модели потоки данных 302 и потоковые обработчики 306 могут образовывать иерархическую структуру, проиллюстрированную в качестве примера на Фиг.4А. На этой фигуре поток данных «STREAM A» (302A) получает данные 401 напрямую из входящего потока данных и далее будет именоваться «исходным потоком данных». Исходный поток данных 302A имеет два ассоциированных с ним потоковых обработчика: HANDLER A.I (306А.1) и HANDLER A.2 (306А.2). Таким образом, информацию, помещаемую в соответствующий исходному потоку данных (302A) потоковый буфер, анализируют одновременно два обработчика: HANDLER A.1 (306А.1) и HANDLER A.2 (306А.2). HANDLER A.1 (306А.1) создает два новых различных потока данных (см. 402, 403), которые помещаются в соответствующие потокам STREAM В (302 В) и STREAM С (302С) потоковые буферы. Оба потока данных STREAM В (302 В) и STREAM С (302С) имеют по одному ассоциированному потоковому обработчику: HANDLER B.1 (306B.1) и HANDLER C.1 (306C.1) соответственно. HANDLER A.2 (306А.2) создает один новый поток данных 404, который помещается в соответствующий потоку STREAM D (302D) потоковый буфер. Поток данных STREAM D (302D) имеет два ассоциированных потоковых обработчика: HANDLER D.1 (306D.1) и HANDLER D.2 (306D.2). Обработчики HANDLER B.1 (306B.1), HANDLER C.1 (306C.1), HANDLER D.1 (306D.1) и HANDLER D.2 (306D.2) не создают новых потоков данных (например, они могут выполнять анализ данных на наличие вредоносных объектов или другого рода функции, не производящих на выходе новых данных).

На Фиг.4Б отображена структура, аналогичная изображенной на Фиг.4А применительно к варианту потоковой антивирусной обработки HTML-страницы. HTML-формат сам по себе считается безопасным от вирусов, однако, он может содержать динамический контент (объекты ActiveX) в виде встроенных скриптов, прикладных программ и исполняемого кода. Такого рода объекты часто используются вирусописателями в качестве носителей вредоносных объектов.

Процессу антивирусного сканирования встроенных в HTML страницы скриптов, предшествует этап нормализации, когда исходный текст переводится в псевдокод (P-CODE). Такого рода нормализация снижает вариативность вредоносных скриптов, делая их более пригодными для анализа (например, для использования сигнатурного поиска при обнаружении вредоносных объектов).

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

В данном случае (Фиг.4Б) поток данных «STREAM A» (450) получает данные напрямую из исходного потока данных 451. Поток STREAM A (450) ассоциирован с двумя потоковыми обработчиками: HANDLER A.1 (452) и HANDLER A.2 (453). В данном примере, HANDLER A.1 (452) анализирует HTML содержимое потока, идентифицируя участки, содержащие динамический контент (скрипты, исполняемый код и т.п.). HANDLER A.2 (453) выполняет сигнатурное сканирование содержимого потока с целью обнаружения вредоносных объектов напрямую в HTML данных без предварительной обработки. HANDLER A.1 (452) создает два новых независимых потока данных (см. 454, 455): STREAM В (456) и STREAM С (457). Содержимое потока STREAM В - (456) представляет собой нормализованный текст найденного скрипта (например, в нижнем регистре без повторяющихся пробелов и без комментариев). Содержимое потока STREAM С (457) представляет собой псевдокод (P-CODE) найденного скрипта. Оба потока данных STREAM В (456) и STREAM С (457) имею по одному ассоциированному с ними потоковому обработчику: HANDLER B.1 (458) и HANDLER C.1 (459) соответственно. Потоковый обработчик HANDLER B.1 (458) осуществляет сигнатурное сканирование нормализованного текста найденного скрипта. Потоковый обработчик HANDLER C.1 (459) осуществляет анализ псевдокода (для анализа могут быть использованы алгоритмы поиска по сигнатурам или любые другие способы обнаружения вредоносных объектов, такие как статический анализ, эмуляция и т.п.). Потоковые обработчики HANDLER A.2 (453), HANDLER B.1 (458) и HANDLER C.1 (459) не создают вторичных потоков данных, а формируют и отправляют системные сообщения 312 для информирования о текущем состоянии процесса анализа потока данных.

Отметим, что потоковые обработчики 306 могут быть реализованы в аппаратном виде для ускорения процесса анализа. Например, в рамках системы быстрого анализа потоков данных на наличие вредоносных объектов аппаратное ускорение может применяться для методов сигнатурного сканирования. Алгоритмы сжатия и кодирования (например, LZW, LZSS, Inflate) так же могут быть реализованы аппаратно, в виде процессоров, ускоряющих необходимую обработку, взаимодействие с которыми осуществляется через программные обработчики по средством специальных API-интерфейсов.

Программный интерфейс типового потокового обработчика 306 изображен в упрощенной форме на Фиг.5. Потоковый обработчик 306 реализует метод обработки данных PROCESS_DATA. Данный метод принимает два параметра: ссылка на соответствующий буфер (DATA_BUFFER) и размер, доступный для записи данных в буфер (SIZE_AVAILABLE). В процессе исполнения метода PROCESS_DATA потоковый обработчик 306 может использовать некоторый объем доступных ему данных. Используемый объем данных может быть меньше объема данных, доступных потоковому обработчику 306. Это связано с тем, что в процессе анализа потоковому обработчику могут потребоваться дополнительные данные для проведения обработки (например, потоковому обработчику необходимо дождаться получения дополнительных данных о протоколе, таких как protocol header, прежде чем анализировать контент).

Объем данных, использованных и проанализированных потоковым обработчиком 306, возвращается через выходной параметр (SIZE_CONSUMED). Если потоковый буфер 302 ассоциирован более, чем с одним потоковым обработчиком 306, то каждый потоковый обработчик 306 может использовать различный объем ассоциированного с потоком буфера. Система отслеживает, какой объем данных был проанализирован каждым ассоциированным с потоком данных обработчиком, а какой не был. Более того, если поток данных ассоциирован с несколькими потоковыми обработчиками, то каждый из них может обрабатывать различный объем данных.

На Фиг.6 изображен случай, когда один поток данных 302 ассоциирован с тремя потоковыми обработчиками 306(1), 306(2) и 306(3). Для применения мульти потоковой обработки потоковый буфер 602 поддерживает отдельные смещения 609 в буфере для каждого ассоциированного обработчика. На изображении потоковый буфер 602 логически поделен на зоны, одна из которых (607) содержит данные, обработанные всеми потоковыми обработчиками, а другая (608) - данные, не обработанные хотя бы одним из потоковых обработчиков.

Смещения в потоковом буфере выбираются по следующему алгоритму: в момент, когда поступает следующая часть входящих данных (606), поток данных 302 вызывает метод PROCESS_DATA(см. Фиг.5) для каждого из закрепленных за потоком обработчиков. Далее смещение буфера 608 обновляется в соответствии с объемом данных, используемых каждым из потоковых обработчиков. За минимальное значение смещения буфера берется смещение области, занимаемой полностью обработанными данными (область 607).

На Фиг.6 объем данных, обработанных потоковым обработчиком 306(1) совпадает с объемом области А, обработанных потоковым обработчиком 306(2) совпадает с суммой объемов областей А и В, обработанных потоковым обработчиком 306(3) - с суммой объемов областей А, В и С. Область D содержит данные, не обработанные ни одним из потоковых обработчиков. Область А потокового буфера 602 может быть освобождена от данных. Однако, в частных случаях, может понадобиться оставить некоторый объем обработанных данных, т.к. алгоритм антивирусной обработки может предусматривать динамическое подключение новых потоковых обработчиков 306 для дальнейшего анализа. В качестве практического примера можно привести ситуацию, когда в процессе анализа первых нескольких байт потоковый обработчик определяет формат полученных данных и создает другие потоковые обработчики. Созданные обработчики осуществляют непосредственную проверку на наличие вредоносных объектов в соответствии с форматом предоставленных данных. Таким образом, вновь созданный обработчик начинает свою проверку с начала потока данных, с области, содержащей уже проанализированные другими потоковыми обработчиками данные. То есть новый потоковый обработчик регистрируется со смещением буфера в области А (см. 306(N) на Фиг.7).

Данная ситуация изображена на Фиг.7. Новый потоковый обработчик 306(N) создан и зарегистрирован таким образом, что указывает на данные в области обработанных данных 703. После регистрации потоковый буфер 602 обновляет размер области обработанных данных до нового значения 704.

На Фиг.8 изображен другой вариант осуществления данной полезной модели, где поток данных 801 и ассоциированный с ним потоковый буфер 802 имеют более сложную структуру. Потоковый буфер 802 разбит на «зоны ответственности» потоковых обработчиков. Зоны могут располагаться, как в области уже полученных данных 804, так и в области еще не полученных, ожидаемых данных (область 805 на Фиг.8). Выбор зоны в области ожидаемых данных определяется в процессе анализа передаваемого объекта (например, исполняемого файла), из специального заголовка (header), в котором содержится информация о структурных элементах объекта, например, о секциях (исполняемом коде, ресурсах, таблице импорта и т.д.). Эти зоны типизируют информацию в зависимости от действий, которые должны быть применены при поступлении в них данных.

На Фиг.8 изображен поток данных 801 и ассоциированный с ним потоковый буфер 802, поделенный на зоны 803: 803А, 803В, и 803С - за каждой из которых закреплен соответствующий потоковый обработчик. Зоны 803А и 803В зарегистрированы в области полученных данных 804, а зона 803С зарегистрирована в области ожидаемых данных 805. Потоковые обработчики 306(1А), 306(1В) и 306(1С) анализируют данные из соответствующих зон 803А, 803В, и 803С (на Фиг.8 не показан случай, когда несколько потоковых обработчиков могут анализировать данные из одной зоны). В данном варианте осуществления полезной модели в процессе выполнения обработки данных для выявления вредоносных объектов могут динамически создаваться новые зоны, ассоциированные с определенными наборами действий, выполняемыми при поступлении в зоны данных из потока.

На Фиг.9 изображена внутренняя архитектура потока данных 801 с возможностью динамического создания зон 803. На Фиг.9 можно видеть поток данных 801, содержащий таблицу зон 902 и потоковый буфер 905, который может содержать буферы памяти, относящиеся к разным зонам. Таблица зон 902 содержит список характеристик 904 зон потока данных. Буферный пул 905 содержит список буферов памяти, относящихся к зонам потока: данных. Характеристики зон содержат информацию следующего характера:

Смещение 908: смещение в байтах относительно начала потока данных, указывающее на начало зоны;

Размер 909: размер зоны (в некоторых случаях размер может изменяться динамически);

Важность 910: определяет, когда информация, размещенная в зоне, может быть удалена по причине нехватки свободного места;

Действия 911: определяет перечень действий, выполняемых при появлении во входящем потоке данных, относящихся к зоне;

ИД Буфера 912: идентификатор буфера памяти, относящегося к зоне. Зоны, зарегистрированные в области ожидаемых данных, или зоны, очищенные от данных, идентификаторов буфера памяти не имеют.

Когда поток данных 801 получает новую порцию входящих данных, происходит обновление значения текущего смещения 901. Данное значение смещения 901 сравнивается с исходным значением смещения 908 выделенных зон. Если порция поступивших данных выходит за пределы выделенной зоны, то для размещения этих данных в зоне создается новый буфер памяти и зона продолжает функционировать - это система 350 исполняет действия, ассоциированные с соответствующей зоной (действия 911).

Действия 911 могут содержать имена процедур или иных инструкций, действий, вызываемых и исполняемых системой 350. К примеру, действиями, осуществляемыми системой 350, могут быть создание новых экземпляров потоковых обработчиков 306 и ассоциирование их с потоком данных 801 на определенном смещении по отношению к исходному смещению 908.

Потоковые обработчики 306, в свою очередь, могут создавать вторичные потоки данных 302 и проводить антивирусное сканирование. Если зона 803 имеет фиксированный размер 909, то система может автоматически удалять зону и освобождать буфер памяти 906, когда значение текущего смещения 901 потока превысит величину, равную -сумме исходного значения смещения 908 выделенной зоны и размера 909 зоны.

На Фиг.10 изображена блок-схема процесса обработки порции данных, получаемой на шаге 1001. На шаге 1002 поток данных проверяет список зон, упомянутый выше, для определения принадлежности данных к зоне. На шаге 1003, если данные относятся к ранее выделенной зоне, то на шаге 1004 данные помещаются в соответствующий буфер (и, если необходимо, в потоковом буфере выделяется новый сегмент памяти). На шаге 1005, если данные носят первичный характер (не обрабатываются повторно), то система 350 выполняет на шаге 1006 ассоциированные с зоной действия, например, создание новых экземпляров потоковых обработчиков, разбор MIME и HTML объектов, распаковка архивированных объектов, сканирование исполняемых файлов и т.п. Процесс обработки порции данных завершается на шаге 1007. На шаге 1003, если порция данных не соотносится ни с одной из зон, данные не буферизуются, и процесс так же завершается на шаге 1007.

Следует отметить, что некоторые потоковые обработчики 306 могут выполнять задачи разборки HTML-страниц, идентификации скриптов и проверки их на наличие вредоносных сигнатур. Перед другими потоковыми обработчиками могут стоять более сложные задачи. На сегодняшний день многие объекты, передаваемые по сети, предварительно архивируются или кодируются. Например, широко распространено применение ZIP и RAR архиваторов - вирусы часто внедряются в запакованные (архивированные) файлы. По этой причине при анализе электронных сообщений, необходимо идентифицировать тип вложений, к примеру, используя заголовочную информацию (header), и распаковывать их для проведения антивирусного сканирования.

Также потоковый обработчик при разборке тела электронного письма может идентифицировать пароль (или набор данных, потенциально подходящих под комбинацию пароля), и попытаться использовать его для распаковки зашифрованных файлов. Подобным образом многие файлы форматов Microsoft Word или Adobe Acrobat PDF так же могут быть защищены паролем, скрывая встроенный внутрь документа код вируса. Таким образом, возникает еще одно препятствие перед потоковыми обработчиками, выполняющими проверку данных на наличие вредоносных объектов - шифрование и другие формы защиты объектов. В некоторых случаях шифрование - это необходимая мера по обеспечению конфиденциальности передаваемых данных. В других случаях - средство противодействия проведению антивирусного сканирования. Например, существует большое количество разновидностей спама, передаваемого в упакованном и зашифрованном виде во вложении к электронным письмам. Однако так как целью спам рассылок является донесение до конечного пользователя некой информации, в тело письма в различных формах (текстом, рисунком и т.д.) включается информация о пароле, и специальные потоковые обработчики включаются в работу с целью идентификации этой информации.

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

Claims (15)

1. Система проверки потока данных на наличие вредоносных объектов, содержащая:

(а) средство разбиения исходного потока данных на множество вторичных потоков данных;

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

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

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

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

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

5. Система по п.1, в которой, по меньшей мере, один из потоковых обработчиков предназначен для распаковки сжатых данных из одного или нескольких вторичных потоков данных.

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

7. Система по п.6, в которой потоковый обработчик анализирует потоки данных, передаваемые по таким протоколам, как протоколы передачи гипертекста, протоколы передачи данных электронной почты, протоколы передачи файлов и протоколы передачи мгновенных сообщений.

8. Система по п.6, в которой в потоке данных объекты представлены, по меньшей мере, в следующих форматах: в формате гипертекстовой информации, в формате архивированных данных, в формате составных электронных документов, в формате исполняемых фалов, в форматах динамического контента и в медиаформатах.

9. Система по п.1, в которой, по меньшей мере, один потоковый обработчик предназначен также для сканирования данных на наличие вредоносных объектов с использованием вирусных сигнатур.

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

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

12. Система по п.1, в которой экземпляр потока данных создается потоковым обработчиком с учетом смещения в потоке данных, от которого отделяется данный экземпляр потока данных.

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

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

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