Linux не безопасен по умолчанию: разоблачение главного мифа

«О том, что Linux «безопасен из коробки», — это полуправда и одновременно грубая ошибка. Любая система по умолчанию — это открытая книга, а безопасность — это настройка. В контексте российских требований 152-ФЗ и ФСТЭК этот миф не просто бесполезен, но и опасен.»

Что значит «безопасен по умолчанию» в реальности

Миф о «безопасном из коробки» Linux уходит корнями в сравнение с другими системами, где активные службы и закрытая архитектура иногда создают больше поверхностей для атаки. Однако «меньше» не означает «ноль». По умолчанию дистрибутив Linux стремится к удобству и функциональности, а не к максимальной изоляции. Это проявляется в нескольких моментах:

Включенные, но не всегда необходимые сетевые службы. Например, OpenSSH-сервер или Avahi для обнаружения устройств в локальной сети.
Стандартные настройки ядра, которые не настроены на жёсткое ограничение доступа. Например, sysctl-параметры, управляющие сетевым стеком.
Установленные по умолчанию пакеты, которые расширяют поверхность атаки. Каждый из них — это потенциальный вектор, если в нём будет найдена уязвимость.
Отсутствие активированных или даже установленных подсистем обязательного контроля доступа, таких как SELinux или AppArmor.

Безопасность по умолчанию в Linux — это скорее архитектурные решения, которые при правильной настройке дают мощный эффект: чёткое разделение прав, модель открытого исходного кода, система пакетов с криптографическими подписями. Но эти возможности нужно активировать и настроить.

Архитектурные плюсы, которые не работают сами по себе

Причина устойчивости Linux в корпоративной среде — не магия, а набор потенциально сильных архитектурных решений. Они лежат в основе, но требуют сознательного применения.

Изоляция привилегий и модель sudo

В отличие от систем, где администратор по умолчанию имеет неограниченные права, Linux чётко разделяет root и обычного пользователя. Однако эта модель сама по себе не защищает от ошибок. Если пользователь получил доступ к sudo с паролем по умолчанию или слишком широкими правами в файле /etc/sudoers, разделение теряет смысл.

Пакетные менеджеры и репозитории

Централизованные репозитории с подписанными пакетами — это огромный шаг вперёд по сравнению со скачиванием исполняемых файлов с неизвестных сайтов. Но и здесь есть нюансы:

Доверие распространяется на всех разработчиков дистрибутива. Уязвимость в цепочке сборки или скомпрометированный ключ подписи ставят под удар всю систему.
Пользователи часто добавляют сторонние репозитории для софта, который не входит в стандартные. Каждый такой репозиторий — это расширение доверенной зоны.

Типичные уязвимости конфигурации «из коробки»

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

Сетевые службы: После установки некоторые дистрибутивы могут держать открытыми порты для SSH, CUPS (печать) или служб удалённого управления. Сканер портов покажет их сразу.
Пароль root: В некоторых сценариях установки пароль для root не задаётся, и учётная запись отключена, но если пользователь создаёт пароль для своей учётной записи и назначает его же для root через sudo, это создаёт излишний риск.
Устаревшие пакеты: На момент выпуска дистрибутива пакеты актуальны, но без настроенного автоматического обновления (которое по умолчанию может быть отложенным или ручным) система быстро становится уязвимой.
Настройки ядра: Параметры вроде net.ipv4.ip_forward, kernel.sysrq или настройки, связанные с dmesg, часто остаются в значениях, удобных для отладки, а не для продакшена.

[ИЗОБРАЖЕНИЕ: Диаграмма, показывающая типичные векторы атаки на свежеустановленный Linux-сервер: открытые порты (SSH, 22), учётные записи по умолчанию, отключённый фаервол, стандартные настройки ядра.]

Требования регуляторов и дистрибутив «из коробки»

В российском сегменте ИБ, особенно для госкомпаний и организаций, работающих с персональными данными (152-ФЗ), подход «установил и забыл» недопустим. Система защиты информации (СЗИ) должна строиться на основе аттестованных средств и проверенных конфигураций. Типовой дистрибутив Linux не проходит требования ФСТЭК без серьёзной доработки. Вот ключевые точки несоответствия:

Учётные записи и аутентификация: Требования предписывают сложные пароли, блокировку после неудачных попыток, ведение журналов событий безопасности — всё это нужно настраивать отдельно (PAM, faillock, auditd).
Разграничение доступа: Для выполнения требований по разграничению прав стандартных механизмов Linux (user/group/other) часто недостаточно. Требуется внедрение систем обязательного контроля доступа.
Регистрация событий: Настройка подсистемы аудита (auditd) для записи всех значимых событий в соответствии с политиками безопасности — это ручная и кропотливая работа.
Базовые настройки: Требования ФСТЭК и 152-ФЗ детально описывают необходимые параметры безопасности ОС, которые собираются в так называемые «закладки» или профили. Ни один дистрибутив не содержит их активированными по умолчанию.

Практические шаги по приведению системы к безопасному состоянию

Превращение типовой установки в защищённую систему — это процесс, который можно структурировать. Вот базовый чек-лист действий после установки дистрибутива общего назначения.

1. Минимизация поверхности атаки

Первое, что нужно сделать — отключить всё лишнее.

# Остановить и отключить неиспользуемые службы
systemctl stop avahi-daemon cups bluetooth
systemctl disable avahi-daemon cups bluetooth

# Удалить ненужные пакеты (пример для Debian/Ubuntu)
apt purge telnet rsh-client rsh-server

# Проверить открытые порты и закрыть неиспользуемые
ss -tulpn
# Настроить фаервол (nftables/iptables) на блокировку всего, кроме необходимого

2. Настройка ядра и системных параметров

Внесение изменений в /etc/sysctl.conf или файлы в /etc/sysctl.d/ для ужесточения сетевого стека и поведения системы.

# Пример критичных параметров
net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.dmesg_restrict = 1

3. Установка и настройка подсистем обязательного контроля доступа

Выбор между SELinux или AppArmor зависит от дистрибутива и требований. SELinux, хоть и сложнее в освоении, предоставляет более детальную политику. Его активация и перевод в режим enforcing — ключевой шаг.

# Для RHEL/CentOS/Rocky/AlmaLinux
sestatus
# Убедиться, что состояние 'enforcing'
# При необходимости отредактировать /etc/selinux/config

[ИЗОБРАЖЕНИЕ: Схема, иллюстрирующая разницу между действием стандартной модели DAC (разрешения 755) и моделью MAC (SELinux/AppArmor), где доступ блокируется, несмотря на стандартные разрешения.]

4. Настройка аудита и мониторинга

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

Специализированные дистрибутивы и сборки

Существуют дистрибутивы и сборки, которые позиционируются как «безопасные из коробки». К ним можно отнести:

Готовые сборки для СВТ: Некоторые российские вендоры предлагают предустановленные и настроенные образы ОС Linux, уже соответствующие профилям защиты ФСТЭК. Однако их использование часто привязано к конкретному аппаратному обеспечению и требует лицензии.
Дистрибутивы для пентеста: Kali Linux, Parrot OS — они поставляются с большим набором инструментов, но их настройки безопасности (например, работа от root) делают их опасными для использования в качестве рабочей станции или сервера.
Минималистичные дистрибутивы: Alpine Linux, CoreOS (ныне Flatcar) — они имеют очень малую поверхность атаки из-за минимального набора пакетов. Но их безопасность также зависит от грамотной конфигурации оставшихся компонентов.

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

Итог: вымысел, требующий превращения в правду

Linux не безопасен по умолчанию в том смысле, в котором этого требуют современные стандарты и, в особенности, российское регулирование. Его безопасность — это не данность, а потенциал, заложенный в архитектуре. Этот потенциал реализуется через жёсткую, системную и непрерывную работу по настройке, обновлению и мониторингу. Утверждение о безопасности «из коробки» — это опасная иллюзия, которая может привести к ложному чувству защищённости. В мире, где соответствие 152-ФЗ и требованиям ФСТЭК является обязательным, отправной точкой должна быть не вера в миф, а готовность к кропотливой работе по приведению любой системы, включая Linux, в безопасное состояние.