Архив рубрики: Темы

Про Linux-ы хорошо заходит

Про Linux-ы хорошо заходит. 🙂 К предыдущему посту набралось много комментариев в VK. К сожалению, у меня создалось такое впечатление, что со многими комментаторами мы не сошлись во мнении из-за того, что писали о разных вещах. Поэтому ещё раз переформулирую почему я считаю, что свободный бесплатный базовый российский Linux дистрибутив нам нужен и делать его видимо лучше независимо от существующих вендоров коммерческих Linux дистрибутивов.

Я на это дело смотрю несколько со стороны. Я не CTO, не системный архитектор и даже не сисадмин. Я безопасник. Мне так-то все равно на чем строится инфраструктура. Не считаю выбор конкретных решений своей зоной ответственности. Хоть на Windows, хоть на Linux платном или бесплатном, хоть на BSD, хоть на AIX и HPUX, хоть на KasperskyOS. Я могу что-то там высказать со своей колокольни, но бизнесу и IT безусловно виднее. Моё дело разбираться как контролировать уязвимости для всего этого безобразия, как его обновлять и харденить. Есть бюллетени безопасности? Класс. Они ещё и в машиночитаемом виде? Супер! Поддерживается сканером уязвимостей? Совсем здорово!

Вместе с тем сложно не замечать тот факт, что инфраструктура больших российских (и естественно не только российских) компаний в настоящий момент по большей части состоит из Linux серверов как железных, так и виртуальных. И используемые Linux дистрибутивы по большей части бесплатные. То есть это как раз-таки Debian, CentOS (Alma/Rocky), Ubuntu. Вопрос в следующем: а на что будут заменяться конкретно эти сервера к 2025 году? Такой конкретный вопрос, остальное импортозамещение в расчет не берем.

И тут видятся следующие варианты:

1. Они вообще не будут заменяться. И тогда зависимость от, по факту, западных решений останется с понятными рисками. И регулятору в виде ФСТЭК такой вариант видимо не особо нравится, см. предыдущий пост про Методику оценки критичности уязвимостей, а конкретно про тестирование патчей для опенсурса.
2. Они будут заменяться на отечественные коммерческие сертифицированные Linux-ы со $100 за лицензию. Про сто баксов это условно, т.к. там есть конкуренция (пока) и на объемах в тысячи и десятки тысяч хостов стоимость будет пониже. Но в любом случае дополнительные затраты будут ощутимые. И это будет уже не вполне тот Linux, который мы любим, ценим и везде используем, в том числе, и из-за возможности за лицензию не платить и разворачивать столько хостов, сколько потребуется.
3. Они будут заменены бесплатным отечественным базовым Linux дистрибутивом. Как раз-таки аналогом "Debian, CentOS (Alma/Rocky), Ubuntu" в том числе и по свободности и бесплатности, но разрабатываемым в России и контролируемым из России. Могут ли российские вендоры коммерческих Linux-ов сделать и поддерживать такой дистриб, включив его в реестр российского ПО, чтобы у компаний и частных лиц была такая опция для импортозамещения? Да конечно могут. Легко! А делают они это? Нет, потому что зачем вредить своему основному бизнесу на торговле лицензиями. Если я здесь не прав и такой вендор и дистриб есть, то назовите его и "свободный бесплатный базовый российский Linux дистрибутив" это будет вот он, сам же буду за него ратовать.

Но пока выглядит, что у государства один интерес - максимально снизить зависимость в том числе от "Debian, CentOS (Alma/Rocky), Ubuntu". А у существующих вендоров коммерческих Linux-ов другой - заработать и выжить на конкурентном рынке. Интересы и цели разные.

Поэтому и приходят в голову идеи, что заниматься разработкой и поддержкой бесплатного базового Linux дистрибутива должны вообще не они, а крупные российские окологосударственные IT компании в интересах государства. Но что-то каких подвижек в эту сторону не видно и по всей видимости будет реализовываться либо вариант 1, либо вариант 2, что мне не особо нравится… Но опять же, см. второй абзац этого поста. 🙂

На эту тему можно ещё посмотреть в контексте контейнеризации, но об этом как-нибудь в следующий раз.

Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"

Прочитал Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средствПрочитал Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств

Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"

Кто-то может подумать из названия, что это наверное про CVSS. И будет отчасти прав. CVSS v3.0/3.1 это один из компонентов итоговой цифири. Причем не только Base Score. "Итоговый показатель I cvss определяется совокупностью показателей базовых, временных и контекстных метрик применительно к конкретной информационной системе". И все кроме базовых придется накликивать самим. Даже этого было бы достаточно для веселья. Но…

Есть ещё второй компонент "характеризующий влияние уязвимости … на функционирование информационной системы". 🙂 Там про тип уязвимого актива, массовость уязвимости, доступность через Интернет.

В зависимости от итогового значения выдвигаются требования по оперативности исправления. И там есть связь со вторым документом про тестирование обновлений:

"3.4. В случае если уязвимости содержатся в зарубежных программных, программно-аппаратных средствах или программном обеспечении с открытым исходным кодом, решение об установке обновления такого программного обеспечения, программно-аппаратного средства принимается оператором информационной системы с учетом результатов тестирования этого обновления, проведенного в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств, утвержденной ФСТЭК России от 28 октября 2022 г., и оценки ущерба от нарушения функционирования информационной системы по результатам установки обновления."

А уж какое там веселье. Ммм… 🙂 Но это как-нибудь в следующий раз.

Какие впечатления:
1. Методика это хорошо. Стандартизация от регулятора должна быть. Описано все просто и понятно.
2. Дополнительные критерии помимо CVSS это хорошо, критерии связанные с инфраструктурой выглядят в целом адекватно.
3. Не увидел учета такого важнейшего фактора как признак Exploitation in the wild. Когда я делаю приоритизацию с помощью своего проекта Vulristics наличие публичного эксплоита и признаков эксплуатации вживую играет наибольшую роль. Если наличие эксплоита ещё как-то учитывается (но кажется недостаточно) в CVSS Temporal Metrics, то эксплуатация вживую не отражена совсем. Кстати, давно уже пора делать наш аналог CISA Known Exploited Vulnerabilities Catalog.
4. Не увидел учет типа уязвимости. Когда я приоритизирую в Vulristics тип уязвимости также играет важную роль. Можно сказать, что тип уязвимости опосредованно учитывается в CVSS, но кажется этого также недостаточно.
5. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐

Благодаря ФСТЭКу будет что почитать в выходные непосредственно по нашей теме

Благодаря ФСТЭКу будет что почитать в выходные непосредственно по нашей теме. 🙂👍

1. Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
2. Методика тестирования обновлений безопасности программных, программно-аппаратных средств

В середине июля я принял участие в записи подкаста ЛК "Смени пароль!"

В середине июля я принял участие в записи подкаста ЛК Смени пароль!

В середине июля я принял участие в записи подкаста ЛК "Смени пароль!".

"Сколько проработает импортное «железо» без обновлений? Как выявлять вредоносные закладки в софте? Что нужней для создания безопасного кода – хакерские конкурсы или научное проектирование? Продолжаем обсуждать главные проблемы года с ИБ-экспертами из разных компаний. В этом выпуске свои истории рассказывают Алексей Лукацкий (Positive Technologies), Александр Леонов («Тинькофф»), Алексей Марков («Эшелон»), Николай Клендар (Home Credit Bank), Александр Бондаренко (R-Vision) и Пётр Девянин («Русбитех-Астра»)."

Я рассказывал про оценку стабильности вендоров, исправление уязвимостей в продуктах нестабильных вендоров и алгоритм НКЦКИ, про зачастую разный mindset у безопасников и админов. С 14:50. За 3 месяца тренд на вынос западных решений только усилился и есть надежда, что возврат к нормальному VM-процессу с доверием используемым вендорам совершится несколько раньше, чем можно было предполагать.

Что касается уязвимостей OpenSSL, которые многие так ждали 1 ноября

Что касается уязвимостей OpenSSL, которые многие так ждали 1 ноября. Обе уязвимости "переполнение буфера" (CVE-2022-3786, CVE-2022-3602).

Лучше всего процитировать блог Rapid7:

"Другими словами, возможности эксплуатации значительно ограничены:

- В случае, когда целью является сервер (веб-сервер, сервер базы данных, почтовый сервер и т.д.): сервер должен сначала запросить аутентификацию клиента как часть взаимной аутентификации. Такую конфигурацию распространенной не назовешь, но в особо критичных системах встречается.
- В случае, когда целью является клиент (веб-браузер, программа для чтения электронной почты, коннектор для базы данных и т.д.): злоумышленнику необходимо сначала заставить уязвимого клиента подключиться к вредоносному серверу. Можно выдать себя за другое лицо (MitM, захват существующего ресурса и т.д.) или убедить человека щелкнуть ссылку (через фишинг, "атаку на водопое" и т.д.).

В обоих сценариях такие атаки вряд ли будут широко использоваться злоумышленниками".

Те кто последнюю видяшку посмотрели, могли заметить, что качество картинки стало получше

Те кто последнюю видяшку посмотрели, могли заметить, что качество картинки стало получше. Особенно если 1440р выбрать. Это потому, что я поправил техпроцесс. В первую очередь отказался от OpenShot, который непонятно почему портил качество скриншотов. Сами скриншоты я делаю в Firefox в довольно высоком разрешении ~ 8424x4384 пикселей. Поэтому получать в итоговой видяшке мыло было очень обидно. Перепробовал несколько альтернативных редакторов. Ничего не понравилось. Тяжеловесные, глючные, ориентированные на ручное редактирование. Явно не оптимальный инструмент для моих задач.

В итоге вообще отказался от каких-либо видео-редакторов, а сделал свою обвязку из ffmpeg и ImageMagick.

Видео генерится из такого описания:

00:00:00.000|Screen Shot 2022-10-29 at 00.41.17.png|Intro
00:00:12.673|Screen Shot 2022-10-29 at 00.41.43.png|Vulristics
00:00:17.578|Screen Shot 2022-10-29 at 00.42.00.png|Vulristics script output
00:00:21.839|Screen Shot 2022-10-29 at 00.42.15.png|Vulnerability statistics
00:00:28.362|Screen Shot 2022-10-29 at 00.43.11.png|RCE Exchange blog
00:00:35.737|Screen Shot 2022-10-29 at 00.44.34.png|RCE Exchange First RCE Vulristics report
00:00:40.379|Screen Shot 2022-10-29 at 00.44.22.png|RCE Exchange Second RCE Vulristics report

Первая колонка это таймстемп, когда начинает показываться картинка из второй колонки. Третья колонка это просто коммент для удобства. Таймстемпы с точностью до миллисекунды смотрю в аудиодорожке в Audacity.

Основное время уходит на конвертацию скриншотов под нужный размер ImageMagick-ом. Сейчас подгоняю под 2560X1440. 22 скриншота обрабатываются на моем ноуте минут 5. Непосредственная сборка видео из скриншотов и совмещение с аудиодорожкой занимает буквально секунды. Пятиминутный ролик в 1440р занимает всего 25 мб. Для сравнения OpenShot генерил такой же по времени ролик минут 15-20, получается файл в 350 мб ещё и в худшем качестве.

Пробовал генерить и в 3840X2160, и 7680X4320. Тоже вполне реально, только предобработка скриншотов занимает подольше. Но такие ролики уже некорректно отображаются у меня медиаплеером на ноуте, поэтому пока остановился на 2560X1440. 😅

Как считаете, есть смысл причесать и оформить код и выложить как опенсурсный проект? Или и так все понятно и тривиально? Полайкайте плз, если оно надо.

Выпустил отчет по октябрьскому Microsoft Patch Tuesday

Выпустил отчет по октябрьскому Microsoft Patch Tuesday. В календарные сроки уложился. 😅

На самом деле не особо интересный месяц. По #ProxyNotShell Remote Code Execution – Microsoft Exchange (CVE-2022-41040, CVE-2022-41082) все ещё ждем патчей. Общевиндовая Elevation of Privilege - Windows COM+ Event System Service (CVE-2022-41033) вроде активно эксплуатируется, но пока не ясно кем и как именно. Остальное всё такое себе, средненькое. Подробнее в блогпосте.