У одной компании администратор заметил странный запрос к панели RabbitMQ: кто-то тянул устаревший API-метод и пытался получить секреты, которые обычно хранятся только для служебных задач. Проверка показала две ошибки в правах доступа, одна из которых могла раскрыть OAuth-секрет, а другая — позволить пользователю видеть чужие очереди внутри кластера.

Какую проблему решаем

Речь идет не о сбое доставки сообщений, а о классической ошибке в контроле доступа. RabbitMQ — это брокер сообщений, который часто стоит в центре корпоративных систем: через него идут заказы, уведомления, внутренние события и служебные токены.

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

О том, как часто секреты утекают из инфраструктуры из-за недосмотра, мы уже писали в разборе утечек секретов в GitHub. Похожие ошибки нередко начинаются с одного лишнего эндпоинта или неправильно настроенной роли.

Что подготовить

Перед обновлением стоит понять три вещи: где у вас стоит RabbitMQ, открыт ли порт управления наружу и используется ли OAuth через management.oauth_client_secret. Если интерфейс администрирования доступен из интернета, риск резко выше.

Ещё один важный момент — сегментация. Если в одном брокере живут разные команды или клиенты, проверьте, разделены ли они по virtual host и не видят ли лишнее друг друга.

Пошаговые действия

  1. Обновите RabbitMQ до исправленных версий: 4.3.0, 4.2.6, 4.1.11, 4.0.20 или 3.13.15. Именно там разработчики закрыли обе дыры.

  2. Если у вас включён OAuth и интерфейс управления доступен извне, срочно смените management.oauth_client_secret. Старый секрет мог утечь через устаревший API-метод.

  3. Закройте доступ к порту 15672 из любых сетей, кроме тех, где реально сидят администраторы. Панель управления не должна торчать в интернет.

  4. Разделите арендаторов по virtual host и проверьте права на очереди и exchange. Пользователь не должен видеть метаданные соседнего сегмента, если у него нет таких полномочий.

  5. На не пропатченных узлах временно ограничьте доступ к уязвимому endpoint через firewall. Это не заменяет обновление, но снижает риск до момента патча.

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

Как проверить себя

После обновления откройте панель RabbitMQ и проверьте, что старый GET /api/auth больше не отдаёт чувствительные данные. В норме запрос должен быть закрыт по правам или вообще не работать в прежнем виде.

Затем зайдите под обычной учётной записью и убедитесь, что вы видите только свои очереди и свои метрики. Если интерфейс показывает чужие queue names, consumer counts или message counts, права настроены неверно.

Полезно отдельно проверить, не светится ли порт управления снаружи. Для этого достаточно пройтись по списку правил на шлюзе и в облачном firewall, а не пытаться «проверить на живом трафике».

Что делать, если не получилось

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

Если у вас распределённая команда, не давайте админ-доступ всем подряд. Ошибка в правах внутри одной площадки быстро превращается в утечку данных по всему контуру.

Сама ситуация вокруг RabbitMQ хорошо показывает: даже зрелый сервер очередей ломается не из-за сложной атаки, а из-за одной старой точки входа и одной пропущенной проверки. Это тот случай, когда патч и ревизия прав важнее любого экзотического средства защиты.

Практический чек-лист

  • Проверить версию RabbitMQ и поставить исправленный релиз.
  • Найти, используется ли management.oauth_client_secret.
  • Сменить OAuth-секрет, если панель управления доступна извне.
  • Закрыть порт 15672 от лишних сетей.
  • Проверить, что tenants разделены по virtual host.
  • Убедиться, что обычный пользователь не видит чужие очереди и метрики.
  • Поставить правила firewall для уязвимого endpoint на старых узлах.
Поделиться: