aidaho6

После консультаций с опытными разработчиками API было принято решение написать его на Flask с использованием views и перейти на JWT-авторизацию. Старый API был разработан на фреймворке Bottle, но поскольку Roxy-WI был переписан на Flask, наличие двух фреймворков в одном проекте не казалось хорошей идеей. На тот момент я уже довольно хорошо изучил Flask. JWT был внедрён, чтобы объединить авторизацию в WEB-версии и API, так как до этого в API использовалась самописная авторизация.

И вот, спустя месяц была выпущена 8 версия! Помимо API и JWT также была внедрена валидация входящих данных на базе Pydantic. Pydantic оказался очень мощным инструментом, но я сопротивлялся использованию библиотеки очень долго - сам уже не знаю почему. И вот, API готов, но необходима документация, поэтому был нужен Swagger. Описывать самому структуру чуть-чуть (очень сильно, капец, как сильно, я же не YAML разработчик) не хотелось. И я решил попробовать ИИ, который предлагает JetBrains за 10 у.е. в месяц (зря что ли плачу?!). Так вот, роботы поработят нас еще не скоро и без работы не оставят :-p. В итоге получилось, правда пришлось поматериться пару вечеров.

API готово, значит пора писать Terraform-провайдер. Долго ли, коротко ли, но первая версия была выпущена и там уже и я подключился к разработке провайдерая и обратился к за помощью. Rocky_Break написал первую версию провайдера и прислал мне книгу по Go. Оказалось, что мало написать API, оно должно еще быть консистентным. Долго ли, коротко ли, но первая версия была выпущена и там уже и я подключился к разработке провайдера (как же не удобно писать на Go, после Python :`( ).

Кстати! Чтобы была возможностью управлять HAProxy полностью терраформом было необходим доработать работу с конфигурациями HAProxy - теперь после "накликивания" себе конфига, его можно так же кликами изменить.

Так что теперь есть IaC вэй для создание HA-кластеров с возможностью создание UDP и HAProxy балансиров ;).

С самого начал работы над Roxy-WI мы думали о максимальном упрощении жизни пользователя с помощью веб-интерфейса. Поэтому мы решили добавить в продукт возможность работы с WAF (Web Application Firewall), чтобы обеспечить защиту веб-сервисов от разного рода вредоносной активности. Естественно, всё то мы старались сделать максимально просто, чтобы даже начинающий пользователь смог без проблем всё настроить.

Введение: немного о WAF вообще и о ModSecurity в частности

Аббревиатура WAF (Web Application Firewall) дословно переводится на русский как “файервол для веб-приложений”. Так называют программные инструменты для защиты веб-приложений от атак и вредоносной активности: брутфорса, SQL-инъекций, XSS-атак, спам-активности в комментариях, попыток загрузки подозрительных файлов и многого другого (у разных WAF набор функций может различаться). Для распознавания злонамеренных действий в разных WAF используются разные технологии: от программно-аппаратных решений, завязанных на железо ― до облачных, в которых активно применяются искусственный интеллект и машинное обучение.

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

На основании применяемых политик все WAF можно разделить на две большие группы: запретительные (англ. blocklist и разрешительные (англ. allowlist). Запретительные, как и следует из названия, не пропускают запросы, которые не попадают под установленными критериями. Разрешительные же работают прямо противоположным образом: они пропускают только те запросы, которые пользователь включил в число дозволенных. Оба этих подхода имеют свои плюсы и минусы, обсуждение которых в задачи нашей статьи не входит. Отметим только, что в современном мире они редко используются в чистом виде: большинство современных WAF используют политики, основанные как на разрешительном, так и на запретительном принципе.

На рынке в настоящее время представлено много инструментов для защиты веб-приложений. Большинство наиболее эффективных WAF ― платные; зачастую они входят в комплекс услуг, предоставляемых облачными и хостинг-провайдерами. Интеграция таких инструментов с веб-приложениями и сервисами, как правило, не представляет никакого труда: большинство провайдеров предоставляют удобный веб-интерфейс, а иногда и API для интеграции. Всё это, как и было сказано выше ― решения коммерческие. Что касается решений с открытым исходным кодом, с помощью которых можно добавить функциональность WAF в собственный сервис, то здесь выбор не особо велик: ModSecurity, WebKnight, Naxsi, Shadow Daemon ― больше никаких известных названий на ум и не приходит.

Самым популярным и самым распространенным из них является, конечно же, ModSecurity ― свободно распространяемый WAF, созданный Иваном Ристичем в 2002 году и в настоящее время поддерживаемый компанией Trustwave SpiderLabs (см. официальный репозиторий на GitHub). Начинался он как модуль для веб-сервера Apache, но со временем проект расширился: появилась поддержка Nginx и HAProxy; впоследствии был выпущен ModSecuriy-модуль и для майкрософтовского веб-сервера IIS.

Начиная с версии 3 проект что ModSecurity по сути начал новую жизнь: внимание разработчиков переключилось с модулей на библиотеку libmodsecurity, с помощью которой стало возможным внедрять функциональность WAF в любые приложения и сервисы: балансировщики нагрузки, панели управления хостингом и другие. Библиотеку можно использовать в программах на C и C++ (в настоящее время ― только для OC семейства Linux); реализована также поддержка ModSecurity для программ на Python.

Продолжается поддержка модулей для Apache и для Nginx (это не совсем модуль в буквальном смысле слова; сами разработчики используют термин сonnector); имеется так же агент для HAProxy.

Именно ModSecurity используется в качестве WAF в Roxy-WI. Ниже мы покажем, как организована работа в нашем сервисе, но перед этим скажем несколько слов об общих принципах работы ModSecurity.

Как работает ModSecurity

Чтобы начать использовать ModSecurity, нужно составить набор правил. Такие наборы поставляются в готовом виде: в свободном доступе распространяется OWASP Core RuleSet (сокращенно OWASP CRS), который как раз и используется в Roxy-WI.

На основе этого набора правил можно защитить веб-приложение от наиболее распространенных атак, в том числе:

- брутфорса;

- shell-инъекций;

- фиксаций сессии;

- SQL-инъекций

- межсайтового скриптинга (XSS);

- локального и удаленного внедрения файлов;

- попыток эксплуатации уязвимостей серии Bashdoor/ShellShock.

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

Структуру и синтаксис правил в этой статье мы подробно разбирать не будем, а всех заинтересованных читателей отсылаем к официальной документации.

ModSecurity на основе правил OWASP CRS может работать в двух режимах. Первый режим ― автономный (используется по умолчанию в ModSecurity версий 2.x). Здесь всё просто: если какой-то запрос попадет под условия правила, то он будет заблокирован; при этом все остальные правила ModSecurity проверять не будет.

Второй режим называется режимом оценки аномалий (используется по умолчанию в ModSecurity версий 3): ModSecurity проверяет все правила и на основе проверки по каждому правилу присваивает проверяемому запросу/ответу определенное количество баллов. Полное совпадение запроса с условиями правила оценивается в 5 баллов, а полное совпадение ответа ― в 4. При достижении порогового количества баллов запрос считается атакой и блокируется.

Как всё сделано в Roxy-WI

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

Здесь всё просто: запрос поступает на бэкенд HAProxy с прописанным правилом, после чего передаётся WAF. Если запрос соответствует правилу, то он возвращается обратно, после чего пересылается на бэкенд-сервер. Если же запрос правилу не соответствует, WAF возвращает ошибку 401 или 404.

В нашей реализации возможности работы с ModSecurity через веб-интерфейс мы руководствовались перечисленными ниже принципами.

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

По завершении установки в меню выбираем HAProxy → WAF, находим в списке нужный сервер и в выпадающем меню WAF Mode выбираем On:

Помимо привычных On и Off можно выбрать ещё и пункт DetectionOnly. В этом случае WAF будет работать только на обнаружение атак, не принимая при этом никаких действий по их обработке.

Во-вторых, мы хотели бы максимально облегчить пользователю работу по добавлению и редактированию правил. В Roxy-WI используется такая модель: по умолчанию устанавливается готовый набор OWASP CRS; некоторые правила из набор пользователь при необходимости может убрать (а потом в случае необходимости вернуть снова). Чтобы просмотреть список правил, нужно нажать на кнопку Open (графа Manage Rules в списке серверов). На скриншоте ниже показан фрагмент списка правил:

Здесь всё просто нужно исключить правило ― убираем чекбокс enabled, нужно вернуть ― ставим чекбокс обратно. Недавно была добавлена возможность просмотра правил: для этого нужно нажать на кнопку View. А вот редактировать правила через веб-интерфейс нельзя ― хотя бы потому, что пользователь (особенно неопытный) может наделать синтаксических ошибок. Да и цель у нас изначально другая: предоставить пользователю (в первую очередь ― пользователю начинающему, который может и не знать ничего о ModSecurity) базовый набор правил из коробки. Если возникает необходимость отредактировать правила, то это можно сделать непосредственно на сервере.

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

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

Заключение

Как обычно, приглашаем всех попробовать ― и поработать с WAF через Roxy-WI. Любые замечания и предложения по улучшению приветствуются.

Наш сайт: https://roxy-wi.org/

Наш GitHub: https://github.com/hap-wi/roxy-wi

Наш телеграм-канал: https://t.me/haproxy_wi

Также приглашаем высказаться в комментариях всех, кто имел дело с ModSecurity и его интеграцией в собственные сервисы: возможно, ваш опыт окажется для нас полезным.

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

Зачем запускать сервисы в контейнере?

Контейнеризация ― это актуальный тренд на протяжении вот уже многих лет (первая версия Docker вышла в 2013 году).  Самое главное преимущество контейнеров заключается в сведении к минимуму возни с установкой и запуском. Все проблемы с зависимости снимаются раз и навсегда. В контейнере мы получаем готовое приложение, которое достаточно просто загрузить на хост и запустить. Собственно, контейнеризованное приложение не будет установлено в систему в буквальном смысле слова: оно будет запущено в изолированном окружении и может быть в любой момент убрано из системы.

Зачем управлять контейнерами через графический интерфейс?

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

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

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

Третье преимущество заключается в упрощении многих операций, что полезно как для начинающих, так и для опытных (особенно при работе с большими инсталляциями) пользователей. Управлять через GUI сетями, томами, образами значительно проще, чем через командную строку.

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

Как это сделано в Roxy-WI

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

Для экземпляров сервисов, работающих в контейнерах, у нас предусмотрена визуализация: на странице HAProxy => Overview (или Nginx => Overview) они помечены значком “коробки”, то есть контейнер. Для них доступны те же функции, что и для всех обычных сервисов.

Начиная с текущей версии (5.3.0)  могут установить HAProxy и Nginx в контейнерах непосредственно через Roxy-WI. Всё очень просто: идём на страницу Servers page и нажимаем на кнопку Proxy installation.  В открывшемся окне выбираем чекбокс Install as a Docker container. После этого всё, начнётся установка.

По умолчанию контейнеры получают имена haproxy и nginx.  Если эти имена требуется изменить, нужно перейти на страницу Settings и отредактировать значения параметров haproxy_container_name и/или nginx_container_name. 

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

Заключение

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

https://roxy-wi.org  - официальный сайт и документация проекта;

https://github.com/hap-wi/roxy-wi - репозиторий проекта (можно не только высказывать своё мнение, но и присылать пулл-реквесты);

https://t.me/haproxy_wi  - наш телеграм-канал; подписывайтесь и будьте в курсе всех новостей.

С помощью Roxy-WI можно работать с конфигурационными файлами для трёх сервисов: HAProxy, Nginx и Keepalived. Через веб-интерфейс пользователи могут выполнять следующие операции:

1. редактировать конфигурационные файлы;

2. визуализировать структуру сети;

3. сравнивать текущую версию конфигурационного файла с предыдущей;

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

Рассмотрим каждую из этих функций подробнее.

Зачем вообще редактировать конфигурационные файлы через веб-интерфейс?

Такой вопрос может возникнуть у многих читателей. Действительно, многие из нас привыкли работать с конфигурационными файлами в текстовом редакторе, и никаких сложностей в этом на первый взгляд нет. Но есть нюансы. Начнём с того, что конфигурационный файл может иметь очень сложную структуру. Сориентироваться в нём бывает сложно, особенно начинающему пользователю. В графическом интерфейсе Roxy-WI всё просто и наглядно. Возьмём в качестве примера конфигурационный файл для HAProxy. Итак, выбираем в главном меню HAProxy => Configs, в выпадающем меню выбираем нужный сервер и нажимаем на кнопку Open. После этого видим такую картину (приводим небольшой фрагмент конфига, секции global и defaults):

Всё вполне понятно; если кликнуть по ссылке Edit, откроется форма для редактирования:

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

Для начинающего пользователя HAProxy (а также Nginx и Keepalived) на таком интерфейсе очень хорошо учиться. Опытному пользователю графический интерфейс поможет не запутаться в сложных конфигах и тем самым снизить вероятность ошибок из-за человеческого фактора.

Ещё Roxy-WI может существенно упростить жизнь, если серверов много: все конфиги можно редактировать в одном месте. Если вы изменили конфиг на master-сервере и применили одно из указанных на кнопках со скриншота выше действий, аналогичные изменения произойдут и на slave-сервере.

Визуализация

Просто читая конфигурационный файл HAProxy, не всегда можно сразу представить, а как именно всё устроено. Именно для этого в Roxy-WI предусмотрена функция визуализации. Выбираем нужный сервер, нажимаем на кнопку Map и видим:

Такая возможность очень полезна для всех, кто только учится работать с HAProxy.

Кроме того, она может очень пригодится в ситуации, когда нужно что-то наглядно объяснить коллегам, которые с HAProxy вообще дела не имели или имели, но очень мало (менеджерам, тестировщикам. техническим писателям и многим другим — здесь возможны варианты).

Работа с версиями

Представьте себе такую гипотетическую ситуацию: вы что-то изменили в конфиге, и нужный вам сервис (тот же HAProxy или Nginx) не запускается. Для таких случаев в Roxy-WI предусмотрена возможность сравнения конфигурационных файлов.

Выбираем нужные версии, нажимаем на кнопку Compare — и на видим diff двух конфигов. Выглядит он так же, как дифф файлов на GitHub:

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

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

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

Заключение

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

https://roxy-wi.org/ - официальный сайт проекта (здесь же документация);

https://github.com/hap-wi/roxy-wi - официальный репозиторий проекта.

Любые пожелания по улучшению работы с конфигурами приветствуются - добро пожаловать в комментарии.