Monday, April 13, 2009

SSH hardening





Mucha gente utiliza SSH para conectarse en forma remota a sus máquinas, tanto en el trabajo como en el hogar.

SSH, o Secure Shell es un programa que permite una conexion segura, encriptando todo el trafico que se envia por esta conexion. Dada su característica de Cliente/Servidor el mismo permite la comunicación simultanea de varios usuarios.

SSH esta expuesto a los siguientes ataques y limitaciones :

Password Cracking
: Un keylogger o una password simple puede poner en peligro toda la seguridad del sistema. SSH solo encripta lo que transmite.

IP y TCP Attacks : Dado que SSH se ejecuta en la capa TCP del protocolo IP, esta expuesto a ataques de DoS.


Traffic Analysis :
Si bien el trafico esta encriptado, el análisis del mismo puede dar información relevante sobre lo que se transmite, backups, transacciones...


Covert Channels :
Es el método de ocultar información dentro de trafico valido. SSH esta expuesto a este tipo de ataques.


Estupidez humana : Un ejemplo de esto pueden encontrarlo aca : How Paris Got Hacked?


Este post tiene como objetivo dar algunos tips de como configurar la conexion SSH de manera segura mediante el hardening del servicio.


El primer tip es mantener siempre actualizada la versión que tengamos ejecutando.

Una rápida búsqueda en Securityfocus nos da una idea de las vulnerabilidades existente en diferentes implementaciones de SSH :

http://www.securityfocus.com/swsearch?query=ssh&sbm=advisories&submit=Search!&metaname=alldoc&sort=swishrank


Vamos tener como supuesto que no tenemos IP's fijas por lo tanto no es posible utilizar los archivos de hosts para limitar la conexion.

etc/hosts.allow
etc/hosts.deny

Existen dos versiones de ssh, versión 1 y 2. La primera contiene vulnerabilidades conocidas, por lo tanto es mejor trabajar con la versión 2.


Protocol 2

El server sshd se configura mediante el archivo /etc/ssh/sshd_config. Aqui podemos setear varias opciones que nos permitirán realizar un hardening del servicio.

Para limitar los usuarios locales que pueden conectarse al server, se encuentra la entrada Allowusers. En el siguiente ejemplo solo permitiremos conectarse al usuario julioj.


AllowUsers julioj

Nunca, pero nuuunnnca !!!! Permitan la conexion remota por medio del usuario root. Recuerdan eso de seguridad en profundidad, ok este es un punto a tener en cuenta como mitigacion en caso que una vulnerabilidad existente permita la conexion remota. El atacante no solo debera la cuenta de un usuario valido y la password para poder accesar.

Para limitar el acceso del usuario root debemos agregar la siguiente linea :


PermitRootLogin no


El port por default del servicio sshd es el 22, pero porque facilitar las cosas ? Pongamos un poco de oscuridad al asunto. Cambiemos el port 22 por el 222. Tengamos en cuenta que nuestro cliente debería apuntar a este nuevo destino. El parámetro SilentDeny evitara dar información al atacante ( y al usuario también ) en caso de error en la autenticación.

Port 222
SilentDeny yes


SSH nos permite utilizar el server como Proxy para conectarnos a equipos detras de la red, esto se realiza por medio de la opción ForwardAgent, como estamos realizando una configuración segura, es recomendable deshabilitar esta opción.

ForwardAgent no
ForwardX11 no

Si queremos una configuración realmente segura debemos dejar de lado las passwords y conectarnos mediante certificados digitales, para esto primero debemos deshabilitar la posibilidad de utilizar passwords y habilitar el uso de certificados :

PasswordAuthentication no
RSAAuthentication yesAllowedAuthentications publickey
RequiredAuthentications publickey


Vamos a limitar el numero de veces que podemos ingresar la password, para evitar ataques de fuerza bruta. Luego de ingresar la password mal dos veces, se cerrara la conexion.

MaxAuthTries 2

Siguiendo la prevención de limitar el campo de ataque, la idea ahora es reducir la cantidad de logins concurrentes que permitiremos. Dado que estamos trabajando en una configuración hogareña, solo permitiremos dos pantallas de login concurrentes.


MaxStartups 2


Vamos a setear un timeout de 30 segundos para el momento del login.


LoginGraceTime 30

En caso de abandonar la máquina por unos minutos y olvidarnos de cerrar la conexion, configuraremos un timeout para prevenir el uso de la terminal por otras personas.


IdleTimeout 15m

Para evitar conexiones que no encrypten la comunicación, agregaremos estas entradas que evitan la no utilización de cifrado. Es interesante decir que un atacante puede modificar estas entradas a "none" y hacer que nuestra comunicación se establezca en claro. Para evitar esto, tenemos que compilar el SSH con la opción -- without-none.


Ciphers anycipher
Ciphers anystdcipher



La configuracion del archivo /etc/ssh/sshd_config quedaria de este modo :

Protocol 2

Port 222

SilentDeny yes


PasswordAuthentication no


PermitRootLogin no


RSAAuthentication yes


AllowedAuthentications publickey


RequiredAuthentications publickey


MaxStartups 2


LoginGraceTime 30


IdleTimeout 15m


Ciphers anycipher


Ciphers anystdcipher


ForwardAgent no
Forward X11 no


Por supuesto que esta configuración por si sola no hace de nuestra máquina una bastilla, pero en lo que respecta al SSH es un buen comienzo.

Dado que recomendé la utilización de certificados, estos deben tener algunas consideraciones :

Las llaves deben tener al menos 1024 bits, y se debe usar una muy buena password, mi recomendación es utilizar un frase que contenga letras minusculas y mayusculas y de un largo importante ( > 25 caracteres ).

Explicar la configuración de las llaves escapa a este post, por lo tanto lo dejamos para futuras entradas.

3 comments:

>> s E t H << said...

esta bueno el post, pero que es encrYptar?

segun google, "Quizás quiso decir: encriptar" :P

Julio Jaime said...

Es un método usado por los Mayas para poner en cryptas los corazones de los enemigos.

Tengo que tomarme unos minutos para releer los posts y corregir los errores. Por suerte tengo visitas que me dan una mano !!!

Solucionaste le problema en tu blog ?

>> s E t H << said...

no, el que me daba hosting deja de pagar asi que ni lo levanto. Capaz mas adelante lo vuelva a poner en un hosting gratuito, vendo publicidad y pago uno bueno pero tampoco tengo tanto tiempo para escribir, me la paso leyendo foros y feeds. Igual escribo en overload

si los lectores le decimos al que escribe los errores nos aburrimos :P