Что такое WAF и как с ним работать. Показываем на примере уязвимого веб-приложения

31r9lpzj3m1lrtuwjcmsr2gjgj4.png


Информационная безопасность веб-приложений за последние несколько лет стала, наверное, одним из ключевых вопросов в IT. Для компаний стабильность работы систем — это репутация и отсутствие лишних издержек. Ежегодная статистика больших ИБ-компаний говорит о росте количества и качества атак.

Ранее в статье я рассказывал о защите веб-приложений с помощью систем класса IDPS. Сегодня — хочу поделиться информацией о том, как работать с WAF. В статье постараюсь оттолкнуться от теории и перейти к вопросу настройки. Будем запускать два сервера, где один будет атаковать, а второй — защищаться с помощью WAF. Надеюсь, текст станет доступным входом для инженеров, которые ранее не задумывались о работе с WAF из-за непонятности этого типа систем. Интересно? Тогда добро пожаловать под кат!

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


Используйте навигацию, если не хотите читать текст полностью:

→ Откуда ноги растут: уязвимости веб-сервисов
→ Знакомство с open-appsec
→ Тестирование open-appsec
→ Выводы

Откуда ноги растут: уязвимости веб-сервисов


Для начала определимся, с чем придется работать. Как известно, к инцидентам ИБ приводит такая цепочка: Система → Нарушитель → Угроза → Уязвимость → Эксплуатация уязвимости.

  • Система — наше потенциальное веб-приложение.
  • Нарушитель — злоумышленник.
  • Угроза — потенциальная возможность нанести ущерб нашей системе.
  • Уязвимость — недостаток системы, с помощью которого можно реализовать угрозу.
  • Эксплуатация уязвимости — применение эксплоита для реализации угрозы.


Появление уязвимости веб-приложения — это, как правило, не внезапная проблема, а «изюминка», которая ожидает, что ее обнаружат. Есть несколько причин, из-за которых она появляется.

Причина 1. Плохая архитектура приложения


Если приложение монолитное или состоит из микросервисов, не разделенных на DMZ/не проводящих валидацию передаваемых данных, то воздействие на одни компоненты повлияет на работу других.

Причина 2. Архитектура просто не учитывает вопросы ИБ


Самый банальный случай — отсутствие валидации отправляемых данных. Эта проблема может привести к самому широкому списку инъекций. По сути, к любому результату, который можно представить.

Причина 3. Умышленное внедрение уязвимостей


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

Причина 4. Недостаточные компетенции в стеке технологий


Создание приложений без отраслевых best-practice, учета предыдущего опыта или рекомендаций вендоров может существенно снизить уровень ИБ будущего приложения. Желательно, чтобы эксперт был всегда под рукой — или на аутсорсе.

Причина 5. Некачественные и недостаточные тесты


Добавление инструментов статического и динамического анализа кода в пайплайн точно не будет лишним. Более того — поможет до публикации сервиса выявить потенциальные проблемы безопасности.

Причина 6. Уязвимости сторонних служб


Можно написать довольно безопасное приложение, но неправильно настроить окружение или не пропатчить вовремя службы. Все это приведет к эксплуатации уязвимостей. Записи на https://www.exploit-db.com/ тому подтверждение.

Причина 7. Уязвимости сторонних сервисов


Атаки вроде SSRF могут легко настигнуть ваше приложение, если вы обрабатываете запросы сторонних ресурсов без должной валидации. На вашей стороны эксплоиты могут казаться вполне легитимными запросами и не блокироваться никакими компонентами.

Если вам интересно, как классифицировать веб-уязвимости, обратитесь к актуальной редакции OWASP Top10.


Как можно понять, приведенные причины появления уязвимостей порождают все способы взлома, которые только можно встретить в рейтинге OWASP. Конечно, контролировать все — невозможно. На каком-то из этапов рано или поздно появится уязвимость и будет ждать своего — в лучше случае — «багхантера». Что делать? Спойлер: использовать WAF!

WAF как защитник от эксплуатации уязвимостей


WAF (Web Application Firewall) — это класс решений, которые обеспечивают безопасность на уровне L7 модели OSI. Если очень коротко, WAF «смотрит» в протоколы прикладного уровня, например HTTP, и — в зависимости от содержимого метода, URI, заголовков, тела запроса — принимает решение, пропустить запрос или «отбросить».


Эволюцию WAF обычно описывают тремя поколениями:

1. WAF на основе регулярных выражений,

2. WAF со специальными выражениями (токенами) для каждого типа атаки,

3. WAF на основе методов машинного обучения.

6bjki1xilozg5yc-8tyuo8uhdz4.png

Знакомство с open-appsec


В интернете много материалов о популярных open source-системах WAF. Решений довольно много, среди них — ModSecurity, Coraza, IronBee, WebKnight, Shadow Daemon, OctopusWAF и другие. По части из них репозитории давно не обновлялись, но их все равно активно используют для защиты большого числа веб-приложений.

Про ModSecurity написано больше всего, поэтому в рамках этой статьи рассмотрим одну из интересных альтернатив — open-appsec от компании CheckPoint. Между прочим, это технология третьего поколения WAF: внутри — ML-движок, который позволяет при минимальном пороге входа получить довольно эффективную защиту. Так что присаживайтесь поудобнее.

Основная функциональность open-appsec — community-версия на базе трех агентов WAG — доступна бесплатно, хорошо подходит для защиты небольших веб-сервисов. Решение поставляется для разворачивания в одном из трех сценариев: Kubernetes Ingress, Nginx Add-On, Kong API Gateway Add-On — и управляется с помощью конфигурационного файла или через веб-портал.

Если вы используете конфигурационный файл, то обеспечиваете полную автономность, если портал — удобную панель управления и дашборды из коробки. Кстати, для авторизации на портале достаточно учетной записи Google или GitHub. В community-версии доступны такие компоненты безопасности:

  • Web Application Attack Mitigation (ML-based WAF),
  • Web API Attack Mitigation (ML-based WAF),
  • IPS Engine with Snort 3.0 Support,
  • Rate Limiting,
  • Custom Source Identifiers (IP and XFF only).


Также доступны следующие опции управления:

  • Declarative code based deployment and configuration (DevOps style),
  • Web-based Management of Protected Assets & Policy (SaaS),
  • Web-based Event Management & Dashboards (SaaS),
  • Log Storage in the Cloud.


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

Тестирование open-appsec


Подготовка целевой схемы


В рамках этой статьи мы посмотрим, как с помощью open-appsec повысить безопасность веб-приложения. Уязвимую систему развернем в Docker-контейнере, используя репозиторий, а WAF — на отдельной виртуальной машине с установленным nginx. Злоумышленник будет хоститься на отдельном сервере.

В качестве уязвимого веб-приложения будем использовать OWASP JuiceShop. Оно представляет собой отличный «дуршлаг» для тестов, т. к. в нем уже заложены уязвимости из категорий XSS, CSRF, SSRF, SSTI, XXE, SQL Injections и других.

Создание виртуальной машины

1. Заходим в панель управления my.selectel.ru. Переходим из Облачной платформы в Серверы и нажимаем Создать сервер. Настраиваем конфигурацию — завершаем создание сервера.

d1d7766c4fec901eb4027e913e714527.png


2. Копируем IP-адрес и пароль от сервера, подключаемся по SSH. Ставим Docker и устанавливаем Docker-образ:

apt install docker.io -y
docker pull bkimminich/juice-shop


3. Запустим контейнер, указав порт доступа к приложению 8080, и проверяем доступность веб-приложения:

docker run --rm -p 8080:3000 bkimminich/juice-shop
curl http://localhost:8080


db29d61fb494f9cff12933fa859247ab.png


Создание хоста злоумышленника

1. Заходим в панель управления my.selectel.ru. Переходим из Облачной платформы в Образы и нажимаем Создать образ. В качестве образа выбираем Kali Linux, установленный с официального сайта, — в нем есть все необходимые инструменты для работы.

048296ef3c224ba65e43d7776e862c21.png


2. Переходим из Облачной платформы в Серверы и нажимаем Создать сервер. В качестве операционной системы указываем погруженный образ:

19e1b78319df447963153bea3ac32ed9.png


Настройка облачного файрвола

Сейчас опубликовано уязвимое приложение. Чтобы его никто кроме нас не поломал, ограничим к нему доступ из интернета с помощью облачного межсетевого экрана. Решение бесплатно для всех пользователей облачной платформы.

1. Заходим в панель управления my.selectel.ru. Переходим из Облачной платформы в Файрволы и нажимаем Создать файрвол.

2. Добавляем правила Входящего трафика, ограничивая доступ к тестовому стенду. Разрешаем подключения только с доверенных белых IP-адресов, остальные запросы — отбрасываем.

33908c86160fc546f1ede1dd9ca77e47.png


Правила входящего трафика.

3. Наружу разрешаем выход в интернет только для NAT-сети, в которой расположены хосты стенда.

dcd74ff6ddf132a5eed58c2c9741aab7.png


Правила исходящего трафика.

Отлично — стенд готов, WAF поставим позже.

b7231f74feaa1e6447190af2d3ecaa8b.png


Разбор техник взлома приложений


Теперь покажу эксплуатацию уязвимостей веб-приложения, которые входят в OWASP Top10. В JuiceShop есть раздел со списком уязвимостей — его можно найти по пути /score-board.

29276f917a1ad0768b3b534564e5939b.png


Раздел со списком уязвимостей.

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

1. DOM XSS. В поле поиска добавляем тег iframe с вызовом алерта: