Системное администрирование *

Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов

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

В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.

Если хотите закрыть базу по Linux и автоматизации

• 18 июня, 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Для тех, кто хочет перестать делать рутинные операции руками и начать автоматизировать админские задачи через простые, понятные Bash‑скрипты.}

• 4 июня, 20:00. «Продвинутый Bash».
  _{Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.}

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages».
  _{Практичная тема для тех, кто сталкивался с ситуацией «память вроде есть, но сервер ведёт себя странно».}

Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)

Если работаете с контейнерами и Kubernetes

• 2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux».
  _{Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.}

• 28 мая, 20:00. «Безопасность K8s: основные концепции и частые проблемы».
  _{На уроке разберем базовые концепции безопасности K8s и ошибки, которые регулярно всплывают в реальных кластерах.}

• 18 июня, 20:00. «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать».
  _{Более прикладной взгляд на безопасность Kubernetes: где кластеры обычно оставляют открытыми, какие настройки создают риск и что стоит проверить в первую очередь.}

Если отвечаете за стабильность систем

• 1 июня, 20:00. «Мониторинг распределенных систем».
  _{На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.}

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе».
  _{Для тех, кто хочет перейти от тушения пожаров к управляемому процессу: как реагировать на инциденты, разбирать причины и снижать вероятность повторения сбоев.}

• 3 июня, 20:00. «Internal Developer Platform: self‑service‑инфраструктура за один вечер».
  _{Как организовать инфраструктуру так, чтобы разработчики могли получать нужные ресурсы быстрее, а инфраструктурная команда не превращалась в ручной сервис‑деск.}

Если зона ответственности включает защиту инфраструктуры

• 16 июня, 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
  _{На уроке разберем, как такие системы вписываются в инфраструктурную безопасность и где от них действительно есть польза.}

Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.

Artemis или Kafka? Как перестать выбирать и начать использовать

Архитекторы и ИТ-директора стоят перед сложным выбором: «сверхбыстрый» ActiveMQ Artemis для транзакционных сценариев с низкими задержками или горизонтально-масштабируемая Apache Kafka для потоковой аналитики и долгосрочного хранения событий. Это была ложная дилемма.

На вебинаре 22 мая в 14:00 (мск) разберем, почему Artemis и Kafka – не конкуренты, а идеальные партнеры, и покажем, как платформа Digital Q. Integration решает задачу маршрутизации «одним окном».

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

Программа вебинара:

14:00 – 14:05 Ложная дилемма выбора: почему Artemis и Kafka – не конкуренты, а партнеры

14:05 – 14:15 Две философии: почта vs лента событий. Как понять, какой инструмент под вашу задачу

14:15 – 14:25 Живые сценарии. Где критична скорость, а где – история данных

14:25 – 14:40 Решение: маршрутизация через Digital Q.Integration. Как один параметр brokerType заменяет две инфраструктуры

14:40 – 14:45 Чек-лист для принятия решения при выборе интеграционной платформы

14:45 – 15:00 Вопросы и ответы

Вебинар будет интересен:

• техническим директорам, СТО, архитекторам;

• руководителям разработки, тим-лидам, владельцам цифровых продуктов;

• тем, кто проектирует и поддерживает асинхронные системы обмена данными.   ·       

 Зарегистрироваться на мероприятие

Как отключить звуковое уведомление для SMS которые рассылает RSCHS (МЧС)

Я не знаю как отписаться от рассылки SMS которые шлёт RSCHS.

RSCHS давно шлёт мне уведомления о разнообразных стихийных бедствиях, хотя я не просил его об этом, и не давал согласия включать меня в эту рассылку. Раньше я эту рассылку терпел, потому что она не была такой частой и назойливой. Но в последнее время RSCHS, душка такая, решил, что совершенно необходимо в два часа ночи сообщить мне о беспилотной опасности. Причём на каждую из моих SIM карт. А звук на входящие SMS у меня громкий. Беспилотники летают почти каждую ночь. Отключать смартфоны на ночь я не хочу. И вот здесь моё терпение лопнуло, и я стал искать способ решить эту проблему. Если у Вас на смартфоне нет возможности занести RSCHS в спам-лист, то есть другой способ.

Идея состоит в том, чтобы создать в адресной книге на смартфоне отдельный контакт для телефона сервисного центра RSCHS и назначить ему специальный файл не содержащий звука.

Для Android. На смартфоне открываем сообщения от RSCHS, выбираем любое, тапаем по нему коротко, открывается окно Message details, или нажать длинно на сообщении - View details. В открывшемся окне в поле Service Center номер +7 921 6000088. Возможно для Вашего сотового оператора и региона номер будет другим. Создаём новый контакт «RSCHS Service Center», в поле mobile number указываем +7 921 6000088. Сохраняем этот новый контакт. Назначаем для этого контакта звук тишины - Set ringtone выбрать рингтон None.

Если на смартфоне по какой-то причине нет рингтона None. Надо создать файл mp3 содержащий тишину. Можно засунуть смартфон микрофоном под подушку и запустить на нём стандартное приложение Sound Recorder. Я использовал звуковой редактор - Audacity. Он умеет Generate Silence. На выходе получился файл silence.mp3 размером один килобайт, содержащий тишину длительностью три секунды. Копируем его на смартфон, в папку со звуками, назначаем для контакта RSCHS.

Теперь SMS от RSCHS будут продолжать поступать на Ваш смартфон, но уже молча.

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

Нужна ли кувалда, чтоб вынуть один кривой гвоздь?

Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.

Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.

И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.

Полный откат – не всегда ответ

С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.

Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.

Не «всё умерло», а:

– удалили одну важную группу;
– изменили атрибут у тысяч пользователей;
– сломали членства;
– неверно применили политику;
– после миграции обнаружили хвосты в объектах;
– интеграция записала в каталог не то, что должна была.

Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.

А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.

Почему полное восстановление неудобно

Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».

Для аварии это нормально.

Для точечной ошибки – не всегда.

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

Получается выбор без хорошего варианта:

1️⃣ откатить больше, чем нужно;

2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;

3️⃣ вручную разбирать, что именно поменялось.

Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.

Что хочется иметь на практике

В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».

А что именно изменилось между текущим состоянием каталога и снимком:

– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.

И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.

Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.

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

Где здесь РЕД АДМ 2.1 и Granulex Recovery

В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.

Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.

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

Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.

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

Тысячи сайтов на cPanel скомпрометированы через одну уязвимость — и атакующие работали незаметно шесть лет до этого всплеска.

По данным SecurityLab, за недавней волной взломов стоит не случайный скрипт-кидди, а организованная группа с многолетним опытом. Шесть лет — это не оговорка. Столько времени они оставались в тени, прежде чем атаки стали заметны.

Что случилось с cPanel. cPanel — это панель управления хостингом, которую используют сотни тысяч веб-серверов по всему миру. Уязвимость в ней позволяла получить доступ к серверу без логина и пароля. Никакого брутфорса, никакой социальной инженерии — просто прямой вход через дыру в аутентификации.

Детали уязвимости в исходном материале не раскрываются — ни CVE-номера, ни версии, ни механизма. Это важная оговорка: оценить реальный масштаб риска без этих данных сложно. Но факт массовых компрометаций зафиксирован.

Почему шесть лет — это тревожнее самого взлома. Долгое присутствие в тени говорит об одном: группа умела не шуметь. Это не сканирование Shodan и немедленная эксплуатация — это терпеливая работа с избирательными целями. Когда такая группа всё же «засвечивается», обычно это означает либо смену тактики, либо намеренный переход к масштабированию.

Для владельцев хостинг-инфраструктуры и тех, кто держит сайты на shared-хостинге с cPanel, вопрос сейчас не «взломают ли», а «не взломали ли уже». Следы присутствия профессиональной группы могут быть нечитаемы стандартными средствами мониторинга.

• Проверить версию cPanel и наличие последних обновлений безопасности

• Поднять логи аутентификации за последние недели — аномальные входы без учётных данных

• Проверить целостность файлов на сервере (особенно конфиги и веб-шеллы)

• Если хостинг управляемый — запросить у провайдера подтверждение патча

Атаки через панели управления хостингом — это удар сразу по всем сайтам на сервере, а не по одному. Один уязвимый сервер cPanel — это потенциально десятки и сотни скомпрометированных проектов одновременно. Масштаб инцидента определяется не числом серверов, а числом сайтов на них.

Пока нет публичного CVE и технического разбора, сложно говорить о полной картине. Но шесть лет незаметной работы — это уже достаточный аргумент, чтобы не откладывать проверку на потом.

TG @CIOlogia

Напрямую или через бот-платформу: как лучше интегрировать чат-боты

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

1. Прямая интеграция с каналом 

➕  Полный контроль над функциональностью — например, в случае VK можно обрабатывать не только запросы в личных сообщениях, но и комментарии под постами, на стене, под фото.
➖  Разные API, авторизации, ограничения и нюансы. Требуется закладывать время на поддержку каждого канала.

2. Интеграция через Botmother

➕  Визуальный конструктор — менять сценарии могут не-разработчики. Один сценарий обработки обращений достаточно просто раскатать на разные каналы.
➖  Меньше гибкости в тонкой настройке маршрутизации и аналитики по сравнению с другими платформами.

3. Интеграция через Fasttrack

➕  Расширенные шаблоны ответов, точная маршрутизация по командам, продвинутая аналитика.
➖  Сложнее в настройке сценариев в отличие от того же Botmother.

Что же в итоге? Можно остановиться на способе 2-в-1. Для отдельных сценариев — прямая интеграция, в других случаях — через бот-платформу. Так сделано у одного крупного клиента ITSM 365.

Подробнее про кейс, нюансы в поддержке интеграций и практические шаги по внедрению — в полной версии статьи на Хабре.

Microsoft майским Patch Tuesday закрыла 120 уязвимостей — 17 критических, 14 из которых позволяют удалённо выполнить код. Нулевых дней нет, но расслабляться рано.

По данным Anti-Malware от 13 мая 2026 года, в майском пакете обновлений Microsoft исправила 120 уязвимостей. Структура по типам: 61 — повышение привилегий, 31 — удалённое выполнение кода, 14 — раскрытие информации, 13 — подмена, 8 — отказ в обслуживании, 6 — обход защиты.

Отсутствие 0-day — хорошая новость. Плохая — три уязвимости из критических заслуживают отдельного внимания, и они не абстрактные.

Три CVE которые стоит закрыть первыми. CVE-2026-35421 — уязвимость в Windows GDI. Эксплуатируется через вредоносный EMF-файл, открытый в Microsoft Paint. Да, в Paint. Звучит несерьёзно, пока не вспоминаешь, сколько пользователей открывают вложения именно там.

CVE-2026-40365 — SharePoint Server. Аутентифицированный злоумышленник может удалённо выполнить код на сервере через сетевую атаку. Для корпоративной среды это прямой путь к данным и внутренним сервисам.

CVE-2026-41096 — Windows DNS Client. Контролируемый атакующим DNS-сервер отправляет специально сформированный ответ, вызывает повреждение памяти и добивается RCE. Вектор атаки — сетевой уровень, без какого-либо взаимодействия с пользователем.

Office и предпросмотр как вектор атаки. Отдельного внимания заслуживает пакет патчей для Microsoft Office, Word и Excel. Несколько закрытых уязвимостей позволяют выполнить код при открытии специально подготовленного файла. Часть атак срабатывает через панель предварительного просмотра — то есть файл даже не нужно открывать полностью.

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

• SharePoint Server — обновить приоритетно, особенно если он смотрит наружу или используется как интранет-портал

• Windows DNS Client — проверить, применились ли патчи на всех рабочих станциях и серверах в домене

• Office / Word / Excel — развернуть через WSUS или Intune без ожидания следующего окна обслуживания

• GDI / Paint — звучит как мелочь, но EMF-файлы гуляют в корпоративной почте чаще, чем кажется

120 уязвимостей за один цикл — это уже не исключение, а норма для Microsoft. Апрельский пакет был сопоставимым. Темп не снижается, и это означает одно: окно между выходом патча и его эксплуатацией в реальных атаках продолжает сжиматься. Кто не успел за 30 дней — играет в другую игру.

TG @CIOlogia

10 мая 2026 года OpenAI объявила Daybreak — связку GPT-5.5 и Codex, которая ищет уязвимости в репозитории, валидирует их в sandbox и предлагает патч в один клик.

GPT-5.5, вышедший 23 апреля 2026-го, стал первой моделью OpenAI, перешагнувшей порог «High» по кибервозможностям согласно собственному Preparedness Framework компании. Поверх него — Codex как агентный harness, который работает напрямую с кодовой базой. Вместе они и составляют Daybreak.

Три уровня доступа и один жёсткий порог. Базовый тир — GPT-5.5 для общих сценариев, без особых ограничений. Средний — Trusted Access for Cyber (TAC): secure code review, triage уязвимостей, анализ малвари, detection engineering, валидация патчей. К моменту анонса в TAC уже числились тысячи верифицированных одиночных защитников и сотни команд.

Верхний тир — GPT-5.5-Cyber, представленный 7 мая 2026-го. Это «cyber-permissive» вариант флагмана: не умнее, но менее склонен отказывать на запросы про крафт пейлоадов, воспроизведение эксплойтов в лабораторных условиях и реверс бинарей. Выдаётся точечно. С 1 июня 2026 года потребуется phishing-resistant аутентификация — OpenAI явно не хочет, чтобы этот SKU воспринимался как обычная подписка.

Что это даёт в реальном pipeline. Если стек уже завязан на Codex или ChatGPT Enterprise, Daybreak встраивает непрерывный security-loop прямо в CI/CD: модель строит threat-модель из репозитория, валидирует уязвимости в sandbox, генерирует патч через Codex. Для open-source мейнтейнеров OpenAI обещает pro bono сканирование — по аналогии с Aardvark в private beta осенью 2025-го, которая дала 10 CVE по итогам responsible disclosure.

Контекст запуска не случаен: IBM X-Force в 2026 году зафиксировал рост атак на публичные приложения на 44% год к году, CrowdStrike — рост активности AI-усиленных противников на 89%. Anthropic продвигает Claude Mythos с фокусом на безопасность, но без публичного доступа; Google — CodeMender; стартап XBOW занимает свою нишу. Daybreak при этом позиционируется как первый массово развёрнутый агент для defense-команд от ведущего AI-вендора.

Интереснее всего здесь не сама модель, а архитектурное решение: OpenAI разделила «умеет» и «разрешено» на уровне продуктовых тиров с верификацией личности. Это прецедент — раньше ограничения были только техническими (system prompt, фильтры). Теперь доступ к определённым возможностям привязан к идентификации пользователя. Насколько это удержит модель от злоупотреблений — покажет практика.

TG @CIOlogia

Представлен бесплатный сервис Filescan, который работает прямо в браузере и проверяет любой сайт или файл на вирусы:

• работает со всеми типами файлов, включая картинки, видео, apk и exe;

• запускает приложения в песочнице и смотрит на его поведение;

• ищет в сигнатуры вредоносных объектов и подозрительный код;

• при этом работает быстро — разбор задачи занимает несколько секунд;

Финдиректор видит два отчёта по выручке за один год: 150 млн в старой системе и 145 млн в новой CRM. Виноватыми назначают айтишников. Но проблема не в миграции.

Разрыв в 5 млн рублей между системами — классический симптом того, что я называю «иллюзией темпоральности». Суть простая: система хранит только последнее известное состояние данных, игнорируя то, что бизнес непрерывно меняется. Клиент переехал — адрес обновился, но старые сделки теперь «переехали» вместе с ним. Товар прошёл ребрендинг — и вся его история числится под новым названием. Итог: исторические отчёты перестают быть историческими.

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

Что такое SCD и почему это не академия. Slowly Changing Dimensions — методология, формализованная Ральфом Кимбаллом ещё в эпоху классических хранилищ данных. Она описывает стратегии того, как измерение (клиент, товар, сотрудник, регион) реагирует на изменение своих атрибутов. Выбор стратегии — архитектурное решение, которое определяет, можно ли будет восстановить состояние данных на любую дату в прошлом.

• Тип 0 — атрибут неизменен: дата рождения, дата открытия счёта. Никогда не перезаписывается.

• Тип 1 — перезапись: новое значение затирает старое. Подходит только для исправления ошибок ввода. Для реальных бизнес-изменений — гарантированный источник расхождений в отчётах.

• Тип 2 — добавление новой строки: текущая запись закрывается (проставляется дата окончания), создаётся новая с актуальными данными и датой начала. Именно это позволяет восстановить состояние на любой момент прошлого.

• Тип 3 — отдельный столбец для предыдущего значения: даёт сравнение «было/стало», но не полноценную историю.

• Тип 6 — гибрид (1+2+3): аналитики получают и текущий срез, и полную историю одновременно.

Почему Тип 2 — это не опция, а обязательство. В российских компаниях, которые сейчас массово мигрируют с SAP и других западных систем, именно SCD Тип 2 оказывается тем местом, где теряются данные и репутация IT-команды. Если при миграции применялся Тип 1 — вся историческая аналитика пересчиталась под текущее состояние справочников. Отсюда и расхождения, которые невозможно объяснить без понимания этой механики.

Тип 2 дороже в реализации: больше строк, сложнее запросы, нужны суррогатные ключи и поля effective_date / expiry_date. Но это единственный способ, при котором отчёт за прошлый год остаётся отчётом за прошлый год — независимо от того, что изменилось в справочниках после.

Для CIO это не вопрос технологий — это вопрос доверия к данным. Когда финдиректор видит расхождение в 5 млн, он теряет доверие к новой системе. Восстановить его потом значительно сложнее, чем заложить правильную архитектуру с самого начала. Миграционные проекты без явного решения по SCD — это отложенный конфликт между бизнесом и IT, который случится ровно в момент первого серьёзного аудита.

TG @CIOlogia

Лаборатория Касперского проверила 231 миллион паролей из даркнет-утечек 2023–2026 годов: 60% взламываются менее чем за час, почти половина — меньше чем за минуту.

Одна видеокарта RTX 5090 перебирает MD5-хеши со скоростью 220 миллиардов в секунду — на 34% быстрее, чем RTX 4090. Арендовать такую мощность в облаке можно за несколько долларов в час. Это уже не академическая атака — это промышленный процесс.

Цифры, которые неприятно читать. По данным SecurityLab, исследование Лаборатории Касперского разбивает 231 миллион паролей примерно так: 45% ломаются за минуту, ещё 15% — в пределах часа, и только 23% требуют больше года непрерывного перебора. Оставшиеся — где-то посередине. Три четверти паролей, которые люди считают «нормальными», не переживут рабочего дня атакующего.

Почему умные алгоритмы выигрывают у человека. Дело не только в железе. Современные инструменты взлома обучены на тех же утечках — они знают, что пользователи заменяют «a» на «@», добавляют год рождения в конец и ставят восклицательный знак, думая, что это хитро. Алгоритм проверяет эти паттерны первыми. Радужные таблицы с миллионами заранее посчитанных хешей — это вчерашний день; сегодня работают вероятностные модели, натренированные на реальном поведении людей.

Отдельная история — повторное использование паролей. Если один и тот же пароль стоит на трёх сервисах, взламывать ничего не нужно: достаточно найти его в одной утечке и прогнать по остальным. Credential stuffing — это не атака на пароль, это атака на человеческую лень.

Что реально помогает

• Менеджер паролей — единственный способ иметь уникальные длинные комбинации без боли. Хранить в браузере или заметках — примерно то же, что оставить ключ под ковриком.

• Длина важнее сложности. Случайная фраза из четырёх слов длиннее и энтропийнее, чем Pa$$w0rd123.

• Passkeys (ключи доступа) там, где сервис поддерживает — убирают пароль из уравнения вообще.

• TOTP-аутентификатор вместо SMS. SMS перехватывается через SS7 или SIM-swap; TOTP — нет.

Для корпоративного контекста добавлю: если у вас нет политики паролей с проверкой по базам утечек (HaveIBeenPwned API или аналог) и принудительного MFA на всех внешних точках входа — вопрос не в том, взломают ли, а в том, когда именно это уже произошло и вы просто не знаете.

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

TG @CIOlogia

За январь–апрель 2026 года число уникальных вредоносных образцов в атаках на российские компании выросло с 66 до 1174 — в 18 раз, по данным Positive Technologies. «Лаборатория Касперского» считает иначе: их аналитики зафиксировали уже более 2000 уникальных образцов среди наиболее активных группировок за тот же период.

Динамика по месяцам показательна: январь — 115 образцов, февраль — 247, март — 413, апрель — 399. Для сравнения: в марте 2025-го их было 8. Рост не постепенный — это резкий перелом с марта 2026-го.

Кто стоит за цифрами. Positive Technologies отслеживает 11 группировок, из которых четыре — PhaseShifters, Rare Werewolf, Hive0117 и PhantomCore — дали около 70% всех новых образцов. PhaseShifters бьёт по авиапрому и ОПК через фишинг с трояном Remcos — полный контроль над машиной, кейлоггер, доступ к данным. Rare Werewolf действует тоньше: разворачивает легитимный AnyDesk со вспомогательным скриптом, который автоматически подтверждает системные оповещения Windows и обходит предупреждения безопасности. Никакого «страшного» экзотического малвари — просто инструмент удалённого доступа, которому сама ОС говорит «ок».

По отраслям лидируют госучреждения (17,86% атак), финансовый сектор и НКО (по 9,82%), промышленность (8,04%). Аналитик Positive Technologies Денис Казаков называет главной причиной роста геополитику и «индустриализацию» разработки малвари: уязвимости, появившиеся в 2025-м, постепенно вошли в оборот, и теперь группировки штампуют новые образцы конвейерным методом.

Для меня как CIO здесь важнее всего не сама цифра «в 18 раз», а то, что Rare Werewolf работает через легитимный софт. Это означает, что сигнатурный антивирус промолчит, а SOC увидит «обычное» подключение AnyDesk — если вообще увидит. Контроль разрешённых инструментов удалённого доступа и мониторинг аномальных сессий сейчас важнее очередного обновления антивирусных баз.

Источники:

• Материал CNews со ссылкой на данные Positive Technologies и Kaspersky

TG @CIOlogia

SELECTOS OpenFix Day 2.0 стартует через час

В 19:00 (мск) мы начинаем митап для инженеров и системных администраторов. Ждем всех, кто не только разворачивает Linux в продакшене, но и читает исходники, гоняет ядро в дебаггере, отслеживает регрессии и закрывает CVE до того, как они становятся инцидентом. 

Программа митапа

• Итоги программы OpenFix и планы на будущее.

• Пластмассовый мир: что не так с ИИ-хайпом и как с этим жить.

• Как ИИ может помочь в управлении ОС.

• Как я ронял прод: конкурс инженерных факапов.

Подключайтесь

✔️ на YouTube

✔️ в VK

Вебинар Orion Private Cloud: частное облако с легким стартом и полным контролем затрат

Привет, Хабр!

Переход к облачной модели и построение частного облака в контуре компании — следующий этап развития ИТ-инфраструктуры после автоматизации базовых процессов.

27 мая в 11:00 мы проведем вебинар про Orion Private Cloud — первое в РФ модульное решение для построения облачной инфраструктуры с легким и экономически выгодным порогом входа.

В базовом составе нашего частного облака три продукта: серверную виртуализацию zVirt с SDN и SDS, платформу контейнеризации Nova с встроенной системой хранения секретов StarVault, слой управления Cloudlink с биллингом, мониторингом и аналитикой.

На вебинаре вместе с лидером Cloudlink Сергеем Мерещенко обсудим:

• Решение ключевых задач бизнеса: экономия и эффективность. Как сократить стоимость поддержки инфраструктуры и максимально эффективно использовать текущие мощности;

• Преимущества частного облака: ускорение запуска новых инициатив, усиление контроля затрат и переход к осознанному потреблению ресурсов;

• Ценность модульного подхода при построении частного облака.

А также проведем live-демо технологического стека Orion Private Cloud и ответим на все интересующие вас вопросы.

Для кого будет актуален вебинар:

• CIO и ИТ-директора

• Руководители направлений учета ресурсов / планирования мощностей

• ИТ-специалисты, отвечающие за развитие, экономику и безопасность ИТ-инфраструктуры

Присоединяйтесь по ссылке, чтобы узнать о техническом устройстве решения, его особенностях и результатах внедрения!

В файрволах Palo Alto Networks нашли критическую уязвимость, позволяющую получить root-доступ удалённо — без аутентификации.

Детали пока скупые: SecurityLab сообщает о захвате устройства через сеть, но ни CVE-номера, ни затронутых версий PAN-OS в открытом доступе пока нет. Это само по себе тревожный сигнал — либо патч ещё не готов, либо информацию придерживают намеренно, чтобы не дать атакующим готовый вектор до выхода исправления.

Для тех, кто держит периметр на PA-серии: Palo Alto — один из самых распространённых enterprise-файрволов в российских корпоративных сетях, особенно в компаниях, которые ещё не завершили импортозамещение. Root на файрволе — это не просто «дыра в защите». Это полный контроль над трафиком, возможность отключить сегментацию сети, обойти политики и получить плацдарм для горизонтального движения внутри инфраструктуры.

Что стоит сделать прямо сейчас. Проверить, торчит ли management-интерфейс вашего Palo Alto в интернет (он не должен). Подписаться на security advisories от Palo Alto Networks напрямую — они публикуют бюллетени на security.paloaltonetworks.com раньше, чем новость доходит до агрегаторов. И следить за обновлением: как только выйдет патч с CVE — ставить без раздумий.

Файрвол с root-уязвимостью на периметре — это уже не файрвол, а открытая дверь с охранником, который работает на другую сторону.

Источники:

• SecurityLab: уязвимость в файрволах Palo Alto

TG @CIOlogia

Отменили разработчиков и пришли за DevOps'ами. Инженеры — всё!

Раньше увольняли кодеров, теперь у микрофона сисадмины

Coder - больше не профессия. Не верите? Cursor, Claude Code, OpenCode уже закрывают вакансии middle-разработчиков быстрее, чем HR успевают постить новые. Кто не верил - уже сидит с гитбуком в одной руке и резюме в другой.

Но была одна святая группа. Люди, которые смотрели на эту вакханалию и говорили: "Ну, нас-то ИИ не заменит. Сервера сами себя не настраивают, прод сами себя не поднимает. У кого рука на пульсе - у того работа есть".

Знакомо? Я тоже так думал.

До вчерашнего дня.

Встречайте: ваш новый коллега - ничего

Пять дней назад Alibaba Cloud выкатил v1.1.0 своего open-source проекта HiClaw. Если кратко - это оператор для AI-агентов на Kubernetes. Агентская команда, которая живёт в Matrix-чате. Ты видишь их переписку, @ упоминаешь, даёшь задачи.

И в этой команде появился новый участник.

Hermes Worker.

Не человек. Не "помощник". Полноценный DevOps-инженер с terminal-песочницей, который: - Лезит в кластер - Смотрит логи - Чинит конфиги - Пишет постмортемы

Сам. Без approvals. В YOLO-mode.

Раньше ты говорил: "У меня мониторинг в 3 ночи - поднимаюсь, лезу в прод, чиню, я незаменим, ваша говношаражка без меня умерла бы давно". Теперь мониторинг пошлёт алерт Hermes Worker-у, тот лезет в кластер, смотрит логи, чинит, пишет постмортем и уходит в спящий режим. Ты узнаёшь об инциденте из утреннего дайджеста в Matrix.

"Ну, это просто автоматизация рутинных операций", - скажете вы. Ага. Cursor тоже начинали с автодополнения скобочек.

Что конкретно произошло

HiClaw работает так: есть Controller (на Go), который через CRD управляет Worker/Team/Manager/Human ресурсами. Вся команда сидит в Matrix-чате. Manager декомпозирует задачу, воркеры исполняют. Ты @упоминаешь, корректируешь, аппрувишь стратегию.

В v1.1.0 добавили Hermes Worker Runtime - first-class сорт воркера наравне с Node.js и QwenPaw.

Чем он отличается: - Node.js Worker - болтает и дёргает тулы - QwenPaw (Python) - инструменты и скрипты - Hermes Worker - автономный программирующий оператор. Сам планирует, исполняет, итерирует

То есть если Manager говорит "нужна диагностика пода в namespce prod, причина OOMKill", Hermes Worker сам: заходит в кластер → смотрит grafana → чекает лимиты → пересчитывает requests/limits → перекатывает деплой → пишет что сделал.

В 3 часа ночи. Без тебя.

Это ещё не всё

• Helm Chart с Leader Election, RBAC, PVC - enterprise-ready

• Provider-интерфейсы для storage - MinIO, S3, OSS - не надо переписывать контроллер

• Multi-container architecture - Manager больше не тащит Higress+Tuwunel+MinIO+Element в одном образе на 1.7 GB. Инфраструктура вынесена в Controller.

• Worker lifecycle - сам засыпает при простое, просыпается по запросу

• Авто-миграция - старые конфиги сами переезжают в CRD

Всё это open-source (Apache 2.0). Ставится одной строкой:

curl -sSL https://higress.ai/hiclaw/install.sh

А что с российскими реалиями?

С одной стороны - open-source. Форкнул, поставил через Selectel/k3s, LLM заменил на GigaChat/YandexGPT через Higress Gateway. Данные никуда не уходят.

С другой стороны - вы серьёзно думаете, что ваш enterprise с 15 согласованиями на любой чих готов отдать прод AI-агенту? Даже если он пишет постмортемы?

Хотя... если Manager будет сидеть в Matrix-комнате, где ИБ видит каждый чих - почему нет? Прозрачность операций - единственный аргумент, который может продать эту архитектуру в enterprise.

И чо теперь?

Варианта два.

Первый: сделать вид, что это очередной хайп, который не дойдёт до продакшна. Написать коммент "В наше то время все руками делали, где скрепы? Риск: 4.4k звезд на GitHub, 519 форков, 9 контрибьюторов в релизе, код на Go (не очередной Python-прототип). Не похоже на pet project.

Второй: принять, что DevOps как ниша "я один знаю как чинить этот кластер" - умирает. Hermes Worker не заменит инженера, который придумывает архитектуру. Но он заменит инженера, который в 3 ночи заходит по SSH и чинит конфиг.

Вопрос не в том, заменят ли тебя. Вопрос в том, когда.

Сервис Your IP Security & Privacy Audit проверяет подключение пользователя на предмет утечек, а также на безопасность сетевого соединения. Решение просматривает: IP, утечку гео и WebRTC, DNS, чёрный список IP-адресов, цифровые отпечатки в браузере.

Opensource-зависимости стали одним из главных векторов атак на цепочки поставок — и это уже не теория. Positive Technologies обновили PT Fusion до версии 1.7: теперь в нём появились фиды от PT Supply Chain Security с данными о вредоносных, протестных и удалённых релизах опенсорс-проектов. Формат — OSV, стандартный для ИБ-сообщества.

Что за угрозы они покрывают. Речь о трёх категориях: пакеты с намеренно внедрённым вредоносным кодом, «протестные» релизы (когда мейнтейнер что-то встраивает из политических или личных соображений — как было с colors.js или node-ipc) и заброшенные проекты, которые никто больше не патчит. Последнее — особенно коварно: уязвимость может существовать годами, и никто её не закроет.

Где это применимо. Фиды грузятся в SCA-инструменты, dependency firewall и реестры артефактов. Отдельный сценарий — ретроспективный forensics: при расследовании инцидента можно проверить, не было ли скомпрометированной зависимости на конечных устройствах. Это меняет SCA из «проверки перед деплоем» в непрерывный мониторинг.

Для компаний, где разработка использует опенсорс (а это почти все), вопрос уже не «нужен ли нам контроль зависимостей», а «насколько актуальна наша база данных угроз». Фиды в PT Fusion обновляются регулярно — это важнее самого факта их наличия.

Источники:

• Новость CNews о PT Fusion 1.7

TG @CIOlogia

4 мая Microsoft подтвердила: Defender с обновлением сигнатур от 30 апреля начал детектировать легитимные корневые сертификаты DigiCert как Trojan:Win32/Cerdigent.A!dha — и в ряде случаев не просто предупреждал, а удалял их из хранилища доверенных корневых сертификатов Windows.

Под удар попали два конкретных сертификата (`0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43` и DDFB16CD4931C973A2037D3FC83A4D7D775D05E4), которые вырезались прямо из ветки реестра HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\. Часть пользователей, не разобравшись, переустанавливала Windows — решив, что машина реально заражена.

Что произошло на самом деле. Defender оперативно добавил правила обнаружения после инцидента у DigiCert: злоумышленники атаковали сотрудника поддержки через вредоносный ZIP под видом скриншота, получили действительные сертификаты и использовали их для подписи малвари — в том числе компонентов кампании Zhong Stealer. DigiCert отозвала 60 сертификатов. Логика детекта сработала, но зацепила слишком широко — накрыв заодно и легитимные корневые.

Проблема исправлена в Security Intelligence 1.449.430.0 и новее. Свежее обновление также восстанавливает ранее удалённые сертификаты — дополнительных ручных действий Microsoft не требует.

Для меня как CIO этот инцидент — хорошая иллюстрация того, насколько хрупкой может оказаться цепочка доверия к сертификатам. Один взломанный сотрудник поддержки у CA, несколько выданных сертификатов — и антивирус крупнейшего вендора начинает «лечить» легитимную инфраструктуру. Если у вас есть системы, критически зависящие от конкретных корневых сертификатов (VPN, внутренние PKI, подписанные агенты мониторинга), стоит проверить, не прилетело ли обновление сигнатур незаметно в нерабочее время и не унесло ли что-нибудь с собой.

Источники:

• Разбор инцидента на Anti-Malware.ru

TG @CIOlogia