Установка на платформу Kong¶
Необходимые условия
Платформа Kong должна соответствовать следующим требованиям:
- Kong версии 1.4.3 или ниже
- Установлена в соответствии с официальными инструкциями для одного из поддерживаемых Вебмониторэкс дистрибутивов
Обратите внимание, что для корректной работы Kong требуются:
- Либо подготовленные конфигурационные файлы
- Либо настроенная база данных
Убедитесь, что один из этих пунктов выполнен, прежде чем переходить к установке модулей Вебмониторэкс.
Смотрите также официальную документацию Kong.
Известные ограничения
- Не поддерживается директива
wallarm_block_page
. - Не поддерживается настройка через Kong Admin API.
Установка¶
Установка модуля постаналитики на отдельный сервер
Если вы планируете установить модуль постаналитики на отдельный сервер, необходимо сначала установить его. Подробнее в Отдельная установка модуля постаналитики.
Установка модуля Вебмониторэкс на платформу Kong проходит следующим образом:
-
Добавление репозиториев Вебмониторэкс.
-
Установка пакетов Вебмониторэкс.
-
Настройка постаналитики.
-
Настройка ноды для использования прокси‑сервера.
-
Подключение ноды к Вычислительному кластеру Вебмониторэкс.
-
Настройка адреса сервера постаналитики.
-
Настройка режима фильтрации.
-
Настройка логирования.
Необходимые условия
- Перед установкой отключите или настройте SELinux, если он установлен в операционной системе.
- Убедитесь, что вы выполняете все команды, приведенные ниже, от имени суперпользователя (например,
root
).
Если вы используете несколько нод Вебмониторэкс
Все ноды Вебмониторэкс, установленные в вашей инфраструктуре, должны иметь одинаковые версии. Аналогично для модулей постаналитики, установленных на отдельных серверах.
Перед установкой дополнительной ноды убедитесь, что ее версия совпадает с версией уже установленных модулей. Если версии модулей устарели или начинают устаревать (3.6
и ниже), рекомендуем обновить все модули до последней версии.
Чтобы получить версию ноды и модуля постаналитики, установленных на одном сервере:
apt list wallarm-node
apt list wallarm-node
yum list wallarm-node
Чтобы получить версию ноды и модуля постаналитики, установленных на разных серверах:
# выполните на сервере с нодой
apt list wallarm-node-nginx
# выполните на сервере с модулем постаналитики
apt list wallarm-node-tarantool
# выполните на сервере с нодой
apt list wallarm-node-nginx
# выполните на сервере с модулем постаналитики
apt list wallarm-node-tarantool
# выполните на сервере с нодой
yum list wallarm-node-nginx
# выполните на сервере с модулем постаналитики
yum list wallarm-node-tarantool
1. Добавьте репозитории Вебмониторэкс¶
Установка и обновление ноды Вебмониторэкс выполняются из репозиториев Вебмониторэкс.
В зависимости от вашей операционной системы, выполните одну из следующих команд:
curl -fsSL https://repo.webmonitorx.ru/wallarm.gpg | sudo apt-key add -
sh -c "echo 'deb http://repo.webmonitorx.ru/ubuntu/wallarm-node bionic/3.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list"
sudo apt update
sudo yum install -y epel-release
sudo rpm -i https://repo.webmonitorx.ru/centos/wallarm-node/7/3.6/x86_64/Packages/wallarm-node-repo-1-6.el7.noarch.rpm
Доступ к репозиториям
У системы должна быть возможность обратиться к https://repo.webmonitorx.ru
для загрузки пакетов. Убедитесь, что доступ не ограничен настройками файервола.
2. Установите пакеты Вебмониторэкс¶
Для установки ноды и модуля постаналитики на одном сервере выполните следующую команду:
sudo apt install --no-install-recommends wallarm-node kong-module-wallarm
sudo yum install wallarm-node kong-module-wallarm
Для установки только ноды выполните следующую команду:
sudo apt install --no-install-recommends wallarm-node-nginx kong-module-wallarm
sudo yum install wallarm-node-nginx kong-module-wallarm
3. Настройте постаналитику¶
Info
Пропустите этот шаг, если модуль постаналитики установлен на отдельный сервер. Вы уже настроили постаналитику во время отдельной установки.
Количество памяти влияет на качество работы статистических алгоритмов. В боевой среде мы рекомендуем выделять для модуля постаналитики 75% от общей памяти виртуальной машины. Например, если у сервера 32 ГБ памяти, оптимально выделить под хранилище 24 ГБ. На сервере с небольшим объемом памяти или для тестирования ноды вы можете выделить меньшее количество памяти (например, 25% от общего объема).
Укажите объем оперативной памяти для Tarantool:
Откройте конфигурационный файл Tarantool:
sudo vim /etc/default/wallarm-tarantool
sudo vim /etc/sysconfig/wallarm-tarantool
Укажите размер выделяемой памяти в конфигурационном файле Tarantool директивой SLAB_ALLOC_ARENA
. Значение может быть целым или дробным (разделитель целой и дробной части — точка).
Например:
SLAB_ALLOC_ARENA=0.5
SLAB_ALLOC_ARENA=24
Перезапустите Tarantool:
sudo service wallarm-tarantool restart
sudo systemctl restart wallarm-tarantool
4. Настройте ноду для использования прокси‑сервера¶
Info
Данный этап настройки предназначен для пользователей, использующих свой прокси‑сервер для работы защищаемых веб‑приложений.
Если вы не используете прокси‑сервер, пропустите этот этап настройки.
Чтобы настроить ноду Вебмониторэкс для использования вашего прокси‑сервера, необходимо присвоить новые значения переменным окружения, которые определяют используемый прокси‑сервер.
Добавьте в файл /etc/environment
новые значения переменных окружения:
-
https_proxy
— прокси для протокола HTTPS -
http_proxy
— прокси для протокола HTTP -
no_proxy
— ресурсы, для запросов к которым необходимо отключить проксирование
Присвойте переменным https_proxy
и http_proxy
строки вида <scheme>://<proxy_user>:<proxy_pass>@<host>:<port>
, где:
-
<scheme>
— используемый протокол (должен совпадать с протоколом, для которого настраивается прокси в текущей переменной окружения) -
<proxy_user>
— имя пользователя для авторизации на прокси‑сервере -
<proxy_pass>
— пароль для авторизации на прокси‑сервере -
<host>
— хост используемого прокси‑сервера -
<port>
— порт используемого прокси‑сервера
Присвойте переменной no_proxy
значение в виде массива IP‑адресов и/или доменов, к которым нужно обращаться без использования прокси: "<res_1>, <res_2>, <res_3>, <res_4>, ..."
, где <res_1>
, <res_2>
, <res_3>
и <res_4>
— IP‑адреса и/или домены.
Ресурсы, к которым нужно обращаться без использования прокси
Для корректной работы системы в список ресурсов, к которым нужно обращаться без прокси, необходимо добавить следующие IP‑адреса и домен: 127.0.0.1
, 127.0.0.8
, 127.0.0.9
и localhost
.
IP‑адреса 127.0.0.8
и 127.0.0.9
используются для работы ноды Вебмониторэкс.
Пример корректного содержимого файла /etc/environment
ниже демонстрирует следующую конфигурацию:
-
HTTPS‑ и HTTP‑запросы проксируются на хост
1.2.3.4
с портом1234
, используя для авторизации на прокси‑сервере имя пользователяadmin
и пароль01234
. -
Для запросов к
127.0.0.1
,127.0.0.8
,127.0.0.9
иlocalhost
проксирование отключено.
https_proxy=http://admin:01234@1.2.3.4:1234
http_proxy=http://admin:01234@1.2.3.4:1234
no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost"
5. Подключите ноду к Вычислительному кластеру Вебмониторэкс¶
Доступ к API
Перед подключением к Вычислительному кластеру Вебмониторэкс убедитесь, что виртуальная машина с нодой имеет доступ к https://api.wallarm.ru:444
для работы с Вычислительным кластером Вебмониторэкс.
В случае проблем убедитесь, что доступ не ограничен файерволом.
В процессе работы нода Вебмониторэкс взаимодействует с Вычислительным кластером Вебмониторэкс. Чтобы подключить ноду к Вычислительному кластеру, выполните следующие действия:
-
Убедитесь, что роль вашего пользователя в Консоли управления Вебмониторэкс — Администратор или Деплой и для пользователя отключена двухфакторная аутентификация.
Для этого перейдите к списку пользователей в Консоли управления и проверьте столбцы Роль и Auth:
-
В системе с установленной нодой запустите скрипт
addnode
:sudo /usr/share/wallarm-common/addnode -H api.wallarm.ru
При необходимости укажите имя создаваемой ноды, используя опцию
‑n <имя ноды>
. Также, вы можете задать или изменить имя ноды в Консоли управления Вебмониторэкс → Ноды. -
Введите email и пароль от вашего аккаунта Вебмониторэкс.
6. Настройте адреса сервера постаналитики¶
Info
- Пропустите данный шаг, если модуль постаналитики и нода установлены на один сервер.
Добавьте в /etc/kong/nginx-wallarm.template
адреса серверов постаналитики:
upstream wallarm_tarantool {
server <ip1>:3313 max_fails=0 fail_timeout=0 max_conns=1;
server <ip2>:3313 max_fails=0 fail_timeout=0 max_conns=1;
keepalive 2;
}
# omitted
wallarm_tarantool_upstream wallarm_tarantool;
Необходимые условия
Для параметров max_conns
и keepalive
необходимо соблюдать следующие условия:
- Значение
keepalive
должно быть не меньше, чем количество серверов Tarantool. - Значение
max_conns
должно быть указано для каждого сервера, чтобы предотвратить создание лишних соединений.
По умолчанию строка # wallarm_tarantool_upstream wallarm_tarantool;
закомментирована – необходимо удалить #
.
7. Настройте режим фильтрации¶
Для настройки правил проксирования и фильтрации необходимо отредактировать файл конфигурации /etc/kong/nginx-wallarm.template
.
Подробную информацию о конфигурации NGINX вы можете найти в официальной документации NGINX.
Логика работы ноды Вебмониторэкс настраивается при помощи директив Вебмониторэкс. Список доступных директив Вебмониторэкс доступен по ссылке.
Пример файла конфигурации
Предположим, что вам необходимо настроить сервер для работы по следующим принципам:
-
Обработка HTTPS‑трафика не настроена
-
Запросы осуществляются к двум доменам:
example.com
иwww.example.com
-
Все запросы нужно передавать на сервер
10.80.0.5
-
Все входящие запросы меньше 1 МБ (значение по умолчанию)
-
Нет запросов, которые обрабатываются дольше 60 секунд (значение по умолчанию)
-
Система должна работать в режиме мониторинга
-
Клиенты обращаются к ноде напрямую, не через промежуточный HTTP‑балансировщик
Файл конфигурации в этом случае будет выглядеть следующим образом:
server {
listen 80;
listen [::]:80 ipv6only=on;
# the domains for which traffic is processed
server_name example.com;
server_name www.example.com;
# turn on the monitoring mode of traffic processing
wallarm_mode monitoring;
location / {
# setting the address for request forwarding
proxy_pass http://10.80.0.5;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
8. Настройте логирование¶
Настройте логирование переменных ноды Вебмониторэкс с помощью NGINX. Это позволит провести быструю диагностику состояния ноды в случае необходимости, основываясь на содержимом лог‑файла NGINX.
Запуск Kong¶
Запуск Kong с установленным модулем Вебмониторэкс выполняется следующей командой:
kong start --nginx-conf /etc/kong/nginx-wallarm.template
Установка завершена¶
На этом установка завершена.
Проверьте, что нода работает и пропускает через себя трафик. Подробнее по ссылке.
Настройки по умолчанию
Только что установленная нода будет находиться в режиме блокировки (см. описание директивы wallarm_mode
) в соответствии с настройками по умолчанию.
Дополнительные настройки¶
После установки нода Вебмониторэкс может потребовать дополнительной настройки.
Далее приводится несколько типовых настроек, которые вы можете выполнить, если это требуется.
Для получения информации о других доступных настройках, обратитесь к разделу Настройка руководства администратора.
Настройка отображения реального IP‑адреса клиента¶
Если нода Вебмониторэкс развернута за прокси‑сервером или балансировщиком нагрузки, то при такой схеме развертывания без дополнительной настройки адрес источника на ноде может совпадать с одним из IP‑адресов прокси‑сервера или балансировщика нагрузки, а не с IP‑адресом клиента.
В этом случае, если вы хотите, чтобы на ноду передавался IP‑адрес клиента в качестве адреса источника, то требуется дополнительная настройка прокси‑сервера или балансировщика.
Ограничение времени обработки единичного запроса¶
Используйте директиву Вебмониторэкс wallarm_process_time_limit
, чтобы задать ограничение времени обработки единичного запроса нодой.
Если запрос обрабатывается за большее время, чем указано в директиве, то в лог‑файл заносится информация об ошибке, а запрос помечается как атака overlimit_res
.
Ограничение времени ожидания ответа сервера¶
Используйте директиву NGINX proxy_read_timeout
, чтобы задать таймаут чтения ответа проксированного сервера.
Если за это время сервер ничего не передаст, то соединение будет закрыто.
Ограничение максимального размера запроса¶
Используйте директиву NGINX client_max_body_size
, чтобы задать ограничение на максимальный размер тела запроса клиента.
В случае превышения этого ограничения NGINX вернет клиенту ответ с кодом 413
(Payload Too Large
, также известный как Request Entity Too Large
).