На сайте ФСТЭК России опубликован Методический документ «Рекомендации по обеспечению безопасной настройки операционных систем Linux». — Security

Ну, хуже никому не будет)))

dumauz ★★
(23.01.23 18:01:48 MSK)

Большой Брат плохого не посоветует.

Irma ★★
(23.01.23 18:03:01 MSK)

Интересно что скажут эксперты. Всё ли там по делу или куча устаревших и малоэффективных советов.

fuggy
(23.01.23 19:28:04 MSK)

Ответ на: комментарий от fuggy 23.01.23 19:28:04 MSK

Предполагаю, эти советы пртдётся соблюсти для прохождения сертификации ФСТЭК, например, если работаете с персональными данными или ещё в госе каком.

madcore ★★★★★
(23.01.23 19:35:53 MSK)

Ответ на: комментарий от madcore 23.01.23 19:35:53 MSK

Нет:

Настоящие Рекомендации подлежат реализации в государственных
информационных системах и на объектах критической информационной
инфраструктуры Российской Федерации, построенных с использованием
операционных систем Linux, несертифицированных по требованиям безопасности
информации, до их замены на сертифицированные отечественные операционные
системы.

vvn_black ★★★★★
(23.01.23 19:39:00 MSK)

Ответ на: комментарий от fuggy 23.01.23 19:28:04 MSK

Я не эксперт, как по мне так норм рекомендации.

vvn_black ★★★★★
(23.01.23 19:42:23 MSK)

Ответ на: комментарий от fuggy 23.01.23 19:28:04 MSK

Начать стоит с объяснения госмужам, что Linux - это ядро. GNU/Linux - операционная система на базе ядра Linux, а реализации этого балагана - дистрибутивы. Ну и по тексту там прям балаган как надо. Видимо в цейтноте кипиай чинуший закрывали, выдавили бумажку, отчитались.

Anoxemian ★★★★★
(23.01.23 19:46:27 MSK)

Ответ на: комментарий от Anoxemian 23.01.23 19:46:27 MSK

Пастернака не читал, всё как обычно.

Aceler ★★★★★
(23.01.23 19:47:28 MSK)

Ответ на: комментарий от Anoxemian 23.01.23 19:46:27 MSK

«Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путём анализа корректности прав доступа к утилитам и системным библиотекам».

Это же в ДМБ, вроде, было: «Для более эффективного проследования в часть, просьба пройти в автобус и проследовать в часть».

Anoxemian ★★★★★
(23.01.23 19:48:52 MSK)

Ответ на: комментарий от Anoxemian 23.01.23 19:48:52 MSK

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

thesis ★★★★★
(23.01.23 19:54:05 MSK)

Как по мне - самое забавное открытие из этого документа - AltLinux единственный из Линуксов, имеющихся сейчас под рукой, у которого ядро собрано похоже действительно без CONFIG_INIT_ON_ALLOC_DEFAULT_ON.
Arch, Void, Ubuntu - у всех включено в config.

Прям даже жаль, что я AltLinux не ставил установщиком, надо бы посмотреть пишут ли они init_on_alloc=1 в параметры ядра, когда он устанавливается в обычном режиме.

Toxo2 ★★★★
(23.01.23 20:59:58 MSK)

Ответ на: комментарий от Anoxemian 23.01.23 19:48:52 MSK

Да вроде обычный казённый язык, тащемта. В духе сводок: «атаковал потерпевшего посредством нанесения колотой раны предметом, конструктивно схожим с ножом» ))

По сути-то, похоже на вполне здравый аудит и выстраивание профилей активности в ОС.

NDfan ★
(23.01.23 21:54:26 MSK)

Пригодится.

По ходу дела, рекомендации, в том или ином виде, распропагандированы для ключевых правительственных сфер. Есть даже ссылки на готовые плейбуки Ansible.

https://ncp.nist.gov/checklist/909

https://security-guidance.service.justice.gov.uk/system-lockdown-and-hardenin...

и т.п.

NDfan ★
(23.01.23 22:19:39 MSK)

Ответ на: комментарий от NDfan 23.01.23 21:54:26 MSK

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

soomrack ★★★★★
(23.01.23 22:21:24 MSK)

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

Мои замечания (после бутылки вина, ибо вечер понедельника!):

2.1.1. Не допускать использование учетных записей пользователей с пустыми паролями

Линукс не допускает пустые пароли, даже не допускает сейчас пароли не соотв. определенным правилам безопасности (но обойти можно).

2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH

Идиотизм, видимо эта рекомендация является следствием того, что для root используют слабые пароли, которые используются для авторизации на всяких сайтах по продаже барахла и соц.сетей… Формально это не дает никаких доп. защит.

2.2.1. Обеспечить ограничение доступа к команде su путём добавления в файл /etc/pam.d/su следующей строки: auth required pam_wheel.so use_uid

разумно, я один раз чуть не поимел с этим проблем при обновлении политик безопасности, в стародавние времена, когда группу wheel только ввели…

2.2.2. Ограничить список пользователей, которым разрешено использовать команду sudo и разрешенных к выполнению через sudo команд путём пересмотра файла /etc/sudoers.

имхо, sudo это очень кривая утилита, добавляющая лишнюю прослойку, ее не стоит использовать в принципе.

2.3

имхо, весь пункт повторяет рекомендации 2.2 но более предметно, по факту надо проверить, а не настраивать, базовые права соотв. рекомендациям.

2.4.1 Ограничить доступ к журналу ядра путём установки значения sysctl- опции kernel.dmesg_restrict=1. Журнал ядра должен быть доступен только пользователям, которые обладают разрешением CAP_SYSLOG (администраторы системы).

Обычно он так и ограничен…

2.4.2 Заменить ядерные адреса в /proc и других интерфейсах на 0 путём установки значения sysctl-опции kernel.kptr_restrict=2.

Зачем?

2.4.3 Инициализировать динамическую ядерную память нулем при ее выделении путём установки значения опции загрузки ядра init_on_alloc=1. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_INIT_ON_ALLOC_DEFAULT_ON при запуске системы (per boot).

Разумно.

2.4.4 Запретить слияние кэшей ядерного аллокатора путём установки опции загрузки ядра slab_nomerge. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_SLAB_MERGE_DEFAULT при запуске системы (per boot).

хмм, не очень понятен возможный вектор атаки

2.4.5 Инициализировать механизм IOMMU путём установки значения для следующих опций загрузки ядра …

зачем? если IOMMU не нужен, то это только ослабляет зашиту…

2.4.6 Рандомизировать расположение ядерного стека путём установки значения опции загрузки ядра randomize_kstack_offset=1. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_RANDOMIZE_KSTACK_OFFSET_ DEFAULT при запуске системы (per boot).

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

2.4.7 Включить средства защиты от аппаратных уязвимостей центрального процессора (для платформы x86) путём установки значения опции загрузки ядра mitigations=auto,nosmt.

Резкое падение производительности, когда нужна эта защита? Какой вектор атаки?

2.4.8 Включить защиту подсистемы eBPF JIT ядра Linux путём установки

eBPF обычно не нужна, ее можно тупо отключить.

2.5.1. Отключить устаревший интерфейс vsyscall путём установки значения опции загрузки ядра vsyscall=none. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_LEGACY_VSYSCALL_NONE при запуске системы (per boot).

По-хорошему, он должен быть отключен при сборке ядра.

2.5.2. Ограничить доступ к событиям производительности путём установки значения sysctl-опции kernel.perf_event_paranoid=3.

Зачем? Какой вектор атаки?

2.5.3. Отключить монтирование виртуальной файловой системы debugfs путём установки значения опции загрузки ядра debugfs=no-mount (по возможности off).

Дебаг функциональность обычно сильно снижает производительность и ее следует отключать по этим соображениям.

2.5.4. Отключить системный вызов kexec_load путём установки значения sysctl-опции kernel.kexec_load_disabled=1.

Последствия? Сколько нужный сервисов перестанет работать?

2.5.5. Ограничить использование user namespaces путём установки значения sysctl-опции user.max_user_namespaces=0. Если система на базе Linux не использует user namespaces для выполнения своей задачи, то данная настройка никак не повлияет на работу системы. Рекомендуется предварительно проверить реализацию данной рекомендации на тестовой системе.

т.е. отключить, если не нужно. логично!

2.5.6. Запретить системный вызов bpf для непривилегированных пользователей путём установки значения sysctl-опции kernel.unprivileged_bpf_disabled=1. Если непривилегированные процессы в системе на базе Linux не используют BPF для выполнения своей задачи, данная настройка никак не повлияет на работу системы. Рекомендуется предварительно проверить реализацию данной рекомендации на тестовой системе.

BPF не нужен, имхо… Одни дыры от него…

2.5.7. Запретить системный вызов userfaultfd для непривилегированных пользователей путём установки значения sysctl-опции vm.unprivileged_userfaultfd=0.

Правильно, но вроде так по дефолту и есть…

2.5.8. Запретить автоматическую загрузку модулей ядра, отвечающих за поддержку дисциплины линии терминала путём установки значения sysctl-опции dev.tty.ldisc_autoload=0.

Если говорить о рекомендациях по безопасности, то лучше делать монолитное ядро…

2.5.9. Отключить технологию Transactional Synchronization Extensions (TSX) путём установки значения опции загрузки ядра tsx=off.

хмм…

2.5.10. Настроить параметр ядра, который определяет минимальный виртуальный адрес, который процессу разрешено использовать для mmap, путём использования sysctl-опции vm.mmap_min_addr = 4096 или больше.

Ядро позволяет очень хорошо ограничить доступ к mmap и к kmap (лучше вообще отключить)…

2.5.11. Реализовать рандомизацию адресного пространства, которая защищает от атак на переполнение буфера, путём использования команды после тестирования kernel.randomize_va_space = 2. значения sysctl-опции net.core.bpf_jit_harden=2.

Вектор атаки? Для ряда систем это полезно, для других – бессмысленно.

soomrack ★★★★★
(23.01.23 23:10:33 MSK)

Ответ на: комментарий от soomrack 23.01.23 23:10:33 MSK

2.6.1. Запретить подключение к другим процессам с помощью ptrace путём установки значения sysctl-опции kernel.yama.ptrace_scope=3.

tmux, привет!

2.6.2. Ограничить небезопасные варианты прохода по символическим ссылкам (symlinks) путём установки значения sysctl-опции fs.protected_symlinks=1. Данная настройка не влияет на нормальную функциональность userspace и блокирует только вредоносное поведение.