Аутентификация и шифрование
Запуск Stunnel с использованием inetd
Если вы предпочитаете, чтобы на серверной стороне экземпляры Stunnel запускались по запросу, вместо режима демона можно воспользоваться службой inetd (или xinetd в новых системах). Как упоминалось выше, это может привести к снижению быстродействия. Но если вы готовы смириться с этим, задача решается относительно легко. Сначала нужно отредактировать файл /etc/services и добавить в него строку для серверного процесса. Достаточно строки следующего вида:
pgssl 9000/tcp # Оболочка stunnel для PostgreSQL
В зависимости от того, какая служба используется в вашей системе, inetd или xinetd, следует либо включить новую службу в файл /etc/inetd.conf, либо создать новый файл службы в каталоге /etc/xinetd.d/. В том и другом случае требуется ввести полную команду (со всеми аргументами, передаваемыми программе). Команда должна иметь следующий формат:
stunnel – P/tmp/ – р путь!stunnel.pern – г порт
В этой команде путь означает каталог, в котором находится файл сертификата (первоначально он находится в каталоге, в котором был откомпилирован пакет Stunnel), а порт – порт, по которому прослушивает PostgreSQL (обычно порт 5432). Главное различие в синтаксисе вызова stunnel при помощи службы inetd и в режиме демона заключается в том, что в первом случае ключ – d не указывается.
В листинге 8.17 показано, как выглядит примерная запись в файле inetd.conf. Запись должна полностью помещаться в одной строке. Конечно, в этой записи необходимо указать каталог с файлом сертификата, используемый в вашей системе, причем этот каталог должен быть доступен для чтения пользователем, указанным в файле inetd.conf. Строка /usr/bln/stunnel содержит полный путь к двоичному файлу Stunnel.
Листинг 8.17. Примерная запись inetd.
pgssl stream tcp nowait root /usr/sbin/stunnel – P/tmp/ – p /root/my.pern – r 5432
В листинге 8.17 указан пользователь root, но по соображениям безопасности лучше задать пользователя, обладающего меньшими правами. Для незарезервированных портов может быть указан любой пользователь, имеющий право доступа для чтения к файлу сертификата и право исполнения для двоичного файла stunnel.
Примерная конфигурация для xinetd приведена в листинге 8.18. В системах, использующих xinetd, эти данные будут храниться в файле /etc/xinetd.d/pgssl. Также следует проверить, что каталог, указанный после ключа – р, соответствует фактическому расположению файла сертификата. Как и в случае с inetd, запускать stunnel с правами root не рекомендуется.
Листинг 8.18. Примерная запись xinetd.
# Конфигурация xinetd для pgssl.
service pgssl
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/stunnel
server_args = – P/tmp/ – p /root/stunnel.pern – r 5432
}
После настройки конфигурации inetd или xinetd следует перезапустить соответствующую службу (в системах Red Hat это обычно делается командой service):
root@host – ]# service xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] [root(?host – ]#
Если команда service недоступна, того же результата обычно можно добиться при помощи команды killall с параметрами – HUP и именем процесса, например:
kill all – HUP xinetd
Внимание
Проследите за тем, чтобы файл сертификата был доступен для чтения только со стороны пользователя, запустившего серверный процесс stunnel.
Выводы
После завершения всех описанных действий вы сможете установить защищенное подключение к базе данных PostgreSQL из любого клиента PostgreSQL. В psql можно воспользоваться следующей командой:
psql – р порт – h хост – и пользователь база_данных
Сначала указывается номер порта, по которому ведет прослушивание клиент Stunnel, затем хост (localhost в данном случае), имя пользователя и база данных, к которой вы хотите подключиться. В результате клиент подключается к базе данных точно так же, как если бы она была открыта в psql локально.
Примечание
Чтобы процесс postmaster взаимодействовал с Stunnel, он должен быть запущен с ключом – i. Ключ – i активизирует поддержку TCP/IP, необходимую для работы Stunnel.