22 junio 2010

Seguridad por oscuridad, el caso del SSH

SANS notificó hace unos días que estaban detectando nuevos ataques de fuerza bruta contra los servicios SSH abiertos en Internet,  aunque con la novedad de utilizar además del método de autenticación tradicional de "password", otro que generalmente está habilitado (aunque depende de la instalación) "keyboard-interactive". 

Para evitar el ataque desde el ISC proponen deshabilitar este otro sistema  configurando la directiva ChallengeResponseAuthentication en "no" del archivo sshd_config, aunque esto puede dejar el servicio sin acceso si no está preparado el sistema para otro método de autenticación, como por ejemplo el uso de certificados.

Generalmente yo no me entero de estos ataques porque tengo configurado mi servicio de acceso seguro en un puerto distinto al 22, lo que evita en gran mayoría todos los intentos que no sean dirigidos como los de este caso, donde el problema viene de gusanos y ataques automáticos.

A la estrategia de cambiar el número del puerto a uno no estándar se le denomina "seguridad por oscuridad", y es un principio que se basa en la ocultación de información como contramedida para vulnerabilidades conocidas. Aunque esto ya lo comentó Lorenzo hace unos meses me gustaría retomarlo.

Hace un tiempo un amigoo me contó que en un curso donde impartían Linux el profesor recomendó no utilizar estas técnicas, ya que por definición la estrategia de seguridad por oscuridad es errónea. Este aventurero no es el único que piensa así y esta misma afirmación se puede encontrar en cientos de sitios, como por ejemplo OWASP.

Es obvio que es preferible mantener el puerto del demonio por defecto antes que dejar un usuario admin con contraseña admin, pero en igual de condiciones, ¿no lo pone un poquito más complicado el cambio del puerto? Si, uno muy sencillo de saltar, pero por ejemplo para el caso reportado por ISC, como mínimo evitará  que se tengan que revisar registros de intentos fallidos.

Muy distinto es disminuir el nivel de seguridad con el cambio de puerto si este es superior al 1024, ya que si se encuentra un DoS que tira el servicio, un usuario sin privilegios de administrador puede configurar un demonio en ese mismo puerto con el objetivo de capturar credenciales.

Por último recordar que para evitar este y otros ataques en SSH el verano pasado publicamos dos artículos con las opciones de seguridad más importantes que permite el servicio: parte 1 y parte 2

17 comments :

Román Ramírez dijo...

El concepto de seguridad por oscuridad no es incorrecto porque sea poco efectivo (poner un ladrillo de chicle, en la base de un rascacielos puede que sirva un tiempo).

Esa frase se refiere principalmente a los algoritmos de cifrado, que no se consideran robustos si parte de su fortaleza tiene que ver con mantenerlos en la "oscuridad".

Pero aplicado al caso concreto del SSH, ¿qué diferencia hay en cambiarlo de puerto? Pues que cuando las víctimas fáciles que lo tienen en el 22/tcp dejen de ser fáciles, cientos de millones de escaneos de baja latencia o distribuidos comenzarán a mirar todos los puertos.

Y con la confianza (absurda) de que "como lo he cambiado de puerto", pues es posible que otras personas hayan sido negligentes en la configuración.

Tópico: seguridad en todas las capas, seguridad en profundidad...

Anónimo dijo...

Hola,

"Pero aplicado al caso concreto del SSH, ¿qué diferencia hay en cambiarlo de puerto?"

La diferencia está en que las botnets y similares no pierden el tiempo escaneando todo el rango posible de puertos, y no encuentran tu SSH. Aparte, los firewalls tipo checkpoint y demás hacen que escanear no sea "le doy a nmap y ya está". No es tan fácil descubrir el SSH, y menos con el banner cambiado.

Si no lo encuentran, no te tiran el servicio y tienes cierto "margen" de tiempo en caso de que salga una vulnerabilidad.

Funciona en la práctica. Y no creo que tenga mucho sentido ponerse a debatir sobre seguridad por oscuridad, dado que funciona ...

Saludos,
Jaime.

Txalin dijo...

Hombre, yo tambien soy un fanatico de cambiar los puertos de "sitio" :) Pero esta claro que esa medida por si misma no es mas que el ladrillo de chicle que comenta Roman.

Porque obviamente, si cambias el puerto pero permites acceso root, con contraseña 1234, y de paso ftp anonimo sin filtrao de directorios, pues tienes un problema muy gordo. Evidentemente hay que combinar ambas tecnicas, especialmente en maquinas expuestas a internet, donde ademas de la securizacion tipica de los servicios (web, sftp, ssh, mysql), lo de cambiar los puertos de sitio es una tecnica buena para evitar escaneos automaticos

vierito5 dijo...

Cambiarlo de puerto, y banear a las IPs que entren al 22 y/o escaneen hacer ya lo creo que hace. Solo tienes que comparar logs entre las 2 máquinas xD Pero eso puede no ser la solución, puede que tu usuario medio cada 2x3 se esté equivocando y cayendo baneado.

Está claro que en el sistema de tu casa o en el de un servidor en concreto con acceso a poca gente puedes tenerlo en el puerto que quieras y ser todo lo bastardo que quieras con los baneos pero no puedes coger y hacer eso mismo en el servidor SSH con varios miles de usuarios y gran parte de ellos "desconocidos/usuario medios", por ejemplo un hosting que da acceso para subir los ficheros por sftp/scp.

Anónimo dijo...

Las frases que mas daño han hecho a la seguridad informatica: "la seguridad a traves de la oscuridad es mala" (y lo aplican a todo sin contemplaciones!), "si no haces responsible disclosure, es que eres de los malos", y "no lo toques que asi funciona".

Anónimo dijo...

IMHO irse a otro puerto no es oscuridad, sino "cambiar la configuración por defecto" :-)

Personalmente lo colgaría de un puerto alto altísimo que no estuviera entre los que escanea por defecto un nmap. El que lo descubra, se lo habrá ganado tras un #nmap -p-

Pptx

Alvaro dijo...

Estoy de acuerdo con lo anterior (sobre todo con anónimo número 1).

Lo que no entiendo es porque nunca se habla de port knocking cuando se intenta proteger puertos importantes.

En un servidor importante donde entran pocos me parece algo indispensable y nunca veo que se hable de ello.

Un saludo.

mgesteiro dijo...

más claro, agua!

genial.

Llallez dijo...

El problema de muchos profesores es que solamente son eso, profesores, nunca han tenido que enfrentarse a problemas reales y por eso se aventuran diciendo barbaridades.
El mejor profesor que he tenido me dio clase unas horas, aprendí más con él que en el resto de la carrera y su trabajo en la universidad era un "extra".

silverhack dijo...

Desde mi humilde punto de vista, pienso que otro factor importante al cambio de puerto es el tema de la documentación. No es lo mismo realizar esto InHome, que realizarlo InCorporate. Realizarlo en la empresa implica varios puntos, destacando sobre todo el que tengamos ciertos privilegios sobre el diseño, y que después de su montaje se documente bien, por si nos vamos.
Pensad por un momento que cambiamos todos los puertos bydefault por puertos bySilverhack, y, tiempo después, nos largamos.... Al tiempo motaríamos un pifostio de copón...
Saludetes

Anónimo dijo...

Pues yo utilizo el puerto por defecto en ssh (22).
Controlo eso si los accesos con una combinación de:
Denyhosts + ssh keys + conexiones concurrentes con iptables (2).

deltonos77 dijo...

Silverhack...para eso está el llamado proceso de documentación en una implantación :-)

LeGNa dijo...

Además de evitar scaneos automáticos, disminuirá el número de logs pero... eso no hará que la cadena sea más fuerte no?
Es más seguro el código privativo que el código libre?

Tal vez fue poco acertado nombrarlo y creó confusión.
Utilizaría más una expresión como
Seguridad con oscuridad.
Seguridad en la oscuridad.
y lo implementaría de esa manera.

silverhack dijo...

# deltonos77
Si se cumple es maravilloso....
Y si se modifica y se documenta todavia más.... ;-)

deltonos77 dijo...

@Silverhack: Claro, somos profesionales :)

deltonos77 dijo...

Silverhack...para eso está el llamado proceso de documentación en una implantación :-)

silverhack dijo...

Desde mi humilde punto de vista, pienso que otro factor importante al cambio de puerto es el tema de la documentación. No es lo mismo realizar esto InHome, que realizarlo InCorporate. Realizarlo en la empresa implica varios puntos, destacando sobre todo el que tengamos ciertos privilegios sobre el diseño, y que después de su montaje se documente bien, por si nos vamos.
Pensad por un momento que cambiamos todos los puertos bydefault por puertos bySilverhack, y, tiempo después, nos largamos.... Al tiempo motaríamos un pifostio de copón...
Saludetes