Примеры правил обработки запросов

Далее приведены примеры правил обработки запросов, которые вы можете реализовать в сервисе Edge Logic Rules

Примеры сгруппированы по типам задач:

Ограничение доступа, защита от ботов и/или митигация DDoS-атак
Перенаправление запросов
Замена контента
Управление заголовками

Ограничение доступа, защита от ботов и/или митигация DDoS-атак

1. Разрешить доступ к интерфейсу администратора только с известных IP-адресов

Например, интерфейс администратора находится по адресу https://example.com/admin и доступ к нему должны иметь только сотрудники офиса из сети 12.23.56.0/24.

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

2. Запретить доступ не из России

3. Запретить доступ с посторонних веб-ресурсов

Например, вы хотите, чтобы определённый контент воспроизводился только на вашем сайте. Вы можете создать список доверенных веб-ресурсов (Список A) и блокировать все запросы, в которых заголовок Referer или Origin не соответствует веб-ресурсам из этого списка. При необходимости вы можете добавить дополнительный критерий, который будет сравнивать путь к конкретным объектам или потокам с заранее созданным списком (Список Б).

4. Запретить доступ к определенной части сайта

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

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

5. Запретить доступ к из определенных автономных систем (ASN)

Вы можете создать список автономных систем (Список A) и блокировать все запросы с IP-адресов, которые принадлежать какой-либо из автономных систем из списка.

6. Запретить доступ для подозрительных User-Agent

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

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

По умолчанию эти приложения устанавливают определённые значения в заголовке User-Agent. Вы можете создать список таких User-Agent (Список А) и создать правило, которое будет блокировать все запросы с заголовком User-Agent, который начинается/содержит/заканчивается на какое-либо из значений из списка.

Для удобства можно отключить опцию Учитывать регистр при редактировании этого правила.

7. Запретить доступ из сетей хостинг-провайдеров/датацентов

8. Запретить доступ из под VPN, Tor и Proxy-сервисов

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

9. Блокировать запросы с версией протокола HTTP/1.0

Протокол HTTP версии 1.0 устарел. В некоторых случаях использование этой версии может быть признаком нежелательного запроса, поскольку большинство современных браузеров используют более новые версии — 1.1 или 2.0.

Вы также можете создать критерий с другими версиями протокола.

10. Блокировать запросы с версией протокола TLS 1.0 или 1.1

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

11. Блокировать запросы от источников, не прошедших JS-валидацию

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

Первым критерием будет проверка, проходил ли пользователь проверку JavaScript ранее (есть ли у него проверочная Cookie). Вторым критерием будет исключение для запросов к /mobile-api – мы предполагаем, что именно по этому пути идут запросы к API.

В соответствии с этим правилом Javascript-валидация будет осуществляться для всех запросов, кроме запросов к /mobile-api. Параметр TTL проверочных Cookie определяет период между повторными проверками пользователя.

12. Блокировать запросы по TLS-отпечаткам

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

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

Перенаправление запросов

1. Отдавать пользователям не из России другой видеопоток

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

В этом случае можно показать зарубежным пользователям специальный поток, например, заглушку. Для этого, после запроса исходного потока https://live.example.ru/live/stream/playlist.m3u8, они будут перенаправлены на другой поток — https://live.example.ru/live/blocked/playlist.m3u8.

2. Перенаправление запросов с сохранением пути запроса

Этот пример демонстрирует, как можно настроить перенаправление всех запросов на другой домен (example.com), при этом сохраняя путь запроса. Для этого в конфигурации правила необходимо использовать переменную ${http.request.path}.

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

3. Перенаправление на заглушку на время регламентных или аварийных работ

4. Перенаправление на заглушку пользователей, использующих VPN

Замена контента

1. Отдавать другой контент пользователям с определенным User-Agent

Например, вы хотите, чтобы веб-страницы с заголовком User-Agent: wget получали специальный контент. Это можно осуществить, изменив содержимое заголовка Host: запросы будут направляться на ваш сервер оригинации через отдельный виртуальный сервер bots.example.ru.

Для удобства можно отключить опцию Учитывать регистр при редактировании этого правила.

Управление заголовками

1. Добавить заголовок в сторону сервера оригинации

Добавление дополнительного заголовка (например X-Cloud-Platform) может быть полезно, если вы хотите пометить запросы, поступающие с Платформы NGENIX, для специальной обработки на вашем сервере. Например, для ведения лога или настройки политик безопасности на вашем веб-сервере. В качестве критерия может использоваться любое условие, которое будет выполняться для любого запроса.

2. Удалить заголовок в сторону сервера оригинации

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

3. Сбор TLS-отпечатков доверенных устройств

Для сбора TLS-отпечатков необходимо создать правило обработки запросов, которое помечает запросы определенным заголовком. Например, tls-fingerprint-ngenix.

Убедитесь, что правило стоит последним в списке в Наборе правил. Таким образом вы отсечете лишние запросы от нелегитимных источников и тем самым сократите объем данных для анализа. Рекомендуется собирать данные минимум в течение недели.

Last updated