17.7. Защита от подмены сервера #

Когда сервер работает, злонамеренный пользователь не может подставить свой сервер вместо него. Однако если сервер отключён, локальный пользователь может подменить нормальный сервер, запустив свой собственный. Поддельный сервер сможет читать пароли и запросы клиентов, хотя не сможет вернуть никакие данные, так как каталог PGDATA будет защищён от чтения посторонними пользователями. Такая подмена возможна потому, что любой пользователь может запустить сервер баз данных; клиент, со своей стороны, не может обнаружить подмену, если его не настроить дополнительно.

Один из способов предотвратить подмену для локальных подключений — использовать каталог Unix-сокетов (unix_socket_directories), в который сможет писать только проверенный локальный пользователь. Это не позволит злонамеренному пользователю создать в этом каталоге свой файл сокета. Если вас беспокоит, что некоторые приложения при этом могут обращаться к файлу сокета в /tmp и, таким образом, всё же будут уязвимыми, создайте при загрузке операционной системы символическую ссылку /tmp/.s.PGSQL.5432, указывающую на перемещённый файл сокета. Возможно, вам также придётся изменить скрипт очистки /tmp, чтобы он не удалял эту ссылку.

Также клиенты могут защитить локальные подключения, установив в параметре requirepeer имя пользователя, который должен владеть серверным процессом, подключённым к сокету.

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

Для защиты от подмены соединения с SSL сервер надо настроить так, чтобы он принимал только подключения hostssl (см. Раздел 19.1) и имел ключ и сертификаты SSL (см. Раздел 17.9). Тогда TCP-клиент должен будет подключаться к серверу с параметром sslmode=verify-ca или verify-full и у него должен быть установлен соответствующий корневой сертификат (см. Подраздел 33.19.1). Как вариант, можно применять системный пул ЦС с помощью sslrootcert=system. В этом случае для безопасности принудительно применяется режим sslmode=verify-full, так как получение сертификатов, подписываемых публичным ЦС, является обычной практикой.

Для защиты от подмены соединения с сервером во время использования сетевой аутентификации по паролю с методом scram-sha-256 следует удостовериться, что подключение к серверу происходит по SSL-протоколу и с одним из методов, защищающих от подмены соединения, которые описаны в предыдущем абзаце. Кроме того, реализация SCRAM в libpq не защищает на протяжении всего процесса обмена информацией при аутентификации, однако использование параметра соединения channel_binding=require позволяет минимизировать вероятность подмены соединения. Злоумышленник, использующий подставной сервер для перехвата данных при обмене по SCRAM, может прибегнуть к офлайн-анализу, чтобы попытаться определить хешированный пароль клиента.

Для защиты от подмены соединения с GSSAPI сервер надо настроить так, чтобы он принимал только подключения hostgssenc (см. Раздел 19.1) и для них использовалась аутентификация gss. TCP-клиент в этом случае должен подключаться с параметром gssencmode=require.