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

Мартовский выпуск "В тренде 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). А как именно это происходит и чьими силами не так уж важно. 😉