Архив метки: PostgreSQL

На прошлой неделе Дмитрий Черняков выложил на сайте АЛТЭКС-СОФТ интересную новость о возобновлении выпуска Windows-версий сканера уязвимостей RedCheck

Добавить комментарий

На прошлой неделе Дмитрий Черняков выложил на сайте АЛТЭКС-СОФТ интересную новость о возобновлении выпуска Windows-версий сканера уязвимостей RedCheck

На прошлой неделе Дмитрий Черняков выложил на сайте АЛТЭКС-СОФТ интересную новость о возобновлении выпуска Windows-версий сканера уязвимостей RedCheck. Суть там в следующем: АЛТЭКС-СОФТ более трёх лет вкладывали все ресурсы в развитие Linux-версии RedCheck из опасения не вписаться в тренды импортозамещения. Приоритетом было не добавление новой функциональности, а миграция архитектуры продукта. Сначала продукт перевели на СУБД PostgreSQL. Затем на Linux, выбрав Astra Linux в качестве базового дистрибутива. В итоге в декабре 2023 года АЛТЭКС-СОФТ выпустили стабильную Linux-версию RedCheck 2.7.0 и стали выпускать новые версии (примерно раз в полгода) только под Linux. Казалось бы, успех: проект миграции на российскую ОС успешно выполнен, и дальше можно развивать только Linux-версию? А вот и нет.

Отследив активации лицензий и версии сканеров, в компании оценили, какие версии реально используют пользователи. Оказалось, что большинство до сих пор работает со старой Windows-версией. Причины могут быть разные: нехватка Linux-специалистов, боязнь нового, доступность "серого" ПО Microsoft или всё вместе. В итоге в АЛТЭКС-СОФТ признали: они переоценили темпы перехода на отечественные ОС, и Windows в России по-прежнему широко используется.

Было принято решение возобновить выпуск современной Windows-версии и перейти к кроссплатформенной кодовой базе. АЛТЭКС-СОФТ планируют это сделать с версии 2.14, которая выйдет осенью. Разработка потребует времени и ресурсов и повлияет на текущие планы, часть задач будет пересмотрена по срокам. Код для Linux-версии изначально создавался кроссплатформенным, тратить время на его перенос не потребуется. Придётся потратить время только на сборку и отладку под компонентную зависимость Windows. Есть основания полагать, что АЛТЭКС-СОФТ смогут это сделать достаточно быстро. Выходу RedCheck VM это повредить не должно, т.к. это технически независимый продукт, и над ним работает другая команда.

Из-за значительного технологического разрыва между версиями 2.6 и 2.14 бесшовное обновление Windows-версии будет невозможно. Придётся переходить либо через чистую установку с переносом хостов и групп через CSV, либо через поэтапную миграцию с промежуточными Linux-версиями с сохранением всех данных и конфигураций.

Чему может научить эта история?

🔹 Прежде чем принимать важные решения по изменению архитектуры, необходимо удостовериться, что конкретно ваши клиенты к этому готовы. Архитектурные изменения, вполне принимаемые и даже ожидаемые в Enterprise-сегменте, могут не приниматься сегментом SMB. Нужно знать своего клиента.

🔹 Как видим, половинчатая позиция государства по части импортозамещения ОС создаёт проблемы разработчикам отечественного ПО. Непонятно, насколько это импортозамещение всерьёз. Если всерьёз, то необходимо усиление регуляторного давления на бизнес (не только гос. сектор), чтобы использование продукции Microsoft было максимально неудобным, дорогим, рискованным, нерукопожатным. Ну, это если действительно есть заинтересованность в импортозамещении ОС. А если её нет, то не стоит удивляться, что российские бизнесы продолжат сидеть на ПО Microsoft (в надежде, что когда-нибудь всё будет как раньше 😏) и всю риторику по импортозамещению пропускать мимо ушей.

Августовский Linux Patch Wednesday

Добавить комментарий

Августовский Linux Patch Wednesday

Августовский Linux Patch Wednesday. Я припозднился с этим LPW, т.к. улучшал генерацию списков LPW-бюллетеней и работу Vulristics. 🙂 В августе Linux вендоры начали устранять 867 уязвимостей, почти в 2 раза больше, чем в июле. Из них 455 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-6558) - эксплуатируемая SFB в Chromium уже четвёртый месяц подряд. 🙄

Для 72 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Можно выделить:

🔸 RCE - WordPress (CVE-2024-31211) - прошлогодняя, но в Debian пофиксили недавно; Kubernetes (CVE-2025-53547), NVIDIA Container Toolkit (CVE-2025-23266), Kafka (CVE-2025-27819)
🔸 Command Injection - Kubernetes (CVE-2024-7646)
🔸 Code Injection - PostgreSQL (CVE-2025-8714/8715), Kafka (CVE-2025-27817)
🔸 Arbitrary File Writing - 7-Zip (CVE-2025-55188)

🗒 Полный отчёт Vulristics

Мартовский выпуск "В тренде VM": уязвимости Microsoft, PAN-OS, СommuniGate и кто должен патчить хосты с развёрнутым прикладом

Добавить комментарий

Мартовский выпуск "В тренде VM": уязвимости Microsoft, PAN-OS, СommuniGate и кто должен патчить хосты с развёрнутым прикладом.

📹 Ролик на VK Видео, RUTUBE, YouTube
🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Содержание:

🔻 00:00 Вступление
🔻 00:41 Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2025-21418)
🔻 01:22 Elevation of Privilege - Windows Storage (CVE-2025-21391)
🔻 02:04 Authentication Bypass - PAN-OS (CVE-2025-0108)
🔻 03:19 Remote Code Execution - CommuniGate Pro (BDU:2025-01331)
🔻 04:37 VM-ная загадка: кто должен патчить хосты с развёрнутым прикладом
🔻 07:21 Про дайджест трендовых уязвимостей

Кстати, продакшн нам делают ребята из brocast.team. Очень толковые и внимательные к деталям. 👍 Сложные приколюшечки типа 03:49 сами придумывают и реализуют. 😮 А склеечки какие аккуратненькие делают - ммм. Работать с ними одно удовольствие. 😇 Рекомендую!

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

Добавить комментарий

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

Обновление хостов с прикладом: альтернативное мнение. Пришёл комментарий от подписчика к VM-ной задачке про 2 подразделения и обновление хостов с развёрнутыми приложениями. С любезного разрешения выкладываю текст полностью. 🙂

"Имея опыт работы с обоих сторон ("общей инфры" и админа приклада — как раз того самого Postgres), хотел бы заметить следующее. Всё же обновлением ОС должна заниматься команда, которая заведует ОС и обще-инфраструктурными сервисами, крутящимися на хостах. А админы прикладного ПО — должны следить за своим ПО.

Но все вместе они — должны согласовывать свои действия.

На хосте, помимо условного постгреса, может крутиться много всякого другого. О чём "прикладные админы" могут знать, но не факт, что могут этим грамотно управлять и правильно оценить последствия обновления пакетов. Пример навскидку — на хосте наверняка будут установлены агенты систем мониторинга — как ИТ-шного, так и ИБ-шного. И передать на админов условного постгреса ответственность за обновление хоста со всем этим набором… А "прикладники" точно должны этим заниматься? 😊 Тогда как мимо линуксовых админов установка, настройка и эксплуатация всех этих дополнительных сервисов на хостах с прикладом точно не пройдёт.

По опыту банка, в котором я работал — хосты обновляли линуксовые админы, а "прикладные" — только тот приклад, который в их зоне ответственности. Пакеты, относящиеся к прикладу, ставились на hold сразу при установке приклада, и их обновление было невозможно при обновлении хоста.

Ну и само собой, обновления сначала выполнялись на тестовых средах, чтобы понять, не приедут ли какие-то обновы зависимостей, которые могут сломать приклад. Если не приедут — хост смело обновлялся отдельно, а приклад — отдельно. Если зависимости ломали приклад — либо пакеты зависимостей дополнительно замораживались, либо, если это ломало остальное обновление — обновление откладывалось до ̶л̶у̶ч̶ш̶и̶х̶ ̶в̶р̶е̶м̶ё̶н̶ тех пор, пока приклад не сможет это поддержать. В тестировании, само собой, участвовали обе команды — и "хостовая" и "прикладная". Но на проде, при использовании этой схемы, их работы по обновлению, по большей части происходили независимо."

У такой схемы, безусловно, есть свои преимущества. И она весьма удобна админам, т.к. они занимаются профильными задачками, а непонятной им фигнёй не заморачиваются. Но вот VM-щику такая совместная работа и размытие ответственности невыгодны, т.к. ему придётся частенько "тыкать палочкой" две (а возможно и более) команды, которые будут показывать друг на друга. 😑 Критичные уязвимости не будут устраняться с формулировкой "обновление отложено". А кто будет нести ответственность в случае, если уязвимость будет проэксплуатирована в течение этого "отложенного" периода непонятно. Видимо предполагается, что нести ответственность будет сам VM-щик. 😏 Так что VM-щикам топить за такую схему я бы не советовал.

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

В любом случае, главное, чтобы обновления ставились и уязвимости устранялись (желательно с соблюдением SLA). А как именно это происходит и чьими силами не так уж важно. 😉