Настройка и монтирование NFS. Что такое NFS? Network File System. Протокол сетевого доступа к файловым системам

пользователь может работать в разное время на разных компьютерах. С помощью файлового сервера решается сразу несколько задач:

регулярное резервное копирование всех данных: нереально выполнять эту операцию для нескольких десятков или сотен компьютеров, но вполне реально - с единственного сервера или нескольких серверов.
повышение надежности хранения данных: неразумно каждый компьютер сети оснащать RAID-массивом, ведь подавляющее большинство файлов в компьютере, таких, как установленные пакеты программ, проще установить заново, чем защищать их от сбоя; но будет вполне разумным укомплектовать файловый сервер аппаратным RAID-массивом или организовать там программный RAID-массив, хотя бы простое зеркалирование дисков.
уменьшение стоимости хранения данных: дорого и неэффективно в каждый компьютер устанавливать огромный диск на случай, если потребуется хранить много данных, но на сервере вполне можно установить масштабируемую дисковую подсистему большого объема.
обеспечение доступа к одним и тем же данным с любого компьютера.

Описание NFS

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

Версии NFS

NFS , разработанная компанией Sun Microsystems, оказалась настолько удачной, что ее реализации были воплощены разными компаниями почти во всех операционных системах. Существует несколько принципиально разных реализаций NFS . Достаточно распространена версия NFS 2.0, хотя уже в Solaris 2.5 была введена NFS 3.0. В последующих версиях Solaris, включая Solaris 9, в NFS были внесены существенные дополнения, но сам протокол остался совместимым с реализациями NFS 3.0 в других системах. Начиная с NFS 3.0, поддерживается передача пакетов посредством TCP и UDP, ранее поддерживался только UDP.

Будьте внимательны ! В сети следует использовать клиенты и серверы NFS одной и той же версии . NFS 2.0 можно встретить в старых системах, например, в HP-UX 10.0. Совместная работа систем, использующих разные версии NFS , нежелательна.

Совместимость NFS и других служб разделяемых каталогов

NFS по смыслу и по организации работы похожа на разделяемые каталоги (shared folders) в системах Windows, но эти службы используют совершенно разные протоколы работы и между собой не совместимы. Однако существует несколько программных продуктов, которые устанавливают поддержку NFS в системах Windows, поэтому применение NFS в сети с различными операционными системами не представляет проблемы, надо только помнить о необходимости использовать одинаковые версии NFS .

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

Поскольку компьютеры на рабочих местах сотрудников в России обычно управляются Windows-системами, в качестве файловых серверов часто используются также Windows-системы. Однако нередко возникает желание установить UNIX на файл-сервер, чтобы повысить надежность, сократить затраты на оборудование или использовать этот же сервер для ряда других корпоративных нужд: в качестве web-сервера, сервера баз данных и т.п. Чтобы не устанавливать дополнительное ПО для поддержки NFS , в таком случае достаточно установить пакет samba на UNIX-машину. Он позволит ей "прикинуться" Windows-сервером так, чтобы все клиентские компьютеры воспринимали его как самый обычный файл-сервер или принт-сервер Windows-сети. Пакет samba обеспечивает поддержку "родного" для Windows-сетей протокола SMB.

В тех случаях, когда в сети работают несколько UNIX-компьютеров и им нужно обращаться к одному файл-серверу, имеет смысл использовать механизм NFS (network file system).

NFS не очень устойчив к сбоям сети, требует ее бесперебойной работы и предполагает быстрое соединение между клиентом и сервером. Использование NFS для монтирования файловых систем вне локальной сети, например, через Интернет, технически осуществимо, но не очень рационально и небезопасно.

Терминология NFS

После настройки NFS-сервера UNIX-компьютер будет предоставлять доступ внешним пользователям к некоторым каталогам своей файловой системы . Такое предоставление доступа называется "экспортом": говорят, что система экспортирует свои каталоги. Как именно каталоги будут экспортироваться, определяется списком, который задает системный администратор. В большинстве систем UNIX этот список содержится в файле /etc/exports , но в Solaris он находится в другом файле - /etc/dfs/dfstab .

NFS работает посредством механизма удаленного вызова процедур ( RPC - Remote Procedure Call ).

Что такое RPC

Идеология RPC очень проста и привлекательна для программиста. Как обычно работает сетевое приложение? Оно следует некоему протоколу (например, HTTP): формирует пакет с запросом, вызывает системную функцию установления соединения, затем функцию отправки пакета, затем ждет ответного пакета и вызывает функцию закрытия соединения. Это значит, что вся работа с сетью является заботой программиста, который пишет приложение: он должен помнить о вызове функций сетевого API системы, думать о действиях в случае сбоев сети.

RPC предполагает иной способ обмена данными между клиентом и сервером. С точки зрения программиста, приложение клиента, работающее с помощью RPC , вызывает функцию на сервере, она выполняется и возвращает результат. Пересылка запроса на выполнение функции через сеть и возврат результатов от сервера клиенту происходит незаметно для приложения, поэтому последнее не должно беспокоиться ни о сбоях сети, ни о деталях реализации транспортного протокола.

Для того чтобы обеспечить прозрачность пересылки данных через сеть, придумана двухступенчатая процедура. На сервере любое приложение, предоставляющее свой сервис через RPC , должно зарегистрироваться в программе, которая называется транслятором портов (port mapper). Функция этой программы - устанавливать соответствие между номером процедуры RPC , которую запросил клиент, и номером TCP или UDP порта, на котором приложение сервера ждет запросов. Вообще говоря, RPC может работать не только с TCP или UDP. В Solaris как раз реализована работа на базе механизма TI (TransportIndependent), поэтому в Solaris транслятор портов называется rpcbind , а не portmap , как в Linux или FreeBSD.

Приложение, которое регистрируется у транслятора портов, сообщает ему номер программы, номер версии и номера процедур, которые могут обрабатываться данной программой. Эти процедуры будут впоследствии вызываться клиентом по номеру. Кроме этого, приложение сообщает номера портов TCP и UDP, которые будут использоваться для приема запросов на выполнение процедур.

Клиент, желающий вызвать выполнение процедуры на сервере, сначала отправляет запрос транслятору портов на сервер, чтобы узнать, на какой TCP или UDP порт надо отправить запрос. Транслятор портов запускается при старте системы и всегда работает на стандартном порту 111. Получив ответ от него, клиент отправляет запрос на тот порт, который соответствует требуемому приложению. Например, сервер NFS работает на порту 2049.

Процедура монтирования общего каталога через NFS

Прежде чем мы перейдем к описанию настроек сервера и клиентов NFS , следует понять, как осуществляется монтирование удаленных файловых систем в принципе.

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

Удобное решение для доступа к распределенной файловой системе

Файловая система - это необходимость. Мы работаем на компьютерах, предоставляющих доступ к принтерам, камерам, базам данных, удаленным датчикам, телескопам, компиляторам и мобильным телефонам. Эти устройства имеют мало общего - в частности, многие из них стали реальностью уже после того, как Интернет стал повсеместным явлением (например, электронные фотокамеры и мобильные устройства, выполняющие функции маленьких компьютеров). Однако всем им необходима файловая система для хранения и защищенного доступа к информации.

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

Сетевые файловые системы и другие священнодействия

Во многом обмен данными является не более чем копированием информации на большие расстояния. Сетевые протоколы были не единственным средством, благодаря которому стал возможен всеобщий обмен данными. В конце концов, каждая компьютерная система должна преобразовывать датаграммы в что-либо понятное для операционной системы на другом конце. TCP - это очень эффективный протокол передачи, но он не оптимизирован для обеспечения быстрого доступа к файлам или для удаленного управления прикладным программным обеспечением.

Распределенные вычисления против сетевых

Традиционные сетевые протоколы не много могут предложить для организации вычислений, распределенных между компьютерами и, тем более, между сетями. Только безрассудные программисты полагались бы на протокол передачи данных и оптические кабели для организации параллельных вычислений. Обычно мы полагаемся на последовательную модель, в которой после установления соединения начинают работать протоколы канального уровня, выполняющие довольно сложную процедуру приветствия между сетевыми картами. Параллельные вычисления и распределенные файловые системы больше не зависят от IP или Ethernet. В настоящее время мы можем их просто не принимать во внимание, говоря о производительности. Однако проблемы защиты - это другое дело.

Одним из звеньев головоломки является способ организации доступа к файлам в компьютерной системе. Сейчас для системы, осуществляющей доступ к файлам, является несущественным, доступны ли необходимые файлы на одном компьютере, или они расположены по каким-либо причинам на нескольких компьютерах. В настоящее время семантика файловой системы и структуры данных файловой системы являются двумя очень разными темами. Семантика файловой системы Plan 9 или распределенной файловой системы AFS-стиля (Andrew File System) скрывает способ организации файлов или способ отображения файловой системы на аппаратное и сетевое обеспечение. NFS не обязательно скрывает способ хранения файлов и каталогов на удаленных файловых системах, но она также не раскрывает действительный аппаратный способ хранения файловых систем, каталогов и файлов.

NFS: Решение UNIX-проблемы

Доступ к распределенной файловой системе, тем не менее, требует несколько больше пары команд, разрешающих пользователям монтировать каталог, который расположен на другом компьютере в сети. Sun Microsystems столкнулась с этой проблемой несколько лет назад, когда начинала распространять нечто, названное Remote Procedure Calls (RPCs), и NFS.

Основной проблемой, которую пытались решить в Sun, был способ подключения нескольких UNIX-компьютеров для организации единой распределенной рабочей среды без необходимости переписывать семантику файловой системы UNIX и добавлять слишком большое количество структур данных, специфичных для распределенных файловых систем - целостность каждой системы должна была быть сохранена, одновременно предоставляя пользователям возможность работы с каталогом на другом компьютере без возникновения нежелательных задержек или ограничений в их рабочем процессе.

Конечно же, NFS делает больше, чем предоставление доступа к текстовым файлам. Вы можете также распределять по NFS "запускаемые" приложения. Процедуры системы защиты служат для предохранения сети от вредоносного вмешательства исполняемых файлов. Но как именно это происходит?

NFS - это RPC

NFS традиционно определяется как RPC-приложение, требующее наличия TCP для NFS-сервера, а также либо TCP, либо другого не перегружающего сеть протокола для NFS-клиента. Организация Internet Engineering Task Force (IETF) опубликовала Request for Comments (RFC) для RPC в RFC 1832. Другой жизненно важный для функционирования NFS-реализации стандарт описывает форматы данных, используемые NFS; он был опубликован в RFC 1831 как документ "External Data Representation" (XDR).

Другие RFC имеют дело с защитой и алгоритмами шифрования, используемыми при обмене информацией для аутентификации во время NFS-сессий, но мы сначала остановимся на базовых механизмах. Одним из протоколов, которые нас интересуют, является протокол Mount , описанный в Приложении 1 RFC 1813.

Этот RFC описывает, какие протоколы обеспечивают функционирование NFS, но в нем не описывается, как NFS функционирует в настоящее время . Вы уже узнали кое-что важное, а именно - NFS-протоколы задокументированы в виде IETF-стандартов. После того, как последняя версия NFS застряла на цифре 3, RPC-протоколы не развивались дальше информационной фазы RFC и воспринимались, в основном, как не выходящие за пределы интересов (предположительно) огромной инженерной рабочей группы Sun Microsystems и патентованных разновидностей UNIX. С 1985 года Sun выпустила несколько версий NFS, на несколько лет предвосхитившей большинство современных разновидностей файловых систем. Sun Microsystems передала контроль над NFS организации IETF в 1998 году, и большая часть работы над NSF версии 4 (NFSv4) проводилась под эгидой IETF.

То есть, работая сегодня с RPC и NFS, вы работаете с версией, которая отражает интересы компаний и групп, не имеющих отношения к Sun. Однако многие инженеры Sun сохраняют глубокий интерес к разработке NFS.

NFS версии 3

NFS в своем воплощении в виде версии 3 (NFSv3) не сохраняет свое состояние (не является stateful), а NFSv4 сохраняет. Это фундаментальное выражение сегодня едва ли кого-то удивляет, хотя мир TCP/IP, на котором построена NFS, по большей части не сохраняет своего состояния (stateless) - факт, который помогает компаниям, производящим программное обеспечение для анализа трафика и системы защиты, чувствовать себя довольно хорошо.

Протокол NFSv3 должен был полагаться на несколько дополнительных протоколов для прозрачного монтирования каталогов на удаленных компьютерах, чтобы не зависеть от используемых на них механизмов файловых систем. NFS не всегда преуспевала в этом. Хороший пример - протокол Mount вызывал начальный идентификатор файла, в то время как протокол Network Lock Manager занимался блокировкой файла. Обе операции нуждались в текущем состоянии, которое протокол NFSv3 не предоставлял. Следовательно, имели место сложные взаимодействия между уровнями протоколов, которые не отражали аналогичные механизмы потоков данных. Кроме того, если добавить тот факт, что создание файла и каталога в Microsoft® Windows® осуществляется совершенно не так, как в UNIX, ситуация еще более усложнится.

Протокол NFSv3 должен был использовать порты для предоставления некоторых из его вспомогательных протоколов; при этом получается довольно сложная картина портов, уровней протоколов и сопутствующих всему этому вопросов безопасности. Сегодня от такой модели функционирования отказались, и все операции, которые ранее выполняли реализации вспомогательных протоколов через индивидуальные порты, управляются протоколом NFSv4 через один хорошо известный порт.

Протокол NFSv3 был также готов для работы с файловыми системами, поддерживающими Unicode - преимущество, которое до конца 1990-х годов оставалось в некоторой степени чисто теоретическим. Он хорошо соответствовал семантике файловой системы UNIX и явился причиной создания конкурирующих реализаций файловых систем, таких как AFS и Samba. Не удивительно, что Windows-поддержка была бедной, но файловые серверы Samba обеспечивали общий доступ к файлам для систем UNIX и Windows.

NFS версии 4

Протокол NFSv4 является, как мы отметили, протоколом, сохраняющим свое состояние. Такое поведение сделали возможным несколько радикальных изменений. Мы уже упоминали, что должны вызываться вспомогательные протоколы, так как процессы пользовательского уровня были устранены. Вместо них все операции по открытию файла и довольно много RPC-вызовов были реализованы в виде операций файловой системы уровня ядра.

Все NFS-версии определяли каждую единицу работы в понятиях операций RPC-клиента и сервера. Каждый NFSv3-запрос требовал довольно значительного количества RPC-вызовов и вызовов операций открытия портов для выдачи результата. Версия 4 упростила это, введя понятие так называемой составной (compound) операции, к которой относится большое количество операций над объектами файловой системы. Прямым эффектом, разумеется, стало значительно меньшее количество RPC-вызовов и меньший объем данных, которые нужно передавать по сети, даже при том, что каждый RPC-вызов нес, по сути, больше данных, выполняя значительно больший объем работы. Было приблизительно подсчитано, что RPC-вызовы в NFSv3 требовали в пять раз большее количество клиент-серверных взаимодействий по сравнению с составными RPC-процедурами.

RPC, на самом деле, больше не имеет такой важности и, по существу, служит оболочкой (wrapper) над несколькими операциями, инкапсулированными в NFSv4-стеке. Также это изменение сделало стек протокола намного менее зависимым от семантики используемой файловой системы. Но это не означает, что операции файловой системы других операционных систем были проигнорированы: например, для совместного использования Windows-ресурсов требуется сохранение состояния при вызовах открытия ресурса. Сохранение состояния не только облегчает анализ трафика, но при реализации на уровне семантики файловой системы делает операции файловой системы значительно более доступными для контроля. Вызовы открытия ресурсов с сохранением состояния позволяют клиентам кэшировать файловые данные и состояние - то, что в противном случае происходило бы на сервере. В реальной жизни (в которой Windows-клиенты распространены повсеместно) организация прозрачной и унифицированной работы NFS-серверов с разделяемыми Windows-ресурсами стоит потраченного вами времени на настройку NFS-конфигурации.

Использование NFS

Установка NFS, в общем, аналогична установке Samba. На стороне сервера вы определяете файловые системы или каталоги для экспорта или совместного использования ; клиентская сторона монтирует эти каталоги. После монтирования удаленным клиентом NFS-каталога этот каталог становится доступен так же, как любой другой каталог локальной файловой системы. Настройка NFS на сервере - это простой процесс. Как минимум, вы должны создать или отредактировать файл /etc/exports и запустить NFS-демон. Для настройки более защищенной NFS-службы вы должны также отредактировать файлы /etc/hosts.allow и /etc/hosts.deny. NFS-клиент требует выполнения только команды mount . Дополнительная информация и параметры описаны в оперативной документации по Linux® (man page).

NFS-сервер

Записи в файле /etc/exports имеют понятный формат. Для организации совместного доступа к файловой системе измените файл /etc/exports и опишите файловую систему (с параметрами) в следующем общем формате:

каталог (или файловая система) client1 (option1, option2) client2 (option1, option2)

Общие параметры

Для настройки вашей NFS-реализации доступно несколько общих параметров. К ним относятся:

secure: Этот параметр (по умолчанию) использует для NFS-соединения доступный порт TCP/IP, меньший 1024. Указание insecure запрещает это.
rw: Этот параметр разрешает NFS-клиентам доступ для чтения/записи. Доступ по умолчанию - только для чтения.
async: Этот параметр может повысить производительность, но он может также вызвать потерю данных при перезапуске NFS-сервера без предварительной процедуры остановки NFS-демона. Настройка по умолчанию - sync .
no_wdelay: Этот параметр отключает задержку при записи. Если установлен режим async , NFS игнорирует этот параметр.
nohide: Если вы монтируете один каталог поверх другого, старый каталог обычно скрывается или выглядит пустым. Для запрета такого поведения разрешите параметр hide .
no_subtree_check: Этот параметр отключает контроль подкаталогов, выполняющийся для некоторых проверок системой защиты, которые вы, возможно, не хотите игнорировать. Параметр по умолчанию - разрешить контроль подкаталогов.
no_auth_nlm: Этот параметр при значении insecure_locks указывает NFS-демону не проводить аутентификацию во время запросов на блокировку. Параметр по умолчанию - auth_nlm или secure_locks .
mp (mountpoint=path) : При явном объявлении этого параметра NSF требует монтирования экспортируемого каталога.
fsid=num: Этот параметр обычно используется при организации системы восстановления после сбоя NFS. Если вы хотите реализовать восстановление после сбоя для NFS, обратитесь к документации по NFS.

Отображение пользователей

Через отображение пользователей в NFS вы можете отождествить псевдопользователя или реального пользователя и группы с пользователем, работающим с NFS-томом. NFS-пользователь имеет права пользователя или группы, которые позволяет отображение. Использование единого (generic) пользователя и группы для NFS-томов обеспечивает уровень защиты и гибкость без значительных усилий по администрированию.

При использовании файлов на NFS-монтированной файловой системе пользовательский доступ обычно "подавляется" (squashed). Это означает, что пользователь обращается к файлам как анонимный пользователь, который имеет доступ к этим файлам только по чтению. Это поведение особенно важно для пользователя root. Однако, существуют ситуации, когда вы хотите, чтобы пользователь обращался к файлам на удаленной системе как root или какой-либо другой определенный пользователь. NFS позволяет указать пользователя (по идентификационному номеру пользователя (UID) и идентификационному номеру группы (GID)) для доступа к удаленным файлам, и вы можете запретить нормальное поведение "подавления" по умолчанию.

К параметрам отображения пользователей относятся:

root_squash: Этот параметр не позволяет пользователю root обращаться к смонтированному NFS-тому.
no_root_squash: Этот параметр позволяет пользователю root обращаться к смонтированному NFS-тому.
all_squash: Этот параметр, полезный для NFS-томов с открытым доступом, подавляет все UID и GID и использует только учетную запись анонимного пользователя. Установка по умолчанию - no_all_squash .
anonuid и anongid: Эти параметры меняют UID и GID анонимного пользователя на указанную учетную запись.

В листинге 1 приведены примеры записей /etc/exports.

Листинг 1. Примеры записей /etc/exports

/opt/files 192.168.0.* /opt/files 192.168.0.120 /opt/files 192.168.0.125(rw, all_squash, anonuid=210, anongid=100) /opt/files *(ro, insecure, all_squash)

Первая запись экспортирует каталог /opt/files для всех хостов сети 192.168.0. Следующая запись экспортирует /opt/files для одного хоста: 192.168.0.120. Третья запись указывает хост 192.168.0.125 и предоставляет доступ по чтению/записи к файлам с правами пользователя, имеющего user id=210 и group id=100 . Последняя запись используется для общедоступного каталога и разрешает доступ только по чтению и только под учетной записью анонимного пользователя.

NFS-клиент

Предостережения

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

Для использования NFS в роли клиента на клиентском компьютере должен выполняться rpc.statd и portmap. Вы можете выполнить команду ps -ef для проверки присутствия двух этих демонов. Если они работают (как и должны), вы можете монтировать экспортируемый сервером каталог при помощи следующей общей команды:

mount server:directory local mount point

Вообще говоря, при монтировании файловой системы вы должны работать как пользователь root. На удаленном компьютере вы можете использовать следующую команду (в предположении, что NFS-сервер имеет IP-адрес 192.168.0.100):

mount 192.168.0.100:/opt/files /mnt

Ваш дистрибутив системы может потребовать указания типа файловой системы при ее монтировании. Если это так, используйте команду:

mount -t nfs 192.168.0.100:/opt/files /mnt

Удаленный каталог должен монтироваться безо всяких проблем, если вы корректно настроили сервер. Теперь выполните команду cd для перехода в каталог /mnt, затем команду ls для просмотра файлов. Для того чтобы сделать такое монтирование постоянным, вы должны изменить файл /etc/fstab и создать запись, аналогичную следующей:

192.168.0.100:/opt/files /mnt nfs rw 0 0

Примечание: Дополнительная информация по записям /etc/fstab приведена в оперативной справке по fstab.

Критика NFS

Критика способствует улучшению

Критика, связанная с защищенностью NFS, была причиной многих улучшений в NSFv4. Создатели новой версии провели реальные мероприятия по усилению защищенности клиент-серверных взаимодействий. Фактически, они решили реализовать абсолютно новую модель системы защиты.

Для понимания модели системы защиты вы должны ознакомиться с интерфейсом прикладного программирования Generic Security Services (GSS-API) версии 2, редакции 1. GSS-API полностью описан в RFC 2743, который, к сожалению, является одним из наиболее сложных для понимания RFC-документов.

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

Соединения между NFS-клиентами и серверами защищаются посредством так называемой (довольно поверхностно) системы защиты strong RPC. NFSv4 использует стандарт Open Network Computing Remote Procedure Call (ONCRPC), определенный в RFC 1831. Система защиты должна была быть усилена, поэтому вместо простой аутентификации (известной как AUTH_SYS ) как обязательная часть протокола NFSv4 была определена и реализована разновидность основанной на GSS-API системы защиты, известная под названием RPCSEC_GSS . К наиболее важным доступным в NFSv4 механизмам защиты относятся Kerberos версии 5 и LIPKEY.

Если Kerberos имеет ограничения при использовании в Интернет, то у LIPKEY есть приятное преимущество - работая как Secure Sockets Layer (SSL), он запрашивает у пользователей их имена и пароли, избегая, в то же время, TCP-зависимости от SSL - зависимости, которую NFSv4 не разделяет. Вы можете настроить NFS на реализацию разновидностей системы защиты, если RPCSEC_GSS не требуется. Предыдущие версии NFS не имели такой возможности и, следовательно, не могли обеспечить качественную защиту, целостность данных, требования по аутентификации или типы шифрования.

Протокол NFSv3 подвергся существенной критике в области защищенности. Если NFSv3-серверы работали по TCP, было абсолютно реально запускать NFSv3-сети по Интернет. К сожалению, нужно было также открывать несколько портов, что приводило к появлению нескольких хорошо разрекламированных дыр в системе защиты. Сделав порт 2049 обязательным для NFS, стало возможным использование NFSv4 с брандмауэрами (firewall) без необходимости уделять слишком большое внимание тому, какие порты прослушивали другие протоколы, например, протокол Mount. Таким образом, исключение протокола Mount имело несколько положительных эффектов:

Обязательные механизмы строгой аутентификации: NFSv4 сделал механизмы строгой аутентификации обязательными. Разновидности Kerberos довольно распространены. Также должен поддерживаться Lower Infrastructure Public Key Mechanism (LIPKEY). NFSv3 никогда не поддерживал что-то большее, чем стандартное UNIX-шифрование для аутентификации доступа - это порождало основные проблемы защиты в больших сетях.
Обязательные схемы списков контроля доступа (access control list - ACL) в стиле Microsoft Windows NT : Хотя NFSv3 позволял реализовать строгое шифрование для аутентификации, он не использовал схемы ACL-доступа в стиле Windows NT. Списки ACL в стиле Portable Operating System Interface (POSIX) иногда реализовывались, но никогда не были общепринятыми. NFSv4 сделал ACL-схемы в стиле Windows NT обязательными.
Договорные механизмы и стили аутентификации : NFSv4 предоставил возможность договариваться о механизмах и стилях аутентификации. В NSFv3 было невозможно сделать что-то большее, чем ручное определение используемого стиля шифрования. Системный администратор должен был затем согласовывать протоколы шифрования и защиты.

До сих пор ли NFS вне конкуренции?

NFSv4 заменяет NFSv3 на большинстве систем UNIX и Linux. Как сетевая файловая система NSFv4 имеет мало конкурентов. Жизнеспособным конкурентом могла бы считаться Common Internet File System (CIFS)/Server Message Block (SMB), исходя из того, что она присутствует во всех разновидностях Windows и (в настоящее время) в Linux. AFS никогда не имела большого коммерческого влияния; в ней придавалось особое значение элементам распределенных файловых систем, которые облегчали миграцию и репликацию данных.

Готовые к использованию Linux-версии NFS были выпущены после достижения ядром версии 2.2, но одной из наиболее общих неудач версий ядра Linux было то, что Linux принял NFSv3 довольно поздно. Фактически, прошло много времени до того, когда Linux стал полностью поддерживать NSFv3. С появлением NSFv4 этот недостаток был быстро устранен и полную поддержку NSFv4 реализовали не только в Solaris, AIX и FreeBSD.

NFS считается в настоящее время зрелой технологией, которая имеет довольно большое преимущество: она защищенная и удобная - большинство пользователей сочли удобным использовать одну защищенную регистрацию для доступа в сеть и для использования ее возможностей, даже когда файлы и приложения расположены на различных системах. Хотя это может выглядеть как недостаток по сравнению с распределенными файловыми системами, скрывающими структуры систем от пользователей, не забывайте о том, что многие приложения используют файлы, находящиеся на разных операционных системах и, следовательно, на разных компьютерах. NFS облегчает работу с различными операционными системами без необходимости слишком беспокоиться о семантике файловых систем и характеристиках их производительности.

Каждый знает, что в UNIX-системах файловая система логически представляет собой набор физических файловых систем, подключенных к одной точке. Одна из самых основных прелестей такой организации, на мой взгляд, состоит в возможности динамически модифицировать структуру существующей файловой системы. Также, благодаря усилиям разработчиков, мы на сегодняшний день имеем возможность подключить ФС практически любого типа и любым удобным способом. Говоря «способом», я прежде всего хочу подчеркнуть возможность работы ядра ОС с файловыми системами посредством сетевых соединений.

Множество сетевых протоколов предоставляют нам возможность работы с удаленными файлами, будь то FTP, SMB, Telnet или SSH. Благодаря способности ядра, в конечном итоге, не зависеть от типа подключаемой ФС, мы имеем возможность при помощи программы mount подключать что угодно и как угодно.

Сегодня мне хочется рассказать об NFS — Network File System. Эта технология позволяет подключать отдельные точки ФС на удаленном компьютере к файловой системе локального компьютера. Сам протокол NFS позволяет выполнять операции с файлами достаточно быстро, безопасно и надежно. А что нам еще нужно? :-)

Что необходимо для того, чтобы это работало

Чтобы долго не разглагольствовать на тему версий NFS и их поддержку в различных ядрах, сразу сделаем допущение, что версия вашего ядра не ниже 2.2.18. В официальной документации разработчики обещают полную поддержку функционала NFS версии 3 в этом ядре и более поздних версий.

Установка

Для запуска сервера NFS в моей Ubuntu 7.10 — the Gutsy Gibbon понадобилось установить пакеты nfs-common и nfs-kernel-server. Если же нужен только клиент NFS, то nfs-kernel-server устанавливать не нужно.

Настройка сервера

После того, как все пакеты успешно установлены, необходимо проверить, запущен ли демон NFS:

/etc/init.d/nfs-kernel-server status

Если демон не запущен, его нужно запустить командой

/etc/init.d/nfs-kernel-server start

После того, как все успешно запустилось, можно приступать к экспорту файловой системы. Сам процесс очень прост и занимает минимум времени.

Основной файл конфигурации NFS-сервера располагается в /etc/exports и имеет следующий формат:

Directory machine1(option11,option12) machine2(option21,option22)

directory — абсолютный путь к каталогу ФС сервера, к которому нужно дать доступ

machineX — DNS-имя или IP-адрес клиентского компьютера, с которого разрешается доступ

optionXX — параметры экспорта ФС, наиболее часто используемые из них:

ro — доступ к файлам разрешается только для чтения
rw — доступ предоставляется на чтение/запись
no_root_squash — по умолчанию, если вы подключаетесь к ресурсу NFS от имени root, сервер, безопасности ради, на своей стороне будет обращаться к файлам от имени пользователя nobody. Однако, если включить эту опцию, то обращение к файлам на стороне сервера будет будет производиться от имени root. Аккуратней с этой опцией.
no_subtree_check — по умолчанию, если вы на сервере экспортируете не весь раздел, а только часть ФС, демон будет проверять, является ли запрошенный файл физически размещенным на том же разделе или нет. В случае, если вы экспортируете весь раздел или точка подключения экспортируемой ФС не затрагивает файлы с других физических томов, то можно включить эту опцию. Это даст вам увеличение скорости работы сервера.
sync — включайте эту опцию, если есть вероятность внезапного обрыва связи или отключения питания сервера. Если эта опция не включена, то очень повышается риск потери данных при внезапной остановке сервера NFS.

Итак, допустим, нам нужно дать доступ компьютеру ashep-desktop к каталогу /var/backups компьютера ashep-laptop. Доступ к каталогу необходим для копирования резервных копий файлов с ashep-desktop. У меня файл получился следующим:

/var/backups ashep-desktop(rw,no_subtree_check,sync)

После добавления строки в /etc/exports необходимо перезапустить сервер NFS для вступления изменений в силу.

/etc/init.d/nfs-kernel-server restart

Вот и все. Можно приступать к подключению экспортированной ФС на клиентском компьютере.

Настройка клиента

На клиентской стороне удаленная файловая система монтируется так же, как и все остальные — командой mount. Также, никто не запрещает вам использовать /etc/fstab в случае, если подключать ФС нужно автоматически при загрузке ОС. Итак, вариант с mount будет выглядеть так:

Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

Если все прошло успешно и вам необходимо выполнять подключение к удаленной ФС автоматически при загрузке — просто добавляем строку в /etc/fstab:

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

Что еще

Вот и получился практический, малюсенький обзор возможностей NFS. Конечно, это всего лишь малая часть того, что умеет NFS. Этого достаточно для использования дома или в небольшом офисе. Если же вам этого недостаточно, рекомендую в первую очередь прочесть

NFS позволяет предоставить общий доступ к каталогам Unix-машины. Небезопасность NFS, и в частности NIS, связана с RPC - по количеству всевозможных эксплоитов RPC представляется негласным лидером (если не считать Sendmail). Так как эти протоколы предназначены для внутренних сетей, защищать их придется от «своих» пользователей. Хотя перед их применением нужно решить, действительно ли они нужны.

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

Файловая система NFS .

Сетевая файловая система (Network File System, NFS) была разработана компанией Sun как средство доступа к файлам, размещенным на прочих Unix-машинах в пределах локальной сети. При разработке NFS безопасность вообще не учитывалась, что с годами стало причиной многих уязвимостей.

NFS может работать по протоколу TCP или UDP, она использует систему RPC, а это означает, что должны быть запущены следующие часто уязвимые приложения: portmapper, nfs, nlockmgr (lockd), rquotad, statd и mountd.

Не надо запускать NFS - нужно найти альтернативное решение. Если же NFS все-таки нужна, здесь будет рассказано о том, как нужно минимизировать риск ее использования.

/etc/exports

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

Каталоги «на экспорт» определяются в файле /etc/exports. Формат каждой записи прост: имя каталога, список пользователей, которым разрешен доступ и режим доступа. К примеру:

Полный доступ (чтение/запись) к каталогу /home/user разрешен машине с IP-адресом 10.0.0.6. Самое лучшее - это не давать полный доступ, а ограничиться доступом «только чтение» (rо). Кроме данного, можно также указать следующие опции:

Secure - запрос на монтирование (mount) должен исходить из привилегированного порта (с номером до 1024). Это означает, что команду на монтирование ввел пользователь с привилегиями root.
Root_squash - запрос пользователя root будет расцениваться как запрос анонимного пользователя. Это позволяет причинить наименьший вред системе. Эта опция должна быть включена.
All_squash - все запросы (не только от пользователя root) будут расцениваться как исходящие от анонимного пользователя. Полезно применять для публично экспортируемых каталогов.

Если крекер с правами root получит доступ к машине, которой дан rw-доступ к каталогу, указанному в /etc/exports, он получит полный контроль над файловой системой, поэтому нельзя экспортировать корневой каталог (/), и системно-важные каталоги, к примеру /usr, /bin, /sbin, /lib, /opt и /etc. Хорошо для экспорта подходят домашние каталоги пользователей.

Со стороны клиента монтирование общей файловой системы нужно выполнять указанием опции -о nosuid:

# mount -t nfs -о nosuid 10.0.0.3:/home/user/files /mnt/home/frank

Это не даст крекеру, получившему доступ к NFS-серверу, получить root-доступ к клиентам.

Ограничение доступа .

Независимо от сервиса для ограничения доступа к машине нужно применять IPTables. В случае с NFS-сервером это особенно важно. При применении IPTables надо помнить, что NFS-демон использует порт 2049/TCP/UDP.

Некоторые RPC-сервисы, к примеру portmapper и NFS, используют постоянные порты (113 и 2049/tcp/udp соответственно), но у остальных RPC-сервисов порты не постоянны, что затрудняет фильтрацию пакетов с помощью IPTables. Единственное, что известно, - это то, что RPC используют порты в диапазоне 32768-65535.

Если используется ядро 2.4.13 или более новое, то с помощью опции -р <порт> можно точно указать порт для каждого RPC-сервиса.

Рассмотрим функцию start() из файла /etc/rc.d/init.d/nfslock, используемую для запуска nsflock:

start () {

#. Start daemons .

if [ "$USERLAND_LOCKD" ]; then

echo -n $"Starting NFS locking: "

daemon rpc.lockd

echo -n $"Starting NFS statd: "

daemon rpc.statd

echo [ $RETVAL -eq 0 ] && touch /var/touch/lock/subsys/nfslock

return $RETVAL }

Для того, чтобы заставить демон statd употреблять конкретный порт, можно употреблять опцию -р, к примеру daemon rpc.statd -p 32800 (или какой угодно другой - какой больше нравится). Точно так же нужно установить порт для mountd, nfsd, rquotad - все они запускаются из сценария /etc/rc.d/init.d/nfs:

start () {

# Start daemons.

action -n $"Starting NFS services: " /usr/sbin/exportfs -r

if t _x /usr/sbin/rpc.quotad ] ; then echo -n $"Starting NFS quotas: " daemon rpc.rquotad echo

fi echo -n $"Starting NFS mountd: "

daemon rpc.mountd 3RPCMOUNTDOPTS

echo -n $"Starting NFS daemon: " daemon rpc.nfsd $RPCNFSDOPTS echo touch /var/lock/subsys/nfs

Технология изменения порта для lockd (nlockmgr) отличается от вышеприведенной (не надо пытаться изменить файл /etc/rc.d/init.d/nfslock - ничего не выйдет).

Lockd исполнен или как модуль ядра, или вкомпилирован в ядро статически. Для изменения номера порта надо открыть файл /etc/modules и найти опции, передаваемые модулю:

options lockd nlm_udpport=33000 nlm_tcpport=33000

Теперь, когда RPC-сервисы используют статические порты, которые известны, надо применять IPTables. В следующем наборе правил предполагается, что NFS - единственный запущенный на машине сервер, доступ к которому разрешен только машинам, перечисленным в файле /usr/local/etc/nfsexports.hosts:

IPX = "/usr/sbin/iptables"

# Очищаем все цепочки

$IPT --flush

$IPT -t nat --flush $IPT -t mangle --flush $IPT -X

# Разрешаем loopback-трафик $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT

# Правила по умолчанию $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP

$IPT -A INPUT -m state -state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m state -state NEW,ESTABLISHED,RELATED -j ACCEPT

# Разрешаем доступ каждому компьютеру,

# указанному в /usr/local/etc/nfsexports.hosts

for host in "cat /usr/local/etc/nfsexports.hosts"; do $IPT -I INPUT -s $host -p tcp -dport 111 -j ACCEPT

$IPT -I INPUT -s $host -p udp -dport 111 -j ACCEPT

$IPT -I INPUT -s $host -p udp -dport 2049 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 32800 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 32900 -j ACCEPT

$IPT -I INPUT -s $host -p tcp -dport 33000 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 33100 -j ACCEPT

Конечно, это только скелет, нужно будет добавить еще много правил: хотя бы разрешить применение SSH и установить некоторые параметры ядра с помощью /prос.

Туннелирование NFS через SSH .

Аббревиатура NFS иногда расшифровывается как «No File Security» - данные три слова говорят сами за себя. Поэтому очень важно обеспечить защиту NFS-трафика. Это легко сделать с помощью ssh.

Начально можно изменить файл /etc/exports на NFS-сервере так, чтобы файловые системы экспортировались локальному узлу:

Затем надо применять SSH для форвардинга портов NFS и mountd. NFS использует порт 2049/udp, a mountd, как было указано, порт с номером 33000:

# ssh [email protected] -L 200: localhost:2049 -f sleep 120m

# ssh [email protected] -L 200: localhost:33000 -f sleep 120m

Данные две команды предоставляют пользователю интерактивную оболочку, но, так как она не нужна, SSH выполняет команду sleep 120: возвращаемся обратно в командную строку, но форвардинг портов будет длиться еще 2 часа.

Монтирование файловой системы со стороны клиента выглядит очень необычно:

mount -t nfs -о nosuid port=200 mountport=210 nfsserver.test.net:/home/user /mnt/another

Если трюки с ssh-тунпелированием слишком сложны, можно применять проект SHFS (Shell Filesystem) (http: //shfs.sourceforge.net/ ), который дает возможность автоматизировать всю эту процедуру.

После установки получить доступ к SHFS надо или с помощью команды mount -t shfs, или с помощью новой команду shfsmount. Синтаксис данной команды похож на предыдущий:

shfsmount [email protected]:/home/user /mnt/user

CFS и TCFS

Криптографическая файловая система (Cryptographic File System) использует прозрачное кодирование и дешифрование NFS-трафика с помощью алгоритма DES. Кроме данного, она поддерживает автоматическое управление ключами, что делает процесс максимально «прозрачным» для пользователя.

Хотя CFS разработана для SunOS и BSD, она порядком интересна, потому что представляется первой попыткой «прозрачного» кодирования общих файлов. Прозрачная криптографическая файловая система (Transparent Cryptographic File System, TCFS) предоставляет еще более прозрачный способ кодирования NFS-трафика.

Кроме кодирования данных, данная файловая система поддерживает проверку целостности данных.

Сетевая файловая система (NFS - Network File System) является решением общего доступа к файлам для организаций, которые имеют смешанные среды машин с Windows и Unix/Linux. Файловая система NFS дает возможность открывать общий доступ к файлам между указанными разными платформами при функционирующей операционной системе Windows Server 2012. Службы NFS в Windows Server 2012 включают следующие возможности и усовершенствования.

1. Поиск в Active Directory. Вы имеете возможность применять Windows Active Directory для доступа к файлам. Расширение схемы Identity Management for Unix (Управление удостоверениями для Unix) для Active Directory содержит поля идентификатора пользователя Unix (Unix user identifier - UID) и идентификатора группы (group identifier - GID). Это позволяет службам Server for NFS (Сервер для NFS) и Client for NFS (Клиент для NFS) просматривать отображения учетных записей пользователей Windows на Unix прямо из служб домена Active Directory (Active Directory Domain Services). Компонент Identity Management for Unix упрощает управление отображением учетных записей пользователей Windows на Unix в Active Directory Domain Services.

2. Улучшенная производительность сервера. Службы для NFS включают драйвер фильтра файлов, который значительно сокращает общие задержки при доступе к файлам на сервере.

3. Поддержка специальных устройств Unix. Службы для NFS поддерживают специальные устройства Unix (mknod).

4. Расширенная поддержка Unix. Службы для NFS поддерживают следующие версии Unix: Sun Microsystems Solaris версии 9, Red Hat Linux версии 9, IBM AIX версии 5L 5.2 и Hewlett Packard HP-UX версии 11i, а также многие современные дистрибутивы Linux.

Один из наиболее распространенных сценариев, который создает необходимость в применении NFS, предусматривает открытие доступа пользователям в среде Windows к системе планирования ресурсов предприятия (enterprise resource planning - ERP), основанной на Unix. Находясь в системе ERP, пользователи могут создавать отчеты и/или экспортировать финансовые данные в Microsoft Excel для дальнейшего анализа. Файловая система NFS позволяет обращаться к этим файлам, по-прежнему находясь в среде Windows, что сокращает потребность в наличии специальных технических навыков и снижает временные затраты на экспорт файлов с использованием сценария Unix и последующий их импорт в определенное приложение Windows.

Может также возникнуть ситуация, когда у вас имеется система Unix, которая применяется для хранения файлов в какой-то сети хранения данных (Storage Area Network - SAN). Запуск служб NFS на машине Windows Server 2012 позволяет пользователям в организации получать доступ к сохраненным там файлам без накладных расходов, связанных со сценариями на стороне Unix.

До установки служб NFS вы должны удалить любые ранее установленные компоненты NFS, такие как компоненты NFS, которые были включены в состав Services for Unix.

Компоненты служб NFS

Доступны следующие два компонента служб NFS.

1. Server for NFS (Сервер для NFS). Обычно компьютер, основанный на Unix, не может обращаться к файлам, расположенным на компьютере, основанном на Windows. Тем не менее, компьютер, на котором функционирует Windows Server 2012 R2 и компонент Server for NFS, может действовать в качестве файлового сервера для компьютеров с Windows и Unix.

2. Client for NFS (Клиент для NFS). Обычно компьютер, основанный на Windows, не может обращаться к файлам, находящимся на компьютере, основанном на Unix. Тем не менее, компьютер, на котором функционирует Windows Server 2012 R2 и компонент Client for NFS, может получать доступ к файлам, которые хранятся на сервере NFS, основанном на Unix.

Установка Server For NFS с помощью PowerShell

Давайте посмотрим, как применять PowerShell для установки роли NFS на сервере и для создания общего файлового ресурса NFS.

1. Откройте окно Windows PowerShell через панель задач от имени учетной записи администратора.

2. Введите следующие команды, чтобы установить роль NFS на сервере:

PS С:\> Import-Module ServerManager PS С:\> Add-WindowsFeature FS-NFS-Services PS С:\> Import-Module NFS

3. Введите приведенную ниже команду, чтобы создать новый общий файловый ресурс NFS:

PS С:\> New-NfsShare -Name "Test" -Path "C:\Shares\Test"

4. Для просмотра всех новых командлетов PowerShell, относящихся к NFS, которые доступны в Windows Server 2012 R2, выполните следующую команду:

PS С:\> Get-Command -Module NFS

5. Щелкните по папке C:\Shares\Test правой кнопкой мыши, выберите «свойства», далее перейдите на вкладку NFS Sharing (Общий доступ NFS). Нажмите на кнопку Manage NFS Sharing (Управлять общим доступом NFS), в появившемся диалоговом окне вы можете управлять разрешениями для доступа к папке, разрешить анонимный доступ, настроить параметры кодировки файлов. Вы можете открывать общий доступ к папке по NFS с помощью диалогового окна NFS Advanced Sharing без использования PowerShell.

Установка стандартных разрешений

Теперь нам потребуется открыть некоторые порты брандмауэра для функционирования NFS. Порты, необходимые для нормального функционирования служб NFS, представлены ниже в таблице.