SSH. Un poco de seguridad parte 4. (Bajando capas OSI para ahorrar ciclos de procesador)

Hola a todos,

No voy a daros una charla sobre protocolos de red, mi objetivo es daros unos pequeños apuntes de como securizar ssh, pero en este caso me intentaré centrar en optimizar algunas cosillas para ahorrar algunos preciosos ciclos de procesador evitando que este se colapse. ¿Cómo? pues ahora lo veremos.

Comentaré que si no recuerdo mal el ssh es un protocolo que trabaja en capa 7 (aplicación), para evitar que el tráfico NO necesario llegue a esta capa utilizaremos un FIREWALL en nuestro caso IPTABLES, que en estado puro funciona a nivel de capa 3 y 4 (red y transporte), evitando entonces con nuestras configuraciones que el tráfico no deseado llegue hasta la capa 7 ahorrando ciclos de procesador y dando un poco de vidilla al servidor.

Voy a trabajar desde la consola, y sin fichero de configuración, más que nada porque cada uno trabaja y se lo monta según sus necesidades, y como lo que nos interesa es ver QUE HACEMOS luego el COMO dependerá de cada escenario, necesidades y preferencias de cada uno de nosotros, además empezaré desde un sistema limpio, así que hay vamos.

En todos los ejemplos utilizaré por defecto politicas DROP para INPUT, OUTPUT Y FORWARD.


#iptables -P INPUT DROP
#iptables -P OUTPUT DROP
#iptables -P FORWARD DROP

En el primer ejemplo vamos primero a pensar que a nuestro servidor ssh solo queremos que se pueda acceder desde una ip que podría ser el equipo del administrador, supondremos que nuestro amigo BOFH tiene la ip 192.168.88.34 y que la ip de nuestro FW es la 192.168.88.35.

En este caso nuestro objetivo será habilitar el acceso a una ip en concreto, como tenemos las politicas en DROP tendremos que habilitar la entrada y salida al puerto 60222 (recordad que nuestro ssh no está escuchando en el 22 sino en el 60222 ver articulos anteriores.


#iptables -A INPUT -i eth0 -s 192.168.88.34 -p tcp --dport 60222 -j ACCEPT
#iptables -A OUTPUT -o eth0 -d 192.168.88.34 -j ACCEPT

Veamos en resultado de un iptables -nL

iptables1

Podemos observar que solo se acepta el protocolo tcp puerto 6022 desde el SOURCE (origen 192.168.88.34) y también se permite TODO el trafico hacia el destino 192.168.88.34, también podríamos haber acotado el protocolo, o haber utilizado el parámetro established pero de momento a mi para las pruebas ya me va bien.

Bien con esto en principio bastaría para bloquear casi todos los tipos de ataque, pero es muy probable que necesitemos acceder a nuestro servidor desde cualquier ubicación, incluida desde internet, tenemos un problema.

Bueno os doy algunas soluciones, podéis crear reglas para permitir rangos de ips, o establecer una vpn para tener un ip válida con la que acceder y/o filtrar vuestro servidor. Si aún así no es viable y tenemos a nuestro servidor dando servicios a internet, nos puede interesar mitigar posibles ataques automatizados típicos, que crearían multiples conexiones para intentar acceder a nuestro ssh. Para ello podemos utilizar las siguientes reglas.


#iptables -I INPUT -p tcp --syn --dport 60222 -i eth0 -m recent --set
#iptables -I INPUT -p tcp --syn --dport 60222 -i eth0 -m recent --update --seconds 300 --hitcount 2 -j DROP

Y al hacer el iptables -nL

iptables2

Con estas líneas le estamos diciendo a iptables que controle quien intenta establer conexión -p tcp --syn y accede más de 2 veces (–hitcount) en 5 minutos, le haga un drop. Evidentemente los parámetros se deben ajustar al nivel de paranóia de cada BOFH.

Hace tiempo vi un script en bash utilizando a nuestro amigo netcat que para probar esto me va a venir muy bien sin tener que utilizar complejas herramientas:

lo he llamado ataca.sh:

script

NOTA: MI AMIGO FRANGOR me ha echado una bronca somera por este script y me ha obligado a cambiarlo o me pegaba….. como no me quiero pelear con el os pongo sus “modificaciones justificadas”, por mi parte he mejora tambien una opcion del netcat ya que sino tarda mucho. VAMOS que se ha optimizado el script. Gracias frangor

ataca.sh


#!/usr/bin/env bash

for i in {1..5} ; do
echo “exit” | nc -vv -w 1 192.168.88.35 60222;
done

Sobre las modificaciones comentar que el #!/usr/bin/env bash es para mejorar la portabilidad, y el -w 1 es el timeout para conexiones y lecturas finales de red

Pues nada hay queda dicho.

Al ejecutarlo nos aparecerá lo siguiente:

resultadoscript

Como podéis observar en la imagen anterior, tras ejecutarlo, y aún teniendo permitido el acceso desde mi ip, no me ha dejado conectar, he tenido que esperar 5 minutos para poder volverlo a intentar.

 

acceso

Bueno y hasta aquí por hoy, espero que este tuto haya sido claro, didáctico y de utilidad para alguno de vosotros.

SSH. Un poco de seguridad parte 3

Hola a todos de nuevo.

En el post de hoy os voy a explicar como “ocultar” nuestra versión de ssh para que cuando nos hagan por ejemplo un escaneo no detecten que versión exacta de ssh tenemos, ¿que ganamos con esto? que si la versión que estamos utilizando tiene algún bug reconocido, puedan utilizarlo contra nosotros.

ADVERTENCIA: NO ME RESPONSABILIZO DE ESTAS MODIFICACIONES EN ENTORNOS DE PRODUCCIÓN, OS RECOMIENDO SIEMPRE QUE LAS PRUEBAS LAS REALIZEIS EN UNA MÁQUINA VIRTUAL ANTES DE PONERLAS EN PRODUCCIÓN YA QUE OS PUEDE OCURRIR QUE NECESITÉIS COMPILAR CON OTRAS OPCIONES DIFERENTES. MI PROPOSITO ES EXPLICAR QUE ES LO QUE SE TIENE QUE HACER, PERO ES IMPOSIBLE ABARCAR TODAS LAS DISTRIBUCIONES Y ESCENARIOS.

 

ANTES DE NADA OS COMENTARE COMO TENGO EL EQUIPO:

Es una Debian con instalación solo del sistema Base, instalada desde una netinstall. VAMOS pelao pelao. Os lo digo porque lo que yo os explique aquí es válido para Debian, pero en otros sistemas VARIA la cosa.

AL TAJO:

Primero nos descargaremos los sources de openssh, ¿Como? ahora vamos a eso…..

#wget http://ftp.caliu.cat/debian/pool/main/o/openssh/openssh_5.9p1.orig.tar.gz

Una vez descargado, realizamos el típico #tar xvfz openssh_5.9p1.orig.tar.gz que descomprimirá el paquete dejándolo en la carpeta openssh-5.9p1.

Bien, como dependencia importante necesitamos los headers de openssl y las librerias zlib, ambos paquetes los encontraremos en libssl-dev asi que:

#apt-get install libssl-dev

Una vez instalados entramos en el directorio de openssh-5.9p1 y buscamos el archvivo version.h. Modifichamos el texto entre “” que hay después de #define SSH_VERSION con lo que nosotros queramos, en mi caso, en lugar de poner alguna chorrada, voy a poner una versión inferior a la que voy a instalar. Ejemmplo 4.1 y la cosa queda como la imagen de acontinuación.

version-h

Y ahra solo nos queda los típicos:
./configure
make
make install

Cuando acaba el make install nos deja el sshd en /usr/local/sbin/sshd y nos crea un script en /etc/init.d/ssh

Ahora el problema es que este fichero /etc/init.d/ssh hay que modificarlo para que apunte al fichero sshd que toca, lo editamos y donde encontremos /usr/sbin/sshd lo sustituimos por /usr/local/sbin/sshd

Una vez realizado esto reiniciamos el servicio ssh como siempre para comprobar que funciona correctamente:

#service ssh restart

y este es el resultado de nuestro nmap

nmap-sshversio

Pues nada amigos, hasta aquí por hoy, otro día más 🙂

SSH. Un poco de seguridad parte 2

Tal y como mencione en mi anterior post voy a continuar con el tema del SSH.

Soy un PESADO, pero aún así reitero mi introducción del primer post.

Ante todo comentar que no soy un super profesional en seguridad, simplemente soy un administrador de sistemas que se preocupa en tener sus sistemas lo más securizados posibles, entre otras cosas por eso de que me gusta dormir tranquilo por las noches 🙂 , seguramente la gran mayoria de vosotros me daréis mil vueltas en estos temas, mi objetivo principal es dar unas pequeñas pautas sobre como dar un poco de seguridad al SSH, no voy a cubrir la instalación ya que hay abundante información sobre ello en internet y considero que repetir el proceso constantemente es perder el tiempo, adjuntaré algunos enlaces a algunos tutos excelentes y lo más sencillos posibles, y siempre que sea posible intentaré enlazar con documentación en castellano (por si alguien no se defiende bien con el inglés).

Al tajo, suponiendo que el equipo al que queremos acceder tenga varias tarjetas de red por X razones (porque hace de proxy, o de firewall, o cualquier otra), no estaría mal por nuestra parte limitar qué tarjeta de red atenderá las peticiones SSH acotando así el área de exposición ante un posible ataque.

Imágen  cogida de la web de pello.info
Imagen cogida “prestada” de pello.info

En este ejemplo podemos ver que el equipo es un Firewall, con 2 interfaces, una al router y otra a la red local, es posible que nos interese acceder solo desde una de las 2 interfaces, o desde la red local o desde internet, ambas opciones tienen sus pros y sus contras y según las necesidades del administrador utlizará la que más le convenga, suponiendo que la interfaz entre el Firewall (FW a partir de ahora) y el router sea la eth1 con ip 10.0.3.15 y la interfaz entre el FW y la red local sea la eth0 con ip 192.168.88.33, voy a poner un ejemplo para limitar el acceso al FW por ssh para que solo la interfaz de la red local conteste a SSH.

Realmente es sencillo, bastará con descomentar el parámetro ListenAddres dejándolo como sigue:

ListenAddress 192.168.88.33

Reiniciamos el servicio y vemos si realmente está escuchando donde le hemos dicho.

listenlimit

Como me gusta este parámetro -putan :-). Biennn vamos mejorando un poco la seguridad de nuestro ssh ahora seguiremos con otro tema, cuando accedemos al sistema por ssh esto es lo que nos aparece.

 

banner1

mmmmmm nada de nada …. bueno, el que avisa no es traidor, vamos a pone un banner de PRE-LOGIN para advertir a quien se conecte que el servidor es privado y que solo tienen permiso los usuarios autorizados, esto os puede sonar raro, pero en algunos países, es necesario advertir para después poder tomar represalias legales.

Crearemos un fichero en /etc que llamaremos banner-ssh.txt donde escribiremos los siguiente

##############################################################
#
# THIS SYSTEM IS PROVIDED FOR USE BY AUTHORIZED USERS ONLY.
#
# EL ACCESO A ESTE SISTEMA ES SOLO PARA USUARIOS
# AUTORIZADOS
###############################################################

lo grabaremos y editaremos el fichero sshd_config descomentando y modficando el parámetro:

Banner /ec/banner-ssh.txt

Reiniciamos el servcio y vemos que ocurre ahora.

banner2

El que avisa no es traidor 🙂 evidentemente no es una opción de seguridad pero al menos de esta forma nadie podrás decir que no lo sabían.

Continuamos, otro parámetro del sshd_config que merece mención es el MaxAuthTries, donde podemos definir el número de intentos para dar contraseña a un sistema, por defecto SSH te permite 3 intentos, pero podemos todavia reducirlo más. ¿Que ganamos con esto? …. relentizar algunos scripts por fuerza bruta, debido a que si en lugar de tener 3 intentos para probar contraseñas tiene por ejemplo 2 o 1 y se desconecta la sesión, evidentemente se hace más laborioso tener que volver a establecer conexión y volver a probar.

El parámetro no aparece por defecto en el fichero de configuración, así que lo añadimos:

MaxAuthTries 2

Reinicamos el servicio del ssh: #service ssh restart

Veamos su efecto.

maxauthtries

Vemos que antes he podido insertar 3 contraseñas pero que después me ha sacado fuera al introducir la 2ª.

Otra opción más que interesante es MaxStartups con la que podemos limitar el número de intentos de login simultáneos. Intentaré explicarme un poco mejor. Supongamos que tengo el MaxStartups a 1, significa que solo 1 conexión podrá intentar acceder al sistema, si mientras estoy intentando hacer login hay otra conexión que intenta acceder, el ssh cerrará la conexión. Os adjunto un pantallazo para que se vea más claro.

maxstartups

Vosotros me diréis, pues vaya tontería, bueno… tontería según para quien se mire, con esto evitamos que los ataques que utilicen multithreads para realizar fuerza bruta o comprobar diccionarios se vean muy mermados si en lugar de poder realizar las 10 conexiones simultáneas de login que permite por “defecto” el ssh se encuentran con que solo permite 1 o 2. Aquí como en todo los posts, que cada uno utilice lo que le interese o pueda necesitar, o que lo adapte a sus necesidades reales.

Se me olvidaba, el parámetro MaxStartups no viene por defecto, lo tenemos que agregar al fichero tal que así:

MaxStartups 1

Acordaros de reiniciar el servicio después de guardar cualquier cambio en el sshd_config.

Otros parámetros que merece la pena comentar:

LoginGraceTime Este parámetro indica el tiempo que podemos estar esperando en la pantalla de login para introducir nuestros datos de autenticación, antes de que el ssh nos desconecte, por defecto viene en 120 segundos (2 MINUTOS!!!!), con 30 segundos es más que suficiente. Sería así:

LoginGraceTime 30

Y lo último por hoy, si no voy a utilizar el sftp, scp, rsync ¿porque los dejo disponible por “defecto”?. La forma más sencilla es comentando la línea:
# Subsystem sftp /usr/lib/opeenssh/sftp-server

Y este es el resultado:

sftp

Como habéis podido observar hasta el momento, simplemente cambiando unos cuantos parámetros de configuración del SSH con “cabeza” adaptándolo a vuestras necesidades se puede mejor BASTANTE la seguridad del mismo, me gustaría hacer hincapié en que las configuraciones por defecto ya sea en cualquier sistema operativo, servicio, etc. no son las más adecuadas para todo tipo de usuarios, esto es un mal que tanto usuarios, empresas y profesionales pecan todos los días sin tener en cuenta las repercusiones que puede producir este tipo de configuraciones. Recordad, aprended con que estáis trabajando y de vez en cuando RTFM.

Bueno, y hasta aquí por hoy, seguiremos con esta serie de post sobre un poco de seguridad con ssh.

Reitero lo mismo de siempre, si encontráis algún fallo, error o no entendéis algo, ya sabéis que estoy a vuestra disposición (en mi tiempo disponible que no es mucho).

Espero que os sirva de ayuda. See you ….

SSH. Un poco de seguridad

Hola a todos,

Ante todo comentar que no soy un super profesional en seguridad, simplemente soy un administrador de sistemas que se preocupa en tener sus sistemas lo más securizados posibles, entre otras cosas por eso de que me gusta dormir tranquilo por las noches 🙂 , seguramente la gran mayoria de vosotros me daréis mil vueltas en estos temas, mi objetivo principal es dar unas pequeñas pautas sobre como dar un poco de seguridad al SSH, no voy a cubrir la instalación ya que hay abundante información sobre ello en internet y considero que repetir el proceso constantemente es perder el tiempo, adjuntaré algunos enlaces a algunos tutos excelentes y lo más sencillos posibles, y siempre que sea posible intentaré enlazar con documentación en castellano (por si alguien no se defiende bien con el inglés).

Para el desarrollo de este tuto he utilizado varias VM’s, sobre Debian Squeeze.

Para quien no sepa que es SSH recomiendo la siguiente entrada en la Wikipedia

Bueno, para la instalación os recomiendo un tuto del gran @foratinfo que lo encontraréis aquí.

Sobre la securización de SSH hay (como escuche en un podcast de @daboblog a Sergio Hernando) enemil opciones, evidentemente no voy a poder abordar todas las opciones, pero al menos intentaré llegar hasta donde mis limitados conocimientos lleguen.

Bueno se acabó el parafrasear, vamos un poco al lio.

Para comprobar si está instalado el servicio, podemos acceder desde la propia consola o desde otra máquina con #ssh root@ip_servidor o podemos realizar un nmap para ver como si el puerto esta abierto.

quickscan1

Bueno, como se ve en la imagen el SSH está en el puerto 22, que es el puerto “habitual” del SSH, pero mmmmmmm esto personalmente no me gusta, entre otras cosas porque hay herramientas que escanean los puertos estandard de los servicios (véase nmap) y su identificación es muy rápida, YO considero una “buena práctica” cambiar el puerto “por defecto” por un puerto que no sea típico, en el ejemplo utilizaré el 60222.

Bueno, vamos a cambiarlo, en Debian el fichero de configuración del servidor ssh lo encontraremos en /etc/ssh/sshd_config lo editamos con vuestro editor favorito y modificamos el parámetro Port 22 por Port 60222 guardamos el fichero y reiniciamos el servicio ssh con #service ssh restart

Veamos que nos dice nmap al ahora con un quickscan.

Uep, no se detecta nada en los puertos estandar que hagan referencia al ssh, bueno esto me gusta más, ahora el que quiera buscar en el servidor el servicio ssh tendrá que hacer un escaneo más completo. Lo cual ya molesta un poco más, pero evidentemente el puerto aparece, tal y como se puede ver con el scaneo completo de puertos tcp.

quickscan2

Más adelante, mostraré como ocultar la versión que se ve en el nmap, para despistar y confundir a un atacante, pero como es un tema algo más avanzado lo dejaré para otro post.

Bueno, ya tenemos algo más asegurado el ssh, pero mmmmmmmm muchas herramientas “automáticas” conocen que la cuenta con más privilegios del sistema es root y que seguramente el administrador la tendrá “por defecto” para entrar en el sistema. Bueno aquí otra buena practica es NO utilizar la cuenta root para acceder directamente a nuestro servidor SSH, además evitaremos algunos ataques automatizados por fuerza bruta, así que, podemos crear una cuenta normal del sistema y luego una vez logeados en el sistema realizar un su o un sudo a gusto del consumidor para realizar las tareas que requieran de privilegios.

No voy a explicar como crear una cuenta de usuario en un GNU/Linux, pero si voy a explicaros como denegar el acceso al root por ssh. Aqui vamos……..

Editamos e fichero de configuración y modificamos el parámetro PermitRootLogin yes por:

PermitRootLogin no

Reiniciamos el SSH y probamos a ver que pasa ahora.

#service ssh restart

ssh-root

Uep…. permission denied. Genial!!!!! Ahora podemos entrar con cualquier otro usuario y listo… mmmmm un segundo cualquier otro usuario ….. nop, peligro….. eso no está bien, cualquiera quiere decir cualquiera….. llamadme paranóico pero eso no es bueno y considero otra “buena practica” que se límite siempre quien y a que se tiene acceso… así que vamos a rizar un pelín el rizo así que voy a crear un usuario digamosle “fpalenzuela” y le vamos a decir al ssh que solo fpalenzuela tendrá acceso al ssh.

Editamos de nuevo el sshd_config y agregamos/modificamos la siguiente entrada.

AllowUsers fpalenzuela

También podríamos forzar a que ese usuario solo pueda acceder desde una ip determinada agregando un nivel más de seguridad, seria como sigue.

AllowUsers fpalenzuela@192.168.88.3

Aqui considero que se tiene que ser un poco flexible y ver las necesidades reales, si fpalenzuela solo se conectará desde una ip determinada la segunda opción es la más restrictiva si por el contrario fpalenzuela es un usuario móvil que está en distintas oficinas la primera es más recomendable. Bueno eso es a gusto del consumidor.

Hay otros parámetros a comentar, aunque veo que por “defecto”, Debian los trae deshabilitados, cosa que es de agradecer. Los menciono a continuación.

Protocol 2 .- Esto indica que el ssh solo acepta conexiones de SSH v2, evidentemente más seguras que las versions anteriores del protocolo.

PermitEmptyPasswords no .- No creo que sea necesario explicar esta opción ya que el propio parámetro es autoexplicativo.

Y bueno, hasta aquí de momento. Dejo para próximos posts la continuación de este.

Desde aquí espero que os sea de utilizad, y agradezco a los compañeros y PROFESIONALES en MAYÚSCULAS de twitter @daboblog, @seguridadyredes, @foratinfo, @sergiohernando por sus aportes en sus respectivas áreas a la comunidad.

PD: Si alguien encuentra algún error en el presente documento, que no dude en ponerse en contacto conmigo que con mucho gusto lo modificaré.

Hasta la próxima…..

samba – papelera en recurso compartido – vfs_recycle

Buenas a todos,

Tras realizar algunas pruebas he conseguido hacer funcionar un Stackable VFS modules, concretamente el vfs_recycle que permite tener una papelera de reciclaje en recursos compartidos de red con SAMBA, cosa que viene muy bien cuando los usuarios son un desastre y evitar tener que estar tirando de backups constantemente.

En el smb.conf en el apartado [Global] hay que añadir lo que queremos:

vfs object = recycle
recycle:repository = .recycle
recycle:keeptree = yes
recycle:versions = yes

y luego en el apartado del recurso compartido añadir la siguiente opción:

vfs object = recycle

y listo, esto crea en el recurso donde lo hemos puesto una carpeta .recycle (queda oculta, pero ojo si accedes desde windows con la opción “mostrar ficheros y carpetas ocultas” lo puedes ver), donde deja los ficheros que has borrado del recurso compartido.

Tambien se puede cambiar a otra carpeta fuera del recurso pero eso es a gusto del consumidor y de vuestras propias necesidades, para mas info podéis consultar la documentación al respecto en la web de SAMBA

NOTA: Si ya usáis otro vfs object, bastará con añadir este a continuación, ejemplo:

vfs object = full_audit recycle

No olvidéis nunca ejecutar el testparm para comprobar que la configuraciónn es correcta.

Como siempre espero que esta información os sea útil. Saludos a todos compañeros.