PostgreSQL
Source: https://severalnines.com/database-blog/how-secure-your-postgresql-database-10-tips
The following default configuration settings should be changed in your installation of PostgreSQL.
The following default configuration settings should be changed in your installation of PostgreSQL.
1) Allow only the access and privileges that you need.
Installing PostgreSQL will generate a file called
pg_hba.conf which governs which IP addresses can connect to the database. Each line is an authentication rule, and PostgreSQL will trust or reject the addresses matching the given rule. This file is read top to bottom, so adding the following line to the very bottom of the file (with each value separated by ↹ TAB indents) will disallow connections unless a defined trust rule is met:host all all 0.0.0.0/0 reject2) Only allow necessary connections.
PostgreSQL listens for connections from the addresses specified in the
postgresql.conf configuration file, by the parameter listen_addresses. This value should default to 'localhost', which is secure. If additional machines need to access the PostgreSQL database, such as other members of a cluster, insert their addresses here separated by commas. Never set listen_addresses to '*' unless you intend to allow remote connection from any machine.listen_addresses = 'localhost'3) Change the port from the default value.
In the
postgresql.conf configuration file, the default port parameter of 5432 should be changed to a different port. Otherwise, attackers that know the database infrastructure will know exactly which points of access to target.4) Restrict SUPERUSER access to localhost.
Add the following rule near the top of the
pg_hba.conf file to restrict access by superusers to the same machine as the PostgreSQL server. Use ↹ TAB indents.host all super 127.0.0.1/32 trust5) Require SSL for client connections.
PostgreSQL sends both queries and data in plaintext by default. Enabling SSL (Secure Sockets Layer) on your PostgreSQL machine secures the transaction to prevent man-in-the-middle attacks. To enable SSL in PostgreSQL, OpenSSL must be installed on the system at build time. If this is the case, the
ssl parameter must then be enabled in the postgresql.conf configuration file:ssl=onPostgreSQL will now read from the system-wide configuration file for OpenSSL called
openssl.cnf. For more information on configuring SSL and securing TCP/IP connections, see the official documentation:6) Consider pgcrypto module to salt hashes.
If an attacker accesses a list of usernames and passwords in your database, they can use the credentials to target and exploit your individual users. To this end, passwords are encrypted. Encrypting passwords disguises the plaintext value as an unreadable value called a hash. This is typically done using a single key that converts each plaintext password into a hash, sort of like a cipher.
Disguising passwords in this way is highly deterministic. For example, if two users have the same password, their hashed passwords will also be the same. To this end, a little bit of extra, randomly-generated data can be added to each hashed password to make the encryption harder to crack. This practice is called salting hashes. PostgreSQL does not salt hashes out of the box, but it does offer a module with this functionality called
pgcrypto.To install this tool, use the PostgreSQL shell to connect to the database with the data you would like to encrypt. Then, create the extension.
\c my_database;
CREATE EXTENSION IF NOT EXISTS "pgcrypto";7) Consider pgaudit module for comprehensive logging.
The default logging functionality of PostgreSQL is controlled by the
log_statement parameter in the postgresql.conf configuration file. Even when this parameter is set to all, it only lists the operations that are performed against the database. A comprehensive audit should also include the changes made to the database during each session. A module called pgaudit offers this functionality. To install the module on a Linux machine, follow the instructions on its GitHub page: