Seguridad – UNMS

Introducción


Al desarrollar UNMS, la cuesti√≥n de la seguridad del usuario es primordial. UNMS usa doble cifrado para elementos cr√≠ticos de la comunicaci√≥n del dispositivo, y no almacenar√° credenciales a menos que sea estrictamente necesario. El programa de recompensas especiales  tambi√©n se cre√≥ para ayudar a encontrar cualquier problema de seguridad.


Puertos de servidor UNMS, certificados y encabezados HTTP


Volver arriba

UNMS s√≥lo se comunicar√° a trav√©s de canales cifrados (HTTPS y WSS), con una excepci√≥n: HTTP puerto 80 es utilizado por UNMS exclusivamente para la generaci√≥n de la  incorporada en LetsEncrypt certificado. No hay una manera f√°cil de evitarlo, ya que los servidores LE necesitan acceder al puerto 80 para validar que el dominio certificado realmente pertenece a la m√°quina que genera el certificado. No admitimos el desaf√≠o de DNS, ya que es casi imposible crear una interfaz de usuario sencilla y f√°cil de usar para configurarlo para todo el alojamiento de DNS. UNMS controla estrictamente si las suites de cifrado est√°n habilitadas o no. Si se usa el certificado LE nativo, entonces UNMS tiene la marca A + en la  prueba de seguridad de SSL Labs .

Si los usuarios suministran su propio certificado durante la instalaci√≥n de UNMS, el puerto 80 no se utiliza en absoluto y puede cerrarse por completo. Sin embargo, es importante mencionar que hay un beneficio significativo de usar el certificado LE nativo: el usuario no tiene que preocuparse por la fecha de vencimiento del certificado, ya que UNMS actualizar√° el certificado autom√°ticamente. 

Todas las dem√°s comunicaciones que vayan a HTTP (en el puerto 80 o en cualquier otro puerto personalizado que pueda elegir, por ejemplo, 8080) se redirigen autom√°ticamente al puerto HTTPS 443 (o un puerto personalizado, si el usuario lo especifica) para utilizar el cifrado de seguridad del protocolo HTTPS . Por esta raz√≥n, no se puede acceder a la interfaz de usuario, API o WebSocket de UNMS a trav√©s de HTTP. 

Es posible configurar un puerto de informaci√≥n personalizado (un puerto al que se pueden conectar los dispositivos) para separar la GUI de UNMS del canal de comunicaci√≥n a los dispositivos. De esta manera, es posible tener acceso a la GUI de UNMS exclusivamente a trav√©s de una red privada y, sin embargo, permitir que los dispositivos se comuniquen con ella. 

Los encabezados HTTP son importantes para la seguridad de UNMS porque administran el navegador y la configuraci√≥n que controlar√° los detalles, como por ejemplo, desde d√≥nde se descarga el JavaScript, c√≥mo debe ejecutarse, c√≥mo deben abordarse los certificados, etc. UNMS utiliza la plataforma securityheaders.com para evaluar la eficiencia de seguridad de sus encabezados HTTP y actualmente posee la marca A + con una configuraci√≥n perfecta.


Descubrimiento y conexión del dispositivo


La forma m√°s segura de conectar un dispositivo con UNMS es insertar manualmente la clave UNMS gen√©rica en ese dispositivo. Esta clave contiene la direcci√≥n URL del servidor UNMS y una clave de cifrado AES gen√©rica. Una vez que el dispositivo recibe esta clave, se conecta a UNMS mediante el protocolo WebSocket cifrado  (WSS). Todos los dispositivos se conectan al controlador UNMS utilizando encriptaciones WSS y AES; Asegurando una doble conexi√≥n encriptada. Toda la comunicaci√≥n se produce a trav√©s de este canal seguro, incluido el acceso remoto a la shell, aunque a primera vista puede parecer que UNMS se est√° conectando al dispositivo a trav√©s de SSH.

Otro escenario al implementar doble cifrado es importante cuando el servidor UNMS no tiene un certificado verificado. Este ser√≠a el caso cuando UNMS sea accesible solo a trav√©s de una direcci√≥n IP sin un certificado v√°lido generado. UNMS utilizar√° otro sistema de cifrado al lado de SSL para garantizar un sistema que sea resistente a los ataques MITM incluso si un certificado no es de confianza. Espec√≠ficamente,  se utiliza el cifrado AES 256 GCM. Puede encontrar m√°s detalles sobre esto en el art√≠culo  La clave de UNMS y el Proceso de registro del dispositivo .

La inserci√≥n manual de las claves UNMS gen√©ricas en los dispositivos una por una no es pr√°ctica, por lo que el equipo de UNMS agreg√≥ una funci√≥n llamada Descubrimiento, que permite encontrar muchos dispositivos en una red e insertar la clave UNMS gen√©rica en ellos autom√°ticamente. Esta es una de las dos ocasiones (la segunda es el shell remoto) en que UNMS solicitar√° las credenciales de un dispositivo y las utilizar√° para conectarse al dispositivo a trav√©s de SSH o HTTPS (si un dispositivo no tiene habilitado el HTTPS, la detecci√≥n no permitir√° que la conexi√≥n se realice, por razones de seguridad). Las credenciales no se guardan durante este proceso. Una vez establecida la conexi√≥n inicial, UNMS inserta la clave en el dispositivo y se establece un nuevo WebSocket cifrado para una mayor comunicaci√≥n. 


Login UNMS


La seguridad del proceso de inicio de sesi√≥n se basa en un token que se env√≠a a trav√©s del encabezado x-auth-token. Este token tambi√©n sirve como protecci√≥n contra ataques CSRF . En la versi√≥n 0.13.1, es v√°lida por 24 horas y se extiende en caso de actividad del usuario. Desde la versi√≥n 0.14.0, la validez es personalizable para los usuarios (desde 30 minutos hasta 30 d√≠as). Mientras un usuario est√° activo, la validez del token se extiende hasta el tope de un mes, luego de eso es necesario iniciar sesi√≥n nuevamente. Hay una estructura de protecci√≥n de fuerza bruta en la UNMS. Estamos utilizando  esta biblioteca  con un siguiente conjunto de opciones:

opciones: {
          habilitado: falso,
          verificaciónUnautorizado: verdadero,
          límite de ruta: falso,
          userPathLimit: true,
          userCache: {expiresIn: config.apiRateLimit.userCacheExpiresIn},
        }

El valor de ‘ userCacheExpiresIn ‘ se establece en 2 minutos.

Actualmente, UNMS soporta dos roles de usuario diferentes. El rol ‘Administrador’ tiene acceso completo a todas las funciones; mientras que el rol de ‘Solo lectura’ no puede realizar ning√ļn cambio en la red o en ning√ļn dispositivo. Se planean extensiones significativas a este sistema para el futuro. 

UNMS es compatible con la autenticaci√≥n de dos factores (2FA). En un dispositivo m√≥vil, los usuarios pueden usar Google Authenticator ( iOS o  Android).). Tambi√©n hay aplicaciones 2FA para computadoras, pero no se recomiendan, ya que para que 2FA sea realmente √ļtil, debe colocarse en un dispositivo completamente separado, con suerte, uno que el atacante no pueda controlar. Cuando se configura 2FA, el usuario deber√° iniciar sesi√≥n en UNMS con sus credenciales e insertar un c√≥digo de seguridad de 6 d√≠gitos proporcionado en ese momento por la aplicaci√≥n de autenticaci√≥n en su dispositivo m√≥vil. Incluso si de alguna manera se comprometieran las credenciales UNMS del usuario, el posible intruso tambi√©n necesitar√≠a acceso al tel√©fono m√≥vil asociado para acceder a la cuenta UNMS. 

Para configurar 2FA en UNMS siga estos tres pasos:

1. En la interfaz de usuario de UNMS, vaya a  Configuraci√≥n> Usuarios> Habilitar dos factores, como se muestra en la siguiente imagen.

2f01.png

2. Aparecer√° una pantalla con un c√≥digo de barras. Escan√©elo con la aplicaci√≥n m√≥vil autenticador de su elecci√≥n para recibir un c√≥digo de seis d√≠gitos.

2f02.png

3. UNMS le pedir√° que vuelva a iniciar sesi√≥n con el c√≥digo reci√©n adquirido. Esto crear√° el enlace. Cada vez que inicie sesi√≥n en UNMS se le pedir√° que proporcione el c√≥digo de seis d√≠gitos actual.

2f03.png

Si tiene alg√ļn problema con 2FA, puede usar este art√≠culo sobre la recuperaci√≥n de contrase√Īas para deshabilitarlo por completo.


Almacenamiento de datos


La UNMS est√° minimizando el n√ļmero de credenciales almacenadas. Cuando se requieren detalles de inicio de sesi√≥n durante el proceso de descubrimiento del dispositivo, los datos no se almacenan en una base de datos. UNMS lo retiene por un per√≠odo corto, pero una vez que se establece la conexi√≥n con el dispositivo, los datos se eliminan. Las credenciales de inicio de sesi√≥n de los usuarios de UNMS se almacenan y protegen con bcrypt, y el texto simple nunca se usa para guardar contrase√Īas en ning√ļn lugar de UNMS. 

A partir de la versi√≥n 0.14.0 de UNMS, se incorporar√° la funci√≥n de almacenamiento de contrase√Īas, lo que permitir√° guardar las contrase√Īas del dispositivo de forma segura. La b√≥veda ser√° encriptada con encriptaci√≥n asim√©trica. Habr√° una clave p√ļblica utilizada para escribir datos y una clave privada, protegida por una contrase√Īa maestra, utilizada para leerlos. La contrase√Īa maestra con una longitud segura se generar√° autom√°ticamente durante el proceso de creaci√≥n de la b√≥veda.