Безпечні мережеві файлові системи для Linux: що роблять люди?

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

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

Так, справді . Що ти все робиш?

Оскільки це специфічне запитання (що ти все робиш), давайте відповімо на нього: нічого. Більшість адміністраторів та користувачів просто не турбуються про безпеку NFS, тому всі використовують NFSv3. Це, як правило, контрольоване середовище (в тому сенсі, що в мережі в першу чергу можуть приєднуватися лише відомі машини). Якщо когось зловживають зловживанням інфраструктурою, його звільняють або в'язницю.

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

Ви, здається, тут задаєте два питання:

Що ми насправді використовуємо? і що це робить?

Що я фактично використовую, це CIFS, у моїх випадках використання POSIX є менш важливим, тому у мене не було проблем. NFS3 використовується в областях, де безпека не важлива, наприклад, мій сервер встановлення SLES. І нарешті, sshfs / gvfs для простого обміну користувачем-землею. Шифрування проводової лінії не вважається необхідним, тому це не є важливим фактором для нас.

Що стосується іншого питання, то, здається, існує шість основних вимог до того, що ви шукаєте:

1. Шифрує трафік на дроті.
2. Шифрує автентифікацію.
3. Семантика Posix.
4. Сильне впровадження серверних ACL.
5. Не є користувачем.
6. Насправді використовується.

Я підозрюю, що пункти 5 і 6 будуть вбивцями тут, але тут йдеться (також, це пункт, коли таблиця була б дуже зручною, але розмітка / 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 включали упаковку для нього. У неї є бородавки, але я виявив, що вони компенсуються більшою адміністративною гнучкістю, можливістю відокремлювати клієнтів та серверів повільними посиланнями, простотою резервного копіювання за межами сайтів та іншими позитивними AFSizmi.

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

Є декілька досить великих користувачів опенів - найбільший комерційний користувач, якого я знаю, - це Морган Стенлі.

Як щодо 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-адреси.

З усією повагою ви повністю дивитесь на цю проблему неправильно, і вам слід відійти від консолі на кілька годин.

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