SSH en la práctica Existen dos protocolos SSH Versión 1 y 2, existen grandes beneficios el usar un protocolo más nuevo. Por tal comentaremos la versión 1 de nuestra configuración. Protocol 2 Y cuando hagamos cambios, debemos regenerar nuestras llaves publicas y claro reiniciamos el servicio. # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # /etc/init.d/sshd restart [ SUCCESSFUL ] Secure Shell Daemon [ SUCCESSFUL ] Secure Shell Daemon
Cerrando a un ip, puerto estándar o no-estándar Cuando tengamos más de 2 tarjetas de red, viene un problema a cuál de ellas escuchará la solicitud de sesión remota. Para este ejemplo usaremos 192.168.0.1 para la red interna, editaremos nuestro archivo sshd_config: ListenAddress 0.0.0.0 Cambiamos a 0.0.0.0 to 192.168.0.1: ListenAddress 192.168.0.1 Y para verificar, damos un restart al servicio y netstat para ver que está escuchando en los puertos TCP. /etc/init.d/sshd restart [ SUCCESSFUL ] Secure Shell Daemon [ SUCCESSFUL ] Secure Shell Daemon netstat -anp | grep sshd tcp 0 0 192.168.0.1:22 0.0.0.0:* LISTEN 7868/sshd Para ver más al respecto del comando Network Statistics (netstat), y claro el ejemplo anterior, ignora toda interface a excepción la obligada. Al igual es importante cambiar el puerto estándar a otro no-estándar con el fin de dar salto a nuestra compuerta 22, digamos cambiarla por 31337. Cambiamos nuestras líneas en la configuración:
Port 22 Lo cambiamos 22 a 31337: Port 31337
Restauramos el servicio y verificamos en el netstat: # netstat -anp | grep sshd tcp 0 0 192.168.0.1:31337 0.0.0.0:* LISTEN 330/sshd Y finalmente nos conectamos ssh -p 31337
[email protected]
Usando TCP Wrappers TCP Wrappers es una herramienta simple que sirve para monitorear y controlar el tráfico que llega por la red. Esta herramienta ha sido utilizada exitosamente en la protección de sistemas y la detección de actividades ilícitas.
Los Wrappers son ampliamente utilizados, y han llegado a formar parte de herramientas de seguridad por las siguientes razones: Debido a que la seguridad lógica está concentrada en un solo programa, los Wrappers son fáciles y simples
de validar. Debido a que el programa protegido se mantiene como una entidad separada, éste puede ser actualizado sin necesidad de cambiar el Wrapper. Debido a que los Wrappers llaman al programa protegido mediante la llamada al sistema estándar exec(), se puede usar un solo Wrapper para controlar el acceso a diversos programas que se necesiten proteger. TCP Wrappers son usados para limitar el acceso al servidor. Estan basados en dos archives configuración /etc/hosts.allow y /etc/hosts.deny. Para nosotros, nos ayudará para decider cuales direcciónes IP, tienen permiso para SSHd, para este ejemplo: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # ALL: ALL # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # sshd: 207.46.236. 198.133.219.25 En este ejemplo, se acceso limitadamente a la red por 207.46.236.0/24 y 198.133.219.25. Si requiere otro servicio del cualquier dirección es negada "ALL: ALL" por parte de hosts.deny. Se enviaría un error similar a: ssh_exchange_identification: Connection closed by remote host
Una configuración simple para resolver un problema potencial de estar expuesto el servicio al mundo. Limítelo y fíltrelo.
Llave pública como método de autenticación Eliminar el password de acceso es recomendable, pues lamentablemente se usan password fáciles de encontrar en un diccionario de Fuerza Bruta de Ataque. Si el administrador tiene ese criterio por un descuido, decimos adiós a la seguridad primaria. Todas las distribuciones trabajan con una llave pública default, veamos como viene predeterminada en la configuración. RSAAuthentication yes PubkeyAuthentication yes Ambos esquemaas están afirmativos, RSA es para SSH ver 1, y PubKey para SSH2. Ya entrando en el tema, desabilitemos el password de entrada. PasswordAuthentication no Perfecto, antes de proceder con los cambios, entremos a la terminar a trabajar. Una vez que restauremos SSHd no podremos entrar, solo con una llave pública que generaremos. # /etc/init.d/sshd restart [ SUCCESSFUL ] Secure Shell Daemon [ SUCCESSFUL ] Secure Shell Daemon Ahora, entremos al servidor: $ ssh
[email protected] Permission denied (publickey,keyboard-interactive). Como verán estamos encerrados. Siguiente paso es generar la llave de trabajo: $ ssh-keygen -t dsa -C "Profe SSHv2 DSA Key (feb 2008)" Generating public/private dsa key pair. Enter file in which to save the key (/home/rwm/.ssh/id_dsa): Enter passphrase (empty for no passphrase): ********** Enter same passphrase again: ********** Your identification has been saved in /home/rwm/.ssh/id_dsa. Your public key has been saved in /home/rwm/.ssh/id_dsa.pub. The key fingerprint is: 98:4d:50:ba:ee:8b:79:be:b3:36:75:8a:c2:4a:44:4b Profe SSHv2 DSA Key (feb 2008) Condiciones para lograr esto: • •
Podemos generar distintos formatos seguros DSA (-t dsa), RSA (-t rsa), or SSHv1 (-t rsa1) para nuestras llaves. Para este ejemplo se usa dsa. Siempre procurar poner fecha en el comentario (-C) asi estaremos consientes de cambiar la llave en el tiempo pertinente.
• •
Estaremos poniendo una a Clave de Paso, no un password. Utilice espacios, puntuaciones, símbolos. Entre más largo, es complicado. El directorio de las llaves está oculto por tal debemos de invocarlo en ruta ~/.ssh/
El comando que trataremos utiliza dos archivos - id_dsa, nuestra llave privada y id_dsa.pub, llave pública. Es crítico que tengamos nuestra llave privada segura, pero podemos distribuir nuestra llave pública a los equipos que remotamente conectemos. Ahora, ya generamos una parte ahora debemos obtener la llave publica en ~/.ssh/authorized_keys a la maquina objetivo. La mejor manera es copy-and-paste, pasarla concatenada de esta forma a la llave pública: $ cat .ssh/id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAL7p6bsg5kK4ES9BWLPCNABl20iQQB3R0ymaPMHK... ... ds= Profe SSHv2 DSA Key (Feb 2008) Es una cadena de texto muy amplia. Asegúrese de copiar todo, evite copiar los espacios en blanco al final del paréntesis, la cadena es muy estricta. Siguiente paso es agregar la línea de cadena a ~/.ssh/authorized_keys en el servidor destino. El siguiente comando lo hará por nosotros copiando la cadena iniciando con KEY: echo "KEY" >> ~/.ssh/authorized_keys Ejemplo: echo "ssh-dss AAAA5kS9BWLPCN...s= Profe SSHv2 DSA Key (Feb 2008)" >> ~/.ssh/authorized_keys Ahora, inicia SSH de nuevo. Si no procede el acceso, pedirá la llave pública: $ ssh
[email protected] Enter passphrase for key '/home/rwm/.ssh/id_dsa': Last login: Thu feb 10 14:37:14 2008 from 201.200.3.201 [
[email protected] ~]$ Perfecto, ya pudo entrar con llave pública, en vez de password.
Créditos http://www.linuxsecurity.com/content/view/133312/171/
