While the server is running, it is not possible for a malicious user to take the place of the normal database server. However, when the server is down, it is possible for a local user to spoof the normal server by starting their own server. The spoof server could read passwords and queries sent by clients, but could not return any data because the <varname>PGDATA</varname> directory would still be secure because of directory permissions. Spoofing is possible because any user can start a database server; a client cannot identify an invalid server unless it is specially configured. サーバが稼働中、悪意のあるユーザが通常のデータベースサーバに取って代わることはできません。 しかし、サーバが停止している時、ローカルユーザに対し、独自のサーバを起動させることで正常なサーバになりすますことは可能です。 なりすましたサーバで、クライアントから送信されたパスワードを読み取ることも問い合わせを読み取ることも可能です。 しかし、PGDATAディレクトリの安全性はディレクトリの権限により維持されていますので、データを返すことはできません。 誰もがデータベースサーバを起動させることができるため、なりすましは可能です。 特殊な設定がなされていなければ、クライアントは無効なサーバであることを識別できません。

One way to prevent spoofing of <literal>local</literal> connections is to use a Unix domain socket directory (<xref linkend="guc-unix-socket-directories"/>) that has write permission only for a trusted local user. This prevents a malicious user from creating their own socket file in that directory. If you are concerned that some applications might still reference <filename>/tmp</filename> for the socket file and hence be vulnerable to spoofing, during operating system startup create a symbolic link <filename>/tmp/.s.PGSQL.5432</filename> that points to the relocated socket file. You also might need to modify your <filename>/tmp</filename> cleanup script to prevent removal of the symbolic link. local接続に対してなりすましを防ぐ、ひとつの方法は、信頼できるローカルユーザのみに書き込み権限を付与したUnixドメインソケットディレクトリ（unix_socket_directories）を使用することです。 これにより、悪意のあるユーザがそのディレクトリに独自のソケットを作成することを防ぐことができます。 一部のアプリケーションがソケットファイルのために/tmpを参照し、なりすましに対して脆弱であるかもしれないと気にするならば、オペレーティングシステムの起動時に、再割り当てされたソケットファイルを指し示す/tmp/.s.PGSQL.5432というシンボリックリンクを作成してください。 また、このシンボリックリンクが削除されることを防ぐために、/tmpを整理するスクリプトを変更する必要があるかもしれません。

Another option for <literal>local</literal> connections is for clients to use <link linkend="libpq-connect-requirepeer"><literal>requirepeer</literal></link> to specify the required owner of the server process connected to the socket. local接続についての別の選択肢は、クライアントがrequirepeerを使用して、ソケットに接続しているサーバプロセスの必要な所有者を指定することです。

To prevent spoofing on TCP connections, either use SSL certificates and make sure that clients check the server's certificate, or use GSSAPI encryption (or both, if they're on separate connections). TCP接続のなりすましを防ぐためには、SSL証明書を使用してクライアントにサーバの証明書を確実に検査させるか、GSSAPI暗号化を使用します。 （あるいはそれらが別々の接続上にあるなら、その両方を使います。）

To prevent spoofing with SSL, the server must be configured to accept only <literal>hostssl</literal> connections (<xref linkend="auth-pg-hba-conf"/>) and have SSL key and certificate files (<xref linkend="ssl-tcp"/>). The TCP client must connect using <literal>sslmode=verify-ca</literal> or <literal>verify-full</literal> and have the appropriate root certificate file installed (<xref linkend="libq-ssl-certificates"/>). Alternatively the system CA pool can be used using <literal>sslrootcert=system</literal>; in this case, <literal>sslmode=verify-full</literal> is forced for safety, since it is generally trivial to obtain certificates which are signed by a public CA. SSLでなりすましを防ぐためには、サーバはhostssl接続（20.1）のみを受け付け、SSLキーと証明書ファイル（18.9）を持つ必要があります。 TCPクライアントはsslmode=verify-caもしくはverify-fullを使用して接続し、また、適切なルート証明書ファイルをインストールしなければなりません（32.19.1）。 あるいは、sslrootcert=systemを使用してシステムCAプールを使用できます。この場合、sslmode=verify-fullが安全のために強制されます。これは、一般的に公開CAによって署名された証明書を取得するのが簡単なためです。

To prevent server spoofing from occurring when using <link linkend="auth-password">scram-sha-256</link> password authentication over a network, you should ensure that you connect to the server using SSL and with one of the anti-spoofing methods described in the previous paragraph. Additionally, the SCRAM implementation in <application>libpq</application> cannot protect the entire authentication exchange, but using the <literal>channel_binding=require</literal> connection parameter provides a mitigation against server spoofing. An attacker that uses a rogue server to intercept a SCRAM exchange can use offline analysis to potentially determine the hashed password from the client. ネットワーク経由でscram-sha-256パスワード認証を使用する場合にサーバのなりすましが発生しないようにするには、SSLを使用してサーバに接続し、前の段落で説明したなりすまし防止方法の1つを使用する必要があります。 さらに、libpqのSCRAM実装は認証情報の交換全体を保護できませんが、channel_binding=require接続パラメータを使用すると、サーバのなりすましに対する防御が提供されます。 不正なサーバを使用してSCRAM交換を傍受する攻撃者は、オフライン分析を使用して、クライアントからのハッシュ化されたパスワードを判断できる可能性があります。

To prevent spoofing with GSSAPI, the server must be configured to accept only <literal>hostgssenc</literal> connections (<xref linkend="auth-pg-hba-conf"/>) and use <literal>gss</literal> authentication with them. The TCP client must connect using <literal>gssencmode=require</literal>. GSSAPIでなりすましを防ぐためには、サーバはhostgssenc接続（20.1）のみを受け付け、gss認証をその接続で使います。 TCPクライアントはgssencmode=requireを使用して接続しなければなりません。