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

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям

1 комментарий

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям

Nucleus Security нарисовали красивую картинку по CISA KEV уязвимостям. Навели статистику по вендорам. К статистике наведенной по всем уязвимостям из NVD я отношусь обычно скептически - непонятно то ли у вендора такие дырявые продукты, то ли вендор наоборот ответственно подходит к уязвимостям в своих продуктах и заводит CVE на каждый чих. Здесь же рассматриваются только уязвимости с признаками эксплуатации в реальных атаках, просто так в CISA KEV не попадают. Поэтому вполне справедливо будет сделать вывод: если у вас инфраструктура на продуктах Microsoft, то уровень риска у вас соответствует этому громадному кружку, а если на Linux, то гораздо меньшему кружку (его так сразу и не заметишь). Выпиливайте у себя Microsoft! Хотя бы стратегически двигайтесь в этом направлении. Тоже касается и других больших кружков: CISCO, Apple, Oracle, Adobe. Google выпилить скорее всего не получится - это вездесущий Chromium. 🙂

Три установки после исхода западных вендоров

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

Три установки после исхода западных вендоров. Предыдущий пост про судьбу специалиста был, разумеется, и про меня тоже. Мне было вполне комфортно работать с западными VM-решениями и писать об этом в своём бложике. Не могу сказать, что исход западных вендоров меня порадовал. Но, с другой стороны, я не был ультрасфокусированным специалистом по Qualys, Tenable и Microsoft Defender, поэтому какой-то катастрофой для меня это не стало. Но заставило призадуматься. В итоге я сформулировал для себя 3 установки, которые выглядят полезными в сложившихся условиях. Возможно они кому-то ещё придутся по вкусу.

1. Специализироваться не на конкретных технических решениях от конкретных вендоров, а на проблеме в целом. Как можно лучше понимать что именно происходит под капотом решений и как, при необходимости, обходиться без них. В контексте нашей темы - как происходит детект уязвимостей в каждой из систем, какие есть тонкости, что и как можно было бы улучшить. Вендоры приходят и уходят, а проблемы остаются.

2. Фокусироваться на Open Source проектах, в особенности на GNU/Linux. Здесь есть несколько моментов:

2.1. Мы во многом утратили или утратим в ближайшем будущем доступ к проприетарным западным решениям. Но вот доступ к Open Source останется, этого у нас никто не отберёт. Несмотря на попытки ограничить возможности контрибьютить код и вести свои проекты, эффективных механизмов препятствовать этому также нет. Поэтому для российского специалиста активная самореализация в Open Source проектах это логичный путь для приобретения скиллов актуальных в общемировом масштабе.

2.2. Open Source это основа российского импортозамещения. Практически все российские ОС это Linux, отечественных IT/ИБ продуктов без использования открытых библиотек также не бывает. Можно долго спорить на тему оправдано ли называть отечественным то, что в основном разрабатывается где-то в Калифорнии. Имхо, это довольно скверно, но может быть в какой-то степени скомпенсировано вовлечённостью в эти проекты российских специалистов как со стороны разработки, так и со стороны использования. Безусловно история успеха здесь проект PostgreSQL. Если появятся эффективные центры компетенций по ключевым открытым компонентам, то возможно появятся и шансы "перевернуть игру", и уже в США будут переживать по поводу российская влияния на Open Source. А если не появятся, хотя бы несколько снизим свои риски в процессе. 😉

3. Относиться к российским коммерческим решениям с "презумпцией крутости". Если не доказано, что продукт полностью неработоспособен и это явное мошенничество, считать российский продукт крутым. 🙂 Я не согласен с бесконечной критикой российских продуктов, что они стоят дороже и при этом менее функциональны. Вернее да, это так, они действительно часто дороже и менее функциональны. 😅 Но критиковать их за это также бессмысленно как возмущаться тем, что за летом приходит зима. Здесь сошлюсь на уморительный пост Рустэма Хайретдинова про первое свидание и сальто назад на коньках. 😆 Наши вендоры зачастую стартуют с нуля, имея в сотни и тысячи раз меньше ресурсов, чем западные. У них нет возможности демпинговать и работать на перспективу, им нужно выживать и развиваться здесь и сейчас. И при этом они умудряются производить что-то сопоставимое с западными решениями. Это ли не чудо! В целом, считаю, что нам к российским ИБ-вендорам, особенно к стартапам, нужно относиться как в Израиле относятся к своим. Холить, лелеять, гордиться, нахваливать и оказывать всяческое содействие. Ну возможно делать это чуть менее энергично, все же у нас несколько иная стилистика. Но ни в коем случае не хаить их за то, что они не top-notch за копейки.

О возможной принудительной предустановке отечественных ОС на импортируемые ноутбуки и ПК

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

О возможной принудительной предустановке отечественных ОС на импортируемые ноутбуки и ПК. Сообщает нам Ъ со ссылкой на источник в правительстве. Якобы это инициатива Минцифры и обязанность делать предустановку возложат на ритейлеров. Если предположить, что так и будет, хорошо ли это? Смотря кому.

1. Вендорам отечественных ОС хорошо, т.к. дополнительный доход от OEM лицензий.

2. Государству хорошо, т.к. это поддержка вендоров отечественных ОС, которая не требует бюджетных вливаний. Теоретически может несколько уменьшиться доля западных ОС и зависимость от них.

3. Ритейлу плохо. На них ляжет дополнительная работа по предустановке, тестированию совместимости и т.п. Что делать с устройствами, на которые нельзя поставить отечественную ОС (читай: Apple)? Это фактический запрет на их продажу? Если да, то продажи таких устройств уйдут в тень, если нет, то будет ли действенна эта мера?

4. Пользователям нейтрально-плохо. Ритейлеры свои дополнительные затраты включат в цену устройств. Каким-то пользователям предустановленная ОС может и зайдет. Почта есть, браузер с соцсеточками и ютубом тоже есть - ну и норм. 🙂 Но, думаю, абсолютное большинство будет на свежекупленное устройства тут же ставить Windows. Лицензионный или не очень. Возможно как доп. услугу у того же ритейлера.

В целом, как мера поддержки отечественных Linux вендоров это выглядит неплохо, но сама по себе это мера расклад по используемым в РФ операционным системам вряд ли изменит. Чтобы снизить долю macOS и Windows нужно прежде всего осознать это как серьёзную проблему и начать это недвусмысленно транслировать. Пока прямых заявлений, что Microsoft и Apple нам вражины и нужно отказываться от использования их продуктов насколько это возможно, я лично не видел. А без этого сложно объяснить конечным пользователям почему им нужно перестать использовать то, что удобно и привычно, и начать вдруг пользоваться тем, что непривычно и менее функционально.

Платные обновления безопасности для актуальных версий Ubuntu

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

Платные обновления безопасности для актуальных версий Ubuntu

Платные обновления безопасности для актуальных версий Ubuntu. Рекомендации в бюллетенях Ubuntu поставить ESM (Expanded Security Maintenance) версий пакетов доступные с платной подпиской это дело обычное. Как правило, это касается End of Life (EOL) версий Ubuntu. С 30 апреля EOL будут все версии ниже Ubuntu 18.04 (Bionic Beaver) включительно. Всё честно. Обновитесь на новую версию дистриба, будут вам безопасные версии пакетов, не можете - платите.

С появлением подписки Ubuntu Pro стало интереснее. Вот 2 USN бюллетеня с ESM пакетами для Ubuntu 20.04 (EOL Apr 2030):

USN-5273-1: RPM Package Manager vulnerabilities
USN-5160-1: Midnight Commander vulnerability

Пишут, что эти обновления доп. фича и без Ubuntu Pro их бы вообще не было - радуйтесь. По факту это значит, уязвимость в пакете из репозитория есть (тот же Scanvus продетектит), версия дистриба актуальная, исправить уязвимость без платной подписки нельзя. А Canonical подписки компаниям из РФ не продает. 🤷‍♂️

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций

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

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций. Baikal Electronics проектирует процессоры и системы на кристалле с архитектурой MIPS и ARM. Компания находится под санкциями США, ЕС и ряда других стран.

"Нам некомфортно принимать патчи от вашей организации или относящиеся к hardware произведенному вашей организацией.

Пожалуйста, приостановите networking contributions до дальнейшего уведомления."

В предложенных патчах для сетевого драйвера stmmac была реализована поддержка GMAC и X-GMAC SoC Baikal, предложены общие исправления для упрощения кода драйвера.

Предсказуемо. Опенсурс-опенсурсом, а Linux Foundation это конкретная американская организация. Как и банящий разработчиков GitHub это Microsoft. Понятно каким регуляциям они подчиняются.

Поэтому ядро Linux должно быть своё. Например, от ИСП РАН. И репозитории должны быть свои. И дистрибутивы Linux. Это породит дополнительную фрагментацию и несовместимость, но это выглядит как неизбежные издержки.

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux

2 комментария

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux. Продолжаю обозревать крутые штуки от ФСТЭК.

У меня в декабре был пост, что если бы я был регулятор, то обязал бы вендоров сертифицированных Linux-ов привести в порядок бюллетени безопасности, а идеально было бы OVAL контент предоставлять. Так как это делает RedOS. И в каком-то виде это осуществилось. 🤩 Ну не силами Linux-вендоров, а силами ИБ-вендора и регулятора. И с существенными ограничениями. Но факт - вот тебе OVAL-контент для сертифицированных Linux-ов в паблике и бесплатный сканер, который с ним работает.

На сайте ФСТЭК-а выложили бесплатный локальный сканер уязвимостей ScanOVAL в версиях под Linux (раньше был только под Windows). И OVAL-контент к нему. В трёх вариантах:

1. ScanOVAL для ОС Astra Linux 1.6 SE - тестовая версия сканера и OVAL-контент
2. ScanOVAL для ОС Альт 9 - тестовая версия сканера и OVAL-контент
3. ScanOVAL для ОС Роса «Кобальт» - тестовая версия сканера (OVAL-контент пока недоступен)

ScanOVAL это, конечно, не вполне полноценный сканер. Он может сканировать только локалхост. Штатно запускается только в графическом режиме. Т.е. использовать его, чтобы вручную валидировать уязвимости на хостах получится, а приспособить для регулярного сканирования всей инфры скорее всего нет. Понятно зачем сделано, этот продукт не должен рушить бизнес VM-вендорам.

Другой вопрос, который естественно возникает, когда видишь OVAL-контент в паблике, а можно ли его использовать не в составе ScanOVAL? 😏 Например, OpenSCAP-у скормить, свой OVAL сканер написать или интерпретировать во что-нибудь? Ответ: технически реально, а юридически нельзя, т.к. EULA для ScanOVAL это отдельно оговаривает:

"Не допускается осуществлять следующие действия:
…
использовать ПО и (или) описания проверок (включая любые их фрагменты), применяемые в ее составе, с целью создания баз данных или кода, предназначенных для предотвращения угроз безопасности информации;
публиковать, а также распространять от своего имени любые фрагменты описаний проверок, применяемых в составе ПО;
…"

Тоже понятно почему. Идентификаторы дефинишенов, такие как "oval:ru.altx-soft.nix:def:156318", не оставляют сомнений в происхождении контента и понятно, что рушить свой бизнес коммерческому VM вендору совсем не нужно.

Поэтому,
1. Круто, что появилась возможность сканировать сертифицированные отечественные Linux-ы бесплатным решением. Даже если использовать его только в ручном режиме как эталонный сканер, это более чем полезно.
2. Потребность в OVAL-контенте (или просто бюллетенях хотя бы) от Linux-вендора это не снимает, т.к. EULA конечно полноценно использовать контент для ScanOVAL не позволяет, к сожалению.

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК

2 комментария

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК. Что? 😳 ДА! 🎉Теперь можно ссылаться не на CIS, не на DISA STIGs, не на BSI IT-Grundschutz, а на технические требования нашего отечественного регулятора. Ну круть же! Скачать можно на сайте ФСТЭК.

1. Документ очень компактный, всего 7 страниц. CIS Benchmark для Ubuntu Linux 20.04 LTS, для сравнения, занимает 531 страницу.
2. Рекомендации подлежат реализации в государственных информационных системах (ГИС) и на объектах критической информационной инфраструктуры (КИИ).
3. Рекомендации распространяются на настройку НЕсертифицированных ОС (как раз Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Т.е. мейнстримные Linux дистрибутивы из КИИ и ГИС придется выносить, если они есть. Сертифицированные же Linux-ы должны настраиваться "в соответствии с эксплуатационной документацией разработчиков".
4. Рекомендации касаются именно настройки. Пример: "2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH путём установки для параметра PermitRootLogin значения no в файле /etc/ssh/sshd_config." Как проверять не расписывается.
5. Сложность реализации настроек и проверок соответствия по пунктам из этих рекомендаций зависит от конкретности рекомендаций. Часть рекомендаций выглядят достаточно конкретными, часть нет, например "2.3.8. Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путём анализа корректности прав доступа к утилитам и системным библиотекам, расположенным по стандартным путям (, /usr/bin, , и другим путям), а также к модулям ядра (для Linux: /lib/modules/версия-текущего-ядра)". Понятно, что конкретные настройки могут зависеть от конкретного дистрибутива, но все же хотелось бы большей однозначности, что нужно делать.
6. В некоторых пунктах приводится обоснование зачем это настройка нужна, например "в противном случае это может привести к выполнению произвольного кода от имени владельца задания cron". Но для большей части рекомендаций этого нет. А тоже хотелось бы.

Блоки рекомендаций:
1. Настройка авторизации в операционной системе.
2. Ограничение механизмов получения привилегий.
3. Настройка прав доступа к объектам файловой системы.
4. Настройка механизмов защиты ядра Linux.
5. Уменьшение периметра атаки ядра Linux.
6. Настройка средств защиты пользовательского пространства со стороны ядра Linux.

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