Check Point улучшил защиту Google Cloud Platform

Check Point улучшил защиту Google Cloud Platform

Check Point улучшил защиту Google Cloud Platform

Check Point представил решение Check Point vSEC for Google Cloud Platform, обеспечивающее продвинутую защиту, интегрированную с платформой Google Cloud Platform. С этим релизом Check Point вступает в партнерскую программу Google Cloud Technology Partner Program, предлагая защиту рабочих ресурсов в физических, виртуальных и облачных средах на любой облачной платформе.

vSEC for Google Cloud Platform обеспечивает продвинутую защиту, созданную для адаптивных и масштабируемых облачных сред.

«Поскольку сегодня мы пользуемся различными сервисами Google, для нас естественно строить свою новую облачную среду вокруг Google Cloud Platform, — объясняет Гюнтер Оберхофер (Günther Oberhofer), руководитель подразделения сетей и коммуникаций компании Conrad Electronic SE. — Внедрение мощных систем защиты — ключевая часть этой стратегии. Check Point vSEC позволяет нам безопасно пользоваться всеми возможностями облака, расширить использование нашего локального ЦОДа и при этом быть уверенными в защищенности критически важных активов от внешних и внутренних угроз. Помимо этого благодаря Google Cloud Platform  увеличивается скорость, адаптивность и экономичность инфраструктуры».

Check Point vSEC for Google Cloud Platform расширяет продвинутую многоуровневую защиту  рабочих ресурсов  в облаке, оберегая их от внешних атак, и при этом обеспечивает безопасность подключения локальных сетей к Google Cloud Platform. Кроме того, это решение предотвращает горизонтальное перемещение угроз между серверами, размещенными в облаке. Разработанный для динамических требований к безопасности, выдвигаемых облачными системами, vSEC автоматически масштабируется по мере необходимости и улучшает видимость работы за счет интеграции объектов Google Cloud Platform в политики безопасности и системные журналы.

Ключевые аспекты:

  • Улучшенное предотвращение угроз защищает облачные активы от внешних и внутренних угроз. vSEC дополняет имеющиеся инструменты управления Google Cloud Platform, защищая трафик с помощью комплексных многослойных средств безопасности.
  • Автоматизированная и адаптивная защита, соответствующая скорости DevOps, динамически масштабируется и растет вслед за потребностями организации, благодаря чему увеличивается эффективность работы и эластичность бизнеса. vSEC быстро внедряется и настраивается благодаря опции конфигурирования в один клик, доступной через Google Cloud Marketplace. Внедрение по запросу и лицензирование по факту использования (модель Pay-as-you-Grow, «оплата-по-мере-роста») снижает совокупную стоимость эксплуатации облачных систем.
  • Управление безопасностью с единой панели для публичного и частного облака, а также локальных физических сетей обеспечивает последовательное управление политиками и видимость работы облачных инфраструктур. Решение позволяет в политиках безопасности, журналах регистрации событий   и в генерируемых  отчетах предлагаемой системы защиты использовать объекты, определенные Google Cloud Platform, что улучшает прозрачность инфраструктуры.
  • Любое облако, любой сервис всегда защищены. Самая широкая в отрасли поддержка облачных платформ и единственное решение для продвинутого предотвращения угроз Advanced Threat Prevention , подходящее для любой облачной среды (публичной, частной или гибридной) — AWS, Microsoft Azure, VMware, Cisco, OpenStack, Nuage Networks, а теперь еще и для Google Cloud Platform.

«Мы очень рады предложить облачную защиту vSEC для Google Cloud Platform, — говорит Эрез Беркнер (Erez Berkner), директор по управлению продуктами компании Check Point Software Technologies. — Облачная защита vSEC — это мощный инструмент для предотвращения угроз, который масштабируется вслед за ростом вашего бизнеса. Безопасность автоматически подстраивается под динамические изменения в облачной среде, что позволяет командам DevOps и специалистам по безопасности поставить защиту на «автопилот» и равномерно использовать инструменты управления безопасностью во всех облаках».

«Check Point vSEC for Google Cloud Platform приносит в облако ту же многослойную защиту, которую заказчики имеют в своих ЦОДах, — говорит Адам Мэсси (Adam Massey), директор по технологическим партнерствам в Google Cloud. — Мы очень рады, что Check Point поддерживает нас в выполнении обязательства перед заказчиками по построению безопасных, масштабируемых и эффективных приложений».

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru