0% found this document useful (0 votes)
14 views21 pages

How To Secure PostgreSQL Against Automated Attacks - DigitalOcean

Uploaded by

auladacivil
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views21 pages

How To Secure PostgreSQL Against Automated Attacks - DigitalOcean

Uploaded by

auladacivil
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

CONTENTS

Background
Prerequisites
Understanding the Default Configuration
Configuring Remote Connections
Step 1 — Adding a User and Database
Step 2 — Configuring UFW
Step 3 — Configuring the Allowed Hosts
Step 4 — Configuring the Listening Address

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 1/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Step 5 — Restarting PostgreSQL


Step 6 — Testing
Step 7 — Removing the Test Database and User
Additional Security Considerations
Conclusion

// TUTORIAL //

How To Secure PostgreSQL Against Automated Attacks

Published on January 24, 2017

Security Ubuntu PostgreSQL Ubuntu 16.04

Melissa Anderson

Introduction

It can be tempting to think because a server has just recently been brought up, sees
little traffic, or offers nothing that seems of value to hackers that it will go unnoticed.
However, many exploits are automated and specifically designed to look for common
errors in configuration. These programs scan networks to discover servers, independent
of the nature of the content.
https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 2/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Allowing remote connections is one of the common and more easily rectified situations
that can lead to the exploit of a PostgreSQL database. This happens because certain
configurations make it easy for programs like these to discover the server.
In this tutorial, we will show how to mitigate the specific risk posed by allowing remote
connections. While this is an important first step, since servers can be compromised in
other ways, we also recommend that you take additional measures to protect your data,
outlined in the Additional Security Considerations.

Background

To understand the specific risk we’re mitigating, imagine the server as a store. If the
server is listening on any port at all, it’s a little like turning on a neon “Open” sign. It
makes the server itself visible on the network, where automated scripts can find it.
We can think of each port as way to enter the store, like a door or a window. These
entrances may be open, closed, locked, or broken depending on the state of the
software that’s listening, but listening on a public interface means that a script seeking to
get inside can start trying. For example, the script might be configured to attempt to log
in with a default password on the chance that it hasn’t been changed. It might attempt
known exploits of the listening daemon in case it hasn’t been patched. Whatever the
script tries, if it is able to find a weakness and exploit it, then the intruder is inside and
can get down to the serious business of compromising the server.
When we restrict a daemon like postgresql to listening locally, it’s like that particular
door to the outside doesn’t exist. There’s no next step to try, at least with respect to
Postgres. Firewalls and VPNs protect in a similar way. In this tutorial, we’ll focus on
removing PostgreSQL as a publicly accessible doorway. To secure the daemon itself or
the data as it is transmitted or stored, see Additional Security Considerations.

Prerequisites

In this tutorial, we’ll use two Ubuntu installations, one for the database host and one as
the client that will be connecting to the host remotely. Each one should have a sudo user
and the firewall enabled. The guide, Initial Server Setup with Ubuntu 16.04 can help you
with this.
One Ubuntu 16.04 PostgreSQL Database Host:
If you haven’t install PostgreSQL yet, you can do so with the following commands:

Copy

host$ sudo apt-get update


https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 3/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

host$ sudo apt-get install postgresql postgresql-contrib

One Ubuntu 16.04 Client Machine: In order to demonstrate and test allowing remote
connections, we’ll use the PostgreSQL client, psql . To install it, use the following
commands:

Copy

client$ sudo apt-get update


client$ sudo apt-get install postgresql-client

When these prerequisites are in place, you’re ready to follow along.

Understanding the Default Configuration

When PostgreSQL is installed from the Ubuntu packages, by default it is restricted to


listening on localhost. This default can be changed by overriding the listen_addresses in
the postgresql.conf file, but the default prevents the server from automatically listening
on a public interface.
In addition, the pg_hba.conf file only allows connections from Unix/Linux domain sockets
and the local loopback address for the server, so it wouldn’t accept connections from
external hosts:

replace

# Put your actual configuration here


# ----------------------------------
#
# If you want to allow non-local connections, you need to add more
# "host" records. In that case you will also need to make PostgreSQL
# listen on a non-local interface via the listen_addresses
# configuration parameter, or via the -i or -h command line switches.

# DO NOT DISABLE!
# If you change this first entry you will need to make sure that the
# database superuser can access the database using some other method.
# Noninteractive access to all databases is required during automatic
# maintenance (custom daily cronjobs, replication, and similar tasks).
#
# Database administrative login by Unix domain socket
local all postgres peer

# TYPE DATABASE USER ADDRESS METHOD

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 4/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

# "local" is for Unix domain socket connections only


local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

These defaults meet the objective of not listening on a public interface. If we leave them
intact and keep our firewall up, we’re done! We can proceed directly to the Additional
Security Considerations to learn how to secure data in transit.
If you need to connect from a remote host, we’ll cover how to override the defaults as
well as the immediate steps you can take to protect the server in the next section.

Configuring Remote Connections

For a production setup and before we start working with sensitive data, ideally we’ll have
PostgreSQL traffic encrypted with SSL in transit, secured behind an external firewall, or
protected by a virtual private network (VPN). As we work toward that, we can take the
somewhat less complicated step of enabling a firewall on our database server and
restricting access to the hosts that need it.

Step 1 — Adding a User and Database

We’ll begin by adding a user and database that will allow us to test our work. To do so,
we’ll use the PostgreSQL client, psql , to connect as the administrative user postgres . By
passing the -i option to sudo we’ll run the postgres user’s login shell, which ensures
that we load options from the .profile or other login-specific resources. -u species the
postgres user:

Copy

host$ sudo -i -u postgres psql

Next, we’ll create a user with a password. Be sure to use secure password in place of
the example highlighted below:

Copy

postgres=# CREATE USER sammy WITH PASSWORD ' password ';

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 5/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

When the user is successfully created, we should receive the following output:

Output
CREATE ROLE

Note: Since PostgreSQL 8.1, ROLES and USERS are synonymous. By convention, a role
that has a password is still called a USER, while a role that does not is called a ROLE, so
sometimes we will see ROLE in output where we might expect to see USER.

Next, we’ll create a database and grant full access to our new user. Best practices
recommend that we grant users only the access that they need and only on the
resources where they should have them, so depending on the use case, it may be
appropriate to restrict a user’s access even more. You can learn more about permissions
in the guide How To Use Roles and Manage Grant Permissions in PostgreSQL on a VPS.

Copy

postgres=# CREATE DATABASE sammydb OWNER sammy ;

When the database is created successfully, we should receive confirmation:

Output
CREATE DATABASE

Now, that we’ve created a user and database, we’ll exit the monitor

Copy

postgres=# \q

After pressing ENTER, we’ll be at the command prompt and ready to continue.

Step 2 — Configuring UFW

In the Initial Server Setup with Ubuntu 16.04 prerequisite, we enabled UFW and only
allowed SSH connections. Before we start our configuration, let’s verify UFW’s status:

Copy
https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 6/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

host$ sudo ufw status

Note: If the output indicates that the firewall is inactive we can activate it with:

Copy

host$ sudo ufw enable

Once it’s enabled, rerunning the status command, sudo ufw status will show the current
rules. If necessary, be sure to allow SSH.

Copy

host$ sudo ufw allow OpenSSH

<$>
Unless we made changes to the prerequisites, the output should show that only
OpenSSH is allowed:

Output

Status: active

To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)

Now that we’ve checked the firewall status, we will allow access to the PostgreSQL port
and restrict it to the host or hosts we want to allow.
The command below will add the rule for the PostgreSQL default port, which is 5432. If
you’ve changed that port, be sure to update it in the command below. Make sure that
you’ve used the IP address of the server that needs access. If need be, re-run this
command to add each client IP address that needs access:

Copy

host$ sudo ufw allow from client_ip_address to any port 5432

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 7/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

To double-check the rule, we can run ufw status again:

Copy

host$ sudo ufw status

Output
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
5432 ALLOW client_ip_address
OpenSSH (v6) ALLOW Anywhere (v6)

<$>[note] Note: If you’re new to UFW, you can learn more in the guide UFW Essentials:
Common Firewall Rules and Commands.

With this firewall rule in place, we’ll now configure PostgreSQL to listen on its public IP
address. This requires a combination of two settings, an entry for the connecting host in
pg_hba.conf and configuration of the listen_addresses in postgresql.conf .

Step 3 — Configuring the Allowed Hosts

We’ll start by adding the host entry in pg_hba.conf . If you have a different version of
PostgreSQL installed, be sure to substitute it in the path below:

Copy

host$ sudo nano /etc/postgresql/ 9.5 /main/pg_hba.conf

We’ll place the host lines under the comment block that describes how to allow non-
local connections. We’ll also include a line with the public address of the database
server so we can quickly test that our firewall is configured correctly. Be sure to
substitute the hostname or IP address of your machines in the example below.

Excerpt from pg_hba.conf

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 8/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

# If you want to allow non-local connections, you need to add more


# "host" records. In that case you will also need to make PostgreSQL
# listen on a non-local interface via the listen_addresses
# configuration parameter, or via the -i or -h command line switches.
host sammydb sammy client_ip_address /32 md5

Before we save our changes, let’s focus on each of the values in this line in case you
want to change some of the options:
host The first parameter, host , establishes that a TCP/IP connection will be used.
database sammydb The second column indicates which database/s the host can
connect to. More than one database can be added by separating the names with
commas.
user sammy indicates the user that is allowed to make the connection. As with the
database column, multiple users can be specified, separated by commas.
address The address specifies the client machine address or addresses and may
contain a hostname, IP address range or other special key words. In the example
above, we’ve allowed just the single IP address of our client.
auth-method Finally, the auth-method, md5 indicates a double-MD5-hashed
password will be supplied for authentication. You’ll need to do nothing more than
supply the password that was created for the user connecting.

For a more complete discussion of these and additional settings, see The pg_hba.conf
File PostgreSQL documentation.
Once you’re done, save and exit the file.

Step 4 — Configuring the Listening Address

Next we’ll set the listen address in the postgresql.conf file:

Copy

host$ sudo nano /etc/postgresql/ 9.5 /main/postgresql.conf

Find the listen_addresses line and below it, define your listen addresses, being sure to
substitute the hostname or IP address of your database host. You may want to double-
check that you’re using the public IP of the database server, not the connecting client:

postgresql.conf

P d
https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 9/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean
Products
#listen_addresses = 'localhost' # what IP address(es) to listen on;
Solutions
listen_addresses = 'localhost, server_ip_address '

Developers
When you’re done save and exit the file.
Partners
Step 5 — Restarting PostgreSQL
Pricing
Our configuration changes won’t take effect until we restart the PostgreSQL daemon, so
we’ll do that before we test:
Log in Sign up
Copy

host$ sudo systemctl restart postgresql Blog

Docs
Since systemctl doesn’t provide feedback, we’ll check the status to make sure the
daemon restarted successfully:
Get Support
Copy
Contact Sales
host$ sudo systemctl status postgresql

Tutorials Questions Product Docs Search Community


If the output contains “Active: active” and ends with something like the following, then
the PostgreSQL daemon is running.

Output
...
Jan 10 23:02:20 PostgreSQL systemd[1]: Started PostgreSQL RDBMS.

Now that we’ve restarted the daemon, we’re ready to test.

Step 6 — Testing

Finally, let’s test that we can connect from our client machine. To do this, we’ll use psql
with -U to specify the user, -h to specify the client’s IP address, and -d to specify the
database, since we’ve tightened our security so that the sammy can only connect to a
single database.

Copy
https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 10/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

client$ psql -U sammy -h postgres_host_ip -d sammydb

If everything is configured correctly, you should receive the following prompt:

Output
Password for user sammy:

Enter the password you set earlier when you added the user sammy in the PostgreSQL
monitor.
If you arrive at the following prompt, you’re successfully connected:

[secondary_label]
sammydb=>

This confirms that we can get through the firewall and connect to the database. We’ll
exit now:

Copy

sammydb=&gt; \q

Since we’ve confirmed our configuration, we’ll finish by cleaning up.

Step 7 — Removing the Test Database and User

Back on the host once we’ve finished testing the connection, we can use the following
commands to delete the database and the user as well.

Copy

host$ sudo -i -u postgres psql

To delete the database:

Copy

postgres=# DROP DATABASE sammydb ;


https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 11/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

The action is confirmed by the following output:

Output
DROP DATABASE

To delete the user:

Copy

postgres=# DROP USER sammy ;

The success is confirmed by:

Output
DROP ROLE

We’ll finish our cleanup by removing the host entry for the sammydb database from
pg_hba.conf file since we no longer need it:

Copy

$ sudo nano /etc/postgresql/ 9.5 /main/pg_hba.conf

Line to remove from `pg_hba.conf`

host sammydb sammy client_ip_address /32 md5

For the change to take effect, we’ll save and exit, then restart the database server:

Copy

$ sudo systemctl restart postgresl

To be sure it restarted successfully, we’ll check the status:

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 12/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Copy

$ sudo systemctl status postgres

If we see “Active: active” we’ll know the restart succeeded.


At this point, we can move forward with configuring the application or service on the
client that needs to connect remotely.

Additional Security Considerations

This tutorial is intended to mitigate the risks posed by allowing unsecured remote
connections to PostgreSQL, which is a common situation that inadvertently exposes
PostgreSQL to exploits. Limiting access to the listening port to specific host/s doesn’t
address other significant security considerations, such as how to encrypt your data in
transit.
Before working with real data, we recommend reviewing the following resources and
taking the appropriate steps for your use case.
Security within PostgreSQL: GRANT statements determine which users are allowed
to access any particular database, while Roles establish the privileges of those
users. In combination, they provide separation between multiple databases in a
single installation.
Setting up SSL with PostgreSQL: Configuring SSL will encrypt data in transit. This
protects data as it is sent.
Securing PostgreSQL TCP/IP Connections with SSH Tunnels: SSH Tunnels are
useful when connecting with clients that are not SSL-capable. In almost any other
situation, it is preferable to set up SSL with Postgres.

Conclusion

In this tutorial, we’ve taken essential steps to prevent advertising our PostgreSQL
installation by configuring the server’s firewall to allow connections only from hosts that
require access and by configuring PostgreSQL to accept connections only from those
hosts. This mitigates the risk of certain kinds of attacks. This is just the first step to
securing data, and we recommend that review and implement additional security
measures outlined above.

Thanks for learning with the DigitalOcean Community. Check out our offerings
for compute, storage, networking, and managed databases.

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 13/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Learn more about our products ->

About the authors

Melissa Anderson Author

Still looking for an answer? Ask a question

Search for more help

Was this helpful? Yes No

Comments

2 Comments

Leave a comment...

This textbox defaults to using Markdown to format your answer.


You can type !ref in this text area to quickly search our full set of tutorials,
documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Comment

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 14/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

jdogg • September 14, 2018


Thank you so much! This is a wonderful tutorial, very helpful and necessary.

Reply

Robert Arellano • August 20, 2018


Great post! It is one of the few well-documented posts I found on how to set up
Postgres on a remote database server. I would suggest two minor
modifications.
1. The title should also include something regarding “Setting up Postgres on
a remote server”. I think the post does a great job at identifying how to
secure Postgres but people may also find it useful as a guide on how to
set up Postgres on a remote server like I did.
2. I created a server through AWS. AWS’ default security policies do not
include an inbound connection to port 5432. Someone might find it useful
if this is mentioned. Make sure to open a connection to port 5432 through
a security policy in the AWS EC2 console.

Thanks for posting!

Reply

This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 4.0


International License.

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!
https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 15/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Sign up

Popular Topics

AI/ML
Ubuntu
Linux Basics
JavaScript
Python
MySQL
Docker
Kubernetes

All tutorials ->

Talk to an expert ->

Congratulations on unlocking the whale ambience easter

egg!

Click the whale button in the bottom left of your screen to toggle some ambient whale
noises while you read.

Reset easter egg to be discovered again


Permanently dismiss and hide easter egg

Thank you to the Glacier Bay National Park & Preserve and Merrick079 for the sounds
behind this easter egg.

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 16/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Interested in whales, protecting them, and their connection to helping prevent climate
change? We recommend checking out the Whale and Dolphin Conservation.

Become a contributor for community

Get paid to write technical tutorials and select a tech-focused charity to receive
a matching donation.

Sign Up

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 17/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

DigitalOcean Documentation

Full documentation for every DigitalOcean product.

Learn more

Resources for startups and SMBs

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 18/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

The Wave has everything you need to know about building a business, from
raising funding to marketing your product.

Learn more

Get our newsletter

Stay up to date by signing up for DigitalOcean’s Infrastructure as a


Newsletter.

Email address Submit

New accounts only. By submitting your email you agree to our Privacy Policy

The developer cloud


Scale up as you grow — whether you're running one
virtual machine or ten thousand.

View all products

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 19/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Get started for free


Sign up and get $200 in credit for your first 60 days
with DigitalOcean.*

Get started

*This promotional offer applies to new accounts only.

Company

Products

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 20/21
03/12/2024, 20:05 How To Secure PostgreSQL Against Automated Attacks | DigitalOcean

Resources

Solutions

Contact

© 2024 DigitalOcean, LLC. Sitemap.

https://www.digitalocean.com/community/tutorials/how-to-secure-postgresql-against-automated-attacks 21/21

You might also like