0 просмотренных постов скрыто
Всем сторонникам терминала и противникам GUI:
Показать полностью
1
Как я перестал пользоваться консолью (почти)
Я достаточно давно, уже больше 18 лет (капец я уже старый :`( ), использую консоль. Пробовал разные оболочки: bash, sh, zsh, ksh, но остановился на тех, что стоят по умолчанию на системах. Пожалуй, это моя лень, перенастраивать оболочки и терминалы под себя - никогда не было моим любимым занятием. А ещё меня всегда бесило редактирование конфигов: ок, если открыл, нашел нужный кусок, поправил, закрыл, перезагрузил сервис, а вот если: открыл, нашел нужный кусок, поправил, закрыл, перезагрузил сервис, а оно не работает... и опять: открыл, нашел нужный кусок, поправил, закрыл, перезагрузил сервис и так пока не заработает, N-ое количество раз.
Да, для этого можно открыть несколько терминалов: редактировать в одном, перезапускать в другом. Но тут тоже есть свои минусы, один из них - захламляется терминал вкладками.
Как вы наверное уже поняли - я ленивый админ, который любит красивенькие (и не очень) GUI. Поэтому, начав плотно работать с HAProxy, мне быстро надоело постоянно править конфиг на нескольких серверах. И, не обнаружив на просторах интернета ничего подходящего, я решил написать свой (ага, очень ленивый - 5 лет уже закончить не могу).
Общаясь с одним из пользователей Roxy-WI, я спросил: “А зачем тебе оно вообще?”, в ответ получил хорошую фразу: “Чтобы в консоль не лазить”. И я задумался. Действительно, после создания пользователя для подключения сервера к Roxy-WI (или можно без этого шага, если root нам не страшен) больше нет необходимости заходить на сервер.
Смотрите сами.
Допустим, мы захотели развернуть новый HA кластер с HAProxy/Nginx/Apache на новых серверах, и нам для этого надо всего-лишь заполнить пару полей и выбрать пару галочек:
И, через минуты полторы, будет поднят Keepalived с VIP адресом, который будет мониторить сервис HAProxy, затем будет установлен и сам HAProxy.
Ок, у нас есть HA кластер и он даже работает, но какой с него прок, если он пустой? Таки надо лезть в консоль? Конечно же нет! Дальше идем на страницу добавления секций и “накликиваем” то, что нам нужно:
Можно посмотреть, что получилось в итоге, а можно даже сохранить этот кусок конфига в основной конфиг! Делаем reload или restart на странице с сервисами и всё.
И да, Roxy-WI не пропустит конфиг с ошибками и не перезапустит сервис. У нас есть настроенный и рабочий HAProxy:
Ещё один приятный бонус от GUI - все видно в одном месте: состояние сервисов, их версию, адрес и кто из них master сейчас. А если нажать на сервис, то можно увидеть более подробную информацию:
И конечно же редактирование конфигов присутствует. Это не замена полноценному IDE, но куда удобней vi:
В 90% случаев, это избавит от открытия консоли, а для оставшихся 10 есть много удобных фич.
Но что делать, если, например, есть коллега, который не признает никакие GUI и надо отобрать у него доступ к серверу (это должно быть зачеркнуто)? В Terraform подобные люди порождают кучу проблем с импортом стейтов или дублированием ресурсов, Roxy-WI избавлен от этой проблемы: конфиг берется напрямую с сервера, по этому риск случайно что-то перезаписать крайне мал.
“Но как же так? Но почему? А как?” - есть такие вопросы? С удовольствием отвечу на них, либо напишу ещё одну статью, если вопрос будет слишком большой для комментария. Вы, главное, расскажите мне свою ситуацию, а я всегда рад поболтать ;)
P.S. Конечно же, я продолжаю активно пользоваться консолью и большую часть работы делаю в ней. Я лишь хотел продемонстрировать, что есть и другие способы управлять частью инфраструктуры и не консолью единой. Уверен, какой-то части людей этот инструмент будет полезен.
Показать полностью
5
WAF в Roxy-WI: базовая защита веб-приложений через графический интерфейс
С самого начал работы над 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. Как только всё будет сделано, мы расскажем о нём подробнее в одной из следующих статей.
Показать полностью
5
HAProxy, Nginx и Docker: как это сделано в Roxy-WI
Продолжаем цикл статей о возможностях Roxy-WI. Сегодня мы поговорим ещё об одном важном наборе функций, связанных с управлением сервисами (а именно ― HAproxy и Nginx) в docker-контейнерах. Мы старались сделать эту функцию максимально простой и удобной в использовании. О том, что у нас получилось, и пойдёт речь ниже.
Зачем запускать сервисы в контейнере?
Контейнеризация ― это актуальный тренд на протяжении вот уже многих лет (первая версия 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 - наш телеграм-канал; подписывайтесь и будьте в курсе всех новостей.
Показать полностью
What does the Checker check, или как организовать удобный мониторинг через веб-интерфейс =)
Продолжаем серию публикаций о нашем веб-интерфейс для HAProxy. Сегодня мы поговорим о специализированном сервис под названием Checker, предназначенном для мониторинга сервисов HAProxy и Nginx, а также бэкендов HAProxy. Если один из сервисов падает, то Checker рассылает уведомления через Telegram или Slack.
Это очень удобно: не нужно "прикручивать" сторонний инструмент мониторинга, да и умеет Checker (причём из коробки) гораздо больше. Впрочем, обо всём по порядку.
Структура и функции
Сервис Cheсker состоит из управляющего компонента (Master Checker в терминологии Roxy-WI) и рабочих компонентов (Worker Checkers в терминологии Roxy-WI)
Рабочие компоненты на текущий момент имеются для HAProxy и Nginx.C функциями управляющего компонента всё понятно - он отвечает за функционирование рабочих компонентов.
Рассмотрим их функции более подробно. Рабочий компонент для HAProxy умеет проверять статус сервиса HAProxy, а также статус бэкендов, а также рассылать уведомления в Теlegram, Slack или в оба мессенджера одновременно. Важный момент: ещё он умеет проверять, приближается ли число установленных соединений к заданному лимиту, и отправлять соответствующие уведомления. При использовании сторонних инструментов мониторинга это возможно, но всё сложнее: для того же Prometheus надо прописывать отдельные правила. У нас же никаких дополнительных настроек не нужно.Рабочий компонент для Nginx умеет проверять статус сервиса Nginx, и рассылать уведомления, если статус изменился. В планах — создание рабочего компонента для Keepalived. Он будет проверять состояние сервиса, а также отправлять уведомления при каждом переключении между мастером и бэкапом.
Установка
Дисклеймер: для выполнения всех описанных ниже действий у вас уже должен быть установлен Roxy-WI. Если вы его ещё не установили, читайте здесь, как это сделать.
Установить Checker можно с помощью стандартного менеджера пакетов:
#yum
$ sudo yum install roxy-wi-checker
#apt
$ sudo apt-get install roxy-wi-checker
После установки нужно запустить Checker. Для этого в главном меню выбираем пункт Admin Area => Services, находим в списке roxy-wi-checker (он там идёт первым) и нажимаем на значок "Play"
Затем потребуется включить Checker для серверов, для которых мы планируем получать уведомоления. Выбираем в главном меню пункт HAProxy => Overview или Nginx => Overview. На экране мы увидим список серверов, в котором каждый сервер будет представлен в виде отдельной карточки, например:
Здесь всё просто: выбираем соответствующий чекбокс — и Checker включен. Уведомления обо всех событиях будут приходить прямо в браузере и сопровождаться звуковым сигналом —’это удобно, например, для дежурных системных администраторов и сотрудников служб технической поддержки.
Информация обо всех событиях, которые регистрирует Checker, сохраняется в истории (Monitoring => Checker history в главном меню):
Она может оказаться полезной при диагностике и устранении неисправностей.Состояние как управляющего (Master), так и рабочих (Worker) компонентов Checker можно отследить на главной странице Roxy-WI в разделе Services status:
Практический кейс: настраиваем уведомления через Telegram
Рассмотрим возможности Checker более подробно. Попробуем сделать так, чтобы сервис рассылал сообщения об изменения состояния сервисов через Telegram.
Для этого потребуется:
1. создать Telegram-бота;
2. создать Telegram-канал;
3. предоставить боту права администратора канала;
4. активировать Checker для серверов, информацию о которых вы планируете получать
Краткая инструкция по созданию бота опубликована на сайте Roxy-WI. По завершению всей процедуры BotFather (служебный бот, который управляет всеми ботами в Telegram) выдаст токен. Скопируем токен и выберем в главном меню Admin Area => Services.
Интерфейс для управления Telegram-уведомлениями выглядит так:
Вставляем Token в соответствующее поле, в поле Channel name вводим имя канала (обязательно со знаком @). Далее нужно будет выбрать группу, для которой будут рассылаться тестовые уведомления. В нашем случае это группа dev.
Вообще серверы на группы можно делить на любых основаниях, и создавать неограниченное количество групп (пункт Admin Area => Groups в главном меню).Заполнив все поля, нажимаем на кнопку test — в канал будет отправлено тестовое уведомление.
Заключение
В этой статье мы кратко рассказали о возможностях нашего внутреннего инструмента мониторинга и рассмотрели практический кейс. Приглашаем всех желающих поэкспериментровать — и высказать своё мнение. Все предложения по улучшению проекта приветствуются.
Наш репозиторий — https://github.com/hap-wi/roxy-wi
Наш Telegram-канал — https://t.me/haproxy-wi
Показать полностью
5