1.3 Технологии CIFS и SMB

Общий протокол доступа к файлам Internet (Common Internet File System - CIFS) своим происхождением обязан технологии блока серверных со¬общений (Server Message Block - SMB), которая впервые появилась в MS DOS 3.3. В стандарте SMB описан протокол отправки команд файловой системы (открыть файл, считать, записать, блокировать и закрыть) от клиента к файловому серверу.
Перед обсуждением технических подробностей технологий CIFS и SMB необходимо выяснить основные различия между ними. Изначально существовала только технология SMB, которая использовалась в качестве клиент-серверного файлового протокола в мире персональных компьютеров. В середине 1980-х годов компания Microsoft дала своей реализации протокола SMB на¬звание CIFS и начала позиционировать CIFS в качестве прямого конкурента стандартов WebNFS и NFS. Компания Microsoft предоставила ознакомительный документ RFC на рассмотрение группе IETF (Internet Engineering Task Force), и впоследствии срок действия документа истек без попыток превратить RFC в одну из спецификаций IETF.
Независимые от компании Microsoft поставщики устройств NAS приступили к разработке спецификации CIFS и организовали несколько мероприятий для популяризации CIFS. Ассоциация SNIA (Storage Networking Industry Association) взяла на себя задачу публикации CIFS. Компания Microsoft также выпустила спецификацию CIFS (она называлась Common Internet Filesystem Access Protocol), распространявшуюся бесплатно.
В похожих друг на друга спецификациях SNIA CIFS и CIFS от компании Microsoft описывается протокол, используемый клиентами Windows NT 4.0 для получения доступа к ресурсам серверов Windows NT. В обеих спецификациях не рассматривается протокол SMB, который применяется в новых версиях Windows (например, не затрагивается клиентское кэширование, которое поддерживается в Windows 2000). Кроме того, в спецификациях не описаны все протоколы взаимодействия между серверами. Новый стандарт SMB, не относящийся к бесплатным спецификациям, описан в соответствующей спецификации, которая за определенную плату распространяется компанией Microsoft, что стало возможным благодаря судебным решениям Европейского Союза и правительства США.
Таким образом, компания Microsoft вновь стала называть свою реализацию описываемой технологии блоком SMB. По сути, SMB от Microsoft - это закрытый протокол, представляющий собой расширенную версию индустриального стандарта CIFS.
Кроме того, следует обратить внимание на историческую связь между SMB/CIFS и NetBIOS. Программный интерфейс NetBIOS (уровень сеанса в модели OSI) на данный момент безнадежно устарел. Интерфейс реализует уровень абстракции, который позволяет приложениям работать с различными транспортными протоколами, например TCP/IP, NetWare или уже забытым протоколом XNS (Xerox Network System). Необходимость в программном интерфейсе приложений, который предоставляет возможность создания приложений, не зависящих от сетевого протокола, существует и поныне. Од¬нако в настоящий момент для этого обычно используется интерфейс сокетов, в частности в мире Windows - интерфейс Winsock.
Компания Microsoft использовала NetBIOS для преобразования имен (пре¬образования имени сервера в сетевой адрес), но сейчас для этого предназначена стандартная служба DNS.
Изначально Microsoft не использовала TCP/IP в качестве транспортного протокола, что кардинально изменилось со временем, однако поддержка NetBIOS продолжала присутствовать. Тем не менее роль NetBIOS постоянно уменьшалась. После назначения порта TCP/IP для файловых серверов SMB зависимость от NetBIOS была полностью "излечена", по крайней мере в контексте базового протокола. Но ситуация оставалась запутанной, так как некоторым вторичным службам клиентов и серверов Windows все равно требовался протокол NetBIOS. Хорошим примером будет объявление серверами о своем присутствии в сети и предоставление списка доступных служб, а также передача этих объявлений клиентам другими серверами. Со временем службы были переделаны и NetBIOS был полностью снят со счетов с выходом Windows 2000.
Наконец, наследие SMB можно заметить в каждом запросе CIFS, поскольку каждый запрос и ответ должны начинаться со значение "0xFF", после чего следуют такие символы ASCII, как "SMB".

1.3.1 Разновидности стандарта CIFS

К сожалению, точного определения стандарта CIFS не существует. Различные типы протоколов SMB называются диалектами. Вот несколько воз¬можных вариантов:
■ применяемый клиентами DOS и Windows 3.x;
■ используемый при подключении к серверам, не работающим под управлением Windows;
■ применяемый клиентами под управлением Windows NT.
Чаще всего клиент отправляет серверу запрос на установку сеанса и передает список всех поддерживаемых вариантов протокола. Сервер выбирает наиболее функциональный вариант и отправляет клиенту соответствующий запрос. В зависимости от протокола, о котором "договорились" клиент и сервер, некоторые запросы и соответствующие им ответы могут быть недопустимыми. Согласованный вариант протокола не определяет однозначно фактическую реализацию функций протокола, что вносит еще большую путаницу; для указания поддержки определенных функций некоторые флаги могут быть установлены или сброшены. Другими словами, даже при выборе протокола существуют различные варианты предоставляемых функций: например, один из флагов может указывать на наличие поддержки длинных имен файлов.
Как описано в документе RFC компании Microsoft (по правилам IETF на данный момент он уже устарел), протокол CIFS обеспечивает взаимодействие клиента и сервера для доступа к файлам и управления ими. Такие функции, как объявление о наличии в сети доступных принтеров и серверов, выходят за рамки возможностей протокола CIFS.
Организация SNIA продолжает работу над спецификацией CIFS. Кроме того, SNIA проводит ежегодную конференцию, посвященную CIFS, и организует другие мероприятия, на которых обсуждаются вопросы взаимодействия систем по протоколу CIFS.
Спецификация SMB стала стандартом с 1992 года (X/Open CAE Specification С209) и описывает SMB как протокол для обеспечения взаимодействия между компьютерами под управлением DOS, Windows, OS/2 и UNIX.

1.3.2 Описание протокола CIFS

Запросы и ответы CIFS имеют четкую, понятную структуру. Поля пакетов SMB также стандартизированы, и отличия зависят от выбранной, разновидности CIFS и функций, поддерживаемых как клиентом, так и сервером.
Обратите внимание, что показаны только общие элементы для всех вариантов SMB. Подробности строения каждого варианта пакета SMB выходят за пределы тематики этой статьи.
Некоторые поля в таблице требуют более полного описания. Поле команды имеет размер в один байт и описывает тип запроса. Сервер копирует это значение в ответ, что позволяет клиенту анализировать последний. Спецификация CIFS содержит значения и определения для этого поля. Описанные команды позволяют выполнять такие операции, как открытие файла, чтение, запись и блокирование определенного диапазона файла. Все эти операции выполняются в качестве ответа на запрос приложения.
Кроме того, запросы клиента CIFS (и связанные с ними ответы сервера) инициируются кодом перенаправителя без явного вмешательства приложения. Примерами будут кэширование и оппортунистическая блокировка (opportunistic locking). В спецификациях CIFS RFC и SNIA, а также Open Group определены значения и семантика кода команды CIFS размером в 1 байт.

Таблица Структура заголовка SMB

Поле	Размер	Описание
		Всегда имеет значение 0 xFFSMB
		Указание типа запроса
		32-разрядный код ошибки (генерируется серверами Windows NT и возвращается в виде 32-разрядного кода ошибки клиентам, поддерживающим коды ошибок Windows NT) ИЛИ Для более старых клиентов, которые не поддерживают 32-разрядные коды ошибок, сообщение об ошибке преобразуется в старый структурный тип. Старый тип включает в себя: ■ 8-разрядный класс ошибки, который указывает на ее разновидность, т.е. сообщается ли эта ошибка операционной системой сервера или самим сервером; кроме того, это может быть ошибка аппаратного обеспечения или протокола SMB ; ■ 8 разрядов игнорируются; ■ 16-разрядный код ошибки, который имеет значение только в рамках определенного класса ошибки
		Семантика представлена в табл. 3.2
		Семантика представлена в табл. 3.3
Заполнение/		Заполнение/подпись. Рассматривается
		в тексте раздела
Tid- значение		Используется для идентификации ресурса сервера, который запрашивается клиентом. Указывается с помощью запроса SMB TreeConnect
		Описание
Идентификатор	2 байт, но	Устанавливается клиентом. Указание на
процесса (Pid)	при необхо-	клиентский процесс, который осуществляет
		запрос. Используется сервером для
	может быть	отслеживания режима открытия файлов
	расширен до	и для блокировок. Отправляется сервером
		обратно клиенту вместе с идентификатором мультиплексора (mid) для уникальной. идентификации запросов, на которые отвечает сервер
Идентификатор		Устанавливается и используется клиентом.
мультиплексора		Сервер возвращает полученный Mid в ответе
		на запрос. Клиент использует значения Mid и Pid, чтобы идентифицировать запрос, для которого пришел ответ
Uid-значение		Назначается сервером после аутентификации клиента. Клиент должен использовать Uid во всех запросах
Параметры	Переменная	Состоит из 16-разрядного счетчика слов, который указывает на количество следующих за счетчиком 16-разрядных слов. Для каждой команды SMB этот счетчик обычно представляет собой фиксированное значение с одним счетчиком слов для команды и вторым - для ответа. Обычно этот счетчик имеет значение 5 или меньше
	Переменная	Состоит из 16-разрядного счетчика слов, который указывает на количество следующих за счетчиком байт (8-разрядных слов) данных. По сравнению с полем параметров поле данных может иметь намного больший размер, например 1 Кбайт и более. В запросах SMB на чтение и запись это поле содержит фактические данные, которые считываются или записываются

Помните, что новые значения и семантика полей могут появиться без предупреждения с выходом новых версий Windows, так как протокол CIFS про¬должает развиваться.
Существует несколько команд для выполнения одинаковых базовых операций; например, для открытия, чтения и записи существует несколько раз личных команд. Некоторые команды уже не применяются, а в ряде случаев могут использоваться альтернативные команды, в зависимости от выбранного диалекта протокола.
Далее представлены примеры функций, описанных в поле команды.
■ Выбор типа SMB.
■ Установка сеанса связи.
■ Переход по каталогам и перечисление файлов и каталогов.
■ Открытие, создание, закрытие или удаление файлов.
■ Блокировка и разблокировка определенных фрагментов файла.
■ Операции печати.
■ Уведомления об изменении файлов и каталогов.
■ Транзакции, при которых указываются данные, параметры и операции. Сервер CIFS выполняет запрошенную операцию и возвращает результат - данные и параметры. Примерами транзакций могут служить ссылки в распределенной файловой системе и управление расширенными атрибутами.

Таблица Семантика поля Flags

Значение	Описание
	Зарезервировало. Используется устаревшими запросами
	Зарезервировано. Должно быть равным нулю
	Указывает на необходимость учета регистра в именах файлов
	и каталогов
	Зарезервировано
	Зарезервировано. Используется устаревшими запросами
	Зарезервировано. Используется устаревшими запросами
	Указание, что это ответ SMB

В поле Flag2 описано еще больше необязательных функций. Значения этого поля приведены в таблице ниже.
Поле Заполнение/подпись изначально представляло собой последовательность "холостых" байт. Со временем значение этого поля изменилось. Поле заполнения теперь может включать в себя следующие элементы:

Таблица Семантика поля Flags2

Значение	Описание
	Клиент поддерживает длинные имена файлов. Сервер может возвращать длинные имена файлов
	Клиент поддерживает расширенные атрибуты OS/2
	Включено подписывание пакетов SMB
	Зарезервировано
	Зарезервировано
	Зарезервировано
	Каждое имя пути в запросе представляет собой длинное имя
	Зарезервировано
	Зарезервировано
	Зарезервировано
	Зарезервировано
	Указание на использование расширенного механизма безопасности, который рассматривается в разделе 3.3.3
	Пути в запросе должны быть преобразованы средствами распределенной файловой системы
	Страничный ввод-вывод, указывающий на то, что чтение должно быть разрешено, когда у клиента есть соответствующее разрешение
	Указание на возврат 32-разрядного кода ошибки. Если флаг не установлен, используется код ошибки в стиле DOS
	Если флаг установлен, пути в пакете SMB указаны в формате Unicode . В противном случае применяется кодировка ASCII

■ 2 байта идентификатора процесса, что позволяет указывать 32-разрядные идентификаторы процесса;
■ 8 байт для хранения подписи пакета SMB, если эта функция активизирована (см. описание поля Flags2);
■ 2 неиспользуемых байта.

1.3.3 Безопасность CIFS

Протокол CIFS обеспечивает безопасность средствами сервера. Администратор может отключить систему встроенной безопасности CIFS, в чем едва ли появится необходимость, поэтому система безопасности включена по умолчанию.
В старых вариантах CIFS допускается отправка незашифрованного текстового пароля от клиента к серверу, что категорически не рекомендуется. Протокол CIFS допускает защиту ресурсов сервера с помощью паролей отдельных пользователей (это называется безопасностью на уровне пользователя). Для обеспечения обратной совместимости серверы CIFS поддерживают защиту общего ресурса на базе пароля, одинакового для всех пользователей. Поскольку ресурс будет предоставлен в общее пользование,- этот метод называется безопасностью на уровне ресурса. Использовать механизм безопасности на уровне ресурса не рекомендуется, и в Windows 2000 Server эта система отсутствует. Первый пакет SMB, который отправляется серверу клиентом, называется SMB_NEG0TIATE_PR0T0C0L. Пакет применяется для выбора типа CIFS. В ответ на запрос SMB_NEG0TIATE_PR0T0C0L сервер сообщает об используемом механизме безопасности (уровень пользователя или ресурса).
Начиная с Windows NT4 SP3 и Windows 2000, компания Microsoft предоставила возможность размещения в пакетах SMB цифровой подписи. Сервер может быть настроен на обязательное требование цифровой подписи от клиента; в противном случае клиенту будет запрещен доступ к ресурсам. Использование цифровой подписи отражается на производительности как сервера, так и клиента, но это цена, которую приходится платить за безопасность. Обратите внимание, что подписывание и проверка имеют двунаправленную природу, т.е. клиент подписывает отправляемые запросы, сервер проверяет подпись клиента и подписывает отправляемые ответы, после чего клиент проверяет подпись сервера. Подпись пакета SMB хранится в поле Заполнение/подпись.
Ответ на запрос SMB_NEG0TIATE_PR0T0C0L используется для предоставления клиенту информации о поддержке сервером подписывания пакетов SMB и о необходимости обязательного подписывания пакетов SMB.

1.3.4 Аутентификация CIFS

Протокол CIFS позволяет определять уровень безопасности при взаимодействии серверов и клиентов. Сервер может быть настроен на отказ в обслуживании клиентов, которые предлагают слишком низкий уровень безопасности.
Протокол CIFS предоставляет механизмы аутентификации, необходимые серверу для аутентификации клиента. Кроме того, предоставляются методы аутентификации сервера клиентом. В базовом уровне аутентификации клиент сообщает имя пользователя и незашифрованный пароль. По очевидным причинам такой подход нежелателен. Более того, сервер можно настроить на отказ в обслуживании клиентов, которые отправляют пароли в незашифрованном виде.
Аутентификация может выполняться с помощью технологии, которая называется протокол запрос/ответ (challenge/response protocol). При отправке клиентом пакета SMB_NEGOTIATE_PROTOCOL для выбора типа CIFS флаг в ответе сервера указывает на возможность использования протокола запрос/ответ. Если сервер поддерживает этот протокол, в ответе сервера предоставляется 8-байтовый запрос. Запрос - это случайное значение с очень низкой вероятностью повторной генерации. И клиент и сервер формируют ключ из пароля пользователя. После этого запрос шифруется с помощью ключа и алгоритма DES (Data Encryption Standart). Клиент отправляет запрос серверу, а сервер сравнивает ответ с собственным подсчитанным значением. Если два значения совпадают, клиент доказывает знание пароля и подтверждает свою аутентичность.
Кроме того, протокол CIFS поддерживает систему расширенной безопасности (можете и не надеяться, что читатель, который догадается об указании на поддержку расширенной безопасности в ответе сервера на запрос SMB_NEGOTIATE_PROTOCOL, получит награду). Механизм расширенной безопасности предоставляет возможность поддержки произвольного протокола аутентификации в рамках протокола CIFS. При выборе расширенной безопасности первый двоичный объект безопасности предоставляется в ответе на запрос SMB_NEGOTIATE_PROTOCOL. Двоичные объекты безопасности не обрабатываются протоколом CIFS. В этом он полагается на механизмы клиента и сервера, предназначенные для генерации и обработки двоичных объектов. Последующие двоичные объекты безопасности могут передаваться с данными SMB.
Использование механизма расширенной безопасности позволило Microsoft обеспечить поддержку протокола Kerberos в Windows 2000 и более поздних версиях. Реализация Kerberos в Windows 2000 является примером использования закрытых элементов. Например, некоторые поля мандатов Kerberos применяются для передачи информации о группах, в которые входит клиент. Реализация Kerberos от Microsoft допускает взаимную аутентификацию, когда не только сервер проводит аутентификацию клиента, но и наоборот, клиент аутентифицирует сервер.
Компания Microsoft предлагает еще один способ установки сеанса связи между клиентом и сервером, который называется Netlogon. При этом используются данные о компьютере (а не о пользователе). Протокол Netlogon необходим для установки безопасного сеанса RPC и имеет намного больше возможностей, так как поддерживает маркеры доступа пользователей, которые не поддерживаются при регистрации средствами протокола CIFS. Обычно Netlogon используется для связи между серверами (один сервер выступает в роли клиента другого сервера).
Наконец, сервер CIFS не обязательно должен обеспечивать работу механизма аутентификации. Протокол CIFS поддерживает сквозную аутентификацию, когда сервер получает запрос у другого сервера, передает этот запрос клиенту и возвращает ответ клиента серверу аутентификации. При этом, если сервер аутентификации отвечает положительно, клиенту предоставляется доступ к запрошенным ресурсам. Этот механизм известен как сквозная аутентификация.

1.3.5 Возможности по оптимизации CIFS

Протокол CIFS обладает различными возможностями по оптимизации взаимодействия между клиентом и сервером.

1.3.5.1 Функция CIFS AndX

Протокол CIFS позволяет формировать последовательность взаимно зависящих друг от друга запросов, поэтому оптимизация этих операций позволяет завершить выполнение запроса за одно обращение к серверу. Эта функция называется AndX; Файловая система NFS версии 4 обеспечивает подобную функцию в виде процедуры COMPOUND. Примером может быть отправка запросов OpenAndRead или WriteAndClose серверу CIFS. При этом вместо отправки отдельных двух запросов, например Open, а затем Read, и получения двух ответов отправляется один запрос OpenAndRead и получается один ответ. Это имеет особое значение в том случае, когда время обращения запрос/ответ слишком велико.

1.3.5.2 Оппортунистическая блокировка

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

Представьте себе приложение, которое открывает файл на сетевом сервере для чтения и записи и записывает в файл 128-байтовые записи. Без оппортунистической блокировки каждая запись размером 128 байт потребует передачи данных по сети. Использование oplock позволяет локально кэшировать файл на клиентской системе и объединять несколько операций записи в одну, которая приводит к передаче данных по сети. Например, предположим, что клиент использует буферы размером 4096 и последовательно записывает в файл по 128 байт. Первый буфер будет содержать данные 32 операций записи (4096/128 = 32), и все данные 32 записей будут переданы по сети одним запросом на запись в файл. Если операция записи не может быть кэширова-на, по сети будет передаваться 32 операции записи (а не одна, как при кэшировании). Сокращение количества операций записи с 32 до одной приводит к значительному снижению нагрузки на сеть и существенному повышению производительности.
Вторым назначением оппортунистической блокировки является расширение условий, при которых подобная блокировка возможна. При использовании oplock можно увеличить эффективность кэширования. Расширение условий, при которых возможна оппортунистическая блокировка, предоставляет несколько дополнительных преимуществ. Предположим, что экземпляр при¬ложения открывает файл (на сетевом сервере) для чтения и записи. При этом запрашивается и предоставляется оппортунистическая блокировка. Программный код клиента может кэшировать операции записи в файле. Предположим, что другой экземпляр того же приложения запущен на другом клиенте. Одним из выходов из подобной ситуации будет снятие оппортунистической блокировки и использование сетевого ввода-вывода для передачи запросов на запись в файл от обоих приложений. Еще одним способом бу¬дет снятие оппортунистической блокировки в тот момент, когда второй экземпляр приложения попытается выполнить операцию записи. Очень часто приложения вообще не выполняют операции записи.
При изменении условий сервер отправляет уведомление клиенту о снятии оппортунистической блокировки. В качестве примера ситуации, когда сервер отправляет уведомление о снятии оппортунистической блокировки, можно указать запрос на доступ к файлу или запись данных в файл другим клиентом. Сервер обеспечивает очистку данных состояния сервера (включая закрытие сеанса клиента), если клиент не отвечает на запрос о снятии оппортунистической блокировки. Клиент запрашивает oplock только в случае необходимости; например, если приложение запрашивает открытие файла для эксклюзивного доступа, запрос оппортунистической блокировки просто не имеет смысла.
Оппортунистические блокировки реализуются в трех вариантах:

Последовательность операций при эксклюзивной оппортунистической блокировке

■ эксклюзивная оппортунистическая блокировка;
■ пакетная оппортунистическая блокировка;
■ оппортунистическая блокировка второго уровня. Далее эти сценарии описываются более подробно.

Эксклюзивная оппортунистическая блокировка

Этот вариант блокировки запрашивается мини-перенаправителем CIFS, когда приложение открывает файл для чтения или записи. Сервер предоставляет оппортунистическую блокировку, если файл еще не открыт другим клиентом. Последовательность операций показана на рисунке.
Для начала первый клиент отправляет запрос на открытие файла, запрашивая эксклюзивную оппортунистическую блокировку. Сервер выполняет необходимую проверку и предоставляет ее. Первый клиент начинает кэширование файла, выполняя операции упреждающего чтения и отложенной записи. Через некоторое время другой клиент, например клиент 2 отправляет серверу запрос на открытие того же файла. Сервер отмечает, что клиент 1 владеет эксклюзивной оппортунистической блокировкой для запрошенного файла, и отправляет уведомление о снятии блокировки клиенту 1. Клиент 1 очищает буферы данных, отправляя необходимые запросы на запись и на блокировку файла. Как только данные состояния файла будут записаны, клиент 1 сообщает серверу, что обработка уведом¬ления о снятии оппортунистической блокировки завершена. На этом этапе сервер отправляет ответ клиенту 2, позволяя ему открыть файл. Клиент 1 продолжает работу с файлом, не проводя при этом локального кэширования. В данном случае предполагается, что клиент 1 открыл файл в режиме, допускающем открытие файла другими клиентами.

Оппортунистическая блокировка второго уровня

Очень часто клиенты открывают файл в режиме чтения/записи и ничего не записывают в файл до его закрытия. Оппортунистическая блокировка второго уровня проектировалась для обеспечения совместного использования и кэширования файлов в такой ситуации. Эксклюзивная оппортунистическая блокировка и пакетная оппортунистическая блокировка (она рассматривается в следующем разделе) всегда предоставляются по запросу клиента. Но оппортунистическая блокировка второго уровня никогда не запрашивается клиентом. Клиент начинает с запроса эксклюзивной оппортунистической блокировки. Если такая блокировка предоставляется, сервер при выполнении определенных условий (они описаны далее) может понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня.
Клиент 1 начинает работу с запроса эксклюзивной оппортунистической блокировки и приступает к локальному кэшированию файла. В частности, клиент 1 проводит упреждающее чтение и локально кэширует блокируемые данные. Помните, что в данном случае клиент не собирается записывать данные в файл. На определенном этапе клиент 2 запрашивает доступ к этому же файлу. Сервер отправляет клиенту 1 уведомление с требованием понизить эксклюзивную оппортунистическую блокировку до блокировки второго уровня. Клиент аннулирует блокировки и сообщает, что обработка уведомления завершена. Далее серь вер отправляет клиенту 2 сообщение об успешном открытии файла и предоставляет клиенту оппортунистическую блокировку второго уровня. В данном случае предполагается, что клиент 1, открывая файл, сообщил серверу, что другие клиенты также могут получить доступ к файлу.
При использовании оппортунистической блокировки второго уровня, клиентам запрещено буферизировать блокируемые данные. Преимущество этой схемы заключается в упрощенной когерентности данных на стороне сервера, в то время как клиент будет кэшировать считываемые данные, что позволяет сократить объем информации, передаваемой по сети. Как только один из клиентов выдает запрос на запись, сервер снимает оппортунистическую блокировку второго уровня, после чего блокировок вообще не остается. Поскольку ни один из клиентов не буферизирует блокируемые данные при на¬личии блокировок второго уровня, успешная операция записи означает, что запись выполнялась в область файла, не заблокированную другими клиента¬ми. После снятия оппортунистической блокировки второго уровня клиентам запрещается буферизировать считанные данные.

Оппортунистическая блокировка второго уровня

Пакетная оппортунистическая блокировка

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

Пакетная оппортунистическая блокировка

Выше приведена последовательность операций. Клиент 1 открывает командный файл и запрашивает пакетную оппортунистическую блокировку. Предположим, что сервер предоставляет пакетную блокировку, так как больше никто не выполняет запись данных в файл. Клиент 1 ищет в файле определенную строку и осуществляет операцию чтения. Интерпретатор выполняет прочитанную строку. Затем файл закрывается. Мини-перенаправитель CIFS не выполняет никаких действий при получении запроса на закрытие файла (т.е. выполняется операция отложенного закрытия). Интерпретатор командной строки открывает файл, но мини-перенаправитель CIFS не выполняет операцию открытия, а просто отменяет размещенную в очереди операцию отложенного закрытия файла. Когда интерпретатор командной строки выполняет операции поиска и чтения строки, мини-перенаправитель CIFS отправляет запросы на поиск и чтение.
В результате сокращается объем данных, передаваемых по сети (выполняется меньше запросов на открытие и закрытие файла). Кроме того, оптимизируется использование ресурсов сервера, так как от сервера не требуется немедленной обработки запроса на закрытие файла с последующим его повторным открытием.

Компьютерная сеть по определению представляет собой распределенную систему. Ее предназначение — совместная работа пользователей. Такая работа подразумевает доступ к сетевым ресурсам , как то файлы и каталоги, принтеры и т.д. Для пользователя обращение к сетевым ресурсам должно быть прозрачным, т.е.:

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

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

Указанные возможности предоставляют специальные протоколы общего доступа. Наиболее распространенными из них являются SMB/CIFS для ОС Windows и NFS, используемый в UNIX-подобных системах.

Протоколы общего доступа

SMB/CIFS

SMB (Server Message Block) — это протокол, предложенный IBM для организации общего доступа к файлам, принтерам, последовательным портам, почтовым ячейкам (mail slots), именованным каналам (named pipes) и API сетевых компьютеров. Протокол SMB может быть использован поверх сетевых протоколов стека TCP/IP, а также поверх ряда других сетевых протоколов.

SMB — это типичный клиент-серверный протокол, который позволяет клиентскому приложению выполнять операции доступа к общему ресурсу (чтение, запись и т.п.) через запросы к серверу. SMB требует установления и поддержания соединения, но может работать и в датаграммном режиме.

В 1992 году появилась Samba - свободная реализация протокола SMB для UNIX-подобных операционных систем. Поскольку Microsoft не публиковала спецификации SMB и дополнений к нему, создателю Samba Эндрю Триджеллу (Andrew Tridgell) пришлось провести обратную разработку протокола на основе анализа пакетов.

Продвижение протокола SMB обеспечила корпорация Microsoft, включив его поддержку в свои продукты. В сетевой среде Microsoft Windows SMB являлся основным протоколом прикладного уровня для работы с ресурсами ЛВС. Он предназначен для выполнения функций общего доступа к файлам и принтерам, авторизации пользователей и обмена сообщениями.

Протокол SMB представляет четыре вида севисов:

• Управление сессиями . Создание, поддержание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.
• Файловый доступ . Рабочая станция может обратиться к файл-серверу с запросами на выполнение типовых файловых операций (открытие файла, чтение данных и т.п.).
• Сервис печати . Рабочая станция может ставить файлы в очередь для печати на сервере и получать информацию об очереди печати.
• Сервис сообщений . SMB поддерживает простую передачу адресных и широковещательных сообщений по локальной сети.

Если режим управления сеансами в SMB прозрачен для пользователя, то остальными сервисами пользователь может управлять непосредственно с помощью команды net (см. net /? в консоли ОС Windows).

Рис. 1. NetBIOS/SMB

Для управления сессиями протокол SMB изначально использовал NetBIOS в реализации NetBEUI (NetBIOS Extended User Interface) - расширенный пользовательский интерфейс дейтаграммной передачи NetBIOS, рассчитанный на сети порядка 20-200 рабочих станций. Сети, основанные на протоколе NetBEUI, легко реализуются, но их трудно расширять, так как протокол NetBEUI не маршрутизируемый.

Для использования SMB в сетях с более сложной топологией в NetBIOS была добавлена поддержка транспортных протоколов TCP (NBT, NetBIOS over TCP), IPX, DECNet и Xerox Networking (XNS) ()

Сервисы SMB, работающие в среде TCP/IP, используют различные порты (стандартные названия портов подчеркивают тесную связь SMB с NetBIOS):

Netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp netbios-dgm 138/tcp # NETBIOS Datagram Service netbios-dgm 138/udp netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp

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

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

Привязка к NetBIOS ограничивало использование SMB небольшими локальными сетями. Первая причина — отсутствие в NetBIOS понятия сети как такового и средств перенаправления трафика (маршрутизации). Вторая — в принятой схеме адресации: имя ресурса, по сути, строка из 15 символов, плюс байт типа ресурса: сервер, контроллер домена и т.д. Естественно, такая одноранговая система именования не годится для интернета.

Для устранения этих ограничений в последних версиях SMB использовался протокол NBT (NetBIOS over TCP), работавший поверх стека TCP/IP.

CIFS создавался совместно разра-бот-чика-ми Samba Team, неза-виси-мым сооб-щест-вом и Microsoft. После того как про-то-кол CIFS был пред-став-лен как откры-тый стан-дарт, Microsoft прекратила финан-сирова-ние про-екта и сотрудничество с Samba Team, а поддержка CIFS в переработке Microsoft для совместимости с прежними версиями SMB была включена в ОС Windows 2000.

CIFS (Common Internet File System) - это открытый стандартный протокол (см. CIFS) на основе SMB, который обеспечивает доступ к файлам и сервисам на удаленных компьютерах в сетях TCP/IP. В отличие от SMB, основным транспортом для CIFS является протокол TCP. Для серверов CIFS зарегистрированы порты 445/TCP и 445/UDP (microsoft-ds # Microsoft Naked CIFS , см. /etc/services)

CIFS обеспечивает функциональность похожую на FTP (File Transfer Protocol), но предоставляет клиентам улучшенный (похожий на прямой) контроль над файлами. Основные возможности CIFS приведены в .

Табл. 1. Возможности протокола CIFS

Возможность	Описание
Доступ к файловой системе	Поддержка файловых операций, таких как открытие, чтение, запись, поиск и закрытие файла или каталога
Блокировка файлов и записей	Неблокирующие приложения не имеют доступа к заблокированному файлу или записи.
Безопасное кэширование (опережающее чтение (read-ahead) и отложенная запись (write-behind))	Поддерживается одновременный доступ на чтение/запись файла множеством клиентов
Уведомления об изменении файла	Приложения могут регистрироваться на сервере для получения уведомлений об изменениях в файлах или директориях
"Переговоры" о версии протокола	Когда клиент и сервер устанавливают первый сетевой контакт, они обмениваются информацией о версии протокола (диалекте), который будет использоваться. Разные диалекты могут включать новые типы сообщений, а также отличия в форматах от других диалектов.
Расширенные атрибуты	Поддерживаются атрибуты, не относящиеся к атрибутам файловой системы. Такие, например, атрибуты как имя автора, могут быть добавлены к встроенным системным атрибутам файла (дата создания, дата модификации и проч.)
Распределенные реплицируемые виртуальные тома	Протокол поддерживает многотомную виртуальную файловую систему, в которой все "поддеревья" файловой иерархии для клиента выглядят как одно целое. CIFS прозрачно для пользователя обрабатывает доступ к физически перемещенным или реплицированным элементам такой файловой системы.
Независимость от серверов распознавания имен	Клиенты могут использовать любой механизм распознавания имен. К примеру, серверы DNS могут использоваться для получения доступа к файловым ресурсам сервера через Internet.
Пакетные запросы	Множественные файловые запросы могут быть "упакованы" в одно сообщение, что сокращает время ожидания ответа сервера. Пакетная обработка возможна даже тогда, когда последующие запросы зависят от результатов выполнения предыдущих.
Поддержка символов Unicode	Строки в формате Unicode могут использоваться в именах файлов, ресурсов и учетных записях пользователей.

Сетевая файловая система NFS

NFS (Network File System, сетевая файловая система) - это стандарт, который включает описание распределенной файловой системы и сетевого протокола для работы с ней. Первая спецификация NFS была разработана компанией Sun в 1989 году и предназначалась для использования только в UNIX. Позже реализации клиентской и серверной частей стали распространенными и в других системах. Текущая версия (на момент написания этого материала) имеет название NFS v4 и является открытым стандартом (RFC 3010).

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

Протокол NFS, как и SMB/CIFS, использует клиент-серверную модель взаимодействия. В ранних версиях NFS для транспортирования данных использовался UDP-протокол, в современных - используется TCP. Сервис NFS работает на следующих зарегистрированных портах:

Nfs 2049/tcp # Network File System - Sun Microsystems nfs 2049/udp # Network File System - Sun Microsystems

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

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

Структура NFS включает три компонента разного уровня:

• Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
• Функции презентационного уровня выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую , форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
• Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.

Процедура подключения сетевого ресурса средствами NFS называется «экспортированием». Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS, в отличие от, например, сервера SMB, не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.

В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован «только для чтения», можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: «жесткое» (hard) или «мягкое» (soft).

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

На вопрос, какой из режимов, «мягкий» или «жесткий», лучше, однозначно ответить невозможно. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то «жесткое» монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах «только для чтения», режим «мягкого» монтирования представляется более удобным.

С точки зрения безопасности первые реализации NFS были крайне слабы: аутентификация выполнялась, по сути, только по ip-адресу клиента. Использование NIS не намного увеличивало защищенность системы. В версиях NFS 3 и 4 эти вопросы были переработаны путем добавления поддержки списков доступа (ACL), защищенного rpc и ряда других решений, которые позволили сертифицировать NFS в минобороны США.

Общий доступ в смешанной сети

Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется практически со всеми версиями этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. К сожалению, использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным.

Низкоуровневые средства общего доступа. Протокол DAFS

Архитектура виртуального интерфейса

Архитектура виртуального интерфейса (VIA) - это совместная разработка Microsoft, Intel и Compaq, которая определяет абстрактную модель низкоуровневой технологии ввода/вывода. VIA используется для организации высокоскоростного обмена данными между двумя процессами, которые работают на разных серверах или системах хранения в центрах обработки данных (ЦОД).

Virtual Interface (VI) — это протокол связи в архитектуре Virtual Interface Architecture

DAFS (Direct Access File System) - это стандартный протокол файлового доступа, который базируется на NFS v4. Он позволяет прикладным задачам передавать данные в обход операционной системы и ее буферного пространства напрямую к транспортным ресурсам, сохраняя семантику, свойственную файловым системам. DAFS использует преимущества новейших технологий передачи данных по схеме память-память. Его использование обеспечивает высокие скорости файлового ввода-вывода, минимальную загрузку CPU и всей системы, благодаря значительному уменьшению количества операций и прерываний, которые обычно необходимы при обработке сетевых протоколов. Особенно эффективным является использование аппаратных средств поддержки .

Кратко описать алгоритм работы DAFS можно следующим образом: пусть имеются два приложения, осуществляющие доступ к сети при помощи сетевого интерфейса пользовательского уровня (VI, ), тогда:

1. Драйвер устройств операционной системы управляет аппаратными средствами интерфейса традиционным способом, осуществляя контроль за доступом приложений к оборудованию.
2. Приложения выделяют буферы сообщений в собственном адресном пространстве и обращаются к драйверу устройств для получения доступа к сетевому интерфейсу. После соответствующей настройки они автоматически инициируют процесс передачи и приема, а интерфейс пересылает информацию в буферы приложений и в обратном направлении, используя обычный механизм прямого доступа к памяти (direct memory access, DMA)

Рис. 3. Общий принцип работы DAFS

Приложения имеют доступ к сети с использованием виртуального интерфейса. Драйвер NIC ОС управляет сетевым контроллером и обеспечивает прямой доступ приложений к интерфейсу. Приложения выделяют буферы в собственном адресном пространстве, куда принимают и откуда отправляют сообщения, используя DMA.

Архитектура сетевого интерфейса пользовательского уровня варьируется в зависимости от особенностей конкретных приложений и сетей - от способа определения приложениями местоположения пересылаемых сообщений, от местонахождения выделяемых для приема информации буферов, от порядка уведомления приложений о поступивших сообщениях. В некоторых сетевых интерфейсах (например, в интерфейсах Active Message или Fast Message) операции передачи и приема реализованы в виде функций, помещенных в пользовательскую библиотеку, которая загружается при инициализации каждого процесса. В других (например, в U-NET и VIA) для каждого процесса создаются очереди, которыми манипулируют сами приложения. Эти очереди обслуживаются аппаратными средствами интерфейса.

DAFS спроектирован для сетей хранения данных (NAS) и используется в кластерном и серверном окружении баз данных и разнообразных Интернет-приложений, ориентированных на непрерывную работу. Он обеспечивает наименьшие задержки доступа к общим файловым ресурсам и данным, а также поддерживает интеллектуальные механизмы восстановления работоспособности системы и данных.

Контрольные вопросы

1. Какой протокол используется для организации общего доступа к ресурсам в сетях Windows?
2. Какие ресурсы можно выделить в общий доступ при помощи протокола SMB?
3. Зачем в NFS выделен специальный протокол презентационного уровня?
4. Чем отличается «жесткое» монтирование томов NFS от «мягкого»?

Постоянный адрес этой страницы:

В связи с недавной эпидемией шифровальщика WannaCry, эксплуатирующим уязвимость SMB v1, в сети снова появились советы по отключению этого протокола. Более того, Microsoft настоятельно рекомендовала отключить первую версию SMB еще в сентябре 2016 года. Но такое отключение может привести к неожиданным последствиям, вплоть до курьезов: лично сталкивался с компанией, где после борьбы с SMB перестали играть беспроводные колонки Sonos.

Специально для минимизации вероятности «выстрела в ногу» я хочу напомнить об особенностях SMB и подробно рассмотреть, чем грозит непродуманное отключение его старых версий.

SMB (Server Message Block) – сетевой протокол для удаленного доступа к файлам и принтерам. Именно он используется при подключении ресурсов через \servername\sharename. Протокол изначально работал поверх NetBIOS, используя порты UDP 137, 138 и TCP 137, 139. С выходом Windows 2000 стал работать напрямую, используя порт TCP 445. SMB используется также для входа в домен Active Directory и работы в нем.

Помимо удаленного доступа к ресурсам протокол используется еще и для межпроцессорного взаимодействия через «именованные потоки» – named pipes . Обращение к процессу производится по пути \.\pipe\name.

Первая версия протокола, также известная как CIFS (Common Internet File System), была создана еще в 1980-х годах, а вот вторая версия появилась только с Windows Vista, в 2006. Третья версия протокола вышла с Windows 8. Параллельно с Microsoft протокол создавался и обновлялся в его открытой имплементации Samba .

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

Под спойлером вы найдете сводную таблицу изменений в версиях SMB.

Версия	Операционная система	Добавлено, по сравнению с предыдущей версией
SMB 2.0	Windows Vista/2008	Изменилось количество команд протокола со 100+ до 19
		Возможность «конвейерной» работы – отправки дополнительных запросов до получения ответа на предыдущий
		Поддержка символьных ссылок
		Подпись сообщений HMAC SHA256 вместо MD5
		Увеличение кэша и блоков записи\чтения
SMB 2.1	Windows 7/2008R2	Улучшение производительности
		Поддержка большего значения MTU
		Поддержка службы BranchCache – механизм, кэширующий запросы в глобальную сеть в локальной сети
SMB 3.0	Windows 8/2012	Возможность построения прозрачного отказоустойчивого кластера с распределением нагрузки
		Поддержка прямого доступа к памяти (RDMA)
		Управление посредством командлетов Powershell
		Поддержка VSS
		Подпись AES–CMAC
		Шифрование AES–CCM
		Возможность использовать сетевые папки для хранения виртуальных машин HyperV
		Возможность использовать сетевые папки для хранения баз Microsoft SQL
SMB 3.02	Windows 8.1/2012R2	Улучшения безопасности и быстродействия
		Автоматическая балансировка в кластере
SMB 3.1.1	Windows 10/2016	Поддержка шифрования AES–GCM
		Проверка целостности до аутентификации с использованием хеша SHA512
		Обязательные безопасные «переговоры» при работе с клиентами SMB 2.x и выше

Считаем условно пострадавших

Посмотреть используемую в текущий момент версию протокола довольно просто, используем для этого командлет Get–SmbConnection :

Вывод командлета при открытых сетевых ресурсах на серверах с разной версией Windows.

Из вывода видно, что клиент, поддерживающий все версии протокола, использует для подключения максимально возможную версию из поддерживаемых сервером. Разумеется, если клиент поддерживает только старую версию протокола, а на сервере она будет отключена – соединение установлено не будет. Включить или выключить поддержку старых версий в современных системах Windows можно при помощи командлета Set–SmbServerConfiguration , а посмотреть состояние так:

Get–SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

Выключаем SMBv1 на сервере с Windows 2012 R2.

Результат при подключении с Windows 2003.

Таким образом, при отключении старого, уязвимого протокола можно лишиться работоспособности сети со старыми клиентами. При этом помимо Windows XP и 2003 SMB v1 используется и в ряде программных и аппаратных решений (например NAS на GNU\Linux, использующий старую версию samba).

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

Производитель	Продукт	Комментарий
Barracuda	SSL VPN
	Web Security Gateway backups
Canon	Сканирование на сетевой ресурс
Cisco	WSA/WSAv
	WAAS	Версии 5.0 и старше
F5	RDP client gateway
	Microsoft Exchange Proxy
Forcepoint (Raytheon)	«Некоторые продукты»
HPE	ArcSight Legacy Unified Connector	Старые версии
IBM	NetServer	Версия V7R2 и старше
	QRadar Vulnerability Manager	Версии 7.2.x и старше
Lexmark		Прошивки Firmware eSF 2.x и eSF 3.x
Linux Kernel	Клиент CIFS	С 2.5.42 до 3.5.x
McAfee	Web Gateway
Microsoft	Windows	XP/2003 и старше
MYOB	Accountants
NetApp	ONTAP	Версии до 9.1
NetGear	ReadyNAS
Oracle	Solaris	11.3 и старше
Pulse Secure	PCS	8.1R9/8.2R4 и старше
	PPS	5.1R9/5.3R4 и старше
QNAP	Все устройства хранения	Прошивка старше 4.1
RedHat	RHEL	Версии до 7.2
Ricoh	МФУ, сканирование на сетевой ресурс	Кроме ряда моделей
RSA	Authentication Manager Server
Samba	Samba	Старше 3.5
Sonos	Беспроводные колонки
Sophos	Sophos UTM
	Sophos XG firewall
	Sophos Web Appliance
SUSE	SLES	11 и старше
Synology	Diskstation Manager	Только управление
Thomson Reuters	CS Professional Suite
Tintri	Tintri OS, Tintri Global Center
VMware	Vcenter
	ESXi	Старше 6.0
Worldox	GX3 DMS
Xerox	МФУ, сканирование на сетевой ресурс	Прошивки без ConnectKey Firmware

Список взят с сайта Microsoft , где он регулярно пополняется.

Перечень продуктов, использующих старую версию протокола, достаточно велик – перед отключением SMB v1 обязательно нужно подумать о последствиях.

Все-таки отключаем

Если программ и устройств, использующих SMB v1 в сети нет, то, конечно, старый протокол лучше отключить. При этом если выключение на SMB сервере Windows 8/2012 производится при помощи командлета Powershell, то для Windows 7/2008 понадобится правка реестра. Это можно сделать тоже при помощи Powershell:

Set–ItemProperty –Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 –Type DWORD –Value 0 –Force

Или любым другим удобным способом. При этом для применения изменений понадобится перезагрузка.

Для отключения поддержки SMB v1 на клиенте достаточно остановить отвечающую за его работу службу и поправить зависимости службы lanmanworkstation. Это можно сделать следующими командами:

sc.exe config lanmanworkstation depend=bowser/mrxsmb20/nsi sc.exe config mrxsmb10 start=disabled

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

Создание элемента реестра через групповые политики.

Чтобы отключить протокол на сервере, достаточно создать следующий параметр:

путь: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters;

новый параметр: REG_DWORD c именем SMB1;

• значение: 0.

Создание параметра реестра для отключения SMB v1 на сервере через групповые политики.

Для отключения поддержки SMB v1 на клиентах понадобится изменить значение двух параметров.

Сначала отключим службу протокола SMB v1:

путь: HKLM:\SYSTEM\CurrentControlSet\services\mrxsmb10;

параметр: REG_DWORD c именем Start;

• значение: 4.

Обновляем один из параметров.

Потом поправим зависимость службы LanmanWorkstation, чтоб она не зависела от SMB v1:

путь: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation;

параметр: REG_MULTI_SZ с именем DependOnService;

• значение: три строки – Bowser, MRxSmb20 и NSI.

И заменяем другой.

После применения групповой политики необходимо перезагрузить компьютеры организации. После перезагрузки SMB v1 перестанет использоваться.

Работает – не трогай

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

Расскажите, а вы уже отключили у себя SMB первой версии? Много было жертв?

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

Что для этого надо?

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

Также, потребуется место, и притом много места, на жестком диске вашего компьютера.

Как это работает?

На компьютере под управлением Windows XP создается общедоступная (расшареная) папка, ей назначаются разрешения для определенного пользователя на чтение и запись.

А в Dreambox от имени этого самого пользователя монтирует (подключает) эту папку к себе в систему по сети, получая тем самым доступ к жёсткому диску вашего компьютере.

Настройка сети в данной статье не рассматривается. Но посмотри здесь:

Роутер или маршрутизатор TP-Link TL-WR340G / TL-WR340GD.

Установка роутера d-link di-604.

Проблема с маршрутизатором или роутером

Предполагается, что вы уже настроили сетевое подключение между компьютером и Дримом. А то… МАГЁМ.

Некоторые предостережения.

Работая в командной строке все команды, символы и знаки препинания пишем только в английской раскладке!!!

Пути к папкам и файлам в той раскладке, на языке какой они названы. Потому-как, например, русская «а » и английская «a » это совершенно разные буквы для компьютера.

Также, особое внимание обращайте на пробелы.

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

net share dreamshare=»C:\Documents and Settings\Коля\Мои Документы\Мои Записи» /unlimited .

Сразу договоримся, что:

IP-компьютера = 192.168.0.1
IP-Дримбокса = 192.168.0.2
Расшариваемая папка = C:\dream_share
Её псевдоним = dreamshare
Пользователь = abc
Его пароль = def

Понятно что у вас может «ip» отличатся, но очень немного… обычно последняя циферка.

Будем работать только с командной строкой. Дальше вводим команды и жмём клавишу Enter !!!

Поехали:

В Windows: Пуск -> Выполнить -> cmd.exe

Добавим юзера «abc » с паролем «def «:
net user abc def /add /active:yes /passwordchg:no

(Кстати, если у вас имя пользователя записано аглицкими буквами, например Kolya, и есть пароль (также английскими или цифрами), то пользователя можно и не добавлять.

Для записи расшариваемую папку желательно создавать на скоростном винте с NTFS файловой системой и в несистемном разделе. Т.е. если у вас Windows находится в разделе C: , то папку желательно создавать в разделе D: или E: (если таковые имеются), и места в разделе должно быть побольше (20 GB и более).

А это важно…

Создадим папку для шары:
mkdir C:\dream_share

(Кстати, если у вас уже есть папка с видео и музыкой, можно использовать ее. Желательно, чтобы в пути к ней не было неанглийских букв и пробелов (иначе, читайте выше как это обойти).

Создадим подпапку, обязательную для видеозаписи:
mkdir C:\dream_share\movie

Создадим тестовый файл для проверки (на всякий случай):
echo test only — %date% > C:\dream_share\test.txt
Отключим простой доступ к общим файлам и папкам (строка длинная, но надо):
reg add «HKLM\SYSTEM\ControlSet001\Control\Lsa» /v «forceguest» /t REG_DWORD /d 0 /f

Расшарим папку и присвоим ей псевдоним dreamshare , через который Дрим будет обращаться к папке по сети:
net share dreamshare=C:\dream_share /unlimited

Разрешим юзеру «abc » подключать папку по сети и иметь к ней полный доступ (запись, чтение и т.д.):
cacls C:\dream_share /e /g abc:f

(Если команда cacls начала ругаться, то ваша расшариваемая папка находится в FAT32-разделе, и прийдётся немножко посчёлкать мышкой:

1. Пуск -> Панель Управления -> Свойства папок -> закладка Вид . Снимем галку с пункта «Использовать простой доступ к общим файлам «. Сохраняемся.
2. Правый клик мыши на расшариваемой папке -> Свойства -> закладка Общий доступ -> кнопка Разрешения . Добавим юзера «abc » и дадим ему полный доступ. Сохраняемся.

Ну, чтож, нам осталась самая малость: подмонтировать нашу папку к Дриму и проверить всё ли работает.

Возможно, на этом этапе потребуется перезагрузить компьютер и войти опять под своей учётной записью. Хотя у меня и так проходит — без перезагрузки.

Если перезагрузились, то возращаемся в cmd.exe .

Подключимся к Дриму по Telnet, для этого наберём:
telnet 192.168.0.2

Не забыли, что 192.168.0.2 это IP-адрес вашего Дримбокса, как мы и договаривались в начале.

Вводим логин:

Вводим пароль (по умолчанию dreambox ):

dreambox

Монтируем расшареную папку dreamshare с компьютера в папку /var/mnt/hdd на Дримбоксе от имени

пользователя abc (или как там вас кличут) и с паролем def (конечно своим) , возможно это займёт некоторое время:

Mount -t cifs -o rw,soft,udp,nolock,rsize=8192,wsize=8192,iocharset=utf8,user=abc,password= def //192.168.0.1/dreamshare /var/mnt/hdd

Проверяем:
mount -t cifs

И получим приблизительно вот такой вывод, который говорит, папка что dreamshare смонтирована:
//192.168.0.1/dreamshare on /var/mnt/hdd type cifs (rw,nodiratime,unc=\192.168.0.1\dreamshare,usernam e=abc,rsize=8192,wsize=8192)

Посмотрим, что есть в расшареной папке:
ls -l /var/mnt/hdd

И получим содержимое /var/mnt/hdd , где есть наши созданные файл test.txt и папка movie :
drwxrwxrwx 1 root root 7 Jul 29 2008 movie
-rwsrwsrwt 1 root root 7 Jul 29 2008 test.txt

Проверим, можем ли мы создавать файлы в расшареной папке с Дримбокса:
echo «Test from Dreambox» > /var/mnt/hdd/test_box.txt

Опять проверим командой ls :
ls -l /var/mnt/hdd

Удалим тестовые файлы:
rm /var/mnt/hdd/test.txt /var/mnt/hdd/test_box.txt

Размонтируем:
umount /var/mnt/hdd

Всё!!!

Сложно?

Да, чуть не забыл. Для постоянного монтирования строку:
Код:

Mount -t cifs -o rw,soft,udp,nolock,rsize=8192,wsize=8192,iocharset=utf8, user=abc,password=def //192.168.0.1/dreamshare /var/mnt/hdd

можно добавить в какой-нибудь стартовый скрипт Дримбокса, или поступить стандартно:
(для Gemini: Menu -> 6 -> 5 -> 1 -> Синяя кнопка )

IP компьютера = 192.168.0.1
Тип монтирования = CIFS
Директория = dreamshare
Локальная директория = /var/mnt/hdd
Опции = rw,soft,udp,nolock,iocharset=utf8
Екстра опции = nolock,rsize=8192,wsize=8192
USER = abc
PASSWORD = def
Automount = ДА (т.е. отметить галкой)

Ну сейчас точно Всё !!!

P.S. Этот метод тестировался и работает в Windows XP Pro, Windows XP Pro SP1, Windows XP Pro SP2. С Windows XP Pro SP3 и Window 7 не тестировался, но вероятнее всего также будет работать.

И запоминай … работа по CIFS и в Африке работа