Más seguros en su puerta SSH

Formas adicionales para fortalecer el acceso SSH

La seguridad no es una ciencia exacta, así que entre más dificultades ponga usted en el camino del pirata informático, mejor. Este artículo considera cómo mejorar el acceso Secure Shell (SSH) al eliminar contraseñas y usando pares de claves públicas/privadas en su lugar. El artículo también explora cómo reconocer y bloquear posibles ataques, incluyendo ataques de fuerza bruta y con diccionarios, al negar al servidor acceso a orígenes que se identifiquen como inseguros.

Federico Kereki, Systems Engineer, Freelance

Photo of Federico KerekiFederico Kereki es un ingeniero de sistemas uruguayo con más de 20 años de experiencia desarrollando sistemas, realizando trabajo de consultoría y enseñando en universidades. Ha estado trabajando con software de fuente abierta por más de 10 años y aprecia particularmente la gran seguridad de Linux. Recientemente escribió Essential GWT, un libro sobre esta herramienta de fuente abierta.


Nivel de autor contribuyente en developerWorks

24-02-2012

Mi primer artículo sobre fortalecimiento del acceso SSH (vea Recursos) consideró tres métodos que se ajustan a operaciones pequeñas, como un servidor de casa o un servidor de pequeña empresa con pocas personas requiriendo acceso SSH remoto:

  1. Cambiando el puerto SSH estándar por un valor inusual y reforzar la configuración SSH para que los ataques simples reboten.
  2. Definiendo una lista restringida de usuarios a los que se les permite iniciar sesión usando Pluggable Authentication Modules (PAM).
  3. Ocultando completamente el hecho de que usted incluso permite acceso SSH y requiriendo una secuencia de "golpe" especial para ser reconocido como posible usuario.

El uso de PAM para definir una lista restringida de usuarios que tienen permitido iniciar sesión, todavía tiene sentido para configuraciones más grandes, pero las otras dos opciones pueden tornarse molestas. Por lo tanto, este artículo examina un par de métodos para mejorar la seguridad que usted puede aplicar más fácilmente a configuraciones más grandes:

  • Conexiones sin necesidad de contraseña
  • Rechazando atacantes

Conexiones sin necesidad de contraseña

Las contraseñas no son seguras contra métodos de ingeniería social por una variedad de razones—demasiados usuarios escriben sus contraseñas para no olvidarlas, las miradas "sobre el hombro" (la razón por la que la mayoría de los cajeros automáticos tienen una especie de cubierta sobre sus manos), rastreadores de teclado y más. Además, si usted usa contraseñas que no sean complejas, los ataques de fuerza bruta o por diccionario pueden lograr recuperarlas y comprometer su sitio.

Usando PuTTY con claves de acceso público/privado

El reconocido programa de terminal PuTTY puede usar pares de claves públicas/privadas, pero usted debe convertirlas de alguna forma porque el programa requiere un formato de archivo específico. Después que usted genera su par de claves como se muestra en el texto, use este comando: puttygen path.to.your.private.key -o path.to.your.putty.key. Luego, abra PuTTY y seleccione Connection > SSH > Auth para tomar su archivo de clave privada recién generado. Después de hacer esto, usted puede usar su par de claves para inicios de sesión sin uso de contraseña vía PuTTY.

Al utilizar inicios de sesión con claves públicas/privadas, usted administra sin contraseñas. La parte pública de su par de claves reside en el servidor, y usted conserva si clave privada segura en su máquina o máquinas remotas. Usted también puede proteger su clave privada con una frase de seguridad para seguridad adicional, como verá en este artículo. Otras personas no podrán iniciar sesión como usted a menos que obtengan su clave privada porque, al menos actualmente, no es computacionalmente factible derivar una clave de otra. Consulte Recursos para más información sobre claves públicas/privadas RSA.

Primero, trabajando como raíz, asegúrese de que su configuración sshd permite inicios de sesión para clave privada. El archivo de configuración /etc/ssh/sshd_config debe incluir las líneas RSAAuthentication yes y PubkeyAuthentication yes como se muestra, sin marcar. Si este no es el caso, añada o modifique las líneas y reinicie el servicio con /etc/init.d/sshd reload. Luego, use ssh-keygen para crear un par de claves públicas/privadas. Usted necesita un par para cada usuario que podrá realizar inicios de sesión remotos sin contraseña. Observe el Listado 1 a continuación como ejemplo.

Listado 1. Use ssh-keygen para generar un par de claves pública/privada
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/fkereki/.ssh/id_rsa): /home/fkereki/mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/fkereki/mykey.
Your public key has been saved in /home/fkereki/mykey.pub.
The key fingerprint is:
6c:36:09:fc:7f:63:27:ff:0b:cd:7c:7f:a9:e9:60:ec fkereki@fkereki-desktop
The key's random art image is:
+--[ RSA 2048]----+
|                 |
|     .           |
|      o          |
|       + .       |
|        S        |
|       o o.   +  |
|          .+=..+o|
|          oo.=o.+|
|           E.+oo=|
+-----------------+

Crear un par de claves es solo el primer paso. Usted debe copiar la parte pública en el servidor al cual desee conectarse. Varios sitios on-line recomiendan que edite directamente ciertos archivos para lograr esto, pero usando el comando ssh-copy-id es mucho más fácil. Observe el Listado 2 a continuación como ejemplo.

Listado 2. Use ssh-copy-id para enviar su clave pública al servidor remoto
$ ssh-copy-id -i /home/fkereki/mykey.pub fkereki@some.server.com
The authenticity of host 'some.server.com (123.45.67.89)' can't be established.
RSA key fingerprint is 16:a4:d8:6a:ee:e0:8d:f4:72:a8:af:42:75:1d:28:3b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'some.server.com,123.45.67.89' (RSA) to the list of known
hosts.
fkereki@some.server.com's password:

Probar su conexión sin uso de contraseña es fácil: ssh remote_user@remote_host es suficiente. Si usted usó una frase de seguridad cuando creó el par de claves (y debería haberlo hecho, como explicaré en breve) debe digitarla. Si todo se ha hecho correctamente, usted establece una conexión SSH con el servidor remoto sin tener que ingresar su contraseña para esa máquina. Observe el Listado 3 a continuación como ejemplo.

Listado 3. Use ssh para intentar su inicio de sesión sin uso de contraseña
$ ssh fkereki@some.server.com
Enter passphrase for key '/home/fkereki/mykey':
Last login: Mon Jan 10 18:40:11 2011
$ logout
Connection to some.server.com closed.

Recordando sus contraseñas

Para usuarios que prefieran una interfaz gráfica de usuario (GUI), es posible que usted desee observar el comando keychain . El comando keychain le permite resumir un ssh-agent entre inicios de sesión, incluso después de un cierre de sesión. Es posible que usted tenga que utilizar el gestor de paquetes de su distribución para instalar este comando (normalmente no está incluido de forma predeterminada). Para usarlo, ingrese keychain path.to.your.private.key desde la línea de comandos, ingrese su frase de seguridad, y habrá terminado. Su frase de seguridad es almacenada hasta que reinicie el servidor y usted no necesitará volverla a ingresar. Si usted desea borrar todas las claves en caché, use keychain --clear o keychain -k all para detener el programa completamente. Los usuarios de GNU Network Object Model Environment (GNOME) pueden desear ver la aplicación Seahorse similar (vea Recursos).

Ahora usted puede ver por qué usar una frase de seguridad es mejor. Si usted no usa una cuando crea el par de claves pública/privada, cualquiera que tenga acceso a su equipo—y por lo tanto a su clave privada—puede lograr acceso de forma inmediata a todos los servidores remotos en los que usted pueda iniciar sesión. Usar una frase de seguridad añade otro nivel de seguridad porque usted puede llevar su clave privada con usted en una memoria Universal Serial Bus (USB) y usarla desde cualquier equipo para iniciar sesión en sus servidores remotos. Sin una frase de seguridad, si pierde su memoria USB compromete automáticamente a todos sus servidores.

Desde luego, tener que ingresar una frase de seguridad cada vez que inicia sesión eventualmente se convertirá en algo molesto y es bastante inconveniente para procesos no atendidos como una copia de seguridad diaria con rsync. Existe una solución para esto. Use ssh-agent al comienzo de su sesión y ssh-add para cada una de las frases de seguridad y luego sus frases de seguridad serán ingresadas automáticamente por usted. Observe el Listado 4 a continuación como ejemplo. Usted puede usar ssh-agent -k para detener su sesión actual. Después de eso, usted tendrá que ingresar su frase de seguridad nuevamente para cada inicio remoto de sesión.

Listado 4. Usar ssh-agent le evita tener que re-ingresar su frase de seguridad en cada inicio de sesión
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-Rvhhx30943/agent.30943; export SSH_AUTH_SOCK;
SSH_AGENT_PID=30944; export SSH_AGENT_PID;
echo Agent pid 30944;

$ ssh-add
Enter passphrase for /home/fkereki/mykey:
Identity added: /home/fkereki/mykey (/home/fkereki/mykey)

$ ssh fkereki@some.server.com
Last login: Mon Jan 10 18:44:15 2011 from 192.168.1.108

Rechazando atacantes

Incluso si usted implementa todas las medidas de seguridad discutidas hasta ahora tanto en este artículo como en el anterior, puede apostar que todavía habrá piratas informáticos intentando obtener acceso a sus servidores, usando métodos de fuerza bruta si es necesario. Pero hay una solución simple para eso. Piense qué sucede si usted ingresa su contraseña incorrectamente suficientes veces. Usted quedará bloqueado(a) durante cierta cantidad de tiempo durante el cual no podrá intentar un nuevo inicio de sesión. Usted aplica esta técnica para quienes podrían ser piratas, modificando el sistema de manera que rechace conexiones de las IP de los piratas. Desde luego, usted no necesariamente desea imponer esta medida para siempre, así que después de un tiempo razonable, usted vuelve a aceptar conexiones de esas IP. No obstante, si los piratas comienzan nuevamente con sus trucos, la IP es rechazada de nuevo, haciendo así que sea casi imposible que acceda a su servidor.

Existen muchas herramientas para esto, como DenyHosts, Fail2ban, BlockHosts y más (vea Recursos). Este artículo se concentra en DenyHosts. Dicho esto, si usted desea proteger servicios diferentes a SSH, los otros programas podrán estar mejor adaptados. Note que todos estos paquetes son considerados estables y que no han tenido nuevos releases desde hace dos años o más. Entonces, no piense que son obsoletos ni que se han abandonado, y no permita que esta falta de actualizaciones le desaliente de usarlos.

DenyHosts escanea periódicamente los registros de autenticación de su servidor en busca de intentos recientes de inicios de sesión no exitosos. Cada vez que el número de intentos provenientes de una misma dirección IP llega a cierto umbral, DenyHosts reacciona añadiendo una línea, como sshd:111.222.33.44 al archivo /etc/hosts.deny. Esto bloquea un potencial ataque por fuerza bruta. Usted puede configurar DenyHosts para que le notifique a usted sobre cualquier IPs bloqueada vía e-mail. Después que pasa un tiempo especificado, DenyHosts usa un método similar para permitir intentos de inicio de sesión desde la IP original, a menos que esa IP haya sido bloqueada muchas veces, en cuyo caso el rechazo será permanente.

DenyHosts está escrito en Python. Por lo tanto, el único requisito es que usted tenga Python versión 2.3 o posterior disponible. Aunque usted puede obtener los paquetes binarios para algunas distribuciones, la instalación desde la fuente es bastante simple. Obtenga el paquete (vea Recursos) y siga las breves instrucciones mostradas en el Listado 5 para preparar la aplicación para configuración.

Listado 5. Instalación de DenyHosts desde la fuente
$ tar zxvf DenyHosts-2.6.tar.gz
$ cd DenyHosts-2.6
$ su
$ python setup.py install
$ cd /usr/share/denyhosts
$ cp denyhosts.cfg-dist denyhosts.cfg
# ... now edit denyhosts.cfg ...

El archivo denyhosts.cfg-dist sugerido tiene algunos valores razonables, pero usted debe editarlos para que se ajusten a su entorno. Probablemente usted desee observar los parámetros descritos en la Tabla 1 a continuación.Existen incluso más parámetros, pero estos son los que usted probablemente desee modificar primero.

Tabla 1. Parámetros de configuración a modificar para DenyHosts
ParámetroDescripción
ADMIN_EMAILSu dirección de e-mail. Si está presente, este parámetro le permite recibir mensajes de e-mail cada vez que DenyHosts decida bloquear un host. Si usted configura este parámetro, modifique también SMTP_HOST y SMTP_PORT para especificar su servidor de e-mail y para verificar otros parámetros SMTP_ .
AGE_RESET_VALIDSimilar a PURGE_DENY (vea a continuación) este define el lapso de tiempo después del cual, si no hay intentos fallidos adicionales, el conteo de fallas para un host se reinicia a cero. AGE_RESET_INVALID es similar pero aplica a intentos (fallidos) de inicio de sesión de usuarios no existentes, mientras que AGE_RESET_ROOT pertenece a intentos fallidos de inicio de sesión raíz. Usted también debe configurar RESET_ON_SUCCESS para definir si el conteo de intentos inválidos para una IP es o no es reiniciado a cero después de un inicio de sesión exitoso. El valor predeterminado es no, pero yo prefiero yes porque si usted algunas veces escribe mal la contraseña, a pesar de haber podido iniciar sesión varias veces, eventualmente quedará bloqueado.
DAEMON_PURGEDefine con qué frecuencia DenyHosts revisa si hay hosts que se deben desbloquear. Este valor puede ser mucho mayor que el tiempo entre ejecuciones, por ejemplo 2h (cada dos horas) o 1d (una vez al día).
DAEMON_SLEEPEspecifica cuánto tiempo espera DenyHosts entre verificaciones sucesivas de SECURE_LOG. Un valor razonable puede ser 30s (treinta segundos), por ejemplo. Usted no deseará ejecutar el script con demasiada frecuencia (gastando ciclos de procesador) ni demasiado esporádicamente (dando total libertar a los piratas).
DENY_THRESHOLD_VALIDDefine cuántos intentos fallidos de inicio de sesión (para usuarios válidos, no raíz) serán tolerados antes de bloquear el host. También hay un valor DENY_THRESHOLD_ROOT que aplica exclusivamente para intentos raíz de inicio de sesión, pero usted estará mejor prohibiendo directamente la raíz para que se conecte remotamente mediante SSH con su servidor, como se mostró en el artículo anterior. Otro valor, DENY_THRESHOLD_INVALID, aplica para intentos de inicio de sesión de usuarios no existentes. El valor anterior debe ser menor que aquel para los usuarios válidos, porque es más probable que este tipo de intento de inicio de sesión sea parte de un intento de phishing.
HOSTS_DENYDebe apuntar al archivo con los datos de acceso de host restringido, el cual normalmente es/etc/hosts.deny. Este parámetro es obligatorio. Si está mal, DenyHosts no funcionará como se espera.
LOCK_FILEEs la ruta y el nombre del archivo, si existe cuando usted ejecute DenyHosts, que hace que salga inmediatamente (por ejemplo, /tmp/denyhosts.lock). El archivo es similar a /etc/nologin, el cual hace que los intentos de inicio de sesión fallen. Si el archivo no existe cuando usted ejecute DenyHosts, será creado y luego eliminado al salir para evitar tener dos instancias del programa ejecutándose al mismo tiempo.
PLUGIN_DENYApunta hacia una aplicación que usted desee ejecutar siempre que se bloquee un host. La aplicación es invocada con el host como un argumento. Usted debe usar esto siempre que desee efectuar acciones adicionales, como actualizar una base de datos. De forma similar, la aplicación referida por PLUGIN_PURGE es llamada cuando un host es removido del archivo HOSTS_DENY.
PURGE_DENYDefine el tiempo después del cual un host bloqueado es permitido nuevamente. Si está vacío los host quedarán bloqueados permanentemente. Esta entrada puede estar en minutos (120m), horas (2h), días (14d), semanas(2w), o años (1y).
PURGE_THRESHOLDDefine cuántas veces un host puede desbloquearse antes de quedar bloqueado para siempre. Si es cero, los host pueden ser bloqueados y desbloqueados un número infinito de veces.
SECURE_LOGLa ruta y nombre del archivo donde sshd registra sus mensajes. Esto varía de distribución a distribución. Por ejemplo es /var/log/messages para openSUSE®, pero para otras distribuciones use /var/log/secure o /var/log/auth.log. Recuerde también configurar sshd de forma que produzca registros. Si este parámetro está equivocado, DenyHosts simplemente no funcionará.
WORK_DIRLa ruta para los archivos propios DenyHosts, la cual normalmente es /usr/share/denyhosts/data. Si la ruta no existe, será creada.

Ahora, configure DenyHosts para que se ejecute. Aunque usted puede ejecutarla desde la línea de comandos (e incluso desde un archivo cron, si lo desea) el método preferido es en modalidad daemon configurándolo como un servicio para que comience a ejecutarse en el arranque. Observe el Listado 6 a continuación para los pasos requeridos.

Listado 6. eUsted puede configurar DenyHosts para que se ejecute en el arranque
$ su
$ cd /usr/share/denyhosts
... edit daemon-control-dist (see below) and then ...
$ cp daemon-control-dist /etc/init.d/denyhosts
$ chown root.root /etc/init.d/denyhosts
$ chmod 700 /etc/init.d/denyhosts
$ chkconfig denyhosts on
$ /etc/init.d/denyhosts start
... or ...
$ /sbin/service denyhosts start

Usted debe editar los tres parámetros del comienzo del script daemon-control-dist para que DenyHosts sepa dónde encontrar sus archivos. Estos parámetros se describen a continuación en la Tabla 2.

Tabla 2. Parámetros a editar en el script daemon-control-dist
ParámetroDescripción
DENYHOSTS_BINApunta al script denyhosts.py.
DENYHOSTS_LOCKApunta al archivo de bloqueo.
DENYHOSTS_CFGApunta al archivo de configuración, el cual es /usr/share/denyhosts/denyhosts.cfg para el ejemplo en este artículo.

Usted ha terminado. Desde ahora, DenyHosts verificará regularmente sus registros sshd, identificará posibles ataques y bloqueará las IP que los originan según corresponda.

Conclusión

Este artículo cubrió más métodos para fortalecer el acceso SSH a su servidor. Usando claves públicas/privadas con frases de seguridad para protegerlas es la forma más segura para permitir acceso a un servidor. Tener a su servidor reconociendo posibles ataques y bloqueando posibles piratas informáticos antes de que puedan siquiera intentar deducir una contraseña, también mejora su seguridad. Desde luego, como siempre en el campo de la seguridad, no crea que cualquier número de prácticas seguras pueden garantizar realmente que su servidor no será atacado por piratas, pero los obstáculos adicionales para los atacantes serán obligatorios.

Recursos

Aprender

  • Consulte el artículo previo, "Three locks for your SSH door" (developerWorks, agosto del 2010) para más métodos para asegurar el acceso a su servidor.
  • consulte la barra lateral "Using rsync without a password" en "The rsync family" (developerWorks, abril del 2009) para una aplicación de sincronización de certificados con datos sin uso de contraseña.
  • Para más información sobre el algoritmo RSA, el cual se usa para generar pares de claves públicas/privadas en este artículo, revise el artículo original de los creadores de RSA y el estándar actual para este.
  • La área de developerWorks de AIX y UNIX ofrece una riqueza de información relacionada con todos los aspectos de los sistemas de administración AIX y con la expansión de sus habilidades.

Obtener los productos y tecnologías

  • Para proteger el acceso SSH contra ataques piratas por fuerza bruta, consulte DenyHosts.
  • Si desea proteger otros servicios contra atacantes, Fail2ban (básicamente cualquier servicio) o BlockHosts (SSH y File Transfer Protocol, o FTP) puede servirle.
  • Pruebe el software IBM gratuitamente. Descargue una versión de prueba, inicie sesión una prueba on-line, trabaje con un producto en un entorno de área segura, o acceda a través de la nube. Escoja entre más de 100 productos de prueba IBM.
  • Lea más sobre Keychain y Seahorse, para simplificar su experiencia de usuario con claves privadas almacenadas y KDE o Gnome.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=
ArticleID=795380
ArticleTitle=Más seguros en su puerta SSH
publish-date=02242012