Руководство по установке, настройке и эксплуатации основных компонентов Nemesida WAF — динамического модуля для Nginx и модуля машинного обучения Nemesida AI.
- Общая информация
- Подключение репозитория Nemesida WAF
- Установка модуля Nemesida WAF
- Настройка RabbitMQ
- Настройка динамического модуля Nemesida WAF
- Настройка модуля Nemesida AI
- Настройка взаимодействия с ClamAV
- Работа Nemesida WAF в режиме IDS
- Работа Nemesida WAF в режиме обратного прокси
- Работа Nemesida WAF в режиме кластера (active/active)
- Управление сигнатурами
- Статусы обработки запроса (BT)
- Интерфейс управления Nemesida WAF Management API
- Разблокирование IP-адреса с использованием капчи
- Синхронизация списка заблокированных IP-адресов
- Получение файла с базой GeoIP2
- Источники сообщений об ошибках
- Техническая поддержка
Доменное имя
example.comвместе с поддоменами в руководстве используется в качестве примера. Доменное имя.example.comвключает в себя основной домен и его поддомены. Доменное имя*.example.comвключает в себя поддомены, но не включает основной доменexample.com.
Требования к аппаратному обеспечению
Для работы компонентов Nemesida WAF необходимы аппаратные ресурсы, имеющие следующие характеристики:
- процессор: Intel Core i3 или выше;
- объем ОЗУ: 2 ГБ для сервера с установленным Nemesida WAF и 32 ГБ для сервера с установленным Nemesida AI MLC;
- дисковое пространство: от 5 ГБ.
Взаимодействие с внешними ресурсами
В процессе работы компоненты Nemesida WAF обращаются к nemesida-security.com:443 и nw-auth-extra.nemesida-security.com:443 для:
- проверки лицензионного ключа;
- загрузки и выгрузки поведенческих моделей и списка виртуальных хостов, определенных параметром
vhosts_listв конфигурационном файле Nemesida AI MLC; - загрузки информации об IP-адресах с GeoIP-сервера.
Бесплатное тестирование
Запросите лицензионный ключ для полноценного 14-ти дневного тестирования Nemesida WAF.
Docker-образ и Virtual Appliance
Nemesida WAF доступен в виде установочных дистрибутивов для ОС Linux, в виде Docker-образа и виртуального диска для KVM/VMware/VirtualBox.
Модель лицензирования
Каждый экземпляр динамического модуля Nemesida WAF для Nginx (установочный пакет nwaf-dyn) должен использовать уникальный лицензионный ключ (лицензию). Лицензия включает в себя право использования всех компонентов, входящих в состав Nemesida WAF, обновления и техническую поддержку. Лицензия предоставляется на один календарный год.
Установочные пакеты Nemesida WAF
Основные:
nwaf-dyn— динамический модуль Nemesida WAF для Nginx и агент для обработки поведенческих моделей Nemesida AI MLA. Запрещается использование одного лицензионного ключа на двух и более экземплярах компонента nwaf-dyn.nwaf-mlc— модуль машинного обучения Nemesida AI MLC, предназначен для построения поведенческих моделей и выявления прочих аномалий (например, атак методом перебора)
Вспомогательные:
nwaf-api— модуль Nemesida WAF API, предназначен для передачи информации о заблокированных запросах и результатах работы модулей Nemesida AI и Nemesida WAF Scanner в СУБД PostgreSQL.nwaf-cabinet— модуль Личный кабинет, предназначен для визуализации и аналитики событий работы компонентов из СУБД PostgreSQL.nwaf-st— модуль Nemesida WAF Signtest, предназначен для управления обучением модуля Nemesida AI.nwaf-scanner— сканер уязвимостей Nemesida WAF Scanner.
# apt install apt-transport-https
# wget -O- https://nemesida-security.com/repo/nw/gpg.key | apt-key add - # apt update && apt upgrade
# apt install apt-transport-https
# wget -O- https://nemesida-security.com/repo/nw/gpg.key | apt-key add - # apt update && apt upgrade
RabbitMQ должен располагаться на каждом сервере с установленным модулем Nemesida WAF или Nemesida AI MLC, даже если использование Nemesida AI MLC не планируется.
1. Установите пакет:
# apt install rabbitmq-server
2. Приведите файл /etc/rabbitmq/rabbitmq.config к виду:
[
{rabbitmq_management, [
{listener, [{port, 15672}, {ip, "127.0.0.1"}]}
]},
{kernel, [
{inet_dist_use_interface,{127,0,0,1}}
]}
].
3. Внесите изменения в файл /etc/rabbitmq/rabbitmq-env.conf:
export RABBITMQ_NODENAME=rabbit@localhost export RABBITMQ_NODE_IP_ADDRESS=127.0.0.1 export ERL_EPMD_ADDRESS=127.0.0.1
4. Завершите настройку RabbitMQ:
# chown rabbitmq:rabbitmq /etc/rabbitmq/rabbitmq.config # systemctl enable rabbitmq-server # service rabbitmq-server restart # service rabbitmq-server status
- Nginx stable, начиная с
1.12; - Nginx mainline, начиная с
1.15; - Nginx Plus, начиная с
R16.
В случае компиляции Nginx из исходного кода необходимо добавить параметры --with-compat --with-threads при выполнении configure для активации поддержки динамического модуля.
# apt install nwaf-dyn-1.18
где 1.18 — версия установленного Nginx. Например, пакет динамического модуля nwaf-dyn-1.12 предназначен для работы с Nginx версии 1.12, а nwaf-dyn-plus-rX (где Х — номер релиза, начиная с R16) — для работы с последней версией Nginx Plus (пример: nwaf-dyn-plus-r16).
# setenforce 0
после чего приведите файл /etc/selinux/config к виду:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of three two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
Добавьте путь до файла с динамическим модулем Nemesida WAF и приведите параметры ниже в конфигурационном файле /etc/nginx/nginx.conf к виду:
load_module /etc/nginx/modules/ngx_http_waf_module.so;
...
worker_processes auto;
...
http {
...
##
# Nemesida WAF
##
## Request body is too large fix
client_body_buffer_size 25M;
include /etc/nginx/nwaf/conf/global/*.conf;
include /etc/nginx/nwaf/conf/vhosts/*.conf;
...
}
Ошибка вида:
nginx: [emerg] module "/etc/nginx/modules/ngx_http_waf_module.so" version 1017010 instead of 1018000 in /etc/nginx/nginx.conf:1возникает в том случае, когда не совпадают версии установленного динамического модуля Nemesida WAF и Nginx. В данном случае
1017010— версия Nginx 1.17.10, для которой был скомпилирован модуль nwaf-dyn, а1018000— Nginx 1.18.0, установленный на сервере. Пакет динамического модуля nwaf-dyn-1.18 предназначен для работы с Nginx версии 1.18, а nwaf-dyn-plus-r22 — для работы с NGINX Plus R22.
Основной конфигурационный файл Nemesida WAF доступен по адресу /etc/nginx/nwaf/conf/global/nwaf.conf.
После внесения изменений выполните перезагрузку сервера или перезапуск сервисов и проверьте их работу:
# systemctl restart nginx nwaf_update mla_main # systemctl status nginx nwaf_update mla_main
За получение набора сигнатур (/etc/nginx/nwaf/rules.bin) для динамического модуля Nemesida WAF отвечает служба nwaf_update. Для проверки работы сигнатурного метода обнаружения атак при отправке запроса http://YOUR_SERVER/nwaftest сервер должен вернуть код ответа 403.
Модуль Nemesida WAF обрабатывает только транслированный до конечного приложения запрос. В случае, если настройки Nginx препятствуют трансляции обращений (возвращая, к примеру, код ответа
301или403), обработка подобных запросов модулем Nemesida WAF производиться не будет.
В случае изменения набора сигнатур на сервере nemesida-security.com служба nwaf_update автоматически обновит файл rules.bin. Если в период обновления набора сигнатур на сервере служба nwaf_update деактивирована, загрузка новой версии набора сигнатур произойдет сразу после запуска службы nwaf_update.
Дополнительный заголовок $nwaf_block_type
Nemesida WAF позволяет использовать специальный заголовок, определяющий результат обработки запроса. Для его активации необходимо добавить параметр add_header NemesidaWAF-BT $nwaf_block_type always; в область http, server или location конфигурационного файла nginx.
Пример использования заголовка
- Установите заголовок в область
server:server { ... add_header NemesidaWAF-BT $nwaf_block_type always; ... }и перезапустите
nginx. - Выполните запрос:
curl -i localhost/nwaftest
В ответе сервера в заголовке NemesidaWAF-BT будет содержаться информация о статусе обработки запроса:
HTTP/1.1 403 Forbidden Server: nginx/1.16.1 Date: Wed, 12 Feb 2020 19:05:26 GMT Content-Type: text/html Content-Length: 153 Connection: keep-alive NemesidaWAF-BT: 2 ...
В данном случае статус равен 2. Это означает, что запрос был заблокирован в связи с вхождением сигнатуры атаки со score равным 12 (nwaftest). Более подробная информация о статусе обработки запроса доступна в соответствующем разделе. Такой заголовок может быть полезен при генерации кастомизированной страницы ответа сервера (например, в случае блокирования запроса).
Прочая информация
Модуль не используется в Nemesida WAF Free.
Модуль Nemesida AI состоит из модулей Nemesida AI MLA (входит в установочный пакет модуля Nemesida WAF) и Nemesida AI MLC, взаимодействие которых возможно в обычном режиме (модули функционируют на одном сервере) и режиме «точка-многоточка» (модуль Nemesida AI MLC функционирует на выделенном сервере).
Точность поведенческих моделей
В период обучения для построения более качественных моделей не рекомендуется производить сканирование веб-приложения на уязвимости, а также направлять другие нелегитимные запросы. Сразу после первого обучения рекомендуется произвести переобучение моделей. Управление ложными срабатываниями производится с помощью модуля Nemesida WAF Signtest.Python pip-пакеты
Для корректной работы модулей машинного обучения необходимо использовать единые версии Python3 pip-пакетов на серверах с установленными Nemesida AI MLA и Nemesida AI MLC.Хранение поведенческих моделей
Поведенческие модели, созданные модулем Nemesida AI MLC, передаются на удаленный сервер Nemesida AI MLS и автоматически распространяются на все запущенные экземпляры Nemesida AI MLA и Nemesida AI MLC в соотвествии с WAF ID.
Nemesida AI MLA
Для настройки модуля внесите необходимые изменения в основной конфигурационный файл /etc/nginx/nwaf/mla.conf.
Модуль Nemesida AI MLA загружает модели в соответствии со списком, полученным из модуля Nemesida AI MLC (параметр
vhosts_listфайлаmlc.conf), и списком из очередиvhost, если она не пустая (за это отвечает опцияvhostпараметраnwaf_rmqв файлеnwaf.conf).
Nemesida AI MLC
Установите модуль (в случае установки модуля на выделенный сервер предварительно подключите репозиторий):
Установите Nemesida WAF MLC:
# apt install nwaf-mlc
Установите Nemesida WAF MLC:
# apt install nwaf-mlc
Независимо от режима работы, модулю Nemesida AI MLC требуется локально установленный экземпляр RabbitMQ. Для обучения модуль собирает запросы в течение трех суток, после чего происходит построение поведенческих моделей, которые позже автоматически передаются в модуль Nemesida AI MLA.
Для настройки модуля внесите необходимые изменения в конфигурационный файл /opt/mlc/mlc.conf.
После внесения изменений выполните перезапуск службы:
# service mlc_main restart # service mlc_main status
Переобучение моделей Nemesida AI
Для повышения точности определения атак рекомендуется выполнять переобучение моделей раз в неделю. Для этого необходимо добавить к значению виртуального хоста символ ^. Пример: vhosts_list = example.com^.
После внесения изменений выполните перезапуск службы:
# service mlc_main restart
После переобучения моделей рекомендуется удалить экспортированные запросы ВТ 12 (запросы содержатся на странице False Positive, доступной на веб-интерфейсе модуля Nemesida WAF Signtest). При обучении моделей для виртуального хоста запросы ВТ 12 войдут в обучающую выборку и далее не потребуются.
Увеличение срока обучения поведенческих моделей Nemesida AI
Основной вариант
Для корректного построения моделей требуется порядка 400.000-800.000 уникальных запросов. По умолчанию срок обучения составляет 4 дня. Период обучения модели можно изменить непосредственно при указании списка доменных имен в параметре vhosts_list в mlc.conf: x:example.com, где x — период обучения в днях. Например, 5:example.com — обучение модели будет длиться 5 дней.
После внесения изменений выполните перезапуск службы:
# service mlc_main restart
Дополнительный вариант
Если для требуемого количества запросов необходимо продлить период обучения, выполните следующие действия:
1. Остановите сервис Nemesida AI MLC:
# service mlc_main stop
2. Переименуйте файл /opt/mlc/ml/[vhost]_[timestamp].db, где [timestamp] — дата начала обучения моделей, от которой рассчитывается период обучения. Например, для увеличения срока построения моделей на пять дней необходимо увеличить значение timestamp на такой же период:
# mv /opt/mlc/ml/example.com_1587416400.db /opt/mlc/ml/example.com_1587848400.db
3. Запустите сервис Nemesida AI MLC:
# service mlc_main start
Дообучение моделей с использованием резервной копии обучающей выборки
Для корректного построения моделей требуется порядка 400.000-800.000 уникальных запросов. Если во время обучения количество запросов было недостаточным, то можно его перезапустить и воспользоваться запросами из прошлой выборки. Для этого выполните следующие действия:
1. Остановите сервис Nemesida AI MLC:
# service mlc_main stop
2. Переместите файл /opt/mlc/ml/backup/[vhost].d_[timestamp], где [timestamp] — дата создания резервной копии обучающей выборки, созданной Nemesida AI MLC перед началом построения модели, в /opt/mlc/ml/[vhost].d. Например, для модели example.com:
# mv /opt/mlc/ml/backup/example.com.d_1613587613 /opt/mlc/ml/example.com.d
3. Запустите обучение. Для этого необходимо добавить к значению виртуального хоста символ ^. Пример: vhosts_list = example.com^.
Запустите сервис Nemesida AI MLC:
# service mlc_main start
После завершения периода обучения (период можно изменить) поведенческая модель будет создана на основе запросов из общей выборки.
Удаление моделей Nemesida AI
В случае некорректного обучения поведенческих моделей или значительных изменений в веб-приложении, приводящих ко множеству ложных срабатываний, рекомендуется удалить модели. Для этого отправьте запрос на support@nemesida-security.com. В запросе укажите лицензионный ключ, используемый в Nemesida WAF.
Обучающая выборка при построении поведенческих моделей
Запросы, определенные как BT 1, BT 2, BT 3 и BT 4, не добавляются в обучающую выборку, даже если попадают под действие режима LM.
При включенном режиме ai_extra запросы, определенные модулем Nemesida AI MLC как нелегитимные, не добавляются в обучающую выборку.
Для активации антивирусной защиты установите ПО ClamAV на сервер с настроенным ПО Nemesida WAF, если это не было сделано ранее.
Пример установки для ОС Debian 9:
# apt install clamav-daemon
Включение функционала взаимодействия с ПО ClamAV осуществляется путем активации параметра nwaf_clamav в файле /etc/nginx/nwaf/conf/global/nwaf.conf и приведения файла /etc/clamav/clamd.conf к виду:
... TCPSocket 3310 TCPAddr 127.0.0.1 ...
После внесения изменений необходимо перезапустить Nginx.
1. На основном сервере (без установленного модуля Nemesida WAF) настройте зеркалирование трафика согласно руководству установленного веб-сервера (Nginx, Apache2, Microsoft IIS и прочие).
2. На сервере с установленным модулем Nemesida WAF приведите конфигурационный файл виртуального хоста Nginx к виду:
server {
listen 80;
index index.html;
root /var/www/html;
try_files $uri $uri/ /index.html;
}
3. На сервере с установленным модулем Nemesida WAF создайте директорию /var/www/html и разместите в ней пустой файл index.html.
4. На сервере с установленным модулем Nemesida WAF приведите файл /etc/nginx/nwaf/conf/global/nwaf.conf к виду:
... nwaf_limit rate=5r/m block_time=0; ...
5. После внесения изменений необходимо перезапустить Nginx на каждом из серверов.
Для использования веб-сервера с установленным Nginx и Nemesida WAF в качестве промежуточного сервера необходимо создать соответствующий файл виртуального хоста (например, /etc/nginx/conf.d/example.com.conf).
Более подробная информация доступна на странице официальной документации Nginx.
Для работы Nemesida WAF в составе кластера все использующиеся лицензионные ключи должны иметь единый WAF ID (идентификатор, позволяющий объединять различные лицензионные ключи в группу). Для группировки лицензионных ключей в единый WAF ID отправьте запрос на support@nemesida-security.com.
Поведенческие модели машинного обучения, а также запросы FP, экспортированные через функционал Nemesida WAF Signtest, будут автоматически загружены на все экземпляры кластера в соответствии с WAF ID. Для более точного выявления атак рекомендуется в один момент времени использовать один установленный экземпляр модуля Nemesida AI MLC.
При использовании Nemesida WAF в качестве кластерного решения в режиме active/active необходимо:
1. Организовать синхронизацию конфигурационных файлов Nemesida WAF (по умолчанию каталог /etc/nginx/nwaf/, исключая объекты /etc/nginx/nwaf/rules.bin и /etc/nginx/nwaf/ml/) со всеми экземплярами установки. Синхронизация должна производиться после каждого внесения изменений в конфигурационные файлы.
2. После синхронизации объектов необходимо на каждом установленном экземпляре динамического модуля Nemesida WAF актуализировать параметры в файле /etc/nginx/nwaf/conf/global/nwaf.conf:
nwaf_license_key(обязательно);nwaf_api_proxyиnwaf_sys_proxy(опционально).
3. После внесения изменений необходимо перезапустить сервисы:
# nginx -t && systemctl reload nginx # systemctl restart nwaf_update mla_main
В Nemesida WAF и Nemesida WAF Free реализован функционал поддержки пользовательского набора правил для выявления атак: сигнатур (RL), а также их исключений (WL).
Зоны и уточнения
При создании RL или WL правил могут быть использованы специальные параметры:
- зоны:
URL,ARGS,BODY,HEADERS,Cookie,User-Agent,Content-Typeи т. д.; - условия применения правила (уточнение зоны, конкретизация):
$URL,$ARGS,$BODY,$HEADERS,$Cookie,$User-Agentи т. д.
Использование зон и уточнений позволяет максимально конкретизировать создаваемое правило. Уточнения задаются путем добавления префикса $ (например: "Z:...|$URL:...").
Пример использования правила с зоной и уточнением: WL ... "Z:ARGS|$URL:/123"; — правило сработает, если зоной вхождения правила RL будет зона ARGS и URL содержит вхождение /123.
Несколько параметров (зоны, уточнения) в одном правиле должны разделяться символом |, при этом будет использоваться следующий принцип взаимодействия:
- зоны взаимодействуют между собой по принципу логического
ИЛИ, например:Z:URL|ARGS; - зоны взаимодействуют с уточнениями по принципу логического
И, например:Z:URL|$ARGS:123; - уточнения взаимодействуют между собой по принципу логического
И, например:Z:...|$ARGS:123|$BODY:123".
Регулярные выражения в уточнениях
При уточнении допустимо использовать регулярные выражения. Для этого необходимо добавить к уточнению постфикс _X (например: "Z:...|$URL_X:\w+").
В случае использования символа | в качестве обычного символа необходимо:
- для обычного правила: произвести его двойное экранирование (например:
Z:...|$BODY:block\\|page– поиск вхожденияblockилиpage); - для правила с регулярным выражением (с постфиксом
_X): произвести его четырехкратное экранирование (например:$BODY_X:block\\\\|page– поиск вхожденияblock|page).
В случае использования в правиле с регулярным выражением (с постфиксом _X) других символов из набора операторов регулярных выражений (/, ., *, ?, !, {, }, [, ], (, ), ^, $, :, \ и т. д.) в качестве обычных символов необходимо производить их двойное экранирование (например: $BODY_X:data=\\(block-\\\a\\\-in-the-main\\) – поиск вхождения (block-\a\-in-the-main); $HEADERS_X:Accept\\: image\\/webp\\\\\* – поиск вхождения Accept: image/webp\*).
Для использования в уточнениях разделителя как метасимвола регулярного выражения его необходимо экранировать два раза. Пример: правило WL ... "Z:...|$URL_X:/(a\\|b)/"; будет применяться к URL, который содержит /a/ или /b/.
Создание персональных сигнатур
Персональные правила определения признака атаки (user-defined RL) можно хранить в основном конфигурационном файле Nemesida WAF (nwaf.conf) или в самостоятельно созданном файле вида *.conf, размещенном в директории /etc/nginx/nwaf/conf/vhosts. Персональные сигнатуры должны определяться параметром RL, иметь ID в диапазоне от 50000 до 99999 и принимать следующий вид:
RL ID:50000 "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50001 domain=example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50002 domain=.example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50003 domain=*.example.com "P:select from" "SC:SQL:12" "Z:ARGS";
RL ID:50004 "PX:select\s+from" "SC:SQL:12" "Z:ARGS|$URL:/admin";
RL ID:50005 "P:select from" "SC:SQL:12" "Z:ARGS|$URL_X:/(admin\|dev)";
Для сигнатур в области зоны допускается использование значения MLA для принудительной отправки запроса в Nemesida AI MLA, попадающего под действие созданной сигнатуры запроса, если score < 12 (по умолчанию в Nemesida AI MLA направляются запросы со score равным или превышающим значение параметра mla_score).
Создание правил исключения сигнатуры
В случае, когда запрос попадает под действие сигнатуры, помимо отправки инцидента в Nemesida WAF API, в журнале ошибок работы Nginx (для коммерческой версии Nemesida WAF) будет содержаться следующая строка:
Nemesida WAF: the request ххх contains a rule id 1 in zone HEADERS, ...
или, если запрос содержит сигнатуру с предельно допустимым цифровым показателем значимости (score = 12):
Nemesida WAF: the request ххх blocked by rule id 1 in zone HEADERS, ...
где:
1— ID сигнатуры атаки;HEADERS— зона вхождения сигнатуры.
Для вывода абсолютно всех вхождений сигнатур в запросе (при наличии вхождений), в том числе тех вхождений, которые не привели к последующему блокированию запроса, активируйте параметр nwaf_log_mr_all; в файле nwaf.conf.
Информация о составе текущего набора сигнатур доступна на странице rlinfo.nemesida-security.com.
Перевод правил блокировки в режим LM
Запросы, попадающие под действие режима LM, фиксируются в БД, но не блокируются. При срабатывании правила в журнал ошибок Nginx и на Nemesida WAF API будет отправлено сообщение о переводе соответствующего правила блокировки в LM режим, но запрос не будет заблокирован. Правила перевода в режим LM должны определяться параметром LM, иметь ID соответствующего правила блокировки и принимать следующий вид:
Каждому запросу, поступающему на анализ в модуль Nemesida WAF, присваивается идентификатор блокировки (BT — blocking type). Идентификатор может присваиваться независимо от того, был ли заблокирован запрос.
В сводной таблице представлены типы идентификаторов и соответствующий им статус обработки запросов.
| 0 | Запрос не был заблокирован. |
| 1 | Запрос заблокирован сигнатурным методом, при этом запрос не содержал ни одной сигнатуры со score = 12.
|
| 2 | Запрос заблокирован сигнатурным методом, при этом в запросе содержалась сигнатура, имеющая score = 12.
|
| 3 | Запрос заблокирован модулем Nemesida AI MLA. |
| 4 | Запрос заблокирован модулем ClamAV. |
| 5 | Запрос заблокирован вследствие внутренней ошибки. |
| 6 | Запрос заблокирован вследствие превышения лимита заблокированных запросов с одного IP-адреса. |
| 7 | Запрос определен как попытка перебора (brute-force) и заблокирован модулем Nemesida AI MLC. |
| 8 | Запрос заблокирован модулем Nemesida AI MLC (дополнительный анализ трафика всех незаблокированных модулем Nemesida WAF запросов) и управляется параметром ai_extra в файлах nwaf.conf и mlc.conf.
|
| 9 | Запрос определен как попытка флуда (flood) и заблокирован модулем Nemesida AI MLC. |
| 10 | Запрос определен как атака «отказ в обслуживании» и заблокирован модулем Nemesida AI MLC. |
Для событий BT 1, 2, 3, 4, 8 параметр nwaf_limit файла nwaf.conf позволяет регулировать допустимое количество заблокированных запросов. При превышении допустимого количества запросов, определенного опцией rate, IP-адрес будет заблокирован на время (в секундах), указанное в block_time.
Для событий BT 7, 9, 10 блокирование IP-адреса источника запросов будет происходить после первого заблокированного запроса, независимо от значения параметра rate в nwaf_limit.
Интерфейс не используется в Nemesida WAF Free.
Для корректной работы Nemesida WAF Management API необходимо разместить все управляемые параметры Nemesida WAF в файле /etc/nginx/nginx/nwaf/conf/global/nwaf.conf. Не допускается размещение управляемых параметров Nemesida WAF в других файлах конфигураций.
Для активации интерфейса управления Nemesida WAF Management API необходимо в файле виртуального хоста в секцию server добавить параметр nwaf_mgmt_api on;, например:
server {
listen 80;
server_name example.com;
location /nwaf_mgmt_api_path {
...
nwaf_mgmt_api on;
...
}
...
}
После активации параметра nwaf_mgmt_api on; и перезапуска Nginx функционал Nemesida WAF Management API становится доступным по целевому URI с установленной опцией nwaf_mgmt_api, например example.com/nwaf_mgmt_api_path.
В целях безопасности рекомендуется ограничить обращения к интерфейсу управления Nemesida WAF Management API через список разрешенных IP-адресов для предотвращения управления процессами работы Nemesida WAF неавторизованными пользователям.
nwaf_limit в конфигурационном файле nwaf.conf). Используя функционал капчи, пользователь может разблокировать собственный IP-адрес, если он был определен как источник атак методом перебора (BT 7), флуда (BT 9) или атак «отказ в обслуживании» (BT 10).
Для корректной работы механизма разблокировки IP-адреса необходимо активировать параметр nwaf_captcha_unban, добавив его в файле виртуального хоста в секцию server для определенного URL-адреса, или активировать и настроить Nemesida WAF Management API.
Пример активации параметра nwaf_captcha_unban:
server {
listen 80;
server_name example.com;
location /captcha_ip_unban_path {
...
nwaf_captcha_unban on;
...
}
...
}
Также необходимо настроить веб-приложение с капчей. С подробной инструкцией по интеграции Nemesida WAF c функционалом reCAPTCHA можно ознакомиться по ссылке.
После активации параметра nwaf_captcha_unban on; и перезапуска Nginx функционал разблокировки IP-адреса становится доступным для целевого URL-адреса с установленной опцией nwaf_captcha_unban. Например: example.com/captcha_ip_unban_path.
При правильном ответе веб-приложение с капчей направляет запрос delete_banned_ip в модуль Nemesida WAF для разблокировки IP-адреса. После этого пользователь будет переадресован на исходную страницу.
В целях безопасности рекомендуется разрешить обращения на
URL-адрес сервера с установленным динамическим модулем Nemesida WAF и активированным параметром разблокировки IP-адресаnwaf_captcha_unbanтолько с IP-адреса сервера с капчей.
Не используется в Nemesida WAF Free.
Функционал Nemesida WAF позволяет организовать автоматическую синхронизацию заблокированных IP-адресов между серверами. Время блокирования IP-адреса определяется опцией nwaf_limit в конфигурационном файле nwaf.conf. Для активации синхронизации заблокированных IP-адресов на всех серверах, использующих данный функционал, необходимо:
- установить единые значения параметров
nwaf_limitиnwaf_sync_ban_ip_keyв файлеnwaf.conf; - определить целевой URL для синхронизации при помощи параметра
nwaf_sync_ban_ip_hostв файлеnwaf.conf. - определить путь с установленным параметром
nwaf_ban_ip_sync on;в файле виртуального хоста в секцииlocationдля получения списка заблокированных адресов, например:location /ban_ip_sync_path { ... nwaf_ban_ip_sync on; ... }
В целях безопасности рекомендуется ограничить обращения к интерфейсу управления синхронизацией заблокированных IP-адресов списком разрешенных IP-адресов для предотвращения
управления процессами работы Nemesida WAF неавторизованными пользователям.
- перейти по адресу и выбрать в разделе
ProductsпунктGeoLite2 Free Geolocation Data; - произвести регистрацию учетной записи, заполнив все обязательные поля и указав действующий адрес электронной почты;
- подтвердить регистрацию, перейдя по ссылке из отправленного на электронную почту письма;
- зайти в раздел
Account Summaryв личном кабинете и перейти по ссылкеDownload Database; - на открывшейся странице найти
GeoLite2 Countryи скачать архив, кликнув по ссылкеDownload GZIP; - распаковать полученный архив для получения
mmdbфайла с базой.
- в системных журналах ОС;
- в журнале работы Nginx;
- в журнале работы RabbitMQ;
- в журнале работы модулей Nemesida WAF
/var/log/nwaf/.
Для пользователей Nemesida WAF Free техническая поддержка оказывается только на форуме.
В случае возникновения непредвиденных ошибок в работе Nemesida WAF свяжитесь с технической поддержкой по телефону +7 (495) 204-19-72, электронной почте или оставьте сообщение на форуме.