Примеры правил обработки запросов
Далее приведены примеры правил обработки запросов, которые вы можете реализовать в сервисе Edge Logic Rules
Примеры сгруппированы по типам задач:
Ограничение доступа, защита от ботов и/или митигация DDoS-атак
1. Разрешить доступ к интерфейсу администратора только с известных IP-адресов
Например, интерфейс администратора находится по адресу https://example.com/admin
и доступ к нему должны иметь только сотрудники офиса из сети 12.23.56.0/24
.
Критерии №1 | Критерий №2 | Действие |
---|---|---|
Поле: http.request.path Оператор: begins Значение: /admin | Поле: ip.addr Оператор: NOT in Значение: 12.23.56.0/24 | Действие: deny HTTP-код: 403 Текст: (опционально) |
Если вы хотите разрешить доступ с нескольких IP-адресов или сетей, то удобнее будет создать список, после чего указать его в необходимом критерии.
2. Запретить доступ не из России
Критерии №1 | Действие |
---|---|
Поле: ip.geoip.country Оператор: NOT equals Значение: Россия | Действие: deny HTTP-код: 403 Текст: (опционально) |
3. Запретить доступ с посторонних веб-ресурсов
Например, вы хотите, чтобы определённый контент воспроизводился только на вашем сайте. Вы можете создать список доверенных веб-ресурсов (Список A) и блокировать все запросы, в которых заголовок Referer
или Origin
не соответствует веб-ресурсам из этого списка. При необходимости вы можете добавить дополнительный критерий, который будет сравнивать путь к конкретным объектам или потокам с заранее созданным списком (Список Б).
Критерии №1 | Критерии №1 | Действие |
---|---|---|
Поле: http.request.referer.host Оператор: NOT in Значение: Список А | Поле: http.request.referer.host Оператор: NOT in Значение: Список Б | Действие: deny HTTP-код: 403 Текст: (опционально) |
4. Запретить доступ к определенной части сайта
Допустим, у вас есть раздел, к которому нельзя получить доступ через Платформу. Вы можете создать правило, блокирующее все запросы, начинающиеся с определённой строки.
Критерии №1 | Действие |
---|---|
Поле: http.request.path Оператор: begins Значение: /local | Действие: deny HTTP-код: 403 Текст: (опционально) |
В указанном примере, все запросы, которые начинаются на /local
, будут заблокированы.
5. Запретить доступ к из определенных автономных систем (ASN)
Вы можете создать список автономных систем (Список A) и блокировать все запросы с IP-адресов, которые принадлежать какой-либо из автономных систем из списка.
Критерии №1 | Действие |
---|---|
Поле: ip.asn Оператор: in Значение: Список А | Действие: deny HTTP-код: 403 Текст: (опционально) |
6. Запретить доступ для подозрительных User-Agent
Существуют большое количество приложений, которые используются злоумышленниками для атак на веб-ресурсы. Например, это может быть ботнет из взломанных Wordpress или других систем и сканеров. Все эти приложения по умолчанию выставляют определенные значения в заголовке User-Agent
. Вы можете определить для себя список подобных User-Agent
и заранее заблокировать запросы, которые его содержат. Для этого:
Существует множество приложений, которые злоумышленники используют для атак на веб-ресурсы. Среди них могут быть ботнеты, состоящие из взломанных систем Wordpress или других систем и сканеров.
По умолчанию эти приложения устанавливают определённые значения в заголовке User-Agent. Вы можете создать список таких User-Agent
(Список А) и создать правило, которое будет блокировать все запросы с заголовком User-Agent
, который начинается/содержит/заканчивается на какое-либо из значений из списка.
Критерии №1 | Действие |
---|---|
Поле: http.request.headers.user-agent Оператор: begins Значение: Список А | Действие: deny HTTP-код: 403 Текст: (опционально) |
Для удобства можно отключить опцию Учитывать регистр при редактировании этого правила.
7. Запретить доступ из сетей хостинг-провайдеров/датацентов
Критерии №1 | Действие |
---|---|
Поле: ip.network_type Оператор: in Значение: datacenter | Действие: deny HTTP-код: 403 Текст: (опционально) |
8. Запретить доступ из под VPN, Tor и Proxy-сервисов
Запросы от таких источников с большой вероятностью инициируются различными ботами, злоумышленниками или просто нерелевантной аудиторией пользователей.
Критерии №1 | Действие |
---|---|
Поле: ip.proxy_type Оператор: in Значение: proxy, vpn, tor | Действие: deny HTTP-код: 403 Текст: (опционально) |
9. Блокировать запросы с версией протокола HTTP/1.0
Протокол HTTP версии 1.0 устарел. В некоторых случаях использование этой версии может быть признаком нежелательного запроса, поскольку большинство современных браузеров используют более новые версии — 1.1 или 2.0.
Критерии №1 | Действие |
---|---|
Поле: http.version Оператор: equals Значение: HTTP/1.0 | Действие: deny HTTP-код: 403 Текст: (опционально) |
Вы также можете создать критерий с другими версиями протокола.
10. Блокировать запросы с версией протокола TLS 1.0 или 1.1
В 2020 году протоколы TLS версий 1.0 и 1.1 были признаны устаревшими. В некоторых случаях использование этих версий может быть значимым признаком нежелательного запроса, поскольку большинство современных браузеров поддерживают более новые версии протокола TLS.
Критерии №1 | Действие |
---|---|
Поле: tls.version Оператор: equals Значение: TLSv1, TLSv1.1 | Действие: deny HTTP-код: 403 Текст: (опционально) |
11. Блокировать запросы от источников, не прошедших JS-валидацию
JS-валидацияРассмотрим сценарий, при котором мы хотим настроить JavaScript-валидацию (и осуществлять блокировку запросов от ботов при их обнаружении) для всех запросов, кроме запросов к API со стороны мобильного приложения.
Первым критерием будет проверка, проходил ли пользователь проверку JavaScript ранее (есть ли у него проверочная Cookie). Вторым критерием будет исключение для запросов к /mobile-api
– мы предполагаем, что именно по этому пути идут запросы к API.
Критерии №1 | Критерии №2 | Действие |
---|---|---|
Поле: http.request.js_challenge_ok Оператор: equals Значение: false | Поле: http.request.path Оператор: NOT begins Значение: /mobile-api | Действие: jsChallenge TTL проверочных Cookie (в секундах): 3600 |
В соответствии с этим правилом Javascript-валидация будет осуществляться для всех запросов, кроме запросов к /mobile-api
. Параметр TTL проверочных Cookie определяет период между повторными проверками пользователя.
12. Блокировать запросы по TLS-отпечаткам
TLS-отпечаткиРассмотрим сценарий, при котором мы хотим настроить блокировку запросов от ботов основываясь на ранее собранном наборе нелегитимных TLS-отпечатков. Применимо для всех запросов включая запросы к API со стороны мобильного приложения.
Критерии №1 | Действие |
---|---|
Поле: tls.ngx_fingerprint_hash Оператор: in Значение: Список TLS-отпечатков | Действие: deny HTTP-код: 403 Текст: (опционально) |
В соответствии с этим правилом если запрос от пользователя приходит с устройства, TLS-отпечаток которого входит в список запрещённых TLS-отпечатков, то будет осуществляться блокировка запроса с возвратом 403 кода ответа.
Перенаправление запросов
1. Отдавать пользователям не из России другой видеопоток
Предположим, вам нужно ограничить доступ к вашим видеопотокам из-за границы в соответствии с условиями лицензионных соглашений.
В этом случае можно показать зарубежным пользователям специальный поток, например, заглушку. Для этого, после запроса исходного потока https://live.example.ru/live/stream/playlist.m3u8
, они будут перенаправлены на другой поток — https://live.example.ru/live/blocked/playlist.m3u8
.
Критерии №1 | Критерии №1 | Действие |
---|---|---|
Поле: http.request.path Оператор: equals Значение: /live/stream/playlist.m3u8 | Поле: ip.geoip.country Оператор: NOT equals Значение: Россия | Действие: redirect Ссылка для перенаправления: https://live.example.ru/live/blocked/playlist.m3u8 |
2. Перенаправление запросов с сохранением пути запроса
Этот пример демонстрирует, как можно настроить перенаправление всех запросов на другой домен (example.com), при этом сохраняя путь запроса. Для этого в конфигурации правила необходимо использовать переменную ${http.request.path}
.
Критерии №1 | Действие |
---|---|
Поле: http.request.method Оператор: exists | Действие: redirect Ссылка для перенаправления: https://example.com${http.request.path} |
В качестве критерия может использоваться любое условие, которое будет выполняться для любого запроса.
3. Перенаправление на заглушку на время регламентных или аварийных работ
Критерии №1 | Действие |
---|---|
Поле: http.request.path Оператор: equals Значение: / | Действие: redirect Ссылка для перенаправления: https://example.ru/maintenance |
4. Перенаправление на заглушку пользователей, использующих VPN
Критерии №1 | Действие |
---|---|
Поле: ip.proxy_type Оператор: in Значение: vpn | Действие: redirect Ссылка для перенаправления: https://example.ru/novpn |
Замена контента
1. Отдавать другой контент пользователям с определенным User-Agent
Например, вы хотите, чтобы веб-страницы с заголовком User-Agent: wget
получали специальный контент. Это можно осуществить, изменив содержимое заголовка Host: запросы будут направляться на ваш сервер оригинации через отдельный виртуальный сервер bots.example.ru
.
Критерии №1 | Действие |
---|---|
Поле: http.request.headers.user-agent Оператор: equals Значение: wget | Действие: setHeader Загаловок: http.request.headers.host Значение заголовка: bots.example.ru |
Для удобства можно отключить опцию Учитывать регистр при редактировании этого правила.
Управление заголовками
1. Добавить заголовок в сторону сервера оригинации
Добавление дополнительного заголовка (например X-Cloud-Platform
) может быть полезно, если вы хотите пометить запросы, поступающие с Платформы NGENIX, для специальной обработки на вашем сервере. Например, для ведения лога или настройки политик безопасности на вашем веб-сервере. В качестве критерия может использоваться любое условие, которое будет выполняться для любого запроса.
Критерии №1 | Действие |
---|---|
Поле: http.request.method Оператор: exists | Действие: setHeader Загаловок: http.request.headers.x-cloud-platform Значение заголовка: NGENIX |
2. Удалить заголовок в сторону сервера оригинации
Например, вы можете настроить обработку запросов таким образом, чтобы данные отдавались без сжатия или только с использованием одного конкретного алгоритма сжатия, удаляя заголовок Accept-Encoding. Для этого можно использовать любое условие, которое будет выполняться для каждого запроса.
Критерии №1 | Действие |
---|---|
Поле: http.request.method Оператор: exists | Действие: delHeader Загаловок: http.request.headers.accept-encoding |
3. Сбор TLS-отпечатков доверенных устройств
Для сбора TLS-отпечатков необходимо создать правило обработки запросов, которое помечает запросы определенным заголовком. Например, tls-fingerprint-ngenix
.
Критерии №1 | Действие |
---|---|
Поле: tls.ngx_fingerprint_hash Оператор: exists | Действие: selHeader Загаловок: http.request.headers.tls-fingerprint-ngenix Значение заголовка: true |
Убедитесь, что правило стоит последним в списке в Наборе правил. Таким образом вы отсечете лишние запросы от нелегитимных источников и тем самым сократите объем данных для анализа. Рекомендуется собирать данные минимум в течение недели.
Last updated