Настройка Системы

Настройка конфигурации Веб-сервера

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

Структура конфигурационных файлов Веб-сервера

В качестве Веб-сервера используется веб-сервер Nginx.

В конфигурационном файле сервиса Weblock.NginxConnector /etc/waf-ngxcnd/ngxcnd.conf заданы пути к перманентному и рабочему конфигурационным файлам в директивах:

work_conf_directory – путь к директории с рабочим конфигурационным файлом nginx.conf,

permanent_conf_directory – путь к директории с перманентным конфигурационным файлом nginx.conf.

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

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

Примечание

В дальнейшем, при описании настройки конфигурационного файла Веб-сервера, имеется в виду редактирование перманентного конфигурационного файла Веб-сервера.

Также конфигурационный файл сервиса Weblock.NginxConnector содержит следующие директивы:

log_level – уровень фиксации сообщений о событиях безопасности в журнале регистрации сервиса Weblock.NginxConnector. Возможные значения: FATAL, ERROR, WARN, INFO. Значение по умолчанию: ERROR.

log_folder – путь к директории с журналом регистрации событий сервиса Weblock.NginxConnector.

Особенности рабочего конфигурационного файла Веб-сервера

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

  • daemon,

  • user,

  • cluster_id (в блоке weblock),

  • brokers (в блоке weblock).

Настройка конфигурационного файла Веб-сервера

Настроить конфигурацию Веб-сервера можно двумя способами:

Далее покажем, как настроить конфигурацию Веб-сервера в конфигурационном файле.

Конфигурация Веб-сервера настраивается в перманентном конфигурационном файле nginx.conf, включающем дополнительные файлы для каждого защищаемого веб-ресурса (в терминологии Nginx – «сервера») /etc/waf-agent/servers/server_0xx.conf.

После редактирования конфигурации Веб-сервера следует проверить синтаксис и перезагрузить сервис Weblock.NginxConnector и веб-сервер Nginx командами:

$ sudo nginx -t
$ sudo systemctl restart waf-ngxcnd

При этом перманентный конфигурационный файл Веб-сервера автоматически преобразуется в рабочий конфигурационный файл, который применяет Веб-сервер.

Подключение веб-приложения

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

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

Рекомендуем для каждого защищаемого веб-ресурса (сервера) в соответствующий конфигурационный файл server_0xx.conf поместить следующие строки:

server {
    listen 80;
    server_name domain;
    return 301 https://$server_name$request_uri;
}
server {
    listen 443 ssl;
    http2 on;
    listen [::]:443 ssl;
    server_name domain;
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/cert.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    weblock_limit_zone_size 128m;
    weblock_iprange_ban_zone_size 64m;
    weblock_sync_bans_default_state on;
    weblock_ad_cookie_http_only on;
    weblock_ad_cookie_secure on;
    weblock_blocked_request_page <путь>;
    weblock_ad_blocked_request_page <путь>;
    weblock_page_502 <путь>;
    weblock_page_503 <путь>;
    weblock_page_504 <путь>;
    weblock_ad_client_counters_max 4194304;
    weblock_ad_limit_exceed_status 429;
    weblock_ban_status 418;
    weblock_iprange_ban_status 418;
    location / {
        proxy_pass http://ip:port;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $binary_remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_verify off;
    }
}

где:

  • server_name - доменное имя защищаемого веб-ресурса (одинаковое в обоих блоках server),

  • ssl_certificate и ssl_certificate_key - путь к SSL сертификатам,

  • weblock_limit_zone_size – максимальный размер зоны разделяемой памяти в Мб для ключей конфигурации запроса ($binary_remote_addr и др.),

  • weblock_iprange_ban_zone_size – максимальный размер зоны разделяемой памяти в Мб для Списков доступа,

  • weblock_sync_bans_default_state – флаг включения по умолчанию синхронизации Ban-Sync блокировок и переводов в строгий режим между инстансами в кластере,

  • weblock_ad_cookie_http_only – флаг применения куки в защитах F2B, Анти-DDoS, когда не требуется обращение куки через JavaScript,

  • weblock_ad_cookie_secure – флаг применения куки в защитах F2B, Анти-DDoS только, когда запрос отправляется по протоколу SSL и HTTPS,

  • weblock_blocked_request_page – путь к странице с ошибкой, возникающей при нарушении правил ModSecurity,

  • weblock_ad_blocked_request_page – путь к странице с ошибкой, выдаваемой при блокировке запроса защитой Анти-DDoS,

  • weblock_page_5хх – путь к странице с ошибкой 5хх,

  • weblock_ad_client_counters_max – максимальное количество счетчиков баллов клиента, которое должно превышать число одновременных соединений, а также превышать среднее количество клиентов за период действия Анти-DDoS куки, число от 524288 до 67108864; при превышении количества счетчиков каждый новый клиент сбросит счетчик самого старого клиента,

  • weblock_ad_limit_exceed_status – код ошибки, выдаваемой при блокировке запроса защитой Анти-DDoS,

  • weblock_ban_status – код ошибки, выдаваемой при блокировке запроса защитами F2B,

  • weblock_iprange_ban_status – код ошибки, выдаваемой при блокировке запроса по Спискам доступа,

  • proxy_pass - протокол, IP-адрес (или доменное имя) и порт проксируемого сервера.

Примечание

По терминологии Nginx защищаемые веб-серверы и веб-приложения называются просто «серверы» по имени блока server. В Личном кабинете «серверы» – защищаемые веб-ресурсы.

Примечание

Подробнее о директивах веб-сервера Nginx можно узнать из официальной документации: https://docs.nginx.com/nginx/admin-guide/web-server/web-server/.

Путь к журналу регистрации событий Веб-сервера logs/error.log и уровень фиксации сообщений в журнале при необходимости задаются в конфигурационном файле веб-сервера Nginx стандартной директивой.

После редактирования конфигурации Веб-сервера следует перезагрузить сервис Weblock.NginxConnector и Веб-сервер командой:

$ sudo systemctl restart waf-ngxcnd

Таким образом под защиту ставятся:

  • сервер порта 80 (http),

  • сервер порта 443 (https) (того же домена).

Примечание

Для каждого сервера можно отдельно настраивать защиту от атак в Личном кабинете в разделе Структура. Серверы.

Подключение нескольких веб-приложений

Чтобы защитить несколько веб-ресурсов (серверов), нужно:

  • создать и настроить соответствующее количество конфигурационных файлов server_0xx.conf,

  • подключить их в перманентном конфигурационном файле nginx.conf,

  • перезагрузить Веб-сервер.

Примечание

Директива server_name поддерживает только одно доменное имя.


lk_simbol Пример 1. Если в конфигурационном файле Веб-сервера задана директива server_name с несколькими доменными именами:

server_name weblock.ru waf.weblock.ru

то будет обработано только первое – weblock.ru, остальные игнорируются.


lk_simbol Пример 2. С помощью переадресации одно и то же веб-приложение может быть доступно по разным доменным именам.

Например, физически веб-приложение находится в домене weblock.ru, а с помощью переадресации это же приложение доступно по имени weblock.su.

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

server_name weblock.su
proxy_pass weblock.ru

А также создается второй файл server_0xx.conf для weblock.ru, чтобы обеспечить защиту обоих веб-приложений.


Отключение веб-приложения

Снять с защиты веб-ресурс (сервер) можно, удалив его конфигурационный файл server_0xx.conf и его подключение в перманентном конфигурационном файле Веб-сервера.

После изменения конфигурации Веб-сервера следует перезагрузить веб-сервер Nginx командой:

$ sudo systemctl restart waf-ngxcnd

Настройка конфигурации под веб-страницы

Если среди страниц защищаемого веб-приложения есть отдельные веб-страницы с особым режимом трафика, то для персональной настройки защиты таких веб-страниц следует в ходе настройки конфигурационного файла Веб-сервера указать эти веб-страницы в блоке location.

Примечание

Настройка защиты страниц веб-приложения осуществляется в Личном кабинете в разделе Структура. Пути.

В рекомендуемой настройке конфигурационного файла Веб-сервера у сервера, слушающего порт 443, задан блок location /. Поэтому в Личном кабинете будут отображаться два варианта настройки:

  • общая для сервера (domain),

  • для веб-страниц (domain/).

Чтобы добавить веб-страницы с особым режимом трафика, следует добавить блок location с путем к этой группе страниц.


lk_simbol Пример. Настройка персональной защиты для веб-страниц weblock.ru/list/.

В конфигурационном файле Веб-сервера в блоке server блок location дублируется; в первом указываются веб-страницы list/, а во втором – остальные веб-страницы, например:

  • блок location /list/

  • блок location /^(?!list)/

Тогда в Личном кабинете будут отображаться три варианта настройки:

  • общая для сервера (weblock.ru),

  • для веб-страниц weblock.ru/list/,

  • для остальных веб-страниц (weblock.ru/^(?!list)/).


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

После изменения конфигурации Веб-сервера следует перезагрузить веб-сервер Nginx командой:

$ sudo systemctl restart waf-ngxcnd

Настройка размера тела запроса

Если защищаемый веб-ресурс используется для загрузки файлов, рекомендуем добавить в конфигурационный файл Веб-сервера в соответствующие веб-ресурсу блоки server и location директиву client_max_body_size, регулирующую максимально допустимый размер тела запроса.

По умолчанию Веб-сервер пропускает запросы с телом ≤ 1 Мб.

При этом Система по умолчанию ограничивает тело запроса ≤ 12 Мб.

Рекомендуем установить:

client_max_body_size = 12m;

либо, чтобы размер тела запроса не проверялся:

client_max_body_size = 0;

После изменения конфигурации Веб-сервера следует перезагрузить веб-сервер Nginx командой:

$ sudo systemctl restart waf-ngxcnd

Настройка капчи

Система применяет сервис капчи при подозрительном трафике. Система позволяет подключить сервис reCAPTCHA или Yandex Smart CAPTCHA. Подключение сервиса капчи необходимо для работы механизма защиты от DDoS-атак уровня приложений (подробнее F2B, Анти-DDoS).

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

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

Примечание

Официальная документация сервиса reCAPTCHA: https://developers.google.com/recaptcha/intro?hl=ru.

Примечание

Официальная документация сервиса Yandex Smart CAPTCHA: https://cloud.yandex.ru/docs/smartcaptcha/quickstart.

  1. Добавить директивы в конфигурационный файл Веб-сервера в блок server, слушающий 443 порт (listen 443 ssl), и разместить их первыми среди блоков location.

Важно

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

Для подключения сервиса reCAPTCHA добавляются следующие строки:

location /my_captcha {
    weblock_ad_captcha_page "../captcha.html";
}
location /my_captcha/my_cool_handler/ {
    proxy_request_buffering on;
    proxy_buffering on;
    proxy_set_body $request_body&secret=xxxx&remoteip=$remote_addr;
    proxy_set_header Cookie "";
    proxy_set_header Accept-Encoding "";
    proxy_set_header Host www.google.com;
    proxy_set_header Content-Type "application/x-www-form-urlencoded";
    proxy_pass https://www.google.com/recaptcha/api/siteverify;
    proxy_http_version 1.1;
    proxy_ssl_session_reuse on;
    weblock_ad_captcha_page_validate_json_response "success" "true";
}

где

  • в директиве weblock_ad_captcha_page указать полный путь к файлу со страницей капчи;

  • в директиве proxy_set_body в параметре secret для проверки ответа указать полученный секретный ключ.

Для подключения сервиса Yandex Smart CAPTCHA добавляются следующие строки:

location /captcha/handler/ {
    weblock_ad_captcha_page "../captcha.html";
}
location /my_captcha/my_cool_handler/ {
    proxy_request_buffering on;
    proxy_buffering on;
    set $args $args&secret=xxxxxx&ip=$remote_addr;
    proxy_set_header Host smartcaptcha.yandexcloud.net;
    proxy_pass https://smartcaptcha.yandexcloud.net/;
    proxy_set_header Cookie "";
    proxy_set_header Accept-Encoding "";
    proxy_http_version 1.1;
    proxy_ssl_session_reuse on;
    weblock_ad_captcha_page_validate_json_response "status" "ok";
}

где

  • в заголовке блока location указать путь к обработчику капчи;

  • в директиве weblock_ad_captcha_page указать полный путь к файлу со страницей капчи;

  • в директиве set в параметре secret для проверки ответа указать полученный ключ сервера.

  1. Для сервиса Yandex Smart CAPTCHA в файле со страницей капчи указать ключ клиента и путь к обработчику капчи.


lk_simbol Пример. Параметры в файле со страницей капчи для сервиса Yandex Smart CAPTCHA:

sitekey: ‘<ключ клиента>’,

fetch('/captcha/handler/validate?token='+token).then(response => {

где /captcha/handler/ - путь к обработчику капчи, как в конфигурационном файле Веб-сервера.


  1. После изменения конфигурационного файла Веб-сервера следует перезагрузить Веб-сервер командой:

    $ sudo systemctl restart waf-ngxcnd
    

Настройка фиксации сообщений

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

Для детализации диагностики защиты F2B, Анти-DDoS, Рейт-лимиты, ModSecurity рекомендуется подключить фиксацию критичных сообщений уровней EMERGENCY, ALERT, CRITICAL, ERROR.

Если Система содержит опциональный сервис Weblock.ML-ADS, тогда необходимо подключить фиксацию критичных сообщений уровней EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE.

Подключение осуществляется двумя способами:

  • с помощью API «Weblock.» (см. ниже),

  • в Личном кабинете в разделе «Структура. Серверы» функция Настройки.

Здесь покажем подключение с помощью API «Weblock.»:

а) Сначала получаем токен авторизации с помощью эндпоинта API oidc/oauth2/token. Токен необходим для работы с другими эндпоинтами API.

б) Затем получаем идентификаторы кластеров и серверов с помощью эндпоинта controller/v1/clusters.

Примечание

Система компонует защищаемые веб-серверы и веб-приложения в кластеры.

в) Наконец для каждого сервера подключаем фиксацию критичных сообщений с помощью эндпоинта controller/v1/clusters/{clusterId}/server/{serverIndex}/configuration метода POST с входными параметрами:

{
    "logBanlimBlockedRequests": true,
    "logAllRequests": true,
    "logLevel": "ERROR",
    "logRequestBody": false
}

где вместо {clusterId} – идентификатор кластера,

вместо {serverIndex} – идентификатор сервера,

logBanlimBlockedRequests – флаг логирования запросов, заблокированных функционалом F2B, Анти-DDoS.

logAllRequests – флаг логирования запросов, заблокированных любым функционалом защиты (Личный кабинет, разделы «Структура» – «Серверы» - Настройки, ML ADS).

logLevel – параметр, задающий уровень фиксации критичных сообщений.

logRequestBody – флаг логирования тела сообщений, не влияет на подключение фиксации критичных сообщений.


lk_simbol Пример. Подключение фиксации критичных сообщений для работы сервиса Weblock.ML-ADS эндпоинтом controller/v1/clusters/{clusterId}/server/{serverIndex}/configuration метода POST с входными параметрами:

{
    "logBanlimBlockedRequests": true,
    "logAllRequests": true,
    "logLevel": "NOTICE",
    "logRequestBody": false
}

Настройка под Email рассылку

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

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

Автоматическую рассылку осуществляет Система по протоколу SMTP.

2) В конфигурационном файле сервиса Weblock.Controller /etc/waf-controller/waf-controller.yml в блоке #mail добавить следующие параметры:

mail:
  enabled: true
  host: <домен SMTP-сервера исходящей почты>
  port: <порт протокола SMTP, с протоколом шифрования SSL/TLS, для почтового сервера>
  username: <email созданного электронного почтового ящика>
  password: <пароль приложения (пароль для внешнего приложения) от этого ящика; при отсутствии – обычный пароль от этого ящика>
  protocol: smtp
  properties:
    mail.smtp.auth: true
    mail.smtp.starttls.enable: true
    mail.smtp.starttls.required: true
    mail.smtp.ssl.enable: true
    mail.smtp.ssl.trust: <домен SMTP-сервера исходящей почты для протокола шифрования SSL/TLS>

Значения параметров зависят от конкретного почтового сервера. Рекомендуем обратиться к документации почтового сервера для получения точной информации по настройке взаимодействия с внешними приложениями.


lk_simbol Пример. Фрагмент конфигурационного файла контроллера, когда для автоматической рассылки писем пользователям используется электронная почта на Mail.ru.

mail:
  enabled: true
  host: smtp.mail.ru
  port: 465
  username: name@mail.ru
  password: application_password
  protocol: smtp
  properties:
    mail.smtp.auth: true
    mail.smtp.starttls.enable: true
    mail.smtp.starttls.required: true
    mail.smtp.ssl.enable: true
    mail.smtp.ssl.trust: smtp.mail.ru

3) Перезагрузить сервис Weblock.Controller командой:

$ sudo systemctl restart waf-controller.service

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

4) Затем в Личном кабинете или по API активировать Email рассылку (подробнее Активация Email рассылки).

Тогда пользователи смогут также подключать/отключать свою Email рассылку, которая будет приходить на электронную почту, указанную в Профиле (подробнее Подключение/отключение опции «Email рассылка»).

Настройка подключения к Личному кабинету

Для обеспечения доступа к Личному кабинету (веб-интерфейсу Системы) по протоколу HTTPs необходимо:

  • изменить настройку переменных окружения,

  • получить SSL сертификат на домен Личного кабинета Системы.

В качестве веб-сервера для доступа в Личный кабинет используется веб-сервер Apache2.

Настройка переменных окружения

В файле настройки переменных окружения /var/www/html/waf-front/env/env.js изменить схему протокола на https.


lk_simbol Пример. Фрагмент настройки переменных окружения. В адресе заменено http на https.

window.env = {
  endpoints:{
    api:"https://domain:1080/controller",
    documentation:"https://docs.weblock.ru",
    geo:"https://domain:1080/geocoder",
    id:"https://domain:1080/oidc",
    report:"https://domain:1080/reporter",
    wafHealth:"https://domain:1080/health"
  }
}

где вместо domain - доменное имя Личного кабинета Системы.


SSL сертификат на домен Личного кабинета

Необходимо получить SSL сертификат на домен, через который будет доступен Личный кабинет Системы. Можно использовать SSL сертификаты, полученные ранее.

Подключение SSL сертификатов к Системе осуществляется в конфигурационном файле веб-сервера Apache2:

etc/apache2/sites-enabled/domain.conf

где вместо domain – доменное имя Личного кабинета, являющееся составной частью имени конфигурационного файла.

Для этого в данном конфигурационном файле в секцию конфигурации доступа к Личному кабинету (по умолчанию 1080) необходимо добавить следующие директивы:

SSLEngine on
SSLCertificateFile <путь до сертификата>
SSLCertificateKeyFile <путь до закрытого ключа>
SSLOptions +StdEnvVars

lk_simbol Пример. Фрагмент конфигурации для бесплатного сертификата безопасности от Let’s Encrypt:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/domain/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain/privkey.pem
SSLOptions +StdEnvVars

где

вместо domain – доменное имя узла, на котором установлена Система,

fullchain.pem – сертификат, содержащий корневой, промежуточный и конечный сертификаты,

privkey.pem – закрытый ключ.


Примечание

Официальная документация сертификационного центра Let’s Encrypt: https://letsencrypt.org/docs/.

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

$ sudo systemctl restart apache2

Изменение порта для Личного кабинета

Доменное имя и порт для Личного кабинета задаются перед установкой Системы в конфигурационном файле Системы.

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

  • /etc/apache2/ports.conf

  • /etc/apache2/sites-enabled/<имя Личного кабинета>.conf

  • /var/www/html/waf-front/env/env.js

и перезагрузить веб-сервер Apache2 командой:

$ sudo systemctl restart apache2

затем изменить порт в файле /etc/iptables/rules.v4 в строке:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 1080 -j ACCEPT

и перезапустить службу Iptables командой:

$ sudo systemctl restart iptables
_images/Weblock_Logos_small.png