Archive

Archive for the ‘Seguridad’ Category

Autenticación Oracle Enterprise Linux 6 con Active Directory

diciembre 22, 2016 Deja un comentario

Una de las principales necesidades crecientes de hoy en día es la seguridad en los sistemas y todo lo que ello conlleva, como la trazabilidad de los accesos a los sistemas, el envejecimiento de las contraseñas y la simplificación de la gestión de los usuarios.

Una de las formas de resolver estos objetivos, en nuestros sistemas unix, es la autenticación a través de entidades externas como LDAP o Active Directory (LDAP).

Para ejemplificarlo, presentamos un caso práctico de como autenticar Oracle Enterprise Linux 6 a través de Active Directory por medio de System Security Services Daemon (SSSD).

System Security Services Daemon (SSSD) es un servicio que pretende ofrecer una interfaz para NSS y PAM única, desde la que administrar el acceso remoto a directorios LDAP y a múltiples mecanismos de autenticación desde un único punto. Este servicio es un elemento fundamental en FreeIPA (el proyecto de identity-manager de RedHat, basado en su LDAP y no en OpenLDAP).

Se trata de disponer de un servicio independiente de nss que se encargue de las búsquedas en LDAP, Kerberos, etc. y que, además, si en algún momento se detuviera, el sistema no se ralentizaría.

Ventajas de SSSD

 

  • Greater extensibility
  • Multiple concurrently available identity stores
  • ID collision management features
  • SSL/TLS or SASL/GSSAPI is required
  • Single configuration file
  • Reduced server loads
  • Offline authentication

 

Proveedores SSSD

 

Local                      Accounts are kept in a local database

LDAP                      Relies on installed extensions of target directory

Kerberos                 Relies on installed extensions of target directory

AD                          Supports many native Active Directory® features

 

Arquitectura de una integración Active Directory con SSSD:

Integrating Red Hat Enterprise Linux 6 with Active Directory

Leer más…

Categorías:Seguridad Etiquetas: ,

Intercambio seguro de datos con Oracle Database

Uno de los puntos de seguridad que se suelen olvidar a menudo es el intercambio de datos entre servidores. Se dedican muchos esfuerzos a proteger los datos en la misma base de datos (con políticas de usuarios y contraseñas, herramientas de cifrado de datos, segregación de funciones, auditoría, etc.) pero por otro lado se permite que estos datos circulen libremente y en texto plano por la red, cuando existen múltiples herramientas para capturar y modificar esta información.

Un usuario malintencionado podría capturar datos en tránsito, modificarlos y retransmitirlos. Por ejemplo, podría capturar todos los datos de las tarjetas de crédito para usarlos posteriormente. También podría capturar un depósito de cierta cantidad en una cuenta bancaria, modificar el importe y/o la cuenta de destino y retransmitir esta información, o retransmitir de manera continua la información de este depósito para multiplicar el importe recibido.

Debido a esto, es muy recomendable añadir seguridad en las comunicaciones si queremos tener un entorno más protegido. Esta seguridad puede implicar controles de cifrado e integridad de los datos: de cifrado para que la información viaje sin que terceras partes puedan verla tal cual y de integridad para que nadie pueda modificarla.

Para configurar el cifrado y la integridad de los datos en las comunicaciones entre servidor de base de datos y clientes, es necesario modificar el fichero ‘sqlnet.ora’. Esto se puede hacer manualmente o mediante la herramienta Oracle Net Manager como se muestra en las siguientes capturas:

cifrado Leer más…

Escalado de privilegios – Apache/OHS, permisos y granularidad insuficiente

escalera El errante viaje del profesional que se dedica a la consultoría esta repleto de curiosidades, poder ver tantas casas diferentes, métodos, preocupaciones y un sinfín de quehaceres hace que las pequeñas partes homogéneas resalten dentro de esa heterogeneidad. Normativas, estándares, auditorías de seguridad, cada cual más ensortijada.

En lo que a la parte de seguridad atañe, la costumbre más global es:

  • Acceso root prohibido.
  • Auditar todos los accesos o “switch” entre usuarios.
  • Guardar todo el historial.
  • Bits uid, gid, desactivados (muchas veces no puedes ni usar el ping).
  • Particiones “comunes” montadas con noexec.
  • etc.

La mayoría de estos aspectos son razonables, de hecho, particularmente opino que todavía podría elevarse el modo “paranoico”; pero en muchas ocasiones los árboles no nos dejan ver el bosque. En abundantes sistemas nos podemos encontrar que por un lado, se lleva una excelente tarea de auditoría, prevención y seguridad, pero por el otro se descuidan aspectos muy básicos: las ‘capabilities‘ de seguridad que nos proporciona el sudo y su dejada configuración.

Desventuradamente he tenido la ocasión de encontrarme, de manera recurrente, una configuración insuficientemente granulada de las reglas de sudo que permiten autenticas “atrocidades”; éstas quizá pueda atribuirse a descuidos, desidia, comodidad, desconocimiento…

Presentamos un escenario real, donde un usuario sin prácticamente permisos, puede llegar a maximizarlos de una manera mayúscula a partir de una mala configuración del sudoers.

Como de costumbre, adentrémonos a la parte práctica:

Sistema con usuario de servicio sin privilegios (o por ejemplo, operador), sin posibilidad de root, en una máquina con un apache corriendo por el puerto 80, sin privilegios para modificar la configuración del servicio pero con la posibilidad de levantar, parar o reiniciar el proceso.

La primera cosa sobrante a destacar, es que se debería evitar utilizar servicios que tengan que asociarse a puertos privilegiados (inferiores a 1024) ya que esto obliga a levantar el proceso de escucha con usuario privilegiado; maneras de evitarlo hay varias, establecer una capa frontal con un balanceador (o similar), mapeo de puertos, iptables, etc.

Comprobamos como está el apache (httpd):

986345609-apache_root_proc

Vemos que el proceso padre con PID 1725 está levantado con un uid de root y los procesos hijo como apache. Esto es necesario, como se ha comentado, para poder hacer el bind al puerto 80:

2459772857-listen_80_apache

Leer más…

Fugas de información en JVM Heap Dumps – Extracción de claves privadas

Abundantes son las prácticas que se implementan en el mundo empresarial para prevenir fugas de información. Estas van des del control de malware, pasando por las auditorías, análisis de riesgos y terminando en procesos de prevención de escape involuntario de datos. Un factor muy importante es la custodia y tratamiento de ficheros digitales, en este artículo nos centraremos en los volcados de memoria (aka Heap Dumps) de las JVMs.

Por un lado, numerosos son los escenarios y derivados en los que entra en juego la extracción de un Java Heap Dump:

por otra parte, muchos son los episodios en los que la insuficiencia de prudencia y prominente descuido hacen que dichos ficheros:

  • Se distribuyan a terceros sin un procedimiento firme del uso de la información. En ocasiones, en los procesos de gestión de problemas frente a incidentes recurrentes dentro de los marcos enumerados se asignan las tareas de análisis a terceros proporcionando los heap dumps sin ser totalmente conscientes de la información implícita que se está cediendo.
  • Se pierdan entre máquinas. ¿Cuántos heap dumps no hemos encontrado en directorios intermedios, de backup, temporales (que luego se quedan allí), e incluso en directorios destinados a la rotación de logs? ¿Cuántos en máquinas “multiuso” porque el entorno donde hemos generado el dump es productivo y no debemos “malgastar” recursos en tareas costosas de análisis y que luego allí se han quedado? ¿Cuántos en los portátiles nominales? (y un largo etcétera).

Para darle el énfasis necesario a la materia y concienciación, vamos a realizar una prueba de concepto, en un escenario de laboratorio, ficticio, controlado, pero extrapolable; extrayendo uno de los datos digitales más privados y preservados que podría tener una organización (su clave privada), a partir de un heap dump sacado de una JVM que corre un WebLogic Server como servidor de aplicaciones.

PoC

Buscamos el proceso java y extraemos un heap dump.

2325797377-heap_dump

Lo portamos a local (si es necesario) para depurar mejor.

825383641-scp

Leer más…

Categorías:Seguridad Etiquetas: , ,

OHS12c vs privilege ports (<1024)

octubre 30, 2015 Deja un comentario

En versiones previas a la 12c, para poder configurar la recepción de solicitudes por los puertos inferiores a 1024, “bastaba” con modificar los puertos en los ficheros de configuración y con ejecutar apache con permisos root realizando lo siguiente:

cd ORACLE_HOME/ohs/bin
chown root .apachectl
chmod 6750 .apachectl

En la versión 12c este procedimiento ha variado especialmente en lo que refiere a los ejecutables, los ficheros de configuración del OHS se ubican en el directorio $DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1.  Aquellos que nos interesan para modificar los puertos son los mismos que en la versión anterior “httpd.conf” y “ssl.conf”.

Para empezar a enviar peticiones en puertos inferiores al 1024 (por ejemplo usando el puerto 443 para conexiones seguras), y tras modificar los ficheros de configuración, será necesario ejecutar las siguientes acciones:

Con los componentes OHS parados y conectados con el usuario propietario de los binarios (“oracle” en nuestro caso).

[oracle@prueba_host ohs1]$ echo `id -ng`: bind > /tmp/cap.ora
[oracle@prueba_host ohs1]$ cat /etc/cap.ora
oracle: bind

Estos comandos almacenan en un fichero los datos del propietario de los binarios y el tipo de permiso que le queremos dar (en este caso el de “bind”).

Acto seguido y como root, modificaremos los permisos y propietario de los ficheros “hasbind” y “cap.ora” y trasladaremos este ultimo a su ubicación definitiva en la carpeta /etc.

chown root $ORACLE_HOME/oracle_common/bin/hasbind
chmod 4755 $ORACLE_HOME/oracle_common/bin/hasbind
cp /tmp/cap.ora /etc/cap.ora
chmod 644 /etc/cap.ora
chown root /etc/cap.ora

Tras estas acciones se debería poder iniciar los procesos de OHS, pero debido a un bug no resuelto en las versiones 12.1.x, veremos las siguientes entradas al intentar iniciar el ohs:

$DOMAIN_HOME/bin/startComponent.sh ohs1 storeUserConfig
Starting system Component ohs1 ...

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Reading domain from /u01/Middleware/OHS12c/user_projects/domains/ohs_domain

Using existing user key file...
The username and password that were used for this WebLogic NodeManager connection are stored in /home/oracle/.wlst/nm-cfg-ohs_domain.props and /home/oracle/.wlst/nm-key-ohs_domain.props.
Connecting to Node Manager ...
Successfully Connected to Node Manager.
Starting server ohs1 ...
Error Starting server ohs1: weblogic.nodemanager.NMException: Received error message from Node Manager Server: [Server start command for OHS server 'ohs1' failed due to: [Failed to start the server ohs1
Check log file /u01/Middleware/OHS12c/user_projects/domains/ohs_domain/system_components/OHS/ohs_nm.log
Check log file /u01/Middleware/OHS12c/user_projects/domains/ohs_domain/servers/ohs1/logs/ohs1.log]. Please check Node Manager log and/or server 'ohs1' log for detailed information.]. Please check Node Manager log for details.
Successfully disconnected from Node Manager.

Exiting WebLogic Scripting Tool.

Done

Leer más…

Categorías:Seguridad Etiquetas: ,

Transparent Data Encryption – Cifrar por columna o tablespace

Transparent Data Encryption (TDE) es la opción de seguridad que proporciona Oracle para cifrar los datos a nivel de sistema operativo. En este post hice una pequeña introducción de este producto y dentro del Oracle Security Tour hablamos más en profundidad sobre él, en concreto en el webinar desde la óptica de la regulación.

Cuando se desea cifrar los datos de la base de datos con TDE, una de las primeras cuestiones que se plantea es qué tipo de cifrado aplicar.

TDE puede cifrar a nivel de columna o de tablespace.

Tipos de cifrado

Tipos de cifrado

 

En el cifrado a nivel de columna se elige qué columna o columnas, de qué tabla o tablas se desean cifrar, y se aplica el cifrado. En el cifrado a nivel de tablespace se crea un tablespace cifrado y todos los objetos que se creen o se muevan ahí estarán cifrados. Cada uno tiene sus ventajas, inconvenientes y puntos a tener en cuenta, que se resumen en la siguiente tabla:

CIFRADO DE COLUMNA CIFRADO DE TABLESPACE
Se conoce dónde está la información sensible Se desconoce dónde está la información sensible
Menos del 5% de las columnas de la aplicación son candidatas a cifrarse La mayoría de los datos de la aplicación se han definido como sensibles o aplica algún tipo de legislación vigente
El tipo de datos y la longitud están soportados por cifrado de columna No todos los tipos de datos que contiene está soportados por cifrado de columna
Las columnas candidatas a ser cifradas no son claves ajenas Las columnas candidatas a ser cifradas son claves ajenas
Los índices sobre las candidatas son índices b-tree normales Los índices de las candidatas a ser cifradas son índices funcionales
La aplicación no realiza escaneos de rango sobre los datos cifrados La aplicación realiza búsquedas por rangos sobre los datos sensibles
Es aceptable un incremento de almacenamiento de 1 a 52 bytes por valor cifrado No es aceptable un incremento en la ocupación de almacenamiento
El impacto en el rendimiento depende del porcentaje de columnas cifradas, con qué frecuencia los valores cifrados son seleccionados o actualizados, el tamaño de los datos cifrados y otras variables Se desea tener un impacto constante de rendimiento por debajo del 10%
Se desea beneficiarse de aceleración de cifrado por hardware
Se desea beneficiarse de cifrado y compresión al mismo tiempo

Transparent Data Encryption – Creación de wallets

Cuando se desea cifrar la información dentro de una base de datos Oracle, se recomienda usar el producto Transparent Data Encryption (TDE) que forma parte de Advanced Security Option (ASO). Esta opción de la BBDD, como su nombre indica, permite cifrar los datos de manera “trasparente” para las aplicaciones, esto es, que las aplicaciones sigan accediendo a los datos normalmente (como lo hacían antes del cifrado): no es necesario modificarlas ni adaptarlas, pero a nivel de sistema operativo/backups los datos quedan almacenados en forma cifrada, evitando que si alguien tienen acceso a ellos pueda extraer la información. ASO es una opción disponible en Oracle Database Enterprise Edition.

Arquitectura TDE

TDE es capaz de utilizar diferentes algoritmos al cifrar la información y todos ellos hacen uso de una clave de cifrado maestra (Master Encryption Key). Esta clave se guarda en un almacén externo de claves (keystore) que puede ser hardware o software. En sqlnet.ora se indica dónde está el almacén de claves y de qué tipo es. Es altamente recomendable hacer backup del almacén de claves al mismo tiempo que se hace backup de la base de datos.

A continuación vamos a hablar de las opciones existentes para crear un almacén de claves software en nuestro entorno, consistentes en hacer uso de wallets de Oracle. Existen 3 tipos de wallets (Password-based, Auto-login y Local auto-login) y se deberá escoger dependiendo de las necesidades de cada entorno. El siguiente paso sería cifrar la información de nuestra base de datos, pero eso ya cae fuera del alcance de este post.

Nota: Todos los ejemplos se han realizado en una base de datos 11gR2 Enterprise Edition.

1) Password-based
Los wallets basados en password o password-based necesitan de su apertura explícita con una contraseña antes de poder ser usados. Si no se hace así, al intentar acceder a los datos cifrados la base de datos da el error ‘ORA-28365: wallet is not open’.

Hay que diferenciar entre la contraseña para abrir el wallet y la Master Encryption Key. La primera es la que nos permite acceder al contenido del wallet y hacerlo disponible a la base de datos. La segunda es la que se utiliza para cifrar los datos de la base de datos. Pueden ser iguales, aunque se recomienda que ambas sean contraseñas complejas y diferentes.

Para crear un wallet de este tipo se puede hacer de dos formas. La primera ejecutando desde sqlplus:

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "password";

Lo que esta sentencia hace realmente es asignar la Master Encryption Key al wallet. Dado que no tenemos un wallet definido en nuestro entorno, lo crea con la Master Encryption Key especificada en una ruta por defecto (ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet o también ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet) que no es necesario registrar en el fichero sqlnet.ora. El password para abrir el wallet y la Master Encryption Key serán idénticos.

Si cuando se crea el wallet de esta manera da el error ‘ORA-28368: cannot auto-create wallet’, suele ser porque no existen los directorios y es necesario crearlos manualmente. Una vez creado, se puede consultar información del wallet en la vista V$ENCRYPTION_WALLET:

SQL> select * from V$ENCRYPTION_WALLET;

WRL_TYPE             WRL_PARAMETER                                                STATUS
-------------------- ------------------------------------------------------------ ------------------
file                 /u01/app/oracle/product/11.2.0/dbhome_2/admin/orcl/wallet    OPEN

Si se renicia la base de datos se puede abrir el wallet ejecutando:

SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "welcome1";

System altered.

Leer más…