id: Гость   вход   регистрация
текущее время 16:20 29/03/2024
Автор темы: Гость, тема открыта 13/11/2006 01:10 Печать
https://www.pgpru.com/Форум/UnixLike/КакуюОСИКрипто-ФСВыбратьДляФайловогоСервера
создать
просмотр
ссылки

Какую ОС и Крипто-ФС выбрать для файлового сервера?


Хочу организовать файловый сервер, с массивом данных на 5Тб, НО чтобы данные обязательно хранились в зашифрованном виде!


Заранее хочу сказать, что я не прощу "разжевывать" что-и-как делать, это было бы слишком нагло. ;) Но очень хочу услышать мнение специалистов насчет выбора ОС и Крипто-ФС! С настройкой всего буду сам разбираться.


Главные вопросы:
1. Какую операционку выбрать? Думаю что это будет FreeBSD или NetBSD.
2. Какую шифрованную файловую систему выбрать для массива? Понимаю, что модель с файлом-контейнером не подойдет стопудово. Какую крипто-фс выбрать даже мыслей нет, что лучше.


Сначала набросаю примерные требования к серверу.
Сервер будет работать только в качестве файлового сервера, и никаких доп. вещей на нем крутиться не будет. Хотя может быть будут еще SAMBA и FTP, но не обязательно.
Загрузка должна быть с флэшки или CD – при загрузке образ системы разворачивается в оперативку и дальше работает только в ней, никаких файлов подкачек и тд. На тойже флэшке (или на другой, не важно) хранится ключ для открытия основного массива с крипто-фс, после загрузки и открытия массива эта флэшка убирается от сервера подальше.


Как возможную "угрозу" рассматрию только то, что к "оппоненту" попадут сами диски и возможно флэшка с ОС и ключем к массиву (без пароля, ессно). Остальные угрозы не рассматриваются (типа внедрение троянов, получение доступа к работающему серверу, получение пароля под пытками, снятие отпечатков с оперативной памяти и тд).


Железо думаю здесь обсуждать смысла нет, но скажу, что дисковый массив будет строиться на 3ware и 12 дисках SATA2 по 500Гб (11 в raid5 + 1 запасной). Весь массив должен быть доступен как единое пространство.


PS Прошу прощения, если мой вопрос уже не раз обсуждался, но...


 
На страницу: 1, 2 След.
Комментарии
— serzh (13/11/2006 06:31, исправлен 13/11/2006 06:32)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
OS: Debian GNU/Linux,
шифрование: через dm-crypt, т.е. шифруется весь раздел и на него накладывается фс по желанию.
P. S. dm-crypt вроде есть и под *BSD.
— spinore (13/11/2006 09:58)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786


насколько я понимаю (могу ошибаться), некоторые фс имеют ограничения на максимальный объём файла или фс. Не знаю, есть ли механизмы это обойти.


Значит так, по поводу операционок:

1. Linux.
Если он, то ядро берёшь 2.4 а не 2.6, ибо стабильность и секъюрность имхо важна, особенно на серваке. Selinux прикручивать геморно если захотеть... а без него недостаточно защищено будет. + Отключить на выполнение стек надо будет. Насчёт фс не знаю даже что сказать... (Хз, поддерживает ли ядро 2.4 райзер). Но если райзер – то не самый последний, а тот что постабильнее. Иначе могут данные тазом накрыться. Linux – это единственный вариант, на которй можно поставить truecrypt, где есть deniable encryption, но, думаю, что вам это не нужно, поэтом не аргумент. По поводу криптофс: loop-aes без вариантов (кстати, это ещё вопрос, есть ли он в 2.4-ядре). dm-crypt и др. уязвимы и т.п. там есть существенные прорехи в алгоритмах и реализации. К loop-aes нареканий нет, двухуровневую аутентификацию он позволяет, алгоритмы и реализация надёжна. Насчёт того, позволяет ли он своп криптить и корень – не помню. Кажется, корень можно криптить. Но имхо здесь это опять не важно. Если грузиться, например, с cd, то всё отлично и корень криптовать не надо.

2. FreeBSD.
У неё там проблемы с поддержкой начались, вначле сняли поддержку с 4.11, потом и с остальных веток скоро снимут. Остаётся 7-я ветка, с которой пока не сказали будут ли снимать поддержку (про остальные ветки известны уже конкретные даты когда она прекратится). По поводу алгоритмов: есть GBDE и GELI (GELI только начиная с 6-й ветке). GBDE относительно не стабильна, глючит, время от времени намертво вешает систему (я под gbde отсидел полтора года :)). О таких проблемах gbde официально в т.ч. писали. Не знаю, пофиксили ли эти баги в поздних ветках (у меня была тогда FreeBSD 5.3). Что касается алгоритмов gbde – двухуровневую аутентификацию (когда то есть ключ можно сохранить отдельно на флэшке, ещё чем-то его зашифровав – соль пароля) GBDE НЕ позволяет, и идёт в топку однозначно. По поводу GELI: в целом лучше, чем gbde, насчёт стабильности не в курсах, а по алгоритмам точно лучше, двухуровневую делать позволяет, рут криптить и своп тоже.

3. OpenBSD.
Как раз недавно вышла OpenBSD 4.0 где пофиксили кучу проблем со слабостью алгоритма в её vnd. Теперь OpenBSD позволяет делать двухуровневую, свопэнкрипт там делается опцией в sysctl на лету за 5сек, на счёт криптов рута – не уверен. Но ранее OpenBSD не позволяла создавать криптофс размером больше 8 гигов. Скорей всего это не пофиксили (не знаю, можно ли это как-то обойти), потому вариант видать вам не подойдёт. Подробности про openbsd можно получить у нас тут: www.obsd.ru, задав вопрос в форуме. Я полтора года назад пользовался openbsd последний раз, сейчас я не во всех делах в курсах поэтому. Вообще, она очень активно развивается и у неё очень хорошая поддержка. К тому же она самая безопасная в сетевом плане. Но на сервере она может оказаться не очень производительной (но для десктопа и рутера – само то. Сам скоро буду себе на десктоп ставить).

4. NetBSD.
В общем-то она попроизводительнее будет чем OpenBSD (хотя немного уступает ей в плане сетевой защиты). Среди криптофс почти единственный выбор и отличный: CGD. Корень вроде криптануть нельзя, всё остальное можно. Про ограничения на размер криптофс не в курсе, но в любом случае не так как у OpenBSD, а вообще, даже не слышал об ограничениях. Среди файловых систем – также как и в OpenBSD доступна только ufs-1 (и, кажется, можно прицепить xfs (что я бы обязательно сделал, ибо она быстрее, а для файлов большого объёма – самая быстрая фс, даже лучше райзера)). CGD по алогритмам безупречен, иногда при создании новых криптофс могут возникать глюки, но они фиксятся перезагрузкой. После создания криптофс работает довольно стабильно (у меня за пол года работы с CGD нет к нему нареканий в отличе от GBDE во FreeBSD).
Сейчас у меня NetBSD на десктопе, двухуровневая включена, первичный ключ на флэшке, раздел с криптофс удаляется после отмонтирования (чтобы не светиться в таблице разделов), свопэнкрипт включён, остальное не криптуется. В принципе, можно посадить на криптофс всё окромя корневой, в сети лежат мануалы ра русском как это сделать. CCD для объединения существующих разделов есть. По поводу русификации и прочим тонкостям есть наш сайт: www.runetbsd.ru, где в т.ч. выложена куча документации по netbsd.

5. DragonFlyBSD.
Увеличивая призводительность дял расчётов и улучшая smp они, говорят, отключили многие системы защиты, поэтому в качестве защищёного сервера никак не годится. Является форком FreeBSD 4-й ветки.

6. Windows.
Это смешно, несмотря на то, сколько ей инфы посвящено на этом сайте.

В силу отказа от поддержки freebsd, и нестабильности linux я бы выбирал только из 2-х вариантов: Openbsd и netbsd. (Последние 2 года пользуюсь только BSD и для меня качество криптофс – первостепенно в ОС). Из оставшисхя Open и Net:
OpenBSD) выясняем об ограничения на максимальный размер криптофс и просто фс. Если этих ограничения для вас не критичны и openbsd удовлетворяет, то можно выбрать её. Но ск. всего ограничения в open на криптофс остались по размеру и вариант этот откидывается.
NetBSD) Всем хороша, в принципе, вариант близок к идеальному. CGD идёт на ура, проблем с алгоритмом заведомо нет. Но для интенсивно юзаемого ftp-сервера может быть кто-то будет жаловаться не медленную fs (что не так для raiser, xfs). Но если всё это совсем критично можно выбрать loop-aes и ядро linux 2.4 (если такой вариант поддерживается). NetBSD-шный CGD мне кажется лучше немного чем OpenBSDшный vnd, который только что начал поддерживать совремнный защиты от атак по словарю и т.д.

Касательно только криптофс (в порядке ухудшения качества алгоритмов):
1) loop-aes в Linux, CGD в NetBSD (точно хороши и без нареканий).
2) OpenBSDшный vnd (он только что вышел, не много что известно) и GELI во FreeBSD (алгоритмы в целом хороши, но детальный анализ я не слышал).
3) FreeBSDшный GBDE, dmcrypt и др. (имеют существенные недостатки в алгоритмах (watermarking, атака по словарю, отсутсие двухуровневой аутентификации и т.д.)).

Итог:
В любом случае loop-aes на Linux – один из лучших вариантов, не имеет нареканий на производительность, зато имеет некоторые нарекания на дрявость linux. Если вы его выберете – не проиграете, но обновлять linux-ядро нужно будет регулярно, могут порутать :)
NetBSDшный CGD в целом хорош. Я, если бы выяснилось, что ограничений на размер фс и криптофс нет (либо мне хватит существующих ограничений) выбрал бы именно NetBSD. Благо, в дефолтное ядро NetBSD CGD входит, PF доступен в качестве модуля. Последняя версия NetBSD, где исправлены быги в безопасности некоторые, 3.1. Ставить надо её, если выбирать NetBSD.

Примечание: в OpenBSD был портирован код CGD, но только в версию 3.2.

Самым лучшим по защите ftp-сервисом считается vsftpd. Я бы выбрал именно его. Аутентификацию там хорошо бы настроить по уму, но я не разбирался с этим (SASL и всё остальное).

Будете поднимать самбу – учтите – там много дыр. Систематически следить за оюновлениями надо. Хорошо бы как vsftpd, так и samba пускать не от рута и в чруте.


NetBSD это всё позволяет.

И ещё: обычно проблем не возникает, но лучше уточните, чтоб ыбло наверняка: поддерживает ли NetBSD всё ваше серверное железо.

Кстати, плюсами любой BSD является наличие PF. Он достаточно секъюрен и производителен. Вы можете резать пакеты даже на основе фингерпринтов коннектящихся осей (например, с linux 2.4 зайти будет к вам можно, а с linux 2.6 нельзя (если только слишком уж извратится и то не уверен)).

Если решите выбрать CGD на NetBSD – могу выложить более подробную инфу как поднять у себя cgd, включить крипты свопа и настроить русификацию. Я бы выбрал NetBSD.
С ccd в NetBSD помочь не смогу. PF немного настраивал, есть подгружаемый модель для него (ядро можно не перекомпиливать), cgd в дефолтном ядре также есть, перекомпилить прийдётся только раз для того чтобы при русификации переключалка по capslock работала. Ещё есть переведёный на русский guide по NetBSD. Могу ссылку дать.

P. S.: наверное, большинство из того что написал есть тривиальности, но так... на всякий случай.
— Гость (13/11/2006 12:50)   <#>
A кто что может сказать про Trustix Secure Linux ?
— unknown (13/11/2006 14:49, исправлен 13/11/2006 15:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
По поводу Linux: Selinux не самый лучший вариант.
Для ядра 2.4 вполне можно обойтись RSBAC или GrSecurity, в которых кроме мандатного доступа есть ещё масса полезных функций – рандомизация стека, защита от переполнений буфера, защищенный chroot.

loop-aes собирается модулем под ядро (не нужно накладывать патч) и есть под 2.4.
Поддерживается и шифрованный своп и шифрованный корневой раздел.

Сказать, что эта программа лучшая не могу. IMHO, Jari Ruusu очень хороший программист, но не криптограф. Протоколы loop-aes не анализировались. В исследованиях написано только про "невнятную документацию".
Например, для защиты от watermarking и улучшения диффузии данных используется не специально разработанный для этого режим шифрования, а массив ключей, хранящихся в файле gpg. Подозреваю, что там много разработок самого Jari (и его сподвижников), никем серьёзно не проанализированных.

Это очень напоминает разработку /dev/urandom и Truecrypt. Немного любительский уровень.

dm-crypt и др. уязвимы и т.п. там есть существенные прорехи в алгоритмах и реализации.

dm-crypt более продуманный, анализировался профессиональными криптографами, watermarking и пр. там пофиксены, но авторы принципиально не хотят делать продукт готовым для "production use". Некоторые уязвимости они действительно спокойно могут оставить открытыми до лучших времён. Местами дыряво, местами отстало, зато с видимостью большей профессиональности.

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

Про Win я тактично промолчу ;-)

A кто что может сказать про [WWW] Trustix Secure Linux ?

Ну был например аналогичный adamantix на основе Debian. Обычный Linux, но все программы перекомпилены с защитой от переполнений и др, много криптографии и секьюрное ядро по дефолту. Попытка создать аналог OpenBSD.

Проблема в том, что пока внесены исправления в родительский дистр, пока они дойдут до текущего и адаптируются к нему, проходит много времени, разработчики не успевали латать дыры. Проект развивался плохо. У меня насчёт всех "секьюрных" Линуксов такое подозрение. Проще пользоваться обычным и настроить всё нужное самому.
— unknown (13/11/2006 15:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Сейчас у меня NetBSD на десктопе, двухуровневая включена, первичный ключ на флэшке, раздел с криптофс удаляется после отмонтирования (чтобы не светиться в таблице разделов), свопэнкрипт включён,
>остальное не криптуется.

Когда открываете разные файлы, печатаете документы, посмотрите, что находится в /var/spool и в /tmp

Однозначно шифровать или симлинками выносить в память.
— spinore (13/11/2006 15:43, исправлен 13/11/2006 15:46)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786


Я имел в виду, что я не слышал ни от кого, что в loop-aes есть прорехи в алгоритмах. Про большинство криптофс я всё же слышал критические замечания. Наоборот, про loop-aes слышал положительные отзывы. Не более того :)


/tmp по умолчанию в NetBSD на memfs. А поскольку своп тоже криптуется, то не страшно.
В /etc/fstab:
swap /tmp mfs rw, nodev, nosuid, noexec,-s=100000 0 0
Маунт (df -h):
mfs:863 47M 402K 45M 0% /tmp

А с /var вообще надо разбираться, и, в частости, с /var/spool. Машина не совсем моя, надо дать права грузить её и не мне только. Поэтому я не стал включать крипты на /var при загрузке. Можно отключить всякие там syslog'и которые мне уже долго нозят своим существованием... но засунуть /var на крипты было бы логичнее. Ладно, скоро у меня будет только совсем свой комп и совсем рабочий, и тогда этой проблемы не будет.
— ParanoidAnt (14/11/2006 13:34)   профиль/связь   <#>
комментариев: 56   документов: 12   редакций: 2
Давайте по понятным причинам не будем говорить кто что слышал. Loop-AES по тестам быстрее, наклыдывать патч на ядро не надо, но утилиты из набора util-linux "патчить" придется. LUKS позволяет задать несколько паролей (loop-aes – нет ?).

Cтабильное ядро Linux сейчас всетаки 2.6, также "a primary focus of the v2.6 kernel is large server architectures". Применительно к данной задаче, стандартное ядро ветки 2.4 может работать сфайловой системой ДО 2Tb (в 2.6 – до 16Tb). Для задач связанных с хранением большых объемов данных также важна возможность в 2.6 настраивать планировщики ввода-вывода IO shedulers.

Из практического опыта – около десятка FreeBSD (5.3 и 6.1) серверов c дисками зашифрованными с помощью GBDE. Размеры шифрованных разделом 4-10 Gb. Encrypted swap на всех серверах. Жалоб нет.
— spinore (14/11/2006 13:54)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786


De facto или de uro?


А нестандартное ядро с 2.4 и больше?


Хороший обзор существующих криптофс + полив грязью GBDE от более-менее компетентных уст:
http://dreamcatcher.ru/index.p.....=view&id=40&Itemid=7


То есть существуют механизмы обойти любые ограничения на макимальный размер ФС? (криптофс?). Как это делается?
— ParanoidAnt (14/11/2006 14:50)   профиль/связь   <#>
комментариев: 56   документов: 12   редакций: 2
de juro: The latest stable version of the Linux kernel is: 2.6.18.2
de facto: все вендоры перешли на 2.6, в том числе "последний оплот 2.4" – RedHat

Стандартное ядро = vanilla kernel.

О каких ограничениях идет речь ? FreeBSD позволяет работать с 2-х терабайтной файловой системой
— unknown (14/11/2006 14:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
As stated several times before, I fully agree that 2.6 as it is now is a moving target which changes way too fast to be stable and secure enough. The often daily security updates have proven this. As
company, we only use 2.4 kernels for production, because we do not
trust 2.6.
Amon Ott

http://marc.theaimsgroup.com/?.....=116184644909122&w=2

Заявление разработчика RSBAC по поводу фактической нестабильности и непригодности 2.6 для критически важных сервисов лично для меня является авторитетным. Не знаю как для Вас.
— ParanoidAnt (14/11/2006 15:02)   профиль/связь   <#>
комментариев: 56   документов: 12   редакций: 2
ответ автора GBDE
— ParanoidAnt (14/11/2006 15:28)   профиль/связь   <#>
комментариев: 56   документов: 12   редакций: 2
unknown, Amon высказал свое мнение, причем аргументировал его скорее в эмоциональном ключе. Это его право. Утверждения о "фактической нестабильности и непригодности 2.6" я не вижу.

Мне не очень интересно спорить на тему 2.4 vs 2.6, я лишь хочу заметить что не все так однозначно.
— spinore (15/11/2006 09:10)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786


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


По определению, что есть ограничение на максимальный размер ФС? Это значит, что нельзя создать раздел больший данного, отформатированный под данную ФС, или, что вообще: данная ОС, независимо от разбиения на разделы, не может управлять совокупным дисковым пространством, отформатированным под данную ФС, большим чем некоторое. Поэтому я и спросил, можно ли обойти эти ограничения, и если можно, то всегда ли. Аналогичный вопрос про криптофс.
— ParanoidAnt (15/11/2006 14:27)   профиль/связь   <#>
комментариев: 56   документов: 12   редакций: 2
"ограничение на максимальный размер ФС" означает что ядро не в состоянии адресовать файловую систему более указанного размера (в силу простого ограничения размера счетчика), очевидно что кроме размера ФС важную роль здесь играет размер адресуемого блока, по этому в зарависимости от него верхний предел может ощутимо варироваться.
— spinore (15/11/2006 14:31)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Ответ на поставленный вопрос не даден :(
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3