aidaho6

Ping стал умнее

Раньше проверка ping в RMON отправляла один пакет — это было достаточно для грубой оценки, но плохо отражало реальное состояние канала. Теперь всё иначе:

• Можно указать количество ICMP-пакетов в настройках проверки.

• Система собирает и отображает:

  • min RTT

  • max RTT

  • avg

  • mean

Это особенно полезно, если канал нестабилен: одиночный ping может случайно показать “всё хорошо”, хотя на деле теряются пакеты или резко плавает задержка.

| Возможность | SmokePing | RMON |

|-----------------------------|----------------|---------------------------|

| Графики RTT и потерь | ✅ Да | ✅ Да |

| Группировка алертов | ❌ Нет | ✅ Да |

| Настраиваемое кол-во пакетов| ✅ Частично | ✅ Да |

| Интерактивный веб-интерфейс | ❌ (CGI) | ✅ Современный UI |

| MTR из разных регионов | ❌ Нет | ✅ Да |

| Проверки из нескольких точек| ❌ (1 сервер) | ✅ Геораспределённые агенты |

| Telegram/Slack уведомления | Только через внешние скрипты | ✅ Встроено |

| API | ❌ Ограничен | ✅ Полноценный REST API |

SmokePing — отличный инструмент для исторического анализа задержек. Но он устарел в архитектуре, плохо масштабируется по регионам и требует обвесов для алертов.

RMON же изначально создавался с упором на:

• простую установку;

• удобный интерфейс;

• встроенные нотификации и API;

• и главное — распределённый мониторинг из разных географий.

Группировка алертов

Пользователи с несколькими агентами в разных регионах сталкивались с таким сценарием:

"Падает один хост — и мы получаем 5+ одинаковых алертов от каждого региона".

Теперь алерты по одному хосту автоматически агрегируются:

• Вы получаете единое уведомление со списком всех регионов, где обнаружена проблема.

• Упрощается логирование, снижается "шум" в системах алертинга (Telegram, Slack и т.п.)

MTR на месте

Мы добавили возможность запускать MTR (traceroute с расширенной статистикой) из конкретного региона:

• Прямо из веб-интерфейса или API

• Можно быстро проверить маршрут от нужного агента до целевого хоста

Это особенно удобно при отладке проблем между регионами, в CDN, или при работе с провайдером.

Что дальше

Мы продолжаем развивать RMON как инструмент для распределённого мониторинга, ориентированный на:

• телеметрию от агентов из разных регионов;

• гибкую конфигурацию проверок;

• удобную интеграцию с Telegram, Slack, Prometheus, Zabbix и другими системами.

Если вы хотите точно знать, где и когда у вас реально деградирует сеть — попробуйте RMON: https://rmon.io

Одна проверка с нескольких агентов

Изначально мы планировали эту возможность, но реализовали, только, спустя полгода. У фичи достаточно сложная логика, по этому прокрастинировали, как можно дольше :). Получилось, вроде неплохо:

Переписали HTTP проверки на libcurl

Изначально использовали Python requests, так как было проще всего начать с нее, но мы сразу понимали, что requests не подходит из-за скорости работы и не возможности снимать HTTP метрики. В поисках решения нашли libcurl. Оказывается, curl - это не просто консольная утилита, с помощью, которой можно скачать файл и дернуть ifconfig.io, но и мощная библиотека для выполнения разных запросов. Кто ж знал.

С помощью Pycurl с libcurl достаточно легко и удобно работать из Python:

class CurlHttp:

def __init__(self, **kwargs) -> None:

...

def curl(self):

try:

buf = io.BytesIO() # We need to measure download time.

c = pycurl.Curl()

self.set_http_method(c)

self.set_curl_options(c, buf)

except pycurl.error as e:

raise Exception(f'Cannot set curl http_{self.check_id} {e.args[1]}')

try:

c.perform()

except pycurl.error as e:

self.reset_http_results(e.args[1])

except Exception as e:

self.reset_http_results(e)

return c, buf

def set_http_method(self, c):

http_methods = {

'get': c.HTTPGET,

'post': c.POST,

'put': c.PUT,

'head': c.NOBODY

}

custom_http_methods = {

'patch': "PATCH",

'delete': "DELETE",

'options': "OPTIONS"

}

if self.http_method in http_methods:

c.setopt(http_methods[self.http_method], 1)

else:

c.setopt(c.CUSTOMREQUEST, custom_http_methods[self.http_method])

def set_curl_options(self, c, buf):

c.setopt(c.URL, self.url)

c.setopt(c.DNS_CACHE_TIMEOUT, 0) # disable dns cache.

c.setopt(c.FORBID_REUSE, 1) # disable dns cache.

c.setopt(c.FRESH_CONNECT, 1) # disable dns cache.

c.setopt(c.HEADERFUNCTION, self.headers.write)

c.setopt(c.WRITEFUNCTION, buf.write)

c.setopt(c.TIMEOUT, self.timeout)

c.setopt(c.USERAGENT, 'RMON-bot')

# c.setopt(pycurl.VERBOSE, 1)

# c.setopt(pycurl.DEBUGFUNCTION, self.debug_curl)

...

if self.is_https == 'https':

c.setopt(c.OPT_CERTINFO, 1)

if self.ignore_ssl_error:

c.setopt(c.SSL_VERIFYPEER, 0)

c.setopt(c.SSL_VERIFYHOST, 0)

При переходе на libcurl удалось запустить несколько тысяч HTTP проверок на довольно слабенькой ВМ, вместо сотен на requests. Кстати, так же с помощью libcurl удалось реализовать SMTP проверки!

Больше параметров богу параметров!

Разве необходимо много параметров, чтобы проверить работает ли сайт? Как оказалось - да, надо много! Сейчас их много, что аж на экран не помещается (классная метрика, достаточности "что аж на экран не помещается", да?):

Но надо еще больше. Как минимум сейчас не хватает:

1. Важности алертов (warning, critical)

2. Инверсивная проверка

3. Возможность принимать несколько статус кодов ответа

4. Авторизация.

Нет предела совершенству и есть куда развиваться.

Что-то вроде итога

Это конечно же не все изменения что были проделаны, но лишь то что может быть интересно пользователям. Что еще хотелось бы отметить:

1. Добавление поддержки PostgreSQL

2. Возможность писать логи в JSON

3. Пуш метрик в VictoriaMetrics

4. Свои CSS стили для Status pages

5. Стабилизация проекта и более читаемый вывод ошибок

6. Переписали всю документацию на сайте

Кто захочет попробовать и потестить, не смотрите на прайс, просто напишите мне ;).

После консультаций с опытными разработчиками 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  - наш телеграм-канал; подписывайтесь и будьте в курсе всех новостей.