Назад | Перейти на главную страницу

Сервер NFS + клиент: Рекомендуемая защита / последние штрихи

Мы только что впервые установили прекрасный маленький общий ресурс / клиент nfs.

a) UID для файлов на стороне клиента отображается как 4294967294 при перечислении через ls, но клиент может создавать и удалять файлы / каталоги в общей папке. Файлы и папки, созданные на стороне клиента, отображаются с правильным именем пользователя (и uid) на стороне сервера. Мы убедились, что пользователи, пишущие в общий ресурс, имеют одинаковый UID на стороне сервера.

Следующее отображается для всех файлов / папок на стороне клиента:

drwxr-xr-x 6 4294967294 4294967294 4096 Feb 23 16:04 foldername

Это нормально?

б) Нужно ли что-нибудь делать с демонами portmap / nfs, чтобы полностью отключить работу любых служб nfs (или rpc *, поскольку он не был установлен до этого) на нашем внешнем интерфейсе? В идеале мы хотели бы привязать сервисы только к нашим подсетям lan и vpn.

c) Каков идеальный способ сделать клиентскую часть nfs максимально агрессивной в отношении попыток повторного подключения? В идеале, если сетевое соединение будет потеряно в любой момент, клиентская сторона nfs будет продолжать попытки часто и бесконечно. Можно ли это сделать через fstab? Или клиент nfs по умолчанию это уже делает? Сторона LAN, где разделяются общие ресурсы nfs, представляет собой соединение 1GBit.

г) Что-нибудь еще?

Конец связи.

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

NFS сложно защитить. Самая важная вещь, которую я мог бы порекомендовать, - это использовать NFS4 с механизмами аутентификации GSS, но я продолжу отвечать, как если бы вы использовали NFS3 (или даже NFS2).

  • Укажите IP-адреса, имена хостов или сетевые группы в файле экспорта. Никогда экспортировать *, поскольку это позволяет кому угодно получить доступ к вашей общей папке.
  • Никогда не используйте insecure или no_root_squash параметры экспорта. secure ограничивает доверие сервера к root на клиенте, а не только к любому пользователю, и root_squash переназначает запросы root на nobody, предотвращая доступ к конфиденциальным системным файлам через общий ресурс.
  • Как вы уже пытаетесь сделать, не разрешайте доступ к portmapper, rpc.nfsd или rpc.mountd из Интернета. Хорошая настройка сети (брандмауэры, списки контроля доступа маршрутизатора и т. Д.) Обеспечит это, но -i возможность portmap и используя hosts.allow file для ограничения доступа к локальным IP-адресам также являются хорошей идеей.

Если вы хотите проверить свою настройку на наличие проблем с безопасностью, я написал программу Python для обхода основных механизмов безопасности NFS, NfSpy. Не стесняйтесь попробовать это и посмотреть, сможете ли вы получить доступ к своему экспорту способами, которых вы не ожидали.

P.S. Что касается попыток повторного подключения клиентов, см. MOUNT OPTIONS раздел справочной страницы nfs (5). В целом retrans и hard/soft параметры управляют тем, что вы хотите, но для каждого запроса. Само крепление будет оставаться в рабочем состоянии, даже если сервер отключится на длительное время. Эти настройки определяют, как обрабатываются конкретные запросы (чтение, запись и т. Д.).

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

Я провел быстрый поиск в Google и нашел две ссылки, которые могут вас заинтересовать:

Обеспечение безопасности NFS

Linux NFS-HOWTO

(Содержит передовой опыт и много другой полезной информации о безопасности и настройке)