Защита Apache APISIX с использованием Coraza и Core Ruleset от OWASP

Проект по обеспечению безопасности приложений Open Worldwide (OWASP) представляет собой онлайн-сообщество, которое создает свободно доступные статьи, методологии, документацию, инструменты и технологии в области безопасности IoT, системного программного обеспечения и веб-приложений. OWASP предоставляет бесплатные и открытые ресурсы. Он возглавляется некоммерческой организацией под названием Фонд OWASP. Топ-10 OWASP – 2021 – это опубликованный результат недавних исследований, основанный на всесторонних данных, собранных более чем от 40 партнерских организаций.

– Сайт OWASP

OWASP регулярно публикует отчет о топ-10 уязвимостях. В отчете рассматриваются уязвимости в веб-приложениях.

В этом посте я хотел бы описать, как исправить некоторые из них с помощью API-шлюза Apache APISIX.

Топ-10 OWASP 2021

В 2021 году отчет упоминает:

A01:2021-Недостаточный контроль доступа
A02:2021-Криптографические сбои
A03:2021-Внедрение
A04:2021-Небезопасный
A05:2021-Неправильная конфигурация безопасности
A06:2021-Уязвимые и устаревшие компоненты
A07:2021-Сбои идентификации и аутентификации
A08:2021-Сбои целостности программного обеспечения и данных
A09:2021-Сбои безопасной регистрации и мониторинга
A10:2021-Запросы к серверу с подменой

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

Устранение уязвимости зависит от ее конкретной природы. Например, устранение уязвимых и устаревших компонентов является процесс-ориентированным, требующим дисциплины в управлении версиями и выводе из эксплуатации старых. Однако некоторые уязвимости являются техническими и требуют только правильной конфигурации в реверс-прокси или API Gateway, например, Server Side Request Forgery.

Никто не заботится о безопасности

Безопасность – это чувствительная тема, потому что укрепление безопасности не приносит никакой ценности для бизнеса. Карьерно-ориентированные менеджеры не будут заботиться о безопасности, поскольку они не смогут продемонстрировать, что увеличили прибыль компании на X% в своем следующем годовом отчете. Если совет не серьезно относится к безопасности, шансов, что кому-то будет на это напрягаться, мало. По этой причине большинство организаций реализуют безопасность на основе чек-листов, также известной как правдоподобное отрицание. Если вы заинтересованы в правильной реализации безопасности, я изложил некоторые мысли в предыдущей статье блога: “Обращаться с безопасностью как с риском.”

В целом, обеспечение безопасности приложений не получит много бюджета, если вообще получит. Поэтому нам нужно быть умными в этом деле и искать уже существующий компонент. К счастью, OWASP предлагает готовую конфигурацию для управления Топ-10, которая может быть исправлена с помощью конфигурации под названием Core Rule Set. К сожалению, она ориентирована на ModSecurity:

ModSecurity, иногда называемый Modsec, является открытым исходным веб-приложением брандмауэра (WAF). Первоначально разработан как модуль для Apache HTTP Server, он развился, чтобы предоставить массив возможностей фильтрации запросов и ответов Hypertext Transfer Protocol, а также другие безопасность функциональные возможности на различных платформах, включая Apache HTTP Server, Microsoft IIS и Nginx. Это бесплатное программное обеспечение, выпущенное под лицензией Apache 2.0.

– ModSecurity на Википедии

Хотя теоретически возможно настроить Nginx через конфигурацию Apache APISIX, есть другой более прямой способ.

Набор правил OWASP Core и Coraza

Описание Core Ruleset довольно актуально для наших нужд:

Набор правил OWASP® ModSecurity Core Rule Set (CRS) представляет собой набор общих правил обнаружения атак для использования с ModSecurity или совместимыми брандмауэрами веб-приложений. CRS стремится защитить веб-приложения от широкого спектра атак, включая Топ 10 OWASP, с минимальным количеством ложных тревог. CRS обеспечивает защиту от многих распространенных категорий атак, включая:

Внедрение SQL (SQLi)

Межсайтовая скриптинговая атака (XSS)

Межсайтовое включение локальных файлов (LFI)

Межсайтовое включение удаленных файлов (RFI)

Внедрение кода PHP

Внедрение кода Java

HTTPoxy

Shellshock

Внедрение команд Unix/Windows Shell

Фиксация сессии

Обнаружение скриптов/сканеров/ботов

Метаданные/Утечки ошибок

– Сайт OWASP® ModSecurity Core Rule Set

OWASP также предоставляет Coraza, порт ModSecurity, доступный в виде библиотеки Go. Coraza Proxy Wasm построен на основе Coraza и реализует ABI proxy-wasm, который определяет набор интерфейсов Wasm для прокси. Наконец, Apache APISIX предлагает интеграцию proxy-wasm.

Сборка всего этого

Давайте подведем итоги:

OWASP предоставляет список 10 главных уязвимостей в области веб-безопасности.
Они реализованы для ModSecurity через Core Ruleset.
Coraza является портом ModSecurity, доступным в виде реализации proxy-wasm.

Мы можем настроить Apache APISIX с разумными и безопасными настройками таким образом. Давайте сделаем это.

Прежде всего: Coraza не является частью дистрибутива Apache APISIX. Тем не менее, его можно легко добавить здесь с помощью Docker:

Dockerfile

FROM apache/apisix:3.8.0-debian

ENV VERSION 0.5.0                                                           #1
ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip                        #1

ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2

USER root                                                                   #3

RUN <<EOF

  apt-get install zip -y                                                    #4
  unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm
  rm $CORAZA_FILENAME
  apt-get remove zip -y
  chown -R apisix:apisix /usr/local/apisix/proxywasm

EOF

USER apisix                                                                 #5

Определите переменные для улучшения поддерживаемости
Получите релиз Coraza Wasm.
В недавних версиях APISIX пользователь apisix для усиления безопасности. Поскольку нам нужно устанавливать пакеты, мы должны переключиться на root.
Установите unzip, так как он не установлен, распакуйте загруженный архив, удалите архив, удалите unzip и измените владельца извлеченного каталога.
Переключиться обратно на пользователя apisix.

Следующим шагом является настройка APISIX для использования плагина Coraza Wasm.

YAML

wasm:
  plugins:
    - name: coraza-filter                                                   #1
      priority: 7999                                                        #2
      file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm              #3

Установить имя фильтра в коде Wasm
Установить наивысший приоритет, чтобы он выполнялся перед любым другим плагином.
Путь к извлеченному файлу (см. Dockerfile выше)

Наконец, мы можем назначить плагин маршрутам или установить его как глобальное правило, применяемое ко всем маршрутам. Я использую статическую конфигурацию:

YAML

global_rules:
  - id: 1
    plugins:
      coraza-filter:                                                        #1
        conf:
          directives_map:                                                   #2
            default:
              - SecDebugLogLevel 9                                          #3
              - SecRuleEngine On                                            #4
              - Include @crs-setup-conf                                     #5
              - Include @owasp_crs/*.conf                                   #6
          default_directives: default                                       #7

Настроить плагин coraza-filter, теперь, когда он доступен.
Определить конфигурации. Здесь мы определяем одну, default, но мы могли бы определить несколько и использовать разные в разных маршрутах.
Увеличить уровень логирования, чтобы видеть, что происходит в логах.
Включить движок.
Использовать настроенный Coraza.
Использовать все правила. Мы могли бы выбрать и выбрать те, которые нам нужны для более тонкого управления.
Использовать определенную выше конфигурацию default.

Мы переходим к определению маршрутов для тестирования нашей установки. Назовем маршрут на /get:

Shell

curl localhost:9080?user=foobar

Ответ соответствует ожиданиям:

JSON

{
  "args": {
    "user": "foobar"
  }, 
  "headers": {
    "Accept": "*/*", 
    "Host": "localhost", 
    "User-Agent": "curl/8.4.0", 
    "X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204", 
    "X-Forwarded-Host": "localhost"
  }, 
  "origin": "192.168.65.1, 176.153.7.175", 
  "url": "http://localhost/get?user=foobar"
}

Теперь давайте попробуем отправить JavaScript в строке запроса. На стороне сервера такой запрос не ожидается, поэтому наша инфраструктура должна защитить нас от него.

Shell

curl 'localhost:9080?user=<script>alert(1)</script>'

Ответ – код состояния HTTP 403. Если мы посмотрим в лог, мы увидим следующие подсказки:

Plain Text

Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"]
Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection
Coraza: Warning. Javascript method detected
Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1

Coraza сделал свое дело!

Заключение

Большинство организаций не стимулируют безопасность. Поэтому нам нужно быть умными в этом вопросе и использовать существующие компоненты насколько это возможно.

Мы можем усилить защиту Apache APISIX против OWASP Top 10 с помощью Coraza и Core Ruleset.

Дальше идти

APISIX – интегрировать с Coraza

Полный исходный код для этого поста можно найти на GitHub.

Source:
https://dzone.com/articles/hardening-apache-apisix-with-the-owasps-coraza-and