Asegure su implementación de SSH con la autenticación de dos factores de WiKID

SSH ofrece un canal altamente seguro para la administración remota de servidores. Sin embargo, si enfrenta una auditoría por requisitos regulatorios o comerciales, como PCI de Visa/Mastercard, debe estar consciente de algunas posibles deficiencias relacionadas con la autenticación que pueden causar dolores de cabeza en una auditoría. Por ejemplo:

No hay forma de controlar qué usuarios tienen autorización de clave pública
No hay forma de hacer cumplir la complejidad de la frase de paso (o incluso estar seguro de que se está utilizando una)
No hay forma de expirar una clave pública

En este documento vamos a demostrar cómo combinar la autenticación de dos factores de WiKID con un servidor de puerta de enlace SSH con claves privadas alojadas para crear una solución de acceso remoto altamente segura, auditable y fácil de usar. El Sistema de Autenticación Fuerte de WiKID es una solución de autenticación de dos factores comercial/código abierto. Primero, configuraremos un dominio en el servidor WiKID, luego agregaremos los servidores como clientes de red al servidor WiKID, y finalmente configuraremos la caja de puerta de enlace y los servidores de destino, en nuestro caso, servidores Fedora Core 6.

Agregar un dominio al servidor WiKID

Crear un cliente de red

Después de guardar la información del dominio, haga clic en la pestaña Cliente de Red y Crear Nuevo Cliente de Red. Ingrese un nombre para este cliente y la dirección IP de la puerta de enlace SSH en la red interna. Seleccione Radius como protocolo y el dominio que creó anteriormente como dominio.

Haga clic en Agregar para obtener la siguiente página e ingrese el secreto compartido para Radius.

Necesitará repetir este proceso para cada servidor en su red.

Configurar la puerta de enlace SSH

Ahora configuraremos la puerta de enlace SSH central. Esta caja de linux es la puerta de enlace/proxy a todos los servidores de producción en la granja. Debe estar bien asegurada sin software o servicios innecesarios en ejecución. Debe tener una interfaz externa para conexiones entrantes y una interfaz interna para conexiones internas. Primero, configuraremos la caja de puerta de enlace para usar WiKID para la autenticación fuerte de los usuarios de SSH. Edite su archivo /etc/pam.d/sshd de la siguiente manera:

#%PAM-1.0   
auth       sufficient   /lib/security/pam_radius_auth.so   
auth       include      system-auth   
account    required     pam_nologin.so   
account    include      system-auth   
password   include      system-auth   
session    include      system-auth   
session    required     pam_loginuid.so

Agregue su servidor WiKID al archivo /etc/raddb/server, utilizando la dirección IP interna del servidor WiKID y el secreto compartido que ingresó en la página de creación del Cliente de Red:

# server[:port] shared_secret      timeout (s)   
127.0.0.1       secret             1   
xxx.xxx.xxx.xx  wikidserver_secret 3

Agreguemos también algo de seguridad a la configuración de SSH aquí. Abra su /etc/ssh/sshd_config (no el archivo cercano ssh_config). Agregue estas opciones de configuración:

#Protocol 2,1   
#Check that only protocol 2 is allowed:   
Protocol 2   
#Disallow root login:   
PermitRootLogin no   
#Disallow accounts without passwords:   
PermitEmptyPasswords no

Si desea cambiar el puerto, puede hacerlo. No detendrá a un atacante, pero podría reducir los eventos de registro causados por script kiddies. Esta caja de puerta de enlace ahora está configurada para usar contraseñas de un solo uso de WiKID para la autenticación SSH. Todos los usuarios deben estar registrados en el servidor WiKID y nadie puede iniciar sesión como root. Antes de dejar esta caja, haremos algo un poco diferente: haremos que los usuarios creen su clave privada RSA en la puerta de enlace. Una vez que cada usuario haya iniciado sesión en la caja con WiKID, pídales que creen sus claves:

ssh-keygen -t rsa

En mi opinión, las frases de paso para estas claves son redundantes. Están aquí solo para crear una funcionalidad de inicio de sesión único en la granja de servidores. Obviamente, debe tener cuidado de asegurarse de que los usuarios no tengan acceso a otras claves.

Configurar los servidores de destino

Obviamente, configuramos estos servidores para aceptar solo solicitudes SSH entrantes desde la puerta de enlace. Hacemos esto restringiendo el acceso en el puerto 22 a nuestras direcciones internas. Edite /etc/sysconfig/iptables y agregue o edite la línea para SSH en el puerto 22:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

Es probable que pueda usar la configuración estándar para sshd_config, que permite la autenticación de clave pública. ¡Así que hemos terminado!

Conclusión

SSH remoto es ahora extremadamente seguro. Ningún usuario puede acceder a la granja de servidores sin primero obtener un código de acceso de un solo uso del servidor WiKID. Los dos factores de autenticación son la posesión del token WiKID (y su clave criptográfica) y el conocimiento del PIN. Debido a que el PIN se valida en el servidor WiKID, es muy fácil deshabilitar a un usuario. Todo está registrado y cualquier auditor debería estar muy complacido.

Además, podría requerir un código de acceso de un solo uso de WiKID para el acceso root en máquinas internas. Simplemente cree un nuevo dominio para su y edite /etc/pam.d/su apropiadamente. Esto también le permitirá dividir los servidores en diferentes grupos para la gestión. Por ejemplo, si tiene un conjunto de servidores para RRHH a los que solo ciertos administradores tienen acceso root, pueden configurarse para un dominio WiKID específico, lo que permite un control de acceso granular y una autenticación fuerte. Obtenga más información sobre la autenticación de dos factores en el sitio web de WiKID.