Ubuntu дээр Postgresql гаднаас хандалттай болгож PGAdmin-аар холбогдох

Эрх авах

1. Login as postgres user using su / sudo command, enter:

   su - postgres

OR

Get root permission

   sudo su

postgresql тохиргоо 1

2. Edit the file:

   vim /etc/postgresql/[version_number]/main/postgresql.conf

Find configuration line that read as follows:

   listen_addresses='localhost'

Дээрх мөрийг комэнт аут хийгээд доорхыг оронд нь нэмнэ. Энэ нь бүх хаягнаас хандах боломжийг нээнэ:

   listen_addresses='*'

OR

Болж өгвөл * биш яг хандах IP хаягнуудаа таслалаар зааглан оруулах нь дээр

   listen_addresses = '10.10.1.105,127.0.0.1,localhost'

postgresql тохиргоо 2

3. Edit the file:

   vim /etc/postgresql/[version_number]/main/pg_hba.conf

Append the following configuration lines to give access to 10.10.1.0/24 network:

   host database user 10.10.1.0/24 md5

database, user хоёрын оронд "хандах баазын нэр" ба "хэрэглэгчийн нэрийг" оруулна. Бас энэ host гэсэн тохиргоо нь plain холболт тул секюрити эрсдэлтэй тул SSL тохируулах хэрэгтэй. Эхний ээлжинд туршиж холбож үзээд доор байгаа заавраар SSL тохируулаарай. Тэгээд host > hostssl гэж солих хэрэгтэй.

postgresql дахин ачааллах

4. Ингээд postgresql дээрх тохиргоо болно.

   systemctl restart postgresql

Firewall дээр порт нээх

5. ufw дээр порт нээж өгөх.

   ufw allow 5432

OR

   ufw allow from 10.10.1.0/24 to any port 5432

OR

   ufw allow from 10.10.1.105 to any port 5432

Аль болох IP зааж өгвөл аюулгүй байдлын хувьд илүү. Мөн түр нээгээд хаах бол:

   ufw status numbered

тушаалаар харж байгаад урд талын дугаараар нь жишээ нь 5 дахь дүрмийг устгах бол:

   ufw delete 5

гэх мэт буцааж арилгана.

Ингээд хандах боломжтой болно.

pgAdmin 4-с хандах

6. pgAdmin 4-с хандахдаа:

Servers баруун дараа Register > Server...

Нээгдсэн цонхонд Name дээр ямар нэгэн нэр оруулаад Connection tab дээр тохиргоо хийнэ:

• Hostname
• Port
• Username
• Password

утгуудыг тохируулаад холбогдоход холбогдох ёстой.

postgresql SSL тохируулах

7. SSL тохируулах

Эх сурвалж: https://www.percona.com/blog/enabling-and-enforcing-ssl-tls-for-postgresql-connections/

Enabling SSL in PostgreSQL is very straightforward. In just three steps we can make sure the connections to it are more secure, using in-transit encryption via SSL/TLS:

1. Make sure we have the server certificate and key files available 2. Enable the SSL configuration (ssl = on) 3. Make sure the pg_hba.conf file rules are updated accordingly

In this blog post, we are going to go through these steps, and we’ll also see how we can check and validate the connections are indeed using the safer SSL protocol. What is SSL/TLS?

SSL (Secure Sockets Layer) is an encryption protocol designed to make network communications between two nodes secure. Without some form of network encryption, any third party that can examine network packets will have access to the data sent between the client and server (in this case, the PostgreSQL data, which means users, passwords, and even SQL statements). TLS (Transport Layer Security) is the more modern definition of it, and even if SSL is deprecated, it is still common to use it for naming purposes. To all intents and purposes, we are using them as aliases in this blog.

The PostgreSQL documentation pages offer us some more insight in this respect. If needed, consult the Secure TCP/IP Connections with SSL and SSL Support entries for more information. Trying to enable SSL without Cert/Key Files

Let’s now see what happens when we try to enable SSL without having the needed certificate and key files in place:

postgres=# alter system set ssl=on;
ALTER SYSTEM
postgres=# select pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

We don’t see any errors, but are we really using SSL? If we check the error log, we’ll indeed see the errors:

2022-06-23 20:43:54.713 UTC [5284] LOG:  received SIGHUP, reloading configuration files
2022-06-23 20:43:54.714 UTC [5284] LOG:  parameter "ssl" changed to "on"
2022-06-23 20:43:54.715 UTC [5284] LOG:  could not load server certificate file "server.crt": No such file or directory
2022-06-23 20:43:54.715 UTC [5284] LOG:  SSL configuration was not reloaded

Creating certificates

So, we first need to create the aforementioned files. If you don’t already have valid certificate and key files, a quick one-liner for this is the following openssl command (it’s not the focus here to delve too much into this part of the process):

[root@node0 ~]# cd /etc/ssl/private/
[root@node0 data]# openssl req -nodes -new -x509 -keyout server.key -out server.crt -subj '/C=US/L=NYC/O=Woovoo/CN=postgres'
Generating a 2048 bit RSA private key
....+++
.........................+++
writing new private key to 'server.key'
-----

We have changed the current working directory to the PostgreSQL data directory. If you are on a Debian-based one, you should store the files in /etc/ssl/certs/ and /etc/ssl/private/ or define/check ssl_cert_file and ssl_key_file PostgreSQL configuration variables, respectively. Also, make sure the postgres user owns them, and they are only readable to it:

Permission тохируулах

[root@node0 data]# chmod 400 server.{crt,key}
[root@node0 data]# chown postgres:postgres server.{crt,key}
[root@node0 data]# ll server.{crt,key}
-r--------. 1 postgres postgres 1212 Jun 23 20:49 server.crt
-r--------. 1 postgres postgres 1704 Jun 23 20:49 server.key
</pre.

==== Enabling SSL/TLS ==== 

Now we can enable SSL and reload the configuration again; this time with no errors shown:

<pre>
postgres=# alter system set ssl=on;
ALTER SYSTEM
postgres=# select pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

​​2022-06-23 20:52:05.823 UTC [5284] LOG:  received SIGHUP, reloading configuration files
2022-06-23 20:52:05.823 UTC [5284] LOG:  parameter "ssl" changed to "on"

So far, we have enabled SSL, but unless we modify the pg_hba.conf file these settings won’t apply to any users (at least not in a forceful manner). This is the first step that can give us a false sense of security, so let’s go ahead and see how to fix it.

Enforcing SSL/TLS

As mentioned, the pg_hba.conf file is where we can tune which connections are going to be required to use SSL. We can instruct PostgreSQL to enforce this by using the “hostssl” keyword instead of the plain “host” one. Note that you can see some connections starting to use SSL at this point because the plain “host” keyword will allow for connections that want to use SSL to use it. However, this is not enforcing SSL to be used (i.e.: if the client doesn’t want to use SSL, PostgreSQL will not deny the connection).

Let’s imagine this is the pg_hba.conf file we have been using so far:

hostssl    database     user    10.10.1.0/24   md5

Again, this is not enough if we are adamant about really enforcing connections to use SSL. We have to call pg_reload_conf() once more to make sure they are loaded into PostgreSQL itself:

postgres=# select pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

At this point, new remote non-SSL connections will be denied:

[root@node1 ~]# psql "host=10.10.1.132 sslmode=disable"
psql: error: connection to server at "10.10.1.132", port 5432 failed: FATAL:  no pg_hba.conf entry for host "10.10.1.113", user "postgres", database "postgres", no encryption

So, can we finally say we are fully secure now? No, not yet! Connections that were already established are not forced to use SSL until they reconnect. Checking for connections using SSL/TLS

We can check for connections using SSL with the following query:

postgres=# select pg_ssl.pid, pg_ssl.ssl, pg_ssl.version,
           pg_sa.backend_type, pg_sa.usename, pg_sa.client_addr
           from pg_stat_ssl pg_ssl
           join pg_stat_activity pg_sa
             on pg_ssl.pid = pg_sa.pid;
 pid  | ssl | version |  backend_type  | usename  |  client_addr
------+-----+---------+----------------+----------+---------------
 5547 | f   |         | walsender      | postgres | 10.10.1.113
 5549 | f   |         | client backend | postgres | 10.10.1.132
 5556 | f   |         | client backend | postgres | 10.10.1.113
(3 rows)

In this case, the replication connection (walsender) is not yet using SSL and neither are the two other clients connected, so we need to force a restart if we want them to reconnect. As always, we recommend that you try all these steps in a testing environment first and that when it’s time to do it in production you do them in a properly established maintenance window (no matter how trivial the steps seem to be).

To force the replication connections to use SSL, one can either restart the service in the replica or use pg_terminate_backend (which will send the SIGTERM signal to the process and is safe to use in this context). In this case, we are using pg_terminate_backend in the primary itself, but it can also be used in the replica, provided we are using the correct PID number.

postgres=# select pg_terminate_backend(5547);
 pg_terminate_backend
----------------------
 t

After that, we should see the new replica connection correctly using the SSL/TLS protocol:

postgres=# select pg_ssl.pid, pg_ssl.ssl, pg_ssl.version,
           pg_sa.backend_type, pg_sa.usename, pg_sa.client_addr
           from pg_stat_ssl pg_ssl
           join pg_stat_activity pg_sa
             on pg_ssl.pid = pg_sa.pid;
 pid  | ssl | version |  backend_type  | usename  |  client_addr
------+-----+---------+----------------+----------+---------------
 5557 | t   | TLSv1.2 | walsender      | postgres | 10.10.1.113
 5549 | f   |         | client backend | postgres | 10.10.1.132
 5556 | f   |         | client backend | postgres | 10.10.1.113
(3 rows)

PID 5549 is our own connection, so that’s an easy fix:

postgres=# select pg_backend_pid();
 pg_backend_pid
----------------
           5549
(1 row)

Connection from 5556 would be the remaining one for us to check if we need to enforce SSL on all. On the client-side, we can use \conninfo to check information on our current connection:

postgres=# \conninfo
You are connected to database "postgres" as user "postgres" on host "10.10.1.132" at port "5432".
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)

Disabling SSL/TLS

If you want to disable SSL instead, be sure to not lose the client connection after you set ssl=off and make changes to the pg_hba.conf file, otherwise you may be locked out if you don’t have any accounts using “host” only access method, and your only way out is to restart the service. To be safe, first, edit and reload pg_hba.conf file to include entries with “host”, and only then fully disable SSL (ssl=off). Conclusion

Enabling SSL/TLS for in-transit connection encryption is easy, but there are some pitfalls to be aware of when it comes to enforcing its usage. Simply enabling the configuration for it is not enough for it to be enforced, even if by default some connections may prefer using SSL when it’s available. If you need to ensure that all connections use SSL, edit the pg_hba.conf file accordingly and make sure it’s loaded. Remember that “hostssl” entries are the ones that force this behavior.

We can use tcpdump and wireshark to check if connections are indeed being encrypted. But, that’s a topic for another blog…