Archivos de la categoría ‘Oracle’

Hace algún tiempo se nos pidió apoyar en una integración no certificada por Oracle, pero que sin embargo, se solicitaba como necesaria y obligatoria, por lo que había que hacerla Sí o Sí.

La solicitud era hacer que Beehive se integrará con un Directorio Externo. Al día de hoy Beehive se puede integrar con los siguientes servicios de Directorio:

  • Oracle Internet Directory
  • IBM Tivoli Directory Server
  • Microsoft Active Directory Server
  • OpenLDAP Directory Server
  • Oracle Directory Server Enterprise

Novell eDirectory no es un servicio de Directorio que este certificado, sin embargo haciendo uso del perfil de OpenLDAP, y haciendo los mapeos necesarios en el archivo XML e importandolo mendiante beectl (beectl add_directory_profile –file openldapMapping.xml) o gestionando el perfil desde la consola de Beekeeper es posible comenzar la integración.

El paso anterior sin embargo presenta el problema que no sincroniza usuario alguno. De hecho si desde la línea de comandos ejecutamos un beectl download_ldap_user_data –file UsersFromLDAP.xml –profile NovellProfile, obtenemos un mensaje de error como el siguiente:
Generando XML de usuarios entre 0 y 100.

Número de entradas de LDAP en las bases de búsqueda de LDAP especificadas: 1000.
Número de entradas de LDAP que se han leído correctamente desde el
servidor LDAP: 0.
Fallo al leer 1000 entradas de LDAP desde el servidor LDAP.
Número de entradas de LDAP que cumplen la asignación de reglas de
sincronización de LDAP: 1000.
Número de usuarios generados correctamente en el archivo XML: 0.

Buscando en los logs, podemos notar que no se encuentra algún mensaje de error suficientemente claro que indique cual es el problema.

Búscando el Origen del Problema
Primeramente, había que encontrar que era lo que provocaba el error, para ello lo primero es hacer uso de un sniffer, Wireshark salió al rescate. Al ejecutar el comando de sincronización, se generan muchas peticiones LDAP para la obtención de información:

Peticiones

Como podemos observar, solo había necesidad de buscar la petición que solicitaba a los diferentes usuarios para determinar cual era el problema, por intuición, buscamos la última solicitud cuya operación sea “Buscar”:

Petición de Búsqueda

Petición de Búsqueda

Finalmente dentro del request, podemos ver que se solicitan diferentes atributos, y en especial debemos prestar atención a uno de ellos entryUUID:

El atributo entryUUID

entryUUID

Desgraciadamente en eDirectory no existe el atributo. Así que la solución como podemos observar se torna sencilla (claro… después de determinar cual fue el error, solucionarlo es mas fácil):

  1. Crear mediante el ConsoleONE, el atributo entryUUID, las características es que dicho atributo debe ser del tipo Case Ignore String y tener activada la bandera de Single Value
  2. Asignar el atributo entryUUID a la clase Person, esto lo heredará al usuario
  3. Se debe rellenar el atributo de forma que a cada usuario le toque un valor diferente, esto es importante porque este es el campo que se asocia al atributo Directory Locator en Beehive y actua como campo clave para las sincronizaciones posteriores. Un ejemplo de como obtener un UUID válido es ejecutar desde linea de comandos: uuidgen -t

Finalmente podemos ejecutar nuevamente el comando de descarga de usuarios, o simplemente habilitar el perfil para que periódicamente sincronice los usuarios.

De esta forma, tenemos una integración “Nativa” entre eDirectory y Beehive sin hacer tanto circo, maroma y teatro.

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio

No existe un día en el que no escuchemos al menos una par de ataques a diferentes sitios. Como podemos suponer en general los administradores de sistemas tienen que estar al pendiente de todas las posibles vulnerabilidades para tratar de subsanarlas (XSS, SQLi, Bugs, CVE’s, etc). Un atacante solo necesita una. Al día de hoy que se escribe este artículo, el 25% de los ataques a los sistemas web, y el robo de información se produce mediante SQL Injection (SQLi).

Un ataque de SQLi, sucede generalmente cuando se hace un chequeo incorrecto de las variables usadas en los formularios o los campos de entrada de texto de las diferentes aplicaciones (por lo general Aplicaciones WEB). Un ataque de SQLi, puede ir desde lo más simple (obtener accesos a una aplicación), hasta obtener un dump completo de la base de datos o información restringida, en general se puede hacer un simple query como:
' HAVING 'x'='x'--
hasta un
a' AND (SELECT CAST(CHAR(10) + COUNT + CHAR(10) AS INT) FROM (SELECT CAST(COUNT(name) AS VARCHAR) AS COUNT FROM syscolumns WHERE id = (SELECT id FROM sysobjects WHERE name = 'clientes' ) ) NataS ) = 1 OR 'perro' = 'gato' AND ID_Cliente = 'a (por decir poco).

Database Firewall es la primer linea de defensa de Oracle para protección de las Bases de datos (es una solución heterogénea). Su aparición se debe a que las actuales herramientas de aseguramiento no son funcionales contra ataques de este tipo.

Database firewall, funciona como un firewall de redes normal… a diferencia que únicamente se encarga de validar las sentencias SQL que pasan por la caja. Que es lo que hace a DBFW diferente:

  • Implementación medianta listas blancas, listas negras y de excepción. A diferencia de otras herramientas que trabajan mediante listas negras para bloquear sentencias que no son válidas, lo que vuelve complejo la protección debido a que existen miles de formas de generar el mismo resultado.
  • Puede trabajar inline y offline, ademas de generar monitoreo y bloqueo.
  • Alertas en tiempo real
  • Soporte para múltiples bases de datos: Oracle, MSSQL, Sybase y DB2
  • Es un software que se instala en equipo común, y que para que este soporte mayor cantidad de TPS, solo necesita mayor cantidad de RAM y CPU

A diferencia de otros proveedores de seguridad de bases de datos que identifican eventos fuera de la política de seguridad mediante expresiones regulares, DBFW entiende el significado y las intenciones de las sentencias.

DBFW implementa un enfoque basado en whitelists que sólo permite que se envíen a la base de datos las sentencias SQL correctas, y aprende de las sentencias SQL que desea controlar. El algoritmo de DBFW va más allá de la sintaxis y se acerca al significado antes de que se envíe a la base de datos. Cuando la sentencia se analiza, se clasifica en un “cluster” según la estructura de la sentencia y se proporciona un valor hash único que identifica de manera eficiente si el SQL se ha registrado o puesto en la whitelist. Mediante la comprensión de la gramática, el ataque de inyección y otras sentencias que no cumplan con las políticas se detectan como anomalías.

DBFW esta compuesto por tres partes:

  • DBFW Server, es el encargado de aplicar las políticas, generar el monitoreo, accionar las alertas, etc. Si lo vemos en una infraestructura de red común, este se convierte en el FW que filtra todas las peticiones de red (solo que en este caso únicamente son sentencias SQL).
  • DBFW Management Server, es el servidor que guarda los reportes sobre la base de datos, y aplica las configuraciones a los diferentes DBFW Servers que tengamos en la infraestructura. También genera los reportes que se le soliciten
  • DBFW Analyzer, se encarga de analizar el conjunto de sentencias inicial y de gestionar las diferentes políticas, crearlas, generar las listas negras, blancas, etc

En las siguientes entradas, aprenderemos a instalar, configurar, gestionar y crear un sizing adecuado en base a nuestra infraestructura.

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio