Реагирование на нештатные ситуации при работе с Немезида ВАФ | Немезида ВАФ

Реагирование на нештатные ситуации при работе с Немезида ВАФ | Немезида ВАФ

Защита сайта от хакерских атак
Реагирование на нештатные ситуации при работе с Немезида ВАФ

Несмотря на постоянную работу над оптимизацией всех компонентов Немезида ВАФ, есть вероятность возникновения внештатной ситуации. К подобным ситуациям можно отнести:

  • Аварийное прекращение работы фильтрующей ноды;
  • Замедление работы конечных веб-приложений из-за повышенного потребления аппаратных ресурсов сервера фильтрующей ноды;
  • Невозможность доступа клиентов к конечному веб-приложению из-за увеличения количества блокировок легитимных запросов.

Рассмотрим каждый из этих сценариев.

🔗 Аварийное прекращение работы фильтрующей ноды

Во время работы Nginx могут возникать ошибки, приводящие к экстренному прерыванию выполнения запросов, вследствие чего Немезида ВАФ не может корректно обработать запрос. Для отслеживания и исправления ошибок в коде применяется анализ записи образа памяти процесса (core dump).

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

  • Активируйте отслеживание аварийного завершения процессов Nginx при работе с Немезида ВАФ;

    Инструкция по активации
    1. Создайте директорию для хранения записей о core dump: 
    # mkdir /var/log/nginx/core_dumps
# chown root:root /var/log/nginx/core_dumps
# chmod 1777 /var/log/nginx/core_dumps
    2. Снимите ограничение на максимальный размер файла с образом памяти процесса: 
    # ulimit -c unlimited
    Если команда завершается с сообщением «Cannot modify limit: operation not permitted», выполните команду: 
    # sh -c "ulimit -c unlimited && exec su $LOGNAME"
    3. Активируйте запись сообщений в системе, добавив соответствующие строки в /etc/sysctl.conf: 
    kernel.core_pattern = /var/log/nginx/core_dumps/core.%e.%p
fs.suid_dumpable = 2
    И примените изменения: 
    # sysctl -p
    4. Активируйте запись сообщений в Nginx:
    4.1 В начало файла конфигурации Nginx /etc/nginx/nginx.conf добавьте: 
    worker_rlimit_core      2G;
working_directory       /var/log/nginx/core_dumps/;
    4.2 Сохраните изменения и перезапустите Nginx: 
    # systemctl restart nginx

    Дополнительные возможности

    Активируйте запись в файл запросов, находящихся в памяти рабочего процесса на момент возникновения ошибки, связанной с core dump, добавив параметр nwaf_coredump_request_path в файл конфигурации динамического модуля Nemesida WAF /etc/nginx/nwaf/conf/global/nwaf.conf: 
    nwaf_coredump_request_path /var/log/nginx/coredump_requests;
    При использовании параметра, на каждый рабочий процесс Nginx будет выделяться по 25 Мб памяти для промежуточного хранения запросов. После заполнения 75% выделенного объема памяти под каждый запрос выделяется по 64 Кб, обрезая тело запроса.
    Активация регистрации записей о core dump и запросов, находящихся в памяти рабочего процесса, существенно влияют на производительность Nginx и генерируют файлы большого объема, поэтому рекомендуется отключать функции после получения необходимой информации.

    Анализ полученных данных

    Для просмотра собранных записей о core dump необходимо воспользоваться отладчиком GDB, выполнив команду gdb path/to/nginx -c path/to/core_dumps: 
    # gdb /usr/sbin/nginx -c /var/log/nginx/core_dumps/core.XX.YY
...
[New LWP XXXX1]
[New LWP XXXX2]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `nginx: worker process                   '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005600c259077a in ngx_radix32tree_find ()
[Current thread is 1 (Thread 0x7f6ca08e9740 (LWP XXXXX))]
(gdb)
    Выполните команду bt (backtrace — вывод стека вызова функций до момента наступления ошибки): 
    (gdb) bt
#0  0x00005600c259077a in ngx_radix32tree_find ()
#1  0x00005600c25ffd84 in ?? ()
#2  0x00005600c25ce948 in ngx_http_get_indexed_variable ()
#3  0x00005600c25cf7e6 in ngx_http_script_copy_var_len_code ()
#4  0x00005600c25cfa9a in ngx_http_complex_value ()
#5  0x00005600c2603428 in ?? ()
#6  0x00005600c25ce948 in ngx_http_get_indexed_variable ()
#7  0x00005600c25cea47 in ngx_http_get_flushed_variable ()
#8  0x00005600c25d1783 in ngx_http_script_var_code ()
#9  0x00005600c2604956 in ?? ()
#10 0x00005600c25be8ec in ngx_http_core_rewrite_phase ()
#11 0x00005600c25ba0be in ngx_http_core_run_phases ()
#12 0x00005600c25ba163 in ngx_http_handler ()
#13 0x00005600c25c4d08 in ngx_http_process_request ()
#14 0x00005600c25c5284 in ?? ()
#15 0x00005600c25c55c4 in ?? ()
#16 0x00005600c25c576f in ?? ()
#17 0x00005600c25ac12d in ?? ()
#18 0x00005600c25a2996 in ngx_process_events_and_timers ()
#19 0x00005600c25aa5d9 in ?? ()
#20 0x00005600c25a8cd2 in ngx_spawn_process ()
#21 0x00005600c25a9874 in ?? ()
#22 0x00005600c25ab100 in ngx_master_process_cycle ()
#23 0x00005600c2583ae2 in main ()
(gdb)
  • Передайте полученную информацию в службу технической поддержки для ее анализа и устранения неисправности.

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

🔗 Замедление доступа конечных веб-приложений из-за повышенного потребления аппаратных ресурсов сервера фильтрующей ноды

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

  • Изучить рекомендуемые требования к аппаратным ресурсам сервера соответствующего компонента и, если возможно, добавить необходимое количество ресурсов в соответствии с требованиями;
  • Передать в службу технической поддержки лог веб-сервера Nginx для анализа и устранения неисправности (если разработчиками будет подтверждено наличие неисправности, приводящее к повышенному потреблению аппаратных ресурсов сервера) или получения рекомендаций для снижения потребления аппаратных ресурсов.

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

В некоторых случаях фильтрующая нода также может потреблять повышенное количество аппаратных ресурсов (в частности, ОЗУ сервера) из-за обработки большого количества запросов, которые передаются на дополнительный анализ модулем машинного обучения. Связано это с тем, что при сигнатурном анализе запроса дополнительно производится Base64-декодирование зон ARGS, BODY, URL, HEADERS, после которого обнаруживаются признаки атаки (сигнатуры), а запрос передается в модуль Nemesida AI MLA. В большинстве случаев для решения проблемы будет достаточно активировать в Личном кабинете параметр отключения декодирования соответствующей зоны.

🔗 Невозможность доступа клиентов к конечному веб-приложению из-за увеличения количества блокировок легитимных запросов

При анализе запросов фильтрующая нода выполняет несколько этапов проверок, в которые входит анализ запросов сигнатурным методом и анализ машинным обучением. При увеличении количества блокировок легитимных запросов необходимо выяснить причину подобного поведения со стороны Немезида ВАФ.

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

  • Перевести Немезида ВАФ на обработку запросов в режиме мониторинга (запрос не блокируется, но соответствующие события записываются в журналах Немезида ВАФ);
  • Предоставить в службу технической поддержки лог веб-сервера Nginx для анализа и устранения неисправности (если разработчиками будет подтверждено наличие неисправности, приводящее к ложным срабатываниям) или получения рекомендаций для снижения их количества.

🔗 Отключение Немезида ВАФ

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

При возникновении необходимости отключения Немезида ВАФ рекомендуется выполнить следующие действия:

  • Деактивировать параметры load_module /etc/nginx/modules/ngx_http_waf_module.so; и include /etc/nginx/nwaf/conf/global/*.conf;;
  • Настроить дополнительный сервер, который будет работать в режиме зеркалирования трафика, чтобы иметь актуальную информацию об атаках на защищаемое веб-приложение, но не влиять на их производительность;
  • Предоставить в службу технической поддержки лог веб-сервера Nginx для анализа и устранения неисправности (если разработчиками будет подтверждено ее наличие) или получения рекомендаций для дальнейших действий.