En hablamos sobre la importancia de la autenticación de dos factores en los portales corporativos de las empresas. La vez pasada, demostramos cómo configurar una autenticación segura en el servidor web IIS.
En los comentarios, nos pidieron que escribiéramos una guía para los servidores web más comunes en Linux: nginx y Apache.
Nos lo pidieron, y nosotros lo escribimos.
¿Qué se necesita para comenzar?
- Cualquier distribución moderna de Linux. Realicé la configuración de prueba en MX Linux 18.2_x64. Este no es, por supuesto, un sistema operativo de servidor, pero para Debian no debería haber diferencias significativas. En otras distribuciones, los caminos hacia las bibliotecas y configuraciones pueden variar ligeramente.
- Token. Continuamos usando el modelo , que es ideal en cuanto a características de velocidad para aplicaciones empresariales.
- Para trabajar con el token en Linux es necesario instalar los siguientes paquetes:
libccid libpcsclite1 pcscd pcsc-tools opensc
Emisión de certificados
En artículos anteriores nos basamos en que los certificados de servidor y cliente serían emitidos a través de Microsoft CA. Pero dado que estamos configurándolo todo en Linux, también hablaremos sobre una forma alternativa de emitir estos certificados, sin salir de Linux.
Usaremos XCA como CA (), que está disponible en cualquier distribución moderna de Linux. Todas las acciones que realizaremos en XCA también se pueden hacer en modo de línea de comandos con las herramientas OpenSSL y pkcs11-tool, pero para mayor simplicidad y claridad, no las incluiremos en este artículo.
Inicio
- Instalamos:
$ apt-get install xca - Y ejecutamos:
$ xca - Creamos nuestra base de datos para la CA — /root/CA.xdb
Recomendamos almacenar la base de datos de la Autoridad de Certificación en una carpeta a la que solo el administrador tenga acceso. Esto es importante para proteger las claves privadas de los certificados raíz, que se utilizan para firmar todos los demás certificados.
Creamos las claves y el certificado root CA
La infraestructura de clave pública (PKI) se basa en un sistema jerárquico. El principal en este sistema es el centro de certificación raíz o root CA. Su certificado es lo que hay que crear primero.
- Creamos una clave privada RSA-2048 para la CA. Para ello, en la pestaña Claves Privadas hacemos clic en Nueva Clave y seleccionamos el tipo correspondiente.
- Asignamos un nombre a la nueva pareja de claves. Yo la llamé — Clave CA.
- Emitimos el propio certificado CA, utilizando la pareja de claves creada. Para ello, vamos a la pestaña Certificados y hacemos clic en Nuevo Certificado.
- Es importante elegir SHA-256, porque el uso de SHA-1 ya no se puede considerar seguro.
- Como plantilla, debemos elegir [default] CA. No olvides hacer clic en Aplicar todo, de lo contrario, la plantilla no se aplicará.
- En la pestaña Sujeto elegimos nuestro par de claves. Allí también puedes completar todos los campos principales del certificado.
Creamos claves y certificado para el servidor https
- De manera similar, creamos una clave privada RSA-2048 para el servidor, la he llamado — Clave del Servidor.
- Al crear el certificado, elegimos que el certificado del servidor debe ser firmado por el certificado CA.
- No olvides elegir SHA-256.
- Como plantilla elegimos [default] HTTPS_server. Hacemos clic en Aplicar todo.
- Después de lo cual, en la pestaña Sujeto elegimos nuestra clave y completamos los campos necesarios.
Creamos claves y certificado para el usuario
- La clave privada del usuario se almacenará en nuestro token. Para trabajar con él, es necesario instalar la biblioteca PKCS#11 desde nuestro sitio web. Para distribuciones populares ofrecemos paquetes listos que se encuentran aquí — . También tenemos compilaciones para arm64, armv7el, armv7hf, e2k, mipso32el, que se pueden obtener en nuestro SDK — . Además de las compilaciones para linux, también hay compilaciones para macOS, freebsd y android.
- Agregamos un nuevo Proveedor PKCS#11 en XCA. Para ello, vamos al menú Opciones en la pestaña Proveedor PKCS#11.
- Hacemos clic en Agregar y elegimos la ruta a la biblioteca PKCS#11. En mi caso es usrliblibrtpkcs11ecp.so.
- Necesitamos un token formateado RUTOKEN ECP PKI. Descargamos la utilidad rtAdmin —
- Ejecutamos
$ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u - Como tipo de clave elegimos — clave RSA-2048 en RUTOKEN ECP PKI. He llamado a esta clave Clave del Cliente.
- Ingresamos el PIN. Y esperamos a que finalice la generación de la pareja de claves por hardware.
- Creamos el certificado para el usuario de manera similar al certificado del servidor. Esta vez elegimos la plantilla [default] HTTPS_client y no olvidamos hacer clic en Aplicar todo.
- En la pestaña Sujeto introducimos la información del usuario. Ante la solicitud de guardar el certificado en el token, respondemos afirmativamente.
Al final, en la pestaña Los certificados en XCA debe verse aproximadamente así.
Este conjunto mínimo de claves y certificados es suficiente para comenzar a configurar directamente los servidores.
Para la configuración necesitamos exportar el certificado del CA, el certificado del servidor y la clave privada del servidor.
Para ello, debemos seleccionar el registro correspondiente en la pestaña pertinente de XCA y hacer clic en Exportar.
Nginx
No escribiré cómo instalar y ejecutar un servidor nginx; hay suficientes artículos sobre este tema en internet, sin mencionar la documentación oficial. Pasemos directamente a la configuración de HTTPS y la autenticación de dos factores mediante tokens.
Agregamos las siguientes líneas a la sección server en nginx.conf:
server {
listen 443 ssl;
ssl_verify_depth 1;
ssl_certificate /etc/nginx/Server.crt;
ssl_certificate_key /etc/nginx/ServerKey.pem;
ssl_client_certificate /etc/nginx/CA.crt;
ssl_verify_client on;
}Una descripción detallada de todos los parámetros relacionados con la configuración de ssl en nginx se puede encontrar aquí —
Solo describiré brevemente aquellos que configuré yo mismo:
- ssl_verify_client — indica que es necesario verificar la cadena de confianza del certificado.
- ssl_verify_depth — define la profundidad de búsqueda del certificado raíz de confianza en la cadena. Dado que nuestro certificado de cliente está inmediatamente firmado por el certificado raíz, se establece una profundidad de 1. Si el certificado del usuario es firmado por un CA intermedio, este parámetro debe ser 2, y así sucesivamente.
- ssl_client_certificate — indica la ruta al certificado raíz de confianza que se utiliza para verificar la confianza del certificado del usuario.
- ssl_certificate/ssl_certificate_key — indican la ruta al certificado/clave privada del servidor.
No olvidemos ejecutar nginx -t para verificar que no haya errores de tipeo en la configuración, y que todos los archivos estén en sus lugares, etc.
¡Y eso es todo! Como pueden ver, la configuración es muy simple.
Verificamos el funcionamiento en Firefox
Dado que estamos haciendo todo completamente en Linux, asumiremos que nuestros usuarios también están trabajando en Linux (si tienen Windows, entonces .
- Iniciamos Firefox.
- Intentemos entrar primero sin el token. Obtendremos esta imagen:
- Accedemos a about:preferences#privacy, y vamos a Security Devices…
- Hacemos clic en Cargar, para agregar un nuevo Controlador de Dispositivo PKCS#11 y especificamos la ruta a nuestra librtpkcs11ecp.so.
- Para verificar que el certificado es reconocido, se puede acceder a Certificate Manager. Aparecerá una solicitud para introducir el PIN. Después de ingresar correctamente, se puede verificar que en la pestaña Your Certificates apareció nuestro certificado del token.
- Ahora accedemos con el token. Firefox nos ofrece seleccionar el certificado que se usará en el servidor. Elegimos nuestro certificado.
- ¡BENEFICIO!
La configuración se realiza una vez, y como se puede ver en la ventana de solicitud de certificado, podemos guardar nuestra elección. Después de esto, al ingresar al portal, solo tendremos que insertar el token y escribir el PIN del usuario que se estableció durante el formateo. Después de esta autenticación, el servidor ya sabe qué usuario ha accedido y no es necesario hacer más ventanas adicionales para verificar, sino que el usuario puede acceder directamente a su panel personal.
Apache
Al igual que con nginx, nadie debería tener problemas para instalar apache. Si no sabe cómo instalar este servidor web, simplemente consulte la documentación oficial.
Ahora comenzamos a configurar nuestro HTTPS y la autenticación de dos factores:
- Primero, es necesario activar mod_ssl:
$ a2enmod ssl - Y luego habilitar la configuración HTTPS del sitio por defecto:
$ a2ensite default-ssl - Ahora editamos el archivo de configuración: /etc/apache2/sites-enabled/default-ssl.conf:
SSLEngine on SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/sites-enabled/Server.crt SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt SSLVerifyClient require SSLVerifyDepth 10Como pueden ver, los nombres de los parámetros prácticamente coinciden con los nombres de los parámetros en nginx, por lo que no voy a explicarlos. Nuevamente, quienes estén interesados en detalles, son bienvenidos en la documentación.
Ahora reiniciamos nuestro servidor:$ service apache2 reload $ service apache2 restart
Como pueden ver, configurar la autenticación de dos factores en cualquier servidor web, ya sea en Windows o en Linux, es cuestión de una hora como máximo. Y la configuración de los navegadores toma alrededor de 5 minutos. Muchos piensan que configurar y trabajar con la autenticación de dos factores es complicado y confuso. Espero que nuestro artículo disipe un poco este mito.
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Es necesaria una guía para configurar el trabajo de TLS con certificados en GOST 34.10-2012:
Sí, TLS-GOST es muy necesario
No, la configuración con algoritmos GOST no interesa
44 usuarios votaron. 9 usuarios se abstuvieron.
Fuente: habr.com
