CYBERTEC PostgreSQL Logo

Enhanced security: Logging PostgreSQL connections

08.2024 / Category: / Tags:

Logging connections in PostgreSQL can be incredibly valuable for monitoring and troubleshooting purposes. However,  that’s not all: auditing is also an important aspect which should be taken into account. Being able to trace and track activity is therefore vital to ensuring security, compliance, and more. This information can help identify potential security risks, such as unauthorized access or suspicious activity, allowing you to take swift action to mitigate threats.

Using log_connections in PostgreSQL

To achieve this in PostgreSQL, we can make use of a simple configuration variable:

By default, this configuration variable is set to “off”. However, turning this feature on can give us some really important details into the activity of your PostgreSQL database server. 

The purpose of this variable is to instruct the servers to add additional information to the log file and provide us with some valuable insights. In PostgreSQL 17, the output we can expect consists of three log entries, which are as follows:

The first entry tells us a bit more about the connect string. In my case, I tried to connect to a database called “postgres” through a local UNIX socket. The “host” entry confirms that. 

However, the second line is even more important. Consider the following output:

This information helps us uncover what the authentication process is up to. First, we see which user is trying to connect. In my case, it is my local user called “hs”. The next piece of information indicates that PostgreSQL was configured to use “trust”. In other words, no password had to be supplied. What is really important here is that we can also see which line in which configuration file is responsible for this decision, making it really easy to debug. In this case, it is line 117 in pg_hba.conf to blame. 

If you have access to the filesystem, debugging your security system is much easier when you use log_connections. It is such a tiny feature, but it really adds value to security and allows you to detect leaks or mis-configurations more easily.

In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Facebook or LinkedIn.

5 1 vote
Article Rating
Subscribe
Notify of
guest
2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Gus Spier
1 month ago

I'm sure this is very useful, but what is the cost in terms of performance, disk space, memory, and CPU?

Laurenz Albe
20 days ago
Reply to  Gus Spier

The performance cost depends on how many connections you establish. The burden on the CPU and memory should be negligible. The biggest problem could be disk space.

But if you want a performant database application, you will use connection pooling anyway. Then the number of connections created and ended should be low, and the overhead of logging those few connections won't be a problem.

CYBERTEC Logo white
CYBERTEC PostgreSQL International GmbH
Römerstraße 19
2752 Wöllersdorf
Austria

+43 (0) 2622 93022-0
office@cybertec.at

Get the newest PostgreSQL Info & Tools


    This site is protected by reCAPTCHA and the Google Privacy Policy & Terms of Service apply.

    ©
    2024
    CYBERTEC PostgreSQL International GmbH
    phone-handsetmagnifiercrosscross-circle
    linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram