Ошибки в NFS позволяют поднять права на Linux-сервере

NFS остаётся удобным способом открыть общий доступ к файлам на Linux-серверах, но ошибка в настройках превращает его в серьёзный риск. Если администратор неверно задаёт права для удалённых каталогов, пользователь с ограниченным доступом может получить лишние привилегии и добраться до данных, которые ему не предназначались.

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

Что такое NFS и почему он до сих пор в работе

NFS (Network File System — «сетевая файловая система») позволяет подключать папки с одного Linux-сервера к другому так, будто они лежат на локальном диске. Для пользователя это выглядит просто: каталог открылся, файлы читаются и записываются обычными командами, приложения не замечают разницы.

За этой простотой стоит сложная связка сетевых вызовов, прав доступа и сопоставления пользователей между системами. Именно здесь и появляются ошибки. Сервер должен понять, кто обращается к файлу, какие права у этого пользователя и можно ли доверять данным, пришедшим с другой машины.

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

Где появляется риск повышения прав

Главная опасность связана с тем, как NFS обрабатывает пользователей с максимальными правами. В Linux суперпользователь root имеет идентификатор UID 0. Если удалённая машина подключается к общему каталогу, серверу важно не принять чужой root за своего собственного.

Для защиты обычно используют механизм root_squash. Он «понижает» права удалённого root до ограниченного пользователя, чтобы тот не мог менять файлы на сервере как администратор. Это базовая страховка, без которой общий каталог может стать слишком доверчивым.

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

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

Почему это не только проблема администраторов

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

Если злоумышленник уже оказался внутри сети или получил учётную запись с минимальными правами, неправильный NFS может помочь ему расширить доступ. Это не сценарий «с улицы за одну минуту», а типичная стадия атаки после первого проникновения: закрепиться, найти слабую точку и поднять привилегии.

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

Для руководителя вывод простой: файловые шары — часть периметра безопасности, а не бытовая настройка «чтобы всем было удобно». Их нужно проверять так же регулярно, как пароли администраторов, резервные копии и журналы входа.

Какие признаки должны насторожить

Первый сигнал — старые экспортируемые каталоги, о назначении которых никто в команде уже не помнит. Часто они остаются после миграций, тестовых стендов или временных проектов. «Временно» в инфраструктуре нередко живёт дольше штатных систем.

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

Третий тревожный признак — отключённые защитные параметры ради совместимости со старым приложением. Это понятная инженерная логика, но такие исключения должны иметь владельца, срок пересмотра и документированную причину. Иначе они превращаются в «слепую зону».

Ещё один маркер — хранение секретов в общих каталогах: конфигураций с паролями, токенов, ключей API, дампов баз. Даже если права выставлены верно, такие файлы требуют отдельного контроля и шифрования. Ошибка в сетевом доступе не должна сразу раскрывать критичные секреты.

Как снизить риск без остановки рабочих процессов

Защита NFS начинается не с покупки нового продукта, а с инвентаризации. Администратору нужно понять, какие каталоги экспортируются, кто ими пользуется, с каких машин идут подключения и какие параметры заданы для каждого ресурса.

Дальше стоит разделить доступ по принципу минимальных прав. Серверу разработки не нужен доступ к архивам бухгалтерии, а тестовому окружению — к рабочим ключам. Чем меньше пересечений, тем меньше ущерб при взломе одной машины.

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

Не менее важны журналы. Подключения к NFS, ошибки доступа, изменения в критичных каталогах и запуск файлов с необычными правами нужно собирать и просматривать. Если компания уже следит за обновлениями рабочих станций, полезно связать этот процесс с серверным контролем: например, после крупных апдейтов сверять, не изменились ли сетевые политики. О том, почему даже рядовые обновления требуют внимания, мы рассказывали в материале про новые бета-сборки Windows 11 и безопасность.

Практический вывод: что проверить сейчас

• Составьте список всех NFS-ресурсов: сервер, каталог, владелец, назначение, список клиентов.
• Убедитесь, что для общих каталогов включена защита root_squash, если нет редкого и документированного исключения.
• Уберите широкие сетевые разрешения, где доступ открыт целым подсетям без нужды.
• Проверьте, нет ли в общих папках ключей, паролей, токенов, дампов баз и резервных копий без шифрования.
• Настройте отдельные права для чтения и записи: большинству сервисов не нужен полный доступ.
• Включите сбор логов по подключениям, ошибкам доступа и изменениям прав на файлы.
• Пересматривайте настройки после миграций, смены подрядчика, ввода нового сервера и закрытия проекта.
• Проведите внутреннюю проверку с участием специалистов по безопасности, но без публикации опасных команд и без экспериментов на рабочих системах без согласования.