Проверка работоспособности фильтрующего узла

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

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

  1. Выполнение команды wallarm-status.
  2. Проведение тестовой атаки.

1. Выполните wallarm-status

Вы можете получить статистику работы фильтрующего узла, обратившись к адресу /wallarm-status.

Включение/выключение команды осуществляется в файле конфигурации nginx.conf.

Выполните в терминале команду:

$ curl http://127.0.0.8/wallarm-status`

Вид полученного ответа зависит от версии установленного фильтрующего узла:

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

Выполнение команды wallarm-status

Команда wallarm-status по умолчанию доступна только на том сервере, где установлен фильтрующий узел Валарм. Чтобы узнать, как разрешить выполнение этой команды с других серверов, обратитесь к описанию директивы wallarm_status в разделе Тонкая настройка конфигурации Валарм.

Версия 2.10 и ниже

{ "requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,
"requests_lost":0,"segfaults":0,"memfaults":0,"time_detect":0,"db_id":42,
"lom_id":141,"proton_instances": { "total":1,"success":1,"fallback":0,"failed":0 } }

Где:

  • requests: количество запросов, которые были обработаны фильтрующим узлом;
  • attacks: количество зафиксированных атак;
  • blocked: количество заблокированных запросов;
  • abnormal: количество запросов, которые расценены как нетипичные для приложения;
  • requests_lost: количество запросов, которые не были проанализированы в постаналитике или переданы в API. Для этих запросов учитываются параметры блокировок, но они не видны в интерфейсе и не учитываются в статистических и поведенческих проверках. Включает в себя tnt_errors и api_errors;
  • tnt_errors: количество запросов, анализ которых на постаналитике завершился ошибкой. Для этих запросов учитываются параметры блокировок, но они не видны в интерфейсе и не учитываются в статистических и поведенческих проверках;
  • api_errors: количество запросов, которые не были переданы в API для дальнейшего анализа. Учитывается только при работе в режиме "без локальной постаналитики".

    Для этих запросов учитываются параметры блокировок, но они не видны в интерфейсе;

  • segfaults: количество проблем, приведших к аварийному завершению воркер-процесса;
  • memfaults: количество ситуаций, когда был достигнут предел размера виртуальной памяти;
  • time_detect: суммарное время, потраченное на анализ запросов;
  • db_id: версия используемой proton.db;
  • lom_id: версия используемого ЛОМ;
  • proton_instances: информация о парах proton.db + ЛОМ:
    • total: количество пар proton.db + ЛОМ;
    • success: количество успешно загруженных пар proton.db + ЛОМ;
    • fallback: количество пар proton.db + ЛОМ, загруженных из последних сохраненных файлов;
    • failed: количество пар proton.db + ЛОМ, которые не были инициализированы и работают в режиме «не анализировать».

Версия 2.12

{ "requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,
"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,
"lom_id":16767,"proton_instances": { "total":1,"success":1,"fallback":0,"failed":0 },
"stalled_workers_count":0,"stalled_workers":[] }

Где:

  • requests: количество запросов, которые были обработаны фильтрующим узлом;
  • attacks: количество зафиксированных атак;
  • blocked: количество заблокированных запросов;
  • abnormal: количество запросов, которые расценены как нетипичные для приложения;
  • requests_lost: количество запросов, которые не были проанализированы в постаналитике или переданы в API. Для этих запросов учитываются параметры блокировок, но они не видны в интерфейсе и не учитываются в статистических и поведенческих проверках. Включает в себя tnt_errors и api_errors;
  • tnt_errors: количество запросов, анализ которых на постаналитике завершился ошибкой. Для этих запросов учитываются параметры блокировок, но они не видны в интерфейсе и не учитываются в статистических и поведенческих проверках;
  • api_errors: количество запросов, которые не были переданы в API для дальнейшего анализа. Учитывается только при работе в режиме "без локальной постаналитики". Для этих запросов учитываются параметры блокировок, но они не видны в интерфейсе;
  • segfaults: количество проблем, приведших к аварийному завершению воркер-процесса;
  • memfaults: количество ситуаций, когда был достигнут предел размера виртуальной памяти;
  • time_detect: суммарное время, потраченное на анализ запросов;
  • db_id: версия используемой proton.db;
  • lom_id: версия используемого ЛОМ;
  • proton_instances: информация о парах proton.db + ЛОМ:
    • total: количество пар proton.db + ЛОМ;
    • success: количество успешно загруженных пар proton.db + ЛОМ;
    • fallback: количество пар proton.db + ЛОМ, загруженных из последних сохраненных файлов;
    • failed: количество пар proton.db + ЛОМ, которые не были инициализированы и работают в режиме «не анализировать»;
  • stalled_workers_count: количество воркеров, которые обрабатывают запрос дольше, чем установленное временное ограничение (значение директивы wallarm_process_time_limit);
  • stalled_workers: список идентификаторов воркеров, которые обрабатывают запрос дольше, чем установленное временное ограничение (значение директивы wallarm_process_time_limit), и количество затраченного ими времени на обработку запроса.

2. Проведите тестовую атаку

Проверить обнаружение атак можно, отправив к защищаемому ресурсу запрос, который Валарм заведомо воспринимает как нелегитимный. Примером такого запроса может служить:

http://<resource_URL>/?id='or+1=1--a-<script>prompt(1)</script>

Валарм должен выдать на этот запрос два срабатывания:

Теперь при повторном выполнении wallarm-status счетчик количества атак увеличится.

results matching ""

    No results matching ""