Результат интеллектуальной деятельности: Способ и система туннелирования трафика в распределенной сети для детонации вредоносного программного обеспечения

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

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

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

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

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

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

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

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

К сожалению, самая простая реализация натирования, при которой IP-адрес песочницы, не находящейся в корпоративной подсети, будет просто заменен на 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.

Из уровня техники известны различные протоколы маршрутизации трафика, в том числе протокол маршрутизации трафика в распределенной сети 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-ом.

В то же время, из уровня техники известно решение US 20050086367 A1 (Alex Conta et at., 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-адрес корпоративной сети с помощью протоколов туннелирования трафика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 1 иллюстрирует общую схему распределенной сети.

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

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

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

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

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

ДЕТАЛЬНОЕ ОПИСАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

Важно отметить, что для реализации описываемого изобретения центральный сервер 101 должен иметь публичный 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-адрес локальной сети 122, в которой этот гейтвей расположен, и пересылает пакет на внешний сервер 130. Вследствие описанной подмены адрес отправителя пакета (который может быть проанализирован программой злоумышленника на внешнем сервере 130) не будет иметь ничего общего с адресом эмиттера 115, поэтому злоумышленнику не станет известно, что открытие письма и переход по ссылке произошли в изолированной среде, а не на одном из устройств атакуемой локальной сети 122.

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

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

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

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

Далее данный способ будет описан детально.

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

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

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

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

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

В конфигурационный файл центрального сервера для интерфейсов Wireguard и GRE добавляют IP-адреса центрального сервера. Как показано на Фиг. 2, на уровне Wireguard центральный сервер имеет два IP-адреса, причем один его IP-адрес 2!0 предназначен для взаимодействия с гейтвеями, а второй IP-адрес 220 - для взаимодействия с эммитерами. Из Фиг. 2 видно, что в рассматриваемом примере на уровне Wireguard за центральным сервером 101 закреплен IP-адрес 10.100.0.1/17 для взаимодействия с подсетью 230 эмиттеров, имеющей адрес 10.100.128.0/17, в то же время IP-адрес 10.100.128.1/17 закреплен за центральным сервером 101 для взаимодействия с подсетью 240 гейтвеев, имеющей адрес 10.100.0.0/17.

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

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

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

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

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

Как показано на Фиг. 2, на уровне Wireguard маршруты на центральном сервере 101 настраивают таким образом, чтобы все пакеты, которые отсылает центральный сервер 101 в подсеть эмиттеров 230, были отправлены с IP-адреса 220. Аналогично, все пакеты, которые центральный сервер 101 отсылает в подсеть гейтвеев 240, должны быть отправлены с IP-адреса 210.

На уровне GRE (не показан на Фиг. 2) центральному серверу 101 назначают один IP-адрес, по одному адресу назначают каждому из гейтвеев и эмиттеров, причем на этом уровне IP-адреса гейтвеев и эмиттеров не разнесены в разные подсети, все они находятся в одной подсети.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На этом шаг 370 и подготовительная стадия 300 заканчиваются. Способ переходит к выполнению рабочей стадии 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-адрес центрального сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В одном из возможных способов реализации гейтвей 125 может находиться за натом 126 и не иметь своего публичного 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 пакет, полученный на шаге 435, пересылают на центральный сервер 101. С этой целью на гейтвее 125 выполняют запрос к таблице маршрутизации и получают IP-адрес шлюза на уровне GRE, то есть IP-адрес центрального сервера 101 на уровне GRE. Далее выполняют обращение к таблице соседей для получения IP-адреса 210 центрального сервера 101 на уровне WireGuard. Все эти действия выполняются общеизвестным образом, штатными средствами используемой на гейтвее 125 операционной системы.

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

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

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

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

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

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

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

В приведенном примере на шагах 435-445 поступивший с внешнего сервера 130 потенциально вредоносный файл, будет получен гейтвеем 125 и переслан в полигон 110 компании "G" для анализа, для чего он будет сначала отправлен с гейтвея 125 на центральный сервер 101, а затем с центрального сервера 101 на эмиттер 115.

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

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

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

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

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

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

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

В общем случае устройство 500 содержит такие компоненты, как: один или более процессоров 501, по меньшей мере одну память 502, средство хранения данных 503, интерфейсы ввода/вывода 504, средства В/В 505, средства передачи данных 506.

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

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

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

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

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

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

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

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

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