Conocí el mundo de los
NoSQL allá por el año
2013 cuando comenzamos con
ElevenPaths a construir nuevas tecnologías. Teníamos muchos retos tecnológicos por completar ante nosotros. Fue una etapa en la que aprendimos mucho ante todos los cambios y avances en tecnología que aparecían ante nosotros. Hay algo que nos enseñaban cuando estudiábamos en la carrera y es que un
Ingeniero debe buscar soluciones, es decir, analizar el problema, analizar una posible solución, diseñar, implementar, etcétera.
 |
| Figura 1: Unos consejos para fortificar MongoDB en el mundo NoSQL |
A uno de esos problemas de aquella época le dimos solución basándonos en un tipo de bases de datos no relacionales llamas
"Not Only SQL" o
NoSQL. Hoy me quiero centrar en una de esas
NoSQL, en
MongoDB. Es, por mérito propio uno de los motores de base de datos no relacional más utilizados hoy en día. En su día sacamos alguna noticia sobre
MongoDB dónde su seguridad no quedaba bien parada, pero quizá no sea la seguridad que
MongoDB puede aportar, si no la configuración que le apliquemos. Es decir, no es problema del producto y sí de la configuración que el administrador ejecute, con el caso de estos artículos del blog:
El
caso de MacKeeper fue recordado por los
13 millones de usuarios filtrados y los
21 GB de información sensible. Algunos echaron la culpa al producto, pero realmente y clarísimamente, fue una mala configuración. No es el único caso en el que este tipo de soluciones se han visto involucradas, por ejemplo, y más recientemente, tenemos el caso de las miles de
apps de iOS que filtraron datos en Firebase, pero no solo en
Firebase, en el listado aparece
MongoDB también.
 |
| Figura 2: El caso de MacKeeper y los datos filtrados |
En el artículo de hoy vamos a hablar de cómo fortificar
MongoDB. La gente de MongoDB pone a disposición de sus usuarios / administradores una serie de “
tips”. En muchos casos, hay cosas “
obvias”, por ejemplo, que la conexión vaya cifrada entre la aplicación y la base de datos. De esto ya hemos hablado en el pasado con los
ataques Network Packet Manipulation.
Sea como sea, siempre viene bien tener un
listado de “tips” o una “checklist” dónde verificar algunas de las cosas que debemos configurar sí o sí en una base de datos, en este caso, no relacional como puede ser
MongoDB.
Habilitar el control de acceso y configurar RBAC
Para que no ocurra como en los ejemplos anteriores de filtrado de información, es muy importante
habilitar el control de acceso. Como hemos visto, si tu
MongoDB da soporte a una aplicación web o un servicio expuesto en la red, es una de las primeras cosas que van a buscarse en un
Hacking de Web Technologies. Los motores
NoSQL con acceso anónimo son objetivo de pentesters y atacantes peor intencionados. Para ello, se puede utilizar un mecanismo de autenticación
SCAM o
x509 que trae el propio
MongoDB. Además, se puede integrar con
Kerberos o
LDAP.
Otra recomendación sería
crear primero un administrador de usuarios y luego ir creando los usuarios necesarios. Es importante, crear un usuario por cada aplicación o persona que requiere acceder al sistema. Como define una de las mínimas de la seguridad informática, debemos seguir el principio del menor privilegio. Es decir, vamos a crear roles que definan derechos de acceso para un conjunto de usuarios.
De esta forma, podemos crear usuarios y asignarlos solo a los grupos/roles que ellos necesiten para poder ejecutar sus tareas u operaciones. Cuando hablamos de usuarios, hay que tener en cuenta que muchas veces son las propias aplicaciones que requieren conectarse contra la base de datos.
Ya hemos comentado sobre
RBAC de forma implícita, pero por si acaso, decir que
RBAC es un control de acceso basado en roles (
Role Based Access Control). Es decir, consiste en asignar derechos de acceso, como comenté antes, a los usuarios en función de los roles y las operaciones o tareas que tienen que realizar. Para habilitar la autenticación, simplemente debemos cambiar la directiva “
auth” o habilitar a true en el fichero de configuración
/etc/mongodb.conf.
 |
Figura 5: Configurando /etc/mongodb.conf
|
El resultado es que cuando queremos conectarnos con
MongoDB a la base de datos que hayamos creado pues nos solicitarán credenciales. Puedes ver más sobre la
creación de usuarios en la documentación oficial de MongoDB.
 |
Figura 6: Conectándonos con nuestro usuario a MongoDB
|
Esto es algo muy básico, pero que como hemos visto pues no es algo que siempre se configure. Importante, antes de habilitar la autenticación hay que tener en cuenta el crear usuarios. Eso se hace con la función
db.createUser y un documento
JSON con el siguiente formato:
{
user: “pablo”,
pwd: “xxx”,
roles: [“dbOwner”] #si queremos que sea el propietario
}
MongoDB tiene lo que se llama “
Collection-level access control” y permite hacer un permiso muy específico sobre las colecciones de datos. Es decir, puedes indicar qué tipo de acción puede hacer un rol sobre una colección de datos. Hay que recordar que una colección de datos está dentro de una base de datos. Sería como las tablas en el mundo
SQL.
Cifrar comunicaciones con TLS/SSL y cifrar y proteger datos almacenados
El cifrado es clave tanto en lo que a la comunicación entre el cliente y el servidor como en el almacenamiento de los datos. Ya hemos comentado lo que son los
ataques de Network Packet Manipulation. Además,
Wireshark da soporte para mostrar los paquetes de MongoDB y diseccionarlo de forma sencilla. En otras palabras, si alguien se pone en medio de la comunicación entre la aplicación y el servidor de
MongoDB toda la información que viaje entre ambos nodos quedará expuesta.
 |
Figura 7: Paquetes MongoDB en WireShark
|
Explicar el proceso para proteger la comunicación entre cliente y servidor daría para uno o dos posts, por lo que os dejo el
enlace a dicha información y se puede configurar de manera sencilla. Hay que tener en cuenta que habrá que configurar tanto servidor como cliente.
Encypted at Rest: Almacenamiento seguro de la información
Ahora, hablemos de la protección de la información en el interior de la base de datos. Cuando se crea un usuario, se nos indica en la documentación que la contraseña no se almacena en texto plano, como era de esperar.
MongoDB dispone de una “
feature” importante que es el motor de almacenamiento cifrado o
“Encrypted Storage Engine”. Esta “
feature” solo está disponible en
MongoDB 3.2 en adelante y en la versión
Enterprise.
Si el cifrado está activo,
MongoDB Enterprise utiliza
AES256-CBC a través del uso de
OpenSSL. Se utiliza la misma clave para cifrar que para descifrar.
MongoDB también soporta un cifrado en modo
FIPS y
AES con el modo
Galois/Counter Mode. Cuando se habilita este cifrado, el proceso incluye las siguientes acciones:
- Generación de una clave maestra y la generación de claves para cada base de datos. Es decir, que cada base de datos estará cifrada con una clave diferente. Esto es algo lógico.
- Cifrar los datos de cada base de datos con las claves generadas previamente para cada base de datos. También se cifrarán las claves de la base de datos con la clave maestra.
- El cifrado es llevado a cabo de forma transparente. Este cifrado se lleva a cabo en todo el almacenamiento, es decir, los archivos que contienen los datos están completamente cifrados. Lo interesante es que los datos descifrados solo existirán en la memoria y nunca en el disco, donde siempre estarán cifrados.
Nota: Ya hemos hablado en este blog sobre ataques a procesos en memoria con el objetivo de sacar información.
Registros y auditoría de las acciones
La trazabilidad es una de las subdimensiones de la seguridad. Es algo importante y el tener un registro de actividad también lo es. Habilitar la auditoría en un
MongoDB es algo vital y que permite conocer que está ocurriendo en tu base de datos. Cuando se habilita la auditoría se escriben eventos en la consola del propio
MongoDB, en el
Syslog o en archivos.
Se registran operaciones de autenticación, de acceso, de autorización, etcétera. Se puede configurar filtros para restringir eventos capturados. Esto se puede hacer a través de la
configuración de los filtros de auditoría. En la auditoría se registran:
- Autenticación y cómo se dijo anteriormente, también la autorización.
- Operaciones del cluster de MongoDB.
- Operaciones de lectura y escritura.
- Operaciones con el esquema o DDL.
- Mensajes personalizados de aplicaciones.
Asegurar el entorno de MongoDB
Este paso es muy importante. De nada valdrá tener las mejores recomendaciones y consejos en el ámbito del
hardening a
MongoDB, si luego tenemos las capas inferiores desprotegidas. Imagínate que permitimos que cualquier usuario pueda acceder a este equipo físicamente y no ponemos barreras, ¿Serviría tener cifrado los datos en disco? Si no tiene un login de usuario, si no tiene un
firewall que rebaje la exposición, si no hay unas barreras físicas que evitan que cualquiera pueda acceder a ese equipo físicamente, etcétera.
En este caso las recomendaciones van por la parte del
firewall, pero no hay que quedarse solo con eso. Si vemos el modelo defensa en profundidad, la seguridad va en armonía con todas las capas. No vale fortificar mucho una capa, si luego por debajo, la base, no se sostiene. Hay un artículo interesante de la gente de
Tenable en la que hablan sobre la
auditoría a MongoDB con Nessus.
Ejecuta MongoDB con opciones de seguridad habilitadas
Este apartado habla sobre la necesidad de ejecutar
MongoDB con un usuario dedicado en el sistema. De forma que si es comprometida, no haya mucho que se pueda hacer hasta que haya una escalada de privilegio en el sistema. Además, hay una serie de opciones de seguridad que se pueden trabajar desde el principio y que ayudan a tener un entorno más seguro dentro de
MongoDB. Seguramente, a estos consejos o recomendaciones se pueden añadir más y entrarían en opciones de seguridad habilitadas desde el principio.
• Deshabilitar la escritura side-server: MongoDB soporta la ejecución de código Javascript. Para llevar a cabo la mitigación de una posible vulnerabilidad a nivel de aplicación, es recomendable deshabilitar el código del lado del servidor. Esto se puede deshabilitar en el archivo de configuración con la directiva noscripting = false.
• Deshabilitar la interfaz de estado: ¿Qué es la interfaz de estado? Esto es un servidor HTTP que expone un sitio web el cual contiene estadísticas e información que pueden ser de interés para un administrador del sistema, pero también para un atacante. En el archivo de configuración se puede deshabilitar esta opción con la directiva nohttpinterface = true.
• Desactivar la interfaz REST: Es una interfaz administrativa que es interactiva, la cual se encuentra desactivada por defecto. Esta interfaz no tiene soporte para autenticación y se debe restringir el acceso a dicha interfaz, por ejemplo, por dirección IP o mediante interfaz de loopback. Para deshabilitar esta interfaz en el fichero de configuración debemos verificar rest = false.
• Limitar la exposición en la red: Limitar la exposición de direcciones IP de un servidor o de interfaces de red es importante. La opción bind_ip indica la interfaz de red por la que se escucharán peticiones en la base de datos. Esto ya depende de cada uno y sus necesidades. Se puede utilizar la directiva bind_ip para limitar la accesibilidad a la red de un programa MongoDB. También se puede jugar con un firewall y dejar pasar el tráfico que provenga de la dirección IP dónde se encuentra la aplicación. En el fichero de configuración se configura esta opción con la directiva bind_ip = [dirección IP de la interfaz que queremos].
Estos son algunos tips para mejorar la seguridad de una basa de datos MongoDB. Por supuesto, hay más cosas que se pueden hacer, pero con estas estamos mejorando bastante la seguridad de MongoDB. Es importante alinear los esfuerzos con el resto de capas, tal y como se indica en el modelo defensa en profundidad.
Saludos,
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Para consultas puedes usar el 
