Archivo

Archive for the ‘Tech – Security’ Category

Oracle Database Security Tips – Network Security

noviembre 20, 2017 Deja un comentario

Oracle Database ofrece una amplia gama de opciones de seguridad tanto como de pago con un licenciamiento adicional u opciones que ya están implícitas con la licencia de Base de Datos. En este post nos ocuparemos de una característica que no requiere licenciamiento adicional, esta es Network Security.

Esta opción nos permite limitar el acceso a la Base de Datos a determinadas IPs configurando estas como una lista de IPs permitidas o excluidas.

Implementar esta solución no requiere licenciamiento adicional y aunque parezca que no aporta mucho, es una gran solución de seguridad en casos en los que por ejemplo confluyan varias Bases de Datos pertenecientes a lineas de negocio distinto o entornos distintos como puede ser BBDD de Desarrollo y Producción.

Configuración Network Security

Para este ejemplo de configuración utilizaremos una herramienta gráfica llamada Network Manager  a la que invocamos a través del comando netmgr.

La primera pantalla que nos muestra este asistente es la siguiente:

Leer más…

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…

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:Tech - Security 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:Tech - Security 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