begriffs open source - ai-pg/blob - full-docs/txt/preventing-server-spoofing.txt

   1
   2 18.7. Preventing Server Spoofing #
   3
   4    While the server is running, it is not possible for a malicious user to
   5    take the place of the normal database server. However, when the server
   6    is down, it is possible for a local user to spoof the normal server by
   7    starting their own server. The spoof server could read passwords and
   8    queries sent by clients, but could not return any data because the
   9    PGDATA directory would still be secure because of directory
  10    permissions. Spoofing is possible because any user can start a database
  11    server; a client cannot identify an invalid server unless it is
  12    specially configured.
  13
  14    One way to prevent spoofing of local connections is to use a Unix
  15    domain socket directory (unix_socket_directories) that has write
  16    permission only for a trusted local user. This prevents a malicious
  17    user from creating their own socket file in that directory. If you are
  18    concerned that some applications might still reference /tmp for the
  19    socket file and hence be vulnerable to spoofing, during operating
  20    system startup create a symbolic link /tmp/.s.PGSQL.5432 that points to
  21    the relocated socket file. You also might need to modify your /tmp
  22    cleanup script to prevent removal of the symbolic link.
  23
  24    Another option for local connections is for clients to use requirepeer
  25    to specify the required owner of the server process connected to the
  26    socket.
  27
  28    To prevent spoofing on TCP connections, either use SSL certificates and
  29    make sure that clients check the server's certificate, or use GSSAPI
  30    encryption (or both, if they're on separate connections).
  31
  32    To prevent spoofing with SSL, the server must be configured to accept
  33    only hostssl connections (Section 20.1) and have SSL key and
  34    certificate files (Section 18.9). The TCP client must connect using
  35    sslmode=verify-ca or verify-full and have the appropriate root
  36    certificate file installed (Section 32.19.1). Alternatively the system
  37    CA pool, as defined by the SSL implementation, can be used using
  38    sslrootcert=system; in this case, sslmode=verify-full is forced for
  39    safety, since it is generally trivial to obtain certificates which are
  40    signed by a public CA.
  41
  42    To prevent server spoofing from occurring when using scram-sha-256
  43    password authentication over a network, you should ensure that you
  44    connect to the server using SSL and with one of the anti-spoofing
  45    methods described in the previous paragraph. Additionally, the SCRAM
  46    implementation in libpq cannot protect the entire authentication
  47    exchange, but using the channel_binding=require connection parameter
  48    provides a mitigation against server spoofing. An attacker that uses a
  49    rogue server to intercept a SCRAM exchange can use offline analysis to
  50    potentially determine the hashed password from the client.
  51
  52    To prevent spoofing with GSSAPI, the server must be configured to
  53    accept only hostgssenc connections (Section 20.1) and use gss
  54    authentication with them. The TCP client must connect using
  55    gssencmode=require.