Интересный разбор PHP2Shell. У нас в инфраструктуре ~200 серверов с PHP (Nextcloud, кастомные приложения).
После анонса 20 октября обновили все за 6 часов через Ansible.
Главный вызов был не сам патчинг, а проверка что всё работает: часть кастомных приложений сломалась на PHP 8.5 из-за deprecated функций.
Пришлось откатывать 15% серверов на PHP 8.4.Вопрос: а как вы рекомендуете тестировать обновления PHP в production? У нас сейчас staging-среда, но она не покрывает все edge cases.
Используете ли вы canary-деплой или blue-green для PHP-приложений?
Спасибо за кейс. Мы в инфраструктуре столкнулись с похожей ситуацией — атака шла через легитимные учётки, и только корреляция логов Wazuh + Suricata позволила восстановить полную цепочку.
Ключевым оказалось то, что мы хранили логи не только в journald, но и отправляли в отдельное хранилище (Prometheus + Grafana для метрик + отдельный raw log storage). Это спасло при расследовании: злоумышленник пытался зачистить локальные логи, но удалённое хранилище осталось нетронутым.
Вопрос: а как вы решаете проблему с retention логов? У нас при полном retention 90 дней хранилище растёт на ~2TB в месяц. Пробовали сжимать через zstd + ротацию по критичности, но всё равно дорого. Какой подход используете в PT?
Интересный разбор. Мы в похожем проекте столкнулись с тем, что DNS-резолверы не только уязвимы к подмене, но и сами могут быть вектором утечки данных через DNS-tunneling.
Использовали комбинацию: nftables для фильтрации + CrowdSec для детекта аномалий + локальный Pi-hole для блокировки подозрительных доменов.
Плюс мониторинг через Prometheus + Grafana.Вопрос: а как вы решаете проблему с DNS over HTTPS (DoH)?
Если клиенты обходят корпоративный резолвер через DoH, то вся эта защита становится бесполезной.
Мы блокируем DoH на уровне firewall, но это ломает приватность для легитимных пользователей.
Как DevOps/SRE инженер, работающий с локальными AI-моделями (Ollama, Llama, Qwen), вижу здесь важный паттерн: чем мощнее модель, тем больше поверхность атаки через промпт-инъекции и data leakage.
Практический вывод для команд: при использовании AI для анализа кода на уязвимости нужно:
Изолировать среду (контейнер без доступа к prod)
Не скармливать модели реальные эксплойты — только синтетические примеры
Валидировать выводы модели через статические анализаторы (Semgrep, CodeQL)
Кстати, в своей статье в песочнице на Хабре как раз разбираю, как настроить локальный AI-контур без облаков, чтобы данные не уходили наружу при анализе. Архитектура на базе nftables + Ollama + Tailscale.
Спасибо OTUS за материал!
Информация
В рейтинге
5 538-й
Откуда
Екатеринбург, Свердловская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
ML разработчик, Архитектор информационной безопасности
История с eMudhra показывает проблему централизованных УЦ.
Мы в инфраструктуре используем только Let's Encrypt + внутренние CA для внутренних сервисов.
Вопрос: а как вы решаете проблему с отзывом сертификатов при компрометации CA?
У нас при отзыве промежуточного CA пришлось пересоздавать ~500 сертификатов за выходные.
Есть ли автоматизация для массового перевыпуска?
Интересный разбор PHP2Shell. У нас в инфраструктуре ~200 серверов с PHP (Nextcloud, кастомные приложения).
После анонса 20 октября обновили все за 6 часов через Ansible.
Главный вызов был не сам патчинг, а проверка что всё работает: часть кастомных приложений сломалась на PHP 8.5 из-за deprecated функций.
Пришлось откатывать 15% серверов на PHP 8.4.Вопрос: а как вы рекомендуете тестировать обновления PHP в production? У нас сейчас staging-среда, но она не покрывает все edge cases.
Используете ли вы canary-деплой или blue-green для PHP-приложений?
Хороший вопрос про latency. У нас MTTD был ~40 минут при time-to-impact в часах — успели.
Но это потому что корреляция Wazuh сработала на аномалию в логах, а не на сигнатуру.
Если бы шифровальщик был быстрее — не успели бы. Поэтому сейчас думаем в сторону canary-токенов в OT-сегменте для раннего детекта.
Спасибо за кейс. Мы в инфраструктуре столкнулись с похожей ситуацией — атака шла через легитимные учётки, и только корреляция логов Wazuh + Suricata позволила восстановить полную цепочку.
Ключевым оказалось то, что мы хранили логи не только в journald, но и отправляли в отдельное хранилище (Prometheus + Grafana для метрик + отдельный raw log storage). Это спасло при расследовании: злоумышленник пытался зачистить локальные логи, но удалённое хранилище осталось нетронутым.
Вопрос: а как вы решаете проблему с retention логов? У нас при полном retention 90 дней хранилище растёт на ~2TB в месяц. Пробовали сжимать через zstd + ротацию по критичности, но всё равно дорого. Какой подход используете в PT?
SCCM — классическая боль.
Мы в инфраструктуре используем Ansible вместо SCCM для патч-менеджмента: декларативный подход, идемпотентность, git-контроль версий.
Плюс Wazuh для file integrity мониторинга после обновлений.Вопрос: а как вы решаете проблему с rollback при неудачном обновлении?
У нас есть сценарий где SCCM ломал загрузку на 5% машин в парке.
Интересный разбор. Мы в похожем проекте столкнулись с тем, что DNS-резолверы не только уязвимы к подмене, но и сами могут быть вектором утечки данных через DNS-tunneling.
Использовали комбинацию: nftables для фильтрации + CrowdSec для детекта аномалий + локальный Pi-hole для блокировки подозрительных доменов.
Плюс мониторинг через Prometheus + Grafana.Вопрос: а как вы решаете проблему с DNS over HTTPS (DoH)?
Если клиенты обходят корпоративный резолвер через DoH, то вся эта защита становится бесполезной.
Мы блокируем DoH на уровне firewall, но это ломает приватность для легитимных пользователей.
Отличная статья, спасибо за подробный разбор!
Как DevOps/SRE инженер, работающий с локальными AI-моделями (Ollama, Llama, Qwen), вижу здесь важный паттерн: чем мощнее модель, тем больше поверхность атаки через промпт-инъекции и data leakage.
Практический вывод для команд: при использовании AI для анализа кода на уязвимости нужно:
Изолировать среду (контейнер без доступа к prod)
Не скармливать модели реальные эксплойты — только синтетические примеры
Валидировать выводы модели через статические анализаторы (Semgrep, CodeQL)
Кстати, в своей статье в песочнице на Хабре как раз разбираю, как настроить локальный AI-контур без облаков, чтобы данные не уходили наружу при анализе. Архитектура на базе nftables + Ollama + Tailscale.
Спасибо OTUS за материал!