Что такое WAF? Знакомство с open-appsec на практике

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WAF как укротитель уязвимостей

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

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

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

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

Знакомство с 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. Переходим из Облачной платформы в Серверы и нажимаем Создать сервер. Настраиваем конфигурацию — завершаем создание сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    <iframe src=”javascript”:alert(‘xss!’)”>

Видим, что XSS действительно есть и готова к эксплуатации.

2. Login Admin. В форме авторизации пропишем простую SQL-инъекцию для обхода авторизации и зайдем под админом. Как видим, особого труда это не составило: 

3. Password Strength. Далее попробуем авторизоваться под админом без использования инъекций — очевидно, понадобится сбрутить пароль. В burpsuite перехватываю попытку авторизации и отправляю в Intruder:

Параметру email задаю значение admin@juice-sh.op, а password буду брутить списком паролей. Подошло значение admin123, с которым можно авторизоваться как админ, при этом без инъекций:

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

Настройка WAF для защиты

Техники взлома понятны. Представим, что разработчики приложения по объективным причинам не закрыли уязвимости, а оставлять приложение в таком виде нельзя. В данном случае нам поможет open-asspec.

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

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

    apt install nginx -y

3. Публикуем приложение через nginx. Для этого создаем файл juiceshop.conf и добавляем в него конфигурацию:

    nano /etc/nginx/sites-available/juiceshop.conf

    server {
    listen 80;
    server_name juiceshop.test;
    location / {
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $host;
        proxy_pass http://192.168.0.3:8080;
    }
    location ~ /\. {
        deny all;
    }
}

4. Создаем ссылку на конфигурацию и устанавливаем агент open-appsec:

    ln -s /etc/nginx/sites-available/juiceshop.conf /etc/nginx/sites-enabled/juiceshop.conf

    wget https://downloads.openappsec.io/open-appsec-install && chmod +x open-appsec-install
./open-appsec-install

    For release notes and known limitations check:
https://docs.openappsec.io/release-notes
Searching local NGINX…
nginx version found: 1.18.0-0ubuntu1.4
Downloading open-appsec NGINX attachment... stored in '/tmp/open-appsec'
Downloading open-appsec agent... stored in '/tmp/open-appsec'
Add your email to receive important security updates and so you can approach us with technical questions (enter IGNORE to ignore):
IGNORE
Installing open-appsec for NGINX...
Updating NGINX server configuration...
Starting open-appsec installation...
Successfully installed open-appsec...
For release notes and known limitations check: https://docs.openappsec.io/release-notes
For troubleshooting and support: https://openappsec.io/support

Теперь по расположению /etc/cp/ доступны каталоги и файлы агента open-appsec.

5. Далее нужно подключить open-appsec к порталу. Для этого проходим авторизацию на портале https://www.openappsec.io и создаем агента. Переходим в Getting Started, в разделе Central Management выбираем «Managed → Linux Embedded Agent Profile». В качестве имени пишем «Test Agent», в поле Agent Upgrade выставляем в «Manual», а в Deployment выбираем «NGINX application security»:

6. В разделе Management выбираем способ задания политик и определения агентов,  «This management». И на виртуальной машине с nginx выполняем две команды для подключения агента к порталу:

    ./open-appsec-linux-connect-mgmt --token <token>

Uploading local policy configuration to cloud...
...
Registering open-appsec Nano Agent to Fog..
open-appsec Nano Agent is registered to https://inext-agents.cloud.ngen.checkpoint.com
Orchestration mode changed successfully

Если все прошло успешно, то вы получите такое уведомление, а в разделе Agents будет информация об инстансе:

6. Далее включаем отправку логов на портал. В разделе Assets после подключения агента появился новый ресурс. Переходим в его свойства. В General → Basic видно прилинкованный профиль:

В General → Web Application указано, что агент будет пропускать трафик ко всем опубликованным по HTTP-ресурсам:

В General → Source Identity и Trusted Sources можно поменять способы определения источников подключения к защищаемым ресурсам, а также указать доверенные источники:

В разделе Threat Prevention можно управлять компонентами защиты приложений, указыв режим обучения/обнаружения или предотвращения. Для начала оставим все в режиме обучения, а далее изменим на предотвращение.

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

Обучение WAF идет с помощью ML-модели, которая доступна в разделе Account → Download advanced ML model. Если нужно добавить свои правила, это можно сделать в разделе Assets → Custom rules and exceptions. Важно: защищать можно и API, если создать отдельные ресурсы в разделе Assets.

7. Применим политику для агента. 

В разделе Behaviors можно настраивать кастомные страницы ответа при запрете доступа к защищаемому ресурсу силами агента open-appsec. В этой политике включаем отправку логов на портал, а также расширенное логирование URL path, URL query, HTTP headers и Request body.

8. Просканируем приложение с помощью сканеров в Kali Linux. 

Теперь с виртуальной машины Kali можно обращаться к уязвимому приложению двумя способами: непосредственно по адресу http://192.168.0.3:8080 или через nginx с open-appsec (http://juiceshop.test). 

Для обучения WAF необходимо сгенерировать разный вид трафика. Для этого на виртуальной машине Kali в /etc/hosts добавим запись: 

    192.168.0.100 juiceshop.test

Запустим сканирование с помощью nikto, о примере работы с которым я писал ранее в статье:

    nikto -h http://juiceshop.test –output report.html

В веб-панели должно появиться сообщение о начале обучения ресурса:

Следить за прогрессом можно в разделе Assets → Learn. Сам процесс обучения ML-движка подробно описан на сайте open-appsec.

Дополнительно сгенерируем трафик с помощью nmap и skipfish:

    nmap -sV --script=http-enum juiceshop.test

    skipfish -o res http://juiceshop.test

Тем временем во время сканирования JuiceShop сообщает об успешном прохождении заданий:

Далее запущу сканирование с помощью замечательного инструмента commix:

То же самое можно сделать из консоли:

    commix -u http://juiceshop.test --level 3

В итоге у WAF есть определенная статистика, которую можно наращивать дальше:

Повторные тесты по эксплуатации уязвимостей

Пришло время на обученном WAF повторить те же атаки. Для начала в разделе Assets → Threat Prevention переключим режим из Learn/Detect в Prevent для параметров Web Attacks и Intrusion Prevention. А далее применим политику и повторно выполним атаку на тестовое приложение через http://juiceshop.test и посмотрим на результат.

1. DOM XSS. WAF детектирует XSS в POST-запросе:

2. Login Admin. Повторные попытки обхода авторизации не дают результата, а в разделе Monitoring появились такие события:

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

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

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

Open-appsec периодически запрашивает уточнение по отнесению запросов источников к легитимной или вредоносной активности:

Это позволяет сделать обучение более эффективным с меньшим количеством false positive-событий.

3. Password Strength. Для предотвращения атак типа брутфорса можно, например, создать правило в разделе Rate Limit:

Сбор статистики отраженных атак

Для наглядности запущу повторное сканирование с помощью commix, когда WAF работает в режиме Prevent. Если запустить сниффинг входящего трафика на интерфейсах сервера с WAF и сервера с приложением в контейнере, можно понять, что до второго хоста arp-запросы не доходят.

На портале можно посмотреть статистику отраженных атак в разделе Monitoring:

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

Просмотр политики:

    open-appsec-ctl -vp

Просмотр логов:

    open-appsec-ctl -vl

Тестирование обхода WAF

Отлично — WAF из коробки после небольшого обучения (без качественных сигнатур) детектирует и отражает атаки. Но давайте попробует его обойти с помощью waf-bypass. 

1. Клонируем репозиторий и запускаем решение локально на Kali Linux:

    # git clone https://github.com/nemesida-waf/waf_bypass.git /opt/waf-bypass/
# python3 -m pip install -r /opt/waf-bypass/requirements.txt
# python3 /opt/waf-bypass/main.py --host='example.com'

2. Запускаем waf-bypass:

    python3 /opt/waf-bypass/main.py –host=’juiceshop.test’

3. Проведем тестирование в два этапа: режиме Learn/Detect и Prevent.

Как видно, результат есть, но не 100%. Чтобы это исправить, можно перейти на расширенную AI-модель, продолжить обучать модель или добавить кастомные правила.

Выводы

Как видим, WAF open-appsec из коробки не гарантирует 100% результат, но ощутимо повышает уровень защищенности приложения. В большинстве случаев решение закроет недостатки в безопасности веб-приложения, но расслабляться и пренебрегать архитектурой нельзя. 

Open-appsec поможет с минимальными усилиями добавить довольно крепкий эшелон безопасности. Однако для более эффективной защиты необходима тонкая настройка с учетом набора допустимых запросов в вашем сервисе.