Restricción de acceso por IP y configuración de pg_hba.conf

pg_hba.conf es un archivo de configuración de PostgreSQL que sirve para gestionar las conexiones y la autenticación. HBA significa Host-Based Authentication (autenticación basada en host). Este archivo es como una barrera de red que define:

• Quién puede conectarse al servidor (direcciones IP, rol, base de datos).
• Qué método de autenticación se requiere para conectarse.

Si lo comparamos con la vida real, pg_hba.conf es como el portero en la entrada de un edificio. Decide a quién dejar pasar y a quién no, revisando no solo tus documentos (contraseña), sino también tu dirección (IP).

Estructura del archivo pg_hba.conf

El archivo pg_hba.conf está compuesto por líneas, donde cada línea describe una regla de acceso. La estructura de la línea es así:

<tipo de conexión> <base de datos> <usuario> <origen> <método de autenticación>

Vamos a ver los componentes:

Tipo de conexión (connection type): define cómo se va a conectar el cliente.

• local: conexión por sockets Unix (para usuarios locales en el servidor Linux).
• host: conexión por TCP/IP.
• hostssl: conexión por TCP/IP, pero solo usando SSL.
• hostnossl: conexión por TCP/IP sin usar SSL.

Base de datos: lista las bases de datos a las que se permite el acceso. Puedes poner una base concreta, varias separadas por comas, o palabras clave:

• all: Permitir acceso a todas las bases de datos.

Usuario: indica qué usuarios pueden conectarse.

• Puedes poner un nombre de usuario concreto o usar all para permitir a todos.

Origen (address): indica la dirección IP del cliente o un rango de direcciones.

• Para IPv4 se usa el formato x.x.x.x o x.x.x.x/y (donde /y es la máscara de subred, por ejemplo, /24).
• Para IPv6 se usa el formato ::/y.
• La palabra clave all significa permitir todas las direcciones IP.

Método de autenticación: indica qué método de autenticación se usa.

Ejemplos:

• trust: permite conectarse sin contraseña (no seguro, solo para pruebas).
• md5: usar contraseña (hasheada).
• scram-sha-256: autenticación más segura usando SHA-256.
• reject: denegar acceso.

Ejemplos de líneas en pg_hba.conf

La configuración del archivo puede ser flexible. Aquí tienes algunos ejemplos:

1. Permitir conexiones locales por socket Unix

   local   all             all                                     trust
   

   Se permite a todos los usuarios conectarse a todas las bases en el servidor local sin contraseña.

2. Permitir conexiones desde una IP concreta

   host    my_database     my_user        192.168.1.100/32         md5
   

   El usuario my_user puede conectarse a la base my_database solo desde la IP 192.168.1.100, usando contraseña.

3. Permitir acceso a la base desde toda una subred

   host    my_database     all            192.168.1.0/24           scram-sha-256
   

   Cualquier usuario de la subred 192.168.1.0/24 puede conectarse a la base my_database, pero solo usando autenticación SHA-256.

4. Denegar conexiones desde una subred concreta

   host    all             all            192.168.2.0/24           reject
   

   Las conexiones desde la subred 192.168.2.0/24 están totalmente prohibidas.

Configuración de acceso por direcciones IP

Ahora que ya pillamos la estructura del archivo, vamos a ver cómo gestionar las conexiones.

Vamos a intentar limitar el acceso al servidor desde ciertas direcciones IP. Supongamos que tenemos un servidor PostgreSQL y queremos permitir acceso solo desde localhost (127.0.0.1) y desde la subred de la oficina (192.168.10.0/24). Para eso añadimos estas líneas en pg_hba.conf:

# Acceso local
host    all             all            127.0.0.1/32             trust

# Acceso desde la oficina
host    all             all            192.168.10.0/24          md5

# Denegar todo lo demás
host    all             all            0.0.0.0/0                reject

Aquí la regla 0.0.0.0/0 significa "todas las direcciones IP". Estamos prohibiendo explícitamente el acceso desde cualquier sitio que no sean las direcciones indicadas.

Configuración de acceso para usuarios remotos

Si tu servidor PostgreSQL está en la nube o en un servidor remoto, puede que necesites permitir conexiones solo para ciertas IP externas. Por ejemplo:

# Acceso para el admin desde casa
host    all             admin_user     203.0.113.10/32          md5

En este ejemplo solo el usuario admin_user desde la IP 203.0.113.10 podrá conectarse.

Recargar la configuración

Después de hacer cambios en pg_hba.conf PostgreSQL tiene que aplicarlos. Para eso usa el comando:

sudo systemctl reload postgresql

Recargar es seguro y no va a tirar el servidor abajo.

Si se te olvida dónde está pg_hba.conf, puedes ver la ruta por SQL:

SHOW hba_file;

Errores típicos al trabajar con pg_hba.conf

Trabajar con pg_hba.conf es bastante sencillo, pero los admins novatos a veces la lían. Por ejemplo:

1. Olvidar recargar el servidor. Todos los cambios en pg_hba.conf solo se aplican después de recargar la configuración.
2. Reglas en conflicto. PostgreSQL procesa las reglas de arriba a abajo. En cuanto una regla se cumple, las demás se ignoran. Las reglas más generales deben ir más abajo.
3. Máscara de subred incorrecta. Por ejemplo, si pones /0, abres el acceso a todo el mundo, lo que puede ser una vulnerabilidad seria.

Ejemplos de escenarios reales de uso

Testear una app en el servidor local.

Permitir acceso solo desde localhost:

local   all   all   trust

Trabajar con clientes remotos.

Permitir acceso a un cliente desde una IP concreta:

host    all   client_user   203.0.113.42/32   scram-sha-256

Restringir acceso en red pública.

Denegar conexiones desde Internet (pero permitir a la oficina):

host    all   all   0.0.0.0/0   reject
host    all   all   192.168.10.0/24   md5

A estas alturas ya deberías tener claro cómo usar pg_hba.conf para restringir el acceso a PostgreSQL. Este archivo es una de las herramientas clave para asegurar tu base de datos. Asegúrate de que la configuración tenga sentido, esté probada y sea coherente con las necesidades del negocio. ¿A que todos queremos vivir en un mundo donde los datos estén protegidos de los hackers? Bueno, claro, salvo que el hacker seas tú :)