Как обеспечить безопасность ОС Linux согласно рекомендациям ФСТЭК России
Исправление мисконфигураций — комплексное мероприятие для устранения некорректных или небезопасных параметров конфигурации информационных систем. В этом критически важном процессе могут возникать технические и организационные сложности. А его эффективность напрямую зависит от согласованности действий между техническими специалистами и ответственными сотрудниками.
На техническом уровне нужно:
- Детально проанализировать текущие конфигурации.
- Выявить отклонения от утвержденных стандартов.
- Скорректировать параметры с учетом совместимости и устойчивости инфраструктуры.
- Верифицировать изменения с помощью тестирования.
Если нарушить последовательность действий или внести некорректные значения, это может привести к отказу сервисов, нарушению целостности данных или формированию новых уязвимых мест в информационных системах.
На организационном уровне исправление мисконфигураций требует соблюсти:
- внутренние регламенты,
- процедуры согласования,
- требования нормативно‑правовых актов.
Даже минимальные изменения в настройках могут потребовать многоступенчатого утверждения, документирования и подтверждения соответствия политике кибербезопасности внутри организации. Если возникают задержки на этих этапах, мисконфигурации в системе существуют дольше. А несоблюдение формальных процедур может привести к претензиям со стороны регуляторов. Особенно если речь идет о государственных информационных системах (ГИС) и объектах критической информационной инфраструктуры (ОКИИ).
У ФСТЭК России есть методический документ «Рекомендации по безопасной настройке операционных систем Linux». В нем подчеркивается важность исправления мисконфигураций и даны конкретные советы. Документ предназначен для выработки единых требований или рекомендаций по исправлению мисконфигураций в Linux. Для этого нужно:
- Определить перечень организационных и технических мер.
- Определить требования ФСТЭК России и их реализацию в Linux.
- Сформировать практические рекомендации по исправлению мисконфигураций и реализовать их.
Для ГИС и ОКИИ, которые построены с использованием Linux-систем, не сертифицированных по требованиям безопасности информации, до их замены на сертифицированные отечественные ОС выполнение этих требований обязательно. Но и для тех компаний, в которых используются ОС на базе Linux, не являющиеся ГИС или ОКИИ, следование этим рекомендациям поможет обеспечить безопасность информационных систем. Четкого перечня дистрибутивов Linux-систем в документе нет, однако такие настройки можно применить на Debian, Ubuntu, CentOS и др.
По данным BI.ZONE TDR, около 90% компаний, у которых в инфраструктуре есть операционные системы на базе Linux, не являющиеся ГИС или ОКИИ, не соблюдают как минимум одно требование из методического документа ФСТЭК России. В рамках мониторинга было зафиксировано, что 8% компаний соблюдают все требования, 44% не соблюдают от 1 до 3 требований, 48% не соблюдают 4 и более требований.
В рамках развития проактивного выявления угроз мы предоставляем клиентам BI.ZONE TDR (тарифы Focus и Panorama) возможность устранить мисконфигурации без непосредственного доступа к хосту, минуя часть рутинных действий. Это упрощает процесс исправления. Кроме того, в августе 2025 года появилась возможность быстро исправить часть мисконфигураций в инфраструктуре с помощью BI.ZONE TDR Bot. И мы продолжаем наращивать объем мисконфигураций из методики ФСТЭК России, которые можно исправить по нажатию одной кнопки.
Организационные меры играют решающую роль в обеспечении безопасности и стабильности информационных систем. Они определяют рамки, правила и последовательность действий, в которых работают технические специалисты, минимизируя риск сбоев или новых ошибок.
Один из ключевых элементов организационных мер — регламентация и стандартизация. Компания должна четко определить стандарты конфигурации для всех критических систем, сетевых устройств, сервисов и приложений. Эти стандарты охватывают допустимые параметры, безопасные значения по умолчанию и исключенные конфигурации, а также описывают порядок внесения изменений. Наличие таких правил позволяет снизить вероятность ошибок и упрощает контроль за состоянием IT‑инфраструктуры.
Не менее важно многоуровневое согласование изменений. Даже тривиальная правка конфигурационного параметра должна проходить проверку на соответствие внутренним политикам и требованиям кибербезопасности. На этапе предварительного согласования изменения рассматривают все ответственные — администраторы, руководители подразделений и специалисты по кибербезопасности. Это обеспечивает согласованность действий и предотвращает случайное внедрение небезопасных настроек.
Контроль и аудит — также неотъемлемая часть организационных мер. Все действия по исправлению мисконфигураций должны фиксироваться в журналах с указанием исполнителя, времени и сути изменений. Такая прозрачность позволяет отслеживать внесенные изменения и устанавливать ответственных, а при необходимости проводить постинцидентный анализ и выявлять причины сбоев.
Процесс исправления мисконфигураций редко ограничивается одним подразделением, поэтому требуется постоянная координация между командами IT и кибербезопасности, а также взаимодействие с эксплуатационными службами. Часть работ по исправлению мисконфигураций связана с управлением уязвимостями, в ходе которого происходят централизованный сбор, классификация и приоритизация обнаруженных ошибок. Эффективный процесс невозможен без четкого распределения ролей между подразделениями.
Исправление мисконфигураций редко бывает однотипным процессом — почти каждая проблема требует уникального подхода. То, что в одном случае можно устранить одной командой, в другом потребует глубокого анализа влияния изменений на работоспособность сервиса или совместимость с другими компонентами системы. Универсальных рецептов не существует, поэтому ключевая задача технических специалистов — выбор оптимального способа устранения конкретной проблемы с учетом ее контекста. Рекомендации ФСТЭК России разбиты на главы, и по каждой можно сопоставить требование с технической реализацией исправления, чтобы системно подойти к устранению мисконфигураций.
Рекомендации касаются авторизации в ОС Linux для предотвращения несанкционированного доступа.
| Рекомендация | Исправление на Linux |
|---|---|
2.1.1. Не допускать использование учетных записей пользователей с пустыми паролями. Настроить учетные записи таким образом, чтобы каждый пользователь системы либо имел пароль, либо был заблокирован по паролю. В системах Linux данную возможность обеспечивает файл /etc/shadow |
Установите пароли для всех пользователей: |
2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH путем установки для параметра PermitRootLogin значения no в файле /etc/ssh/sshd_config |
Отредактируйте |
Настройка авторизации имеет фундаментальное значение для предотвращения несанкционированного доступа. Без этих мер система уязвима к брутфорс-атакам и прямому входу root, что может привести к полной компрометации. Следование рекомендациям важно для соблюдения принципа минимальных привилегий, что снижает риски утечек и злоупотреблений.
Здесь описано ограничение механизмов получения привилегий для минимизации рисков эскалации. Рекомендации включают ограничение доступа к команде su и списку пользователей, которым разрешено использовать sudo.
| Рекомендация | Исправление на Linux |
|---|---|
2.2.1. Обеспечить ограничение доступа к команде su путем добавления в файл /etc/pam.d/su следующей строки: auth required pam_wheel.so use_uid. Создать список пользователей в записи для группы wheel в файле /etc/group: wheel:x:10:root,<user list> |
Отредактируйте |
2.2.2. Ограничить список пользователей, которым разрешено использовать команду sudo и разрешенных к выполнению через sudo команд путем пересмотра файла /etc/sudoers |
Отредактируйте |
Ограничение привилегий предотвращает несанкционированную эскалацию. Без него возможны инсайдерские атаки и распространение вредоносного ПО. Ограничение привилегий позволяет соблюсти принцип разделения прав доступа и минимизировать ущерб от компрометации.
Здесь собраны рекомендации по настройке прав доступа к файловой системе для защиты от несанкционированных изменений. Они охватывают файлы учетных данных, запускаемые процессы, cron и SUID-/SGID‑приложения.
| Рекомендация | Исправление на Linux |
|---|---|
2.3.1. Установить корректные права доступа к файлам настройки пользователей, а именно к файлам с перечнями пользовательских идентификаторов (/etc/passwd) и групп (/etc/group), либо хранилищам хешей паролей (в операционных системах GNU/Linux, Solaris, HP‑UX: /etc/shadow, AIX: /etc/security/passwd), с помощью команд: chmod 644 /etc/passwd; chmod 644 /etc/group; chmod go-rwx /etc/shadow |
Выполните команды:
|
2.3.2. Установить корректные права доступа к файлам запущенных процессов путем выполнения команды вида: chmod go-w /путь/к/файлу для всех исполняемых файлов, запущенных в настоящий момент, и соответствующих библиотек. После этого необходимо осуществить проверку, что директория, содержащая данный файл, а также все родительские директории недоступны для записи непривилегированным пользователям |
Найдите исполняемые файлы: Выполните Проверьте директории |
2.3.3. Установить корректные права доступа к файлам, выполняющимся с помощью планировщика задач cron неавторизованными пользователями путем выполнения команды chmod go-w путь_к_файлу для каждого файла (либо команды), который вызывается из заданий cron. В противном случае это может привести к выполнению произвольного кода от имени владельца задания cron (в том числе root, что приведет к полной компрометации операционной системы) |
Выполните |
2.3.4. Установить корректные права доступа к файлам, выполняемым с помощью sudo путем изменения владельца командой chown root путь_к_файлу для каждого исполняемого файла, который можно запускать с привилегиями суперпользователя root, но владельцем которого является обычный пользователь и выполнения команды chmod go-w путь_к_файлу для каждого исполняемого файла, который можно запускать с привилегиями суперпользователя root и к которому имеют доступ на запись все пользователи |
Выполните Выполните |
2.3.5. Установить корректные права доступа к стартовым скриптам системы путем выполнения команды chmod o-w <filename> к каждому файлу в директориях /etc/rc#.d, а также к файлам .service, присутствующим в системе |
Выполните Выполните для файлов |
2.3.6. Установить корректные права доступа к системным файлам заданий (конфигурационным файлам) cron при помощи команды chmod go-wx путь_к_файлу_или_директории. К системным файлам-описаниям очередей cron относятся следующие файлы (могут присутствовать не всегда, в зависимости от операционной системы и ее настроек): /etc/crontab; /etc/cron.d (директория и файлы внутри нее); /etc/cron.hourly (директория и файлы внутри нее); /etc/cron.daily (директория и файлы внутри нее); /etc/cron.weekly (директория и файлы внутри нее); /etc/cron.monthly (директория и файлы внутри нее) |
Выполните |
2.3.7. Установить корректные права доступа к пользовательским файлам заданий cron при помощи команды вида: chmod go-w путь_к_файлу_заданий |
Выполните |
2.3.8. Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путем анализа корректности прав доступа к утилитам и системным библиотекам, расположенным по стандартным путям (/bin, /usr/bin, /lib, /lib64 и другим путям), а также к модулям ядра (для Linux: /lib/modules/версия-текущего-ядра). Местоположение большинства стандартных исполняемых файлов указано в переменной $PATH пользователя root |
Выполните Выполните |
2.3.9. Установить корректные права доступа к SUID/SGID-приложениям путем проведения аудита системы на предмет поиска всех SUID/SGID-приложений — права доступа к каждому из них не должны позволять остальным пользователям изменять его содержимое (в особенности если это SUID-приложение и его владелец root). В противном случае следует выполнить команду вида: chmod go-w /путь/к/приложению. Проверить, что среди выявленных SUID/SGID-приложений не присутствуют лишние (например, если определен «белый» список таких приложений), в противном случае следует снять с таких приложений SUID/SGID-биты |
Выполните Выполните |
2.3.10. Установить корректные права доступа к содержимому домашних директорий пользователей (.bash_history, .history, .sh_history и т. п. — файлы истории команд оболочек, .bash_profile, .bashrc, .profile, .bash_logout и т. п. — файлы настройки оболочки, .rhosts — настройки R-подсистем) путем установки на каждый из указанных файлов корректных прав доступа с помощью команды вида: chmod go-rwx путь_к_файлу |
Выполните |
2.3.11. Установить корректные права доступа к домашним директориям пользователей с помощью команды chmod 700 домашняя_директория |
Выполните |
Настройка прав доступа защищает файлы от модификаций. Без корректных настроек возможны атаки на целостность, такие как подмена скриптов или кража данных. Перечисленные меры важны для предотвращения эскалации и обеспечения конфиденциальности в КИИ.
Здесь описана настройка механизмов защиты ядра Linux для повышения безопасности. Рекомендации включают ограничение доступа к журналу ядра, адресов и другие параметры sysctl.
| Рекомендация | Исправление на Linux |
|---|---|
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) |
Добавьте в GRUB: |
2.4.4. Запретить слияние кешей ядерного аллокатора путем установки опции загрузки ядра slab_nomerge. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_SLAB_MERGE_DEFAULT при запуске системы (per boot) |
Добавьте в GRUB: |
2.4.5. Инициализировать механизм IOMMU путем установки значения для следующих опций загрузки ядра: iommu=force; iommu.strict=1; iommu.passthrough=0 |
Добавьте в GRUB: |
2.4.6. Рандомизировать расположение ядерного стека путем установки значения опции загрузки ядра randomize_kstack_offset=1. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT при запуске системы (per boot) |
Добавьте в GRUB: |
2.4.7. Включить средства защиты от аппаратных уязвимостей центрального процессора (для платформы x86) путем установки значения опции загрузки ядра mitigations=auto,nosmt |
Добавьте в GRUB: |
2.4.8. Включить защиту подсистемы eBPF JIT ядра Linux путем установки значения sysctl-опции net.core.bpf_jit_harden=2 |
|
Защита ядра предотвращает эксплуатацию уязвимостей. Без этих мер ядро уязвимо к таким угрозам, как утечки адресов или DoS. Защита ядра способствует стабильности КИИ и минимизирует риски системных сбоев.
Этот раздел касается уменьшения периметра атаки ядра Linux путем отключения ненужных функций. Рекомендации включают отключение vsyscall, user namespaces и других.
| Рекомендация | Исправление на Linux |
|---|---|
2.5.1. Отключить устаревший интерфейс vsyscall путем установки значения опции загрузки ядра vsyscall=none. Эта настройка позволяет изменить значение опции сборки ядра CONFIG_LEGACY_VSYSCALL_NONE при запуске системы (per boot) |
Добавьте в GRUB: |
2.5.2. Ограничить доступ к событиям производительности путем установки значения sysctl-опции kernel.perf_event_paranoid=3 |
|
2.5.3. Отключить монтирование виртуальной файловой системы debugfs путем установки значения опции загрузки ядра debugfs=no-mount (по возможности off) |
Добавьте в GRUB: |
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 для выполнения своей задачи, данная настройка никак не повлияет на работу системы. Рекомендуется предварительно проверить реализацию данной рекомендации на тестовой системе |
|
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 |
Добавьте в GRUB: |
2.5.10. Настроить параметр ядра, который определяет минимальный виртуальный адрес, который процессу разрешено использовать для mmap, путем использования sysctl-опции vm.mmap_min_addr = 4096 или больше |
|
2.5.11. Реализовать рандомизацию адресного пространства, которая защищает от атак на переполнение буфера, путем использования команды после тестирования kernel.randomize_va_space = 2 |
|
Уменьшение периметра снижает поверхность атаки. Без этого ядро подвержено таким действиям злоумышленников, как повышение привилегий. Уменьшение периметра имеет большое значение для харденинга систем, предотвращая продвинутые атаки на КИИ.
Здесь описывается настройка средств защиты userspace со стороны ядра. Рекомендации включают ограничение ptrace, symlinks и core dumps.
| Рекомендация | Исправление на Linux |
|---|---|
2.6.1. Запретить подключение к другим процессам с помощью ptrace путем установки значения sysctl-опции kernel.yama.ptrace_scope=3 |
|
2.6.2. Ограничить небезопасные варианты прохода по символическим ссылкам (symlinks) путем установки значения sysctl-опции fs.protected_symlinks=1. Данная настройка не влияет на нормальную функциональность userspace и блокирует только вредоносное поведение |
|
2.6.3. Ограничить небезопасные варианты работы с жесткими ссылками (hardlinks) путем установки значения sysctl-опции fs.protected_hardlinks=1. Данная настройка не влияет на нормальную функциональность userspace и блокирует только вредоносное поведение |
|
2.6.4. Включить защиту от непреднамеренной записи в FIFO-объект путем установки значения sysctl-опции fs.protected_fifos=2. Данная настройка не влияет на нормальную функциональность userspace и блокирует только вредоносное поведение |
|
2.6.5. Включить защиту от непреднамеренной записи в файл путем установки значения sysctl-опции fs.protected_regular=2. Данная настройка не влияет на нормальную функциональность userspace и блокирует только вредоносное поведение |
|
2.6.6. Запретить создание core dump для некоторых исполняемых файлов путем установки значения sysctl-опции fs.suid_dumpable=0. Данная настройка не влияет на нормальную функциональность userspace и блокирует только вредоносное поведение |
|
Защита пространства пользователя (userspace) от ядра предотвращает потенциально вредоносные действия программ. Без таких мер возможны атаки, например, с использованием гонок символических ссылок (symlink races). Защита userspace особенно важна для обеспечения изоляции и снижения рисков в многопользовательских системах КИИ.
Один из наиболее эффективных инструментов для массового исправления конфигураций в Linux‑средах — Ansible. С его помощью можно централизованно изменять параметры в конфигурационных файлах, управлять разрешениями, отключать или настраивать службы, а также применять комплексные политики безопасности на сотнях узлов одновременно. При этом важно не ограничиваться точечными правками, а интегрировать безопасные настройки в золотой образ (golden image) — эталонную сборку операционной системы и приложений, из которой будут развертываться новые серверы и контейнеры. Такой подход позволяет избежать повторного появления уже известных мисконфигураций в новых системах.
В дополнение к элементам технических мер идут:
- автоматизированные проверки на соответствие конфигураций установленным стандартам безопасности;
- хранение и контроль версий настроек через системы вроде Git;
- тестирование изменений в изолированных средах перед их применением в продуктивной среде.
Все это делает процесс исправления мисконфигураций управляемым и минимизирует риск сбоев.
Современные средства защиты конечных точек могут не только обнаруживать вредоносную активность, но и играть ключевую роль в выявлении и профилактике мисконфигураций. В BI.ZONE EDR реализованы механизмы, позволяющие автоматически анализировать параметры конфигурации операционных систем и прикладного ПО, выявлять отклонения от рекомендованных значений и классифицировать их по степени критичности.
Используя встроенные правила детектирования, решение BI.ZONE EDR способно обнаруживать широкий спектр мисконфигураций — от неправильно настроенных парольных политик и небезопасных параметров автозагрузки до неправомерно выданных привилегий и отсутствия критических обновлений, в том числе все мисконфигурации из рекомендаций ФСТЭК России. При этом результаты анализа автоматически интегрируются в общую картину безопасности инфраструктуры, что упрощает их обработку в рамках процессов управления уязвимостями и харденинга систем.
BI.ZONE EDR также позволяет автоматизированно устранять выявленные мисконфигурации с использованием BI.ZONE TDR Bot. Этот инструмент интегрирован с BI.ZONE EDR и позволяет администраторам инициировать исправление конфигураций одним действием — нажатием кнопки «Исправить мисконфигурации» в интерфейсе. BI.ZONE TDR Bot выполняет корректирующие действия удаленно и не требует доступа к каждому хосту по административным каналам.
Интеграция BI.ZONE TDR Bot в существующие процессы значительно сокращает время между обнаружением и устранением мисконфигураций. После выявления отклонений от стандартов безопасности задача по их исправлению передается в автоматический сценарий, где все действия выполняются централизованно и прозрачно для специалистов по IT и кибербезопасности. Такой подход обеспечивает управляемость процесса, не требует отдельного подключения к каждому узлу и снижает влияние человеческого фактора.
В результате команды кибербезопасности и IT-администрирования получают единый инструмент, объединяющий функции мониторинга, анализа и немедленного реагирования, что особенно важно при работе с распределенной или критически важной инфраструктурой.
/etc/passwd) и групп (/etc/group), либо хранилищам хешей паролей». Инициация исправления мисконфигураций доступна в чате в топике «Рекомендации безопасности». Чтобы запустить процесс, нужно найти уведомление, под которым будет доступна кнопка «Исправить мисконфигурации».
Рекомендации ФСТЭК России помогают сделать системы более безопасными, но работа с мисконфигурациями — это не разовое мероприятие, а непрерывный процесс. Он требует комплексного подхода, который сочетает технические инструменты, организационные процедуры и четко выстроенное взаимодействие между подразделениями. Ошибки в настройках могут быть столь же критическими, как и уязвимости в ПО, создавая для злоумышленников прямые точки входа в систему.
Комплексный подход предполагает стандартизацию настроек, автоматизацию исправлений, контроль версий и постоянный мониторинг. Это позволяет не только оперативно устранять выявленные проблемы, но и предотвращать их повторное появление. У клиентов BI.ZONE TDR с тарифами Focus и Panorama, подключивших BI.ZONE TDR Bot, есть возможность исправлять некоторые мисконфигурации безопасно и удаленно. Процесс прозрачный и полностью управляемый.
Особое значение имеет сочетание автоматизации и грамотно выстроенной организационной структуры. В условиях, когда сложность инфраструктуры растет, а объем угроз увеличивается, системный подход к выявлению и исправлению конфигурационных ошибок существенно снижает риск их эксплуатации. Это позволяет командам кибербезопасности и IT сосредоточиться на стратегических задачах, а не на постоянном ручном устранении последствий ошибок.