Самоучитель по SQL-сервер в Linux
         

Шифрование сеанса

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

В то же время шифрование обмена данными стало вполне обыденным явлением. На всех солидных коммерческих сайтах пересылка конфиденциальных данных (номера кредитной карты, домашнего адреса) защищается при помощи протокола SLL (Secure Sockets Layer).

Самый распространенный тип компьютерных преступлений вообще не связан со «взломом». Многие беспечные пользователи доверяют пересылку информации по Интернету таким протоколам, как POP и FTP. При этом пользователь может непреднамеренно передать свое имя и пароль в текстовом (не зашифрованном) виде.

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



Удаленное подключение к PostgreSQL без шифрования данных открывает потенциальные возможности для злоупотреблений. Если хакер установит сниффер в вашей сети или в сети между клиентом и сервером, к которому вы подключаетесь, он сможет получить полный доступ ко всей информации, хранящейся в PostgreSQL.

В этом разделе мы рассмотрим три общих способа шифрования данных между PostgreSQL и клиентом.

  • Встроенная поддержка SSL. Поддержка SSL в PostgreSQL активизируется при компиляции с ключом --with-ssl. Это позволяет psql (или любому клиенту, написанному с учетом возможности подключения к PostgreSQL через SSL) установить защищенное подключение к PostgreSQL.
  • SSH/OpenSSH. Сеанс SSH (Secure SHell) позволяет создать туннель (tunnel) к удаленному серверу — при условии, что демон SSH (например, sshd) установлен в системе и доступен для подключающегося пользователя. Для этого в системе, в которой работает PostgreSQL, создается учетная запись для каждого пользователя.
  • Stunnel. Приложение Stunnel создает шифрованный туннель для обмена данными между клиентом и сервером PostgreSQL. Для пользователей, не имеющих прямого доступа к удаленному серверу, Stunnel можно настроить на работу в клиентской системе.

Встроенная поддержка SSL

В PostgreSQL предусмотрена возможность активизации встроенной поддержки SSL при помощи ключа конфигурации - -with-ssl. Этот вариант особенно удобен в тех случаях, когда для работы с PostgreSQL вы собираетесь в основном использовать psql, потому что в этом клиенте предусмотрена внутренняя поддержка подобного способа подключения.

Большинство пользователей предпочитает работать с PostgreSQL при помощи всевозможных клиентских приложений. В этом случае вам придется либо самостоятельно написать клиента, поддерживающего SSL-подключение к PostgreSQL, либо выбрать внешнюю схему шифрования сеансов между клиентом/приложением и сервером PostgreSQL (например, SSH или Stunnel).

SSH/OpenSSH

OpenSSH является превосходным средством внешнего шифрования обмена данными между клиентом и сервером. Профессионалы в области безопасности и системные администраторы фактически приняли OpenSSH как стандарт в области шифрования. Чаще всего OpenSSH используется в терминальных приложениях или в программах пересылки файлов. Протокол SSH обеспечивает обобщенный механизм шифрования, применимый практически в любой области.

Имея доступ к системной учетной записи на удаленном сервере, можно пройти аутентификацию и открыть туннель между удаленным и локальным хостами с ключом -L. Туннель прослушивает заданный порт локального компьютера, шифрует поступающие пакеты данных и отправляет их на удаленный сервер в зашифрованном виде. Там данные расшифровываются и передаются на указанный порт удаленного сервера.

Подобная схема позволяет легко создать обобщенный туннель для обмена шифрованными данными между клиентом и сервером. Более того, весь процесс остается прозрачным для системы PostgreSQL, полагающей, что пакетные входные данные поступают с локального компьютера от пользователя, создавшего туннель. Обратите внимание на это обстоятельство, поскольку оно требует внесения соответствующих изменений в файл pg_hba.conf.

Исполняемый файл SSH обычно называется ssh, а туннель создается командой следующего вида:

ssh -L лок_порт:уддл_хост:удал_порт пользователь@удал_хост

Параметрлок_порт содержит произвольный номер порта, по которому организуется локальное прослушивание. Номер порта должен быть больше 1024 (если команда не выполняется с правами root, чего делать не рекомендуется). Заданное число определяет тот номер порта, по которому, как полагает ваш клиент, он подключен к PostgreSQL. В действительности данные, передаваемые через этот порт, попадают на порт прослушивания SSH (обычно порт 22) удаленного хоста, расшифровываются и затем передаются на заданный порт удаленного хоста.

Секция полъзователь@удал_хост необходима для аутентификации системных пользователей. Без действительной учетной записи на удаленном хосте создать туннель SSH не удастся. Весь процесс создания туннеля продемонстрирован в листинге 8.14, в котором два терминальных сеанса разделены многоточием. Первое терминальное подключение создает туннель SSH и остается активным, чтобы туннель продолжал существование. Второе терминальное подключение использует туннель для установки связи с локальным портом и последующей пересылки данных на удаленный хост, их расшифровки и передачи серверу PostgreSQL.

Листинг 8.14. Создание туннеля SSH на сервере PostgreSQL

[user@local ~]$ ssh -L 4001:remotehost:5432 userPremotehost

user@remotehost's password: [user@remote -]$

[user@local -]$ psql -h localhost -p 4001 tempiatel

Welcome to psql, the PostgreSQL Interactive terminal.

Type: \copyright for distribution terms

\h for help with SQL commands

\? for help on internal slash commands

\g or terminate with semicolon to execute query

\q to quit

tempiatel=#

ПРИМЕЧАНИЕ

Если после создания туннеля SSH вам не нужно переходить в режим командной строки, как это происходит по умолчанию, включите в команду ssh ключ -Т. В этом случае после аутентификации терминал перестает реагировать на действия пользователя. После завершения сеанс прерывается комбинацией клавиш Ctrl+C.

Единственный недостаток механизма туннелей SSH заключается в том, что он требует наличия системной учетной записи для пользователя, подключающегося к PostgreSQL. SSH не предоставляет абсолютно прозрачного доступа к шифрованным потокам данных до тех пор, пока пользователь не инициирует соединение и не пройдет аутентификацию у демона ssh, обычно называемого sshd. В зависимости от ситуации это ограничение может приносить как пользу, так и вред.

Тем, кто захочет создать туннель шифрования данных еще более общего характера, стоит рассмотреть возможность использования пакета Stunnel.

Настройка и использование пакета Stunnel

Хотя встроенная поддержка SSL и OpenSSH обеспечивают надежный, хорошо защищенный обмен данными с PostgreSQL, у этих инструментов имеются свои особенности и недостатки. Многие пользователи PostgreSQL интересуются, существует ли другой способ шифрования с полностью прозрачным удаленным доступом к серверу. Если вы хотите обеспечить прозрачное шифрование сеанса для любого клиента, без обязательной привязки к SSH, в вашем распоряжении два общедоступных средства: OpenSSL и Stunnel.

Системные администраторы Unix и Linux обычно знакомы с одним или обоими пакетами, поскольку они часто используются в других областях (в конце концов, шифрование применяется не только в контексте PostgreSQL). А если вы еще не сталкивались с шифрованием обмена данными, с этой проблемой стоит познакомиться поближе.

OpenSSL

Программный пакет OpenSSL был разработан группой, входящей в сообщество Open Source. Это довольно мощный инструментарий, позволяющий реализовать в системе протокол SSL (Secure Sockets Layer) и другие протоколы, применяемые в области безопасности данных — например, TLS (Transport Layer Security). Кроме того, в OpenSSL входит библиотека криптографических функций. Этот пакет пригодится всем, кто уделяет внимание проблемам безопасности системы Linux (его область применения не ограничивается PostgreSQL, хотя ниже основное внимание будет уделяться именно этому аспекту). Пакет распространяется с открытыми исходными текстами, поэтому вы сможете загрузить его бесплатно, тогда как коммерческие пакеты SSL потребуют расходов на приобретение и/или лицензирование.

За последней версией OpenSSL обратитесь на web-страницу OpenSSL по адресу http://www.openssl.org. Здесь вы найдете список существующих версий со ссылками для загрузки. Существует две разновидности версий: рабочие и бета-версии. Также имеются ссылки на более старые версии с исправленными ошибками. Вероятно, вас заинтересует последняя рабочая версия или подобная версия с исправленными ошибками.

Рабочие версии выглядят в списке примерно так:

09-Jul-2001: OpenSSL 0.9.6b is now available, a major release

Откройте страницу по ссылке available. На ней можно загрузить новейшую версию OpenSSL, помеченную словом [LATEST].

Загрузите файл выбранной версии и сохраните его в домашнем каталоге (или другом каталоге, в котором вы обычно сохраняете файлы). После завершения пересылки откройте консольное окно и перейдите в этот каталог командой cd. Файл запакован и заархивирован, поэтому его необходимо извлечь следующей командой (поле [версия]заменяется номером версии продукта — например, 0.0.6b):

gzip -d openssl-<f версияj.tar.gz

Затем введите следующую команду:

tar xf openssl-/"версия.?.tar

Эти команды распаковывают файлы OpenSSL в каталог с именем openssl-[версия], где [версия] — номер версии продукта.

ПРИМЕЧАНИЕ

Если вы используете GNU-версию tar, вместо отдельных команд gzip и tar достаточно ввести команду tar -xzf openssl -[версия].tar.gz.

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

  • утилита gmake (или make);
  • Perl версии 5 и выше;
  • компилятор ANSI С;
  • среда разработки (библиотеки разработки, заголовочные файлы С);
  • поддерживаемая Unix-совместимая операционная система.

Если у вас имеется все необходимое, можно переходить к компиляции. В противном случае перед установкой OpenSSL придется загрузить и установить недостающие продукты.

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

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

    2. $ ,/config

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

    3. $ make

  3. После завершения компиляции запустите тест (команда проверяет, успешно ли прошла компиляция; при обнаружении ошибок обращайтесь к файлу INSTALL):

    4. $ make test

  4. Если тестирование прошло успешно, установите двоичные файлы OpenSSL:

    $ make install

На этом установка OpenSSL завершается. Если у вас возникнут проблемы, обращайтесь к документации (а именно к файлам INSTALL и README).

Stunnel

Stunnel представляет собой оболочку SSL, то есть позволяет наделить поддержкой SSL демона, не рассчитанного на безопасный обмен данными. При помощи Stunnel можно установить защищенный канал связи с базой данных PostgreSQL, улучшить общую безопасность системы и защитить данные.

Пакет Stunnel распространяется с сайта http://www.stunnel.org. Перейдите по этому адресу, откройте страницу загрузки и щелкните на ссылке Get the source code. Начнется загрузка последней версии пакета. Сохраните файл в домашнем или любом другом каталоге файловой системы. Завершив загрузку Stunnel, откройте консольное окно и перейдите в каталог с принятым файлом. Распакуйте файл следующими командами:

$ gzip -d stunnel-[версия].tar.gz $ tar xf stunnel-[версия].tar

Файлы Stunnel распаковываются в каталог с именем st\mne\-[версия], где [версия] — номер версии продукта. К счастью, установка Stunnel обычно проходит быстрее, чем установка OpenSSL. После распаковки файлов перейдите в созданный каталог с помощью команды cd. Помните, что пакет OpenSSL должен быть уже установлен в системе, без него установка Stunnel не работает. Процедура построения и установки Stunnel описана ниже.

  1. Запустите сценарий конфигурации, который собирает информацию о системе и производит настройку установочных сценариев Stunnel:

    2. $ ./configure

  2. Откомпилируйте исходные тексты Stunnel следующей командой make, которая создает исполняемые файлы по исходным текстам Stunnel. В процессе компиляции вам будет предложено ввести сведения о местонахождении и имени домена. Введенные данные используются для построения файла stunnel.pern. В этом файле хранится сертификат, при помощи которого шифруются данные.

    3. $ make

  3. Если компиляция прошла успешно, установите двоичные файлы OpenSSL следующей командой, которая устанавливает откомпилированные файлы:

    $ make install

Запуск Stunnel

Существует два варианта работы Stunnel в системе: использование inetd или запуск двоичного файла Stunnel в режиме демона. Второй вариант считается пред-лочтительным, поскольку использование inetd накладывает на работу пакета некоторые ограничения, связанные с особенностями SSL, в том числе:

  • для каждого подключения необходимо инициализировать Stunnel демоном inetd;
  • кэширование сеанса невозможно;
  • использование inetd сопровождается порождением новых процессов, что требует дополнительных затрат процессорного времени.

Пакет Stunnel позволяет устанавливать защищенные подключения как к удаленным, так и к локальным базам данных. Если клиент psql обращается к базе данных, обслуживаемой другим хостом, создается защищенный канал обмена данными между psql и этой базой данных. Если база данных находится на одном компьютере с клиентом psql, можно создать защищенный канал обмена данными между двумя локальными программами (на случай, если вы опасаетесь прослушивания локальных подключений через сокеты TCP/IP).

В каталоге Stunnel должен находиться файл с именем stunnel; это исполняемый файл программы. Далее предполагается, что исполняемый файл хранится в этом каталоге, однако вы можете скопировать его в каталог /usr/local/sbin или любой другой каталог по своему усмотрению. Кроме того, ссылку на этот файл можно включить в стартовый сценарий, чтобы он автоматически запускался (в виде одного или двух процессов по вашему выбору) во время загрузки системы.

ПРИМЕЧАНИЕ

Если Stunnel используется с inetd, запускать файл в стартовом сценарии не нужно.

Запуск Stunnel в режиме демона

Запуск Stunnel в режиме демона не вызывает проблем при подключении как к локальным, так и к удаленным базам данных. Чтобы использовать Stunnel для подключения к локальной базе данных, следует запустить пакет в режиме клиента и сервера (два разных процесса одной программы, работающих на разных портах). Затем вы приказываете psql подключиться к номеру порта, на котором работает клиентская часть Stunnel.

После того как psql подключится к клиенту, все данные автоматически шифруются и передаются серверу Stunnel, работающему на другом порте, номер которого сообщается клиенту при запуске. Сервер расшифровывает данные и пересылает их серверу PostgreSQL. Клиент должен знать свой номер порта, а также номер порта, на котором работает сервер, чтобы передать ему зашифрованные данные.

Впрочем, Stunnel чаще применяется для передачи данных от локального клиента удаленному серверу. Для этого следует запустить локальный клиентский процесс Stunnel либо включением в стартовый сценарий (например, /etc/rc.d/rc.local), либо непосредственным запуском из каталога. Затем удаленный процесс Stunnel запускается на хосте, на котором работает PostgreSQL. Сервер, как и клиент, обычно запускается автоматически в процессе загрузки системы.

Примеры запуска клиентской и серверной частей Stunnel приведены в листинге 8.15. Если исполняемый файл stunnel не был скопирован в каталог /usr/sbin, Stunnel следует запускать из каталога установки.

Листинг 8.15. Использование Stunnel при удаленных подключениях

[user@remote -]$ # Запуск сервера на удаленном компьютере

[user@remote -]$ stunnel -P/tmp/ -p -/stunnel.pern -d 9000 -г local host:5432

[user@local -]$ # Запуск клиента на локальном компьютере

[user@local -]$ stunnel -P/tmp/ -c -d 5432 -г 192.168.1.2:9000

Первая команда в листинге 8.15 приказывает серверу использовать в качестве сертификата для шифрования файл ~/stunnel.pem и запустить процесс Stunnel в режиме демона. Параметр -d 9000 означает, что демон должен прослушивать порт 9000. Параметр - г 1 оса! host: 5432 сообщает процессу-демону, что при получении зашифрованных данных на прослушиваемом порте (в данном примере — 9000) эти данные необходимо расшифровать и передать локальному хосту на порт 5432 (номер порта PostgreSQL). Таким образом, расшифрованные данные будут переданы серверу базы данных на локальном хосте.

Вторая команда запускает экземпляр Stunnel на клиентском компьютере в режиме клиента (на что указывает ключ -с) с прослушиванием порта 5432. Параметр -г 192.168.1.2:9000 сообщает процессу, что сервер работает по адресу 192.168.1.2:9000 и прослушивает зашифрованные пакеты на порте 9000.

В обоих режимах обязательный ключ -P/tmp/ сообщает путь к временному файлу PID, в котором хранится системный идентификатор процесса Stunnel. Указывать имя файла не обязательно, достаточно пути (по умолчанию используется имя вида stunnel.localhost.9000.pid), хотя при желании можно задать полное имя.

После того как оба процесса Stunnel заработают на своих хостах, клиент psql направляется на порт 5432 клиентского компьютера. Пакеты, отправляемые на этот порт, проходят прозрачное шифрование, перенаправляются на порт 9000 серверного компьютера, расшифровываются и передаются PostgreSQL на порт 5432. Происходящее напоминает туннели SSH, о которых говорилось в подразделе «SSH/ OpenSSH», но между ними существует одно важное различие: клиентский процесс Stunnel может создаваться без аутентификации на удаленном сервере. Таким образом, любой пользователь может создать защищенного «отправителя» на сервере базы данных, хотя при этом все равно потребуется создать защищенного «получателя», принимающего зашифрованные данные.

Шифрование полностью отделено от обычной процедуры аутентификации PostgreSQL; с точки зрения серверного процесса postmaster данные поступают в текстовом виде, поскольку они проходят предварительную расшифровку. Stunnel идеально работает в сочетании с парольной аутентификацией — пароли обеспечивают необходимое ограничение доступа и пересылаются по сети в зашифрованном виде.

Кроме того, как упоминалось выше, локальный запуск двух процессов Stunnel позволяет шифровать пакеты, передаваемые между двумя локальными портами TCP/IP. В листинге 8.16 приведен пример запуска клиентского и серверного процессов на одном компьютере.

Листинг 8.16. Локальный запуск Stunnel

[user@local -]$ stunnel -P/tmp/ -p -/stunnel-3.15/stunnel.pern -d 9000 -r 5432

[user@local -]$ stunnel -P/tmp/ -c -d 5433 -r local host:9000

Первая команда запускает серверный процесс, использующий файл сертификата ~/stunnel-3.15/stunnel.pem. Демон прослушивает подключения на порте 9000 и передает расшифрованные данные с этого порта на порт 5432. В примере использован номер 5432, потому что сервер PostgreSQL работает на этом порте.

Вторая команда запуска Stunnel в листинге 8.16 открывает клиентский процесс Stunnel на порте 5433 (порт выбирается произвольно; в данном примере он напоминает номер порта PostgreSQL). Демон шифрует входящие данные и передает их серверному процессу на порт 9000 локального хоста.

Запуск 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.


Содержание раздела