Безопасные сетевые файловые системы для Linux: что делают люди?

NFSv3 широко распространен, но модель безопасности по умолчанию ... странная . CIFS может использовать аутентификацию Kerberos, но без семантики POSIX это не стартер. AFS никогда не шифровал трафик по проводам и является krb4 - и в основном мертвым проектом. Интересные новые экспериментальные файловые системы либо никогда не материализуются, либо ориентированы на скорость (и, если вам повезет, надежность данных) - например, Luster использует ту же модель доверия клиентов, что и NFSv3. Для домашнего использования sshfs изящен, но это точно не масштабируется.

И, конечно же, есть NFSv4 с sec = krb5p. Великолепно в теории, но через десять лет кажется, что это беспорядочно не используется в реальном мире. У клиента Linux только что удален экспериментальный тег. И если вы посмотрите на EMC Celerra, Isilon и т. Д., Это все NFSv3. (Celerra поддерживает NFSv4, но он действительно скрыт в документации. Isilon, очевидно, работал над добавлением поддержки RPCGSS во FreeBSD, так что, возможно, он появится, но сейчас его нет.) Я даже не могу пометить этот пост как «nfsv4», потому что я Я новичок здесь, и это будет новый тег .

Так что, действительно . Что вы все делаете?

Поскольку это конкретный вопрос (что вы все делаете), давайте ответим на него: ничего. Большинство администраторов и пользователей просто не беспокоятся о безопасности NFS, поэтому все используют NFSv3. Обычно это контролируемая среда (в том смысле, что только известные машины могут подключаться к сети в первую очередь). Если кого-то поймают на злоупотреблении инфраструктурой, его уволят или посадят в тюрьму.

Для данных, которые вы действительно не хотите, чтобы кто-либо мог прочитать, вы явно шифруете их, например, базы данных паролей Firefox, ключи ssh или ключи pgp. Вы делаете это, потому что знаете, что администратор может читать их на файловом сервере, поэтому безопасность сетевой файловой системы в любом случае не поможет.

Вы, кажется, задаете два вопроса здесь:

Что мы на самом деле используем? и что это значит?

На самом деле я использую CIFS, в моих сценариях использования POSIX менее важен, поэтому у меня не было никаких проблем. NFS3 используется в областях, где безопасность не важна, таких как мой установочный сервер SLES. И, наконец, sshfs / gvfs для простого общего доступа пользователей к земле. Проводное шифрование не считается необходимым, поэтому для нас это не имеет большого значения.

Что касается другого вопроса, кажется, есть шесть основных требований к тому, что вы ищете:

1. Шифрует трафик по проводам.
2. Шифрует аутентификацию.
3. Семантика Posix.
4. Строгое соблюдение ACL на основе сервера.
5. Это не пользователь.
6. На самом деле используется.

Я подозреваю, что пункты 5 и 6 будут убийцами здесь, но здесь идет (также, это - точка, где таблица была бы действительно удобна, но markdown / StackExchange не поддерживает это).

NFSv3 + IPSec

1. Зашифрованный на проводе, пасс
2. Нет зашифрованной аутентификации, сбой
3. Posix семантика, мини
4. Нет строгого применения ACL на основе сервера, сбой
5. Это не пользователь, проход
6. На самом деле используется, пройти

NFSv4 + Krb + IPSec

1. Зашифрованный на проводе, пасс
2. Зашифрованная аутентификация, пароль
3. Posix семантика, мини
4. Строгое соблюдение ACL на основе сервера, проход
5. Это не пользователь, проход
6. На самом деле не используется, сбой

CIFS

1. Не зашифрован на проводе, сбой
2. Зашифрованная аутентификация
3. Семантика Posix, проход (Samba & Kernel теперь, Windows имеет слой Posix со времен NT)
4. Строгое соблюдение ACL на основе сервера, проход
5. Это не пользователь, проход
6. На самом деле используется, пройти

CIFS + IPSec

1. Зашифрованный на проводе, пасс
2. Зашифрованная аутентификация
3. Семантика Posix, проход (Samba & Kernel сейчас)
4. Строгое соблюдение ACL на основе сервера, проход
5. Это не пользователь, проход
6. На самом деле не используется, сбой

SSHFS

1. Зашифрованный на проводе, пасс
2. Зашифрованная аутентификация, пароль
3. Posix семантика, мини
4. Строгое соблюдение ACL на основе сервера, проход
5. Это пользователь, провал
6. На самом деле используется, пройти

AFP / Netatalk

1. Зашифрованный на проводе, сбой
2. Зашифрованная аутентификация, пароль
3. Posix семантика, мини
4. Строгое соблюдение ACL на основе сервера, проход
5. Это не пользователь, проход
6. На самом деле используется, сбой

И я не касаюсь распределенных файловых систем там. Там просто нет ни одной вещи, которая делает все это. Некоторые подходят близко (CIFS), а некоторые уже есть, но никто не использует их (NFS4 + IPSec, CIFS + IPSec). По какой-то причине защищенная сетевая файловая система является предметом множества компромиссов на протяжении многих лет.

Я использую openafs в производстве в течение многих лет с клиентами как Linux, так и Windows. Он отлично работает, имеет активное сообщество разработчиков, и за последние несколько лет его стало намного проще устанавливать и администрировать, так как различные дистрибутивы Linux включают в себя пакет для него. У него есть свои недостатки, но я обнаружил, что они компенсируются большей административной гибкостью, возможностью разделения клиентов и серверов по медленным каналам связи, простотой резервного копирования за пределы площадки и другими положительными AFSism.

Одна вещь, которая мне особенно нравится, - это запуск рабочих веб-серверов с выходом в Интернет на openafs с заблокированными ACL. Без билета Kerberos на компьютере не будет ни одного процесса, даже работающего от имени пользователя root, который сможет записать в файловую систему. Я не могу сосчитать, сколько раз мы замечали, что атаки полностью терпят неудачу из-за этой простой меры.

Есть несколько довольно крупных пользователей openafs - крупнейший коммерческий пользователь, которого я знаю, это Morgan Stanley.

Как насчет OpenAFS, который еще жив и VPN под ним, потому что на данный момент его единственным шифрованием является DES.

Я вижу, что многие люди в этой теме говорят о сокрытии данных, то есть о том, что атаки не могут отследить ваши данные. Не менее важно думать о целостности и достоверности данных. Эти пакеты nfs действительно с вашего сервера nfs? Изменен ли пакет nfs при передаче?

Ну, для меня это звучит так, будто одна из этих распределенных файловых систем была бы для вас. Я бы не очень рекомендовал OpenAFS, так как он старый, пока не поддерживает IPv6, ..

Я очень доволен GlusterFS сам. Gluster довольно зрелый, хорошо работает и имеет хороший набор функций. Однако, как недавно обсуждалось в IRC, Gluster также не поддерживает IPv6 стабильно. Эта функция будет запланирована на 3,6 или 3,7.

Существует также проект под названием HekaFS, основанный на Gluster, который добавляет более продвинутые функции аутентификации и SSL. Это очень хорошо документировано и очень хорошо разработано.

Что может заинтересовать вас, так это XtreemFS , которая предназначена для глобальных грид-вычислений, поэтому по умолчанию она поставляется с SSL и другими компонентами . Мой выбор для использования остановился на Gluster, так как сообщество кажется более активным и лучше документировано.

Оба, конечно, соответствуют посиксам.

Я использую NFS. Но межсерверная NFS выполняется по выделенной сетевой магистрали, поэтому шифрование не требуется, а аутентификация бессмысленна. Просто установите для каждого экспорта только общий доступ к выбранному каталогу на сервере по IP.

При всем уважении, вы полностью смотрите на эту проблему неправильно, и вам следует отойти от консоли на несколько часов.

Практически все хранилище данных не зашифровано, потому что это не имеет значения на этом уровне стека абстракции. Сомневаюсь? Нажмите на волоконный коммутатор парчи, и вы увидите, что оптоволоконный канал, как и iscsi и nfs, - все это незашифрованный беспорядок - по замыслу. Решение этой проблемы является средней, а не проблемой протокола хранения. Например, хотите защищенные и зашифрованные NFS? Создал сеть, которая шифруется точка-точка между клиентом и сервером nfs, используя ipsec / ssl / tls или чисто аппаратное решение.