RU2740027C1

RU2740027C1 - Способ и система предотвращения вредоносных автоматизированных атак

Info

Publication number: RU2740027C1
Application number: RU2020106555A
Authority: RU
Inventors: Виталий Геннадьевич Золотарев; Антон Алексеевич Барабанов; Олег Александрович Лексунин
Original assignee: Варити Менеджмент Сервисез Лимитед
Priority date: 2020-02-12
Filing date: 2020-02-12
Publication date: 2020-12-30
Also published as: RU2768567C1; WO2021162589A1; CN115087977A; EP4105799A1; EP4105799A4; US20230069644A1

Abstract

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

Description

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

[0002] DoS-атака представляет собой атаку на вычислительную систему с целью доведения ее до отказа. Таким образом, DoS-атаку осуществляют с целью создания таких условий, при которых легитимные (правомерные) пользователи системы не могут получить доступ к предоставляемым системой ресурсам (серверам), либо этот доступ существенно затруднен. Если атака выполняется одновременно с большого числа компьютеров, говорят о DDoS- атаке (от англ. Distributed Denial of Service, распределенная атака типа «отказ в обслуживании»). Существуют две основные разновидности DDoS-атак: атаки на полосу пропускания и атаки на приложения.

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

[0004] Атаки на приложения характеризуются тем, что злоумышленник, эксплуатируя особенности поведения протоколов взаимодействия компьютеров (TCP, HTTP и т.п.), а также поведения сервисов и приложений, захватывает вычислительные ресурсы компьютера, на котором функционирует объект атаки, что не позволяет последнему обрабатывать легитимные транзакции и запросы. Примерами атак на приложения являются атаки с полуоткрытыми соединениями HTTP и с ошибочными соединениями HTTP.

[0005] В последнее время компьютерные системы всё больше подвергаются так называемым Slow-Rate, Low volume или "Low and Slow" атакам. Подобные атаки используют недостатки реализации приложений на стороне сервера (например, веб¬сервера) и позволяют, используя лишь небольшое количество запросов, вывести важный

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

[0006] В нижеследующем изложении речь пойдет о защите ресурса (сервера). Однако, следует отметить, помимо самого ресурса в традиционном понимании (в частности, веб¬сайт, на который заходят пользователи, используя свои браузеры), ресурс может включать любые веб-сервисы, построенные с использованием стандартов HTML, XML, WSDL, SOAP и т.д. Кроме того, сервер может предоставлять интерфейсы для доступа к другим сервисам, например, к СУБД. Также следует принимать во внимание, что сервер может включать не один физический компьютер (сервер), а целую группу (кластер или дата центр), имеющую собственные механизмы балансировки нагрузки (не рассматриваются в рамках настоящей заявки).

[0007] Известен способ, в котором реализуют регулирование потоков запросов к охраняемому ресурсу с отделением легитимных запросов, сделанных человеком, а не роботом, от вредоносных запросов, которые генерированы автоматически компьютером. Способ базируется на использовании капчи (CAPTCHA). CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart, в переводе - «компьютерный тест, предназначенный для определения, кем является пользователь системы: человеком или роботом (компьютером)». Основная идея теста: предложить пользователю такую задачу, которая с лёгкостью решается человеком, но крайне сложна и трудоёмка для робота. В наиболее распространённом варианте капчи пользователь вводит символы, изображённые на рисунке, при этом на рисунке символы изображены таким образом, чтобы машине было очень затруднительно распознать их (зачастую символы изображены с добавлением помех или полупрозрачности).

[0008] Однако у данного способа есть недостатки. Например, вследствие развития

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

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

[0009] Одним из подходов к регулированию потоков запросов и предотвращению, снижению влияния подозрительной активности, полному или частичному избавлению от DoS-атак, является настройка сервиса таким образом, чтобы при отправке запроса к ресурсу

подозрительный пользователь (потенциальный бот, ботнет) нес со своей стороны какие-то вычислительные затраты для получения доступа к ресурсу.

[0010] Известно решение [US2016344752 Brute force attack prevention system], в котором система предотвращения атак методом перебора (брутфорса) включает в себя устройства ввода и вывода, процессор.

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

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

[0012] Известен другой аналог [US2014380418, System and method for verifying the legitimacy of requests sent from clients to server], в котором запрос к охраняемому ресурсу считается легитимным, когда пользователь затрачивает некоторое количество своих вычислительных ресурсов для доступа к серверу.

[0013] Процедуру квалификации запроса к числу легитимных запросов осуществляют в форме теста запрос-ответ (challenge-response). При этом в компьютерной системе

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

[0014] Кроме того, известен следующий аналог [патент US10291408 на изобретение «Generation of Merkle trees as proof-of-work», опубликовано 14.05.2019]). В его основе используется подход, суть которого в том, что при получении запроса от пользователя к ресурсу, пользователю системой ставится вычислительная задача - генерация дерева Меркла, которую он должен верно решить для получения доступа к ресурсу (proof of work).

[0015] При этом на решение поставленной задачи необходимо потратить больше вычислительных ресурсов, чем на проверку решения. В некоторых вариантах, система осуществляет выдачу задачи в ответ на каждый запрос пользователя (например, в период аномально высокого трафика или когда защищенный ресурс подвергает DоS атаке). Задача может включать в себя инструкции для генерирования дерева Меркла определенной глубины, начальную информацию, которая может использоваться для получения узлов дерева Меркла, и сообщение. Также в задаче может быть указано, что сообщение должно быть подписано с использованием определенного ключа подписи дерева Меркла. В некоторых вариантах осуществления начальная информация может включать в себя идентификатор ключа, соответствующий ключу подписи дерева Меркла. В некоторых вариантах осуществления задача включает в себя фактор работы. Фактор работы дерева Меркла может относиться к числу операций хеширования, которые необходимы для генерации полного дерева Меркла.

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

[0017] Настоящий способ и система предотвращения вредоносных автоматизированных атак на компьютерные системы направлены на решение технической проблемы обеспечения возможности гибкого, в реальном масштабе времени (in situ), реагирования на запросы пользователей, возможности предоставления легитимным пользователям без задержки доступа к охраняемому ресурсу, максимально быстрого реагирования на атаки, обеспечение безопасности вычислительной системы от подозрительной автоматизированной активности, вредоносных автоматизированных атак, в частности, низкочастотных DDoS-атак, за счет нижеследующего технического результата.

[0018] Техническим результатом является:

[0019] - обеспечение безопасности охраняемого ресурса (вычислительной системы) от подозрительной автоматизированной активности, вредоносных автоматизированных атак, ddos атак;

[0020] - снижение нагрузки на вычислительные мощности (процессор) как пользователя, так и защищаемой системы (ресурса);

[0021] - сокращение времени предотвращения вредоносных автоматизированных атак.

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

[0023] а) оценивают пользователя на основании полученного запроса к компьютерной системе о сессии посредством технического анализа, в ходе которого осуществляют:

[0024] сбор числовых и статистических метрик запроса,

[0025] счет метрик, характеризующих пользователя на основании статистики его общения с ресурсом,

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

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

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

[0029] в) при подтверждении подозрительности пользователя - в случае отсутствия верного решения криптографической задачи и определения его к категории бота - блокируют доступ к ресурсу, в случае верного решения определяют к категории легитимного пользователя и предоставляют доступ.

[0030] В способе собирают числовые и статистические метрики запроса, доступные на сетевом уровне L3, и/или доступные на транспортном уровне L4, и/или доступные на уровне приложения, например, протокола HTTP/HTTPS.

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

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

[0033] В способе при проведении дополнительной проверки пользователя получают дополнительные метрики браузера подозрительного пользователя для выявления ботов,

[0034] формируют задачу на основании ключа,

[0035] высылают пользовательской компьютерной системе задачу и токен запроса,

[0036] получают от пользовательской компьютерной системы решение задачи и токен ответа,

[0037] при предоставлении неверного решения доступ пользователя к ресурсу блокируют.

[0038] В способе при проведении дополнительной проверки пользователя получают дополнительные метрики браузера подозрительного пользователя, а именно проверяют работоспособность различных особенностей языка Java Script и/или CSS и/или HTML и уточняют версию браузера, а также проверяют параметры окна, наличие движения мышкой и другие факторы, обеспечивающие выяснение режима работы браузера. Кроме того, получают уникальную для данной инсталляции браузера строку, не обеспечивающую при этом однозначную идентификацию браузера.

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

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

[0041] блока сбора метрик соединения на сетевом уровне L3,

[0042] блока сбора метрик соединения на транспортном уровне L4,

[0043] блока сбора базовых метрик на уровне приложения,

[0044] блока статистических метрик пользователя,

[0045] блока сопоставления метрик по сессии с обычными для данного ресурса значениями,

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

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

[0048] Блок сбора метрик соединения выполнен с возможностью сбора метрик по крайней мере на сетевом уровне и/или транспортном уровне.

[0049] В составе блока дополнительной проверки выполнены:

[0050] блок проверки JS стека, проверяющий работоспособность особенностей языка JS,

[0051] блок проверки CSS стека, проверяющий работоспособность особенностей реализации CSS,

[0052] блок проверки HTML стека, проверяющий работоспособность особенностей реализации HTML,

[0053] блок выявления HeadLess, проверяющий параметры окна, наличие движения мышкой и факторы, выявляющие режим работы браузера,

[0054] блок вычисления уникальной сигнатуры, обеспечивающий вычисление уникальной для данной инсталляции браузера строку, препятствующую однозначной идентификации браузера,

[0055] блок отправки собранных данных, связанный с указанными выше блоками,

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

[0057] Сущность изобретения поясняется следующими фигурами.

[0058] На фиг. 1 представлена блок-схема осуществления технического анализа (100) в системе для предварительной оценки легитимности запроса, где:

[0059] 101 - блок сбора метрик соединения на сетевом уровне L3,

[0060] 102 - блок сбора метрик соединения на транспортном уровне L4,

[0061] 103 - блок сбора базовых метрик на уровне приложения,

[0062] 104 - блок статистических метрик пользователя,

[0063] 105 - блок сопоставления метрик по сессии с обычными для данного ресурса значениями,

[0064] 106 - блок вычисления вектора факторов запроса,

[0065] 107 - блок отправки факторов в статистическую модель и вычисления результата.

[0066] На фиг. 2 изображена блок-схема Java Script (JS) challenge (200), где:

[0067] 201 - криптографический блок,

[0068] 202 - блок проверки JavaScript стека,

[0069] 203 - блок проверки CSS стека,

[0070] 204 - блок проверки HTML стека,

[0071] 205 - блок выявления HeadLess,

[0072] 206 - блок вычисления уникальной сигнатуры,

[0073] 207 - блок отправки собранных данных,

[0074] 208 - блок запуска проверки.

[0075] На фиг. 3 показана общая блок-схема обработки (300) системой новой сессии при запросе от пользователя к ресурсу, где:

[0076] 301 - поступление запроса от пользователя,

[0077] 302 - предоставление доступа к ресурсу по легитимному запросу,

[0078] 303 - генерация задачи (JS challenge) по подозрительному запросу,

[0079] 304 - принятие решения о блокировке нелегитимной сессии,

[0080] 305 - отправка ответа пользователю в виде сгенерированной задачи,

[0081] 306 - блокировка запроса пользователя,

[0082] 307 - получение от пользователя решения сгенерированной задачи (JS challenge),

[0083] 308 - блокировка пользователя по результату решения задачи,

[0084] 309 - признание сессии легитимной по решении задачи,

[0085] 310 - допуск помеченной легитимной сессии к серверу.

[0086] Используемые в описании технического решения термины «модуль», «компонент», «элемент», «блок» и подобные используются для обозначения компьютерных сущностей, которые могут являться аппаратным обеспечением/оборудованием (например, устройством, инструментом, аппаратом, аппаратурой, составной частью устройства, например, процессором, микропроцессором, интегральной схемой, печатной платой, в том числе электронной печатной платой, макетной платой, материнской платой и т.д., микрокомпьютером и так далее), программным обеспечением (например, исполняемым программным кодом, скомпилированным приложением, программным модулем, частью программного обеспечения или программного кода и так далее) и/или микропрограммой (в частности, прошивкой). Так, например, компонент может быть процессом, выполняющимся на процессоре (процессором), объектом, исполняемым кодом, программным кодом, файлом, программой/приложением, функцией, методом, (программной) библиотекой, подпрограммой, сопрограммой и/или вычислительным устройством (например, микрокомпьютером или компьютером) или комбинацией программных или аппаратных компонентов. Так, в частном случае, запущенное на сервере приложение может являться компонентом/модулем, а, сервер, в свою очередь может являться компонентом/модулем. Стоит отметить, что, по крайней мере, один компонент/модуль может являться частью процесса. Компонент/модуль может располагаться на одном вычислительном устройстве (например, микрокомпьютере, микропроцессоре, печатной плате и т.д.) и/или может быть распределен/разделен между несколькими вычислительными устройствами

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

[0088] Особенности состоят в следующем.

[0089] Во-первых, выполняют технический анализ пользователя по комплексу метрик (см. Фиг. 1), что обеспечивает определение пользователя к одной из категорий: легитимного, подозрительного и/или бота. Соответственно, в первом случае пользователю предоставляют доступ к ресурсу, во втором случае проводят дополнительную проверку (JavaScript Challenge), в третьем случае осуществляют блокировку. Такой подход позволяет не нагружать вычислительные ресурсы (CPU) в случае, если запрос заведомо сделан человеком (что важно в отношении мобильных устройств и ноутбуков в силу зачастую их

небольших вычислительных мощностей). Легитимному пользователю могут сразу предоставить доступ к ресурсу. В случае, если запрос заведомо сделан ботом, его блокируют. Комплекс метрик может содержать такие данные как: тип, версия браузера из заголовка User-Agent пользователя, стартовый размер окна, опции, флаги и TTL.

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

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

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

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

[0094] Подробное описание изобретения.

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

[0096] Блок-схема на фиг. 1 описывает процесс технического анализа (100) в системе для предварительной оценки легитимности запроса со стороны пользователя. Результатом проведения технического анализа являются следующие варианты:

[0097] легитимный запрос — можно пропустить запрос на ресурс клиента;

[0098] подозрительный запрос — нужно подвергнуть сессию дополнительным проверкам (JS Challenge компонента);

[0099] нелегитимный запрос — запрос нужно заблокировать.

[00100] В ходе технического анализа в системе блоки (101)-(107) выполняют перечисленные ниже действия:

[00101] (101) - собирают всевозможные числовые и статистические метрики,

доступные на сетевом уровне L3 (уровень IP модели TCP/IP). Например, флаги и TTL.

[00102] (102) - собирают всевозможные числовые и статистические метрики,

доступные на транспортном уровне L4 (уровень TCP модели TCP/IP). Например, флаги, опции и стартовый размер окна.

[00103] (103) - собирают всевозможные числовые и статистические метрики на уровне приложения, протокола HTTP/HTTPS. Например, тип, версия браузера из заголовка User-Agent.

[00104] (104) - на основе имеющейся статистики общения пользователя с ресурсом считают метрики, характеризующие данного клиента. Например, медианное время между запросами к ресурсу.

[00105] (105) - имея общую статистику по ресурсу, вычисляют метрики,

показывающие отклонение сессии клиента от медианной и средней сессии на данном ресурсе.

[00106] (106) - сводят вычисленные метрики в единый вектор факторов запроса и выполняют нормализацию метрик.

[00107] (107) - используя предварительно подготовленную статистическую модель, вычисляют результат и получают оценку легитимности запроса.

[00108] Для подготовки и обучения модели можно использовать различные техники машинного обучения, или написать её вручную. Для подготовки и обучения модели выделяется контрольная группа пользователей для каждой возможной группы/подгруппы факторов и размечается вручную на бот/человек. Полученные данные используются для вычисления уровня подозрительности для данной группы/подгруппы.

[00109] Все блоки являются программными компонентами, частью программного комплекса, который выполняет процессор.

[00110] Сетевой уровень (англ. network layer) модели предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и «заторов» в сети.

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

[00112] Протоколы сетевого уровня: IP/IPv4/IPv6 (Internet Protocol), IPX (Internetwork Packet Exchange, протокол межсетевого обмена), X.25 (частично этот протокол реализован на уровне 2), CLNP (сетевой протокол без организации соединений), IPsec (Internet Protocol Security). Протоколы маршрутизации — RIP (Routing Information Protocol), OSPF (Open Shortest Path First).

[00113] Internet Protocol (IP, досл. «межсетевой протокол») — маршрутизируемый протокол сетевого уровня стека TCP/IP. Именно IP стал тем протоколом, который объединил отдельные компьютерные сети во всемирную сеть Интернет. Неотъемлемой частью протокола является адресация сети

[00114] Транспортный уровень (англ. transport layer) модели предназначен для обеспечения надёжной передачи данных от отправителя к получателю. При этом уровень надёжности может варьироваться в широких пределах. Существует множество классов протоколов транспортного уровня, начиная от протоколов, предоставляющих только основные транспортные функции (например, функции передачи данных без подтверждения приёма), и заканчивая протоколами, которые гарантируют доставку в пункт назначения нескольких пакетов данных в надлежащей последовательности, мультиплексируют несколько потоков данных, обеспечивают механизм управления потоками данных и гарантируют достоверность принятых данных. Протокол TCP обеспечивает надёжную непрерывную передачу данных, исключающую потерю данных или нарушение порядка их поступления или дублирования, может перераспределять данные, разбивая большие порции данных на фрагменты и наоборот, склеивая фрагменты в один пакет.

[00115] Протоколы транспортного уровня: ATP (AppleTalk Transaction Protocol), CUDP (Cyclic UDP), DCCP (Datagram Congestion Control Protocol), FCP (Fibre Channel Protocol), IL (IL Protocol), NBF (NetBIOS Frames protocol), NCP (NetWare Core Protocol), SCTP (Stream Control Transmission Protocol), SPX (Sequenced Packet Exchange), SST (Structured Stream Transport), TCP (Transmission Control Protocol), UDP (User Datagram Protocol).

[00116] Transmission Control Protocol, TCP, протокол управления передачей — один из основных протоколов передачи данных интернета, предназначенный для управления передачей данных.

[00117] В стеке протоколов TCP/IP выполняет функции транспортного уровня модели OSI.

[00118] Механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым, целостность передаваемых данных и уведомление отправителя о результатах передачи.

[00119] Когда осуществляется передача от компьютера к компьютеру через Интернет, TCP работает на верхнем уровне между двумя конечными системами, например, браузером и веб-сервером. TCP осуществляет надёжную передачу потока байтов от одного процесса к другому. TCP реализует управление потоком, управление перегрузкой, рукопожатие, надёжную передачу.

[00120] Система позволяет создавать различной сложности дополнительную проверку для уточнения легитимности запроса как описано ниже. При этом так же могут вычисляться дополнительные метрики браузера для выявления ботов, ботнетов. Вся проверка сведена в компонент, разработанный на языке Java Script (JS), и выполняется непосредственно браузером.

[00121] На фиг. 2 изображена блока-схема Java Script Challenge (JS Challenge) компонента, частью которой являются блоки (201)-(208).

[00122] Криптографический блок (201) имплементирует алгоритм ассиметричного шифрования, отвечает за решение математической задачи, исходные параметры которой кодируются в блок запуска (208). Решаемая задача может иметь различную сложность в зависимости от размера ключа. Можно заранее сгенерировать несколько ключей разного уровня сложности и, в зависимости от уровня подозрительности запроса, загруженности ресурса или других факторов, например, количества успешных прохождений подозрительными пользователями дополнительной проверки, выбрать тот или иной ключ.

[00123] Блок проверки JS стека (202) проверяет работоспособность различных особенностей языка JS, что позволяет уточнить версию браузера.

[00124] Блок проверки CSS стека (203) проверяет работоспособность различных особенностей реализации CSS, что позволяет уточнить версию браузера.

[00125] Блок проверки HTML стека (204) проверяет работоспособность различных особенностей реализации HTML, что позволяет уточнить версию браузера.

[00126] Блок выявления HeadLess (205) проверяет параметры окна, наличие движения мышкой и прочие факторы, которые позволяют выяснить режим работы браузера.

[00127] Блок вычисления уникальной сигнатуры (206) позволяет вычислить уникальную для данной инсталляции браузера строку, не позволяющую при этом однозначно браузер идентифицировать. Такая информация может быть использована для

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

[00128] На основе особенностей реализации JS/CSS/HTML (в ходе работы блоков 202-204) можно выяснить точную версию и тип браузера и сравнить с информацией, полученной в ходе технического анализа (100) при работе блока (103), а именно, тип и версия браузера из заголовка User-Agent. При несоответствии информации, такого пользователя можно отнести к категории нелегитимных.

[00129] Блок отправки собранных данных (207) компонует результат проверок и решение задачи в единую структуру и отправляет её системе на сервер.

[00130] Блок запуска (208) запускает проверки блоков (202)-(206) после загрузки модуля JS challenge и вызывает криптографический блок (201) с закодированным в нем стартовым условием задачи.

[00131] Система работает следующим образом.

[00132] Система получает от пользователя запрос о новой сессии. Общая схема (300) обработки новой сессии от пользователя к защищаемому ресурсу включает следующее.

[00133] При поступлении запроса от пользователя он отправляется (301) на технический анализ (100). При осуществлении технического анализа происходит сбор метрик (необходимых для осуществления технического анализа, фиг. 1), который сводится в вектор факторов запроса. Далее подготовленная статистическая модель на основании вектора факторов запроса вырабатывает результат (оценку) легитимности запроса.

[00134] В случае, если сессия была распознана как легитимная (302), и, таким образом, пользователь идентифицирован как человек (а не бот), она отправляется к защищаемому ресурсу.

[00135] Если сессия был распознана как нелегитимная (304), она подлежит блокировке. Блокировка (306) осуществляется либо через 403 код (HTTP), либо через другие механизмы, позволяющие эффективно утилизировать ресурсы источника.

[00136] Если сессия была распознана как подозрительная (303), система проводит дополнительную проверку, а именно, генерирует Java Script Challenge (200). Сложность проверки (размер ключа) варьируется в зависимости от уровня подозрительности запроса, производительности защищаемого ресурса, метрики, показывающей количество успешных прохождений проверки подозрительными пользователями.

[00137] Сгенерированный JS Challenge отправляется в качестве ответа (высылается задача) на первый запрос сессии (305), а именно, система отправляет пользователю токен доступа, зашифрованный посредством алгоритма ассиметричного шифрования, например,

RSA. Также возможны и другие варианты реализации пометки. Например, система может отправлять зашифрованное сообщение и токен доступа (как указано в аналоге US10291408). Далее система переходит в режим ожидания ответа.

[00138] Блок (207) JS Challenge получает от пользователя решение сгенерированной задачи и отправляет результаты работы на сервер.

[00139] Если по результатам проверки с помощью JS Challenge сессия признана нелегитимной, она подлежит блокировке.

[00140] Если сессия признана легитимной, она подлежит пометке (309) «легитимная» с использованием механизма HTTP Cookie, токена запроса/ответа или иных механизмов, например, пометка уже встроена в ответ защищаемой системы.

[00141] Помеченная легитимная сессия отправляется на сервер (310).

[00142] Легитимные сессии можно пометить лимитированным токеном доступа. Таким образом система предотвращает получение «вручную» доступа и дальнейшее использование уже ботом.

[00143] Систему можно настроить в режим принудительный дополнительной проверки всех запросов, тогда все запросы после прохождения технического анализа будут отправляться на дополнительную проверку JS Challenge.

[00144] Пример 1 - Легитимный пользователь.

[00145] Пользователь выполняет запрос к ресурсу (301), система выполняет технический анализ (100). Происходит сбор и вычисление числовых и статистических метрик, сведение их в вектор факторов запроса (работа блоков 101-106) и вычисление (оценка) легитимности запроса посредством подготовленной статистической модели (107).

[00146] По итогам технического анализа (100) делается вывод о том, что запрос является легитимным. Если не выставлен режим принудительной проверки всех запросов, то пользователь получает доступ к ресурсу (302) и лимитированный токен доступа для того, чтобы не производить технический анализ (100) повторно на каждый запрос. Токен лимитируется как по времени, так и по количеству запросов.

[00147] Если выставлен режим принудительной дополнительной проверки, генерируется упрощенный JS Challenge (303), который отправляется пользователю. После получения результатов (307) запрос пропускается на ресурс (309, 310), а пользователю выдается лимитированный токен доступа.

[00148] Пример 2 - Подозрительный пользователь.

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

[00150] Пользователь выполняет запрос к ресурсу (301), система выполняет технический анализ (100). Например, сбор числовых и статистических метрик на уровне приложения, протокола HTTP/HTTPS, показал, что тип браузера совпадает с типом в запросе к системе, но версия не совпадает. Или, например, счет метрик, характеризующих данного пользователя (104), показал значительное отклонение в количестве запросов на единицу времени в сравнении со средним пользователем (например, ресурс - сайт с товарными предложениями, значительное превышение количество запросов на единицу времени - происходит парсинг сайта).

а. По итогам технического анализа (100) пользователя квалифицируют как подозрительного и проводят дополнительную проверку. Сложность проверки задается заранее сгенерированным ключом. Длина ключа, например, 512 бит. Пользователю высылается токен доступа и открытый ключ. Браузер на основе открытого ключа шифрует токен доступа. Решение задачи (зашифрованный токен доступа) вместе с дополнительными данными, собранными в браузере в ходе работы блоков (202-206), отправляется системе на сервер.

[00151] Система квалифицирует подозреваемого как легитимного пользователя и выдает доступ к ресурсу.

[00152] Пример 3 Нелегитимный пользователь.

[00153] Пользователь выполняет запрос к ресурсу (301), система выполняет технический анализ (100). По итогам технического анализа (100) пользователя квалифицируют как нелегитимного и блокируют.

[00154] Например, сбор числовых и статистических метрик на уровне приложения, протокола HTTP/HTTPS, показал, что версия и тип браузера не совпадает с версией в запросе к системе. Также сбор числовых и статистических метрик, доступных на сетевом уровне L3 и на транспортном уровне L4 показал, что тип операционной системы пользователя не совпадает с типом операционной системы в запросе. Собранные метрики были сведены в вектор факторов запроса и отправлены в статистическую модель. Итогом оценки пользователя стала его квалификация как бота и блокировка.

[00155] В настоящем изобретении под блоками (101-107, 201-208) понимаются компоненты, группа компонентов, реализованных с использованием аппаратных средств, таких как интегральные микросхемы или, например, в виде комбинации программных и аппаратных средств, таких как микропроцессорная система и набор программных инструкций. Функциональность блоков (101- 107, 201-208) может быть реализована исключительно аппаратными средствами, а также в виде комбинации, где часть функциональности реализована программными средствами, а часть аппаратными

(программно-аппаратный комплекс). В некоторых вариантах реализации часть блоков (101-107, 201-208) может быть исполнена на процессоре компьютерной системы общего назначения.

[00156] Ниже описан пример компьютерной системы общего назначения (сервера, где стоит система).

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

[00158] Персональный компьютер в свою очередь содержит жесткий диск для чтения и записи данных, а также может содержать привод магнитных дисков для чтения и записи на сменные магнитные диски и оптический привод для чтения и записи на сменные оптические диски, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск, привод магнитных дисков, оптический привод соединены с системной шиной через интерфейс жесткого диска, интерфейс магнитных дисков и интерфейс оптического привода соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера.

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

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

[00161] Персональный компьютер способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами. Удаленный компьютер (или компьютеры) являются такими же персональными

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

[00162] Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер подключен к локальной сети через сетевой адаптер или сетевой интерфейс. При использовании сетей персональный компьютер может использовать модем или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем, который является внутренним или внешним устройством, подключен к системной шине посредством последовательного порта. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

Claims

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

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

сбор числовых и статистических метрик запроса,

счет метрик, характеризующих пользователя на основании статистики его общения с ресурсом,

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

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

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

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

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

3. Способ по п. 2, в котором собирают числовые и статистические метрики, доступные на уровне приложения, а именно протокола HTTP/HTTPS.

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

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

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

формируют задачу на основании ключа,

высылают пользовательской компьютерной системе задачу и токен запроса,

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

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

7. Способ по п. 6, в котором при проведении дополнительной проверки пользователя получают дополнительные метрики браузера подозрительного пользователя, а именно проверяют работоспособность различных особенностей языка Java Script и уточняют версию браузера.

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

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

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

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

12. Компьютерная система предотвращения вредоносных автоматизированных атак, включающая:

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

при этом блок оценки легитимности запроса со стороны пользователя выполнен в составе:

блока сбора метрик соединения,

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

блока статистических метрик пользователя,

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

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

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

13. Система по п. 12, в которой блок сбора метрик соединения выполнен с возможностью сбора метрик соединения по крайней мере на сетевом уровне и/или транспортном уровне.

14. Система по п. 12, в которой в составе блока дополнительной проверки выполнены:

блок проверки JS стека, проверяющий работоспособность особенностей языка JS, блок проверки CSS стека, проверяющий работоспособность особенностей реализации CSS,

блок проверки HTML стека, проверяющий работоспособность особенностей реализации HTML,

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

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

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