Database Hardening

Haz 100 flexiones más, 200 abdominales y da 15 vueltas al campo de fútbol.

Respuesta: Ufff, si que es difícil endurecer los servicios.

Todos sabemos que donde nosotros vemos ladrillos, medidas de seguridad, obstáculos a saltar, etc. Los chicos malos ven grietas, agujeros y facilidades, después de casi un año leyendo estas líneas creo que no os sorprendo si digo que no hay ninguna medida de seguridad o herramienta que sea la panacea, así que la única solución es utilizar varias de ellas que trabajen codo con codo con un objetivo común. La estrategia utilizada para que todo esto funcione como un engranaje se llama “defensa en profundidad”, y ya la utilizaban los militares en la 2ª Guerra Mundial y posiblemente, mucho antes.

¿Cuál es la profundidad aquí? Pues hay muchas y depende de cómo se mire, pero nosotros lo vamos a llamar arquitectura multicapa (frontend – middleware – backend). Si ponemos un nuevo servicio en producción, es lógico y normal que hagamos “hardening” del mismo, eso se suele traducir en bastionar el equipo, eliminar usuarios y contraseñas por defecto, deshabilitar servicios innecesarios, configurar control de acceso, etc. etc. Todo esto está bien pero, ¿qué pasa con las otras capas? Estamos dando por sentado que nadie pasará la frontera de Bélgica y holanda, pero esto ya les pasó a los franceses y ya sabéis como acabó .

Hoy vamos a hacer hardening del backend y vamos a ver cómo nunca tenemos que perder de vista los datos, el verdadero foco de la cuestión. Redactar todas las cositas que hay que mirar en un backend puede ser un checklist bastante extenso que seguramente no aporte mucho, casi todos los sistemas tienen sus checklist publicados, ya sea vía proveedor, vía NIST, etc. Lo que vamos a hacer es concentrarnos en tres cosas:

-   Detectar fallos de configuración (cuentas por defecto, servicios innecesarios, etc.)

-   Detectar vulnerabilidades software (no hay una política de “critical path update”)

-   Detectar mal uso (cuenta de administrador compartida por varios usuarios, consultas al backend con excesivos privilegios).

Existen herramientas para automatizar estos análisis especializadas en bases de datos como son AppDetective o NGSSQuirrel, la diferencia de los escáneres tradicionales con estos radica en la especialización, si bien un Nessus te detectará vulnerabilidades de todo tipo en dispositivos de red, servidores, Workstation, etc. nunca podrá realizar exámenes tan exhaustivos como por ejemplo Nikto hace con servidores web o AppDetective con una base de datos. Pero no solo de escáneres vive el Consultor, aunque con ellos y nuestro conocimiento (valor añadido) podremos comenzar a detectar fallos y recomendar medidas de hardening.

Medidas adicionales que nos ayudarán a mantener todo securizado (la seguridad es un proceso, recordemos) será habilitar un detector de cambios en la configuración, para ello tenemos herramientas como Intrust de Quest Software (que ya nos contó Carles Matin) o algunas más sencillas como habilitar las opciones de auditoria de SQL Server (si es esa nuestra BBDD).

Finalmente tenemos los datos, el quiz de la cuestión, toda la estrategia “defense in depth” se basa en este tesoro que puede ser expuesto a pesar de todo lo dicho hasta ahora. Una puerta trasera, una copia no autorizada, una migración de backend, unas pruebas desde otros entornos como certificación, desarrollo, etc. y ya tenemos nuestra temida fuga de datos. La principal medida en estos casos pasa por hacer lo que en el CISSP llamaban “Data Sanization” y que se traduce en preparar esos datos sensibles para que no pierdan su estructura (claves foráneas, atributos, tablas relacionales, etc.) y sin embargo no se puedan entender o pierdan su significado, es decir, ofuscar los datos. Para ello me he guardado en último lugar una herramienta que descubrí hace unos días, se llama Data Masker y tiene una funcionalidad interesante. Permite conectarse a las bases de datos, obtener su estructura, crear reglas de ofuscado, ejecutarlas, etc:

DataMasker: Autenticación en las conexiones.

DataMasker: Tablas de ejemplo para jugar.

Y esto es todo por hoy, recordad, proteger el frontend está muy bien pero...¡el foco siempre en los datos!

Salu2