Библиотека сайта rus-linux.net
Безопасность Samba. Часть четвертая.
Оригинал: Paranoid Penguin - Samba Security, Part IV
Автор: Mick Bauer
Дата: 1 февраля 2009
Перевод: Александр Тарасов aka oioki
Дата перевода: 13 мая 2009
В этой серии статей мы рассматриваем задачу настройки защищенного Samba-сервера для нашей локальной сети с помощью веб-интерфейса Swat. Напомню, в предыдущих статьях мы настраивали общие ресурсы с различными правами доступа.
Данная статья будет последней в этой серии, и в ней я расскажу, как создать ограниченный ресурс, доступный только для его владельца, а также как монтировать Samba-ресурсы на клиентских системах с помощью утилиты mount.cifs.
Что уже было сделано
В предыдущей статье мы создали публичный ресурс SUPPER, и непубличный ресурс с доступом для членов группы CHORES. Перед этим были сделаны глобальные настройки - они относятся ко всем общим ресурсам сразу. Вот эти глобальные параметры:
workgroup = FED-CENTRAL security = user client schannel = yes server schannel = yes map to guest = Bad User guest account = nobody unix password sync = yes valid users = mick, knute, pepe, skippy, nobody read list = knute, pepe, skippy write list = mick
Внимательный читатель может обратить внимание, что я опустил параметр admin users, хотя во второй статье серии этот параметр был установлен в mick. Это моя ошибка. По крайней мере в системах типа Ubuntu, при установке этого параметра нарушаются связи взаимодействия Samba и прав доступа на файл в системе Linux. Поэтому параметр admin users лучше очищать.
Напомню, что пользователи из списка admin users получают привилегии пользователя root после аутентификации в Samba. Другими словами, если параметру admin users присвоено значение mick, тогда каждый раз когда он будет входить на Samba-ресурс, он фактически будет входить в систему под пользователем root. Таким образом, пользователь mick по сути обладает привилегиями администратора, и действия его ничем не ограничены. На практике последствия такой настройки могут быть совершенно непредсказуемыми.
Рассмотрим для примера мою систему Ubuntu 8.04. Допустим, параметру admin users установлено значение mick. Давайте создадим каталог, владельцем которого будет пользователь mick, а права доступа - rwx------ (или 0700), а затем создадим Samba-ресурс, соответствующий этому каталогу, причем на нем не должно быть настройки гостевого входа или доступа только на чтение (такую мы настроим чуть позже).
Теперь если я попробую соединиться с этим ресурсом с помощью команды:
bash-$ smbclient //CASA_DE_MICK/BUZZ-OFF -U mick
и введу правильный пароль пользователя mick, тогда на самом деле я должен буду прозрачно войти в систему как root. Однако на самом деле произойдет следующее:
Domain=[CASA_DE_MICK] OS=[Unix] Server=[Samba 3.0.28a] tree connect failed: NT_STATUS_ACCESS_DENIED
Как же это возможно? Доступ не должен быть ограничен ничем, ведь мы работаем от root, не так ли? Однако доступ все-таки будет запрещен, потому что по логике Samba ресурс не принадлежит пользователю root. Такое поведение может встречаться на системах, отличных от Ubuntu, а может и не встречаться. Как мне кажется, влияние параметра admin users непредсказуемо влияет на поведение системы.
Как я уже говорил в прошлый раз, возможность использования пользователями Samba-ресурса от имени пользователя root в любом случае небезопасна. Samba-клиент - не самое лучшее средство администрирования. Вот, как минимум две причины, чтобы оставить параметр admin users пустым.
Продолжим рассмотрение параметров, отвечающих за конкретные ресурсы. Переменные файла smb.conf, задающие настройки для ресурса SUPPER и установленные с помощью средства Swat, выглядят следующим образом:
path = /home/mick/supper read only = yes guest ok = yes invalid user = root valid users = read list = write list = mick admin users = hosts allow = 192.168.44 hosts deny = ALL create mask = 0644 browseable = yes available = yes
Для ресурса CHORES все параметры такие же, за исключением следующих:
path = /home/mick/chores guest ok = no valid users = +users
Что означают все эти переменные? Их предназначение тщательно объяснено в предыдущих статьях, официальные сведения можно найти в man-странице smb.conf(5). Некоторые параметры из приведенных здесь нам еще понадобятся, когда мы будем создавать разделяемый ресурс с ограниченным доступом.
Создание ограниченного ресурса
Напомню, что наш Samba-сервер содержит четыре пользовательских аккаунта: pepe, skippy, knute, mick - это три моих квартиранта и я сам. Эти учетные записи являются стандартными учетными записями UNIX, и им соответствуют отдельные записи в базе данных пользователей Samba-сервера. Как создавать и синхронизировать учетные записи пользователей Samba, было рассказано во второй статье этой серии.
Итак, к нашему ограниченному ресурсу BUZZ-OFF может обращаться лишь один пользователь - mick. Он будет иметь доступ как на чтение, так и на записть. Все остальные пользователи не будут иметь никаких прав доступа на этот ресурс. Соответственно, при создании каталога данного ресурса, нужно установить владельцем пользователя mick, а права доступа - 0700 (u+rwx,g-rwx,o-rwx), к примеру так:
drwx------ 2 mick users 4096 2008-11-04 00:00 buzz-off
На рисунке 1 показаны первые настройки, которые нужно прописать сразу после создания ресурса в базовом режиме просмотра Swat.
Рисунок 1. Ограниченный ресурс, базовые настройки
После установки пути path, устанавливаем параметр read only в значение no - ведь пользователь mick будет создавать здесь новые файлы, а параметр guest ok, разумеется, в no - мы не хотим давать анонимного доступа к ресурсу. Параметры hosts allow и hosts deny оставим такими же, как и для других ресурсов - а именно дадим доступ для IP-адресов из локальной сети (в вашей локальной сети, скорее всего, другой диапазон IP-адресов).
Присвоим переменной browseable значение no - мы не хотим, чтобы ресурс даже появлялся в Сетевом окружении или smbtree других пользователей. Теперь, чтобы подключиться к этому ресурсу, мы должны будем указать явный путь к нему.
Присвоим пока параметру available значение no. Нажмем кнопку Commit Changes, переключимся в расширенный режим с помощью кнопки Advanced. Нужно произвести еще здесь несколько настроек, см. рисунок 2.
Рисунок 2. Ограниченный ресурс, расширенные настройки
Как вы видите, мы собираемся очистить список valid users, за исключением mick, и полностью очистим список read list. Параметр write list, однако, будет содержать единственного mick.
Одна настройка, которую нужно будет поменять - это параметр create mask, которому нужно присвоить значение 0600. Это отличается от маски 0700, которую мы устанавливали на создание каталогов; каталогам необходимо право на исполнение, иначе нельзя будет в них войти, однако содержимому каталога, т.е. файлам, это совершенно необязательно.
Теперь можем включить ресурс (устанавливаем значение available в yes, нажимаем Commit Changes). Теперь наш ограниченный ресурс готов к использованию!
Чтобы это проверить, удостоверимся, что ресурс не отображается в списке локальных ресурсов. Это можно сделать, к примеру, с помощью утилиты smbtree, так:
bash-$ smbtree -N -b
FED-CENTRAL
\\CASA_DE_MICK iwazaru-ubuntu server (Samba, Ubuntu)
\\CASA_DE_MICK\print$ Printer Drivers
\\CASA_DE_MICK\SUPPER Mick's menus
\\CASA_DE_MICK\CHORES Chore lists
\\CASA_DE_MICK\IPC$ IPC Service (iwazaru-ubuntu server (Samba, Ubuntu))
Действительно, новый ресурс BUZZ-OFF не отображается в списке ресурсов. Но ведь он должен быть доступен пользователю mick, владельцу. Давайте проверим с помощью smbclient:
bash-$ smbclient //CASA_DE_MICK/BUZZ-OFF -U mick Password: ******** Domain=[CASA_DE_MICK] OS=[Unix] Server=[Samba 3.0.28a] smb: \>
Работает. Мы получили приглашение Samba! Нет причин не попробовать вывести список файлов:
smb: \> dir
. D 0 Tue Nov 4 23:17:34 2008
.. D 0 Tue Nov 4 23:17:34 2008
access-log_10312008.txt 665 Tue Nov 4 23:17:34 2008
52008 blocks of size 262144. 13229 blocks available
smb: \> exit
Итак, все работает, как мы предполагали. Последняя проверка - хочу войти в ресурс как гость. Запомните, что если клиент ввел несуществующее имя пользователя, тогда Samba-сервер будет рассматривать его как гостя:
bash-$ smbclient //CASA_DE_MICK/BUZZ-OFF -U totallyfakeuser Password: ******** Domain=[CASA_DE_MICK] OS=[Unix] Server=[Samba 3.0.28a] tree connect failed: NT_STATUS_ACCESS_DENIED
Произошла ошибка доступа, как и предполагалось.
Подключение сетевых дисков с помощью mount.cifs
Итак, у нас есть ограниченный ресурс, который доступен только мне. Предположим, что есть файлы на нем, которые я хочу регулярно обновлять. Неужели каждый раз придется использовать этот консольный клиент smbclient?
Конечно же, нет. Возможность монтировать удаленные Samba-ресурсы так, как будто это разделы жесткого диска - одна из самых замечательных возможностей Samba. Это можно сделать на клиентских машинах с помощью стандартной команды mount, а также с помощью модуля Samba под названием mount.cifs.
В системах, основанных на Red Hat и SUSE, файловая система cifs и соответствующие утилиты включены в стандартный пакет samba-client. В Debian, Ubuntu и других дистрибутивах, основанных на Debian, придется установить пакет smbfs.
Smbfs и cifs, хотя и основаны на одном и том же протоколе, но на самом деле представляют из себя две разные вещи. Реализация cifs новее, чем smbfs, а команда smbmount ранее использовалась для монтирования файловых ресурсов Samba через smbfs, но этот способ был признан разработчиками устаревшим, а новой реализацией стала cifs с модулем mount.cifs. Smbfs и smbmount все еще распространяются с программным набором Samba, однако разработчики их почти не поддерживают.
Возможно, вам понадобится также пакет winbind, который используется модулем mount.cifs для разрешения имен NetBIOS или Windows NT (Samba-сервер, который мы настраиваем, использует разрешение имен NetBIOS, а не Windows NT). Пользователям SUSE нужно будет установить пакет samba-winbind. Пакет winbind включен также в пакет samba-client дистрибутивов Red Hat/CentOS/Fedora.
После установки winbind, нужно добавить строку wins в строчку hosts: файла /etc/nsswitch.conf. Это может проделать лишь пользователь root, так что придется воспользоваться su или sudo.
Итак, утилиты mount.cifs и winbind установлены, теперь мы готовы монтировать ресурсы Samba. Для подключения вручную из командной строки, можно вызвать команду mount от имени root, к примеру так:
myclientlaptop-$ sudo mount -t cifs //CASA_DE_MICK/BUZZ-OFF ./mymountpoint -o rw,suid,user=mick
В этом примере, мы указали утилите mount тип файловой системы (-t cifs). Очевидно, мы монтируем ресурс BUZZ-OFF, находящийся на сервере //CASA_DE_MICK, точкой монтирования является каталог ./mymountpoint, он находится в моем домашнем каталоге. Обратите внимание, что я могу вместо имени NetBIOS (или имени Windows NT) использовать IP-адрес Samba-сервера, в этом случае часть команды будет выглядеть как //192.168.44.123/BUZZ-OFF.
Ключ -o предназначен для задания опций монтирования. Первая опция rw позволяет мне монтировать ресурс с правами как для чтения, так и для записи. Опция suid приводит к тому, что бит set-uid признается. Опция user указывает имя пользователя, с правами которого происходит подключение к ресурсу. После ввода этой команды, у пользователя, сидящего за компьютером, спросят сначала пароль администратора root, а затем пароль пользователя mick.
Что бы вы ни делали, не вводите в командной строке пароль в открытом виде с помощью опции password=. Команды оболочки сохраняются во всевозможных журналах и отображаются в списках запущенных процессов, поэтому это очень плохая идея. Лучше вводить пароли в "скрытом" виде, когда вам это предлагают.
Если данные аутентификации не столь важны, к примеру, когда они не соотнесены ни с каким UNIX-пользователем, обладающим доступом на машину, тогда можно не вводить пароль, а аутентифицироваться с помощью "удостоверения" (credential file). Такой файл - это всего лишь текстовый файл, содержащий имя пользователя и пароль.
Однако этот метод не годится для хранения данных аутентификации, с помощью которых можно зайти удаленно на машину (к примеру, по SSH). Даже если у вас стоят строгие ограничения на доступ к файлу, все равно у злоумышленника есть шансы скопировать или прочитать файл-удостоверение.
Как и в случае монтирования обычных разделов жесткого диска, можно сэкономить время, если добавить запись в файл /etc/fstab. К примеру, для указанной выше команды соответствующая запись в /etc/fstab будет иметь следующий вид:
//CASA_DE_MICK/BUZZ-OFF /home/mick/mymountpoint cifs rw,noauto,suid,user=mick 0 0
Как видите, эта строка очень похожа на команду mount, которую мы вводили ранее. Но здесь появляется опция noauto, которая подавляет автоматическое монтирование ресура при загрузке системы. Ресурс не будет подключен, пока вы вручную не введете команду mount, например так:
myclientlaptop-$ sudo mount /home/mick/mymountpoint
При этом sudo затребует у вас пароль администратора root (опять же, если у вас стоит не Ubuntu, а другая система, тогда можно опустить sudo и просто выполнять команды из сессии пользователя root). После этого будет запрошен пароль уже пользователя mick.
Предполагая, что аутентификация прошла успешно, можно пользоваться подмонтированным удаленным ресурсом BUZZ-OFF так, как будто это часть вашей локальной файловой системы, расположенной по пути /home/mick/mymountpoint. Когда закончите работу с ресурсом, его можно отключить следующим образом:
bash-$ sudo umount /home/mick/mymountpoint
Если же вы предпочитаете, чтобы Samba-ресурс подключался автоматически при загрузке системы, нужно убрать опцию noauto из файла /etc/fstab. Однако если вы не пользуетесь credentials-файлом, тогда вы будете обязаны присутствовать при загрузке системы, ведь она будет спрашивать у вас пароль для подключения удаленного ресурса - и будет ждать бесконечно долго. Для ноутбука это не проблема, однако для других систем, к примеру, серверных, это может быть очень неудобно.
Аналогично, если сам Samba-сервер по какой-либо причине недоступен, тогда ваша клиентская машина будет зависать или надолго задерживаться. В общем, если сомневаетесь, включайте опцию noauto.
Заключение
Итак, завершилась серия статей по безопасной настройке Samba. Надеюсь, в этих статьях вы нашли для себя что-нибудь полезное.
Ссылки
"Samba Security, Part I", LJ, November 2008: www.linuxjournal.com/article/10224
"Samba Security, Part II", LJ, December 2008: www.linuxjournal.com/article/10256
"Samba Security, Part III", LJ, January 2009: www.linuxjournal.com/article/10292
Переводы на сайте Линукс по-русски:
1. Безопасность Samba. Часть первая.
2. Безопасность Samba. Часть вторая.
3. Безопасность Samba. Часть третья.
Mick Bauer (darth.elmo [at] wiremonkeys [dot] org) - архитектор сетевой безопасности одного из крупнейших банков США. Он является автором книги Linux Server Security, 2nd edition издательства O'Reilly (ранее называлась Building Secure Servers With Linux), иногда выступает на конференциях по информационной безопасности.