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

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

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

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

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.

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

Занятно конечно жизнь складывается: кто бы мог подумать, ещё года 2 назад, что пресловутый анекдотический "виндекапец" (как впрочем и "макокапец") станет ощутимо вырисовываться в отдельно взятой стране? 🤩

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

Занятно конечно жизнь складывается: кто бы мог подумать, ещё года 2 назад, что пресловутый анекдотический "виндекапец" (как впрочем и "макокапец") станет ощутимо вырисовываться в отдельно взятой стране? 🤩 Что, например, российские ИБ вендоры судорожно кинутся пилить поддержку Linux серверов и Linux десктопов (!), потому что именно это теперь перспективная инфра. А то, что десятки лет было стандартом де-факто в корпоративной среде превратится в legacy, которое здесь и сейчас ещё поработает, но на горизонте 2025-2030 вряд ли от него хоть что-то ещё останется. Просто ух! 🙂

Мне как ИБшнику с бэкграундом именно в *nix безопасности наблюдать это, безусловно, отрадно. 😇 Конечно, если бы западные ОС вендоры начали сейчас жестить, резать обновления, а то и брикать устройства, то переход прошел бы гораздо быстрее, хоть и в авральном режиме. Видимо у этих вендоров свои причины пока не вести себя так. Хотя в том, что этот процесс идёт достаточно медленно тоже есть плюс, т.к. есть время провести миграцию на Linux нежно и аккуратно, с наименьшим стрессом для всех участвующих. 😏

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

Отличные новости по моему опенсурсному проекту Scanvus!

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

Отличные новости по моему опенсурсному проекту Scanvus!

Отличные новости по моему опенсурсному проекту Scanvus! Теперь вы можете проводить проверки на уязвимости Linux хостов и докер-образов не только с помощью API от Vulners.com, но и с помощью аналогичного API от Vulns.io. Особенно приятно, что весь код для поддержки нового API коллеги из Vulns.io написали и законтрибьютили сами. Оставалось только потестить, что все работает. За это им огромное спасибо!