Способ и система ускоренного туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения Российский патент 2024 года по МПК G06F21/60 H04L9/40 H04L61/2592 

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

Данное техническое решение относится к области вычислительной техники, а именно к способам и системам ускоренного туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения (ВПО).

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

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

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

Современные СОА выполняют множество функций, одной из которых является поведенческий (behavioral) анализ потенциально ВПО. В процессе поведенческого анализа выполняют запуск исполняемых файлов потенциально ВПО в специальной изолированной среде для детонации - анализа программного обеспечения и выявления его вредоносности. Такие среды называются в области кибербезопасности песочницами. Подробнее про песочницы написано здесь https://m.wikipedia.org/wiki/Песочница (безопасность).

Уже давно известно об использовании в области кибербезопасности песочниц, специальной изолированной среды для детонации - анализа программного обеспечения и выявления его вредоносности. Подробнее про песочницы написано здесь https://ru.wikipedia.org/wiki/Песочница (безопасность). В ответ на создание песочниц, злоумышленниками были реализованы более сложные виды ВПО. Такие ВПО, например, способны анализировать среду, в которую они попадают. В случае, если ВПО попадает в песочницу, его поведение может отличаться от его поведения в неизолированной среде.

Известно, что некоторым ВПО удается преодолеть статический анализ программного обеспечения, который производится посредствам анализа различных ресурсов исполняемого файла без его выполнения и изучения каждого его компонента в отдельности. А некоторым ВПО даже удается остаться не обнаруженными после динамического анализа. Также используется название поведенческий (behavioral) анализ. Для проведения динамического или поведенческого анализа выполняется запуск исполняемых файлов в эмулированной среде (песочнице/sandbox) и наблюдение за совершаемыми ими действиями и событиями, происходящими в системе. При выявлении подозрительной активности производится блокирование ВПО и последующее уведомление клиента о готовящейся, проводящейся или уже проведенной атаке, в зависимости от способа реагирования.

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

Очевидным решением для такой ситуации может показаться технология подмены IP-адреса на желаемый, например, натирование. Натирование также имеет второе название -маскарадинг. Натирование является способом трансляции сетевого адреса, при котором IP-адрес отправителя проставляется динамически в зависимости от назначенного интерфейсу IP-адреса. Подробнее натирование описано здесь https://ru.wikipedia.org/wiki/Маскарадинг и здесь https://ru.wikipedia.org/wiki/NAT.

К сожалению, самая простая реализация натирования, при которой IP-адрес песочницы, не находящейся в корпоративной подсети, будет просто заменен на ГР-адрес корпоративной подсети, не сработает. Удаленный сервер злоумышленника, получив запрос из корпоративной подсети, направит ответ на IP-адрес корпоративной подсети. Корпоративная подсеть скорее всего проигнорирует входящий пакет, полученный как ответ от сервера злоумышленников, так как не отправляла запроса на удаленный сервер злоумышленников. Для того, чтобы корпоративная подсеть переслала входящий пакет, полученный в ответ от сервера злоумышленников, в песочницу, песочница должна действительно находиться в корпоративной подсети, что технически реализовать сложнее и помимо технических сложностей в реализации является ресурсозатратным. Таким образом, сетевое окружение является одним из уязвимых мест и позволяет атакующему понять, что исполнение ВПО происходит в эмулированном окружении. Современные СОА для того, чтобы эффективно противостоять быстро развивающимся ВПО должны на определенном уровне эмулировать сетевое окружение.

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

VPN - это обобщенное название для технологий, позволяющих обеспечить одно или несколько сетевых соединений поверх другой сети, например, сети Интернет. Подробнее про VPN написано здесь https://ru.wikipedia.org/wiki/VPN.

У каждого из участников сети, пира, есть свой локальный IP-адрес. Маршрутизация каждого пира настроена таким образом, что он передает пакеты в Интернет через сервер. Так для каждого исходящего пакета данных, проходящего через сервер, выполняется натирование. А для каждого входящего пакета выполняется денатирование - публичный IP-адрес заменяется на локальный IP адрес пира. В случае, если песочница является одним из пиров и находится в корпоративной сети VPN, технология натирования будет работать и позволит решить задачу подмены IP-адреса. Однако это решение не является оптимальным и имеет ряд недостатков. Один из них - это клиент-серверная архитектура, которая требует постоянного поддержания большого количества соединений в актуальном состоянии. Это ресурсозатратно.

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

Поэтому современные облачные СОА поддерживают туннелирование всего сетевого трафика. Туннелирование трафика - это процесс, в ходе которого создается логическое соединение между двумя конечными точками посредством инкапсуляции. Туннелирование представляет собой метод построения сетей, при котором один сетевой протокол инкапсулируется в другой, то есть передаваемые через туннель данные "упаковываются" вместе со служебными полями в область полезной нагрузки несущего протокола. Подробнее туннелирование описано здесь https://en.wikipedia.org/wiki/Tunneling protocol. Туннелирование выполняется для всего трафика, генерируемого в ходе проведения поведенческого анализа, до проксирующего сервера, установленного внутри подсети клиента. Клиентам предлагается расположить небольшой проксирующий сервер в демилитаризованной зоне (DMZ) внутри своей подсети. Такой сервер обычно называется выходной нодой, exit node, или гейтвеем, gateway. Он служит шлюзом для туннелирования всего IP-трафика, генерируемого в ходе поведенческих анализов исполняемых файлов, принадлежащих или предназначавшихся данному клиенту.

Из уровня техники известны различные протоколы маршрутизации трафика, в том числе протокол маршрутизации трафика в распределенной сети Next Hop Resolution Protocol, в дальнейшем для краткости называется NHRP (https://en.wikipedia.org/wiki/Next_Hop_Resolution Protocol). NHRP является расширением механизма маршрутизации ARP ATM, который иногда используется для повышения эффективности маршрутизации компьютерного сетевого трафика по нешироковещательным сетям с множественным доступом. Данный протокол определен стандартом IETF RFC 2332 и дополнительно описан стандартом RFC 2333. Он может использоваться отправителем для определения маршрута с наименьшим количеством переходов к получателю. Протокол отличается от протоколов типа ARP тем, что позволяет оптимизировать маршрутизацию между несколькими IP-подсетями.

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

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

В то же время, из уровня техники известно решение US20050086367A1 (Alex Conta et al., Methods and apparatus for implementing multiple types of network tunneling in a uniform manner, опубл. 04.21.2005. кл. G06F 15/173), в котором описан способ реализации поддержки нескольких протоколов туннелирования трафика с помощью роутера. Предлагается к реализации туннелирование трафика одновременно с помощью протокола IP-IP и IP-over-MPLS.

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

Как было ранее упомянуто, из уровня техники известны решения для детонации и исследования вредоносного программного обеспечения, так называемые песочницы. А также известны различные способы по организации окружения песочниц для того, чтобы затруднить для злоумышленника и его программного обеспечения обнаружение песочниц. Одним примером такого решения является US 10404661 В1 (Taylor Ettema et al., Integrating a honey network with a target network to counter IP and peer-checking evasion techniques, опубл. 09.03.2019. кл. G06F 9/455, H04L 29/06), в котором описывается способ интеграции сети "honey pot" с целевой сетевой средой (например, корпоративной сетью) для подмены IP и методы уклонения от одноранговой проверки. В некоторых вариантах осуществления система для интеграции сети "honey pot" с целевой сетью включает в себя хранилище данных профиля устройства, которое включает в себя множество атрибутов каждого из множества устройств целевой среды: диспетчер виртуальных копий, который создает виртуальную копию одного или нескольких устройств целевой сети на основе одного или нескольких атрибутов целевого устройства в хранилище данных профиля устройства и сетевую политику "honey pot", которая сконфигурирована для маршрутизации внешней связи от виртуальной копии к целевому устройству в сети "honey pot" к внешнему устройству через сетевую среду. В данном решении не упоминается ни одного способа туннелирования трафика и реализации подмены IP-адреса песочницы на IP-адрес корпоративной сети с помощью протоколов туннелирования трафика.

Наиболее близким к предлагаемому к патентованию решением является решение, описанное в заявках RU 2022114307 и RU 2023110050. Данное решение является способом и системой туннелирования трафика, где передача трафика реализована через центральный сервер, который выступает в роли главного маршрутизатора в системе. Это является ограничивающим фактором работоспособности системы, так как при недоступности центрального сервера пиры не могут получать IP-адреса.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Центральный сервер - сервер в распределенной сети, который используется для настройки маршрутизации и выдачи IP-адресов внутри сети, на центральном сервере хранится талица соседей;

Гейтвей - пир распределенной сети, реализованный для натирования пакетов исходящего трафика;

Эмиттер - пир распределенной сети, на котором установлена одна или несколько песочниц;

Пир - участник распределенной сети, например, гейтвей или эмиттер;

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

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

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

Таблица соседей - таблица в сетевом стеке ОС, в которой хранятся записи о соответствии IP-адресов на уровне GRE к IP-адресам на уровне WireGuard. Аналогом таблицы соседей является ARP-таблица, в которой хранятся записи о соответствии IP-адресов к МАС-адресам. ОС обращается к этим таблицам при маршрутизации пакетов для получения адреса получателя на нижележащем уровне сети;

Интерфейс - здесь значит интерфейс взаимодействия с программным обеспечением Wireguard или GRE;

Полигон - набор изолированных сред для детонации и анализа потенциально вредоносного контента;

ARP-запрос - ARP-ответ- передача запросов по протоколу ARP (Address Resolution Protocol - протокол определения адреса).

В данном изобретении может быть использован любой аналог ARP-протокола.

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

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

В предпочтительном варианте реализации заявлен компьютерно-реализуемый способ ускоренного туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения, распределенная сеть реализованная с помощью двухуровневого туннелирования, включающего уровень WireGuard соединения и уровень GRE соединения, способ, реализованный с помощью по меньшей мере одного эмиттера, способ по которому передают запрос на получение эмиттером данных гейтвея, включающих IP-адрес гейтвея на уровне WireGuard, публичный ключ, UDP-адрес, на центральный сервер: по меньшей мере один эмиттер является пиром распределенной сети для анализа вредоносного контента и получения инкапсулированных пакетов на уровнях WireGuard и GRE; по меньшей мере один центральный сервер хранит таблицу соседей и является сервером для настройки ускоренного туннелирования между пирами; по меньшей мере один гейтвей является пиром распределенной сети для натирования по меньшей мере одного пакета исходящего трафика и денатирования по меньшей мере одного пакета входящего трафика; в ответ на получение от центрального сервера данных гейтвея, добавляют гейтвей в качестве пира на WireGuard интерфейс эмиттера; передают на центральный сервер ARP-пробу, где ARP-проба идентифицирует готовность эмиттера к установке р2р связи с гейтвеем; в ответ на получение на эмиттере ответа на ARP-пробу обновляют данные гейтвея в таблице соседей на эмиттере; отправляют эмиттером по меньшей мере один пакет исходящего трафика на гейтвей для натирования, где по меньшей мере один пакет исходящего трафика содержит два уровня инкапсуляции поверх транспортного протокола; извлекают, в ответ на получение по меньшей мере одного пакета входящего трафика от гейтвея, из по меньшей мере одного пакета входящего трафика потенциально вредоносный контент; анализируют потенциально вредоносный контент и добиваются его детонации. В представленном способе запрос на получение эмиттером данных гейтвея содержит IP-адрес гейтвея на уровне GRE. IP-адреса включают: IP-адрес в сети Интернет, IP-адрес на уровне Wireguard, IP-адрес на уровне GRE. Одна из реализаций может содержать подготовительный этап, на котором выполняют регистрацию по меньшей мере одного эмиттера и по меньшей мере одного гейтвея на по меньшей мере одном центральном сервере посредством выдачи конфигурационного файла. Конфигурационный файл получают на эмиттере от центрального сервера. Посредством полученного конфигурационного файла выполняют конфигурацию интерфейсов на WireGuard уровне и GRE уровне. В случае превышения временного интервала на получение ARP-ответа высылают повторный ARP-запрос. В случае превышения лимита отправки повторных ARP-запросов выполняют переход эмиттера на резервный маршрут через центральный сервер. При переходе на резервный маршрут с эмиттера на гейтвей отправляют запрос на переход на резервный маршрут.

В альтернативном варианте реализации способ может быть выполнен эмиттером, способ, содержащий шаги, на которых в ответ на получение от центрального сервера ARP-пробы эмиттера на WireGuard интерфейсе гейтвея проверяют наличие эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера; в ответ на отсутствие на WireGuard интерфейсе гейтвея эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера, отправляют запрос на получение гейтвеем данных эмиттера, включающих IP-адрес эмиттера на уровне WireGuard, публичный ключ, UDP-адрес, для установки р2р соединения на центральный сервер; в ответ на получение от центрального сервера данных эмиттера, добавляют эмиттера в качестве пира в таблицу соседей гейтвея; отправляют на эмиттер ответ на ARP-пробу, идентифицирующий готовность гейтвея к установке р2р связи с эмиттером; декапсулируют, в ответ на получение по меньшей мере одного пакета исходящего трафика от эмиттера, по меньшей мере один пакет исходящего трафика; идентифицируют данные внешнего сервера, указанные в качестве данных получателя на уровне GRE; инкапсулируют гейтвеем по меньшей мере один пакет исходящего трафика; натируют по меньшей мере один пакет исходящего трафика IP-адресом гейтвея; отправляют по меньшей мере один натированный пакет исходящего трафика на внешний сервер; денатируют, в ответ на получение по меньшей мере одного пакета входящего трафика от внешнего сервера, по меньшей мере один пакет входящего трафика; инкапсулируют по меньшей мере один пакет входящего трафика на WireGuard уровне и GRE уровне, где по меньшей мере один IP-адрес, указанный на уровне WireGuard, отличается от по меньшей мере одного IP- адреса, указанного на уровне GRE; отправляют по меньшей мере один пакет входящего трафика на эмиттер. Запрос на получение гейтвеем данных эмиттера содержит IP-адрес гейтвея на уровне GRE. В по меньшей мере одной реализации выполняют регистрацию по меньшей мере одного эмиттера и по меньшей мере одного гейтвея на по меньшей мере одном центральном сервере посредством выдачи конфигурационного файла. В альтернативном способе реализации возможен подготовительный этап, на котором получают по меньшей мере одним гейтвеем конфигурационный файл от по меньшей мере одного центрального сервера. С помощью полученного конфигурационного файла выполняют конфигурацию интерфейсов на WireGuard уровне и GRE уровне. В случае получения запроса на переход на резервный маршрут от эмиттера выполняют переход на резервный маршрут через центральный сервер.

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

Заявленное решение также осуществляется за счет системы маршрутизации трафика внутри распределенной сети для анализа потенциально вредоносного контента, где распределенная сеть реализована посредствам двухуровневого туннелирования, включающего: уровень WireGuard и уровень GRE. Система представлена по меньшей мере одним эмиттером выполняющим шаги на, которых передают запрос на получение эмиттером данных гейтвея, включающих IP-адрес гейтвея на уровне WireGuard, публичный ключ, UDP-адрес, на центральный сервер по меньшей мере один эмиттер является пиром распределенной сети для анализа вредоносного контента и получения инкапсулированных пакетов на уровнях WireGuard и GRE; по меньшей мере один центральный сервер хранит таблицу соседей и является сервером для настройки ускоренного туннелирования между пирами; по меньшей мере один гейтвей является пиром распределенной сети для натирования по меньшей мере одного пакета исходящего трафика и денатирования по меньшей мере одного пакета входящего трафика; в ответ на получение от центрального сервера данных гейтвея, добавляют гейтвей в качестве пира на WireGuard интерфейс эмиттера; передают на центральный сервер ARP-пробу, где ARP-проба идентифицирует готовность эмиттера к установке р2р связи с гейтвеем; в ответ на получение на эмиттере ответа на ARP-пробу обновляют данные гейтвея в таблице соседей на эмиттере; отправляют эмиттером по меньшей мере один пакет исходящего трафика на гейтвей для натирования, где по меньшей мере один пакет исходящего трафика содержит два уровня инкапсуляции поверх транспортного протокола; извлекают, в ответ на получение по меньшей мере одного пакета входящего трафика от гейтвея, из по меньшей мере одного пакета входящего трафика потенциально вредоносный контент; анализируют потенциально вредоносный контент и добиваются его детонации. Данная система содержит IP-адрес гейтвея на уровне GRE. Упомянутые IP-адреса включают: IP-адрес в сети Интернет, IP-адрес на уровне Wireguard, IP-адрес на уровне GRЕ. Описываемая система может быть реализована также посредством подготовительного этапа, на котором выполняют регистрацию по меньшей мере одного эмиттера и по меньшей мере одного гейтвея на по меньшей мере одном центральном сервере посредством выдачи конфигурационного файла. Система предполагает получение эмиттером конфигурационного файла от по меньшей мере одного центрального сервера. Интерфейсы могут быть заранее сконфигурированы на уровне WireGuard и GRE с помощью конфигурационных файлов на подготовительном этапе. В ответ на превышение временного интервала на получение ARP-ответа высылают повторный ARP-запрос. В ответ на превышение лимита отправки повторных ARP-запросов выполняют переход эмиттера на резервный маршрут через центральный сервер. С эмиттера на гейтвей отправляют запрос на переход на резервный маршрут.

В другом реализации система ускоренного туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения, распределенная сеть реализованная с помощью двухуровневого туннелирования, включающего уровень WireGuard соединения и уровень GRE соединения, система, реализованная с помощью по меньшей мере одного гейтвея, система по которой в ответ на получение от центрального сервера ARP-пробы эмиттера на WireGuard интерфейсе гейтвея проверяют наличие эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера; в ответ на отсутствие на WireGuard интерфейсе гейтвея эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера, отправляют запрос на получение гейтвеем данных эмиттера, включающих IP-адрес эмиттера на уровне WireGuard, публичный ключ, UDP-адрес, для установки р2р соединения на центральный сервер; в ответ на получение от центрального сервера данных эмиттера, добавляют эмиттера в качестве пира в таблицу соседей гейтвея; отправляют на эмиттер ответ на ARP-пробу, идентифицирующий готовность гейтвея к установке р2р связи с эмиттером; декапсулируют, в ответ на получение по меньшей мере одного пакета исходящего трафика от эмиттера, по меньшей мере один пакет исходящего трафика; идентифицируют данные внешнего сервера, указанные в качестве данных получателя на уровне GRE; инкапсулируют гейтвеем по меньшей мере один пакет исходящего трафика; натируют по меньшей мере один пакет исходящего трафика IP-адресом гейтвея; отправляют по меньшей мере один натированный пакет исходящего трафика на внешний сервер; денатируют, в ответ на получение по меньшей мере одного пакета входящего трафика от внешнего сервера, по меньшей мере один пакет входящего трафика; инкапсулируют по меньшей мере один пакет входящего трафика на WireGuard уровне и GRE уровне, где по меньшей мере один IP-адрес, указанный на уровне WireGuard, отличается от по меньшей мере одного IP-адреса, указанного на уровне GRE; отправляют по меньшей мере один пакет входящего трафика на эмиттер. Запрос на получение гейтвеем данных эмиттера содержит IP-адрес гейтвея на уровне GRE. Регистрацию эмиттеров иди гейтвеев на центральном сервере выполняют посредством выдачи конфигурационного файла. В не ограничивающем примере реализации система может быть выполнять подготовительный этап, на котором получают по меньшей мере одним гейтвеем конфигурационный файл от по меньшей мере одного центрального сервера. С помощью полученного конфигурационного файла выполняют конфигурацию интерфейсов на WireGuard уровне и GRE уровне. В ответ на получение запроса на переход на резервный маршрут от эмиттера выполняют переход на резервный маршрут через центральный сервер.

Еще в одной альтернативно реализации система ускоренного туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения, распределенная сеть реализованная с помощью двухуровневого туннелирования, включающего уровень WireGuard соединения и уровень GRE соединения, способ, реализованный с помощью по меньшей мере одного центрального сервера, система по которой в ответ на получение на центральном сервере ARP-пробы от по меньшей мере одного эмиттера, проверяют, что IP-адрес эмиттера принадлежит в подгруппе эмиттеров и IP-адрес гейтвея принадлежит к подгруппе гейтвеев в ответ на то, что IP-адрес эмиттера принадлежит в подгруппе эмиттеров и IP-адрес гейтвея принадлежит к подгруппе гейтвеев пересылают ARP-пробу на гейтвей. Регистрацию по меньшей мере одного эмиттера и по меньшей мере одного гейтвея на по меньшей мере одном центральном сервере выполняют посредством выдачи конфигурационного файла.

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

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

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

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

Фиг. 3 иллюстрирует подготовительную стадию способа.

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

Фиг. 4Б иллюстрирует передачу входящего трафика на рабочей стадии.

Фиг. 5 иллюстрирует алгоритм установки р2р соединения между эмиттером и гейтвеем.

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

Фиг. 6Б иллюстрирует передачу входящего трафика на рабочей стадии при ускоренном туннелировании.

Фиг. 7 иллюстрирует алгоритм совместного перехода пиров на резервный маршрут через центральный сервер.

Фиг. 8 иллюстрирует гейтвей в локальной сети клиента.

Фиг. 9 иллюстрирует схему вычислительного устройства.

ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

Рассмотрим пример. Банк "X" обратился к компании "G" с запросом на предоставление услуг в области кибербезопасности, а именно на услуги аутсорс-анализа подозрительного контента, поступающего из внешних ресурсов. В этом случае компания "G" может предоставить банку возможность использования своего полигона. Компания "G" предоставляет одну или несколько входящих в состав полигона изолированных сред ("песочниц") для обслуживания запроса банка "X". Распределенная сеть полигона устроена таким образом, что по запросу от банка "X" строится маршрут до одной или нескольких находящихся в полигоне изолированных сред, и подозрительный трафик от банка "X" анализируется в этих изолированных средах. Туннелирование внутри распределенной сети реализовано таким образом, что на выходе из данной сети происходит натирование каждого пакета исходящего трафика и в качестве отправителя указывается IP-адрес банка "X". Таким образом, злоумышленник, направивший в адрес банка "X" вредоносный контент, например, вредоносный файл или ссылку на вредоносный сайт, в результате анализа и детонации (срабатывания) данного файла или перехода по ссылке будет видеть обращение к своему серверу с IP-адреса банка "X", а не с IP-адреса полигона.

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

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

Центральный сервер может также использоваться для работы системы в резервном режиме. Резервный режим может запускаться, если произошел сбой, например пиры не имеют IP-адресов для отправки запросов. В резервном режиме может выполняться маршрутизация трафика через центральный сервер. В распределенной сети центральный сервер является шлюзом для пиров. Шлюз в резервном режиме используется пирами для передачи пакетов адресату, IP-адреса которого они не знают. Таким образом, когда гейтвею из локальной сети компании "X" нужно переслать пакет данных для анализа на одном из устройств, входящих в состав инфраструктуры компании "G", он пересылает пакет на центральный сервер, который, в свою очередь, выполнен с возможностью пересылать полученный пакет на соответствующий данному гейтвею эмиттер. Пересылка пакетов реализуется посредством туннелирования любым общеизвестным образом.

На Фиг. 1 представлена схема возможной реализации описываемой технологии. Как показано на Фиг. 1, полигон 100 для анализа вредоносного контента содержит центральный сервер 101 и множество пиров. На центральном сервере 101 хранится таблица соседей 102. Таблица соседей 102 содержит информацию, необходимую для построения маршрутов между пирами; она может быть реализована общеизвестным образом, как база данных любого подходящего формата, например таблица МАС-адресов. В одном из примеров реализации таблицы соседей могут также храниться на эмиттерах 110 и гейтвеях 120.

Пирами в данной распределенной сети являются эмиттеры 110 и гейтвей 120. На эмиттере 115, как было ранее упомянуто, может быть установлена изолированная среда для детонации подозрительного контента (на чертеже условно не показана). Гейтвей 125 - это вычислительное устройство, которое находится в локальной сети 122 компании-клиента; оно выполнено с возможностью заменять IP-адрес отправителя на IP-адрес клиента.

Маршрутизация в распределенной сети настроена таким образом, что ни один из гейтвеев 120, такой как гейтвей 125, не может обмениваться данными с другими гейтвеями 120. Так же как и ни один из эмиттеров 110, например эмиттер 115, не может обмениваться данными с другими эмиттерами 110. При этом от каждого из эмиттеров 110 можно проложить маршрут до каждого из гейтвеев 120 и обратно. В одном примере реализации маршрут может быть проложен напрямую от гейтвея, такого как гейтвей 125, к эмиттеру, такому как эмиттер 115 и обратно. В другом примере реализации маршрут может быть проложен через центральный сервер 101.

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

Важно отметить, что для реализации описываемого изобретения центральный сервер должен иметь публичный IP-адрес. В то время как гейтвей 125 может находиться за натом 121 и не иметь публичного IP-адреса. Так же, как и эмиттер 115 может находиться за натом 116 и не иметь публичного IP-адреса.

В альтернативном варианте реализации и гейтвей 125, и эмиттер 115 могут иметь свои публичные IP-адреса.

Далее будет подробно описан маршрут, по которому в ходе реализации вышеназванного примера с банком "X" и компанием "G" могут передаваться пакеты данных в распределенной сети 100. На эмиттере 115 может быть сформирован запрос к внешнему серверу 130, который находится за пределами распределенной сети 100. Этот запрос может быть, например, переходом по внешней ссылке из электронного письма, полученного в установленной на данном эмиттере 115 изолированной среде, а внешний сервер 130 в таком случае может являться командным сервером злоумышленника. Эмиттер 115 отправляет запрос в виде пакета исходящих данных на центральный сервер 101. Центральный сервер 101 пересылает пакет исходящих данных на гейтвей 125. Гейтвей 125 выполняет подмену IP-адреса отправителя на IP-адрес локальной сети, в которой этот гейтвей 125 расположен, и пересылает пакет на внешний сервер 130. Вследствие описанной подмены адрес отправителя пакета (который может быть проанализирован программой злоумышленника на внешнем сервере 130) не будет иметь ничего общего с адресом эмиттера 115, поэтому злоумышленнику не станет известно, что открытие письма и переход по ссылке произошли в изолированной среде, а не на одном из устройств атакуемой локальной сети.

Таким образом, когда внешний сервер 130 получает пакет, пришедший из распределенной сети 100, внешний сервер 130 определяет IP-адрес локальной сети клиента как адрес отправителя. Благодаря выполнению подмены IP-адреса, распределенная сеть 100 будет имитировать локальную сеть клиента. Внешний сервер 130, если он принадлежит злоумышленникам, в ответ на запрос (переход по ссылке) высылает вредоносный контент, то есть начинается загрузка вредоносной программы, на которую вела ссылка. Пакет входящего трафика, содержащий в себе вредоносный контент, передается на гейтвей 125. Гейтвей 125 пересылает пакет на центральный сервер 101. Центральный сервер 101 пересылает пакет на эмиттер 115. Таким образом, эмиттер 115 получает пакет, содержащий вредоносный контент. Эмиттер 115 распаковывает полученный пакет в изолированной среде и производит его анализ.

В приведенном примере происходит следующее. В локальной сети банка "X" получают электронное письмо от неизвестного отправителя. Письмо содержит ссылку для загрузки файла. Письмо перенаправляют на анализ в изолированную среду, установленную на эмиттере 115. На эмиттере 115 выполняют переход по содержащейся в письме ссылке, то есть запрос к внешнему серверу 130 для загрузки файла. Запрос автоматически пересылается сначала на центральный сервер 101, потом на гейтвей 125. Гейтвей 125, установленный в атакуемой локальной сети, подменяет IP-адрес эмиттера 115 на IP-адрес локальной сети банка "X" и пересылает пакет на внешний сервер 130, возможно, принадлежащий злоумышленнику.

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

Пересылка пакетов между акторами сети: эмиттером 115, центральным сервером 101 и гейтвеем 125 происходит благодаря туннелированию, переупаковке пакета на нескольких уровнях передачи данных. В предлагаемой технологии реализовано два интерфейса передачи данных поверх интернет-соединения - это Wireguard и GRE. Wireguard и GRE - это протоколы взаимодействия и программное обеспечение для реализации данных протоколов. Оба вида программного обеспечения имеют интерфейсы, посредством которых происходит их конфигурация.

Далее данный способ будет описан детально. Способ состоит из двух стадий: подготовительной и рабочей. На подготовительной стадии происходит настройка интерфейсов и настройка маршрутов между эмиттером 115 и соответствующим ему гейтвеем 125, IP-адреса эмиттера 115 и соответствующего ему гейтвея 125 прописываются в таблицу соседей 102 на центральном сервере 101.

Подготовительная стадия представлена на Фиг. 3. Она состоит из 7 шагов. Далее каждый из шагов будет подробно описан.

Подготовительная стадия в приведенном примере выполняется на центральном сервере 101, на эмиттере 115 и на гейтвее 125, находящемся в локальной сети 122 компании "X".

Подготовительная стадия 300 начинается с выполнения шага 310. На шаге 310 на центральном сервере 101 создают два интерфейса: Wireguard и GRE. Для интерфейса GRE указывают, что он работает поверх интерфейса Wireguard. При данной настройке пакеты в настроенной распределенной сети будут инкапсулироваться в следующей очередности: UDP, Wireguard, GRE.

Затем на шаге 320 на центральном сервере 101 на интерфейсе Wireguard генерируют приватный ключ и способ переходит к шагу 330.

На шаге 330 на центральном сервере 101 для интерфейса Wireguard с помощью соответствующей команды задают порт слушания, то есть указывают в конфигурационном файле, какой именно порт сервера будет выполнять прослушивание входящих соединений Затем способ переходит к шагу 340, на котором на центральном сервере 101 генерируют конфигурационные файлы. Конфигурационные файлы генерируют для всех эмиттеров 110 и для всех гейтвеев 120, в частности, для эмиттера 115 и гейтвея 125.

В конфигурационный файл центрального сервера для интерфейсов Wireguard и GRE добавляют IP-адреса центрального сервера. На уровне Wireguard центральный сервер 101 имеет два IP-адреса, один из которых предназначен для взаимодействия с гейтвеями 120, второй - для взаимодействия с эммитерами 110.

Также в конфигурационном файле центрального сервера указывают подсети. Подсети - это списки IP-адресов, из числа которых пирам будут выдаваться IP-адреса при их последующей конфигурации. Указание подсетей в конфигурационном файле центрального сервера определяет возможность центрального сервера 101 получать пакеты от заданной подсети и отправлять или передавать пакеты в заданные подсети. Важно отметить, что эмиттеры 110 и гейтвей 120 относятся к разным подсетям на уровне Wireguard. Выдача разных IP-адресов центральным сервером 101 на уровне Wireguard из непересекающихся подсетей для эмиттеров 110 и гейтвеев 120 позволяет настроить маршруты таким образом, чтобы эмиттеры 110 могли передавать пакеты гейтвеям 120 и не могли передавать пакеты другим эмиттерам 110. Равно как и гейтвей 120 могли передавать пакеты эмиттерам 110 и не могли передавать пакеты гейтвеям 120. Это нужно для того, чтобы разные владельцы разных локальных сетей, например, конкурирующие банки, не могли получать доступ к локальной сети друг друга и производить натирование через гейтвей конкурентов.

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

На шаге 350 выполняют настройку маршрутов на центральном сервере 101. Маршруты на центральном сервере 101 настраивают таким образом, чтобы все пакеты, которые отсылает центральный сервер 101 в подсеть эмиттеров 110, были отправлены с IP-адреса центрального сервера 101 для гейтвеев 120. И наоборот все пакеты, которые центральный сервер 101 отсылает в подсеть гейтвеев 120, были отправлены с IP-адреса для эмиттеров 110.

На Фиг. 2 в качестве неограничивающего примера показано, что эмиттеры 110 относятся к подсети 10.100.128.0/17, а гейтвей 120 относятся к подсети 10.100.0.0/17. На уровне Wireguard за центральным сервером 101 закреплен IP-адрес 10.100.0.1/17 для взаимодействия с подсетью эмиттеров 10.100.128.0/17 и IP-адрес 10.100.128.1/17 для взаимодействия с подсетью гейтвеев 10.100.0.0/17. Каждый из эмиттеров из подсети 10.100.128.0/17 может взаимодействовать с каждым из гейтвеев из подсети 10.100.0.0/17 напрямую или через центральный сервер.

На уровне GRE центральный сервер 101 имеет один IP-адрес, а IP-адреса гейтвеев 120 и эмиттеров 110 не разнесены в разные подсети, потому что уровень GRE работает поверх уровня Wireguard, который, в свою очередь, работает поверх уровня UDP. Это значит, что все пакеты сначала обрабатываются на уровне UDP, затем на уровне Wireguard, и лишь затем обрабатываются на уровне GRE.

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

• генерируют приватный ключа для пира

• генерируют публичный ключ на основании приватного ключа, сгенерированного ранее

• аллоцируют (резервируют) IP-адреса для пира на уровне Wireguard

• добавляют пары из публичного ключа и IP-адреса пира в интерфейс Wireguard

• аллоцируют (резервируют) IP-адреса для пира на уровне GRE

• добавляют соответствия IP-адресов пира на уровнях Wireguard и GRE в таблицу соседей

• добавляют в базу данных соответствия публичного ключа IP-адресов на уровнях Wireguard и GRE.

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

Ответом на запрос о регистрации пира на центральном сервере 101 является конфигурационный файл, содержащий приватный ключ, пару IP-адресов на уровнях Wireguard и GRE, информацию о центральном сервере, включающую его публичный ключ, а также адрес и UDP-порт, на котором центральный сервер 101 слушает входящие Wireguard-пакеты. Получив конфигурационный файл, его любым общеизвестным образом передают на подлежащий конфигурации пир по закрытому каналу связи. На этом шаг 360 завершается и метод переходит к следующему шагу 370.

На шаге 370 выполняют конфигурацию пиров, то есть эмиттера 115 и гейтвея 125. Запускают посредством скрипта утилиту wg-quick. Утилита поднимает WireGuard интерфейс и настраивает его таким образом, как это указано в конфигурационном файле. Ниже представлен пример конфигурационного файла эмиттера, такого, например, как эмиттер 115.

Ниже представлен пример конфигурационного файла гейтвея, такого, например, как гейтвей 125.

В процессе применения конфигурационного файла эмиттера посредством утилиты wg-quick выполняют следующие действия:

• создают Wireguard-интерфейс

• присваивают ему приватный ключ, указанный в конфигурационном файле

• присваивает IP-адрес Wireguard-интерфейсу

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

• создают GRE-интерфейс, работающий поверх Wireguard-интерфейса, созданного ранее

• присваивают GRE-интерфейсу указанный IP-адрес

• добавляют в таблицу соседей соответствие между IP-адресами центрального сервера на уровнях Wireguard и GRE

• устанавливают маршруты до всех адресов в подсети GRE через шлюз (центральный сервер)

• добавляют правила файрволла (firewall), разрешающие прием и отправку пакетов через созданные Wireguard- и GRE-интерфейсы.

Для конфигурации эмиттера запуск конфигурационного файла выполняется на том вычислительном устройстве, например сервере, которое исполняет роль эмиттера 115.

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

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

На этом шаг 370 и подготовительная стадия 100 заканчиваются. Способ переходит к выполнению рабочей стадии 400.

Рабочая стадия 400 будет описана применительно к Фиг. 4А на примере отправки запроса от эмиттера 115 на внешний сервер 130 и применительно к Фиг. 4Б на примере получения ответа от внешнего сервера 130 на эмиттере 115.

Рабочая стадия 400 начинается, как показано на Фиг. 4А, с выполнения шага 410. На шаге 410 передают пакет исходящего трафика от эмиттера 115 на центральный сервер 101. Пакет исходящего трафика содержит полезную нагрузку, которая предназначена для внешнего сервера 130. На эмиттере 115 перед передачей пакета выполняют его инкапсуляцию, таким образом, что пакет имеет следующий вид:

• уровень полезной нагрузки;

• уровень GRE: в качестве IP-адреса отправителя указывают IP-адрес эмиттера на уровне GRE, в качестве IP-адреса получателя указывают IP-адрес внешнего сервера;

• уровень Wireguard: в качестве IP-адреса отправителя указывают IP-адрес эмиттера на уровне Wireguard, в качестве IP-адреса получателя указывают IP-адрес гейтвея на уровне Wireguard;

• уровень UDP. В UDP пакетах в заголовке в поле отправителя указывают WireGuard-порт эмиттера, в поле получателя указывают WireGuard порт центрального сервера;

• уровень Интернет-соединения: в качестве IP-адреса отправителя указывают локальный IP-адрес эмиттера, в качестве IP-адреса получателя указывают публичный IP-адрес центрального сервера.

В одном из возможных способов реализации эмиттер 115 может находиться за натом 116 и не иметь своего публичного IP-адреса. В этом случае в пакете на уровне Интернет-соединения в качестве IP-адреса отправителя указывают локальный IP-адрес эмиттера. А при отправке пакета выполняют натирование и локальный IP-адрес эмиттера, указанный в качестве IP-адреса отправителя на уровне Интернет-соединения, заменяют на публичный IP-адрес эмиттера.

В другом возможном способе реализации эмиттер 115 может иметь публичный IP-адрес. В этом случае данный публичный IP-адрес указывается в качестве отправителя на уровне Интернет-соединения и натирование не выполняется.

Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 410 завершается и способ переходит к шагу 415.

В рассматриваемом примере на эмиттере 115 выполняют анализ данных, полученных из локальной сети (122, в соответствии с Фиг. 1) банка "X". Электронное письмо, направленное неизвестным отправителем сотруднику банка "X", перенаправляют для анализа в компанию "G", а именно в изолированную среду на эмиттере 115. На эмиттере 115 выполняют переход по ссылке (запрос) на внешний сервер 130, причем выполнение этого запроса может означать загрузку с сервера 130 потенциально вредоносного файла. Для того, чтобы переданный в ответ на запрос потенциально вредоносный файл с внешнего сервера 130 поступил на эмиттер 115, выполненный с возможностью анализа подобных файлов, а не на машину пользователя в локальной сети 122, запрос формируют на эмиттере 115.

На шаге 415 на центральном сервере 101 получают пакет данных от эмиттера 115. В ответ на получение пакета на центральном сервере 101 выполняют его декапсуляцию и идентифицируют IP-адрес получателя на уровне Wireguard. Иными словами, на шаге 415 на центральном сервере компании "G" получают очередной пакет данных от того эмиттера 115, который был конфигурирован для анализа подозрительного трафика, поступающего из локальной сети 122 банка "X".

Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 415 завершается и способ переходит к выполнению шага 420.

На шаге 420 в ответ на обнаружение, на шаге 415, в качестве получателя на уровне Wireguard IP-адреса гейтвея 125, выполняют пересылку пакета с центрального сервера 101 на гейтвей 125. На центральном сервере 101 выполняют инкапсуляцию пакета таким образом, что пакет имеет следующий вид:

• уровень полезной нагрузки;

• уровень GRE: в качестве IP-адреса отправителя указывают IP-адрес эмиттера на уровне GRE, в качестве IP-адреса получателя указывают IP-адрес внешнего сервера 130;

• уровень Wireguard: в качестве IP-адреса отправителя указывают IP-адрес эмиттера на уровне Wireguard, в качестве IP-адреса получателя указывают IP-адрес гейтвея 125 на уровне Wireguard;

• уровень Интернет-соединения: в качестве IP-адреса отправителя указывают публичный IP-адрес центрального сервера 101, в качестве IP-адреса получателя указывают IP-адрес гейтвея 125.

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

В другом возможном способе реализации гейтвей 125 может иметь публичный IP-адрес. В этом случае данный публичный IP-адрес указывается в качестве отправителя на уровне Интернет-соединения и денатирование не выполняется.

Иными словами, на шаге 420 на центральном сервере компании "G" перенаправляют запрос, полученный от эмиттера 115, который был конфигурирован для работы с подозрительным трафиком банка "X", на гейтвей банка "X", находящийся в локальной сети 122 этого банка, для подмены IP-адреса.

Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 420 завершается и способ переходит к шагу 425.

На шаге 425 на гейтвее 125 получают пакет от центрального сервера 101. В ответ на получение пакета на гейтвее 125 выполняют декапсуляцию, идентифицируют IP-адрес получателя на уровне Wireguard, а также идентифицируют IP-адрес получателя на уровне GRE.

В приведенном примере на шаге 420 на гейтвее 125, находящемся в локальной сети 122 банка "X", получают от центрального сервера 101 компании "G" данные, содержащие как полезную нагрузку (запрос), так и IP-адреса получателя и отправителя на уровнях Wireguard и GRE, а также идентифицируют эти адреса.

Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 425 завершается и способ переходит к выполнению шага 430.

В ответ на обнаружение, на шаге 425, в качестве получателя на уровне GRE IP-адреса внешнего сервера 130, на шаге 430 выполняют пересылку пакета с гейтвея 125 на внешний сервер 130. При этом на гейтвее 125 выполняют натирование пакета таким образом, что пакет имеет следующий вид:

• уровень полезной нагрузки;

• уровень Интернет-соединения: в качестве IP-адреса отправителя указывают IP-адрес гейтвея 125, в качестве IP-адреса получателя указывают IP-адрес внешнего сервера 130.

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

В другом возможном способе реализации гейтвей 125 может иметь публичный IP-адрес. В этом случае данный публичный IP-адрес указывается в качестве отправителя на уровне Интернет-соединения и натирование не выполняется.

Иными словами, на шаге 425 натирование выполняется на гейтвее 125, установленном в локальной сети 122 банка "X". В результате натирования в пакете вместо IP-адреса компании "G", на эмиттере 115 которой был сформирован исходный запрос, будет указан IP-адрес гейтвея 125, принадлежащий адресному пространству локальной сети 122 банка "X". Таким образом, внешний вредоносный сервер 130 при получении пакета идентифицирует IP-адрес гейтвея 125 как принадлежащий атакуемой локальной сети 122 и произведет ожидаемое воздействие, например, вышлет потенциально вредоносный контент, такой как вредоносный файл.

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

На этом шаг 430 завершается и способ переходит к шагу 435, описанному далее со ссылкой на Фиг. 4Б.

На шаге 435 гейтвей 125 получает пакет входящего трафика от внешнего сервера 130. Пакет входящего трафика имеет следующий вид:

• уровень полезной нагрузки;

• уровень Интернет-соединения: в качестве IP адреса отправителя указан IP-адрес внешнего сервера 130, в качестве IP-адреса получателя указан IP-адрес гейтвея 125.

Получение пакета выполняется любым общеизвестным способом.

После получения пакета шаг 435 завершается и способ переходит к следующему шагу 440.

На шаге 440 на гейтвее 125 выполняют запрос к таблице маршрутизации и получают IP-адреса шлюза на уровне GRE, то есть IP-адрес центрального сервера на уровне GRE. Далее выполняют обращение к таблице соседей для получения IP-адреса центрального сервера на уровне WireGuard. Все эти действия выполняются общеизвестным образом, штатными средствами используемой на гейтвее 125 операционной системы.

После этого шаг 440 завершается и способ переходит к шагу 445.

На шаге 445 полученный на шаге 435 пакет пересылают на центральный сервер 101. Полученный пакет инкапсулируют таким образом, что он имеет следующий вид:

• уровень полезной нагрузки;

• уровень GRE: в качестве IP-адреса отправителя указывают IP-адрес внешнего сервера 130, в качестве IP-адреса получателя указывают IP-адрес эмиттера 115 на уровне GRE;

• уровень Wireguard: в качестве IP-адреса отправителя указывают IP-адрес гейтвея 125 на уровне Wireguard, в качестве IP-адреса получателя указывают IP-адрес центрального сервера 101 на уровне Wireguard;

• уровень Интернет-соединения: в качестве IP адреса отправителя указывают IP-адрес гейтвея 125, в качестве IP-адреса получателя указывают публичный IP-адрес центрального сервера 101.

В приведенном примере на шаге 445 полученный на гейтвее потенциально вредоносный файл будет переслан в компанию "G" для анализа, для чего он сначала поступит на центральный сервер 101.

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

На этом шаг 445 завершается и способ переходит к следующему шагу 450. На шаге 450 на центральном сервере 101 получают пакет входящего трафика от гейтвея 125. В ответ на получение пакета на центральном сервере 101 выполняют декапсуляцию, идентифицируют IP-адрес получателя на уровне Wireguard, идентифицируют IP-адрес получателя на уровне GRE.

Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 450 завершается и алгоритм переходит к выполнению шага 455.

В ответ на обнаружение, на шаге 450, в качестве получателя на уровне GRE IP-адреса эмиттера 115, на шаге 455 выполняют пересылку пакета с центрального сервера 101 на эмиттер 115. На центральном сервере 101 выполняют инкапсуляцию пакета таким образом, что пакет имеет следующий вид:

• уровень полезной нагрузки;

• уровень GRE: в качестве IP-адреса отправителя указывают IP-адрес внешнего сервера 130, в качестве IP-адреса получателя указывают IP-адрес эмиттера 115 на уровне GRE;

• уровень Wireguard: в качестве IP-адреса отправителя указывают IP-адрес центрального сервера 101 на уровне Wireguard, в качестве IP-адреса получателя указывают IP-адрес эмиттера 115 на уровне Wireguard;

• уровень Интернет-соединения: в качестве IP адреса отправителя указывают публичный IP-адрес центрального сервера 101, в качестве IP-адреса получателя указывают IP-адрес эмиттера 115.

Все перечисленные действия выполняют любым общеизвестным образом. На этом шаг 455 завершается и способ переходит к выполнению шага 460.

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

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

На этом шаг 460 и способ 400 завершается.

На Фиг. 5 представлен алгоритм установки р2р соединения 500 между эмиттером 115 и гейтвеем 125 распределенной сети 100. Установка р2р соединения 500 начинается с шага 510.

На шаге 510 с эмиттера 115 на внутренний API центрального сервера высылают GRE IP-адрес гейтвея и запрашивают WireGuard IP-адрес, публичный ключ, UDP-адрес, с которых гейтвей 125 производил подключение к центральному серверу. После получения запрошенных сведений гейтвей 125 добавляют в качестве пира на WireGuard-интерфейс. На этом шаг 510 заканчивается и алгоритм переходит к шагу 520.

На шаге 520 с эмиттера 115 на WireGuard IP-адрес центрального сервера посылают аналог широковещательной ARP-пробы, при этом указывают значение REQUESTENABLE в поле OPERATION. На этом шаг 520 завершается и алгоритм 500 переходит к шагу 530.

На шаге 530 на центральном сервер получают ARP-пробу от эмиттера 115 и пересылают ее на WireGuard IP-адрес гейтвея, сверяясь по таблице соседей. На этом шаг 530 завершается и алгоритм переходит к шагу 540.

На шаге 540 на гейтвее получают ARP-пробу, содержащую значение REQUEST ENABLE в поле OPERATION от эмиттера 115, переданную на шаге 530 через центральный сервер.

В ответ на получение ARP-пробы на эмиттере 115 на шаге 542 проверяют, добавлен ли эмиттер 115 с соответствующим IP-адресом на WireGuard интерфейс гейтвея.

Если эмиттер 115 с соответствующим IP-адресом добавлен на WireGuard интерфейс гейтвея, то способ переходит к шагу 550.

Если эмиттер 115 не добавлен на WireGuard интерфейс гейтвея, то на шаге 544 с гейтвея отправляют запрос на получение WireGuard IP-адреса, публичного ключа и UDP-адреса.

Запрос высылают на API центрального сервера. Запрос содержит GRE IP-адрес эмиттера 115, ранее полученный в ARP-пакете. На этом шаг 544 завершается и алгоритм переходит к шагу 546.

На шаге 546 на гейтвее добавляют эмиттер 115 в качестве пира на WireGuard интерфейс, после чего способ переходит к шагу 550.

На шаге 550 отсылают на эмиттер 115 напрямую стандартный ARP ответ. На этом шаг 550 завершается и алгоритм переходит к шагу 560.

На шаге 560 на эмиттере 115 получают ARP-ответ от гейтвея и обновляют соответствующую запись в таблице соседей. На этом р2р-соединение считается установленным. Шаг 560 и алгоритм 500 завершается.

Для каждого ARP-запроса устанавливается лимит повторных попыток отправки и определенный временной интервал в качестве таймаута для получения ответа. Если ответ не был получен в течение заданного интервала и были израсходованы все попытки, эмиттер 115 выполняет переход на резервный маршрут через центральный сервер. Перед переходом на резервный маршрут на гейтвей 125 высылают уведомление о неудачной попытке установить р2р-соединение. Когда на гейтвее будет получено уведомление о неудачной попытке установить р2р-соединение, гейтвей 125 также будет переведен на резервный маршрут через центральный сервер.

Далее со ссылкой на Фиг. 6А будет описана Рабочая стадия 600, иллюстрирующая ускоренное туннелирование, на примере отправки запроса от эмиттера 115 на внешний сервер 130 и применительно к Фиг. 6Б на примере получения ответа от внешнего сервера 130 на эмиттере 115.

Рабочая стадия 600 начинается, как показано на Фиг. 6А, с выполнения шага 610. На шаге 610 передают пакет исходящего трафика от эмиттера 115 на гейтвей 125. Пакет исходящего трафика содержит полезную нагрузку, которая предназначена для внешнего сервера 130. На эмиттере 115 перед передачей пакета выполняют его инкапсуляцию, таким образом, что пакет имеет следующий вид:

• уровень полезной нагрузки;

• уровень GRE: в качестве IP-адреса отправителя указывают ГР-адрес эмиттера 115 на уровне GRE, в качестве IP-адреса получателя указывают IP-адрес гейтвея 125 на уровне GRE;

• уровень Wireguard: в качестве IP-адреса отправителя указывают IP-адрес эмиттера 115 на уровне Wireguard, в качестве IP-адреса получателя указывают IP-адрес гейтвея 125 на уровне Wireguard;

• уровень Интернет-соединения: в качестве IP-адреса отправителя указывают публичный IP-адрес эмиттера 115, в качестве IP-адреса получателя указывают IP-адрес внешнего сервера.

В одном из возможных способов реализации эмиттер 115 может находиться за натом 116 и не иметь своего публичного IP-адреса. В этом случае в пакете на уровне Интернет-соединения в качестве IP-адреса отправителя указывают локальный IP-адрес эмиттера 115. А при отправке пакета выполняют натирование и локальный IP-адрес эмиттера 115, указанный в качестве IP-адреса отправителя на уровне Интернет-соединения, заменяют на публичный IP-адрес эмиттера 115.

В другом возможном способе реализации эмиттер 115 может иметь публичный IP-адрес. В этом случае данный публичный IP-адрес указывается в качестве отправителя на уровне Интернет-соединения и натирование не выполняется.

Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 610 завершается и способ переходит к шагу 615. На шаге 615 на гейтвее 125 получают пакет данных от эмиттера 115. В ответ на получение пакета на гейтвее 125 выполняют его декапсуляцию и идентифицируют IP-адрес получателя на уровне Интернет-соединения. Все перечисленные действия выполняют любым общеизвестным образом.

На этом шаг 615 завершается и способ переходит к выполнению шага 620.

На шаге 620 в ответ на обнаружение, на шаге 615, в качестве получателя на уровне Интернет-соединения IP-адреса внешнего сервера 130, выполняют пересылку пакета с гейтвея 125 на внешний сервер 130. На гейтвее 125 выполняют инкапсуляцию пакета таким образом, что пакет имеет следующий вид:

• уровень полезной нагрузки;

• уровень Интернет-соединения: в качестве IP-адреса отправителя указывают IP-адрес гейтвея 125, в качестве IP-адреса получателя указывают IP-адрес внешнего сервера 130.

На этом шаг 620 завершается и алгоритм переходит к шагу 625.

На шаге 625 на гейтвее получают пакет входящего трафика от внешнего сервера 130. Пакет входящего трафика имеет следующий вид:

• уровень полезной нагрузки;

• уровень Интернет-соединения: в качестве IP адреса отправителя указан IP-адрес внешнего сервера 130;

• в качестве IP-адреса получателя указан IP-адрес гейтвея 125. Получение пакета выполняется любым общеизвестным способом.

После получения пакета шаг 625 завершается и способ переходит к следующему шагу 630.

На шаге 630 на гейтвее 125 выполняют запрос к таблице маршрутизации и получают IP-адреса шлюза на уровне GRE, то есть IP-адрес эмиттера 115 на уровне GRE. Далее выполняют обращение к таблице соседей для получения IP-адреса эмиттера 115 на уровне WireGuard. Все эти действия выполняются общеизвестным образом, штатными средствами используемой на гейтвее 125 операционной системы.

После этого шаг 630 завершается и способ переходит к шагу 635.

На шаге 635 полученный на шаге 625 пакет пересылают на эмиттер 115. Полученный пакет инкапсулируют таким образом, что он имеет следующий вид:

• уровень полезной нагрузки;

• уровень GRE: в качестве IP-адреса отправителя указывают IP-адрес гейтвея, в качестве IP-адреса получателя указывают IP-адрес эмиттера 115 на уровне GRE;

• уровень Wireguard: в качестве IP-адреса отправителя указывают IP-адрес гейтвея 125 на уровне Wireguard, в качестве IP-адреса получателя указывают IP-адрес эмиттера 115 на уровне Wireguard;

• уровень Интернет-соединения: в качестве IP адреса отправителя указывают IР-адрес внешнего сервера 130, в качестве IP-адреса получателя указывают публичный IP-адрес эмиттера 115.

На этом шаг 635 завершается и способ переходит к шагу 640.

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

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

На этом шаг 640 и способ 600 завершается.

Далее со ссылкой на Фиг. 7 будет описан алгоритм 700 совместного перехода на резервный маршрут через центральный сервер.

На шаге 710 с эмиттера 115 отправляют ARP-запрос на гейтвей 125 по уже имеющемуся WireGuard IP-адресу гейтвея. На этом шаг 710 завершается и алгоритм 700 переходит к следующему шагу.

На шаге 720 проверяют, был ли на эмиттере 115 получен ARP ответ. В ответ на то, что ответ был получен, алгоритм 700 завершается, то есть переход на резервный маршрут через центральный сервер не выполняется.

В ответ на то, что ARP-ответ не был получен на эмиттере 115, на шаге 722 проверяют, достигнут ли заранее установленный лимит повторных попыток получения ARP-ответа.

Если лимит повторных попыток не достигнут, то алгоритм 700 возвращается к шагу 710.

Если лимит повторных попыток достигнут, то есть заранее заданное количество дополнительных ARP-запросов также не увенчались успехом, то на шаге 724 с WireGuard-интерфейса эмиттера 115 удаляют гейтвей 125 и посылают аналог широковещательного ARP-запроса на центральный сервер. В поле OPERATION в ARP-запросе указывают REQUESTDISABLE. На этом шаг 724 завершается и алгоритм переходит к шагу 730.

На шаге 730 на центральном сервере получают ARP-пакет от эмиттера 115 и пересылают его на WireGuard-IP адрес гейтвея, сверяясь по таблице соседей. На этом шаг 730 завершается и алгоритм переходит к шагу 740.

На шаге 740 на гейтвее получают ARP-запрос, в котором в поле OPERATION указано REQUEST DISABLE. В ответ на получение данного запроса с WireGuard-интерфейса гейтвея удаляют эмиттер 115 с соответствующим IP-адресом и обновляют запись в таблице соседей. На этом шаг 740 завершается и алгоритм переходит к шагу 650.

На шаге 750 с гейтвея на эмиттер 115 отправляют стандартный ARP-ответ по маршруту через центральный сервер. На этом шаг 750 завершается и алгоритм переходит к шагу 760.

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

На Фиг. 8 изображен один из примеров реализации гейтвея 125. Гейтвей 125 находится в локальной сети клиента 122. Гейтвей 125 содержит модуль хранения информации 811, модуль анализа 812, модуль связи 813. Модуль хранения информации 811 выполнен с возможностью хранения потенциально вредоносного контента, хранения конфигурационного файла, баз данных. Модуль анализа 812 выполнен с возможностью анализа потенциально вредоносного контента, а также с возможность определения отправителя пакета. Модуль связи 813 выполнен с возможностью получать данные и отправлять данные.

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

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

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

В общем случае устройство (900) содержит такие компоненты, как: один или более процессоров (901), по меньшей мере одну память (902), средство хранения данных (903), интерфейсы ввода/вывода (904), средство ввода-вывода (905), средства передачи данных (906).

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

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

Средство хранения данных (903) может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (903) позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов, промежуточных данных, списков, баз данных и т.п.

Интерфейсы (904) представляют собой стандартные средства для подключения и работы, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.

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

В качестве средств ввода-вывода данных (905) может использоваться клавиатура. Помимо клавиатуры, в составе средств ввода-вывода данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

Средства сетевого взаимодействия (906) выбираются из устройств, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п.С помощью средств (906) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.

Компоненты устройства (900) сопряжены посредством общей шины передачи данных (910).

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

Способ ускоренного туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения, содержащий: подготовительный этап, на котором: регистрируют эмиттер и гейтвей на центральном сервере посредством выдачи конфигурационного файла, который получают эмиттером от центрального сервера; и рабочий этап, на котором: передают запрос на получение эмиттером данных гейтвея на центральный сервер, где эмиттер является пиром распределенной сети для анализа вредоносного контента и получения инкапсулированных пакетов на уровнях WireGuard и GRE; центральный сервер хранит таблицу соседей и является сервером для настройки ускоренного туннелирования между пирами; гейтвей является пиром распределенной сети для натирования пакета исходящего трафика и денатирования пакета входящего трафика; добавляют гейтвей в качестве пира на WireGuard интерфейс эмиттера; передают на центральный сервер ARP-пробу; обновляют данные гейтвея в таблице соседей на эмиттере; отправляют пакет исходящего трафика на гейтвей для натирования; извлекают из пакета входящего трафика потенциально вредоносный контент; анализируют потенциально вредоносный контент и добиваются его детонации. 6 н. и 18 з.п. ф-лы, 11 ил.

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

подготовительный этап, на котором:

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

- получают по меньшей мере одним эмиттером конфигурационный файл от по меньшей мере одного центрального сервера,

рабочий этап, на котором:

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

- по меньшей мере один эмиттер является пиром распределенной сети для анализа вредоносного контента и получения инкапсулированных пакетов на уровнях WireGuard и GRE;

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

- по меньшей мере один гейтвей является пиром распределенной сети для натирования по меньшей мере одного пакета исходящего трафика и денатирования по меньшей мере одного пакета входящего трафика;

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

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

- в ответ на получение на эмиттере ответа на ARP-пробу обновляют данные гейтвея в таблице соседей на эмиттере;

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

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

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

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

3. Способ по п. 1, где IP-адреса включают:

- IP-адрес в сети Интернет;

- IP-адрес на уровне Wireguard;

- IP-адрес на уровне GRE.

4. Способ по п. 1, включающий конфигурацию интерфейсов на WireGuard уровне и GRE уровне с помощью полученного конфигурационного файла.

5. Способ по п. 1, где в ответ на превышение временного интервала на получение ARP-ответа высылают повторный ARP-запрос.

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

7. Способ по п. 6, где с эмиттера на гейтвей отправляют запрос на переход на резервный маршрут.

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

подготовительный этап, на котором:

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

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

рабочий этап, на котором:

- в ответ на получение от центрального сервера ARP-пробы эмиттера на WireGuard интерфейсе гейтвея проверяют наличие эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера;

- в ответ на отсутствие на WireGuard интерфейсе гейтвея эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера, отправляют запрос на получение гейтвеем данных эмиттера, включающих IP-адрес эмиттера на уровне WireGuard, публичный ключ, UDP-адрес, для установки р2р соединения на центральный сервер;

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

- отправляют на эмиттер ответ на ARP-пробу, идентифицирующий готовность гейтвея к установке р2р связи с эмиттером;

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

- идентифицируют данные внешнего сервера, указанные в качестве данных получателя на уровне GRE;

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

- натируют по меньшей мере один пакет исходящего трафика IP-адресом гейтвея;

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

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

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

- отправляют по меньшей мере один пакет входящего трафика на эмиттер.

9. Способ по п. 8, где запрос на получение гейтвеем данных эмиттера содержит IP-адрес гейтвея на уровне GRE.

10. Способ по п. 8, включающий конфигурацию интерфейсов на WireGuard уровне и GRE уровне с помощью полученного конфигурационного файла.

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

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

подготовительный этап, на котором:

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

рабочий этап, на котором:

- в ответ на получение на центральном сервере ARP-пробы от по меньшей мере одного эмиттера, проверяют, что IP-адрес эмиттера принадлежит в подгруппе эмиттеров и IP-адрес гейтвея принадлежит к подгруппе гейтвеев;

- в ответ на то, что IP-адрес эмиттера принадлежит в подгруппе эмиттеров и IP-адрес гейтвея принадлежит к подгруппе гейтвеев, пересылают ARP-пробу на гейтвей.

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

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

- по меньшей мере один эмиттер является пиром распределенной сети для анализа вредоносного контента и получения инкапсулированных пакетов на уровнях WireGuard и GRE;

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

- по меньшей мере один гейтвей является пиром распределенной сети для натирования по меньшей мере одного пакета исходящего трафика и денатирования по меньшей мере одного пакета входящего трафика;

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

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

- в ответ на получение на эмиттере ответа на ARP-пробу обновляют данные гейтвея в таблице соседей на эмиттере;

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

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

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

14. Система по п. 13, где запрос на получение эмиттером данных гейтвея содержит IP-адрес гейтвея на уровне GRE.

15. Система по п. 14, где IP-адреса включают:

- IP-адрес в сети Интернет;

- IP-адрес на уровне Wireguard;

- IP-адрес на уровне GRE.

16. Система по п. 13, включающая конфигурацию интерфейсов на WireGuard уровне и GRE уровне с помощью полученного конфигурационного файла.

17. Система по п. 13, где в ответ на превышение временного интервала на получение ARP-ответа высылают повторный ARP-запрос.

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

19. Система по п. 18, где с эмиттера на гейтвей отправляют запрос на переход на резервный маршрут.

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

- в ответ на получение от центрального сервера ARP-пробы эмиттера на WireGuard интерфейсе гейтвея проверяют наличие эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера;

- в ответ на отсутствие на WireGuard интерфейсе гейтвея эмиттера с IP-адресом, указанным в полученной ARP-пробе эмиттера, отправляют запрос на получение гейтвеем данных эмиттера, включающих IP-адрес эмиттера на уровне WireGuard, публичный ключ, UDP-адрес, для установки р2р соединения на центральный сервер;

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

- отправляют на эмиттер ответ на ARP-пробу, идентифицирующий готовность гейтвея к установке р2р связи с эмиттером;

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

- идентифицируют данные внешнего сервера, указанные в качестве данных получателя на уровне GRE;

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

- натируют по меньшей мере один пакет исходящего трафика IP-адресом гейтвея;

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

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

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

- отправляют по меньшей мере один пакет входящего трафика на эмиттер.

21. Система по п. 20, где запрос на получение гейтвеем данных эмиттера содержит IP-адрес гейтвея на уровне GRE.

22. Система по п. 20, включающая конфигурацию интерфейсов на WireGuard уровне и GRE уровне с помощью полученного конфигурационного файла.

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

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

- в ответ на получение на центральном сервере ARP-пробы от по меньшей мере одного эмиттера, проверяют, что IP-адрес эмиттера принадлежит в подгруппе эмиттеров и IP-адрес гейтвея принадлежит к подгруппе гейтвеев;

- в ответ на то, что IP-адрес эмиттера принадлежит в подгруппе эмиттеров и IP-адрес гейтвея принадлежит к подгруппе гейтвеев пересылают ARP-пробу на гейтвей.