Tengo un servidor OpenVPN que utiliza certificados y autenticación LDAP.
El problema es que un usuario podría compartir su certificado y otros usuarios válidos de LDAP podrían usar este certificado.
Pregunta
¿Cómo me aseguro de que el certificado de Bob solo se pueda usar con el usuario de LDAP "bob"?
Según esta publicación , common_nameno puede ser falsificado por el usuario.
Agregue esto a openvpn server.conf
script-security 2
# untrusted state
auth-user-pass-verify /etc/openvpn/scripts/check_cn_on_connect.sh via-env
/etc/openvpn/scripts/check_cn_on_connect.sh contiene
#!/bin/bash
# username and common_name must be the same to allow access.
# users are not allowed to share their cert
if [ $username != $common_name ]; then
echo "$(date +%Y%m%d-%H%M%S) DENIED username=$username cert=$common_name" >> /var/log/openvpn-access.log
exit 1
fi
echo "$(date +%Y%m%d-%H%M%S) GRANTED username=$username cert=$common_name" >> /var/log/openvpn-access.log
exit 0
Actualizar
Esto es para OpenVPN 2.1.4. En 2.2.0 han agregado muchas variables nuevas que puede ver env >> /tmp/env, donde una de estas nuevas variables es la huella digital / número de serie de los certificados.
Hay muchas opciones, ya que OpenVPN es un proyecto de código abierto, y tiene la capacidad de escribir su propio gancho de autenticación, hay muchas personas que han hecho muchas cosas diferentes para proporcionar diferentes niveles de autenticación.
No he probado la mayoría de estos, solo los he visto mencionados en los documentos / blogs / listas de correo. Algunos de estos pueden requerir parches o la versión no gratuita.
Un método principal será hacer que la parte privada de su par de claves sea extremadamente difícil de extraer / copiar.
Si proteger la clave es prohibitivo, no es compatible con las plataformas de sus clientes o no es posible por alguna otra razón, entonces le quedan algunas opciones.
Establezca una gran cantidad de registros en su servidor, para observar anomalías. Si Bob normalmente solo inicia sesión desde su casa, y luego, un día, comienza a iniciar sesión desde Acme Inc., entonces es posible que deba investigar.
Configurar la autenticación multifactor. Su certificado cuenta como "algo que tiene". Por lo tanto, debe buscar alternativas en el 'algo que es' o 'algo que sabe'. Esto incluye bio métricas o contraseñas / frases de paso.
auth-user-pass-verifyopción. Esta opción pasa el nombre de usuario y la contraseña proporcionados a un script / programa externo que tomará la decisión de autenticación en función de lo que desee.
auth-user-pass-verify /etc/openvpn/scripts/connect.sh via-envpara obtener el nombre de usuario del usuario. ¿Sabes si también puedo obtener la identificación del certificado que está usando el usuario? Si es así, entonces puedo escribir un script de Perl que verifique un archivo yaml con identificaciones cert certificadas.No soy un profesional de seguridad, soy estricto con la seguridad. Su pregunta llega precisamente al núcleo de la seguridad de TI: la confianza. Como lo veo, uno nunca debe suponer que se puede confiar en Bob. Claro, Bob podría ser un tipo realmente agradable y confiable. Ha trabajado en su empresa durante más de 20 años. Sin embargo, la persona "Bob" es completamente irrelevante en su infraestructura de TI.
Bob usa 'relevos' arbitrarios que permiten el acceso. Los relés pueden ser cualquier cosa: una contraseña, certificado, token de hardware, escaneo de iris, ADN. Son claves que permiten el acceso a su sistema. Si su pregunta es sobre verificar la identidad de la persona que está usando una clave, la única respuesta honesta probablemente sea que tendrá que estar en la misma habitación. En todos los demás casos, creo que no debes asegurarte de que Bob realmente es Bob y que actualmente no está retenido a punta de pistola mientras obtienes su acceso. Entonces, en su plan de diseño de infraestructura de TI, lo lógico es no referirse a "Bob": una entidad obtuvo acceso a su sitio.
Debido a que solo puede saber realmente que 'una entidad' obtuvo acceso con una llave que le pasó en el pasado, la perspectiva adecuada probablemente sea limitar el número de puertas que la llave puede abrir. Cuantas más llaves pases, menos puertas abrirán.
OpenVPN también tiene una opción para permitir solo una conexión concurrente por clave. Entonces, si Alice inicia sesión con la clave de Bob mientras Bob ya está adentro, a Alice se le niega el acceso. Desafortunadamente, esto también significa que Bob no puede iniciar sesión cuando Alice inicia sesión con la clave de Bob. Por lo tanto, debe configurar su sistema para informarle de intentos de inicio de sesión simultáneos desde múltiples IP de origen. Y comience ambos cuando ocurra alguna violación, por lo que Bob tendrá que marcar para pedir ayuda.
El punto es: no te asegures de cosas de las que no puedes estar seguro y tenlo en cuenta al diseñar tu plan de seguridad. Suponga que siempre hay una persona más inteligente, muy por delante de usted, que no puede esperar para demostrar que está equivocado ... solo 'por el lulz'. :-)
fuente