Библиотека сайта rus-linux.net
Ошибка базы данных: Table 'a111530_forumnew.rlf1_users' doesn't exist
Безопасность Samba. Часть первая.
Оригинал: Paranoid Penguin - Samba Security, Part I
Автор: Mick Bauer
Дата: 1 ноября 2008
Перевод: Александр Тарасов aka oioki
Дата перевода: 7 марта 2009
Недавно я осознал, что за восемь лет, которые я веду колонку Paranoid Penguin, мною никогда не затрагивались темы файловых серверов. Я освещал темы, связанные с безопасной передачей файлов, к примеру, по scp, rsync и vsftpd. Конечно, это все важно, но нужно поговорить и о файловых серверах, которые позволяют пользователям иметь постоянно подключенные "сетевые диски", чтобы можно было работать с ними, как с обычными локальными дисками. Это эффективно во всех смыслах - пользователям достаточно легко работать с такими дисками, а администратору удобно держать все в одном месте, единым образом обрабатывать и архивировать.
В Linux есть замечательный набор программ для построения и безопасного использования серверов - это набор демонов и команд Samba от Эндрю Триджелла (Andrew Tridgell). Для удобства администрирования в пакет включены графические средства настройки. В следующих статьях я расскажу, как настроить безопасный Samba-сервер, как через командную строку, так и через графические средства.
Чего мы хотим добиться
Очевидно, никакая серия статей не может охватить решение всех задач, связанных с файловыми серверами. Поэтому давайте сразу ограничимся следующей тройкой требований (надеюсь, они совпадают с вашими). Разумно будет остановиться на безопасности, удобстве и кросс-платформенной совместимости.
Среди моих критериев безопасность идет на первом месте - об этом можно даже и не говорить. При настройке файлового сервера я хочу обратить особое внимание на защиту самих данных, а именно целостности (Ц), доступности (Д) и конфиденциальности (К) файлов, размещающихся на сервере, и в процессе передачи по сети. Также я хочу защитить сам сервер - как обезопасить данные, так и предотвратить использование сервера в нерабочих целях.
Три задачи, упомянутые выше (конфиденциальность, целостность и доступность) составляют классическую догму информационной безопасности. В любом случае, когда нужно обеспечивать информационную безопасность - К, Ц и Д являются важными в той или иной степени.
Задачу, решением которой будет запрет на использование сервера в нерабочих или нежелательных целях неавторизованными пользователями, я называю настройкой исключительного доступа. Даже если сами пользовательские данные на 100% скучны и бесполезны, даже если будет сложно настраивать и поддерживать работоспособность сервера, все равно я хочу, чтобы доступ к серверу могли получить только я и пользователи, которых я явным образом выберу.
Даже если мой сервер будет в какой-то степени публичным (кстати, в этом случае более безопасны технологии асинхронной передачи файлов, такие как FTP, HTTP и rsync), но я все равно хочу, чтобы сервер использовался исключительно для этой цели. Совсем не хочется, чтобы он использовался как чей-то пиратский IRC-сервер, склад пиратского софта или прокси для атаки других систем.
Только что я упоминал, что файловый сервер, о котором я говорю (такой вариант, когда можно подключать сетевые диски) не годится для публичного доступа. Это происходит потому что два преобладающих средства (Samba и NFS) исторически основываются на RPC (Remote Procedure Call, удаленный вызов процедуры) - протоколе, работа которого связана с назначением прослушивающих TCP- и UDP-портов на каждого клиента, на каждое соединение, что потребует открытия большого количества портов на файрволле, если таковой имеется. Увы, открывая UDP- и TCP-порты с номерами от 1025 до 65,534 в обоих направлениях через файрволл, мы тем самым сводим на нет все присутствие файрволла.
С другой стороны, современные версии NFS (версии 3 и 4) позволяют серверу (демону) использовать единый для всех пользователей TCP-порт. Однако большинство NFS-серверов в мире все-таки консервативны и поддерживают лишь вторую версию. Добавим к этому, что традиционно поддержка NFS вне мира UNIX и UNIX-подобных систем довольно скудна.
Итак, мы приходим к двум другим нашим требованиям: удобство и кросс-платформенная совместимость. Я хочу, чтобы можно было подключать сетевые диски, потому что это намного удобнее, чем вручную копировать файл на сервер, каждый раз при изменении файла, даже если это будет происходить автоматически с помощью какого-нибудь скрипта. Лучше иметь общий ресурс, который позволит мне работать с файлами, находящимися в этом централизованном хранилище; нежели держать в нескольких местах копии одного и того же файла.
NFS позволяет подключать сетевые диски почти так же, как и Samba. Однако, смирившись с жестокой реальностью, признаю, что иногда мне нужно работать с Windows-системами. Этого требует моя работа, а также желание поиграть в игрушки. Поэтому мне нужен файловый сервер, который поддерживает как Linux-, так и Windows-клиентов... На самом деле, Samba поддерживает еще и FreeBSD, NetBSD, Solaris, Mac OS X и практически все остальные операционные системы из семейства *nix!
Подведем итог. Мы собираемся настроить файловый сервер на Samba, потому что это удобно и имеется поддержка всевозможных клиентских платформ. И мы хотим сделать его максимально безопасным.
Samba через интернет?
Тут вы можете спросить, если Samba так удобна, почему бы не пустить ее по IPsec или другому защищенному VPN-каналу и использовать ее в интернете? На самом деле, это возможно. Довольно давно я изучал протокол IPsec, а потом его поддержка появилась в ядре Linux. Поэтому эту серию статей я завершу кратким руководством по настройке Samba поверх IPsec.
Однако, Samba весьма "говорливый" протокол - он генерирует большое количество пакетов, даже если вы работаете с мелкими файлами. Из-за этого могут появиться проблемы с производительностью: Samba очень чувствительна к потерянным или задержавшимся пакетам. Вероятность таких потерь весьма велика в интернете, по сравнению со значительно более компактными локальными сетями.
Настройка Samba поверх IPsec может стоить вашего времени или нет, однако я напишу об этом в одной из следующих статей моей колонки Paranoid Penguin.
Понятия и концепции Samba
Надеюсь, я толково объяснил, почему Samba, файрволлы и интернет не уживаются вместе. Итак, как же обезопасить Samba-сервер в локальной сети?
Безопасность Samba - это удивительно сложная тема, вот почему по ней будет несколько статей. Есть множество способов обезопасить Samba-сервер. Будет ли ваш Samba-сервер контроллером NT-домена или будет входить в существующий домен или рабочую группу? Разрешите ли гостевой вход в систему, либо каждому пользователю, чтобы войти, нужно будет пройти аутентификацию? Будут ли у вас закрытые и публичные ресурсы?
Не расстраивайтесь, если на какие-то вопросы вы не знаете, как ответить. Я здесь как раз для этого, далее будет все детально разъяснено. А затем мы начнем погружаться в дебри конфигурационного файла smb.conf и демона NMB.
Для начала, определимся с основными понятиями:
- SMB: протокол Server Message Block, сердце Samba. SMB - это набор сообщений, управляющих файловыми ресурами и ресурсами печати.
- CIFS: сокращение от Common Internet File System, на практике то же самое, что и SMB.
- NetBIOS: интерфейс передачи SMB-сообщений в сетевые протоколы нижнего уровня, такие как TCP/IP.
- NBT: спецификация использования NetBIOS поверх TCP/IP.
- WINS: протокол от Microsoft, предназначенный для разрешения NBT-имен в IP-адреса. Это альтернатива технологии DNS от Microsoft.
- Рабочая группа (Workgroup): одноранговая группа компьютеров, предоставляющих общие SMB-ресурсы. Пользовательские учетные записи децентрализованы, то есть хранятся на самих системах, а не на едином центральном сервере.
- Домен NT (NT domain): совокупность компьютеров, пользовательских учетных записей и других групп (но не включает в себя другие домены). Эта конфигурация сложнее рабочих групп, но из-за того, что сведения о пользователях хранятся централизованно в одном месте, а не разбросаны по серверам сети, управлять ею намного удобнее. Более того, домен проще масштабировать, нежели рабочую группу.
- Active Directory: доменная система последнего поколения от Microsoft. Samba-сервер может работать как клиент Active Directory через Kerberos, однако с помощью Samba-сервера не получится управлять деревом Active Directory. Однако это возможно в доменах NT. Полная поддержка Active Directory появится в 4-й версии Samba.
- Режим доступа пользователя (User-mode security): когда доступ к ресурсам Samba-сервера предоставляется в локальной рабочей группе по имени пользователя и паролю.
- Режим доступа ресурса (Share-mode security): когда доступ к каждому ресурсу на Samba-сервере осуществляется по паролю, присущему этому данному ресурсу, а не пользователям.
- Гостевой доступ: когда Samba-сервер предоставляет ресурс анонимным пользователям. При этом используется специальная гостевая учетная запись и пароль не указывается.
Вот что нужно вынести из этого списка определений.
Во-первых, это протоколы. SMB, или иначе CIFS - это протокол, определяющий сетевую файловую систему, ее структуру и порядок использования. NetBIOS предоставляет интерфейс, через который SMB-сообщения передаются в сети, он используется серверами для "анонса" служб в сети, и клиентами для "обзора" этих служб. NetBIOS в качестве транспортного протокола может использовать любой низкоуровневый сетевой протокол, однако наиболее часто используется TCP/IP; когда NetBIOS работает поверх TCP/IP, это называется NBT. WINS предоставляет централизованные службы имен (отображение имен машин в IP-адреса) там, где это необходимо.
Далее, роли сервера. Samba-сервер может аутентифицировать транзакции либо на основе самих ресурсов, при этом используются пароли, привязанные к данному конкретному ресурсу, и неявные имена пользователей; либо на основе пользователей, хранящихся в локальной базе данных пользователей (режим доступа пользователя), либо в какой-нибудь сетевой структуре, такой как LDAP, NIS, домены NT или Active Directory. Сервер может находиться в рабочей группе, в этом случае на нем должны храниться все сведения обо всех пользователях сети; либо он может быть включен в домен NT или Active Directory, в этом случае информация о пользователях хранится и обрабатывается централизованно.
Когда вы хотите дать общий доступ с минимумом ограничений и наибольшим удобством, к примеру, файлы только для чтения, доступ к которым одинаков для всех пользователей - можно открыть гостевой доступ. Пользователи, подключающиеся к такому ресурсу, не будут вводить ни имя пользователя, ни пароль, а сразу попадут в папку с файлами.
И это лишь малая часть тех знаний, которые нужны для понимания служб SMB/Samba. Домены NT и Active Directory не будет упоминаться в этой серии статей. Здесь мы сконцентрируемся на создании безопасного файлового сервера Samba.
Рабочие группы плохо наращиваются, потому что каждому серверу в группе приходится самостоятельно поддерживать сведения о пользователях всей рабочей группы, и вам как администратору необходимо будет каким-либо образом упорядочивать эти сведения и информировать пользователей об их паролях (кроме тех случаев, когда используется гостевой доступ или режим доступа ресурса).
Создание одного или двух общих файловых ресурсов, к которым можно получить доступ из домашней сети (пользователей не так много, да и сервер, пожалуй, будет лишь один) - такова наша задача. Поэтому мы предпочтем простой отдельный сервер в рабочей группе, а не сложный, но правда и мощный, сервер в домене NT. Если вам нужно сделать обратное, все равно эти статьи помогут вам в установке Samba-сервера в NT-домене.
Итак, в следующих статьях я планирую провести вас по процессу настройки отдельного Samba-сервера (для рабочей группы), работающем в режиме доступа пользователя, сведения о пользователях хранятся в локальной базе данных. Наш сервер будет предоставлять несколько общих ресурсов с гостевым доступом с правами только на чтение, а также общие ресурсы, которые могут быть прочитаны некоторыми пользователями, а некоторыми другими они могут быть еще и изменены.
Но сначала нам нужно где-нибудь достать сам программный пакет Samba.
Где достать пакет Samba
На машине, которая будет исполнять роль сервера, необходимо будет через пакетный менеджер установить пакеты библиотек Samba; Samba-демонов smbd, nmbd и winbindd; клиентские команды Samba - smbclient, smbmount и т.п. (они полезны при отладке конфигураций сервера Samba); а также веб-интерфейс для конфигурирования - SWAT (см. рисунок 1). Все эти компоненты содержатся в пакетах, имена которых мало связаны с названиями демонов, библиотеками и т.п., но я скажу ниже, что именно устанавливать.
Рисунок 1. Веб-интерфейс SWAT
Сначала пару слов о SWAT, установка которого в Ubuntu потребует небольшого снижения безопасности. В Ubuntu сделано так, что пользователь root не может напрямую войти в систему, а для Samba это необходимо. Придется искать компромисс, а именно устанавливать пароль пользователю root в Ubuntu, на котором установлен SWAT.
Но я не рекомендую этого делать на машине, открытой для интернета. Можно ограничиться и ручной правкой конфигурационных файлов. SWAT - это всего лишь полезный и удобный интерфейс для изучения Samba; однако в локальных сетях использование SWAT может оградить вас от ошибок конфигурирования, гораздо более опасных, чем само по себе использование SWAT.
Как я упоминал, пакеты Samba включены в большинство современных дистрибутивов Linux. В Debian и его производных, таких как Ubuntu, нужно будет установить следующие deb-пакеты: samba, samba-common, samba-doc, smbclient и swat (плюс дополнительные зависимости, которые могут вылезти).
В системе SUSE нужно установить samba, samba-client, samba-winbind и samba-doc (SWAT включен в один из этих пакетов, предположительно в samba).
В дистрибутиве Red Hat Enterprise и его производных потребуются пакеты samba, samba-client, samba-common и samba-swat.
При установке этих бинарных файлов будут вызваны установочные скрипты, которые поместят в нужное место системы инициализационные скрипты (для автоматического запуска служб при загрузке системы), создадут символьные ссылки и другие подобные вещи, чтобы все нормально работало. SWAT - лучший способ знакомства с Samba, с его помощью можно настроить что-нибудь сразу, обладая минимумом знаний. В него интегрирована замечательная справочная система, которая по вашему запросу вызывает разные части man-страницы Samba.
Есть два нюанса работы со SWAT, о которых нужно упомянуть. Во-первых, SWAT должен запускаться супер-сервером интернета, таким как старый берклевский inetd или современный xinetd. Ubuntu автоматически сконфигурирует inetd при установке пакета swat, однако если этого не сделает ваш дистрибутив, вам придется добавить или раскомментировать следующую строчку в файле /etc/inetd.conf:
swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat
Во-вторых, чтобы работала справка SWAT в SUSE 11.0, нужно будет создать несколько символьных ссылок, вот так, от имени пользователя root:
ln -s /usr/share/doc/packages/samba/htmldocs/manpages /usr/share/samba/swat/help ln -s /usr/share/doc/packages/samba/htmldocs/using_samba /usr/share/samba/swat/help ln -s /usr/share/doc/packages/samba/htmldocs/index.html /usr/share/samba/swat/help ln -s /usr/share/doc/packages/samba/htmldocs/manpages.html /usr/share/samba/swat/help
Заключение
Итак, теперь мы готовы настраивать наш Samba-сервер! Пока готовится следующая статья серии, можете обратиться к источникам информации, указанным ниже. Также не забывайте обращаться к справке в самом SWAT.
Источники информации
1. Christopher R. Hertel's On-Line Book Implementing CIFS. Полноценный источник информации по всему, что связано с CIFS/SMB:
www.ubiqx.org/cifs
2. "The Official Samba 3.2.x HOWTO and Reference Guide":
http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection
Mick Bauer (darth.elmo [at] wiremonkeys [dot] org) - архитектор сетевой безопасности одного из крупнейших банков США. Он является автором книги Linux Server Security, 2nd edition издательства O'Reilly (ранее называлась Building Secure Servers With Linux), иногда выступает на конференциях по информационной безопасности.