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

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

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

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

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

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

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

какой я на самом деле используется 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). По какой-то причине защищенная сетевая файловая система - это то, что на протяжении многих лет подвергалось множеству компромиссов.

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

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

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

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

Есть несколько довольно крупных пользователей openaf - самый крупный коммерческий пользователь, о котором я знаю, - это 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, поскольку сообщество кажется более активным, и это лучше документировано.

Оба, конечно, совместимы с posix.

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

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

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