Implantacin de Bases de Datos Seguras en PostgreSQL V 8.2.

6
Introduccin
Distribucin GNU/Linux usada
Versin de PostgreSQL usada
Requisitos de instalacin
Instalacin de PostgreSQL
Inicializacin de la base de datos maestra
Configuracin bsica de Seguridad de PostgreSQL
Habilitar Secure Socket Layer (SSL) en PostgreSQL
Importancia de adaptar SSL para la Seguridad en las Bases de Datos
Crear solicitudes para que una CA nos firme los certificados
Proceso completo de creacin de CA y certificados emitidos
Configurar PostgreSQL para que solicite certificados a los clientes
Diseo Seguro de Bases de Datos en PostgreSQL
Disponibilidad basada en un respaldo global (full back-up)
Disponibilidad basada en respaldos incrementales
Configurar PostgreSQL para usar respaldos incrementales
Conclusiones
Revisin histrica
Introduccin
Hoy en da la informacin se ha convertido en el activo ms importante de cualquier organizacin sea
acadmica o con fines de de lucro.
Esto ha permitido fundamentar la seguridad informtica en sus principios bsicos: integridad,
confidencialidad y disponibilidad.
Son varios los DBMS que existen actualmente; algunos se quedan slo en este concepto, otros son RDBMS e
inclusive de tipo ORDBMS. Todos con objetivo principal de administrar los datos.
La tarea ms importante del DBMS es garantizar los tres pilares fundamentales de la seguridad, y as
disminuir el riesgo de compromiso de la informacin instalada y configurada.
Uno de tantos DBMS que se encuentran disponibles actualmente es PostgreSQL, el cual es un Sistema de
Administracin de Bases de Datos Objeto-Relacionales (ORDBMS) resultado de varias etapas desde 1977.
Comenz como un proyecto denominado Ingres en la Universidad de Berkeley en California. Ingres fue ms
tarde desarrollado comercialmente por la Relational Technologies/Ingres Corporation.
En 1986 otro equipo dirigido por Michael Stonebraker, investigador de Berkeley, continu el desarrollo del
cdigo de Ingres para crear un sistema de bases de datos objeto-relacionales llamado Postgres. En 1996,
debido a un nuevo esfuerzo de cdigo abierto y a la incrementada funcionalidad del software, Postgres fue
renombrado a PostgreSQL, tras un breve paso como Postgres95.
Distribucin GNU/Linux usada
Cabe mencionar que PostgreSQL desde hace varios aos se encuentra disponible para plataformas Windows y
Unix o Linux. Se utiliz para esta recomendacin de instalacin de PostgreSQL, la versin 7.10, la ms
reciente de Ubuntu Server al momento de la elaboracin de este documento. Se procede a realizar la
instalacin sin ninguna caracterstica extra, slo las instaladas por default en este sistema operativo.
Figura 1 Ubuntu 7.10
Versin de PostgreSQL usada
De igual forma se utiliza la versin estable ms reciente de este ORDBMS, PostgreSQL 8.2.6
Figura 2 PostgreSQL 8.2.6
Requisitos de instalacin
Compilador g++ 4.1 o superior.
libreadline-dev es opcional para poder contar con el auto completado de comandos e historial.
libssl si se usara conexiones por medio de SSL las bases de datos.
Zlib1g-dev si se quiere que postgreSQL arroje por default los respaldos compresos con zip.
GNU make
Todas las opciones anteriores se pueden omitir excepto la de g++ y make que son necesarias para compilarlo,
se recomienda contar con todas estas opciones para tener una mejor instalacin y as facilitar la administracin
del servidor.
Instalacin de PostgreSQL
La instalacin se llevara a cabo desde archivo fuente, existen varias distribuciones en formato binario pre
configuradas para instalarse como ".deb" o".rpm"; aqu la primera recomendacin: para tener un mejor
control, se recomienda hacer uso de este tipo de archivo para la instalacin, es decir configurando y
compilando de acuerdo a nuestros requerimientos.
Para comenzar con la instalacin se necesita obtener el archivo fuente desde el sitio oficial de PostgreSQL:
http://www.postgresql.org/
Para obtener el archivo fuente se necesitan dos pasos:
1. - wget
El primer paso es obtener el archivo por medio de wget es fcil hacer esto, por ejemplo usar el siguiente
mirror(aunque puede encontrar ms en la pgina oficial de postgresql):
$ wget http://ftp8.us.postgresql.org/postgresql//source/v8.2.6/postgresql-8.2.6.tar.bz2
En su defecto obtenerlo por medio de otra herramienta o directamente del sitio oficial por medio de un
navegador Web.
Obtener de igual forma el archivo que contiene el hash md5 del paquete.
$ wget http://ftp8.us.postgresql.org/postgresql//source/v8.2.6/postgresql-8.2.6.tar.bz2.md5
2. - md5sum
Ahora debe comprobarse la integridad del paquete, con md5sum instalada por default en los sistemas
GNU/Linux ms recientes. El resultado tiene que coincidir con lo que est dentro del archivo con extensin
md5 que se obtuvo en el punto anterior.
$ cat postgresql-8.2.5.tar.bz2.md5
MD5 (postgresql-8.2.5.tar.bz2) = bb1cd309ea72f070cb964736f5755847
$ md5sum postgresql-8.2.5.tar.bz2
bb1cd309ea72f070cb964736f5755847 postgresql-8.2.5.tar.bz2
Ahora, ya con la seguridad de que la integridad del paquete no ha de modificarse y que la versin fue
proporcionada por el sitio oficial, procedemos a definir el lugar en dnde se debe encontrar el servidor de base
de datos.
Se recomienda instalar el directorio de datos separado de la instalacin, esto debido a que se tiene una mejor
organizacin a la hora de administrar los datos y los archivos. Incluso es mejor que se encuentre en una
particin destinada exclusivamente para almacenar lo datos, dado que PostgreSQL trabaja directamente sobre
el sistema de archivos, nicamente el dueo con permisos 700debe controlar el acceso a este directorio .
Adems sera ms fcil agregar espacio extra a dicha particin en caso de que se sature.
Descomprimir y desempaquetar el archivo tar.bz2 que se descarg.
$ tar -jxvf postgresql-8.2.6.tar.bz2.md5
Nos cambiamos al directorio creado.
$ cd postgresql-8.2.6
Ahora hay que comenzar a configurar las opciones que ms se adecuen a nuestras necesidades, como ruta de
instalacin, soporte para conexiones SSL, etc. y para conocer las opciones completas de instalacin se hace
con la opcin:
$./configure --help
Una vez elegidas las opciones necesarias, lo primero que hacemos es:
$./configure --prefix=/usr/local/serverdb --with-pgport=2345 -with-openssl
--prefix Es la ruta de instalacin, se cambia a la que configura PostgreSQL por omisin.
--with-pgport se cambia el puerto por default 5432 a 2345
--with-openssl para usar un canal cifrado de conexin y establecer un nivel ms de seguridad por medio de
certificados digitales.
La instalacin de openssl lo podemos llevar a cabo por medio del administrador de paquetes del sistema
operativo, en este caso apt-get o por medio de los archivos fuente del sitio oficial del proyecto openssl .
Si no regresa ningn error procedemos a realizar como administrador del sistema un
$make && make install.
Al finalizar esto si ningn error se present hemos terminado la instalacin. Si en alguno de los dos pasos
anteriores se encontrara algn error seguramente es porque alguno de los requisitos no est instalado. Hay dos
formas de solucionarlos, una es instalando estos requisitos, y la otra es omitindolos por medio de opciones en
el comando configure.
Inicializacin de la base de datos maestra
Lo primero que debe hacerse es pensar en qu lugar del sistema de archivos queremos tener nuestro directorio
de datos. Se recomienda tenerlo en una particin por separado en donde, si se llega a dar el caso, poder
agregar espacio a la particin con menor dificultad como ya hemos mencionado, otra razn es para mantener
un mejor control hacia este directorio.
Por ejemplo se elige algo as como:
/dataserver
Este directorio debe tener permisos nicamente para el dueo
drwx------ 2 egonzalez egonzalez 4096 2007-11-26 17:25 dataserver
Debe crearse un usuario que fungir como administrador del RDBMS, para lo cual es recomendable se use
cualquier otro menos el default de PostgreSQL (comnmente postgres), pues ste tendr acceso al sistema
operativo, otro consejo es que este usuario lleve un nombre distinto de todo aquello que lo pueda hacer
parecer un usuario administrador de la base de datos.
Ejecutamos todava como usuario administrador:
$ adduser gmartinez
Aunque de igual forma pudo ser el default, tomando las medidas necesarias, como la de establecer una
contrasea fuerte. En este caso se configura la cuenta "gmartinez" como usuario administrador para
PostgreSQL.
Al directorio que albergara las bases de datos debemos asignarle como dueo al nuevo usuario, y con todos
los permisos sobre l nicamente al dueo, que en nuestro caso ser el administrador de PostgreSQL:
drwx------ 2 gmartinez gmartinez 4096 2007-11-26 17:25 dataserver
En la instalacin hecha se encuentra un directorio de binarios /usr/local/serverdb/bin en l hay un script que
sirve para inicializar las bases de datos llamado initdb.
Nos cambiamos como usuario gmartinez .
$su - gmartinez
Se ejecuta:
$ /usr/local/serverdb/bin/initdb -D /dataserver
Esta instruccin indica a PostgreSQL que el directorio /dataserver es el que guardar las bases de datos, en
especifico con la opcin -D.
Lo ltimo que hacemos es inicializar el servidor con el directorio de datos especfico que acabamos de crear.
$/usr/local/serverdb/bin/postmaster -i -D /dataserver > /dataserver/logfile 2>&1 &
-i Permite conexiones TCP/IP
-D indicar el directorio de datos.
-/dataserver/logfile 2>&1& (es muy importante para detectar posibles errores y redireccionar las salidas tanto
estndar como de error hacia un archivo de log).
Con esta ltima lnea ejecutada tenemos un servidor de base de datos instalado listo para soportar conexiones
SSL, con las herramientas necesarias para llevar una buena administracin, pero an no lo configuramos con
las opciones bsicas para disminuir el riesgo de que nuestro servidor sea comprometido.
Configuracin bsica de Seguridad de PostgreSQL
En el directorio de datos hay 3 archivos de configuracin. Uno de ellos es pg_hba.conf, el cual debe de
configurarse de acuerdo a nuestras polticas de accesos para permitir conexiones locales o remotas. Lo
primero que hay que quitar son los permisos de acceso por default.
De inicio contiene algo como lo siguiente:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
Esta configuracin por default permite que cualquiera se conecte al servidor de base de datos, desde cualquier
lugar tanto localmente como remotamente sin solicitarles una contrasea de autenticacin. De entrada esto
aumenta el riesgo de que alguien sin autorizacin acceda a la informacin que se est resguardando.
Bsicamente son las 5 columnas que se describen a continuacin:
Type. Al colocar este tipo de conexin se usar de dos formas local y remota. La forma "local" se refiere a los
usuarios que acceden desde el servidor en que se aloja el RDBMS, en lo que respecta a "host" son aquellas
conexiones remotas tanto de redes tipo ipv4 como soporte para ipv6. Tambin est en la parte de host la
opcin con soporte para SSL "hostssl".
Database. Es el nombre de la base de datos a la que podemos conectarnos, si se requiere se pueden poner
todas con la palabra reservada "all". "sameuser" specifica especifica que el cliente slo puede conectar a una
base de datos en la que coinciden los nombre de usuarios autenticados de los clientes.
User. Es el usuario que tendr acceso a la o las bases de datos que le sean permitidas. De igual forma se hace
referencia a todos con "all".
Cidr-address. Es la columna de la IP y la netmask que puede acceder al servidor. Para el caso de una conexin
local se deja en blanco.
Method: El mtodo de autenticacin define el tipo de autenticacin que el servidor debera usar para un
usuario que intenta conectar a PostgreSQL. Existen varios mtodos posibles a utilizar.
trust. Permite a cualquier usuario sin el uso de una contrasea. No es una opcin recomendable para
conectarse a un servidor remoto, en conexiones locales puede usarse con sus respectivas
consideraciones.

reject. Automticamente deniega el acceso a PostgreSQL para esa mquina o usuario. sta puede ser
una configuracin prudente para sitios en los que nadie est autorizado a conectar a su servidor de
bases de datos.

password. Exige la existencia de una contrasea para una conexin de usuario. La contrasea se enva
en texto plano, es por ello que no se recomienda usar este mtodo.

crypt. Enva la contrasea a travs de un formato simple de encriptacin, no es muy seguro, pero es
mejor que usar el mtodo password, aunque tampoco se recomienda usarlo.

md5 .Enva los datos de autenticacin con el algoritmo md5. Es la que comnmente usamos para
autenticarnos.

krb4, krb5. Los mtodos krb4 y krb5 se autentifican con Kerberos.
ident. Establece que un mapa de identidad debera ser usado cuando una mquina est solicitando
conexiones desde una IP vlida listada en el archivo pg_hba.conf.

ldap: Usado parapara autenticarnos.
Lo primero que demos hacer al configurar este archivo es definir las polticas de cmo se podr acceder al
servidor, si ser local o slo remotamente o una combinacin de las dos.
Para tener un mejor registro y basndonos en un control de acceso de tres capas definimos que se debe
conectar el usuario administrador de PostgreSQL nicamente localmente a todas las bases de datos. El mtodo
de autenticacin a utilizar ser md5, y las otras lneas para comentar el archivo(se usa #) pg_hba.conf,
agregando nicamente las necesarias dependiendo de las reglas del negocio, un ejemplo sera:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
#local all all trust
local all gmartinez md5
# IPv4 local connections:
#host all all 127.0.0.1/32 trust
host serverdb egonzalez 192.168.101.125/32 md5
# IPv6 local connections:
#host all all ::1/128 trust
Antes de que hagan efecto estos cambios debemos ponerle un password fuerte a nuestro usuario
administrador, debido a que en la lnea siguiente se especifica que requiere de una contrasea cifrada:
local all gmartinez md5
El mtodo de autenticacin md5 solicitar la contrasea de acceso. Para realizar esto ingresamos por medio
del cliente de la siguiente forma:
$/usr/local/serverdb/bn/psql -d template1
Ya dentro de psql:
template1=# ALTER USER gmartinez ENCRYPTED PASSWORD 'xxxxxxxxxx';
Con esto la contrasea del usuario administrador de PostgreSQL ha sido actualizada y se pedir cada que se
requiera conectar. Por default PostgreSQL crea el archivo llamado .psql_history en el HOME del usuario que
se conecta .psql_history ,el cual una vez ejecutado el comando de cambio de password del administrador
debemos borrar el contenido para evitar un posible mal uso del archivo, ya que se almacenan las instrucciones
hechas por el cliente psql de PostgreSQL.
Ahora hay que reiniciar el servicio para que hagan efecto los cambios. Una forma de hacerlo es la siguiente:
Primero detenemos el servicio:
$ /usr/local/serverdb/bin/pg_ctl stop -D /dataserver -l /dataserver/logfile -i
Ahora lo volvemos a inicializar con la opcin -i, es importante si nicamente permitirs conexiones TCP/IP al
servidor.
$/usr/local/serverdb/bin/postmaster -i -D /dataserver > /dataserver/logfile 2>&1 &
Esta parte depende netamente de las polticas de acceso que se vayan a implementar para el servidor de bases
de datos. Con una configuracin de esta forma, los datos enviados desde conexiones remotas en cuanto a
autenticacin pasan protegidas por medio del algoritmo md5, pero las consultas realizadas ya dentro del psql
viajan de forma plana.
Se recomienda tener un servidor dedicado a las bases de datos, permita conexiones remotas, y por lo tanto no
es adecuado pasar informacin de esta forma a menos que se tenga una buena organizacin de la red y una
extrema confianza del servidor al que se conecta. Gracias a esto PostgreSQL permite cifrar el canal de
comunicacin y para ello se configur la instalacin con la opcin -with-openssl para evitar que al enviar
sentencias SQL y resultados obtenidos viajen en forma clara y que cualquiera que tenga acceso al trfico de la
red pueda ver la informacin transmitida. Lo primero que vamos a hacer es activar SSL en PostgreSQL.
Podemos verificar la conexin, en nuestro ejemplo tenemos una lnea:
host serverdb egonzalez 192.168.101.125/32 md5
sta permite que el usuario egonzalez se conecte a la base de datos serverdb nicamente desde la direccin IP
(Internet Protocol) 192.168.101.125 la cual slo cifra el password de autenticacin por medio del algoritmo
md5.
El riesgo de confidencialidad sobre la informacin se determina al ejecutarse:
tcpdump -nnxXvs 1514 -i eth0 port 2345 and host 192.168.101.125
De esta accin podemos encontrar informacin valiosa.
Se percibe que el tcpdump es la solicitud de acceso al servidor, lo cual es congruente con la conexin
establecida para host 192.168.101.125 por parte del usuario egonzalez a la base de datos serverdb.
0x0000: 4500 005f 79df 4000 4006 bd83 84f8 7c9d E.._y.@.@.....|.
0x0010: 84f8 7ca8 a848 1a0a 1a3e efc3 b67b b8c5 ..|..H...>...{..
0x0020: 8018 16d0 4944 0000 0101 080a 4da0 9661 ....ID......M..a
0x0030: 0f0f ad03 0000 002b 0003 0000 7573 6572 .......+....user
0x0040: 0065 676f 6e7a 616c 657a 0064 6174 6162 .egonzalez.datab
0x0050: 6173 6500 6567 6f6e 7a61 6c65 7a00 00 ase.serverdb..
En el ejemplo, el esquema de autenticacin usa md5 para cifrar la contrasea y sta no pase en claro, como se
puede apreciarslo se trata del hash md5 de la contrasea.
0x0030: 0f0f bb84 7000 0000 286d 6435 6166 6365 ....p...(md5afce
0x0040: 6138 3061 3734 3463 3935 3062 3663 6331 a80a744c950b6cc1
0x0050: 6666 3462 3034 3864 3436 3430 00 ff4b048d4640.
Si se tuviera por ejemplo una password conel tipo de autenticacin en el archivo pg_hba.conf en lugar de md5
se podra ver la contrasea en claro.
0x0000: 4500 0043 7784 4000 4006 bffa 84f8 7c9d E..Cw.@.@.....|.
0x0010: 84f8 7ca8 a906 1a0a 5441 892e f0f0 0151 ..|.....TA.....Q
0x0020: 8018 16d0 1ea4 0000 0101 080a 4da1 ff85 ............M...
0x0030: 0f13 33c9 7000 0000 0e65 676f 6e7a 616c ..3.p....passwordegonzal
0x0040: 657a 00 ez.
La autenticacin no es lo nico que nos interesa proteger, se tiene adems que contemplar el servidor de base
de datos, y si la configuracin que se tiene al momento despliega informacin de las sentencias SQL de forma
entendible y fliudae, como una simple consulta a las tablas de sistema de PostgreSQL.
SELECT * from pg_user ;
Cuya salida en consola del cliente psql es:
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
-----------+----------+-------------+----------+-----------+----------+--------- -+-----------
dba | 10 | t | t | t | ******** | |
egonzalez | 16384 | f | f | f | ******** | |
(2 rows)
Al ejecutarel mismo comando tcpdump se obtiens como salida lo siguiente, respecto a la
instruccin de SQL:
0x0000: 4500 0051 778a 4000 4006 bfe6 84f8 7c9d E..Qw.@.@.....|.
0x0010: 84f8 7ca8 a906 1a0a 5441 8e29 f0f0 041e ..|.....TA.)....
0x0020: 8018 1d50 beab 0000 0101 080a 4da2 f4bb ...P........M...
0x0030: 0f14 dc75 5100 0000 1c53 454c 4543 5420 ...uQ....SELECT.
0x0040: 2a20 6672 6f6d 2070 675f 7573 6572 203b *.from.pg_user.;
Y al respecto de los datos de la consulta hecha.
0x0000: 4500 019e 3295 4000 4006 038f 84f8 7ca8 E...2.@.@.....|.
0x0010: 84f8 7c9d 1a0a a906 f0f0 041e 5441 8e46 ..|.........TA.F
0x0020: 8018 0204 91c1 0000 0101 080a 0f15 98c3 ................
0x0030: 4da2 f4bb 5400 0000 e000 0875 7365 6e61 M...T......usena
0x0040: 6d65 0000 0028 4200 0100 0000 1300 40ff me...(B.......@.
0x0050: ffff ff00 0075 7365 7379 7369 6400 0000 .....usesysid...
0x0060: 2842 0002 0000 001a 0004 ffff ffff 0000 (B..............
0x0070: 7573 6563 7265 6174 6564 6200 0000 2842 usecreatedb...(B
0x0080: 0003 0000 0010 0001 ffff ffff 0000 7573 ..............us
0x0090: 6573 7570 6572 0000 0028 4200 0400 0000 esuper...(B.....
0x00a0: 1000 01ff ffff ff00 0075 7365 6361 7475 .........usecatu
0x00b0: 7064 0000 0028 4200 0500 0000 1000 01ff pd...(B.........
0x00c0: ffff ff00 0070 6173 7377 6400 0000 2842 .....passwd...(B
0x00d0: 0006 0000 0019 ffff ffff ffff 0000 7661 ..............va
0x00e0: 6c75 6e74 696c 0000 0028 4200 0700 0002 luntil...(B.....
0x00f0: be00 04ff ffff ff00 0075 7365 636f 6e66 .........useconf
0x0100: 6967 0000 0028 4200 0800 0003 f1ff ffff ig...(B.........
0x0110: ffff ff00 0044 0000 0036 0008 0000 0003 .....D...6......
0x0120: 6462 6100 0000 0231 3000 0000 0174 0000 dba....10....t..
0x0130: 0001 7400 0000 0174 0000 0008 2a2a 2a2a ..t....t....****
0x0140: 2a2a 2a2a ffff ffff ffff ffff 4400 0000 ****........D...
0x0150: 3f00 0800 0000 0965 676f 6e7a 616c 657a ?......egonzalez
0x0160: 0000 0005 3136 3338 3400 0000 0166 0000 ....16384....f..
0x0170: 0001 6600 0000 0166 0000 0008 2a2a 2a2a ..f....f....****
0x0180: 2a2a 2a2a ffff ffff ffff ffff 4300 0000 ****........C...
0x0190: 0b53 454c 4543 5400 5a00 0000 0549 .SELECT.Z....I
Es posible percatarse que al analizar el trfico de la red corporativa, la informacin de las sentencias
ejecutadas remotamente son visualizadas slo por quin tiene autorizacin de hacerlo al . Para evitar otro tipo
de revelacin de informacin, se debe habilitar el SSL en la comunicacin del cliente con el servidor.
Habilitar Secure Socket Layer (SSL) en PostgreSQL
Al realizar la configuracin de PostgreSQL se agreg una opcin para habilitar openssl, PostgreSQL no se
activa por default, al instalarlo con esta opcin y configurndolo adecuadamente la conexin se cifrar, esta
cualidad reduce a un porcentaje mnimo el desempeo general del servidor, pero aumenta la confidencialidad
de la informacin resguardada.
PostgreSQL necesita un certificado para poder establecer un canal de comunicacin seguro, lo primero que
hacemos es solicitar un certificado a alguna autoridad certificadora vlida.
$cd /dataserver/
$openssl req -new -text -out server.req
El comando anterior requerir una palabra secreta (Hay que recordarla). Asegrate de ingresar el nombre de tu
host como "Common Name".
Ahora hay que generar una llave con algoritmo RSA.
$openssl rsa -in privkey.pem -out server.key
Debes ingresar la palabra secreta en cada comando que te lo solicite. Ahora borramos el archivo .pem creado,
esto para evitar una posible prdida de la llave privada e impedir que el servidor se vea comprometido.
$rm privkey.pem
Ahora se firma la solicitud como Autoridad Certificadora. Este paso se omite si quien firma es de verdad una
Autoridad Certificadora, a la que proporcionaremos la solicitud del certificado es decir el archivo server.req.
$openssl req -x509 -in server.req -text -key server.key -out server.crt
Una vez ejecutado el comando o la Autoridad Certificadora nos regresa el certificado con nombre server.crt.
Cambiamos los permisos a los archivos generados, tal como se hizo al cambiar el dueo al usuario
administrador y asegurarnos que estn dentro del directorio de datos de PostgreSQL.
$chmod og-rwx server.key
$chown gmartinez:gmartinez server.*
Ya que tenemos el archivo "crt" en el directorio de datos, lo ltimo que hay que hacer es activar el SSL en el
archivo de configuracin de PostgreSQL "postgres.conf", ubicado dentro del directorio de datos.
Es decir, cambiar ssl = off por ssl = on. Es importante notar que ssl = on debe quedar sin el smbolo de
comentario, en otras palabras, sin el #.
Lo que sigue es reiniciar el servidor para que hagan efecto los cambios realizados a la activacin del SSL.
Para verificar que se ha habilitado SSL debemos conectarnos con el cliente al usuario DBA:
$/usr/local/serverdb/bin/psql -d template1
Y realizamos la siguiente consulta:
template1=# SELECT name, setting from pg_settings where name ='ssl';
Y arroja como resultado de la sentencia SQL:
ssl | on |
Esta ltima instruccin provee una instalacin con los requerimientos mnimos para disminuir el riesgo de
comprometer el servidor , pero no garantiza que el servidor de base de datos sea totalmente seguro, el
Administrador de las Bases de Datos (DBA) realiza una tarea muy importante, la cual consiste en mantener
actualizado el Software de acuerdo a las nuevas vulnerabilidades que puedan alterar de alguna forma el
RDBMS.
Volviendo a tcpdump, podemos analizar la salida de una consulta de nueva cuenta con SSL habilitado.
Al conectarnos debe arrojar un mensaje parecido a este:
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Y la salida de tcpdump respecto a la consulta :
0x0000: 4500 0034 6db5 4000 4006 c9d8 84f8 7ca8 E..4m.@.@.....|.
0x0010: 84f8 7c9d 1a0a aaea 87e6 3943 eafc 4f32 ..|.......9C..O2
0x0020: 8010 01ad a900 0000 0101 080a 0f1c d2ed ................
0x0030: 4da5 d8dc M...
Y a la salida del resultado de la ejecucin respecto a la consulta:
0x0000: 4500 01de 6db6 4000 4006 c82d 84f8 7ca8 E...m.@.@..-..|.
0x0010: 84f8 7c9d 1a0a aaea 87e6 3943 eafc 4f32 ..|.......9C..O2
0x0020: 8018 01ad a185 0000 0101 080a 0f1c d2ee ................
0x0030: 4da5 d8dc 1703 0100 2044 f8f2 b7e3 ffa4 M........D......
0x0040: bcae 9e5d 22f6 e257 a223 db45 fe21 3347 ...]"..W.#.E.!3G
0x0050: c244 0dcc 734a 6abb b917 0301 0180 dbc4 .D..sJj.........
0x0060: ec92 e4f4 c9ca 37fd 0e2b 7c6c 9bf9 c746 ......7..+|l...F
0x0070: 958b eef8 3bbc a577 f1dd b038 b559 824e ....;..w...8.Y.N
0x0080: ecdd 7091 8dff 669a 8a6c 6f64 5a59 a0b9 ..p...f..lodZY..
0x0090: a0d1 3225 c2d7 49c9 0e54 6c78 f361 62ed ..2%..I..Tlx.ab.
0x00a0: 4b64 c8e4 23cb a6fb 4a93 49ca 084c 7978 Kd..#...J.I..Lyx
0x00b0: 7e05 f738 ee02 c729 4c00 82c3 03b2 5a69 ~..8...)L.....Zi
0x00c0: 643d 0ba1 834e cc9c 2bb6 4378 9ec9 378b d=...N..+.Cx..7.
0x00d0: ce40 3424 20b5 398b b43e 93d9 252f 9339 .@4$..9..>..%/.9
0x00e0: de08 a4e7 4a1e 821b 3096 c168 75cf 5416 ....J...0..hu.T.
0x00f0: 0507 82cc b05c 4af5 3e11 d6d4 9949 5e37 .....\J.>....I^7
0x0100: bb50 1eb3 9559 2eca 67d4 1f7b 3636 7f2e .P...Y..g..{66..
0x0110: b890 45aa 9cb5 e71b 5092 6c0a fcb0 fde1 ..E.....P.l.....
0x0120: 578f 31d3 4f89 0724 6cec a750 70bb f069 W.1.O..$l..Pp..i
0x0130: 286f c7ef 6c25 b51a 4577 e70f ac8d c4bc (o..l%..Ew......
0x0140: 037a 4958 e491 8d27 fffe 9788 a879 de10 .zIX...'.....y..
0x0150: 66f1 b0e5 6995 406e 9199 16ce fe71 0bf7 f...i.@n.....q..
0x0160: 3497 25e9 a11b 6720 9dda 3824 f6a2 ca9d 4.%...g...8$....
0x0170: b238 78b9 a4a3 4904 a157 5e64 4706 dc63 .8x...I..W^dG..c
0x0180: 9d45 a87e 69d2 351c eea8 5b1d 923a c816 .E.~i.5...[..:..
0x0190: efb4 f680 f15f fd09 132e 0bbc 32f9 0137 ....._......2..7
0x01a0: b4c6 c635 cc02 09bb b80e 60b7 cadc 4ce7 ...5......`...L.
0x01b0: 0864 86cd 3561 b172 0351 51c0 80a9 1bb7 .d..5a.r.QQ.....
0x01c0: 294a def8 eb33 06fb 1c53 2d75 da87 29ce )J...3...S-u..).
0x01d0: 4d12 3511 ec37 cdaf 7f6c ae60 98ee M.5..7...l.`..
Como pudimos observar en esta ltima captura de trfico, la informacin a la que se accede, es inentendible a
simple vista.
Importancia de adaptar SSL para la Seguridad en las Bases de Datos
Hasta este momento, el habilitar el cifrado en la comunicacin remota con el servidor de base de datos nos
permite poder cifrar todas las peticiones que realice el cliente desde la conexin remota. Esto no asegura que
quien obtenga la contrasea de usuario vlido en el servidor, sea quien dice ser. En otras palabras la
comunicacin es segura, pero no garantiza que el usuario autenticando sea el correcto, con un certificado
personal se disminuye aun ms el riesgo de que la cuenta sea usada por alguien con fines ajenos al propietario
y acceda al servidor de base de datos.
Generalmente se establece un nivel de seguridad de 3 capas, la primera consiste en tener la certeza de que el
sistema operativo se implementa sobre el servidor, en el que se encuentra el servicio de base de datos, la
segunda es tener acceso desde un equipo vlido al ORDBMS de acuerdo a sus mecanismos de configuracin,
y por ltimo, tener acceso a los objetos de la base de datos.
Con SSL y en especifico por medio de certificados, se puede agregar un nivel ms, donde el cliente deba
introducir una clave personal de su certificado as de no presentarse la contrasea adicional para la
comunicacin, y adems no concuerda con el servidor sencillamente no podr conectarse.
Para poder conseguir esto, el proceso a seguir es iniciar PostgreSQL en una comunicacin con SSL y pedirle
al cliente que se identifique con un certificado.
El proceso para obtener un certificado consiste en generar una solicitud de firma de certificado (CSR:
Certificate Sign Request), enviar esta solicitud a la Autoridad de Certificacin para que lo apruebe e instalar
este certificado en nuestro servidor.
Tenemos dos opciones para que los certificados sean funcionales a nuestro objetivo:
1.- Crear las solicitudes necesarias para los certificados y que una CA las apruebe .
2.- A parte de crear las solicitudes, implantamos una CA que emita certificados para nuestros fines
especficos, que es controlar la autenticacin de usuarios.
En ambos casos debemos obtener al final de todo el proceso los siguientes archivos:
Archivo root.crt. Certificado de la CA, proporcionado por dicha Autoridad.
Archivo root.crl. Lista de certificados revocados por la CA, que han expirado o han sido revocados.
Los siguientes archivos deben ser por cada cliente y cada servidor de base de datos. En donde el nombre de
los archivos del cliente debe ser caracterstico de ellos.
Archivo server.crt . Certificado emitido por la CA.
Archivo server.key. Llave privada del certificado.
Archivo server.req enviado a la CA para que sea firmado.
Crear solicitudes para que una CA nos firme los certificados
Para obtener certificados de una CA, se debe enviar una solicitud creada por nosotros, para lo cual se sigue
este proceso:
Adems de generar la solicitud del certificado, tenemos que generar un par de claves que se usarn en l. Para
ello usaremos el siguiente comando OpenSSL que se encuentra instalado disponible en el PATH del usuario:
openssl req -new -keyout priv.key -out server.req
Con el parmetro keyout estamos indicando en que fichero queremos que se guarde la clave privada. sta
deber permanecer de forma segura en el servidor. Si algn atacante logra acceder a ella, toda la seguridad
proporcionada por el SSL se comprometer.
Por defecto la clave se genera encriptada y es altamente recomendable que permanezca as en el servidor. Sin
embargo, en algunos sistemas esto puede ser un problema. Para hacer que esta clave no se genere encriptada
aadiremos a los parmetros anteriores -nodes.
Aunados a los parmetros de la ejecucin del comando anterior, se nos va a pedir una serie de datos a los que
se deber contestar con valores indicados en las polticas de certificacin de la CA, los cuales son
fundamentales para que su solicitud sea aprobada. De no coincidir, est no podr firmarlo. Para solicitar tanto
al servicio como a la persona se sigue la misma ejecucin de la solicitud.
Country Name (ISO 2 letter code): MX
State or Province Name (full name): Mexico City
Locality Name (eg, city): Distrito Federal
Organization Name (eg, company): DGSCA
Organizational Unit Name (eg, section, division): SERVERDB/UNAM-CERT
El ltimo de los datos requeridos es el Common Name, el cual vara de acuerdo al uso que se le da y a las
polticas de la autoridad certificadora para emitir certificados de servicio y personales.
Para el caso de servicio supongamos tener como poltica el DNS del servidor.
Common Name (full qualified domain name): serverdb.seguridad.unam.mx
Al tratarse de uno de persona se coloca el nombre completo.
Common Name (full qualified domain name): Nombre Apellidos
Una vez finalizada la peticin de datos se nos generar el CSR "server.req", el cual tendr el siguiente
aspecto:
-----BEGIN CERTIFICATE REQUEST-----
MIICEDCCAXkCAQAwgc8xCzAJBgNVBAYTAk1YMRkwFwYDVQQIExBEaXN0cml0byBG
ZWRlcmFsMRAwDgYDVQQHEwdVTkFNLUNVMR8wHQYDVQQKExZGYWN1bHRhZCBkZSBQ
c2ljb2xvZ2lhMS4wLAYDVQQLEyVTaXN0ZW1hIGRlIEFwcmVuZGl6YWplIGRlIE1h
dGVtYXRpY2FzMR0wGwYDVQQDExRuYWh1bS5wc2ljb2wudW5hbS5teDEjMCEGCSqG
SIb3DQEJARYUc2FtQHNlcnZpZG9yLnVuYW0ubXgwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAOv+3a2Nevh5RWH16ZYebLzkoD7QWCECetlALZuM6TgiiCYqeood
oxtUw64UNvP18iTQjbE4/2oxgD3JP3s3qvxOPOc7gAusdVThLYL2gBvd0yAcRqCj
o4M5+DhBzg0vSkbjuuAnJSTQlYzV/iMpcywJ2B4L17sXwEBJA89POyJnAgMBAAGg
ADANBgkqhkiG9w0BAQQFAAOBgQCMwSfxStSiIFYcudzS3TauNNkkIn0PY9ZotVNt
+QtyVVoL5LBt3iteY4HIbjHdynmSsckbhWZVhr1+8+WDVmP0k2IQlMLYumc3TnFD
6JDfRnIIBYJUzw7m5LD9lN4p0/LOngcChbkowNUet4CstlgZJ42xhRcGJRLmAaD9
SmAn3Q==
-----END CERTIFICATE REQUEST-----
Este archivo es lo que debe enviarse a la CA correspondiente para que sea firmado.
Una vez firmado el CSR, la CA nos devolver el certificado. Deberemos guardar el archivo del certificado.
ste y el que contiene la clave privada (priv.key) son los dos archivos necesarios para hacer funcionar el SSL
al utilizar un certificado firmado por la CA.
En resumen la CA debe proporcionarnos dos archivos: un root.crt, es decir el certificado de la CA, y un
root.crl, el cual nos mantiene actualizados en cuanto a validez de certificados, se le conocer tambin como
lista de revocacin de certificados.
Proceso completo de creacin de CA y certificados emitidos
Por otro lado si se pretende realizar la funcin de CA, el proceso de emisin de certificados con una CA
propia es el siguiente:
1)Crear una CA y enviar solicitud para el certificado de la CA:
$ /usr/share/ssl/misc/CA -newca
El resultado es el siguiente:
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 1024 bit RSA private key
.............................++++++
.......................................++++++
unable to write 'random state'
writing new private key to './demoCA/private/./cakey.pem'
Enter PEM pass phrase: capassword
Verifying - Enter PEM pass phrase: capassword
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:MX
State or Province Name (full name) [Berkshire]:Mexico City
Locality Name (eg, city) [Newbury]:Distrito Federal
Organization Name (eg, company) [My Company Ltd]:DGSCA
Organizational Unit Name (eg, section) []:SERVERDB/UNAM-CERT
Common Name (eg, your name or your server's hostname) []:caUNAM-CERT
Email Address []:ca@seguridad.unam.mx
Hay que ingresar datos importantes como el CN (Common Name) de la CA y la frase secreta para
posteriormente firmar los certificados, el resultado de este comando crea un directorio llamado "demoCA",
ubicado en el lugar en que se ejecut la instruccin para crear una CA.
Ahora hay que firmar dicho certificado:
$ openssl x509 -in cacert.pem -days 3650 -out cacert.pem -signkey ./private/cakey.pem
Getting Private key
Enter pass phrase for ./private/cakey.pem:capassword
unable to write 'random state'
Una vez creada la CA, debemos crear la solicitud de certificado del servidor PostgreSQL, el cual debe tener
los mismos datos de la CA, solo cambiamos el CN el cual debe ser el nombre del servidor y la frase secreta.
La forma de hacerlo es la siguiente:
$cd ..
$ /usr/share/ssl/misc/CA -newreq
Da como resultado algo parecido a esto:
Generating a 1024 bit RSA private key
......++++++
..++++++
unable to write 'random state'
writing new private key to 'newreq.pem'
Enter PEM pass phrase: serverdbpassword
Verifying - Enter PEM pass phrase:serverdbpassword
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:MX
State or Province Name (full name) [Berkshire]:Mexico City
Locality Name (eg, city) [Newbury]:Distrito Federal
Organization Name (eg, company) [My Company Ltd]:DGSCA
Organizational Unit Name (eg, section) []:SERVERDB/UNAM-CERT
Common Name (eg, your name or your server's hostname) []: serverdb
Email Address []:serverdb@seguridad.unam.mx
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem
Derivado de esto obtenemos un archivo newreq.pem, el cual debe firmarse como CA para ello debe recordar
la frase secreta de la misma.
$ /usr/share/ssl/misc/CA -sign
Arrojar los datos de la solicitud en donde debemos validar que cumpla, ya que verificado que todo est en
orden respondemos la pregunta que nos indica el tiempo de vida del certificado:
Certificate is to be certified until Jan 16 17:32:06 2009 GMT (365 days)
Sign the certificate? [y/n]:y
Ahora aprobamos la solicitud:
1 out of 1 certificate requests certified, commit? [y/n]y
Debemos haber obtenido el certificado del servidor en un archivo nombrado newcert.pem.
El formato de creacin de solicitud, guarda en newreq.pem tanto la solicitud como la llave del certificado, sta
ltima debe de separarse del servidor para que al iniciarlo no nos pida la palabra secreta.
Primero hacemos una copia del archivo newreq.pem en server2.key. Editamos server2.key y borramos desde
la lnea
-----BEGIN CERTIFICATE REQUEST-----
Hasta
-----END CERTIFICATE REQUEST-----
Se guardan los cambios.
Ahora ejecutamos la siguiente instruccin:
openssl rsa -in server2.key -out server.key
Y borramos el archive server2.key
$ rm server2.key
Configurar PostgreSQL para que solicite certificados a los clientes
Se renombran los archivos y newreq.pem a server.req y newcert.pem a server.crt y junto con server.key los
movemos al directorio de datos del servidor, tal y como lo hicimos anteriormente. Estos archivos son los que
auto firmamos nosotros o bien en su defecto los entregados por la CA elegida.
La diferencia ahora es copiar el certificado de la CA, el cual es: cacert.pem del directorio demoCA. O bien el
que nos proporcion la CA en formato PEM.
Y lo copiamos al directorio de datos como root.crt, se debe colocar una lista de revocacin para actualizarse
desde la CA cada vez que se quiera revocar algn certificado.
La forma de hacer la lista de revocacin es :
$ openssl ca -gencrl -out crl.pem
Y se obtiene como salida:
Enter pass phrase for ./demoCA/private/cakey.pem:
unable to write 'random state'
Tambin podemos usar la liberada por la CA ya que est actualizanda constantemente.
Copiamos el archivo crl.pem al directorio de datos como root.crl. Recuerda que todo el directorio debe tener
todos los permisos, nicamente para el dueo en octal sera algo as como 700.
Con el SSL activado en postgres.conf simplemente reiniciamos el servicio y listo, tenemos habilitado el SSL.
Ahora, para solicitar que el cliente porte un certificado debemos configurar el archivo pg_hba.conf,
tomaremos como ejemplo la lnea antes mencionada de conexin desde un host:
host serverdb egonzalez 192.168.101.125/32 md5
Esto nos permitira conectar slo como host, inclusive la comunicacin, si queremos asegurarnos que se use
un certificado debemos colocar "hostssl" :
hostssl serverdb egonzalez 192.168.101.125/32 md5
Deberemos reiniciar el servidor.
Para que el cliente pueda conectarse desde un HOST debe tener en su directorio HOME tres archivos
esenciales: postgresql.crt, root.crt y postgresql.key en un directorio llamado ".postgresql". Si no existe alguno
de estos tres archivos la conexin no se podr establecer. Es importante recordar que debemos tener instalado
un cliente psql para establecer la comunicacin.
Debemos crear el certificado por medio de la CA como lo hicimos con el servidor, solo que al realizar la
solicitud debe tener el password del usuario. Creemos el certificado para egonzalez:
Se crea con la siguiente instruccin:
$ /usr/share/ssl/misc/CA -newreq
Deben coincidir todos los datos de la CA y se enva sta para su firma o en su defecto la firmamos como CA
con:
/usr/share/ssl/misc/CA -sign
Para realizar la operacin de firmado debemos ingresar la clave de CA.
Con esto garantizamos que el usuario se responsabilice de otro mecanismo de identificacin que lo autentica
en el servidor de bases de datos.
De ser comprometida la clave del certificado del usuario, debemos rehacer la lista de revocacin de
certificados, as se garantiza una autenticacin adecuada en un nivel ms de seguridad para el ORDBMS, en
nuestro caso para PostgreSQL.
Diseo Seguro de Bases de Datos en PostgreSQL
Todo DBMS tiene la obligacin de facilitar mecanismos para prevenir los fallos (subsistema de control),
detectarlos una vez que se han producido (subsistema de deteccin) y corregirlos despus de haber sido
detectados (subsistema de recuperacin).
Con esto el DBMS debe garantizar que se cumplan los tres principios de seguridad, los cuales son integridad,
disponibilidad y confidencialidad, para lo que PostgreSQL cumple con estos principios.
La primera de dichas caractersticas es la integridad, la cual se garantiza no slo al momento de crear la base
de datos por medio del SQL en PostgreSQL, si no que debemos ir un poco ms atrs, al anlisis y diseo de la
base de datos. Un buen diseo de la base de datos ayudar a conservar la integridad de la informacin dentro
del DBMS.
Desde el diseo debemos definir el cumplimiento de los requerimientos que haga la organizacin, la
integridad radica en asegurar que los datos almacenados sean correctos, es decir verdicos, adems de asegurar
que lo que se trata de hacer es correcto. Por ejemplo, comnmente tenemos el diseo de una entidad de la
siguiente forma:
Figura 3 Estructura de una tabla
Por lo general no hay preocupacin porque la aplicacin que manipula los datos y los objetos de la base , lo
hace de forma adecuada.
Los datos deben estar protegidos contra modificaciones accidentales o maliciosas, considerando incluso la
insercin de datos falsos o la destruccin de los mismos. Dichas verificaciones deben contemplar desde los
inicios del ciclo de vida de las bases de datos. Si en un principio se elabora un diseo a la ligera, la seguridad
de la base de datos se ver comprometida.
Existen tres tipos de integridad:
Tipo de Integridad
Tipo de restriccin
Tabla
Llave Primaria (Primary Key)
Valor nico (UNIQUE)
Dominio
Verificar valor NULL
Valor por default
Verificacin de valor(Constraint de tipo Check)
Referencial
Llave Coreana (Foreign Key)
Integridad de Tabla. Cada una de las tablas que tenemos dentro del DBMS debede tener asignada una llave
primaria, es decir un campo que garantice el registro nico, con ello evitamos la redundancia.
Integridad de Dominio: Es muy importante que en la base de datos almacenemos exactamente lo deseado. Por
medio de clusulas SQL como Constraints de tipo Check, valores nulos y valores por default.
Integridad referencial: Este tipo de integridad garantiza que los registros se integren de forma adecuada en las
tablas, sin violar el principio bsico de las bases de datos relacinales.
Un ejemplo creado con SQL para mostrar los principios bsicos de la creacin de una tabla es el siguiente:
CREATE TABLE usuario (
idusuario serial NOT NULL PRIMARY KEY ,
login VARCHAR(16) NULL check(trim(login) <> '') UNIQUE,
pass VARCHAR(32) NOT NULL ,
nombre VARCHAR(50) NOT NULL check(trim(nombre) <> ''),
ap_paterno VARCHAR(50) NOT NULL check(trim(ap_paterno) <> ''),
ap_materno VARCHAR(40) NULL check(trim(ap_materno) <> ''),
fecha_registro timestamp not null default now() check (fecha_registro > '2008-01-01'),
correo VARCHAR(100) NOT NULL check( correo ~ '[a-z0-9_]+@[a-z0-9_](.?[a-z0-9_]+)*') unique,
sueldo float not null default 10000 check(sueldo > 0 and sueldo < 15000)
);
En la creacin anterior de la tabla se contemplan las siguientes clusulas:
PRIMARY KEY : Identificador nico del registro.
NOT NULL: Nos obliga a ingresar algo en el campo.
NULL: el campo puede ser nulo.
DEFAULT: Es un valor por default en caso de no poner uno.
CHECK: realiza validaciones de dominio, por ejemplo una expresin regular para el correo electrnico
verifica que no se ingresen espacios en blanco.
A veces esta parte es muy descuidada por los analistas y/o diseadores de la base de datos, dejando la tarea de
validar este tipo de cosas al desarrollador de alguna aplicacin que explota los datos, por lo que no es
recomendable hacerlo.
Al hacer un buen diseo de la base de datos y especificar los tipos de datos y sus dominios, PostgreSQL es
capaz de garantizar que en la Base de Datos pueda controlarse la redundancia a su mnima expresin,
manteniendo consistente la base de datos y as conseguir la integridad de los datos que se persigue en un
inicio. Parte importante de la Seguridad en Base de datos es hacer estas validaciones desde el RDBMS.
PostgreSQL puede echar mano adems de las clusulas bsicas de creacin de las bases de datos, de otra
caracterstica que tiene, los Trigger los cuales son programas que se disparan en cuanto se realiza una cierta
accin, son de gran utilidad cuando queremos evitar que la accin realizada ponga en riesgo la integridad de
los datos o para identificar posibles problemas. Por ejemplo, la modificacin inapropiada de datos por parte de
algn usuario.
Existen diferentes lenguajes que nos pueden ayudar a la elaboracin de un trigger, el que est instalado por
default en PostgreSQL es el PL/PGSQL solo hay que habilitarlo.
Una vez garantizado o al menos disminuido elel riesgo de que la base de datos pierda su integridad, se debe
evaluar el tipo de datos almacenados y quienes van a acceder a determinada informacin producida.
Un ejemplo de uso de triggers es almacenar las acciones realizadas inapropiadamente por los usuarios en la
modificacin de informacin de la base de datos. Retomando el ejemplo de la tabla usuario, cada uno tiene
asignado un sueldo, puede haber cambios de aumento en la cantidad del sueldo por usuarios
malintencionados, entonces debemos tener un mecanismo que detecte quin incremento la cantidad.
Realizamos el insert de un usuario llamado jortiz el cual tiene asignado un sueldo de $12,000 pesos.
INSERT INTO usuario(login,pass,nombre,ap_paterno,ap_materno,fecha_registro,correo,sueldo) VALUES
('jortiz',md5('jortiz'),'juan','ortiz','ortiz','2008-02-12','jortiz@seguridad.unam.mx',12000);
Ya que tenemos dicha informacin vamos a establecer un mecanismo que establezca quin modific ese
registro y as tener un mecanismo de deteccin de falta de integridad.
Idealmente nuestra base de datos debe ser ntegra y consistente al crearla, antes de ponerla en produccin, en
ese momento se detectarn todos aquellos cambios que se hagan a la informacin, por ejemplo un incremento
en el sueldo de algn usuario y el usuario de postgresql que realiz los cambios y qu datos se cambiaron.
Primero creamos una tabla alterna llamada usu_audit:
CREATE TABLE usu_audit(
operation char(1) NOT NULL,
stamp timestamp NOT NULL,
userid integer NOT NULL,
usunombre text NOT NULL,
sueldo_anterior float not null,
sueldo_nuevo float not null
);
Ahora vamos a crear un lenguaje para la base de datos, dentro de ella ejecutamos:
CREATE LANGUAJE plpsql;
Creemos una funcin que se ejecute al momento de modificar la tabla usuario, sta deber realizar un insert en
la tabla usu_audit.
CREATE OR REPLACE FUNCTION funcion_usu_audit() RETURNS TRIGGER AS E'
BEGIN
IF (TG_OP = \'DELETE\') THEN
INSERT INTO usu_audit SELECT \'D\', now(), user, OLD.idusuario,OLD.sueldo;
RETURN OLD;
ELSIF (TG_OP = \'UPDATE\') THEN
INSERT INTO usu_audit SELECT \'U\', now(), user, NEW.idusuario,NEW.sueldo;
RETURN NEW;
ELSIF (TG_OP = \'INSERT\') THEN
INSERT INTO usu_audit SELECT \'I\', now(), user, NEW.idusuario,NEW.sueldo;
RETURN NEW;
END IF;
RETURN NULL;
END;
'LANGUAGE plpgsql;
Con esto slo falta crear nuestro trigger, el cual se ejecutara al hacer un insert, update, o delete de la tabla
usuario.
CREATE TRIGGER usu_audit
AFTER INSERT OR UPDATE OR DELETE ON usuario
FOR EACH ROW EXECUTE PROCEDURE funcion_usu_audit();
Al hacer una actualizacin de los registros de la tabla usuario, por ejemplo el de nuestro insert anterior, se
registrar en la tabla usu_audit, esto nos permitir detectar posibles inconsistencias de la informacin dentro
de la base de datos.
En este ejemplo cuidaremos los sueldos que tienen asignados los usuarios. Por ejemplo si un usuario puede
actualizar los datos de la tabla o modificar el sueldo de alguno debemos saber cundo lo hizo, quin lo hizo y
as controlar los cambios autorizados y no autorizados.
El sueldo anterior es de 12000.
UPDATE usuario SET sueldo=13000 where idusuario=2;
En la tabla audit se registrarnlos movimiento hechos y a cules registros. Esto se debe hacer sobre la
informacin con mayor grado de sensibilidad dentro de la base de datos
operation | fecha_modificacion | usuario_modifico | idusuario | sueldo
-----------+----------------------------+------------------+-----------+--------
U | 2008-02-13 11:55:17.431217 | dba | 2 | 13000
U | 2008-02-13 12:00:07.664966 | egonzalez | 2 | 13500
Esto debe estar ligado a las polticas establecidas en la organizacin.
En una base de datos pueden almacenarse tres tipos de datos:
Solamente datos sensibles
Solamente datos pblicos
Con ambos tipos de datos
Ya que sabemos qu tipos de datos estn dentro de la base de datos es momento de evaluar los usuarios que
accedern a ella, desde qu lugar de la organizacin se conectaran, de qu forma van a explotarlos, etc.
Sin duda lo ms importante es considerar a los usuarios que accedern a la informacin, qu nivel de
conocimiento tcnico tienen y qu informacin van a consultar, extraer, modificar, etc.
La segunda caracterstica de la seguridad informtica es la confidencialidad, la cual aplica directamente a las
bases de datos y consiste en permitir al usuario acceder a informacin que puede ver y negarle el acceso a
quien no tiene privilegios de acceder.
Como ya hemos visto, el acceso que se tiene a los datos pasa por un mecanismo de autenticacin denominado
multicapas, es decir por reglas del servidor, del DBMS y finalmente de accesos a los objetos establecidos por
el dueo de la base de datos. Entindase por dueo de la base de datos a la persona encargada de su
proteccin.
Para hacer esto PostgreSQL permite hacer uso de las sentencias REVOKE y GRANT en donde se revocan y
otorgan privilegios respectivamente. Las instrucciones son relativamente sencillas de construir y ejecutar.
GRANT privilegio [, ...] ON objecto [, ...]
TO { PUBLIC | nombre_usuario | GROUP nombre_grupo }
REVOKE privilege [, ...] ON object [, ...]
FROM { PUBLIC | nombre_usuario | GROUP groupname }
Para conocer qu privilegios se asignan a cada usuario debemos crear algo que se llama matriz de control
accesos a las bases de datos, en la cual aparecen del lado izquierdo los usuarios que accedern a la
informacin y en la parte superior los posibles privilegios que puede tener sobre los objetos dentro de la base
de datos, por ejemplo:
Tabla Usuario:
Usuarios Select Usuario Insert sobre Usuario Update Sobre Usuario Alter sobre Usuario
gmartinez X X X X
egonzalez X
hgalvez X
prios X
Para poder ayudar a mantener la confidencialidad de la informacin se recomienda la creacin de vistas para
que los usuarios menos privilegiados puedan hacer slo lecturas de cierta informacin disponible, y as
mantener su confidencialidad.
Una vista se crea de la siguiente forma:
create view v_usuarios as (select login,correo from usuario);
La seguridad de base de datos debe garantizar la disponibilidad de los datos a aquellos usuarios que tengan
derecho al acceso , por lo que se proporcionan mecanismos que permitan recuperar la Base de Datos contra
fallos lgicos o fsicos que destruyan los datos en todo o alguna parte de ellos.
Para mantener la disponibilidad de un servidor de base de datos se tiene un principio bsico: la redundancia
fsica. En l se apoya la recuperacin de los datos ante cualquier falloredundancia fsica. Un par de problemas
que pueden llegarse a presentar y poner en riesgo la disponibilidad de la informacin son:
*Prdida de memoria voltil, provocada por la interrupcin del suministro elctrico o por
funcionamiento anormal del hardwarey,

* Prdida del contenido de memoria secundaria.
Lo importante ante cualquier tipo de fallo es asegurar que, despus de una actualizacin, la BD se quede en un
estado consistente. Por definicin, la Base de Datos se encuentra en este estado antes de que se ejecute una
transaccin y deber recobrarlo al concluir sta.
Las propiedades principales que debe poseer una transaccin son:
Atomicidad.
Preservacin de la consistencia.
Aislamiento. Una transaccin no muestra los cambios que produce hasta que finaliza.
Persistencia. Una vez que la transaccin finaliza con xito, sus efectos perduran en la BD.
Las sentencias de que consta la transaccin debern, por tanto, deshacerse (rollback) en caso de no ser
concluidas satisfactoriamente. De darse este caso, las actualizaciones de que consta la transaccin se graban
(commit) si termin con xito. Esto se puede implementar como medida de seguridad para la consistencia de
la base de datos.
PostgreSQL soporta transacciones clsicas mediante las sentencias.
COMMIT y ROLLBACK
Sin duda, una parte fundamental para mantener disponible la informacin es respaldar los datos que se
encuentran en la base de datos. Para ello PostgreSQL permite realizar dos tipos de respaldos, los cuales se
deben adaptar de acuerdo a las polticas de respaldo implementadas por la organizacin.
Estos tipos de respaldos son llamados comnmente respaldos en fro y caliente. El primerohace una copia de
las estructuras fsicas de las bases de datos cuando stas no estn disponibles a los usuarios. La copia de los
datos se hace a travs de las utileras del DBMS o comandos del Sistema Operativo tales como tar, cp, cpio,
etc.Mientras, el otro se realiza cuando la BD est abierta y funciona el mecanismo de LOG. Consiste en copiar
todos los archivos de LOG correspondientes a un directorio determinado.
De acuerdo a las necesidades de cada una de las organizaciones se debe elegir un tipo de respaldo que desea
realizarse. Para poder escoger el que ms adecuado a las necesidades de la organizacin, y elegirlo
correctamente, debemos primero conocer cules son los tipos de respaldos que ofrece PostgreSQL.
Disponibilidad basada en un respaldo global (full back-up)
Este tipo de respaldo es tambin conocido como respaldo en fro, pensado para hacer el respaldo cada cierto
tiempo, en caso de ocurrir una prdida total de todas las bases de datos, o por un problema tcnico del
servidor. Este tipo de respaldo se puede realizar en un solo archivo de todas las bases de datos en conjunto o
de forma individual.
Para poder realizar un respaldo completo de todas las bases de datos del RDBMS PostgreSQL se debe usar la
siguiente sentencia:
pg_dumpall [option...] > backup.psql
donde algunas opciones son :
-h host
-d datos en forma de instert
-U usuario
La opcin para crear un respaldo de una sola base de datos es la siguiente:
pg_dump [option...] dbname > backup.psql
donde dbname es el nombre de la base de datos.
las opciones puedes ser distintas las ams importantes son:
-h host
-d datos en forma de instert
-U usuario
Disponibilidad basada en respaldos incrementales
Este tipo de respaldo nicamente se encarga de crear respaldos peridicos de los cambios realizados desde el
ltimo respaldo hecho hasta el momento de hacer uno nuevo, trabaja independientemente del DBMS usado,
partiendo de un respaldo total. Registra en archivos de log todas las transacciones hechas a las bases de datos.
El log de transacciones agrupa en archivos binarios todos los cambios realizados durante el periodo activo. En
otras palabras, almacena las transacciones hechas en cierto tiempo, se depura despus de ste y forma
pequeos archivos.
La idea principal, tras este backup , es utilizar los archivos de bitcora de PostgreSQL para hacer la copia de
seguridad, los cuales se localizan en el directorio de datos, en el subdirectorio llamado pg_xlog. Esto
funcionara de la siguiente forma:
Configurar el archivo postgres.conf ubicado en el directorio de datos para que acepte respaldos
incrementales.

Hacer un backup base o total al momento de activar el sistema.
Guardar los archivos de bitcora utilizados desde el backup base.
Verificar que se almacene el archivo WALL en uso.
Para habilitar el mecanismo provisto en el DBMS para guardar los archivos de bitcora, basta indicarle al
PostgreSQL qu comando utilizar para conservar el archivo de bitcora. De no indicarlo el DBMS
simplemente recicla los archivos de bitcora, usando uno a la vez y regresando al primero despus del ltimo.
Para esto slo es necesario indicar la variable:
archive_command = 'cp -i %p /backup/directorio/%f </dev/null'
El cual guarda el archivo de bitcora en /backup/directorio. Existe la posibilidad de comprimir el archivo con
algn compresor.
En el segundo paso debemos de conectarnos a la base de datos principal como DBA y ejecutar el siguiente
query , indicando al manejador que haremos un backup base:
SELECT pg_start_backup('backupbase');
La etiqueta "backupbase" es cualquier nombre que identifique el backup. Lo siguiente es hacer la copia fsica
de los datos, es decir, hacer un backup en fro de todo el directorio de datos.
$cd /usr/local/pgsql$ tar -exclude=data/pg_xlog -zcvf data_fecha.tar.gz data
Para este backup no hay necesidad de bajar el DBMS. Al finalizarlo debemos indicarle al DBMS esto,
entonces ejecutamos:
SELECT pg_stop_backup();
Ahora en el directorio /backup/directorio quedaran los archivos WAL (otra forma de decir Write Ahead Log),
o tambin llamados , archivos de bitcora. Cuando los archivos de bitcora se llenen se respaldaran en el
directorio /backup/directorio, de no llenarse se podra usar una opcin del postgres.conf para hacer la copia
cada cierto tiempo sin esperar a que esto suceda.
archive_timeout = ##
Donde ## es el nmero de segundos de espera antes de ejecutar el vaciado de archivos.
Para realizar esto ltimo, debemos copiar el ltimo archivo en uso del directorio pg_xlog para asegurarnos
que no se pierda ningn dato.
Configurar PostgreSQL para usar respaldos incrementales
Para poder comenzar a hacer uso de los respaldos incrementales se deben adecuar a PostgreSQL, para ello
tenemos ubicado PostgreSQL en las siguientes rutas de instalacin:
/usr/local/serverdb instalacin del servidor PostgreSQL
/dataserver directorio de las bases de datos.
Una vez conocidos estos datos esenciales, podemos empezar a configurar los servidores para que acepten
respaldos incrementales. El directorio comn de archivos de respaldo debe estar en la misma mquina del
servidor de base de datos, lo cual no es muy recomendable, debido a que si llega a ser comprometido el
servidor, se podra perder el acceso a ellos. Por tal motivo, se recomienda hacer un script que copie los
respaldos a un servidor remoto de respaldos.
Se crea en el directorio general de backups /db/backups un directorio para los respaldos de PostgreSQL
llamado pgsql.
$ mkdir /db/backups/pgsql
Se debe tener el DBMS sin dar servicio,es decir sin iniciarse. Lo primero que se debe hacer es configurar el
archivo postgres.conf agregando un par de lneas.
La primera indica que se copiaran los archivos log a un directorio ya definido para los backups, el cual ser
dueo:
archive_command = 'test ! -f /db/backups/pgsql/%f.gz && gzip -1 -c %p > /db/backups/pgsql/%f.gz'
Tambin se le indica que va a comprimir los archivos log con el comando gzip.
La segunda lnea es requerida para poder controlar el tiempo de almacenamiento de los cambios, ya que por
default se guardan hasta que el log binario se llena.
archive_timeout = 3600
Ahora basta con iniciar el servicio, es importante hacerlo con su respectiva bitcora, para lograrlo se realiza la
siguiente instruccin:
$ /usr/local/sql/bin/postmaster -i -D /db/pgsql > /var/log/serverlogdb 2>&1 &
Una vez que se ha inicializado se debe realizar un respaldo completo del directorio de datos con una
herramienta del sistema de archivos, este respaldo no debe incluir el directorio pg_xlog del directorio de datos
que en este caso es /db/backups/pgsql.
$cd /db/backups
Antes de hacer el respaldo se debe indicar a PostgreSQL que va hacer un respaldo total en fro del DBMS, es
decir sin darlo de baja. Se realiza con la siguiente instruccin :
SELECT pg_start_backup('backupbase');
ahora realizamos el backup en fro:
$ tar -exclude=pgsql/pg_xlog -zxvf /db/backups/pgsql/backup_pgsql_completo_fecha.tar.gz pgsql
y concluimos la realizacin del respaldo;
SELECT pg_stop_backup();
Con esto estamos garantizando por lo menos el almacenamiento de los cambios hechos cada hora en las bases
de datos, estableciendo unas polticas adecuadas disminuimos el riesgo de que la informacin solicitada por
los usuarios pierda su disponibilidad. Debemos poner nfasis en el mecanismo establecido para copiar el
respaldo completo y los pequeos fragmentos del log que se almacenan en /db/backups/pgsql para evitar
posibles complicaciones con la disponibilidad.
Conclusiones
Es imposible que un DBMS, o en este caso un ORDBMS, por si solo nos garantice que ser totalmente
seguro, son muchos los factores que pueden intervenir para conseguir disminuir el riesgo de que nuestro
servidor sea comprometido, o que no cumpla con alguno de los tres principios de seguridad para la
informacin.
Lo que si podemos asegurar es realizar una instalacin adecuada cuya parte fundamental para comenzar a
cimentar es la buena administracin de las bases de datos, aunado a una buena configuracin, para as cubrir
los huecos ms comunes y frustrar los intentos de acciones indebidas.
Revisin histrica
Liberacin original: 15 de Febrero de 2008
ltima actualizacin y revisin: 15 de Febrero de 2008
El Departamento de Seguridad en Computo/UNAM-CERT agradece el apoyo en la elaboracin de este
tutorial a:
Eduardo Gonzlez Martnez (egonzalez at seguridad.unam.mx)
El Departamento de Seguridad en Computo/UNAM-CERT agradece la coordinacin y revisin de este
tutorial a:
Alejandro Nuez Sandoval (anunez at seguridad.unam.mx)
Revisin histrica
Liberacin original: 15-Feb-2008
ltima revisin: 1 de octubre de 2010
El Departamento de Seguridad en Computo/UNAM-CERT agradece el apoyo en la elaboracin y revisin de
este documento a:
Eduardo Gonzlez Martnez
Alejandro Nuez Sandoval
Galvy Cruz Valencia
Andrs Leonardo Hernndez Bermdez
Para mayor informacin acerca de ste documento de seguridad contactar a:
UNAM CERT Equipo de Respuesta a Incidentes UNAM
Departamento de Seguridad en Cmputo DGSCA - UNAM
E-Mail:seguridad@seguridad.unam.mx
http://www.cert.org.mx
http://www.seguridad.unam.mx
ftp://ftp.seguridad.unam.mx
Tel:56 22 81 69
Fax:56 22 80 43