Bienvenido a proyecto online, en este sitio hallarás la respuesta que estás buscando.
Solución:
Solución 1:
Requerir SSL, mantener SELinux encendido, monitorear los registros y usar una versión actual de PostgreSQL.
Lado del servidor
Requerir SSL
En postgresql.conf colocar ssl=on y asegúrese de tener su archivo de claves y certfile instalados correctamente (consulte los documentos y los comentarios en postgresql.conf).
Es posible que deba comprar un certificado de una CA si desea que los clientes confíen en él sin una configuración especial en el cliente.
En pg_hba.conf usa algo como:
hostssl theuser thedatabase 1.2.3.4/32 md5
… posiblemente con “todos” para el usuario y / o la base de datos, y posiblemente con un filtro de dirección IP de origen más amplio.
Limite los usuarios que pueden iniciar sesión, niegue el inicio de sesión de superusuario remoto
No permita “todos” para los usuarios si es posible; no desea permitir los inicios de sesión de superusuario de forma remota si puede evitar la necesidad de hacerlo.
Limitar los derechos de los usuarios
Restrinja los derechos de los usuarios que pueden iniciar sesión. No les dé CREATEDB o CREATEUSER derechos.
REVOKE los CONNECT desde PUBLIC en todas sus bases de datos, luego devuélvalo solo a los usuarios / roles que deberían poder acceder a esa base de datos. (Agrupe a los usuarios en roles y otorgue derechos a los roles, en lugar de directamente a usuarios individuales).
Asegúrese de que los usuarios con acceso remoto solo puedan conectarse a las bases de datos que necesitan y solo tengan derechos sobre los esquemas, tablas y columnas dentro de los que realmente necesitan. Esta es una buena práctica para los usuarios locales también, es solo una seguridad sensata.
Configuración del cliente
En PgJDBC, pase el parámetro ssl=true:
Para indicar al controlador JDBC que intente establecer una conexión SSL, debe agregar el parámetro de URL de conexión ssl =true.
… e instale el certificado de servidor en el almacén de confianza del cliente, o use un certificado de servidor en el que confíe una de las CA en el almacén de confianza integrado de Java si no desea que el usuario tenga que instalar el certificado.
Acción en curso
Ahora asegúrese de mantener PostgreSQL actualizado. PostgreSQL solo ha tenido un par de agujeros de seguridad previos a la autenticación, pero eso es más de cero, así que manténgase actualizado. De todos modos, debería tener correcciones de errores.
Agregue un firewall al frente si hay grandes bloques de red / regiones desde las que sabe que nunca necesita acceso.
Registrar conexiones y desconexiones (ver postgresql.conf). Registre las consultas si es práctico. Ejecute un sistema de detección de intrusos o fail2ban o similar al frente si es práctico. Para fail2ban con postgres, hay un práctico procedimiento aquí
Supervise los archivos de registro.
Bonificación de paranoia
Pasos adicionales para pensar …
Requerir certificados de cliente
Si lo desea, también puede usar pg_hba.conf para requerir que el cliente presente un certificado de cliente X.509 en el que confíe el servidor. No necesita usar la misma CA que el certificado del servidor, puede hacer esto con una CA homebrew openssl. Un usuario de JDBC debe importar el certificado de cliente a su almacén de claves Java con keytool y posiblemente configure algunas propiedades del sistema JSSE para apuntar Java a su almacén de claves, por lo que no es totalmente transparente.
Poner en cuarentena la instancia
Si desea ser realmente paranoico, ejecute la instancia para el cliente en un contenedor / VM separado, o al menos con una cuenta de usuario diferente, con solo la (s) base de datos (s) que requieren.
De esa manera, si comprometen la instancia de PostgreSQL, no llegarán más lejos.
Utilice SELinux
No debería tener que decir esto, pero …
Ejecute una máquina con soporte SELinux como RHEL 6 o 7, y no apague SELinux ni lo configure en modo permisivo. Manténgalo en modo de aplicación.
Utilice un puerto no predeterminado
Seguridad por solamente la oscuridad es estupidez. La seguridad que usa un poco de oscuridad una vez que haya hecho las cosas sensatas probablemente no le hará daño.
Ejecute Pg en un puerto no predeterminado para hacer la vida un poco más difícil a los atacantes automatizados.
Pon un proxy al frente
También puede ejecutar PgBouncer o PgPool-II frente a PostgreSQL, actuando como un grupo de conexiones y un proxy. De esa manera, puede dejar que el proxy maneje SSL, no el host de la base de datos real. El proxy puede estar en una máquina virtual o máquina separada.
El uso de proxies de agrupación de conexiones es generalmente una buena idea con PostgreSQL de todos modos, a menos que la aplicación cliente ya tenga una agrupación incorporada. La mayoría de los servidores de aplicaciones Java, Rails, etc. tienen agrupación incorporada. Incluso entonces, un proxy de agrupación del lado del servidor es, en el peor de los casos, inofensivo.
Solución 2:
Una simple extensión del impresionante plan de acción de Craigs:
Tal vez el usuario esté utilizando solo un conjunto relativamente pequeño de proveedores de red (por ejemplo, su proveedor de red móvil mientras se mueve, su red de cable desde el hogar y la IP saliente del trabajo).
La mayoría de los proveedores de red tienen muchas direcciones IP, pero no muchas subredes. Por lo tanto, puede proporcionar un filtro de iptables, que limita el acceso postgresql a los segmentos de red que utiliza su cliente. Esto redujo en gran medida las posibilidades de ataque de fuentes de problemas de la red seleccionadas al azar.
Un escenario de soporte simple:
- Tu cliente te llama “No puedo iniciar sesión”.
- Te enteras con un
tcpdump -i eth0 -p tcp port 5432comando, de dónde viene. - Con un
whois 1.2.3.4puede obtener la dirección IP utilizada por esta IP. Por ejemplo, puede ser1.2.3.0/24. - Con un
iptables -A INPUT -s 1.2.3.0/24 -p tcp --dport 5432 -j ACCEPT(o algo similar) permite las conexiones tcp con su nueva subred.
Hay un muy buen script en Perl llamado uif que puede proporcionar conjuntos de reglas de iptables declarables permanentes e intuitivos. (Google para “uif iptables”).
Solución 3:
Aquí hay una configuración de Fail2ban bastante simple para PostgreSQL basada en el CÓMO vinculado anteriormente, pero ajustada para funcionar realmente con paquetes de Ubuntu, detectar otra condición de error y omitir varios mensajes de depuración para hacerlo más rápido:
/etc/fail2ban/filter.d/local-postgresql.conf:
[Definition]
failregex = (d+) FATAL: password authentication failed for .+$
(d+) FATAL: no pg_hba.conf entry for host .+$
ignoreregex = duration:
/etc/fail2ban/jail.d/local-postgresql.conf:
[local-postgresql]
enabled = true
filter = local-postgresql
action = iptables[name=PostgreSQL, port=5432, protocol=tcp]
sendmail-whois[name=PostgreSQL, [email protected]]
logpath = /var/log/postgresql/postgresql-9.3-main.log
maxretry = 3
Puedes añadir valor a nuestra información colaborando tu experiencia en los comentarios.