|
|
содержание .. 1 2 3 ..
Множественное связывание
устройств (DM-Multipath)
Опция
Описание
-ll
Показывает текущую конфигурацию multipath,
собранную из sysfs, маршрутизатора устройств и
всех иных доступных компонентов в системе.
-f device
Удалить именованное множественное устройство.
-F
Удалить все неиспользуемые множественные
устройства.
5.9. Определение меток маршрутизации устройств
командой dmsetup
Вы можете использовать команду dmsetup для поиска того, какие метки
маршрутизаторов устройств соответствуют каким множественным
устройствам.
Следующая команда показывает все маршрутизаторы устройств и их
старшие и младшие номера. Младшие номера определяют имя dm
устройства. Например, младший номер 3 соответствует множественному
устройству /dev/dm-3.
# dmsetup ls
mpathd
(253, 4)
mpathep1
(253, 12)
mpathfp1
(253, 11)
mpathb
(253, 3)
mpathgp1
(253, 14)
mpathhp1
(253, 13)
mpatha
(253, 2)
mpathh
(253, 9)
mpathg
(253, 8)
VolGroup00-LogVol01
(253, 1)
mpathf
(253, 7)
VolGroup00-LogVol00
(253, 0)
mpathe
(253, 6)
mpathbp1
(253, 10)
mpathd
(253, 5)
5.10. Решение проблем с помощью интерактивной
консоли multipathd
Команда multipathd -k - это интерактивный интерфейс к сервису
multipathd. Ввод этой команды запускает интерактивную консоль
multipath. После ввода этой команды вы можете ввести help для получения
91
Множественное связывание
устройств (DM-Multipath)
списка доступных команд, интерактивную команду или нажать CTRL-D для
выхода.
Интерактивная консоль multipathd может быть использована для решения
проблем, которые могут возникнуть на вашей системе. Например,
следующая последовательность команд показывает конфигурацию
multipath, включая умолчания, до выхода из консоли. Смотрите статью IBM
"Tricks with Multipathd"3 для дополнительных примеров.
# multipathd -k
> > show config
> > CTRL-D
Следующая последовательность команд подтверждает что multipath
подхватила все изменения в multipath.conf.
# multipathd -k
> > reconfigure
> > CTRL-D
Используйте следующую последовательность команд, чтобы убедиться, что
контроль маршрутов работает правильно.
# multipathd -k
> > show paths
> > CTRL-D
Команды могут также передаваться через поток stdin в multipathd, как
показано ниже:
# echo 'show config' | multipathd -k
92
Глава 6. Удалённое
администрирование
Есть множество способов удалённого администрирования сервера Linux.
В этой главе рассматриваются два наиболее популярные приложения:
OpenSSH и Puppet.
93
Удалённое администрирование
1. Сервер OpenSSH
1.1. Введение
Этот раздел руководства по Ubuntu Server представляет мощную
коллекцию инструментов для удалённого управления и обмена данными с
сетевыми компьютерами, которая называется OpenSSH. Вы также изучите
некоторые конфигурационные настройки, доступные для серверного
приложения OpenSSH, и то, как изменять их в вашей системе Ubuntu.
OpenSSH - это свободно распространяемая версия семейства
инструментов для удалённого управления компьютерами и передачи
файлов с использованием протокола Secure Shell (SSH). Традиционные
инструменты, используемые для этих целей, такие как telnet и rcp,
небезопасны и передают пользовательский пароль открытым текстом.
OpenSSH предоставляет серверный демон и клиентские приложения для
облегчения операций защиты, зашифрованного удалённого управления и
передачи файлов, эффективно заменяя устаревшие инструменты.
Серверная компонента OpenSSH, sshd, постоянно ожидает клиентских
соединений от любых клиентских программ. Когда приходит запрос
на соединение, sshd устанавливает правильный тип соединения, в
зависимости от типа подключаемого клиента. Например, если удалённый
компьютер пытается подключиться с помощью клиента ssh, то сервер
OpenSSH после аутентификации запустит сеанс удалённого управления.
Если же удалённый пользователь подключается с помощью scp, серверный
демон OpenSSH после аутентификации организует безопасное копирование
файлов между сервером и клиентом. OpenSSH может использовать
множество методов аутентификации, включая обычный пароль,
использование открытого ключа и сертификаты Kerberos.
1.2. Установка
Установка клиента и сервера OpenSSH проста. Для установки клиента
OpenSSH на вашу систему Ubuntu используйте следующую команду в
строке терминала:
sudo apt-get install openssh-client
Для установки сервера OpenSSH и всех необходимых файлов выполните эту
команду в строке терминала:
94
Удалённое администрирование
sudo apt-get install openssh-server
Пакет openssh-server также может быть выбран для установки во время
инсталляции Server Edition.
1.3. Конфигурация
Вы можете настроить режим работы по умолчанию серверного приложения
OpenSSH, sshd, редактируя файл /etc/ssh/sshd_config. Для получения
информации о конфигурационных директивах, используемых в этом
файле, вы можете просмотреть соответствующее руководство с помощью
следующей команды, выполненной в командной строке терминала:
man sshd_config
Существует множество директив в конфигурационном файле sshd,
управляющих такими вещами, как настройки соединений и способы
аутентификации. Далее следуют примеры конфигурационных директив,
которые могут быть изменены редактированием файла /etc/ssh/sshd_config.
Перед внесением изменений в файл настроек вы должны сделать
копию оригинального файла и защитить её от записи. Благодаря
этому, вы всегда сможете посмотреть оригинальные настройки, а в
случае необходимости вы сможете вернуться к этим настройкам.
Создайте копию файла /etc/ssh/sshd_config и защитите её от записи,
введя в терминале следующие команды:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
sudo chmod a-w /etc/ssh/sshd_config.original
Ниже даны примеры конфигурационных директив, которые вы можете
изменить:
• Чтобы настроить демона OpenSSH в режим прослушивания TCP порта
2222, вместо стандартного TCP порта 22, измените директиву Port таким
образом:
Port 2222
• Чтобы sshd разрешал использовать процедуру идентификации
пользователя с помощью данных, основанных на открытом ключе, просто
добавьте или измените следующую строку:
PubkeyAuthentication yes
Если строка уже присутствует, убедитесь, что она не закомментирована.
95
Удалённое администрирование
• Чтобы ваш сервер OpenSSH отображал содержимое файла /etc/issue.net
в качестве сообщения перед логином, просто добавьте или измените
следующую строку:
Banner /etc/issue.net
В файле /etc/ssh/sshd_config.
После внесения изменений в файл /etc/ssh/sshd_config, сохраните его и,
чтобы изменения вступили в силу, перезапустите серверное приложение
sshd, выполнив следующую команду в терминале:
sudo /etc/init.d/ssh restart
Существует множество других директив конфигурации sshd для
изменения поведения серверного приложения под ваши нужды.
Однако учтите, что если единственный способ доступа к серверу -
это ssh, и вы допустили ошибку конфигурации sshd в файле /etc/ssh/
sshd_config, то ваш сервер может оказаться заблокированным, пока
его не перезагрузите. В дополнение, если указана неправильная
конфигурационная директива, сервер sshd может отказаться
загружаться, поэтому будьте очень осторожны, когда редактируете
этот файл на удалённом сервере.
1.4. Ключи SSH
Ключи SSH разрешают аутентификацию пользователей между двумя
узлами без необходимости ввода пароля. Аутентификация по ключам SSH
использует два ключа: секретный и открытый.
Чтобы сгенерировать ключи, наберите в приглашении терминала:
ssh-keygen -t dsa
Эта команда сгенерирует ключи с помощью метода Digital Signature
Algorithm (DSA). Во время процесса генерации вам будет предложено
ввести пароль. Просто нажмите Enter на запрос о создании ключа.
По умолчанию открытый ключ сохраняется в файл ~/.ssh/id_dsa.pub, в то
время как секретный - в ~/.ssh/id_dsa. Теперь скопируйте файл id_dsa.pub на
удалённый компьютер и добавьте его к ~/.ssh/authorized_keys командой:
ssh-copy-id username@remotehost
96
Удалённое администрирование
В конце дважды проверьте права доступа к файлу authorized_keys. Только
аутентифицированный пользователь должен имть права на чтение и
запись этого файла. Если права установлены некорректно, измените их:
chmod 600 .ssh/authorized_keys
Теперь у вас есть возможность соединиться по SSH с этим узлом без ввода
пароля.
1.5. Ссылки
• Страница SSH на Ubuntu Wiki1.
• Сайт OpenSSH2
• Страница Wiki о расширенных настройках OpenSSH3
97
Удалённое администрирование
2. Puppet
Puppet - это кроссплатформенный фреймворк, позволяющий системным
администраторам выполнять общие задачи администрирования с
помощью кода. Код может выполнять различные задачи: от установки
новых программ до проверки прав доступа к файлам или обновления
пользовательских учётных записей. Puppet превосходна не только в
процессе изначальной установки системы, но и на протяжении всего
жизненного цикла системы. В большинстве случаев puppet используется в
конфигурации клиент/сервер.
Этот раздел посвящён установке и настройке Puppet в конфигурации
клиент/сервер. Этот простой пример демонстрирует, как установить Apache
с использованием Puppet.
2.1. Установка
Для установки Puppet наберите в терминале сервера:
sudo apt-get install puppetmaster
На клиентском компьютере (или нескольких компьютерах), введите:
sudo apt-get install puppet
2.2. Конфигурация
Прежде чем настраивать puppet, вам, возможно, захочется добавить запись
DNS CNAME для puppet.example.com, где example.com - это ваш домен. По
умолчанию клиенты Puppet проверяют DNS на наличие puppet.example.com
в качестве имени сервера puppet (Puppet Master). Посетите раздел Глава 8,
Служба доменных имён (DNS) [158] для дополнительных деталей
использования DNS.
Если вы не предполагаете использовать DNS, вы можете добавить записи
в файл /etc/hosts на сервере и клиенте. Например, в файл /etc/hosts сервера
Puppet добавьте:
127.0.0.1 localhost.localdomain localhost puppet
192.168.1.17 meercat02.example.com meercat02
На каждом клиенте Puppet добавьте запись для сервера:
192.168.1.16 meercat.example.com meercat puppet
98
Удалённое администрирование
Замените указанные в приведённом выше примере IP-адреса и
доменные имена на реальные адреса и доменные имена вашего
сервера и клиента.
Теперь настроим некоторые ресурсы для apache2. Создайте файл /etc/
puppet/manifests/site.pp, содержащий следующее:
package {
'apache2':
ensure => installed
}
service {
'apache2':
ensure => true,
enable => true,
require => Package['apache2']
}
Далее создайте файл узла /etc/puppet/manifests/nodes.pp с:
node 'meercat02.example.com' {
include apache2
}
Замените meercat02.example.com на реальное имя хоста вашего
клиента Puppet.
Финальным шагом для этого простого сервера Puppet является перезапуск
демона:
sudo /etc/init.d/puppetmaster restart
Теперь на сервере Puppet всё настроено, и пришло время настроить
клиента.
Сначала настроим демон агента Puppet для запуска. Отредактируйте /etc/
default/puppet, заменив значение START на yes:
START=yes
Далее запустите сервис:
sudo /etc/init.d/puppet start
Возвращаемся на Puppet сервер для подписи клиентского сертификата с
помощью команды:
99
Удалённое администрирование
sudo puppetca --sign meercat02.example.com
Проверьте /var/log/syslog на предмет наличия каких-либо ошибок
конфигурации. Если всё прошло успешно, пакет apache2 и его зависимости
будут установлены на клиенте Puppet.
Этот пример очень простой и не показывает многие возможности и
преимущества Puppet. Для дополнительной информации смотрите
Раздел 2.3, «Ресурсы» [100].
2.3. Ресурсы
• Посетите сайт официальной документации Puppet4.
• Также смотрите Pro Puppet5.
• Ещё один источник дополнительной информации - страница Ubuntu Wiki
Puppet6.
100
Удалённое администрирование
3. Zentyal
Zentyal - это Linux-сервер для малого бизнеса, который может быть
сконфигурирован как шлюз (Gateway), инфраструктурный менеджер
(Infrastructure Manager), защитный сервер (Unified Threat Manager), офисный
сервер (Office Server), коммуникационный сервер (Unified Communication
Server) или любое их сочетание. Все сетевые сервисы, управляемые
Zentyal, тесно интегрированы, автоматизируя большинство задач. Это
помогает избежать ошибок в сетевых настройках и администрировании,
и, как следствие, сэкономить время. Zentyal имеет открытый исходный
код, опубликованный под лицензией GNU General Public License (GPL) и
запускается поверх Ubuntu GNU/Linux.
Zentyal содержит серию пакетов (обычно по одному на модуль), которые
обеспечивают веб-интерфейс для настройки различных серверов или
сервисов. Конфигурация сохраняется в базе данных Redis парами ключ-
значение, а настройки, связанные с пользователями, группами и доменами
- в OpenLDAP . Когда вы настраиваете любые из доступных параметров
через веб-интерфейс, окончательные файлы настройки переписываются
с использованием шаблонов, предоставляемых модулями. Основные
преимущества использования Zentyal это: унификация, графический
интерфейс пользователя для настройки всех сетевых сервисов и высокая
их интеграция между собой «из коробки».
3.1. Установка
Zentyal 2.3 доступен в Ubuntu 12.04 в репозитории Universe. Доступны
следующие модули:
• zentyal-core и zentyal-common: ядро интерфейса Zentyal и общие
библиотеки окружения. Также включают модули журналирования
и событий, которые обеспечивают администратору интерфейс для
просмотра журналов и генерации событий из него.
• zentyal-network: управляет настройкой сети. От интерфейсов
(поддерживая статичные IP, DHCP, VLAN, мосты или PPPoE) до
множественных шлюзов, когда существует более одного соединения
с интернетом, балансировки нагрузки и расширенной маршрутизации,
статической маршрутизации или динамического DNS.
• zentyal-objects и zentyal-services: предоставляют абстрактный уровень
сетевой адресации (например, LAN вместо 192.168.1.0/24) и именования
портов как сервисов (например, HTTP вместо 80/TCP).
101
Удалённое администрирование
• zentyal-firewall: настройка правил iptables для блокирования запрещённых
соединений, сетевой трансляции адресов (NAT) и перенаправления
портов.
• zentyal-ntp: устанавливает сервис NTP, чтобы контролировать время
на сервере и позволять клиентам в сети синхронизовать свои часы с
серверными.
• zentyal-dhcp: настраивает сервер ISC DHCP, поддерживающий диапазоны,
статические выделения и другие расширенные опции, такие как NTP,
WINS, обновления динамического DNS и загрузка через сеть с помощью
PXE.
• zentyal-dns: добавляет DNS-сервер ISC Bind9 на ваш компьютер
для кэширования локальных запросов, работая в качестве
перенаправляющего DNS-сервера (DNS forwarder) или доверенного
сервера (authoritative server) для настроенных доменов. Позволяет
настраивать записи A, CNAME, MX, NS, TXT и SRV.
• zentyal-ca: интегрирует управление центром сертификации в Zentyal
таким образом, что пользователи могут использовать сертификаты для
аутентификации сервисов, подобно OpenVPN.
• zentyal-openvpn: позволяет настроить несколько VPN серверов и
клиентов, использующих OpenVPN с настройкой динамической
маршрутизации с помощью Quagga.
• zentyal-users: предоставляет интерфейс настройки и управления
пользователями и группами в OpenLDAP. Другие сервисы Zentyal
авторизуются по LDAP, имея централизованное управления
пользователями и группами. Это также позволяет синхронизировать
пользователей, пароли и группы из домена Microsoft Active Directory.
• zentyal-squid: настраивает Squid и Dansguardian для ускорения просмотра
благодаря возможностям кэширования и фильтрования контента.
• zentyal-samba: позволяет настраивать Samba и интеграцию с
существующим LDAP. Из этого же интерфейса вы можете задавать
политику паролей, создавать ресурсы общего доступа и устанавливать
права доступа.
• zentyal-printers: интегрирует CUPS с Samba и позволяет не только
настраивать принтеры, но и предоставлять им права доступа на основе
пользователей и групп LDAP.
Для установки Zentyal в терминале на сервере введите следующее (здесь
<zentyal-module
sudo apt-get install <zentyal-module>
102
Удалённое администрирование
Zentyal выпускает по одной стабильной версии в год (в сентябре),
в качестве базового дистрибутива для которой используется
последний выпуск Ubuntu LTS. Стабильные выпуски всегда имеют
чётное значение младшей части версии (например, 2.2, 3.0), а бета-
версии - нечётное (2.1, 2.3). Ubuntu 12.04 поставляется с версией
пакетов Zentyal 2.3. Если вы хотите обновиться до последней
стабильной версии, опубликованной после выпуска Ubuntu 12.04,
используйте Zentyal Team PPA7. Обновление до новейшей стабильной
версии может предоставить вам исправления незначительных
ошибок, которые не будут бэкпортироваться в версию 2.3 для
Precise, а также добавить новые возможности.
Если вам требуется больше информации о том как добавлять пакеты
из PPA, смотрите Добавление персонального архива пакетов (PPA)8.
В Zentyal Team PPA9 вы можете найти следующие модули,
отсутствующие в репозитории Ubuntu Universe:
• zentyal-antivirus: интегрирует антивирус ClamAV с другими
модулями, такими как прокси, общего доступа к файлам и
почтового фильтра.
• zentyal-asterisk: настраивает Asterisk для обеспечения работы
PBX (Private branch exchange, офисная АТС) на основе LDAP-
аутентификации.
• zentyal-bwmonitor: позволяет отслеживать использование
пропускной способности вашей локальной сети.
• zentyal-captiveportal: интегрирует captive portal (механизм
регистрации доступа в интернет) с защитным сервером (firewall), а
также пользователями и группами LDAP.
• zentyal-ebackup: позволяет выполнять резервное копирование
по расписанию, используя популярное средство резервного
копирования duplicity.
• zentyal-ftp: настраивает FTP-сервер на использование
аутентификации по LDAP.
• zentyal-ids: добавляет систему обнаружения сетевых вторжений.
• zentyal-ipsec: позволяет настраивать IPsec туннели с
использованием OpenSwan.
• zentyal-jabber: интегрирует XMPP-сервер ejabberd с пользователями
и группами LDAP.
103
Удалённое администрирование
• zentyal-thinclients: терминальный сервер (LTSP) для "тонких"
клиентов.
• zentyal-mail: полный почтовый стек, включая Postfix и Dovecot с
LDAP.
• zentyal-mailfilter: настраивает amavisd на работу с почтовым
стеком для фильтрации спама и прикрепленных вирусов.
• zentyal-monitor: добавляет collectd для отслеживания
производительности сервера и запущенных сервисов.
• zentyal-pptp: настраивает PPTP VPN сервер.
• zentyal-radius: интегрирует FreeRADIUS с пользователями и
группами LDAP.
• zentyal-software: простой интерфейс для управления
установленными модулями Zentyal и системными обновлениями.
• zentyal-trafficshaping: настраивает правила ограничения трафика
для уменьшения полосы пропускания и уменьшения задержек.
• zentyal-usercorner: разрешает пользователям редактировать их
собственные атрибуты LDAP, используя веб-браузер.
• zentyal-virt: простой интерфейс для создания и управления
виртуальными машинами на базе libvirt.
• zentyal-webmail: позволяет осуществлять доступ к вашей почте,
используя популярный веб-интерфейс Roundcube.
• zentyal-webserver: настраивает интернет сервер Apache для
обслуживания различных сайтов на вашей машине.
• zentyal-zarafa: интегрирует средство групповой работы Zarafa с
почтовым стеком Zentyal и LDAP.
3.2. Первые шаги
Любой системный пользователь, принадлежащий к группе sudo, имеет
возможность войти в веб-интерфейс Zentyal. Если вы используете
пользователя, созданного при установке системы, то он входит в группу
sudo по умолчанию.
Если вам надо добавить другого пользователя к группе sudo, просто
выполните:
sudo adduser username sudo
Для доступа к веб-интерфейсу Zentyal подключитесь к адресу https://
localhost/ (или IP-адресу вашего удалённого сервера). Поскольку Zentyal
104
Удалённое администрирование
создаёт собственный самозаверенный сертификат SSL, вы получите
предупреждение системы безопасности в вашем браузере.
Подключившись, вы увидите панель управления (dashboard) с обзором
всего вашего сервера. Для настройки любого свойства установленного
вами модуля, перейдите к нужной секции в меню слева. Когда вы
делаете изменения, в правом верхнем углу появляется красная кнопка
Save changes, которую надо нажать для сохранения всех изменений
настроек. Для применения этих изменений на сервере, вначале модуль
нужно подключить, что вы можете сделать при выборе Module Status
в меню слева. Каждый раз как вы включаете модуль, будет появляться
всплывающее окно подтверждения о выполнении необходимых действий и
изменений на вашем сервере и в файлах настроек.
Если вам требуется настроить под себя какой-либо файл
конфигурации или выполнить определенные действия (сценарий
или команду) по настройке, не доступной из Zentyal, поместите
шаблон конфигурационного файла в Zentyal и указатели (hooks) в /
etc/zentyal/hooks/<module>.<action>.
3.3. Ссылки
Официальная страница документации Zentyal10
Смотрите также страницу документации сообщества Zentyal 11
И не забудьте посетить форум 12сообщества для поддержки, обратной
связи, запросов на доработку и пр.
10
11
12
105
Глава 7. Сетевая
аутентификация
В этом разделе рассматривается применение LDAP для аутентификации и
авторизации.
106
Сетевая аутентификация
1. Сервер OpenLDAP
Lightweight Directory Access Protocol (LDAP) - это протокол запросов и
изменений к сервису каталогов на базе X.500, работающий поверх TCP/IP.
Текущая версия LDAP - LDAPv3, как определено в RFC45101, а реализация
LDAP в Ubuntu - это OpenLDAP, текущей версии 2.4.25 (Oneiric) (2.4.28 для
Precise - прим. переводчика).
Итак, этот протокол обеспечивает доступ к каталогам LDAP. Здесь
приведены некоторые ключевые понятия и термины:
• Каталог LDAP - это дерево данных в виде записей, иерархичных по своей
природе, которое называется деревом каталогов информации (Directory
Information Tree, или DIT).
• Запись состоит из набора атрибутов.
• Атрибут имеет тип (имя/описание) и одно или несколько значений.
• Каждый атрибут должен быть определён как минимум в одном
объектном классе (objectClass).
• Атрибуты и объектные классы определяются в схемах (объектный класс
фактически рассматривается как специальный вид атрибута).
• Каждая запись имеет уникальный идентификатор - отличительное
имя (Distinguished Name, или DN). Оно состоит из относительного
отличительного имени (RDN), за которым следует запись родительского
DN.
• DN записи - это не атрибут. Оно не является частью собственно записи.
Термины объект, контейнер, and узел (node) имеют определенный
подтекст, но они все по существу обозначают такую вещь, как
запись, технически корректный термин.
Например, далее мы имеем одну запись, содержащую 11 атрибутов. Её DN
- это "cn=John Doe,dc=example,dc=com"; её RDN - это "cn=John Doe"; а
родительский DN - "dc=example,dc=com".
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Larry Smith,dc=example,dc=com
107
Сетевая аутентификация
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
Вышепривёденная запись - это формат LDIF (LDAP Data Interchange Format,
то есть формат обмена данными LDAP). Любая информация, которую вы
помещаете в ваш DIT, должна быть в таком формате. Это определено в
RFC28492.
Хотя данное руководство описывает, как использовать его для
централизованной идентификации, LDAP хорош для всего, что затрагивает
большое количество запросов к системе, основанной на атрибутах
(имя:значение) и ориентированной преимущественно на чтение. В качестве
примеров можно привести адресную книгу, список адресов электронной
почты и конфигурацию почтового сервера.
1.1. Установка
Установите демон сервера OpenLDAP и традиционные утилиты управления
LDAP. Они находятся в пакетах slapd и ldap-utils, соответственно.
Установка slapd создаст работающую конфигурацию. В частности, она
создаст экземпляр базы данных, которую вы можете использовать
для хранения своих данных. Однако суффикс (или базовый DN) этого
экземпляра будет определён из доменного имени localhost. Если вы
хотите использовать что-то другое, отредактируйте /etc/hosts и замените
доменное имя на подходящее. Например, если вам нужен суффикс
dc=example,dc=com, то ваш файл должен иметь подобную строку:
127.0.1.1
hostname.example.com hostname
Вы можете отменить изменения после установки пакета.
Это руководство будет использовать суффикс базы данных
dc=example,dc=com.
Приступаем к установке:
sudo apt-get install slapd ldap-utils
Начиная с Ubuntu 8.10 slapd проектируется так, чтобы настраиваться
самостоятельно, выделяя отдельный DIT для этой цели. Это позволяет
108
Сетевая аутентификация
динамически настраивать slapd без необходимости перезапускать сервис.
Эта конфигурационная база данных состоит из набора текстовых LDIF-
файлов, расположенных в /etc/ldap/slapd.d. Этот вариант работы известен
под разными названиями: метод slapd-config, RTC-метод (от Real Time
Configuration - настройка в реальном времени) или метод cn=config.
Вы всё ещё можете использовать традиционный метод плоского файла
(slapd.conf), но это не рекомендуется; данная функциональность в
конечном счете будет убрана.
В настоящее время Ubuntu использует метод slapd-config для
настройки slapd, и данное руководство это отражает.
Во время установки вам будет предложено указать учётные
данные администратора. Это LDAP-данные для rootDN вашего
экземпляра базы данных. По умолчанию DN этого пользователя:
cn=admin,dc=example,dc=com. Также по умолчанию не создается
административного пользователя для базы данных slapd-config
и вы, следовательно, будете вынуждены использовать внешнюю
аутентификацию LDAP для доступа к ней. Мы рассмотрим, как это
делается, позднее.
Некоторые классические схемы (cosine, nis, inetorgperson) выпускаются
теперь для slapd. Это также включает базовую (core) схему, которая
предполагается для любой рабочей схемы.
1.2. Проверка после установки
Процесс установки создаст два DIT. Один для slapd-config и один для ваших
данных (dc=example,dc=com). Давайте взглянем:
• Здесь показано, как выглядит дерево (DIT) базы данных slapd-config.
Напомним, что эта база основана на LDIF и находится в /etc/ldap/slapd.d:
/etc/ldap/slapd.d/
├── cn=config
│
├── cn=module{0}.ldif
│
├── cn=schema
│
│
├── cn={0}core.ldif
│
│
├── cn={1}cosine.ldif
│
│
├── cn={2}nis.ldif
│
│
└── cn={3}inetorgperson.ldif
│
├── cn=schema.ldif
│
├── olcBackend={0}hdb.ldif
│
├── olcDatabase={0}config.ldif
│
├── olcDatabase={-1}frontend.ldif
109
Сетевая аутентификация
│
└── olcDatabase={1}hdb.ldif
└── cn=config.ldif
Не редактируйте базу slapd-config напрямую. Вносите изменения
через протокол LDAP (утилитами).
• Здесь показано, как выглядит дерево slapd-config через LDAP протокол:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config
Пояснения к записям:
• cn=config: глобальные настройки
• cn=module{0},cn=config: динамически загружаемый модуль
• cn=schema,cn=config: содержит жёстко запрограммированную схему
системного уровня
• cn={0}core,cn=schema,cn=config: жёстко запрограммированная базовая
(core) схема
• cn={1}cosine,cn=schema,cn=config: схема cosine
• cn={2}nis,cn=schema,cn=config: схема nis
• cn={3}inetorgperson,cn=schema,cn=config: схема inetorgperson
• olcBackend={0}hdb,cn=config: тип хранилища 'hdb' заднего плана
• olcDatabase={-1}frontend,cn=config: база переднего плана, настройка
по умолчанию для других баз данных
110
Сетевая аутентификация
• olcDatabase={0}config,cn=config: конфигурационная база slapd
(cn=config)
• olcDatabase={1}hdb,cn=config: экземпляр вашей базы данных
(dc=examle,dc=com)
• А здесь показано как выглядит дерево dc=example,dc=com:
ldapsearch -x -LLL -H ldap:/// -b dc=example,dc=com dn
dn: dc=example,dc=com
dn: cn=admin,dc=example,dc=com
Пояснения к записям:
• dc=example,dc=com: базовый уровень вашего дерева (DIT)
• cn=admin,dc=example,dc=com: администратор (rootDN) данного дерева
(заполняется в процессе установки пакета)
1.3. Изменение/заполнение вашей базы данных
Давайте введём некоторые данные в нашу базу. Мы добавим следующее:
• узел (node) с названием People (для хранения пользователей)
• узел с названием Groups (для хранения групп)
• группу с названием miners
• пользователя с именем john
Создайте следующий LDIF файл и назовите его add_content.ldif:
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups
dn: cn=miners,ou=Groups,dc=example,dc=com
objectClass: posixGroup
cn: miners
gidNumber: 5000
dn: uid=john,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
111
Сетевая аутентификация
uid: john
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 10000
gidNumber: 5000
userPassword: johnldap
gecos: John Doe
loginShell: /bin/bash
homeDirectory: /home/john
Важно, чтобы значения uid и gid в вашем каталоге не совпадали
с локальными значениями. Используйте диапазон больших чисел,
начинающийся, например, с 5000. Установка больших значений uid
и gid для ldap также позволяет упростить контроль за тем что могут
делать локальные пользователи, а что ldap. Подробнее об этом
смотрите далее.
Добавляем данные:
ldapadd -x -D cn=admin,dc=example,dc=com -W -f add_content.ldif
Enter LDAP Password: ********
adding new entry "ou=People,dc=example,dc=com"
adding new entry "ou=Groups,dc=example,dc=com"
adding new entry "cn=miners,ou=Groups,dc=example,dc=com"
adding new entry "uid=john,ou=People,dc=example,dc=com"
Мы можем проверить что информация добавлена правильно с помощью
утилиты ldapsearch:
ldapsearch -x -LLL -b dc=example,dc=com 'uid=john' cn gidNumber
dn: uid=john,ou=People,dc=example,dc=com
cn: John Doe
gidNumber: 5000
Объяснения ключей команды:
• -x: "простое" связывание; не будет использоваться метод SASL по
умолчанию
• -LLL: отключить вывод посторонней информации
• uid=john: - «фильтр» для поиска пользователя john
112
Сетевая аутентификация
• cn gidNumber: запрос на вывод определенных атрибутов (по умолчанию
выводятся все атрибуты)
1.4. Изменение базы данных настройки slapd
Дерево (DIT) slapd-config также может запрашиваться и изменяться. Здесь
приведено несколько примеров.
• Используйте ldapmodifyдля добавления индекса (атрибут DbIndex) для
вашей {1}hdb,cn=config базы (dc=example,dc=com). Создайте файл с
названием uid_index.ldif следующего содержания:
dn: olcDatabase={1}hdb,cn=config
add: olcDbIndex
olcDbIndex: uid eq,pres,sub
Затем выполните команду:
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f uid_index.ldif
modifying entry "olcDatabase={1}hdb,cn=config"
Вы можете подтвердить изменения следующим способом:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}hdb)' olcDbIndex
dn: olcDatabase={1}hdb,cn=config
olcDbIndex: objectClass eq
olcDbIndex: uid eq,pres,sub
• Давайте добавим схему. Сначала её нужно преобразовать в формат
LDIF. Вы можете найти не преобразованные схемы в добавление к
преобразованным в каталоге /etc/ldap/schema.
• Удаление схемы из базы slapd-config - нетривиальная задача.
Потренируйтесь добавлять схемы на тестовой системе.
• Перед добавлением любой схемы вам следует проверить, какие
схемы уже установлены (показан вывод по умолчанию, для
состояния "из коробки"):
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=schema,cn=config dn
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
113
Сетевая аутентификация
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
В следующем примере мы добавим схему CORBA.
1. Создайте конфигурационный файл преобразования schema_convert.conf,
содержащий следующие строки:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/ldapns.schema
include /etc/ldap/schema/pmi.schema
2. Создайте выходной каталог ldif_output.
3. Определите индекс схемы:
slapcat -f schema_convert.conf -F ldif_output -n 0 | grep corba,cn=schema
cn={1}corba,cn=schema,cn=config
Когда slapd вводит объекты с тем же родительским DN,
он создает индекс для этого объекта. Индекс обрамляется
скобками: {X}.
4. Используйте slapcat для выполнения преобразования:
slapcat -f schema_convert.conf -F ldif_output -n0 -H \ ldap:///cn={1}corba,cn=schema,cn=confi
Сконвертированная (преобразованная) схема теперь в cn=corba.ldif
5. Редактируйте cn=corba.ldif по достижении следующих атрибутов:
dn: cn=corba,cn=schema,cn=config
114
Сетевая аутентификация
cn: corba
Также удалите следующие строки в конце:
structuralObjectClass: olcSchemaConfig
entryUUID: 52109a02-66ab-1030-8be2-bbf166230478
creatorsName: cn=config
createTimestamp: 20110829165435Z
entryCSN: 20110829165435.935248Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20110829165435Z
Значения ваших атрибутов могут быть другими.
6.
Наконец, используйте ldapadd для добавления новой схемы к дереву
slapd-config:
sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f cn\=corba.ldif
adding new entry "cn=corba,cn=schema,cn=config"
7.
Проверьте текущую загруженную схему:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}corba,cn=schema,cn=config
Для аутентификации с помощью LDAP внешних приложений и
клиентов, они должны быть специфически настроены. Обратитесь к
соответствующей документации по поводу деталей.
1.5. Ведение журнала
Ведение журнала активности для slapd обязательно, когда осуществляется
решение на базе OpenLDAP, поэтому его требуется включить вручную после
установки приложения. Иначе только элементарные сообщения будут
115
Сетевая аутентификация
доступны в журналах. Ведение журналов, как и другие настройки slapd,
подключаются через базу данных slapd-config.
OpenLDAP поставляется с несколькими подсистемами (уровнями)
журналирования, каждая из которых включает подчиненную
(дополнительную). Хороший вариант, который стоит попробовать - это
stats. Страница slapd-config3 содержит больше информации по иным
подсистемам.
Создайте файл logging.ldif со следующим содержимым:
dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: stats
Производим изменения:
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif
Это породит значительный объем записи в журнал и вы захотите
уменьшить уровень детализации когда ваша система станет боевой.
С таким уровнем детализации система журналирования вашего хоста
(rsyslog) может отнимать значительное время процессора, а также
пропускать сообщения:
rsyslogd-2177: imuxsock lost 228 messages from pid 2547 due to rate-limiting
Вы можете решить изменить настройки rsyslog. В файл /etc/rsyslog.conf
поместите следующее:
# Disable rate limiting
# (default is 200 messages in 5 seconds; below we make the 5 become 0)
$SystemLogRateLimitInterval 0
А затем перезапустите демон rsyslog:
sudo service rsyslog restart
1.6. Репликация
Сервис LDAP становится всё более и более важным, поскольку большинство
сетевых систем начинают зависеть от него. В этом контексте стандартной
116
Сетевая аутентификация
практикой является встраивание избыточности (высокой доступности) в
LDAP для защиты от опустошения, которое сделает сервер неработающим.
Это достигается с помощью репликации LDAP.
Репликация доступна через механизм Syncrepl. Он позволят
синхронизировать изменения используя модель Потребитель - Поставщик.
Специфический вид репликации, который мы будем реализовывать в этом
руководстве, является комбинацией следующих режимов: refreshAndPersist
и delta-syncrepl. Это подразумевает что Потребитель передает измененные
записи Поставщику, как только они появляются, но при этом посылаются
только актуальные изменения, а не все записи.
1.6.1. Настройка Поставщика
Начнем с настройки Поставщика.
1. Создайте файл LDIF со следующим содержимым и назовите его
provider_sync.ldif:
# Add indexes to the frontend db.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq
#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
-
add: olcModuleLoad
olcModuleLoad: accesslog
# Accesslog database definitions
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=example,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
# Accesslog db syncprov.
117
Сетевая аутентификация
dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
# accesslog overlay definitions for primary db
dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
olcAccessLogPurge: 07+00:00 01+00:00
Замените rootDN в LDIF файле на соответствующий вашему каталогу.
2.
Профиль apparmor для slapd нужно будет отрегулировать для
расположения базы accesslog. Отредактируйте /etc/apparmor.d/local/
usr.sbin.slapd, добавив следующее:
/var/lib/ldap/accesslog/ r,
/var/lib/ldap/accesslog/** rwk,
Создаём каталог, устанавливаем файл настроек базы данных и
перезагружаем профиль apparmor:
sudo -u openldap mkdir /var/lib/ldap/accesslog
sudo -u openldap cp /var/lib/ldap/DB_CONFIG /var/lib/ldap/accesslog
sudo service apparmor reload
3.
Добавляем новый контент и, поскольку изменили apparmor,
перезапускаем сервис:
sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif
sudo service slapd restart
Теперь поставщик настроен.
118
Сетевая аутентификация
1.6.2. Настройка Потребителя
А теперь настроим Потребителя.
1.
Установим программное обеспечение как указано в Раздел 1.1,
«Установка» [108]. Убедитесь, что база slapd-config аналогична базе
Поставщика. Особенно проверьте, что одинаковы схемы и суффикс
базы.
2.
Создайте файл LDIF со следующим содержимым и назовите его
consumer_sync.ldif:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=admin,dc=exa
credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on
type=refreshAndPersist retry="60 +" syncdata=accesslog
-
add: olcUpdateRef
olcUpdateRef: ldap://ldap01.example.com
Убедитесь, что следующие атрибуты имеют правильные значения:
• provider (hostname сервера Поставщика - в этом примере - или IP-
адрес)
• binddn (DN администратора, которым вы пользуетесь)
• credentials (пароль для DN администратора, который вы используете)
• searchbase (суффикс базы, которую вы используете)
• olcUpdateRef (hostname сервера Поставщика или его IP адрес)
• rid (Replica ID, уникальное трёхзначное число, идентифицирующее
данную копию. Каждый Потребитель должен иметь минимум один rid)
3.
Добавьте новое содержимое:
sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f consumer_sync.ldif
Вы сделали это! Две базы (суффикс: dc=example,dc=com) будут теперь
синхронизированы.
119
Сетевая аутентификация
1.6.3. Тестирование
Как только репликация стартует, вы можете отслеживать ее запустив:
ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base contextCSN
dn: dc=example,dc=com
contextCSN: 20120201193408.178454Z#000000#000#000000
как на Поставщике, так и на Потребителе. Как только вывод
(20120201193408.178454Z#000000#000#000000в примере выше) на обеих машинах
совпадет, вы провели репликацию. Каждый раз, как происходят изменения
на Поставщике, это значение будет изменяться и должно стать таким же
на Поставщике.
Если ваше соединение медленное и/или ваша база LDAP велика, процесс
приведения в соответствие contextCSN Потребителя и Поставщика может
быть протяженным. Но, вы должны знать, что процесс запускается как
только contextCSN Потребителя неизбежно увеличивается.
Если contextCSN Потребителя отсутствует или не совпадает со значением
Поставщика, вы должны остановиться и понять причину проблемы перед
тем как продолжить. Попробуйте проверить slapd (syslog - системный
журнал) и файлы журналов аутентификации Поставщика, чтобы увидеть
удачны ли были запросы аутентификации Потребителя и не возвращались
ли ошибки в ответ на запросы данных (они будут видны как множество
записей ldapsearch).
Чтобы проверить, что всё работает, просто запросите на Потребителе DN из
базы:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com dn
Вы должны увидеть пользователя 'john' и группу 'miners', также как ноды
'People' и 'Groups'.
1.7. Управление доступом
Управление тем, какой тип доступа пользователей (чтение, запись и пр.)
должен быть предоставлен к ресурсам, известно как контроль доступа.
Используемые для этого директивы называются списками контроля
доступа (access control lists, или ACL).
Когда мы устанавливали пакет slapd, различные ACL были установлены
автоматически. Мы рассмотрим некоторые важные следствия этих
120
Сетевая аутентификация
умолчаний и, занимаясь этим, мы поймём идею того, как работают ACL и
как их настраивать.
Для получения эффективных ACL для запроса LDAP нам надо посмотреть
на ACL записи запрашиваемой базы данных также как и на записи
специального экземпляра базы данных переднего плана. По умолчанию
используются ACL, полученные последним действием, в случае, если они не
совпадают с правилами из предыдущего варианта. База данных переднего
плана опрашивается во вторую очередь и применяется ACL по первому
совпадению среди этих двух источников ACL. Следующие команды покажут
соответственно ACL базы hdb ("dc=example,dc=com") и они же из базы
переднего плана:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}hdb)' olcAccess
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous
auth by dn="cn=admin,dc=example,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by *
read
rootDN всегда имеет полный доступ к своей базе данных.
Добавление их к ACL обеспечивает полную конфигурацию, но при
этом становится причиной снижения быстродействия slapd.
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAcc
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,
cn=external,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
Самый первый ACL очень важен:
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous
auth by dn="cn=admin,dc=example,dc=com" write by * none
Это может быть представлено по-другому для лучшего понимания:
to attrs=userPassword
by self write
by anonymous auth
by dn="cn=admin,dc=example,dc=com" write
121
Сетевая аутентификация
by * none
to attrs=shadowLastChange
by self write
by anonymous auth
by dn="cn=admin,dc=example,dc=com" write
by * none
Этот составной ACL (их два) предписывает следующее:
• Анонимный 'auth' доступ обеспечивается к атрибуту userPassword для
осуществления изначального соединения. Возможно потребуется counter-
intuitively для 'by anonymous auth' даже когда анонимный доступ к DIT
не требуется. Как только удаленное соединение установлено, требуется
аутентификация (см. следующий пункт).
• Должна пройти аутентификация, поскольку все пользователи имеют
доступ на чтение (вследствие 'by self write') к атрибуту userPassword.
• Атрибут userPassword не доступен для всех других пользователей за
исключением rootDN, который имеет полный доступ.
• Для того чтобы пользователи могли менять собственные пароли,
используя passwd или иные утилиты, атрибут shadowLastChange должен
быть доступен как только пользователь авторизовался.
Поиск по этому DIT может быть проведен анонимно из-за 'by * read' в
данном ACL:
to *
by self write
by dn="cn=admin,dc=example,dc=com" write
by * read
Если это нежелательно, то вам потребуется изменить набор ACL. Для
принуждения к аутентификации в процессе связывающего (bind) запроса
в качестве альтернативы (или в комбинации с измененным ACL) вам надо
использовать директиву 'olcRequire: authc'.
Как указывалось ранее, для базы slapd-config не создаётся никаких
административных пользователей. Однако существует идентификация
SASL, которая обеспечивает полный доступ к ней. Она подобна
суперпользователю для localhost (root/sudo). Вот она:
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
Следующая команда покажет ACL базы slapd-config:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess
122
Сетевая аутентификация
dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,
cn=external,cn=auth manage by * break
Поскольку это SASL идентификация, нам потребуется механизм SASL, когда
запрашивается LDAP утилита, о которой идет речь и мы увидим это много
раз в данном руководстве. Это внешний (EXTERNAL) механизм. Смотрите
предыдущую команду в качестве примера. Обратите внимание:
1. Вы должны использовать sudo для идентификации как root, чтобы ACL
сработали.
2. Механизм EXTERNAL работает через IPC (доменные сокеты UNIX). Это
означает, что вы должны использовать ldapi формат адресации (URI).
Короткий путь для получения всех ACL выглядит следующим образом:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffix
Есть ещё много что сказать по контролю доступа. Смотрите страницу
руководства по slapd.access4.
1.8. TLS
Когда происходит аутентификация на OpenLDAP сервере, лучше всего это
делать, используя зашифрованную сессию. Это может быть достигнуто
использованием транспортного уровня шифрования (TLS).
Здесь мы организуем свой собственный Центр сертификации (Certificate
Authority - CA) и затем создадим и подпишем сертификат нашего
LDAP сервера от имени этого CA. Поскольку slapd скомпилирован с
использованием библиотеки gnutls, мы будем использовать для выполнения
этих задач утилиту certtool.
1. Установите пакеты gnutls-bin и ssl-cert:
sudo apt-get install gnutls-bin ssl-cert
2. Создайте секретный ключ для центра сертификации
sudo sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"
3. Создаём временный файл /etc/ssl/ca.info для определения CA:
cn = Example Company
123
Сетевая аутентификация
ca
cert_signing_key
4.
Создаём самоподписанный сертификат центра:
sudo certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /
5.
Создайте секретный ключ для сервера:
sudo certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/ldap01_slapd_key.pe
Замените ldap01 в имени файла на имя вашего сервера
(hostname). Имена сертификата и ключа для узла и сервиса,
которые будут их использовать, помогут сохранять ясность
понимания.
6.
Создайте файл /etc/ssl/ldap01.info, содержащий:
organization = Example Company
cn = ldap01.example.com
tls_www_server
encryption_key
signing_key
expiration_days = 3650
Данный сертификат будет действителен 10 лет. Вы можете выбрать
другое значение.
7.
Создайте сертификат для сервера:
sudo certtool --generate-certificate \ --load-privkey /etc/ssl/private/ldap01_slapd_key.pem \ -
Создайте файл certinfo.ldif со следующим содержимым (подставляйте свои
значения, наш пример предполагает использование https://www.cacert.org):
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem
Используйте команду ldapmodify, чтобы сообщить slapd о работе нашего
TLS через базу данных slapd-config:
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif
124
Сетевая аутентификация
Вопреки распространённому мнению, вам не обязательно указывать
ldaps:// в /etc/default/slapd чтобы использовать шифрование. Вам достаточно
указать:
SLAPD_SERVICES="ldap:/// ldapi:///"
LDAP поверх TLS/SSL (ldaps://) осуждается в пользу StartTLS.
Последний опирается на существующую LDAP сессию
(прослушивание TCP порта 389), защищённую TLS/SSL в то время
как LDAPS, подобно HTTPS, является другим защищённым-с-самого-
начала протоколом, который работает через TCP порт 636.
Сужаем права на владение и доступ:
sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod o-r /etc/ssl/private/ldap01_slapd_key.pem
Перезапустите OpenLDAP:
sudo service slapd restart
Проверьте журналы вашего хоста (/var/log/syslog), чтобы убедиться, что
сервер запущен правильно.
1.9. Репликация и TLS
Если вы настроили репликацию между серверами, существует
общая практика шифровать (StartTLS) трафик репликации для
исключения прослушивания. Лучше всего использовать шифрование
с аутентификацией, как мы делали выше. В этом разделе мы будем
основываться на проделанной работе по TLS-аутентификации.
Здесь предполагается, что вы настроили репликацию между Поставщиком
и Провайдером в соответствии с Раздел 1.6, «Репликация» [116] и
настроили TLS для аутентификации на Поставщике, следуя инструкциям
Раздел 1.8, «TLS» [123].
Как утверждалось ранее, цель (для нас) репликации - это высокая
доступность сервиса LDAP. Поскольку мы имеем TLS для аутентификации на
Поставщике, мы нуждаемся в этом и на Потребителе. Однако в дополнение
к этому мы хотим зашифровать трафик репликации. Что остается сделать,
так это создать ключ и сертификат для Потребителя и затем провести
соответствующую настройку. Мы создадим ключ и сертификат на
125
Сетевая аутентификация
Поставщике для предотвращения создания другого Центра сертификатов,
а затем перенесем необходимые данные на Потребителя.
1.
На Поставщике:
Создаём промежуточный каталог (который будет использоваться для
переноса) и затем секретный ключ Потребителя:
mkdir ldap02-ssl
cd ldap02-ssl
sudo certtool --generate-privkey \ --bits 1024 \ --outfile ldap02_slapd_key.pem
Создаём информационный файл ldap02.info для сервера Потребителя;
подставляйте свои соответствующие значения:
organization = Example Company
cn = ldap02.example.com
tls_www_server
encryption_key
signing_key
expiration_days = 3650
Создаём сертификат Потребителя:
sudo certtool --generate-certificate \ --load-privkey ldap02_slapd_key.pem \ --load-ca-certific
Получаем копию сертификата CA:
cp /etc/ssl/certs/cacert.pem .
Всё готово. Теперь переносим каталог ldap02-ssl на сервер Потребителя.
Здесь мы использовали scp (данные изменяем соответственно):
cd ..
scp -r ldap02-ssl user@consumer:
2.
На Потребителе:
Настраиваем TLS-аутентификацию:
sudo apt-get install ssl-cert
sudo adduser openldap ssl-cert
sudo cp ldap02_slapd_cert.pem cacert.pem /etc/ssl/certs
sudo cp ldap02_slapd_key.pem /etc/ssl/private
sudo chgrp ssl-cert /etc/ssl/private/ldap02_slapd_key.pem
sudo chmod g+r /etc/ssl/private/ldap02_slapd_key.pem
sudo chmod o-r /etc/ssl/private/ldap02_slapd_key.pem
126
Сетевая аутентификация
Создаём файл /etc/ssl/certinfo.ldif со следующим содержимым
(исправляйте соответственно):
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap02_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap02_slapd_key.pem
Настраиваем базу slapd-config:
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
Настраиваем /etc/default/slapd как на Поставщике (SLAPD_SERVICES).
3. На Потребителе:
Настраиваем TLS для репликации на стороне Потребителя. Изменяем
существующий атрибут olcSyncrepl присоединяя некоторые TLS опции.
Делая это, мы увидим в первый раз как изменять значения атрибутов.
Создайте файл consumer_sync_tls.ldif со следующим содержимым:
dn: olcDatabase={1}hdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://ldap01.example.com bindmethod=simple
binddn="cn=admin,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com"
logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog
starttls=critical tls_reqcert=demand
Дополнительные опции определяют, соответственно, что Потребитель
должен использовать StartTLS и что CA сертификат требуется для
идентификации Поставщика. Также обратите внимание на LDIF
синтаксис для изменения значений атрибута ('replace').
Применяем эти изменения:
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_sync_tls.ldif
И перезапустите slapd:
127
Сетевая аутентификация
sudo service slapd restart
4. На Поставщике:
Проверяем, что TLS сессия устанавливается. В /var/log/syslog,
предполагая что вы настроили уровень журналирования 'conns', вы
сможете увидеть подобные записи:
slapd[3620]: conn=1047 fd=20 ACCEPT from IP=10.153.107.229:57922 (IP=0.0.0.0:389)
slapd[3620]: conn=1047 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[3620]: conn=1047 op=0 STARTTLS
slapd[3620]: conn=1047 op=0 RESULT oid= err=0 text=
slapd[3620]: conn=1047 fd=20 TLS established tls_ssf=128 ssf=128
slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128
slapd[3620]: conn=1047 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
slapd[3620]: conn=1047 op=1 RESULT tag=97 err=0 text
1.10. Установление подлинности через LDAP
Поскольку вы имеете работающий LDAP сервер, вам потребуется
установить библиотеки на клиенте, которые будут знать, как и когда к
нему (серверу) подсоединяться. На Ubuntu это традиционно производится
установкой пакета libnss-ldap Этот пакет добавит другие инструменты,
которые будут помогать вам на шаге настройки. Теперь установим этот
пакет:
sudo apt-get install libnss-ldap
У вас будут запрошены подробности по вашему LDAP серверу. Если вы
сделаете ошибку, вы можете попробовать снова, используя:
sudo dpkg-reconfigure ldap-auth-config
Результат диалога можно увидеть в /etc/ldap.conf. Если ваш сервер требует
опции, недоступные в меню, редактируйте этот файл самостоятельно.
Теперь настраиваем LDAP профиль для NSS:
sudo auth-client-config -t nss -p lac_ldap
Настраиваем систему на использование LDAP для аутентификации:
sudo pam-auth-update
Из меню, выберите LDAP и любые другие механизмы аутентификации,
которые вам требуются.
128
Сетевая аутентификация
Теперь вы имеете возможность входить в систему, используя учётные
записи на основе LDAP.
Клиентам LDAP потребуются ссылки на несколько серверов, если
используется репликация. В /etc/ldap.conf вам надо иметь что-то похожее:
uri ldap://ldap01.example.com ldap://ldap02.example.com
Запросы имеют таймаут и будет попытка обратиться к Потребителю
(ldap02), если Поставщик (ldap01) станет недоступным.
Если вы собираетесь использовать LDAP для хранения пользователей
SAMBA, вам потребуется настроить SAMBA сервер на использование LDAP.
Смотрите Раздел 2, «Samba и LDAP» [135] для подробностей.
Альтернативой пакету libnss-ldap является пакет libnss-ldapd. Однако
он добавит в систему пакет nscd, который, возможно, нежелателен.
Просто впоследствии удалите его.
1.11. Управление пользователями и группами
Пакет ldap-utils поставляется с достаточным количеством утилит для
управления каталогами, но необходимость использовать длинные строки
с опциями делает их применение обременительным. Пакет ldapscripts
содержит обёрточные сценарии (wrapper scripts) для этих утилит, которые
некоторые находят более удобными в использовании.
Установите пакет:
sudo apt-get install ldapscripts
Затем отредактируйте файл /etc/ldapscripts/ldapscripts.conf, чтобы получить
что-то наподобие следующего:
SERVER=localhost
BINDDN='cn=admin,dc=example,dc=com'
BINDPWDFILE="/etc/ldapscripts/ldapscripts.passwd"
SUFFIX='dc=example,dc=com'
GSUFFIX='ou=Groups'
USUFFIX='ou=People'
MSUFFIX='ou=Computers'
GIDSTART=10000
UIDSTART=10000
MIDSTART=10000
Затем редактируем файл ldapscripts.passwd для получения нечто похожего
на следующее:
129
Сетевая аутентификация
sudo sh -c "echo -n 'secret' > /etc/ldapscripts/ldapscripts.passwd"
sudo chmod 400 /etc/ldapscripts/ldapscripts.passwd
Замените «secret» на действующий пароль для пользователя rootDN
вашей базы.
Теперь этот сценарий готов помочь вам в управлении вашим каталогом.
Вот несколько примеров его использования:
• Создание нового пользователя:
sudo ldapadduser george example
Это создаст пользователя с uid george и установит gid example в качестве
первичной пользовательской группы.
• Изменение пароля пользователя:
sudo ldapsetpasswd george
Changing password for user uid=george,ou=People,dc=example,dc=com
New Password:
New Password (verify):
• Удаление пользователя:
sudo ldapdeleteuser george
• Добавление группы:
sudo ldapaddgroup qa
• Удаление группы:
sudo ldapdeletegroup qa
• Добавление пользователя в группу:
sudo ldapaddusertogroup george qa
Вы теперь можете увидеть атрибут memberUid для группы qa со
значением для george.
• Удаление пользователя из группы:
sudo ldapdeleteuserfromgroup george qa
Атрибут memberUid теперь будет удален из группы qa.
130
Сетевая аутентификация
• Сценарий ldapmodifyuser позволяет добавлять, удалять или заменять
пользовательские атрибуты. Сценарий использует тот же синтаксис, что
и утилита ldapmodify. Например:
sudo ldapmodifyuser george
# About to modify the following entry :
dn: uid=george,ou=People,dc=example,dc=com
objectClass: account
objectClass: posixAccount
cn: george
uid: george
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/george
loginShell: /bin/bash
gecos: george
description: User account
userPassword:: e1NTSEF9eXFsTFcyWlhwWkF1eGUybVdFWHZKRzJVMjFTSG9vcHk=
# Enter your modifications here, end with CTRL-D.
dn: uid=george,ou=People,dc=example,dc=com
replace: gecos
gecos: George Carlin
Поле имени пользователя gecos теперь «George Carlin».
• Приятной особенностью ldapscripts является система шаблонов.
Шаблоны позволяют вам настраивать атрибуты пользователей, групп
и компьютерных объектов. Например, чтобы разрешить шаблон
пользователей, отредактируйте /etc/ldapscripts/ldapscripts.conf, изменив:
UTEMPLATE="/etc/ldapscripts/ldapadduser.template"
В каталоге /etc/ldapscripts имеются образцы шаблонов. Скопируйте
или переименуйте файл ldapadduser.template.sample в /etc/ldapscripts/
ldapadduser.template:
sudo cp /usr/share/doc/ldapscripts/examples/ldapadduser.template.sample \ /etc/ldapscripts/ldapad
Отредактируйте новый шаблон для добавления желаемых атрибутов.
Следующее создаст новых пользователей с объектным классом
inetOrgPerson:
dn: uid=<user>,<usuffix>,<suffix>
objectClass: inetOrgPerson
objectClass: posixAccount
cn: <user>
sn: <ask>
131
Сетевая аутентификация
uid: <user>
uidNumber: <uid>
gidNumber: <gid>
homeDirectory: <home>
loginShell: <shell>
gecos: <user>
description: User account
title: Employee
Обратите внимание на опцию <ask>, использованную для атрибута sn.
Это заставит ldapadduser запросить у вас его значение.
В пакете имеются утилиты, которые не были рассмотрены здесь. Вот
полный список:
ldaprenamemachine5
ldapadduser6
ldapdeleteuserfromgroup7
ldapfinger8
ldapid9
ldapgid10
ldapmodifyuser11
ldaprenameuser12
lsldap13
ldapaddusertogroup14
ldapsetpasswd15
ldapinit16
ldapaddgroup17
ldapdeletegroup18
ldapmodifygroup19
ldapdeletemachine20
ldaprenamegroup21
ldapaddmachine22
10
11
12
13
14
15
16
17
18
19
20
21
22
132
Сетевая аутентификация
ldapmodifymachine23
ldapsetprimarygroup24
ldapdeleteuser25
1.12. Резервное копирование и восстановление
Есть утилиты из пакета, которые здесь не рассматривались. Вот их полный
список:
Что нам требуется, это способ сделать резервные копии для базы данных
ldap, специфичные для данных баз заднего (cn=config) и переднего плана
(dc=example,dc=com). Если мы собираемся сохранить эти базы, скажем, в
/export/backup, мы можем использовать slapcat как показано в следующем
сценарии с именем /usr/local/bin/ldapbackup:
#!/bin/bash
BACKUP_PATH=/export/backup
SLAPCAT=/usr/sbin/slapcat
nice ${SLAPCAT} -n 0 > ${BACKUP_PATH}/config.ldif
nice ${SLAPCAT} -n 1 > ${BACKUP_PATH}/example.com.ldif
nice ${SLAPCAT} -n 2 > ${BACKUP_PATH}/access.ldif
chmod 640 ${BACKUP_PATH}/*.ldif
Это несжатые текстовые файлы, содержащие все данные из вашей
ldap базы, включая расположение дерева, имена пользователей и
каждый пароль. Поэтому вы можете решить сделать /export/backup
шифрованным разделом и даже иметь сценарии шифрования этих
файлов сразу после создания. В идеале вы можете сделать и то и
другое, но это зависит от ваших требований безопасности.
Затем имеет смысл создать сценарии cron для запуска этой программы
настолько часто, насколько вам будет комфортно. Для большинства
достаточно одного раза в день. Для некоторых требуется чаще. Здесь
пример сценария cron, названного /etc/cron.d/ldapbackup, который
срабатывает каждую ночь в 22:45:
MAILTO=backup-emails@domain.com
45 22 * * * root
/usr/local/bin/ldapbackup
Теперь файлы созданы и они могут быть скопированы на резервный сервер.
23
24
25
133
Сетевая аутентификация
Предположим мы сделали переустановку ldap; процесс восстановления
будет подобен следующему: sudo service slapd stop
sudo service slapd stop
sudo mkdir /var/lib/ldap/accesslog
sudo slapadd -F /etc/ldap/slapd.d -n 0 -l /export/backup/config.ldif
sudo slapadd -F /etc/ldap/slapd.d -n 1 -l /export/backup/domain.com.ldif
sudo slapadd -F /etc/ldap/slapd.d -n 2 -l /export/backup/access.ldif
sudo chown -R openldap:openldap /etc/ldap/slapd.d/
sudo chown -R openldap:openldap /var/lib/ldap/
sudo service slapd start
1.13. Ресурсы
• Основной ресурс - это документация из апстрима: www.openldap.org26
• Существует много страниц руководств пакета slapd. Здесь наиболее
важные, особенно в плане рассматриваемых в этом руководстве
материалов:
slapd27
slapd-config28
slapd.access29
slapo-syncprov30
• Другие man-страницы:
auth-client-config31
pam-auth-update32
• LDAP for Rocket Scientists33 от Zytrax; руководство менее педантичное, но
содержащее всесторонне рассмотренный LDAP.
• OpenLDAP wiki34 страница сообщества Ubuntu имеет коллекцию заметок.
• LDAP System Administration35 от O'Reilly (текст, 2003)
• Mastering OpenLDAP36 от Packt (текст, 2007)
26
27
28
29
30
31
32
33
34
35
36
134
Сетевая аутентификация
2. Samba и LDAP
В этом разделе описана интеграция Samba и LDAP. В этом случае сервер
Samba выполняет роль «отдельного» сервера, а LDAP обеспечивает
уровень аутентификации с описанием пользователя, группы и информации
о пользователе компьютера для нормального функционирования и
выполнения своих ролей (из 3 возможных). Отправной точкой в этом
может служить сервер OpenLDAP с определённой директорией, которая
принимает запросы аутентификации. Подробнее эта процедура описана в
предыдущей главе Раздел 1, «Сервер OpenLDAP» [107]. После прочтения
этой главы, вы должны решить для себя что вы хотите от вашего сервера
Samba, а затем настроить его относительно ваших потребностей.
2.1. Установка программного обеспечения
Для интеграции Samba с LDAP необходимы три пакета: samba, samba-doc и
smbldap-tools.
Строго говоря, пакет smbldap-tools не является необходимым, но, пока
у вас нет других способов управления различными сущностями Samba
(пользователями, группами, компьютерами) в контексте LDAP, вам следует
установить его.
Установите эти пакеты сейчас:
sudo apt-get install samba samba-doc smbldap-tools
2.2. Конфигурация LDAP
Теперь настроим LDAP-сервер, чтобы он мог хранить данные Samba. Для
этого нам необходимо выполнить три пункта:
1. Импортировать схему
2. Индексировать записи
3. Добавить объекты
2.2.1. Схема Samba
Для того чтобы OpenLDAP использовался как дополнение к Samba,
теоретически в дереве (DIT) должны присутствовать атрибуты, которые
корректно описывают данные Samba. Такие атрибуты могут быть получены
путём введения схемы Samba в LDAP. Сейчас мы это сделаем.
Для более детальной информации о схемах и их установке смотрите
Раздел 1.4, «Изменение базы данных настройки slapd» [113].
135
Сетевая аутентификация
1.
Такая схема находится в свежеустановленном вами пакете samba-doc.
Её требуется скопировать и разархивировать в каталог /etc/ldap/schema:
sudo cp /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz /etc/ldap/schema
sudo gzip -d /etc/ldap/schema/samba.schema.gz
2.
Получаем файл конфигурации schema_convert.conf, который должен
содержать следующие строки:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/ldapns.schema
include /etc/ldap/schema/pmi.schema
include /etc/ldap/schema/samba.schema
3.
Оставляем каталог ldif_output для вывода.
4.
Определите индекс схемы:
slapcat -f schema_convert.conf -F ldif_output -n 0 | grep samba,cn=schema
dn: cn={14}samba,cn=schema,cn=config
5.
Конвертируем схему в формат LDIF:
slapcat -f schema_convert.conf -F ldif_output -n0 -H \ ldap:///cn={14}samba,cn=schema,cn=config
6.
Редактируем созданный файл cn=samba.ldif, удаляя индексную
информацию, по достижению:
dn: cn=samba,cn=schema,cn=config
cn: samba
Удалите нижние строки:
structuralObjectClass: olcSchemaConfig
entryUUID: b53b75ca-083f-102d-9fff-2f64fd123c95
creatorsName: cn=config
136
Сетевая аутентификация
createTimestamp: 20080827045234Z
entryCSN: 20080827045234.341425Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20080827045234Z
Значения ваших атрибутов могут быть другими.
7. Добавляем новую схему:
sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f cn\=samba.ldif
Для запроса и просмотра новой схемы введите:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config 'cn=*samba*'
2.2.2. Индексы Samba
Теперь, когда slapd знает о атрибутах Samba, мы можем создать несколько
индексов на их основе. Индексация записей является способом повышения
производительности, когда клиент осуществляет выборочный поиск в
дереве (DIT).
Создайте файл samba_indices.ldif со следующим содержимым:
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
Используйте утилиту ldapmodify для загрузки новых индексов:
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f samba_indices.ldif
Если всё настроено правильно, вы увидите новые индексы, используя
утилиту ldapsearch:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H \ ldapi:/// -b cn=config olcDatabase={1}hdb olcDbIndex
137
Сетевая аутентификация
2.2.3. Добавление объектов Samba к LDAP
Далее настройте пакет smbldap-tools для соответствия вашей рабочей
среде. Пакет поставляется со сценарием конфигурации, который будет
задавать вопросы о необходимых опциях установки. Для запуска сценария
введите в терминале:
sudo gzip -d /usr/share/doc/smbldap-tools/configure.pl.gz
sudo perl /usr/share/doc/smbldap-tools/configure.pl
Вам может понадобиться закомментировать strict pragma в файле
configure.pl.
После того, как вы ответили на вопросы, должны быть сгенерированы
файлы /etc/smbldap-tools/smbldap.conf и /etc/smbldap-tools/smbldap_bind.conf.
Если вы сделали какие-либо ошибки при выполнении сценария, вы всегда
можете впоследствии отредактировать файлы.
Сценарий smbldap-populate добавит объекты LDAP, необходимые для
Samba. Неплохая идея - сначала сделать резервную копию всего каталога
с помощью slapcat:
sudo slapcat -l backup.ldif
После создания резервной копии, приступите к наполнению каталога:
sudo smbldap-populate
Вы можете создать файл LDIF, содержащий новые объекты Samba,
выполнив sudo smbldap-populate -e samba.ldif. Это позволит
просматривать изменения, убедившись, что всё работает правильно. Если
это так, перезапустите сценарий без опции '-e'. Либо вы можете взять файл
LDIF и импортировать его данные в обычном режиме.
Теперь ваш каталог LDAP содержит всю необходимую информацию для
аутентификации пользователей Samba.
2.3. Настройка Samba
Существуют различные способы настроить Samba. Информацию о
некоторых типичных конфигурациях смотрите в главе Глава 18, Сетевое
окружение Windows [320]. Чтобы настроить Samba для использования
LDAP, отредактируйте конфигурационный файл /etc/samba/smb.conf,
закомментировав параметр по умолчанию passdb backend и добавив
несколько параметров, связанных с LDAP:
138
Сетевая аутентификация
#
passdb backend = tdbsam
# LDAP Settings
passdb backend = ldapsam:ldap://hostname
ldap suffix = dc=example,dc=com
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=admin,dc=example,dc=com
ldap ssl = start tls
ldap passwd sync = yes
add machine script = sudo /usr/sbin/smbldap-useradd -t 0 -w "%u"
Измените значения для вашей конфигурации.
Перезапустите samba, чтобы задействовать новые настройки:
sudo restart smbd
sudo restart nmbd
Теперь укажите Samba пароль пользователя rootDN (который создан при
установке пакета slapd):
sudo smbpasswd -w password
Если у вас уже есть существующие пользователи LDAP, которых вы хотите
включить в вашу конфигурацию Samba, они должны иметь необходимые
атрибуты. Утилита smbpasswd подойдёт для этого наилучшим образом
(ваш компьютер должен иметь возможность видеть (нумеровать) этих
пользователей через NSS; или же должны быть установлены и настроены
пакеты libnss-ldapd или libnss-ldap):
sudo smbpasswd -a username
Вам будет предложено ввести пароль. Он будет считаться новым паролем
для этого пользователя. Разумным решением будет сделать его таким же,
как прежде.
Для настройки пользователей, групп и учётных записей на компьютерах
используйте стандартные утилиты, предоставляемые пакетом smbldap-
tools. Вот несколько примеров:
• Чтобы добавить нового пользователя:
sudo smbldap-useradd -a -P username
139
Сетевая аутентификация
Опция -a добавляет атрибут Samba, а опция -P вызывает утилиту smbldap-
passwd, после того как пользователь создан, позволяя создать новый
пароль для этого пользователя.
• Чтобы удалить пользователя:
sudo smbldap-userdel username
В этой команде также можно использовать опцию -r для удаления
домашней директории пользователя.
• Чтобы добавить группу:
sudo smbldap-groupadd -a groupname
Как и для smbldap-useradd, опция -a добавляет атрибуты Samba.
• Чтобы сделать существующего пользователя членом группы:
sudo smbldap-groupmod -m username groupname
Опция -m позволяет добавить сразу несколько пользователей,
перечислив их через запятую.
• Чтобы удалить пользователя из группы:
sudo smbldap-groupmod -x username groupname
• Добавить в Samba учетную запись компьютера:
sudo smbldap-useradd -t 0 -w username
Замените username на имя рабочей станции. Опция -t 0 создает учетную
запись без задержки, в то время как опция -w определяет пользователя
как учетную запись компьютера. Также обратите внимание, что параметр
add machine script в /etc/samba/smb.conf изменён, чтобы использовался
smbldap-useradd.
В пакете smbldap-tools есть пакеты, которые здесь не были рассмотрены.
Вот полный список:
smbldap-groupadd37
smbldap-groupdel38
smbldap-groupmod39
37
38
39
140
Сетевая аутентификация
smbldap-groupshow40
smbldap-passwd41
smbldap-populate42
smbldap-useradd43
smbldap-userdel44
smbldap-userinfo45
smbldap-userlist46
smbldap-usermod47
smbldap-usershow48
2.4. Ресурсы
• Для получения дополнительной информации по установке и
конфигурированию Samba прочтите главу Глава 18, Сетевое окружение
Windows [320] этого руководства.
• Существует несколько мест, где документированы LDAP и Samba в
апстриме Samba HOWTO Collection49.
• Относительно предыдущей ссылки, смотрите отдельно passdb section50.
• Хотя он и устарел (2007 год), ресурс Linux Samba-OpenLDAP HOWTO51
содержит ценную информацию.
• Основная страница Samba Ubuntu community documentation52 содержит
множество ссылок на статьи, которые могут оказаться полезными.
40
41
42
43
44
45
46
47
48
49
50
51
52
141
Сетевая аутентификация
3. Kerberos
Kerberos - это система сетевой аутентифиации, основанная на принципах
доверия третьей стороне. Другие две стороны - это пользователь и
сервис, на котором он хочет авторизоваться. Не все сервисы и приложения
могут использовать Kerberos, но те, которые могут, приближают сетевое
окружение на один шаг к технологии единого входа (Single Sign On - SSO).
В этом разделе рассматривается установка и настройка сервера Kerberos, а
также некоторые примеры настройки клиентов.
3.1. Обзор
Этот раздел раскрывает установку и настройку сервера Kerberos, а также
некоторые примеры клиентских настроек.
• Учётная запись (Principal): любые пользователи, компьютеры или сервисы,
предоставляемые серверами, должны быть определены, как учётные
записи Kerberos.
• Требования (Instances): используются для сервисных и специальных
административных учетных записей.
• Области (Realms): уникальная область управления, обеспечиваемая
установкой Kerberos. Представляйте её себе как домен или группу
ваших компьютеров и пользователей, ей принадлежащих. По умолчанию
Ubuntu использует имя DNS домена в верхнем регистре (EXAMPLE.COM) в
качестве имени области.
• Центр распространения ключей (KDC): состоит из трёх частей: базы
данных всех учетных записей, сервера аутентификации и сервера
предоставления билетов. Для каждой области должен быть хотя бы один
KDC.
• Билет для получения билета (TGT): изданный сервером аутентификации,
TGT зашифровывается на пароле пользователя, который известен только
пользователю и KDC.
• Сервер распространения билетов (TGS): выпускает сервисные билеты для
клиентов по запросу.
• Билеты (Tickets): подтверждение идентичности двух учётных записей.
Одна учётная запись - пользователь, а другая - сервис, запрашиваемый
этим пользователем. Билеты устанавливают секретный ключ,
используемый для защищённого соединения во время авторизованной
сессии.
• Файлы ключей (Keytab Files): файлы, извлечённые из базы учетных
записей KDC и содержащие ключ шифрования для сервиса или
компьютера.
142
Сетевая аутентификация
Чтобы сложить все вместе: область содержит как минимум один KDC,
лучше больше для обеспечения безотказности, которые содержат
базу данных учётных записей. Когда пользователь под учётной
записью заходит на рабочую станцию, которая настроена на Kerberos
аутентификацию, KDC выпускает билет для получения билетов (TGT).
Если пользователь предоставляет совпадающие параметры, он считается
аутентифицированным и может запрашивать билеты для сервисов,
поддерживающих Kerberos, на сервере распространения билетов (TGS).
Сервисные билеты позволяют пользователю аутентифицироваться на
сервисах без ввода имени и пароля.
3.2. Сервер Kerberos
3.2.1. Установка
Протокол Kerberos разработан в Масачусетском технологическом
университете (MIT), поэтому полное название протокола MIT Kerberos.
(прим. переводчика). Мы создадим домен MIT Kerberos со следующими
характеристиками (измените их под свои нужды):
• Realm: EXAMPLE.COM
• Primary KDC: kdc01.example.com (192.168.0.1)
• Secondary KDC: kdc02.example.com (192.168.0.2)
• Учетная запись пользователя: steve
• Учетная запись администратора: steve/admin
Настоятельно рекомендуется, чтобы ваши авторизованные в сети
пользователи имели uid в отдельном диапазоне от ваших локальных
пользователей (скажем, начиная с 5000).
Перед установкой сервера Kerberos требуется правильно настроить DNS-
сервер для вашего домена. Поскольку область Kerberos по соглашению
совпадает с именем домена, этот раздел использует домен EXAMPLE.COM,
настроенный как Primary Master по документации Раздел 2.3, «Первичный
мастер» [161].
Кроме того, Kerberos - протокол, зависимый от времени. Поэтому
если локальное время системы на клиентской машине и на сервере
отличается более чем на 5 минут (по умолчанию), рабочая станция не
будет аутентифицирована. Для решения проблемы все узлы сети должны
синхронизировать своё время по одному серверу Network Time Protocol
(NTP). Детали настройки NTP смотрите в разделе Раздел 4, «Синхронизация
времени с NTP» [57].
143
Сетевая аутентификация
Первый шаг по созданию области Kerberos - это установка пакетов krb5-
kdc и krb5-admin-server. Введите в терминале:
sudo apt-get install krb5-kdc krb5-admin-server
В конце установки у вас запросят сетевые имена серверов Kerberos и
административного, которые могут быть одним и тем же или разными
серверами для определённой области.
По умолчанию область создаётся из доменного имени KDC.
Далее создаём новую область с помощью утилиты kdb5_newrealm:
sudo krb5_newrealm
3.2.2. Конфигурация
Вопросы, задаваемые в процессе установки, используются для настройки
файла /etc/krb5.conf. Если вам требуется скорректировать настройки
KDC, просто измените файл и перезапустите службу krb5-kdc. Если
вам требуется перенастроить Kerberos с самого начала, возможно, для
изменения имени области, вы можете это сделать, набрав следующее:
sudo dpkg-reconfigure krb5-kdc
1. Как только KDC запущен правильно, требуется административный
пользователь учётная запись администратора. Рекомендуется
использовать имя пользователя, отличное от вашего повседневного
пользователя. Для использования утилиты kadmin.local наберите в
терминале:
sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc steve/admin
WARNING: no policy specified for steve/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "steve/admin@EXAMPLE.COM":
Re-enter password for principal "steve/admin@EXAMPLE.COM":
Principal "steve/admin@EXAMPLE.COM" created.
kadmin.local: quit
В примере выше steve - учётная запись, /admin - требование, а
@EXAMPLE.COM - определяет область. "Ежедневная" учётная запись,
она же пользовательская - steve@EXAMPLE.COM; она будет иметь
только обычные права пользователя.
144
Сетевая аутентификация
Замените EXAMPLE.COM и steve на ваши имена области и
администратора.
2.
Далее, новому пользователю-администратору требуется предоставить
соответствующие права доступа ACL. Права настраиваются в файле /
etc/krb5kdc/kadm5.acl:
steve/admin@EXAMPLE.COM
*
Эта запись предоставляет для steve/admin возможность выполнять
любые операции над любыми учётными записями в этой области. Вы
можете настроить учётные записи более ограниченными правами,
которые удобны, если вам требуется учётная запись младшего
администратора, которую можно использовать на клиентах Kerberos.
Пожалуйста, посмотрите страницу руководства (man) по kadm5.acl.
3.
Теперь перезапустите krb5-admin-server, чтобы применились новые ACL:
sudo /etc/init.d/krb5-admin-server restart
4.
Новая пользовательская учётная запись может быть протестирована
утилитой kinit:
kinit steve/admin
steve/admin@EXAMPLE.COM's Password:
После ввода пароля используйте утилиту klist, чтобы увидеть
информацию о билете для получения билетов (TGT):
klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: steve/admin@EXAMPLE.COM
Issued
Expires
Principal
Jul 13 17:53:34 Jul 14 03:53:34 krbtgt/EXAMPLE.COM@EXAMPLE.COM
где имя файла кэша krb5cc_1000 составлено из префикса krb5cc_ и
идентификатора пользователя (UID), который в нашем случае 1000. У вас
может возникнуть необходимость добавить запись в /etc/hosts для KDC,
чтобы клиент мог его найти. Например:
192.168.0.1
kdc01.example.com
kdc01
Замените 192.168.0.1 на IP-адрес вашего KDC. Обычно такое требуется,
когда ваша область Kerberos охватывает различные сети, разделенные
маршрутизаторами.
145
Сетевая аутентификация
5. Лучший способ позволить клиентам автоматически определить KDC для
области - это использование SRV-записей DNS. Добавьте следующие
записи в /etc/named/db.example.com:
_kerberos._udp.EXAMPLE.COM.
IN SRV 1
0 88 kdc01.example.com.
_kerberos._tcp.EXAMPLE.COM.
IN SRV 1
0 88 kdc01.example.com.
_kerberos._udp.EXAMPLE.COM.
IN SRV 10 0 88 kdc02.example.com.
_kerberos._tcp.EXAMPLE.COM.
IN SRV 10 0 88 kdc02.example.com.
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1
0 749 kdc01.example.com.
_kpasswd._udp.EXAMPLE.COM.
IN SRV 1
0 464 kdc01.example.com.
Замените EXAMPLE.COM, kdc01, иkdc02 на ваши имя домена,
первичный и вторичный KDC
Смотрите Глава 8, Служба доменных имён (DNS) [158] для детальных
инструкций по настройке DNS.
Ваша новая область Kerberos теперь готова аутентифицировать клиентов.
3.3. Вторичный KDC
Когда у вас есть один центр распространения ключей (KDC) в сети,
хорошей практикой является создание вторичного KDC на случай,
если первичный будет недоступен. Также, если у вас клиенты
Kerberos расположены в различных сетях (возможно разделённых
маршрутизаторами, использующими NAT), разумно будет поместить
вторичные KDC в каждую такую сеть.
1. Сначала установим пакеты и на вопросы о Kerberos и административном
серверах введем имя первичного KDC:
sudo apt-get install krb5-kdc krb5-admin-server
2. Как только пакеты установлены, создайте учетную запись вторичного
KDC. Из терминала набираем:
kadmin -q "addprinc -randkey host/kdc02.example.com"
Впоследствии, при выполнении любых команд kadmin, у вас
будет запрашиваться пароль вашей учётной записи username/
admin@EXAMPLE.COM.
3. Извлекаем файл keytab:
kadmin -q "ktadd -norandkey -k keytab.kdc02 host/kdc02.example.com"
4. Теперь в текущем каталоге появился keytab.kdc02, переместите его в /
etc/krb5.keytab:
146
Сетевая аутентификация
sudo mv keytab.kdc02 /etc/krb5.keytab
Если путь до файла keytab.kdc02 иной, замените соответственно.
Также вы можете вывести список учётных записей в файл keytab,
который может быть полезен при решении проблем, используя утилиту
klist:
sudo klist -k /etc/krb5.keytab
Опция -k показывает, что это keytab файл.
5.
Затем на каждом KDC должен быть файл kpropd.acl, который содержит
список всех KDC в области. В нашем примере на первичном и вторичном
KDC создайте /etc/krb5kdc/kpropd.acl:
host/kdc01.example.com@EXAMPLE.COM
host/kdc02.example.com@EXAMPLE.COM
6.
Создаём пустую базу данных на вторичном KDC:
sudo kdb5_util -s create
7.
Теперь запускаем службу kpropd, которая слушает соединения от
утилиты kprop. kprop используется для передачи файлов выгрузки
данных:
sudo kpropd -S
8.
Из терминала на первичном KDC создаём файл выгрузки для базы
данных учетных записей:
sudo kdb5_util dump /var/lib/krb5kdc/dump
9.
Извлекаем keytab файл первичного KDC и копируем его в /etc/
krb5.keytab:
kadmin -q "ktadd -k keytab.kdc01 host/kdc01.example.com"
sudo mv keytab.kdc01 /etc/krb5.keytab
Убедитесь, что это host для kdc01.example.com, перед
извлечением Keytab.
10. Используя утилиту kprop, загрузите базу данных на вторичный KDC:
sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
147
Сетевая аутентификация
Должно вернуться сообщение SUCCEEDED, если
распространение сработало. Если вернулось сообщение
об ошибке, проверьте /var/log/syslog на вторичном KDC для
дополнительной информации.
Вы можете также создать задачу cron для периодического обновления
базы данных на вторичных KDC. Например, следующий код будет
выгружать базу данных каждый час (обратите внимание, что длинная
строка разделена чтобы соответствовать формату документа):
# m h dom mon dow
command
0 * * * * /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump &&
/usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
11. Вернёмся на Secondary KDC, создадим stash (stash) файл для хранения
Kerberos master key (главного ключа Kerberos):
sudo kdb5_util stash
12. Под конец запустим сервис krb5-kdc на вторичном KDC:
sudo /etc/init.d/krb5-kdc start
Вторичный KDC теперь должен иметь возможность выдавать билеты
для своей области. Вы можете это проверить, остановив службу krb5-
kdcна первичном KDC и затем запросив билет с помощью kinitЕсли всё
пойдет хорошо, вы получите билет со вторичного KDC. В противном случае
проверяйте /var/log/syslog и /var/log/auth.log на вторичном KDC.
3.4. Клиент Kerberos для Linux
Эта часть освещает настройку клиента Kerberos на системе Linux. Это
позволит получить доступ к любому керберезированному сервису, как
только пользователь удачно авторизуется в системе.
3.4.1. Установка
Чтобы аутентифицироваться в области Kerberos, требуются пакеты krb5-
user и libpam-krb5, а также некоторые другие, которые не являются
необходимыми, но делают жизнь проще. Для установки пакетов наберите
следующую команду в терминале:
sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config
Пакет auth-client-config позволяет просто настроить PAM для
аутентификации множества сервисов, а libpam-ccreds будет кэшировать
148
Сетевая аутентификация
параметры аутентификации, позволяя вам подключаться, когда центр
распространения ключей (KDC) недоступен. Этот пакет также полезен
для переносных компьютеров, которые могут авторизовываться с
использованием Kerberos в корпоративной сети, но также должны быть
доступны и вне сети.
3.4.2. Конфигурация
Для настройки клиента наберите в терминале:
sudo dpkg-reconfigure krb5-config
Вас попросят ввести имя области Kerberos. Также, если у вас нет DNS-
сервера с настроенными записями Kerberos SRV, меню запросит у вас
сетевое имя центра распространения ключей (KDC) и административного
сервера области.
dpkg-reconfigure добавит записи в файл /etc/krb5.conf для вашей области. У
вас будут записи, похожие на следующие:
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = }
kdc = 192.168.0.1
admin_server = 192.168.0.1
}
Если вы установите uid каждого вашего авторизованного
в сети пользователя начиная с 5000, как предложено в
Раздел 3.2.1, «Установка» [143], вы затем сможете указать pam
аутентифицировать с помощью Kerberos только пользователей с uid
> 5000:
# Kerberos should only be applied to ldap/kerberos users, not local ones. for i in common-a
Это поможет избежать запросов (несуществующих) паролей
Kerberos для локально аутентифицированных пользователей при
смене у них пароля с помощью passwd.
Вы можете проверить настройки запросив билет с помощью утилиты kinit.
Например:
kinit steve@EXAMPLE.COM
Password for steve@EXAMPLE.COM:
149
Сетевая аутентификация
Когда билет будет предоставлен, детали можно увидеть с помощью klist:
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: steve@EXAMPLE.COM
Valid starting
Expires
Service principal
07/24/08 05:18:56
07/24/08 15:18:56
krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 07/25/08 05:18:57
Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached
Затем используйте auth-client-config для настройки модуля libpam-krb5 для
запроса билета в процессе входа:
sudo auth-client-config -a -p kerberos_example
Теперь вы будете получать билет в случае удачной аутентификации на
входе.
3.5. Ресурсы
• Для дополнительной информации по версии MIT Kerberos смотрите сайт
MIT Kerberos53.
• Страница Ubuntu Wiki Kerberos54 содержит дополнительные подробности.
• Kerberos: The Definitive Guide55 от O'Reilly - великолепное руководство по
установке Kerberos.
• Посетите также IRC-каналы #ubuntu-server и #kerberos на Freenode56,
если у вас остались вопросы по Kerberos.
53
54
55
56
150
Сетевая аутентификация
4. Kerberos и LDAP
Большинство людей не используют Kerberos сам по себе; как только
пользователь аутентифицировался (Kerberos), нам нужно вычислить что
пользователь может делать (авторизация). И это становится задачей таких
программ, как LDAP.
Репликация базы данных учётных записей (принципалов) Kerberos
между двумя серверами может быть сложной и добавляет в вашу
сеть дополнительную базу данных пользователей. К счастью, MIT
Kerberos можно сконфигурировать для использования каталога LDAP в
качестве базы данных принципалов. В этом разделе рассматривается
конфигурирование первичного и вторичного серверов Kerberos для
использования OpenLDAP для базы данных принципалов.
Приведенные здесь примеры предполагают использование MIT
Kerberos и OpenLDAP.
4.1. Настройка OpenLDAP
В первую очередь, schema должен быть загружен на OpenLDAP сервер,
который имеет подключения к сети на Первичном и Вторичном KDC. Далее
в этом разделе предполагается, что у вас также настроена репликация
LDAP, как минимум, между двумя серверами. Для получения информации о
настройке OpenLDAP смотрите Раздел 1, «Сервер OpenLDAP» [107].
Необходимо также настроить OpenLDAP для TLS и SSL-соединений, чтобы
трафик между KDC и LDAP сервером был в зашифрованном виде. Подробнее
смотрите в Раздел 1.8, «TLS» [123] .
cn=admin,cn=config - пользователь, которого мы создали с правами
редактирования базы ldap. Много раз это был RootDN. Измените его
значение для соответствия вашим настройкам.
• Для загрузки схемы в LDAP, на сервере LDAP установите пакет krb5-kdc-
ldap. В терминале введите:
sudo apt-get install krb5-kdc-ldap
• Далее распакуйте файл kerberos.schema.gz:
sudo gzip -d /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz
sudo cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema /etc/ldap/schema/
151
Сетевая аутентификация
• Схема kerberos должна быть добавлена к дереву cn=config. Процедура
добавления новой схемы к slapd детально описана в секции Раздел 1.4,
«Изменение базы данных настройки slapd» [113].
1.
Сначала создадим файл настроек с именем schema_convert.conf или
другим значащим именем, содержащим следующие строки:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/kerberos.schema
2.
Создадим временный каталог для хранения LDIF файлов:
mkdir /tmp/ldif_output
3.
Теперь используем slapcat для конвертирования файлов схемы:
slapcat -f schema_convert.conf -F /tmp/ldif_output -n0 -s \ "cn={12}kerberos,cn=schema,cn=con
Измените имена файла и каталога выше для соответствия вашим
именам, если они отличаются.
4.
Отредактируйте созданный файл /tmp/cn\=kerberos.ldif, изменив
следующие атрибуты:
dn: cn=kerberos,cn=schema,cn=config
cn: kerberos
И удалите следующие строки в конце файла:
structuralObjectClass: olcSchemaConfig
entryUUID: 18ccd010-746b-102d-9fbe-3760cca765dc
creatorsName: cn=config
createTimestamp: 20090111203515Z
entryCSN: 20090111203515.326445Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20090111203515Z
152
Сетевая аутентификация
Значения атрибутов могут отличаться, просто убедитесь, что
атрибуты удалены.
5.
Загрузите новую схему с помощью ldapadd:
ldapadd -x -D cn=admin,cn=config -W -f /tmp/cn\=kerberos.ldif
6.
Добавьте индекс для атрибута krb5principalname:
ldapmodify -x -D cn=admin,cn=config -W
Enter LDAP Password:
dn: olcDatabase={1}hdb,cn=config
add: olcDbIndex
olcDbIndex: krbPrincipalName eq,pres,sub
modifying entry "olcDatabase={1}hdb,cn=config"
7.
В конце обновите списки контроля доступа (ACL):
ldapmodify -x -D cn=admin,cn=config -W
Enter LDAP Password:
dn: olcDatabase={1}hdb,cn=config
replace: olcAccess
olcAccess: to attrs=userPassword,shadowLastChange,krbPrincipalKey by
dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none
-
add: olcAccess
olcAccess: to dn.base="" by * read
-
add: olcAccess
olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read
modifying entry "olcDatabase={1}hdb,cn=config"
Ну вот, теперь ваш каталог LDAP готов обслуживать базу данных учётных
записей Kerberos.
4.2. Настройка первичного KDC
С настроенным OpenLDAP самое время настроить KDC.
• Сначала установите необходимые пакеты, набрав в теминале:
sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldap
• Теперь редактируем /etc/krb5.conf, добавив следующие опции в
соответствующие секции:
[libdefaults]
153
Сетевая аутентификация
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc01.example.com
kdc = kdc02.example.com
admin_server = kdc01.example.com
admin_server = kdc02.example.com
default_domain = example.com
database_module = openldap_ldapconf
}
[domain_realm]
.example.com = EXAMPLE.COM
[dbdefaults]
ldap_kerberos_container_dn = dc=example,dc=com
[dbmodules]
openldap_ldapconf = {
db_library = kldap
ldap_kdc_dn = "cn=admin,dc=example,dc=com"
# this object needs to have read rights on
# the realm container, principal container and realm sub-trees
ldap_kadmind_dn = "cn=admin,dc=example,dc=com"
# this object needs to have read and write rights on
# the realm container, principal container and realm sub-trees
ldap_service_password_file = /etc/krb5kdc/service.keyfile
ldap_servers = ldaps://ldap01.example.com ldaps://ldap02.example.com
ldap_conns_per_server = 5
}
Замените example.com, dc=example,dc=com,
cn=admin,dc=example,dc=com, и ldap01.example.com на
соответствующие домен, LDAP объект и LDAP сервер вашей сети.
• Далее используем утилиту kdb5_ldap_util для создания области:
sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees \ dc=example,dc=com -r EXAMPLE
• Создаём тайник для пароля, используемого для подключения к LDAP-
серверу. Этот пароль используется опциями ldap_kdc_dn и ldap_kadmin_dn
в /etc/krb5.conf:
154
Сетевая аутентификация
sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f \ /etc/krb5kdc/service.keyfile cn
• Копируем сертификат CA из сервера LDAP:
scp ldap01:/etc/ssl/certs/cacert.pem .
sudo cp cacert.pem /etc/ssl/certs
и редактируем /etc/ldap/ldap.conf для использования этого сертификата:
TLS_CACERT /etc/ssl/certs/cacert.pem
Сертификат также нужно скопировать на вторичный KDC, чтобы
позволить соединение с LDAP-серверами с использованием LDAPS.
Вы можете добавить учётные записи Kerberos в базу LDAP, и они будут
скопированы на все LDAP-серверы, настроенные на репликацию. Для
добавления учётной записи с использованием утилиты kadmin.local
введите:
sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc -x dn="uid=steve,ou=people,dc=example,dc=com" steve
WARNING: no policy specified for steve@EXAMPLE.COM; defaulting to no policy
Enter password for principal "steve@EXAMPLE.COM":
Re-enter password for principal "steve@EXAMPLE.COM":
Principal "steve@EXAMPLE.COM" created.
Теперь будут добавлены атрибуты krbPrincipalName, krbPrincipalKey,
krbLastPwdChange и krbExtraData к объекту пользователя
uid=steve,ou=people,dc=example,dc=com. Используйте утилитыkinit и klist
для проверки, что пользователю действительно выдали билет.
Если объект пользователя уже создан, потребуется опция -x dn="..."
для добавления атрибутов Kerberos. Иначе будет создан новый
объект учетной записи в поддереве области.
4.3. Настройка вторичного KDC
Настройка вторичного KDC с использованием LDAP похожа на настройку
обычной базы Kerberos.
1. Во-первых, установите необходимые пакеты. В терминале введите:
sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldap
2. Далее редактируем /etc/krb5.conf для использования LDAP:
155
Сетевая аутентификация
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc01.example.com
kdc = kdc02.example.com
admin_server = kdc01.example.com
admin_server = kdc02.example.com
default_domain = example.com
database_module = openldap_ldapconf
}
[domain_realm]
.example.com = EXAMPLE.COM
[dbdefaults]
ldap_kerberos_container_dn = dc=example,dc=com
[dbmodules]
openldap_ldapconf = {
db_library = kldap
ldap_kdc_dn = "cn=admin,dc=example,dc=com"
# this object needs to have read rights on
# the realm container, principal container and realm sub-trees
ldap_kadmind_dn = "cn=admin,dc=example,dc=com"
# this object needs to have read and write rights on
# the realm container, principal container and realm sub-trees
ldap_service_password_file = /etc/krb5kdc/service.keyfile
ldap_servers = ldaps://ldap01.example.com ldaps://ldap02.example.com
ldap_conns_per_server = 5
}
3.
Создаём тайник для пароля соединения с LDAP:
sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f \ /etc/krb5kdc/service.keyfile
4.
Теперь на первичном KDC копируем /etc/krb5kdc/.k5.EXAMPLE.COM тайник с
главным ключом на вторичный KDC. Убедитесь, что копирование файла
происходит через зашифрованное соединение, такое как scp или через
физический носитель.
156
Сетевая аутентификация
sudo scp /etc/krb5kdc/.k5.EXAMPLE.COM steve@kdc02.example.com:~
sudo mv .k5.EXAMPLE.COM /etc/krb5kdc/
Снова замените EXAMPLE.COM на вашу актуальную область.
5. Возвращаемся на Secondary KDC, чтобы только (пере)запустить ldap
сервер:
sudo service slapd restart
6. И в конце запускаем сервис krb5-kdc:
sudo /etc/init.d/krb5-kdc start
7. Убедитесь, что два LDAP-сервера (и kerberos вдобавок)
синхронизированы.
Теперь у вас в сети избыточные KDC, и с избыточными LDAP серверами вы
можете продолжать аутентифицировать пользователей, если один LDAP
сервер, один Kerberos сервер или один LDAP с одним Kerberos сервером
станут недоступны.
4.4. Ресурсы
• Kerberos Admin Guide57 содержит некоторые дополнительные детали.
• Для дополнительной информации по kdb5_ldap_util смотрите Section 5.658
и kdb5_ldap_util man page59.
• Другой полезной ссылкой является krb5.conf man page60.
• Также смотрите Kerberos and LDAP61 на Ubuntu wiki.
57
back_002dend
58
Database
59
60
61
157
Глава 8. Служба доменных
имён (DNS)
Служба доменных имён (Domain Name Service, DNS) - это служба
интернета, которая ставит в соответствие друг с другом IP-адреса и полные
доменные имена (Fully Qualified Domain Names, FQDN). Таким образом,
DNS избавляет от необходимости запоминать IP-адреса. Компьютеры,
на которых запущен сервер DNS, называются серверами имён. Ubuntu
включает в себя BIND (Berkley Internet Naming Daemon), наиболее
распространенную программу для обслуживания серверов имён в Linux.
158
Служба доменных имён (DNS)
1. Установка
Для установки bind наберите в терминале следующую команду:
sudo apt-get install bind9
Очень полезный пакет для тестирования и решения проблем с DNS - это
пакет dnsutils. Очень часто эти инструменты уже установлены, но для
проверки и/или установки dnsutils введите следующее:
sudo apt-get install dnsutils
159
Служба доменных имён (DNS)
2. Конфигурация
Существует много способов настроить BIND9. Наиболее распространенные
конфигурации - это кэширующий сервер имён, первичный мастер и
вторичный мастер.
• Когда BIND9 настроен как кэширующий сервер, он ищет ответы на
запросы имени и запоминает ответ на случай, если запрос придёт
повторно.
• В качестве первичного мастера BIND9 читает данные зоны из локального
файла и является ответственным за эту зону.
• В качестве вторичного мастера BIND9 получает данные по зоне (целиком)
с другого сервера имён, отвечающего за эту зону.
2.1. Обзор
Файлы настройки DNS сохраняются в каталоге /etc/bind. Основной файл
конфигурации - это /etc/bind/named.conf.
Строки include определяют имена файлов, которые содержат опции
DNS. Строка directory в файле /etc/bind/named.conf.options сообщает DNS,
где искать файлы. Пути ко всем файлам, используемым BIND, будут
относительными к этому каталогу.
Файл с именем /etc/bind/db.root описывает корневые сервера имён в мире.
Сервера со временем меняются, поэтому файл /etc/bind/db.root должен
время от времени обслуживаться. Обычно это делается через обновлений
к пакету bind9. Секция zone определяет мастер сервер, и она хранится в
файле, определяемом опцией file.
Существует возможность настроить один сервер как кэширующий сервер
имён, первичный мастер и вторичный мастер одновременно. Сервер
может быть началом Authority (Start of Authority, SOA) для одной зоны,
при этом предоставляя вторичный сервис для другой, и при всём этом
предоставлять кэширующий сервис в локальной сети (LAN).
2.2. Кэширующий сервер имён
По умолчанию конфигурация настраивается на работу в качестве
кэширующего сервера. Всё, что для этого требуется - это добавить
IP-адреса DNS-серверов вашего интернет-провайдера. Просто
раскомментируйте и исправьте следующее в /etc/bind/named.conf.options:
160
Служба доменных имён (DNS)
forwarders {
1.2.3.4;
5.6.7.8;
};
Замените 1.2.3.4 и 5.6.7.8 на актуальные IP-адреса серверов имён.
Теперь перегружаем DNS-сервер для применения новой конфигурации.
Наберите в терминале:
sudo service bind9 restart
Смотрите Раздел 3.1.2, «dig» [166] для информации по тестированию
кэширующего DNS-сервера.
2.3. Первичный мастер
В этом разделе BIND9 будет настроен как первичный мастер для домена
example.com. Просто замените example.com на ваше FQDN (Fully Qualified
Domain Name).
2.3.1. Файл прямой зоны
Чтобы добавить зону DNS в BIND9, превратив его в сервер первичного
мастера, первым шагом отредактируем /etc/bind/named.conf.local:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
Теперь используем существующий файл зоны в качестве шаблона для
создания файла /etc/bind/db.example.com:
sudo cp /etc/bind/db.local /etc/bind/db.example.com
Редактируем новый файл зоны /etc/bind/db.example.com, заменив localhost.
на FQDN нашего сервера, оставляя дополнительную "." в конце. Заменим
127.0.0.1 на IP-адрес сервера имён и root.localhost на правильный адрес
электронной почты, но с "." вместо символа "@", опять же оставляя "." в
конце. Измените комментарий для указания домена, для которого этот
файл сделан.
Создайте запись A для базового домена example.com. Также создайте
запись A для ns.example.com - сервера имён в данном примере:
161
Служба доменных имён (DNS)
;
; BIND data file for example.com
;
$TTL
604800
@
IN
SOA
example.com. root.example.com. (
2
; Serial
604800
; Refresh
86400
; Retry
2419200
; Expire
604800 )
; Negative Cache TTL
IN
A
192.168.1.10
;
@
IN
NS
ns.example.com.
@
IN
A
192.168.1.10
@
IN
AAAA
::1
ns
IN
A
192.168.1.10
Вы должны увеличивать порядковый номер (Serial) каждый раз, когда
делаете изменения в файле зоны. Если вы делаете множественные
изменения перед перезапуском BIND9, просто увеличьте Serial на единицу
один раз.
Теперь вы можете добавлять DNS записи в конец файла зоны. Смотрите
подробности в разделе Раздел 4.1, «Общие типы записей» [170].
Многие администраторы предпочитают использовать дату
последнего редактирования в качестве порядкового номера (Serial)
зоны в виде 2012010100, что соответствует формату yyyymmddss
(где ss - порядковый номер)
Как только вы произвели изменения в файле зоны, требуется перегрузить
BIND9 для применения изменений:
sudo service bind9 restart
2.3.2. Файл обратной зоны
Теперь, когда зона создана и разрешает имена в IP-адреса, требуется
создать также обратную зону. Обратная зона позволяет DNS определять
имя по IP-адресу.
Редактируем /etc/bind/named.conf.local и добавляем следующее:
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
};
162
Служба доменных имён (DNS)
Замените 1.168.192 на первые три октета адресов сети, которую
вы используете. Также дайте имя файлу зоны /etc/bind/db.192 в
соответствии с первым октетом вашей сети.
Теперь создаём файл /etc/bind/db.192:
sudo cp /etc/bind/db.127 /etc/bind/db.192
Далее редактируем /etc/bind/db.192, изменяя в основном те же опции, что и
в /etc/bind/db.example.com:
;
; BIND reverse data file for local 192.168.1.XXX net
;
$TTL
604800
@
IN
SOA
ns.example.com. root.example.com. (
2
; Serial
604800
; Refresh
86400
; Retry
2419200
; Expire
604800 )
; Negative Cache TTL
;
@
IN
NS
ns.
10
IN
PTR
ns.example.com.
Порядковый номер (Serial)в обратной зоне также требуется увеличивать
при каждом изменении. Для каждой Записи A, которую вы настроите в /etc/
bind/db.example.com, то есть для каждого адреса, вы должны создать запись
PTR в /etc/bind/db.192.
После создания файла обратной зоны перегрузите BIND9:
sudo service bind9 restart
2.4. Вторичный мастер
Поскольку первичный мастер (Primary Master) настроен, требуется
Secondary Master для того, чтобы поддерживать домен при недоступности
первичного мастера.
Для начала на первичном мастере надо разрешить передачу зоны.
Добавьте опцию allow-transfer к определениям прямой и обратной зон в /
etc/bind/named.conf.local:
zone "example.com" {
type master;
163
Служба доменных имён (DNS)
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
};
Замените 192.168.1.11 на IP-адрес вашего вторичного сервера имён.
Перезапустим BIND9 на первичном мастере:
sudo service bind9 restart
Далее, на вторичном мастере установите пакет bind9 так же, как делали
на первичном. Затем отредактируем /etc/bind/named.conf.local и добавим
следующие определения к прямой и обратной зонам:
zone "example.com" {
type slave;
file "db.example.com";
masters { 192.168.1.10; };
};
zone "1.168.192.in-addr.arpa" {
type slave;
file "db.192";
masters { 192.168.1.10; };
};
Замените 192.168.1.10 на IP-адрес вашего первичного сервера имён.
Перегружаем BIND9 на вторичном мастере:
sudo service bind9 restart
В /var/log/syslog вы сможете увидеть нечто похожее на (некоторые строки
разделены для соответствия формату документа):
client 192.168.1.10#39448: received notify for zone '1.168.192.in-addr.arpa'
zone 1.168.192.in-addr.arpa/IN: Transfer started.
transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
connected using 192.168.1.11#37531
zone 1.168.192.in-addr.arpa/IN: transferred serial 5
transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
164
Служба доменных имён (DNS)
Transfer completed: 1 messages,
6 records, 212 bytes, 0.002 secs (106000 bytes/sec)
zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5)
client 192.168.1.10#20329: received notify for zone 'example.com'
zone example.com/IN: Transfer started.
transfer of 'example.com/IN' from 192.168.1.10#53: connected using 192.168.1.11#38577
zone example.com/IN: transferred serial 5
transfer of 'example.com/IN' from 192.168.1.10#53: Transfer completed: 1 messages,
8 records, 225 bytes, 0.002 secs (112500 bytes/sec)
Обратите внимание, что передача зоны произойдет только если
порядковый номер (Serial) на первичном сервере больше значения
на вторичном. Если вы хотите, чтобы первичный мастер DNS
сообщал вторичному DNS серверу об изменении зоны, вы можете
добавить also-notify { ipaddress; }; в /etc/bind/named.conf.local, как
показано в примере ниже:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
Каталог по умолчанию для файлов неавторизованных зон - /var/
cache/bind/. Этот каталог также настроен в AppArmor для разрешения
доступа сервису named на запись в него. Для дополнительной
информации по AppArmor смотрите Раздел 4, «AppArmor» [189].
165
Служба доменных имён (DNS)
3. Устранение проблем
Этот раздел посвящён способам определения причины проблем,
возникающих с DNS и BIND9.
3.1. Тестирование
3.1.1. resolv.conf
Первый шаг в тестировании BIND9 - это добавление IP-адреса сервера
имён в список определителя сетевых имен. Первичный сервер имён должен
настраиваться, как и любой другой узел сети, с двойной проверкой. Просто
отредактируйте/etc/resolv.conf, добавив следующее:
nameserver 192.168.1.10
nameserver 192.168.1.11
Вам надо добавить также IP-адрес вторичного сервера имен на
случай недоступности первичного.
3.1.2. dig
Если вы установили пакет dnsutils, вы можете проверить свою установку,
используя обзорную утилиту DNS dig:
• После установки BIND9 примените dig к интерфейсу обратной петли
(loopback), чтобы убедиться, что порт 53 прослушивается. Из терминала
наберите:
dig -x 127.0.0.1
Вы должны увидеть строки вывода, похожие на следующее:
;; Query time: 1 msec
;; SERVER: 192.168.1.10#53(192.168.1.10)
• Если BIND9 настроен у вас как кэширующий сервер, используйте "dig" для
замера времени при разрешении имени внешнего домена:
dig ubuntu.com
Обратите внимание на время в конце вывода результата команды:
;; Query time: 49 msec
После повторного вызова dig должно произойти улучшение:
166
Служба доменных имён (DNS)
;; Query time: 1 msec
3.1.3. ping
Теперь для демонстрации, как приложения могут использовать DNS для
разрешения сетевых имён, используйте утилиту ping для отправки эхо-
запроса ICMP. Из терминала наберите следующее:
ping example.com
Это проверит, может ли сервер имён разрешить имя ns.example.com в IP-
адрес. Вывод команды будет напоминать следующее:
PING ns.example.com (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.800 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.813 ms
3.1.4. named-checkzone
Хороший способ проверить ваши файлы зон - это использовать утилиту
named-checkzone, установленную вместе с пакетом bind9.Эта утилита
позволяет вам убедиться в корректности настроек до перезапуска BIND9 и
применения изменений.
• Для тестирования нашего файла прямой зоны из примера введите
следующее в командной строке:
named-checkzone example.com /etc/bind/db.example.com
Если всё настроено верно, вы сможете увидеть вывод, похожий на:
zone example.com/IN: loaded serial 6
OK
• Аналогично, для тестирования файла обратной зоны введите следующее:
named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192
Вывод должен напоминать следующее:
zone 1.168.192.in-addr.arpa/IN: loaded serial 3
OK
Порядковый номер (Serial) вашего файла зоны может отличаться.
167
Служба доменных имён (DNS)
3.2. Ведение журнала
BIND9 имеет широкий набор доступных опций настроек журналов.
Существуют две основные опции. С помощью опции channel указывается,
где вести журналы, а опция category определяет, какую информацию
писать в журнал.
Если опции журналов отсутствуют, по умолчанию применяется следующее:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Этот раздел раскрывает, как настроить BIND9 для отправки отладочных
сообщений, связанных с DNS запросами, в отдельный файл.
• Сначала нам надо настроить канал (channel) для определения того, в
какой файл посылать сообщения. Редактируем /etc/bind/named.conf.local и
добавляем следующее:
logging {
channel query.log {
file "/var/log/query.log";
severity debug 3;
};
};
• Затем настраиваем категорию (category) для отправки всех DNS запросов
в файл:
logging {
channel query.log {
file "/var/log/query.log";
severity debug 3;
};
category queries { query.log; };
};
Обратите внимание на опцию debug, которая может принимать
значения от 1 до 3. Если уровень отладки не указан, по умолчанию
используется 1.
• Поскольку сервис named daemon запускается от имени bind, надо создать
файл /var/log/query.log и сменить его владельца:
sudo touch /var/log/query.log
sudo chown bind /var/log/query.log
168
Служба доменных имён (DNS)
• Перед тем, как сервис named сможет писать в новый файл журнала,
нужно изменить профиль AppArmor. Сначала редактируем файл /etc/
apparmor.d/usr.sbin.named, добавив:
/var/log/query.log w,
Затем перезагружаем профиль:
cat /etc/apparmor.d/usr.sbin.named | sudo apparmor_parser -r
Дополнительную информацию по AppArmor смотрите в разделе Раздел 4,
«AppArmor» [189]
• Теперь перезагружаем BIND9 для применения изменений:
sudo service bind9 restart
Теперь вы можете увидеть файл /var/log/query.log, заполненный
информацией о запросах. Это простейший пример использования опций
журналирования BIND9. По использованию расширенных опций смотрите
раздел Раздел 4.2, «Дополнительная информация» [170].
169
Служба доменных имён (DNS)
4. Ссылки
4.1. Общие типы записей
Этот раздел покажет некоторые наиболее общие типы записей DNS.
• Запись A: Эта запись указывает IP-адрес для сетевого имени (hostname).
www
IN
A
192.168.1.12
• Запись CNAME: Используется для создания псевдонима (alias) записи A.
Нельзя создавать запись CNAME, указывающую на другую запись CNAME.
web
IN
CNAME www
• Запись MX: Используется для определения, куда должна отправляться
электронная почта. Должна указывать на запись A, не на CNAME.
IN
MX
1
mail.example.com.
mail
IN
A
192.168.1.13
• Запись NS: Используется для определения, какие сервера поддерживают
копии зоны. Должна указывать на запись A, не на CNAME. Ею
определяются первичные и вторичные сервера зоны.
IN
NS
ns.example.com.
IN
NS
ns2.example.com.
ns
IN
A
192.168.1.10
ns2
IN
A
192.168.1.11
4.2. Дополнительная информация
• DNS HOWTO1 описывает больше расширенных опций для настройки
BIND9.
• Для глубокого освещения DNS и BIND9 смотрите Bind9.net2.
• Популярная книга DNS and BIND3 теперь в пятой редакции.
• Хорошее место для вопросов поддержки BIND9 и вовлечения в
сообщество Ubuntu Server - это канал IRC #ubuntu-server на freenode4.
• Также смотрите BIND9 Server HOWTO5 на Ubutu wiki.
170
Глава 9. Защита
Безопасность всегда следует учитывать во время установки,
развёртывания и использования любого вида компьютерных систем.
Несмотря на то, что чистая установка Ubuntu весьма безопасна для
немедленного использования в Интернете, важно иметь хорошее
понимание состояния безопасности ваших систем, на основании того, как
они будут использоваться после развёртывания.
В этой главе дается обзор безопасности, связанных с тем, как они
относятся к Ubuntu 12.04 LTS Server Edition, а также описываются простые
меры, которые вы можете использовать для защиты вашего сервера и сети
от любого числа потенциальных угроз безопасности.
171
Защита
1. Управление пользователями
Управление пользователями - это важная часть контроля безопасности
системы. Неэффективное управление пользователями и привилегиями
часто приводит многие системы к компрометации. Однако, важно, чтобы
вы понимали, как можно защитить ваш сервер простыми и эффективными
техниками управления пользовательскими учётными записями.
1.1. Где root?
Разработчики Ubuntu сделали сознательное решение по умолчанию
отключить административную учётную запись root во всех инсталляциях
Ubuntu. Это не означает, что аккаунт root был удалён или что к нему
нельзя получить доступ. Он просто получил пароль, соответствующий
невозможному значению, так что войти в систему напрямую под root
нельзя.
Вместо этого, пользователям для выполнения административных
задач предлагается использовать инструмент sudo. Sudo позволяет
авторизованному пользователю временно повышать свои привилегии,
пользуясь их собственным паролем вместо пароля учётной записи root.
Эта простая и эффективная методика предоставляет возможность учёта
всех действий пользователей и даёт администратору точечный контроль
на тем, какие действия пользователь может выполнять с указанными
привилегиями.
• Если по какой-то причине вам хочется включить учётную запись root,
просто дайте ей пароль:
sudo passwd
Sudo запросит ваш пароль, а затем предложит ввести новый пароль для
root, как показано ниже:
[sudo] password for username: (введите ваш пароль)
Enter new UNIX password: (введите новый пароль для root)
Retype new UNIX password: (повторите новый пароль для root)
passwd: password updated successfully
• Для отключения учётной запись root используется следующий синтаксис
passwd:
sudo passwd -l root
• Вам стоит прочитать больше о Sudo, обратившись к его man-странице.
172
Защита
man sudo
По умолчанию исходный пользователь, созданный инсталлятором Ubuntu
- член группы "admin", который добавляется в файл /etc/sudoers как
авторизованный пользователь sudo. Если вы хотите предоставить любым
другим учётным записям полный доступ root через sudo, просто добавьте
их в группу admin.
1.2. Добавление и удаление пользователей
Процесс управления локальными пользователями и группами совершенно
понятный и почти не отличается от большинства других операционных
систем семейства GNU/Linux. В Ubuntu и других дистрибутивах, основанных
на Debian, рекомендуется использовать для управления учётными
записями пакет "adduser".
• Чтобы добавить учётную запись пользователя, используйте следующий
синтаксис и следуйте указаниям системы, чтобы назначить учётной
записи пароль и указать другие данные, такие как полное имя, номер
телефона и прочее.
sudo adduser username
• Чтобы удалить учётную запись пользователя и его основную группу,
используется следующий синтаксис:
sudo deluser username
Удаление учётной записи не уничтожает соответствующий ей домашний
каталог. На вас остаётся решение, удалить ли папку вручную или
оставить в соответствии с желаемыми политиками хранения.
Помните, любой пользователь, добавленный позже с такими же UID/GID,
как предыдущий владелец, получит доступ к этому каталогу, если вы не
примете требуемых мер предосторожности.
Вы можете захотеть заменить значения UID/GID на что-то более
подходящее, такое как учётная запись root, и, возможно, даже
переместить каталог во избежание будущих конфликтов.
sudo chown -R root:root /home/username/
sudo mkdir /home/archived_users/
sudo mv /home/username /home/archived_users/
• Чтобы временно заблокировать или разблокировать учётную запись
пользователя, используется соответственно следующий синтаксис:
173
Защита
sudo passwd -l username
sudo passwd -u username
• Чтобы добавить или удалить конкретную группу, используется
соответственно следующий синтаксис:
sudo addgroup groupname
sudo delgroup groupname
• Чтобы добавить пользователя в группу, используется следующее:
sudo adduser username groupname
1.3. Безопасность пользовательских профилей
Когда создаётся новый пользователь, утилита adduser создаёт новый
соответствующий домашний каталог, называющийся /home/username. Профиль
по умолчанию создаётся на основе содержимого, найденного в папке /etc/
skel, включающей всё базовое содержимое профиля.
Если ваш сервер будет использоваться многими пользователями, нужно
уделить большое внимание правам доступа к домашним каталогам
пользователей, чтобы гарантировать конфиденциальность. По умолчанию,
пользовательские домашние каталоги в Ubuntu создаются с правами
чтения/выполнения для всех. Это означает, что все пользователи могут
просматривать и читать содержимое домашних каталогов других
пользователей. Это может не подходить для вашего рабочего окружения.
• Чтобы проверить текущие права доступа к домашним каталогам ваших
пользователей, используйте следующий синтаксис:
ls -ld /home/username
Следующий вывод показывает, что у всех есть право доступа к папке /
home/username на чтение.
drwxr-xr-x
2 username username
4096 2007-10-02 20:03 username
• Вы можете удалить полномочия чтения для всех, используя следующую
команду:
sudo chmod 0750 /home/username
Некоторые люди необдуманно склоняются к использованию
рекурсивной опции (-R), которая модифицирует все дочерние
174
Защита
папки и файлы, однако это не требуется и может привести к
нежелательным результатам. Изменения прав для родительской
папки достаточно для предотвращения неавторизованного
доступа ко всему её содержимому.
Гораздо более эффективным подходом к вопросу будет изменение
глобальных полномочий по умолчанию на создание пользовательских
домашних каталогов для adduser. Просто откройте файл /etc/adduser.conf и
измените переменную DIR_MODE на что-нибудь подходящее, и на все новые
домашние каталоги будут устанавливаться корректные права доступа.
DIR_MODE=0750
• После изменения прав доступа к папке с использованием любого из
ранее показанных способов, проверьте результат, используя следующий
синтаксис:
ls -ld /home/username
Результаты ниже показывают, что полномочия на чтение для всех были
удалены:
drwxr-x---
2 username username
4096 2007-10-02 20:03 username
1.4. Политики паролей
Хорошая политика паролей - это один из наиболее важных аспектов
состояния безопасности. Для многих успешных взломов против слабых
паролей использовался простой брутфорс и перебор по словарю. Если вы
планируете предоставить любой вид удалённого доступа с использованием
локальной системы паролей, убедитесь, что вы в достаточной мере
обдумали требования к минимально сложности пароля, максимальному
сроку его жизни и частоте аудита ваших систем аутентификации.
1.4.1. Минимальная длина пароля
По умолчанию Ubuntu требует минимальную длину пароля в 6 символов,
также выполняет некоторые базовые проверки энтропии. Эти параметры
управляются файлом /etc/pam.d/common-password и приведены ниже:
password
[success=2 default=ignore]
pam_unix.so obscure sha512
Если вы хотите установить минимальную длину в 8 символов, измените
соответствующую переменную на min=8. Изменения приведены ниже:
175
Защита
password
[success=2 default=ignore]
pam_unix.so obscure sha512 min=8
Базовые проверки на качество (энтропию) и минимальную длину
пароля не применяются к администратору, использующему команды
уровня sudo для настройки нового пользователя.
1.4.2. Истечение срока действия пароля
При создании пользовательских учётных записей вам следует сделать
политику минимального и максимального срока действия пароля,
принуждая пользователей менять их пароли при истечении срока.
• Чтобы просмотреть текущее состояние пользовательской учётной записи,
используйте следующий синтаксис:
sudo chage -l username
Листинг ниже демонстрирует интересные факты о пользовательской
учётной записи, а именно, что не применены никакие политики:
Последнее изменение пароля: 20 января 2008 года
Действие пароля заканчивается: никогда
Пароль становится неактивным: никогда
Действие аккаунта заканчивается: никогда
Изменение пароля возможно, если прошло не менее (указывается количество дней): 0
Изменение пароля возможно, если прошло не более (указывается количество дней): 99999
Количество дней, за которое высвечиватся предупреждение об истечении действия пароля: 7
• Чтобы установить любой из этих параметров, просто воспользуйтесь
следующей командой и следуйте указаниям:
sudo chage username
Ниже показан пример того, как вы можете вручную изменить дату
завершения действия пароля (-E) на 01/31/2008, минимальное время
действия пароля (-m) 5 дней, максимальное время действия 90 дней,
период бездействия (-l) 5 дней по окончанию срока действия пароля и
период предупреждения (-W) на 14 дней до завершения действия пароля.
sudo chage -E 01/31/2011 -m 5 -M 90 -I 30 -W 14 username
• Чтобы проверить изменения, воспользуйтесь способом, применявшимся
ранее:
sudo chage -l username
Листинг ниже показывает новые политики, установленные для учётной
записи:
176
Защита
Последнее изменение пароля: 20 января 2008 года
Действие пароля заканчивается: 19 апреля 2008 года
Пароль становится неактивным: 19 мая 2008 года
Действие аккаунта заканчивается: 31 января 2008 года
Изменение пароля возможно, если прошло не менее (указывается количество дней): 5
Изменение пароля возможно, если прошло не более (указывается количество дней): 90
Количество дней, за которое высвечивается предупреждение об истечении действия пароля: 14
1.5. Иные предложения по безопасности
Многие приложения используют собственные механизмы аутентификации,
которые могут быть не замечены даже опытными системными
администраторами. Поэтому важно понимать и контролировать, как
пользователи проходят аутентификацию и получают доступ к сервисам и
приложениям на вашем сервере.
1.5.1. Доступ отключенных пользователей по SSH
Простое отключение или блокирование пользовательской учётной
записи не помешает пользователю войти на ваш сервер удалённо, если
предварительно они установили аутентификацию по открытому ключу
RSA. У них всё ещё будет возможность получить скрытый доступ к серверу
без потребности в каком бы то ни было пароле. Не забудьте проверить
домашний каталог пользователя на файлы, которые разрешают данный
вид аутентичного доступа по SSH, как например /home/username/.ssh/
authorized_keys.
Удалите или переименуйте каталог .ssh/ в пользовательском домашнем
каталоге, чтобы предотвратить дальнейшее использование возможностей
аутентификации по SSH.
Обязательно проверьте наличие любых SSH соединений, установленных
отключенными пользователями, так как возможно, что они могут иметь
существующее входящее или исходящее подключение. Закройте их, если
таковые имеются.
Разрешайте доступ по SSH только тем учётным записям пользователей,
которым он нужен. Например, вы можете создать группу "sshlogin"
и добавить её в переменную, связанную с переменной AllowGroups,
расположенной в файле /etc/ssh/sshd_config.
AllowGroups sshlogin
Затем добавьте пользователей, которым разрешён доступ по SSH, в группу
"sshlogin" и перезапустите сервис SSH.
177
Защита
sudo adduser username sshlogin
sudo service ssh restart
1.5.2. Аутентификация базы данных сторонних пользователей
Большинство корпоративных сетей требуют централизованную
аутентификацию и контроль доступа ко всем системным ресурсам. Если
вы настроили ваш сервер на аутентификацию пользователей с помощью
внешних баз данных, убедитесь, что вы отключили пользовательские
учётные записи для удалённого и локального использования. Так вы
удостоверитесь, что невозможен локальных обход аутентификации.
178
Защита
2. Безопасность консоли
Как и в случае с любым другим барьером безопасности, который вы
выстраиваете для защиты вашего сервера, требуется довольно жёстко
защититься от невообразимого ущерба, который может возникнуть от
физического доступа кого-то лица к вашему оборудованию, например,
воровства жёстких дисков, сбоя по питанию, отказа в обслуживании и т.п.
Поэтому безопасность консоли стоит рассматривать просто как ещё один
компонент вашей общей стратегии физической безопасности. Блокируемая
"ширма" (screen door) может защитить от случайного криминала и очень
сильно замедлить активное воздействие, поэтому очень желательно
соблюдать простейшие предосторожности по отношению к безопасности
консоли.
Нижеприведенные инструкции помогут вам обезопасить сервер от таких
событий, которые в ином случае могли бы вызвать серьёзные последствия.
2.1. Отключение Ctrl+Alt+Delete
Прежде всего, любой, кто имеет доступ к клавиатуре, просто может
нажать комбинацию Ctrl+Alt+Delete для перезагрузки сервера и без
необходимости входить в систему. Конечно, можно просто отключить шнур
питания, но отключение этой команды на рабочем сервере по-прежнему
необходимо. Это заставит злоумышленника предпринимать более
радикальные меры по перезагрузке сервера, и в тоже время предотвратит
случайные перезагрузки.
• Для отключения перезагрузки по нажатию комбинации Ctrl+Alt+Delete
закомментируйте следующую строку в файле /etc/init/control-alt-
delete.conf.
#exec shutdown -r now "Control-Alt-Delete pressed"
179
Защита
3. Брандмауэр
3.1. Введение
Ядро Linux включает подсистему Netfilter, которая используется для
регулирования сетевого траффика, входящего на или проходящего через
вашу систему. Все современные средства межсетевой защиты Linux
используют эту систему для фильтрации пакетов.
Система фильтрации пакетов ядра была бы малопригодной для
администраторов без пользовательского интерфейса управления ею.
Для этого предназначено приложение iptables. Когда пакет достигает
вашего сервера, он передаётся подсистеме Netfilter для приёма, обработки
или отклонения, в зависимости от правил, передаваемых ей из рабочего
пространства пользователя с помощью iptables. Таким образом, если вы
хорошо знакомы с iptables - это всё, что вам необходимо для управления
межсетевым экраном. Однако существует множество программ,
предоставляющих интерфейс для упрощения этой задачи.
3.2. ufw - Uncomplicated Firewall
По умолчанию, программой для настройки брандмауэра в Ubuntu
является приложение ufw. Разработанное для облегчения настройки
iptables, приложение ufw предоставляет дружелюбный пользователю
способ по созданию брандмауэра для адресов в формате IPv4 или IPv6,
устанавливаемый на машину пользователя.
Приложение ufw по умолчанию отключено. Выдержка из man-страницы ufw:
«Приложение ufw не может предоставить полной функциональности
брандмауэра через свой интерфейс командной строки, однако, такое
приложение предлагает лёгкий способ добавления или удаления
несложных правил. В основном, такое приложение используется для
создания брандмауэра, устанавливаемого на компьютере пользователя.»
Ниже идут примеры по использованию приложения ufw:
• Сначала необходимо активировать ufw. Введите в терминале:
sudo ufw enable
• Для того, чтобы открыть порт (в нашем примере - ssh), введите:
sudo ufw allow 22
180
Защита
• Также правила могут быть добавлены в числовом формате:
sudo ufw insert 1 allow 80
• Похожим образом, чтобы закрыть порт, введите:
sudo ufw deny 22
• Чтобы удалить правило, введите delete и, далее, удаляемое правило:
sudo ufw delete deny 22
• Также возможно разрешить доступ с определённых узлов или сетей на
конкретный порт. Нижеследующий пример позволяет доступ к порту ssh
с узла 192.168.0.2 на любой IP-адрес на данном компьютере:
sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Замените 192.168.0.2 на 192.168.0.0/24, чтобы разрешить доступ к порту
ssh из целой подсети.
• Указание опции --dry-run у команды ufw, приведёт к выводу
результирующих правил без их применения. Например, следующее будет
применено, если открыт порт HTTP:
sudo ufw --dry-run allow http
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
### ПРАВИЛА ###
### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0
-A ufw-user-input -p tcp --dport 80 -j ACCEPT
### ОКОНЧАНИЕ ПРАВИЛ ###
-A ufw-user-input -j RETURN
-A ufw-user-output -j RETURN
-A ufw-user-forward -j RETURN
-A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT]: "
-A ufw-user-limit -j REJECT
-A ufw-user-limit-accept -j ACCEPT
COMMIT
Правила изменены
• Можно отключить приложение ufw, для этого введите:
181
Защита
sudo ufw disable
• Введите для просмотра статуса брандмауэра:
sudo ufw status
• Для более детального отображения статуса введите следующую
команду:
sudo ufw status verbose
• Для просмотра числового формата:
sudo ufw status numbered
Если порт, который вы хотите открыть или закрыть, определён в
файле /etc/services, вы можете использовать имя порта вместо его
номера. Для этого в приведённых выше примерах можно заменить
число 22 на ssh.
Это краткое введение в использование ufw. Пожалуйста, обратитесь к
справочной странице программы ufw для более подробной информации.
3.2.1. Интеграция приложений с ufw
Приложения, открывающие порты, могут включать ufw профиль, который
определяет порты, необходимые для корректной работы приложения. Эти
профили содержатся в /etc/ufw/applications.d и могут быть изменены, если
были изменены порты «по умолчанию».
• Для просмотра списка приложений с установленными профилями введите
в терминале следующую команду:
sudo ufw app list
• Аналогично, чтобы разрешить трафик через порт с помощью профиля
приложения, введите:
sudo ufw allow Samba
• Также доступен расширенный синтаксис:
ufw allow from 192.168.0.0/24 to any app Samba
Замените Samba и 192.168.0.0/24 профилем используемого вами
приложения и адресом вашей сети соответственно.
182
Защита
Нет необходимости указывать протокол для приложения, т.к.
эта информация уже содержится в профиле. Также, обратите
внимание, что имя приложения - app - заменяет номер порта.
• Для просмотра деталей по портам, протоколам и т.д. для приложения,
введите:
sudo ufw app info Samba
Не для всех приложений, которые требуют открытие сетевого порта,
поставляется профиль ufw, но если у вас есть профиль для приложения,
и вы хотите чтобы этот файл был включен в пакет приложения,
зарегистрируйте ошибку о пакете на сайте Launchpad.
ubuntu-bug имя_пакета
3.3. IP маскировка
Назначение IP маскировки в том, чтобы позволить машинам в вашей сети с
частными, не маршрутизируемыми IP-адресами, иметь доступ в Интернет
через машину, осуществляющую маскировку. Трафик из вашей сети,
предназначенный для Интернета, должен быть обработан так, чтобы
ответы могли вернуться обратно на машину, которая организовала запрос.
Чтобы это сделать, ядро должно изменить IP-адрес источника в каждом
пакете так, чтобы ответы возвращались на сервер, а не на частный IP-адрес
(что невозможно в Интернете), с которого сделан запрос. Linux использует
Connection Tracking (conntrack) для хранения записи о том, каким машинам
принадлежат соединения, и перенаправляет каждый возвращенный пакет
соответствующим образом. Таким образом, трафик, покидающий вашу сеть,
"замаскирован", как будто исходит от машины, которая выполняет роль
шлюза. В документации Microsoft этот процесс упоминается как технология
Internet Connection Sharing.
3.3.1. Маскарадинг ufw
Маскарадинг IP может быть реализован использованием пользовательских
правил ufw. Это возможно благодаря тому, что текущий бэк-энд для ufw
- это iptables-restore с файлами правил, хранящихся в /etc/ufw/*.rules. Эти
файлы - замечательный способ добавить родные правила iptables без
участия ufw, и эти правила больше ориентированы на шлюз или мост сети.
Правила разделены на два файла: те, которые должны быть выполнены
до правил командной строки ufw, и те, которые выполняются после правил
командной строки ufw .
183
Защита
• В начале, перенаправление пакетов должно быть включено в ufw. Для
этого необходимо настроить два конфигурационных файла: в /etc/default/
ufw измените DEFAULT_FORWARD_POLICY на «ACCEPT»:
DEFAULT_FORWARD_POLICY="ACCEPT"
После этого отредактируйте /etc/ufw/sysctl.conf и раскомментируйте:
net/ipv4/ip_forward=1
Аналогично, для форвардинга IPv6, раскомментируйте
net/ipv6/conf/default/forwarding=1
• Теперь мы добавим правила в файл /etc/ufw/before.rules. Правила по
умолчанию задают только таблицу фильтрации, а для включения
маскарадинга должна быть отредактирована таблица nat. Добавьте
нижеследующее в начало файла, сразу после комментариев в заголовке:
# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT
Комментарии не обязательны, но считается хорошей практикой
документировать свою конфигурацию. При этом, редактируя любой файл
правил в /etc/ufw, убедитесь, что эти строки являются последними во всех
изменённых таблицах:
# не удаляйте строку "COMMIT", иначе эти правила не будут обрабатываться
COMMIT
Для каждой таблицы требуется соответствующий оператор правила
COMMIT. В этих примерах показаны только таблицы nat и filter, но вы
можете точно так же добавить правила для таблиц raw и mangle.
В приведённом примере замените eth0, eth1 и 192.168.0.0/24 на
подходящие для вашей сети интерфейсы и диапазон IP.
• Наконец, отключите и заново включите ufw для того, чтобы изменения
вступили в силу:
184
Защита
sudo ufw disable && sudo ufw enable
Маскарадинг IP должен быть включён. Также вы можете добавить
дополнительные правила FORWARD в /etc/ufw/before.rules. Рекомендуется
добавлять эти правила в цепочку ufw-before-forward.
3.3.2. Маскарадинг iptables
iptables также может быть использован для маскировки соединений.
• Аналогично случаю с ufw, первым шагом будет включение
перенаправления пакетов IPv4. Для этого отредактируйте /etc/sysctl.conf
и раскомментируйте следующую строчку
net.ipv4.ip_forward=1
Если вы хотите включить и перенаправление IPv6, раскомментируйте:
net.ipv6.conf.default.forwarding=1
• Затем выполните команду sysctl для включения новых настроек в
конфигурационном файле:
sudo sysctl -p
• Маскарадинг IP теперь может быть завершён одним правилом iptables,
которое может слегка отличаться, в зависимости от конфигурации вашей
сети:
sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE
Команда вверху предполагает, что ваш внутрисетевой диапазон адресов
- 192.168.0.0/16, а интерфейс, смотрящий в Интернет - ppp0. Синтаксис
выглядит следующим образом:
• -t nat - правило для обращения к таблице NAT
• -A POSTROUTING - правило, добавляемое (-A) к цепочке POSTROUTING
• -s 192.168.0.0/16 - правило применяется для трафика, происходящего
из обозначенного адресного пространства
• -o ppp0 - правило применяется к трафику, который планируется
направить через определенное сетевое устройство
• -j MASQUERADE - трафик, попадающий под данное правило, должен
быть перенаправлен "jump" (-j) с маскировкой (MASQUERADE) для
обработки, как описано выше
185
содержание ..
1
2
3 .. |
||
|
|
|