СИСТЕМА И СПОСОБ АВТОГЕНЕРАЦИИ РЕШАЮЩИХ ПРАВИЛ ДЛЯ СИСТЕМ ОБНАРУЖЕНИЯ ВТОРЖЕНИЙ С ОБРАТНОЙ СВЯЗЬЮ Российский патент 2017 года по МПК G06F21/55 

ОБЛАСТЬ ТЕХНИКИ

[0001] Техническое решение относится к компьютерным системам и более конкретно к системам и способам обнаружения компьютерных атак.

УРОВЕНЬ ТЕХНИКИ

[0002] В связи с бурным развитием компьютерной техники и компьютерных сетей все большую актуальность обретает задача детектирования компьютерных атак и своевременного обнаружения случаев заражения вредоносным ПО рабочих станций, мобильных устройств и серверов.

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

[0004] СОВ сетевого уровня используют базы решающих правил. Решающие правила содержат в себе ряд критериев, по которым осуществляется анализ сессий связи и регистрация событий ИБ. Критерии описывают, в рамках установленного синтаксиса, требования к содержимому и атрибутам сетевых соединений, считаемых системой вредоносными.

[0005] В практическом применении сетевых СОВ важными задачами являются:

- Своевременное обновление базы решающих правил для более эффективного детектирования новых угроз

- Снижения числа ошибок первого рода (ложно-положительных событий)

СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ

[0006] Данное техническое решение направлено на устранение недостатков, присущих существующим решениям в известном уровне техники.

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

[0008] Техническим результатом данного технического решения является повышение эффективности выявления компьютерных атак.

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

[00010] В некоторых вариантах реализации извлекаемым из события признаком является ip-адрес получателя данных или доменное имя, извлеченное из служебных заголовков передаваемых данных;

[00011] В некоторых вариантах реализации сформированные решающие правила включают комбинацию из, по крайней мере, двух следующих правил:

- отслеживание DNS запросов,

- отслеживание HTTP запросов,

- отслеживание сессий связи,

- отслеживание TLS-рукопожатий и сертификатов;

[00012] В некоторых вариантах реализации сохраняют сформированные решающие правила с использованием системы контроля версий;

[00013] В некоторых вариантах реализации в качестве системы контроля версий используют GIT или SVN или CVS или Mercurial;

[00014] В некоторых вариантах реализации дополнительно получают от, по крайней мере, одного сенсора пассивно собираемый список DNS-запросов с ответами;

[00015] В некоторых вариантах реализации при формировании решающих правил, включающих отслеживание HTTP запросов, используют полученный от, по крайней мере, одного сенсора пассивно собираемый список DNS-запросов с ответами;

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

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

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

- список доверенных доменных имен;

- passiveDNS - пассивно собираемый сенсорами список DNS-запросов с ответами;

[00018] Модуль репозитория правил, выполненный с возможностью получения и хранения базы решающих правил с поддержкой версионности данных;

[00019] Модуль генерации правил, выполненный с возможностью:

получения событий из базы данных событий, сформированной данными,

полученными от, по крайней мере, одного сенсора;

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

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

проверки наличия извлеченных признаков в списке доверенных имен полученном от модуля базы данных;

формирования решающих правил, включающих отслеживание всех DNS, HTTP запросов, сессий связи, TLS-рукопожатий и сертификатов, связанных с извлеченными признаками;

отправления сформированных решающих правил в модуль репозитория правил для сохранения;

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[00020] Признаки и преимущества настоящего технического решения станут очевидными из приводимого ниже подробного описания и прилагаемых чертежей, на которых:

[00021] на Фиг. 1 показан пример возможной конфигурации сети;

[00022] на Фиг. 2 показана блок-схема способа автогенерации решающих правил для систем обнаружения вторжений с обратной связью;

[00023] на Фиг. 3 показан пример осуществления варианта технического решения согласно системе автогенерации решающих правил для систем обнаружения вторжений с обратной связью.

[00024] На всех фигурах линии со стрелками означают наличие и направление взаимодействия между объектами.

ПОДРОБНОЕ ОПИСАНИЕ

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

[00026] Техническое решение может быть реализовано в виде распределенной компьютерной системы, включающей два или более сервера, соединенных каналами связи. В данном техническом решении под сервером подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций), имеющие возможность получать данные, отправлять запросы и принимать ответы на других серверов или устройств через каналы связи.

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

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

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

[00030] Ниже будут описаны понятия и определения, необходимые для подробного раскрытия осуществляемого технического решения.

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

[00032] RFC (Request for Comments) - документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и Стандарты, широко используемые во Всемирной сети.

[00033] Центр управления - в области компьютерной безопасности, включает в себя серверы и другие технические инфраструктуры, используемые для контроля вредоносных программ в целом и, в частности, ботнетов.

[00034] Системы обнаружения вторжения (СОВ) - это системы, собирающие информацию из различных точек защищаемой компьютерной системы (вычислительной сети) и анализирующие эту информацию для выявления как попыток нарушения, так и реальных нарушений защиты (вторжений).

[00035] Ниже рассмотренный пример реализации является иллюстративным и не ограничивает сущность технического решения.

[00036] Способ автогенерации решающих правил для систем обнаружения вторжений с обратной связью.

[00037] Рассмотрим принципиальную схему сети с установленной системой обнаружения вторжений.

[00038] Пусть имеется несколько подсетей (100 и 110), в каждой из которых располагается одно или более устройств (101, 111), имеющих доступ к сети. В качестве таких устройств могут выступать смартфоны, ноутбуки, планшеты, стационарные компьютеры, серверы или любые другие устройства, выполненные с возможностью подключения к сети и обмена данными. Также к сети могут быть подключены маршрутизаторы (105, 115). Для анализа сетевого трафика сетевое оборудование настраивается таким образом, чтобы осуществлять зеркалирование передаваемых пакетов данных сегментов на определенный порт, к которому и подключается устройство анализа трафика (далее сенсор). Сенсор (102, 112) производит мониторинг сетевого трафика и анализирует содержимое сессий связи на наличие вредоносных признаков. В качестве сенсора используется компьютер или любое другое устройство имеющее, по крайней мере, 2 сетевые карты (NIC), при этом одна сетевая карта сенсора используется для захвата сетевого трафика, а вторая используется для управления, настройки и коммуникаций с сервером, выполняющим функционал центрального узла (130).

[00039] Центральный узел (ЦУ) в такой системе реализует следующую функциональность:

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

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

[00040] В некоторых вариантах реализации сенсоры пассивно собирают информацию о происходящих события в сети и отправляют ее на центральный узел (ЦУ). В качестве такой информации может быть информация о DNS-запросах с ответами (PassiveDNS).

[00041] Пусть на некотором сенсоре sensor_1 срабатывает правило rule_1. Под правилом понимают набор признаков, характерных вредоносному сетевому трафику. Признаки, используемые в правиле, могут быть отнесены к любому из протоколов модели OSI, поддерживаемому СОВ. В данном техническом решении используются правила, работающие со следующими уровнями и протоколами (согласно модели OSI):

[00042] Сетевой уровень - IP, ICMP, но не ограничиваясь;

[00043] Транспортный уровень - TCP, UDP, SCTP, но не ограничиваясь;

[00044] Прикладной - HTTP, DNS, FTP, SMTP, IRC и другие прикладные протоколы.

[00045] Правила имеют собственную классификацию. В зависимости от СОВ может использоваться различная классификация правил (сигнатур). В качестве иллюстративного примера частично приведем классификацию правил (сигнатур) COB Bot-Trek TDS:

- banking-trojan - правила обнаруживающие вредоносное ПО, атакующее системы дистанционного банковского обслуживания;

- mobile-trojan - детектируют заражения мобильных устройств и коммуникацию с используемыми командными центрами;

- backdoor - правила срабатывают при обнаружение характерных сетевых соединений инициированными известными программами для удаленного доступа к компьютеру или серверу;

- apt-trojan - срабатывают на сетевое взаимодействие с командными центрами троянов, отнесенных к используемым в целевых атаках;

- ek-activity - фиксируют взаимодействия с узлами, на которых размещены так называемые «Связки эксплоитов», т.е. Наборы вредонсоного ПО для удаленной эксплуатации уязвимостей в браузерах и их плагинах;

- botnet-cnc - срабатывает на трафик, схожий с тем, который генерирует С&С (Command&Control Centre) - центр управления ботнетом;

- dos, ddos - оповещают о трафике, генерируемом известными методами, вызывающими отказ в обслуживание (например, Trin00);

[00046] Затем после срабатывания правила rule_1 на сенсоре sensor_1 создается событие event_1, содержащее, по крайней мере, следующие свойства:

- Время регистрации события (event_1);

- Уникальный идентификатор сенсора, на котором произошло событие (sensor_1);

- Уникальный идентификатор сработавшего правила (rule_1);

- IP-адрес источника пакета;

- IP-адрес получателя пакета;

- Используемый протокол передачи данных;

- Служебные заголовки пакетов данных;

- Фрагмент полезной нагрузки вредоносного пакета, на котором произошло срабатывание правила.

[00047] Согласно модели OSI, протоколы более высокого уровня реализуются на базе протоколов более низкого уровня. Например, протокол HTTP может быть реализован поверх протокола TCP, который в свою очередь реализуется поверх протокола IP. Некоторые из протоколов высокого уровня могут быть реализованы поверх протокола UDP или других протоколов. Таким образом, IP адрес получателя и источника пакета, служебные заголовки пакетов данных, фрагмент полезной нагрузки вредоносного пакета извлекаются на уровне протоколов TCP/UDP и IP или других протоколов, которые располагают такой информацией или поверх которых реализован текущий протокол, на котором произошло срабатывание правила. Служебные заголовки пакетов данных представляют собой данные, хранящиеся в заголовке пакета, в соответствии с RFC данного протокола.

[00048] Затем данное событие event_1 сенсор sensor_1 отправляет на Центральный узел (ЦУ), который получает данное событие, производит его анализ и сохраняет в базе событий.

[00049] Далее, система автогенерации решающих правил получает событие из базы данных событий (201) и анализирует его на принадлежность к классу взаимодействия с центрами управления вредоносных программ (202). Если событие относится к такому классу, то из события извлекают признаки, используемые для формирования решающих правил (203). Проверка наличия новых событий может осуществляться периодически или при помощи механизма оповещений.

[00050] В качестве признаков могут использоваться любые идентификаторы, указывающие на сетевой адрес центра управления вредоносных программ или атакуемого узла. В качестве таких идентификаторов могут выступать ip-адрес получателя данных (пакета) или доменное имя, извлеченное из служебных заголовков, передаваемых данных (пакета). Так, например, для протокола HTTP доменное имя извлекается из служебного поля Host. Для DNS доменное имя извлекается из бинарной структуры передачи данных в соответствии с RFC 1035. В случае TLS, доменное имя извлекается из расширенного «client hello» сообщения (SNI, RFC3546). В общем случае извлечение признаков происходит из структур данных согласно RFC протоколу.

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

[00052] Затем система автогенерации решающих правил формирует решающие правила (204), включающие отслеживание всех DNS, HTTP запросов, сессий связи, TLS-рукопожатий и сертификатов, связанных с извлеченными признаками. Сформированные решающие правила могут включать, но не ограничиваясь, следующие правила:

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

- фиксировать все HTTP-запросы к извлеченному доменному имени (если извлеченные признаки содержат домен);

- фиксировать все TLS-рукопожатия и сертификаты, связанные с извлеченным доменным именем (если извлеченные признаки содержат домен). При этом производится поиск данного доменного имени в трафике установления TLS-соединений (TLS Handshake) и сертификате сервера. Позволяет детектировать угрозы, использующие TLS для шифрования сетевого взаимодействия с командными центрами. В некоторых вариантах реализации используется Server Name Indication (SNI) - расширение компьютерного протокола TLS, которое позволяет клиентам сообщать имя хоста, с которым он желает соединиться, во время процесса рукопожатия. Обычно задается в виде поля server_name в запросе;

- фиксировать все сессии связи, связанные с извлеченным IP-адресом;

- фиксировать все HTTP-запросы к доменным именам, имеющим А-/АААА-запись с извлеченным IP-адресом. Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос А-записи на имя referrals.icann.org вернет его IPv4-адрес- 192.0.34.164. Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос АААА-записи на имя К.ROOT-SERVERS.NET вернет его IPv6-адрес - 2001:7fd::1.

[00053] В некоторых вариантах реализации при формировании правила фиксирующего все HTTP-запросы к доменным именам, имеющим А-/АААА-запись с извлеченным IP-адресом, может использоваться пассивно собираемая сенсорами информация о DNS-запросах с ответами (PassiveDNS). При этом список DNS-запросов с ответами анализируется на наличие записей, содержащих А-/АААА-запись с извлеченным IP-адресом, что позволяет отследить трафик направленны к разделегированным или недоступным на данный момент доменным именам.

[00054] Далее система автогенерации решающих правил сохраняет сформированные решающие правила (205). Решающие правила могут сохраняться в файлах, базе данных. В некоторых вариантах реализации, для сохранения версионности изменений и возможности отката к предыдущим версиям при хранении сформированных правил используют системы контроля версий. В некоторых вариантах реализации используют распределенные системы контроля версий. В качестве существующих реализаций систем контроля версий могут использоваться, но не ограничиваясь, SVN, Mercurial, GIT, CVS.

[00055] После этого система автогенерации решающих правил предоставляет возможность получения обновления решающих правил для сенсоров.

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

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

[00058] Система автогенерации решающих правил включает следующие модули, выполняемые на сервере.

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

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

- список доверенных доменных имен (312). Список может пополняться оператором системы, а изначальный перечень может быть загружен из публичных источников, в частности рейтинга ALEXA;

- Passivedns (313) - пассивно собираемый сенсорами список DNS-запросов с ответами, позволяющий по IP-адресу восстанавливать список доменных имен, имеющих (либо имевших в прошлом) соответствующую А-/АААА/МХ-запись, связанную с данным IP-адресом.

[00060] Модуль репозитория правил (320), выполненный с возможностью хранения базы решающих правил с поддержкой версионности данных. Решающие правила могут сохраняться в файлах, базе данных. В некоторых вариантах реализации для сохранения версионности изменений и возможности отката к предыдущим версиям при хранении сформированных правил используют системы контроля версий. В некоторых вариантах реализации используют распределенные системы контроля версий. В качестве существующих реализаций систем контроля версий могут использоваться, но не ограничиваясь, SVN, Mercurial, GIT.

[00061] Модуль генерации правил (330), выполненный с возможностью анализа полученных от сенсоров событий, генерации новых решающих правил. Модуль генерации правил (330) получает, по крайней мере, одно событие из базы данных событий (341) центрального узла (340), полученных от, по крайней мере, одного сенсора, и анализирует его на принадлежность к классу взаимодействия с центрами управления вредоносных программ на основе списка идентификаторов правил модуля базы данных (311). Если событие относится к такому классу, то модуль (330) из события извлекает, по крайней мере, один признак, используемый для формирования решающих правил. В качестве признаков могут использоваться любые идентификаторы, указывающие на сетевой адрес центра управления вредоносных программ или атакуемого узла. В качестве таких идентификаторов могут выступать ip-адрес получателя данных (пакета) или доменное имя, извлеченное из служебных заголовков, передаваемых данных (пакета). Так, например, для протокола HTTP доменное имя извлекается из служебного поля Host. Для DNS доменное имя извлекается из бинарной структуры передачи данных в соответствии с RFC 1035. В случае TDS домен извлекается из «client hello» сообщения, содержащего расширение SNI.

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

[00063] Затем модуль генерации правил формирует решающие правила, включающие отслеживание всех DNS, HTTP запросов, сессий связи, TLS-рукопожатий и сертификатов, связанных с извлеченными признаками. Сформированные решающие правила могут включать, но не ограничиваясь, следующие правила:

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

- фиксировать все HTTP-запросы к извлеченному доменному имени (если извлеченные признаки содержат домен);

- фиксировать все TLS-рукопожатия и сертификаты, связанные с извлеченным доменным именем (если извлеченные признаки содержат домен). При этом производится поиск данного доменного имени в трафике установления TLS-соединений (TLS Handshake) и сертификате сервера;

- фиксировать все сессии связи, связанные с извлеченным IP-адресом;

- фиксировать все HTTP-запросы к доменным именам, имеющим А-/АААА-запись с извлеченным IP-адресом.

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

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

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

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

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

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

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

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

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

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

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

2. Способ по п. 1, в котором извлекаемым из события признаком является ip-адрес получателя данных или доменное имя, извлеченное из служебных заголовков, передаваемых данных.

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

- отслеживание DNS запросов,

- отслеживание HTTP запросов,

- отслеживание сессий связи,

- отслеживание TLS-рукопожатий и сертификатов.

4. Способ по п. 1, в котором сохраняют сформированные решающие правила с использованием системы контроля версий.

5. Способ по п. 4, в котором в качестве системы контроля версий используют GIT, или SVN, или CVS, или Mercurial.

6. Способ по п. 3, в котором дополнительно получают от, по крайней мере, одного сенсора пассивно собираемый список DNS-запросов с ответами.

7. Способ по п. 6, в котором при формировании решающих правил, включающих отслеживание HTTP запросов, используют полученный от, по крайней мере, одного сенсора пассивно собираемый список DNS-запросов с ответами.

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

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

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

список доверенных доменных имен;

PassiveDNS - пассивно собираемый сенсорами список DNS-запросов с ответами;

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

модуль генерации правил, выполненный с возможностью:

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

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

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

проверки наличия извлеченных признаков в списке доверенных имен, полученном от модуля базы данных;

формирования решающих правил, включающих отслеживание всех DNS, HTTP запросов, сессий связи, TLS-рукопожатий и сертификатов, связанных с извлеченными признаками;

отправления сформированных решающих правил в модуль репозитория правил для сохранения;

сенсор, выполненный с возможностью:

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

отправки сформированных событий на центральный узел;

отправки в модуль базы данных пассивно собираемого списка DNS-запросов с ответами;

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