Hoy en día los diferentes sistemas, aplicaciones, frameworks, etc… vienen con un sinfín de configuraciones que algunas veces no son ni revisados. Incluso dentro del equipo de Sistemas, se suele hacer la broma de que instalar cosas en Windows es "next next next…" o en programación "seguir el tutorial X hasta que funcione".
La seguridad es un punto totalmente aparte de la funcionalidad de un sistema/aplicación e incluso muchas veces ni siquiera se llevan bien. Suele ser relativamente fácil poner en marcha una plataforma, pero no tanto hacerlo de manera segura tanto para el propio ecosistema como para el usuario.
En este artículo, vamos a ver los peligros que pueden provocar en cualquier empresa los diferentes tipos de "por defecto", causados por: la inexperiencia de los técnicos, la excusa de "está en la red interna, no va a pasar nada" o incluso un jefe que quiere algo "para ayer" o el técnico, que su prioridad va a ser que funcione, no que sea seguro.
Pues sí, uno de los mayores peligros son las contraseñas por defecto. No sólo las que literalmente van por defecto en algunas aplicaciones, sino esa contraseña que sabe toda la empresa, que se pone por defecto y que como la descubran, tienen la mitad de los usuarios del sistema y el colmo, es que sea "Empresa01".
Es obvio que, con tantos sistemas y necesidad de contraseñas diferentes, siempre caiga un entorno de test o algo que "iba a ser sólo para probar, pero ya que funciona vamos a dejarlo así". El colmo de esta situación es que esté expuesto en Internet donde millones de bots día a día intentan acceder con credenciales por defecto a todo tipo de servicios y software. Quien crea que eso es imposible, es que no ha visto un chat IRC con más de 150 "usuarios" que eran raspberry pi expuestas a internet infectadas con un malware que simplemente accedía a los que tenían credenciales por defecto "pi" y contraseña "raspberry".
A estas alturas debería sobrar decirlo, pero, aunque un dispositivo esté en una red interna, los atacantes solo necesitan un único agujero para acceder a tu red. Si además sumamos la posibilidad de saltar de máquina en máquina, tarde o temprano nos encontraremos una nota de rescate porque los datos han sido robados y cifrados y se solicita dinero a cambio.
Como solución, el uso de un gestor de contraseñas. No hay excusas para una sola contraseña por defecto. Incluso para entornos cloud, existen varios servicios y sistemas que pueden llevar esta gestión.
Recordad revisar contraseñas tanto de routers, wifi, usuarios locales, de base de datos, de servicios web y como no, de administradores.
El Active Directory (AD) suele ser una tarea algo fácil con unos pocos usuarios, pero por defecto no tiene implementado ni grupos ni políticas adecuadas para una buena seguridad. También los permisos por defecto no suelen ser suficientemente seguros y al escalar un sistema o empresa, poco a poco se requiere una estructura de grupos diferentes con más restricciones.
A su vez, tenemos las directivas de grupos de las cuales nos puede interesar cambiar sus valores por defecto. Por ejemplo, un usuario normal no debería necesitar acceso a la consola CMD de Windows, aun así, está habilitada por defecto. ¿Cuántas veces hemos oído que los empleados no deben conectar dispositivos externos a los ordenadores? Entonces, ¿por qué está habilitado por defecto en entornos AD? Incluso en los permisos, los usuarios que ejecutan servicios, como pueden ser web deberían estar aislados y no poder acceder a funciones u otros ficheros de sistema que no sean estrictamente necesarios. Y aun así muchas veces se logra escalar privilegios por configurar permisos por defecto.
El que existan ciertos usuarios por defecto que no tienen aplicados los permisos correctamente o no son eliminados son un peligro añadido que pasa desapercibido ya que son olvidados. Incluso Wordpress no se libra de configuraciones peligrosas por defecto, ya que existen algunas que revelan los nombres de usuario e incluso te ofrecen un servicio habilitado por defecto para realizar ataques de fuerza bruta, y peor aún, sin un límite de intentos.
Por último añadiría las configuraciones de algunas guías muy usadas que no aplican configuraciones seguras. Un ejemplo sería un empleado que quiere montar un servicio web Apache. Como no tiene tiempo, busca en internet y escoge entre las 4 primeras entradas de guías a seguir. En esa guía explica que se ejecuten unos cuantos comandos y listo. Por la falta de tiempo, no ha revisado más a fondo lo que estaba haciendo y ha puesto una contraseña insegura, o puede que esa guía, la haya realizado alguien en un entorno de prueba y no haya aplicado ninguna medida de seguridad.
¿Suena a broma el hecho de que para un producto de software existan en internet guías que no aplican una autenticación básica para datos sensibles? Suena absurdo, pero ahora sólo nos reímos de esa época en la que se filtraron decenas y decenas de Elasticsearch expuestos en Internet con datos sensibles sin ninguna autenticación. Por suerte, ahora el setup de Elasticsearch solicita si quieres autenticación o no, aunque aún puedes encontrarte alguno sin restricciones.
No se gana nada intentando buscar culpables, pero, para que no vuelvan a suceder más se deben fomentar las buenas prácticas de seguridad, formar a los empleados en configurar correctamente los diferentes servicios aunque sea algo más difícil, se debe proporcionar tiempo para aplicar correctamente las nuevas funcionalidades y solicitar auditorías de seguridad periódicas a proveedores especializados.
Por suerte (aunque no debemos confiarnos) algunas configuraciones Cloud ya son seguras por defecto, por ejemplo bloquean todos los accesos a no ser que alguien modifique esos valores, una práctica que mejora los entornos nuevos.
No solo busquéis cómo hacer algo, buscad como hacerlo de manera segura.