Web application firewall настройка

Обновлено: 08.07.2024

Являются ли системы класса WAF обязательным стандартом для обеспечения безопасности веб-ресурсов или же остаются важной, но дополнительной опцией? Как выбрать и внедрить Web Application Firewall и что ждёт рынок в будущем? Об этом рассуждают представители вендоров, сервис-провайдеров и крупных заказчиков в рамках онлайн-конференции AM Live.

Введение

Очередной выпуск онлайн-конференции AM Live был посвящён системам стоящим на страже веб-ресурсов — решениям класса Web Application Firewall. Для того чтобы разобраться, что такое WAF, какие функции этих систем наиболее востребованны и как избежать проблем при внедрении, мы пригласили в студию ведущих экспертов рынка информационной безопасности. Предлагаем вашему вниманию ключевые тезисы прямого эфира, длившегося более двух часов.

В дискуссии приняли участие:

  • Михаил Кондрашин, технический директор компании Trend Micro в СНГ, Грузии и Монголии.
  • Виктор Рыжков, менеджер по продуктовому маркетингу направления Application Security компании Positive Technologies.
  • Вячеслав Гордеев, системный инженер компании Fortinet.
  • Вячеслав Алешин, руководитель направления разработки облачных продуктов кибербезопасности компании BI.ZONE.
  • Александр Баринов, руководитель направления сервисов Solar MSS компании «Ростелеком-Солар».
  • Иван Новиков, CEO компании «Валарм».

Ведущий и модератор дискуссии — Андрей Дугин, начальник отдела обеспечения информационной безопасности компании МТС.

Для чего нужен Web Application Firewall

В первую очередь мы спросили у наших экспертов, кому и зачем нужен WAF. Модератор дискуссии предложил поговорить о том, чем этот класс средств защиты отличается от обычных файрволов, в том числе — нового поколения (Next Generation Firewall, NGFW). Не проще ли вместо использования WAF банально поддерживать безопасность сайта — устанавливать актуальные патчи, устраивать пентесты и т. д.?

Виктор Рыжков:

— Сейчас легче перечислить тех, кому WAF не нужен: Web Application Firewall не нужен только тогда, когда у компании просто нет веб-ресурсов или эти ресурсы не жалко потерять. WAF помогает защитить веб-ресурсы, если они являются основой бизнеса, если они используются как хранилище персональных данных или другой критической информации или если они связаны с инфраструктурой компании и могут послужить точкой входа для злоумышленников.

Вячеслав Алешин:

— WAF поможет защитить заказные решения, используемые компаниями. Такие системы нередко содержат уязвимый код и могут представлять угрозу безопасности компании.

Иван Новиков:

— WAF занимается защитой на седьмом уровне по модели OSI. Такой межсетевой экран анализирует запросы, которые не контролирует ни обычный файрвол, ни NGFW. Помимо сайта WAF защищает веб-серверы приложений, контролирует интеграции со сторонними сервисами, а также отрабатывает угрозы не связанные с уязвимостями — такие как DDoS-атаки.

Вячеслав Гордеев:

Михаил Кондрашин:

— Если говорить образно, WAF — это продукт, который позволяет эксплуатировать уязвимый веб-сайт так, чтобы его не взломали. Что касается размещения, то NGFW устанавливается на шлюзе, а WAF — там, где находится веб-сайт.

Александр Баринов:

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

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

Ещё одна тема, которую затронули гости студии, — варианты размещения Web Application Firewall. Имеет ли смысл использовать локальный (on-premise) вариант или лучше подписаться на облачный сервис? Как отметили эксперты AM Live, в данном случае это — вопрос доверия к облачному провайдеру, поставщику услуги. Сейчас рынок безопасности веб-приложений активно мигрирует в облако, а значит, всё больше и больше заказчиков считают риски таких сервисов приемлемыми для себя.

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

Рисунок 1. Используете ли вы WAF в своей организации?

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

Технические особенности WAF

Базовую структуру «типового» решения класса Web Application Firewall обрисовал Вячеслав Гордеев. Как сказал эксперт, у каждого WAF есть набор модулей защиты, по которым проходит весь трафик. Обычно всё начинается с базовых уровней — модулей защиты от DDoS-атак и блоков сигнатурного анализа. Уровнем выше стоит возможность разработки своих собственных политик безопасности, а также подсистема математического обучения. На одном из последних этапов обычно появляется блок интеграции со сторонними системами.

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

Обсуждая работу Web Application Firewall с контейнерами, спикеры заметили, что отличия могут быть только в способе развёртывания, а принципы работы остаются прежними. В среде контейнеризации WAF может быть развёрнут разными способами — например, выступать в роли IP-шлюза, фильтруя все запросы на вход в среду виртуализации. Кроме того, WAF может работать как контейнер и быть интегрирован с шиной передачи данных.

Отвечая на вопрос «Что, на ваш взгляд, наиболее важно при выборе WAF?», большинство зрителей прямого эфира AM Live отметили в качестве ключевого фактора технологии обнаружения атак. За этот вариант проголосовали 63 % респондентов. Интеграцию с другими средствами защиты считают наиболее важной функцией WAF 12 % опрошенных, а стоимость — 9 %. За варианты «Модель поставки» и «Сертификация» высказались 2 % и 3 % соответственно. Другие факторы считают наиболее важными 11 % участников опроса.

Рисунок 2. Что, на ваш взгляд, наиболее важно при выборе WAF?

В завершение второго блока прямого эфира эксперты обсудили возможность предоставления сервиса WAF по модели SaaS, а также способы оценки эффективности работы файрвола. Как отметили наши спикеры, SaaS — это предоставление полного доступа к приложению и его администрированию в облаке. Каких-то значительных преимуществ этот подход не несёт, но он является первым шагом к переносу инфраструктуры в облако. Если компания делегирует провайдеру и эксплуатацию системы, то речь идёт скорее о модели MSSP, которая может дать некоторую выгоду. Оценить эффективность WAF поможет пентест, который заказчик может провести во время пилотирования проекта. Помимо этого, вендоры и системные интеграторы могут предоставлять клиенту регулярные отчёты по работе файрвола, демонстрирующие результаты анализа трафика.

Как внедрять Web Application Firewall

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

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

  • Пилотирование.
  • Выбор поставщика.
  • Определение архитектуры решения.
  • Определение технологий резервирования.
  • Развёртывание программного или программно-аппаратного комплекса.
  • Обучение и мотивация персонала, убеждение в необходимости использования WAF.

Михаил Кондрашин отметил, что внедрение сервиса WAF в одно приложение занимает полторы минуты. Эксперт пояснил, что речь идёт только о мониторинге: настройка правил блокировок займёт дополнительное время. При этом другие спикеры онлайн-конференции указали, что подразумевается «чистое» время, которое не включает многие аспекты внедрения — согласования, обучение персонала и другие этапы. Иван Новиков подчеркнул, что время внедрения зависит от способа развёртывания, а также от конкретного приложения и от трафика, который необходимо контролировать.

Гости студии рассказали также о том, как правильно построенный процесс внедрения поможет уменьшить процент ложных срабатываний WAF. Виктор Рыжков отметил, что решить эту задачу поможет тестирование на подготовительном этапе (pre-production), а также после ввода системы в эксплуатацию. Эксперт отметил важность возможности «обучения» файрвола, когда на этапе теста часть вердиктов корректируется специалистом. Александр Баринов порекомендовал изучить статистику работы WAF за первый месяц работы, чтобы понять, не блокирует ли система легитимный трафик. Вячеслав Алешин подчеркнул, что не бывает WAF полностью исключающих ложные срабатывания.

Спикеры перечислили также основные направления интеграции Web Application Firewall с другими средствами безопасности. По мнению экспертов, это:

  • SIEM-системы (WAF выступает поставщиком данных).
  • Различные виды песочниц.
  • Антивирусные ядра.
  • DLP-системы.
  • Сканеры уязвимостей.
  • Средства безопасности внутри платформы Kubernetes.
  • NGFW.

Зрители AM Live высказали свои мнения о том, что больше всего тормозит внедрение WAF. Почти треть опрошенных (32 %) отметила, что главным препятствием для успешного внедрения являются ложные срабатывания. Ещё 21 % указал на сложность администрирования, а 18 % — на высокую цену. Снижение производительности веб-сайта отметили 5 % респондентов, а 4 % пожаловались на недостаточную масштабируемость. Не видят препятствий для внедрения и используют WAF 20 % опрошенных.

Рисунок 3. Что, на ваш взгляд, тормозит внедрение WAF больше всего?

Тренды и прогнозы развития рынка WAF

В заключение беседы эксперты в студии поделились своим видением перспектив развития рынка Web Application Firewall. Спикеры отметили рост популярности различных открытых WebAPI и предсказали смещение фокуса защиты в их сторону; у Gartner даже есть определения для таких продуктов — Web Application & API Protection (WAAP). Из-за пандемии зависимость от онлайна выросла драматическим образом, поэтому важность WAF возрастёт, его наличие может стать обязательным условием безопасности веб-ресурса. Участники онлайн-конференции отметили, что WAF станет «ближе» к приложениям и будет встроен в процесс их разработки.

Говоря о технологических тенденциях развития систем класса WAF, эксперты предсказали внедрение в WAF систем искусственного интеллекта и многоуровневого машинного обучения. Будут усилены возможности обнаружения неизвестных угроз, а также активизируется использование предварительно сгенерированных моделей, созданных внутри компании. Помимо этого, спикеры AM Live отметили вероятное развитие механизмов фильтрации, основанных на поведенческих факторах.

С точки зрения развёртывания продолжатся миграция WAF в облака и интеграция систем этого класса с другими облачными сервисами. Эксперты отметили тенденцию к открытости систем безопасности, которая затронет и WAF; это — ответ на запросы рынка, выгодный как покупателям, так и вендорам.

Финальный опрос зрителей онлайн-конференции был посвящён мнению нашей аудитории относительно WAF по итогам эфира. Почти треть опрошенных (29 %) после просмотра очередного выпуска AM Live убедились в правильности своего выбора WAF. Ещё 16 % респондентов заинтересовались и готовы тестировать эти средства безопасности. Считают WAF избыточным для себя 13 % участников опроса, а 3 % зрителей в результате решили сменить поставщика WAF.

Не поняли, о чём шла речь во время прямого эфира, 32 % наблюдавших за ним, а 7 % опрошенных считают, что участники не смогли доказать необходимость использования WAF.

Рисунок 4. Каково ваше мнение относительно WAF по итогам эфира?

Выводы

Дискуссия показала, что Web Application Firewall является ключевым элементом безопасности современных веб-ресурсов. Рост числа критически важных задач, выполняемых посредством веб-интерфейсов и открытых API, является драйвером рынка систем безопасности этого класса. Сегодня заказчик может выбирать: самостоятельно развёртывать WAF на собственной инфраструктуре, встраивать в неё готовые программно-аппаратные комплексы или же использовать облачные сервисы.

Важным трендом является интеграция WAF — как с другими системами информационной безопасности, так и с процессом разработки сайтов. Необходимость встраивания такого файрвола в процесс DevSecOps не раз отмечали приглашённые нами эксперты.


Занимаясь разработкой или обслуживанием веб-приложений, в какой-то момент времени приходится сталкиваться с необходимостью использовать WAF (Web Application Firewall). Если опыта работы с такого класса решением у вас нет или устали от постоянных ложных срабатываний, я расскажу, как упростить задачу, а также поделюсь советами и фишками. В качестве инструмента будем использовать Nemesida WAF Free — бесплатную версию Nemesida WAF.

Визуализация, или начнем с конца

Наблюдать за работой Nemesida WAF Free можно через браузер, поэтому после недолгой настройки системы мы получим доступ к веб-интерфейсу, в котором будет доступна информация по заблокированным атакам, причинах блокировки, информации об IP-адресах и т.д. Кроме этого появятся разделы со сводной статистикой в виде графиков, диаграмм и данными по трафику от модуля VTS (если он используется).



Приступаем к установке.

Установка Nemesida WAF Free

В предыдущем абзаце я специально разделил функционал блокирования атак на выявление и блокирование, поскольку есть 2 (даже три) режима работы продукта: IDS, IPS и PseudoIDS (режим LM).

Режим IDS

IDS режим позволяет использовать WAF на копии трафика, выявляя, но не блокируя атаки. Такой режим работы полезен, например, для первичного запуска или для пассивного мониторинга, чтобы исключить любое блокирование запросов или увеличение, пусть и незначительное, времени отклика. Для примера настройки будем использовать Nginx для передающего сервера (хотя можно использовать любой другой, например, Apache2 или IIS).

Настройка передающего сервера:

(вместо 192.168.0.1 необходимо указать адрес сервера с установленным Nemesida WAF)

После внесения изменений и перезапуска веб-сервера, поступающие на этот сервер запросы будут транслироваться на сервер 192.168.0.1 с установленным Nemesida WAF (его настройка проста и будет описана ниже). Такая схема работы позволяет мониторить атаки без их блокирования, но в то же время, без воздействия на основной сервер.

Режим IPS и PseudoIDS

Остальные 2 режима работы предполагают использование WAF «вразрез», при этом в режиме IPS выявленные инциденты безопасности блокируются, в режиме PseudoIDS — фиксируются, но не блокируются. Последний режим удобен тем, что переключение между этими двумя режими происходит с помощью простых опций: возможность перевода в режим PseudoIDS как по имени сервера (опция nwaf_host_lm ), так и по IP-адресу клиента (опция nwaf_ip_lm ).

Вообще, в Nemesida WAF Free предусмотрено множество параметров для «тонкой» настройки системы: гибкий функционал создания собственных правил блокировок и исключений, возможность добавлять IP клиента в «список исключений», опция настройка бана для всех и для каждого отдельного виртуального хоста и т.д. Всем этим хозяйством можно управлять через конфигурационный файл в бесплатной версии, а в полноценной — еще и через вызовы API.

Вернемся к процедуре установки. Nemesida WAF представлен в виде нескольких компонентов:

  • Динамический модуль для Nginx
  • Nemesida WAF API (принимает события от Nemesida WAF и помещает их в Postgres для последующего вывода в ЛК или интеграции с SIEM-системами)
  • Личный кабинет (веб-интерфейс для мониторинга за инцидентами)
  • Модуль машинного обучения Nemesida AI
  • Сканер уязвимостей Nemesida WAF Scanner
  • Nemesida WAF Signtest — веб-интерфейс для управления модулем машинного обучения

Динамический модуль Nemesida WAF

Для тех, кто устанавливает дистрибутив не в первый раз, процесс установки и запуска динамического модуля занимает примерно 5-10 минут. Динамический модуль Nemesida WAF можно подключить к уже установленному Nginx (или скомпилированному из исходников с собственными модулями).

Репозитории Nemesida WAF доступны для следующих ОС: Debian 9/10, Ubuntu 16.04/18.04/20.04, Centos 7/8. На Youtube-канале опубликованы видео-инструкции по установке и первичной настройке компонентов. Рекомендуем ознакомиться с одной из них, но установку и настройку советуем производить по документации на основном сайте, поскольку некоторые параметры могут устаревать, другие — добавляться.

Установка динамического модуля Nemesida WAF (видео)

Nemesida WAF API и Личный кабинет

После того, как динамический модуль будет установлен и запущен, пора переходить к установке оставшихся двух компонентов: Nemesida WAF API и Личный кабинет.

Nemesida WAF API представлен в виде API, написанного с использованием Flask, и предназначен для приема событий от Nemesida WAF, Nemesida WAF Scanner и Nemesida AI с последующим помещением этих событий в БД. В качестве СУБД используется PostgreSQL. В бесплатной версии Nemesida WAF в БД будут передаваться только информация о заблокированных запросах.

После того, как Nemesida WAF API будет настроен и подключен к PostgreSQL, пора приступать к запуску Личного кабинета. Согласно документации производим установку, настройку, выполняем миграцию, указываем пользователя и пароль для входа.

По опыту установка двух последних компонентов вызывает больше затруднений (обычно пропускаются какие-то шаги, например, забывают сделать миграцию или разрешить подключение к Postgres), поэтому для быстрого старта мы подготовили Virtual Appliance (виртуальный диск с Debian 10 и компонентами Nemesida WAF, 3GB до распаковки), а также сделали 2 Docker-образа: для динамического модуля и для Nemesida WAF API/Личного кабинета.

Ну что, самая скучная часть позади, теперь можем проверить WAF в действии.

Первый hack

Отправляем запрос (я это сделал через консоль, но лучше делать через браузер для наглядности):


или, если хочется что-то более приближенное к реальности:


В ответ получаем код ответа 403:


А в ЛК через несколько секунд должна появиться атака:


Если запрос не заблокировался — WAF некорректно подключен или настроен (возможно, адрес или хост добавлен в WL/LM), если блокирование запроса произошло, но в ЛК информации нет — проверьте корректность настройки взаимодействия с Nemesida WAF API и ЛК. В любом случае, всегда можно задать вопрос на форуме.

Кастомная 403 страница

По умолчанию 403 страница (страница с 403 кодом ответа) невзрачна и скупа на информацию. Nemesida WAF в связке с Nginx позволяет ее сделать красивой и более информативной.

Чтобы ваш сервер отдавал такую страницу, необходимо:

1. Создать файл конфигурации для кастомных страниц (например, в /etc/nginx/snippets/custom_pages.conf );

Описание:

error_page 403 405 = 222 /403.html; — задаем кастомный 222 код ответа для кодов ответа 403 и 405 и возвращаем локацию /403.html ;


2. Подключить созданный файл:

Подключить созданный файл к конфигурации Nginx

3. Создать кастомную страницу (например, /var/www/custom_pages/403.html ) следующего содержания (для примера):

После перезапуска Nginx (с установленным Nemesida WAF) все страницы, имеющие код ответа 403 и 405, будут выглядеть следующим образом:


При этом кастомная страница будет обновляться каждые 7 секунд, и если IP клиента не будет забанен, то возвратится корневая страница сайта.

Автоматический бан

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

  • Количество атак с IP, которое приводит к блокированию;
  • Период блокирования;
  • Виртуальный хост, на который направлены атаки (опционально).

Списки исключений (While lists)

Работа WAF построена по принципу анализа поступающих на сервер запросов и реакции в случаях, когда в них содержатся признаки атаки или аномалий. Применение алгоритмов машинного обучения вкупе с улучшенной технологией нормализации в полноценной версии Nemesida WAF позволяет выявлять такие атаки точно и с ультра-минимальным количеством ложных срабатываний (порядка 0.01%), но в бесплатной версии для снижения количества ложных срабатываний мы упираемся в ограничения, заложенные в архитектуру сигнатурного анализа. Таким образом, бесплатная версия имеет большее количество ложных срабатываний, и для решения этой проблемы приходится использовать списки исключений (или «white lists»). В Nemesida WAF также доступно создание правил исключений.

Чаще всего ложные срабатывания появляются, когда администратор/модератор веб-ресурса производит обновление или изменение через веб-интерфейс, передавая в теле запроса нетипичные для пользователя конструкции:
.
$html = curl_exec($ch);
curl_close($ch);
return json_decode($html,true);
.

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

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

Кстати, Nemesida WAF позволяет добавлять не только IP-адреса, но и подсети, если в этом появляется необходимость.

Заключение

Независимо от того, насколько качественно на ваш взгляд написан код, применяются в нем функции фильтрации ввода и специальные фреймворки вроде HTML Purifier, призванные удалять если не весь вредоносный код, то большую его часть, необходимо использовать WAF для повышения уровня защищенности.

Если использовать WAF предполагается впервые, или вы устали от бесконечных добавлений правил исключения, рекомендуем попробовать бесплатную Nemesida WAF Free. Для профессионального использования (блокирование сложных атак, атак методом перебора, СМС флуда; поиск уязвимостей; наличие системы виртуального патчинга и т.д.) требуется полноценная версия Nemesida WAF с модулем машинного обучения и сканером уязвимостей. Тем не менее, для большинства нецелевых атак и массовых сканирований Nemesida WAF Free будет хорошим и удобным инструментом.

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

Некоторые тестеры-разоблачители WAF , считают что достаточно поставить коробочку / подключить сервис и всё - можно проводить свои изощренные эксперименты и выдавать разоблачительные статьи.

Посмотрим какие настройки должны выполняться на WAF в реальных проектах (не считая инициализации, базовых и сетевых настроек, подключения онлайн-сервисов) и разберем подробно для чего эти настройки нужны:

· Так как мы глубокий анализ трафика web трафика задача ресурсоемкая, а мы хотим эффективно использовать ресурсы нашего WAF , то нам нужно точное определение области защиты (весь трафик не касающийся области защиты будем пропускать без проверок):

o задаем перечень ip -адресов серверов web приложений ( Server Groups )

o для каждого сервера указываем сервисы и порты, связанные с web приложениями ( web services )

o определяем все web приложения, расположенные на наших web сервисах (а их может быть больше 1, например: www . microtest . ru , www . security - microtest . ru ) и задаем соответствие приложений и URL . В дальнейшем это нам поможет включать разные политики на разные приложения, а при мониторинге WAF и реагировании на инциденты поможет быстро определить приложения, на которые производится атака. Это важно - за разные приложения могут отвечать разные группы разработчиков, специалистов поддержки

Ваш запрос к web приложению не может быть выполнен в связи с нарушением политик безопасности. Свяжитесь с службой поддержки для получения дополнительной информации.< br >

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


o разместив WAF до балансировщиков, мы видим в поле ip -адреса назначения запросов адреса балансировщиков, а не адреса защищаемых web серверов.

o разместив WAF после балансировщиков мы видим в поле ip -адреса источика запросов – адреса балансировщиков, а не пользователей или атакующих.

o можно подключить WA F до и после балансировщиков, но в таком случае мы будем обрабатывать 2 раза один и тот же трафик и получать в 2 раза больше событий и нарушений

Одно из красивых решений: разместить WAF после балансировщиков, а на балансировщиках настроить опцию регистрации форвардинга, в которой в запрос будет добавляться указание ip -адреса источника (в опцию X - Forwarded - For ). В таком случае, на WAF для определенных web сервисов нам надо будет настроить распознавание ip -адреса источника из поля X - Forwarded - For .


Так-же мы не хотим чтобы ip -адреса балансировщиков попадали в долговременный черный список (в отличае от ip -адресов атакующих) нужно добавить в исключения в настройках реакций WAF


· Полезным было бы задать в WAF структуру web приложений с указанием всех каталогов, страниц и используемых параметров на каждой странице. Это пригодится нам для тонкой настройки политик в дальнейшем (например, мы захотим явно указать все страницы, на которых разрешено принимать данные от пользователя или например, захотим отметить все страницы, на которых могут отображаться персональные данные).

Вручную задавать такие данные – задача трудоемкая, а ведь надо ещё и актуализировать при изменениях web приложений. Поэтому, хорошо если ваш WAF поддерживает динамическое профилирование web -приложений.

В таком случае нам нужно его включить и настроить правила динамического обновления профилей web приложений

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

Жду отзывов – интересны ли вам подобные статьи и стоит ли делать продолжение?

Развертывание WAF‑ноды на Google Cloud Platform (GCP) включает в себя следующие шаги:

Запуск инстанса с WAF‑нодой Валарм.

Настройка инстанса с WAF‑нодой Валарм.

Подключение по SSH к инстансу с WAF‑нодой.

Подключение WAF‑ноды к облаку Валарм.

Настройка WAF‑ноды для использования прокси‑сервера.

Настройка правил проксирования и фильтрации.

Настройка выделения оперативной памяти для WAF‑ноды.

2. Запуск инстанса с WAF‑нодой Валарм¶

Если Валарм WAF уже установлен

Если вы устанавливаете Валарм WAF вместо существующего Валарм WAF или дублируете установку, используйте версию существующего Валарм WAF или обновите версии всех установок до последней.

Чтобы получить текущую версию, подключитесь к существующему инстансу и выполните команду:

  • Если установлена версия 3.4.x , используйте текущую инструкцию.
  • Если установлена версия 3.2.x , используйте инструкцию для 3.2 или обновите все инстансы Валарм WAF до последней версии.
  • Если установлена версия 3.0.x или ниже, обновите все инстансы Валарм WAF до последней версии. Поддержка установленных версий скоро будет прекращена или уже прекращена.

Более подробная информация о поддержке версий доступна в политике версионирования WAF‑ноды.

Запуск через интерфейс Google Cloud Platform¶

Чтобы запустить инстанс с WAF‑нодой через интерфейс Google Cloud Platform, откройте образ WAF‑ноды и нажмите LAUNCH.

Инстанс запустится с предустановленной WAF‑нодой. Более подробная информация о запуске инстансов на Google Cloud Platform приведена в официальной документации Google Cloud Platform.

Запуск через Terraform или другой инструмент¶

При запуске инстанса с WAF‑нодой с помощью Terraform или другого инструмента вам может потребоваться указать название образа.

Название образа имеет формат:

Чтобы запустить инстанс с WAF‑нодой версии 3.4, используйте название образа:

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

Выполнить команду gcloud compute images list со следующими параметрами:

Скопировать версию из названия последнего доступного образа и вставить скопированное значение в приведенный формат названия образа. Например, для образа WAF‑ноды версии 3.4:

3. Настройка инстанса с WAF‑нодой Валарм¶

Для того, чтобы настроить запущенный инстанс с WAF‑нодой Валарм, выполните следующие действия:

Перейдите на страницу VM instances в разделе Compute Engine навигационного меню.

Нажмите на запущенный вами инстанс с WAF‑нодой и нажмите на кнопку Edit.

Разрешите необходимые типы входящего трафика к WAF‑ноде, установив требуемые галочки в пункте Firewalls.

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

Поставьте галочку «Block project-wide» в пункте SSH Keys.

Нажмите на кнопку Show and edit в пункте SSH Keys, чтобы развернуть поле для ввода SSH-ключа.

Сгенерируйте пару из открытого и закрытого SSH-ключей. Например, вы можете использовать утилиты ssh-keygen или PuTTYgen ;

Скопируйте открытый ключ в формате OpenSSH из интерфейса используемой утилиты для генерации SSH-ключей (в этом примере с генерацией ключей в PuTTYgen необходимо скопировать открытый ключ из поля Public key for pasting into OpenSSH authorized_keys file) и вставьте его в поле, содержащее подсказку «Enter entire key data».

Сохраните закрытый ключ. В будущем он будет необходим для подключения к настроенному инстансу.

Нажмите на кнопку Save внизу страницы, чтобы сохранить внесенные изменения.

4. Подключение по SSH к инстансу с WAF‑нодой¶

Информация о способах подключения к инстансам доступна по ссылке Google Cloud Platform: Connecting to Instances.

Подключение к инстансу с использованием собственного закрытого ключа

Если в процессе создания инстанса вы настроили собственную пару SSH-ключей для использования вместо пары ключей проекта при подключении к инстансу по протоколу SSH, то убедитесь, что вы имеете доступ к закрытому ключу из этой пары.

5. Подключение WAF‑ноды к облаку Валарм¶

WAF‑нода в процессе работы взаимодействует с облаком Валарм.

Существует два способа подключения WAF‑ноды к облаку:

Требуемые права доступа

Убедитесь, что роль вашего пользователя в Консоли управления Валарм — Администратор или Деплой и для пользователя отключена двухфакторная аутентификация.

Для этого перейдите к списку пользователей в RU‑облаке или EU‑облаке и проверьте столбцы Роль и Auth:

Подключение с использованием токена WAF‑ноды¶

Для того, чтобы подключить WAF‑ноду к облаку с использованием токена, выполните следующие действия:

На вкладке Ноды веб‑интерфейса Валарм создайте новую WAF‑ноду:

В появившейся форме выберите Облачная нода и введите имя WAF‑ноды.

Вы сможете изменить заданное имя позже.

Нажмите на кнопку Создать.

В появившемся окне нажмите на кнопку Скопировать справа от поля с токеном, чтобы добавить токен созданной WAF‑ноды в ваш буфер обмена.

На виртуальной машине с WAF‑нодой запустите скрипт addcloudnode :

Вставьте токен WAF‑ноды из буфера обмена.

Теперь WAF‑нода будет синхронизироваться с Облаком каждые 2‑4 минуты в соответствии с конфигурацией синхронизации по умолчанию.

Конфигурация синхронизации WAF‑ноды с Облаком

После запуска скрипта addcloudnode будет создан файл /etc/wallarm/syncnode , содержащий переменные окружения и их значения. Вы можете конфигурировать синхронизацию WAF‑ноды с Облаком, редактируя этот файл.

Подключение с использованием логина и пароля вашей учетной записи в облаке¶

Для того, чтобы подключить WAF‑ноду к облаку с использованием логина и пароля вашей учетной записи в облаке, выполните следующие действия:

На виртуальной машине с WAF‑нодой запустите скрипт addnode :

Введите логин и пароль от вашего аккаунта Валарм.

Виртуальная машина должна с WAF‑нодой должна иметь доступ к:

В случае проблем убедитесь, что доступ не ограничен файерволом.

Теперь WAF‑нода будет синхронизироваться с Облаком каждые 2‑4 минуты в соответствии с конфигурацией синхронизации по умолчанию.

Конфигурация синхронизации WAF‑ноды с Облаком

После запуска скрипта addnode будет создан файл /etc/wallarm/node.yaml , содержащий настройки синхронизации WAF‑ноды с Облаком и другие настройки для корректной работы WAF‑ноды. Вы можете изменять настройку синхронизации WAF‑ноды с Облаком, редактируя этот файл и используя системные переменные окружения.

6. Настройка WAF‑ноды для использования прокси‑сервера¶

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

Если Вы не используете прокси‑сервер, пропустите этот этап настройки.

Чтобы настроить WAF‑ноду Валарм для использования вашего прокси‑сервера, необходимо присвоить новые значения переменным окружения, которые определяют используемый прокси‑сервер.

Добавьте в файл /etc/environment новые значения переменных окружения:

no_proxy — ресурсы, для запросов к которым необходимо отключить проксирование.

<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 используются для работы WAF‑ноды Валарм.

Пример корректного содержимого файла /etc/environment ниже демонстрирует следующую конфигурацию:

для запросов к 127.0.0.1 , 127.0.0.8 , 127.0.0.9 и localhost проксирование отключено.

7. Настройка правил проксирования и фильтрации¶

Для настройки правил проксирования и фильтрации необходимо отредактировать файлы конфигурации NGINX и WAF‑ноды Валарм:

/etc/nginx/nginx.conf с настройками NGINX

/etc/nginx/conf.d/wallarm.conf с глобальными настройками WAF‑ноды Валарм

/etc/nginx/conf.d/wallarm-status.conf с настройками сервиса мониторинга WAF‑ноды Валарм

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

Подробную информацию о работе с конфигурационными файлами NGINX вы можете найти в официальной документации NGINX.

Логика работы WAF‑ноды Валарм настраивается при помощи директив Валарм. Список доступных директив Валарм доступен на странице «Тонкая настройка».

Пример файла конфигурации¶

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

все запросы нужно передавать на сервер 10.80.0.5 ;

все входящие запросы меньше 1 МБ (значение по умолчанию);

нет запросов, которые обрабатываются дольше 60 секунд (значение по умолчанию);

система должна работать в режиме мониторинга;

Создание файла конфигурации

При создании собственного файла конфигурации, убедитесь, что NGINX будет слушать входящие соединения на свободном порту.

Файл конфигурации в этом случае будет выглядеть следующим образом:

8. Настройка выделения оперативной памяти для WAF‑ноды¶

WAF‑нода использует находящееся в памяти хранилище Tarantool.

По умолчанию развернутый образ WAF‑ноды Валарм выделяет под Tarantool 40% от общей памяти инстанса.

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

Откройте для редактирования конфигурационный файл Tarantool:

Укажите размер выделенной памяти в директиве SLAB_ALLOC_ARENA в ГБ. Значение может быть целым или дробным (разделитель целой и дробной части — точка).

В боевой среде мы рекомендуем выделять для модуля постаналитики 75% от общей памяти виртуальной машины. Для тестирования ноды вы можете выделить меньшее количество памяти (например, 25% от общего объема).

Чтобы применить сделанные изменения, перезапустите Tarantool:

9. Настройка логирования¶

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

10. Перезапуск NGINX¶

Перезапустите NGINX, используя следующую команду:

Установка завершена¶

На этом установка завершена.

Проверьте, что WAF‑нода работает и пропускает через себя трафик. Подробнее в Проверка работоспособности WAF‑ноды.

Настройки по умолчанию

Только что установленная WAF‑нода будет находиться в режиме блокировки (см. описание директивы wallarm_mode ) в соответствии с настройками по умолчанию.

Это может привести к неработоспособности сканера Валарм. Если вы используете сканер, выполните дополнительные действия, чтобы он работал.

Дополнительные настройки¶

После установки WAF‑нода может потребовать дополнительной настройки.

Далее приводится несколько типовых настроек, которые вы можете выполнить, если это требуется.

Для получения информации о других доступных настройках, обратитесь к разделу «Настройка» руководства администратора.

Настройка отображения реального IP‑адреса клиента¶

Если WAF‑нода развернута за прокси‑сервером или балансировщиком нагрузки, то при такой схеме развертывания без дополнительной настройки адрес источника на WAF‑ноде может совпадать с одним из IP‑адресов прокси‑сервера или балансировщика нагрузки, а не с IP‑адресом клиента.

В этом случае, если вы хотите, чтобы на WAF‑ноду передавался IP‑адрес клиента в качестве адреса источника, то требуется дополнительная настройка прокси‑сервера или балансировщика.

Ограничение времени обработки единичного запроса¶

Используйте директиву Валарм wallarm_process_time_limit , чтобы задать ограничение времени обработки единичного запроса WAF‑нодой.

Если запрос обрабатывается за большее время, чем указано в директиве, то в лог‑файл заносится информация об ошибке, а запрос помечается как атака overlimit_res .

Ограничение времени ожидания ответа сервера¶

Используйте директиву NGINX proxy_read_timeout , чтобы задать таймаут чтения ответа проксированного сервера.

Если за это время сервер ничего не передаст, то соединение будет закрыто.

Ограничение максимального размера запроса¶

Используйте директиву NGINX client_max_body_size , чтобы задать ограничение на максимальный размер тела запроса клиента.

В случае превышения этого ограничения NGINX вернет клиенту ответ с кодом 413 ( Payload Too Large , также известный как Request Entity Too Large ).

Читайте также: