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.

VPN – explicación para DUMMIES

Hola a todos,

Las VPN (Virtual Private Network) o Red Privada Virtual, ha dia de hoy no es algo oscuro y raro, hay extensa documentación repartida por todo internet, desde lo que és, hasta como montarla con diferentes sistemas operativos y hardware de distintos proveedores. Mi intención con el siguiente post, no es repetir (aunque tal vez ya exista un post por internet que no haya visto) lo que aparece en todos lados, sino intentar explicarlo de forma somera, mundana y para DUMMIES.

Bueno aquí vamos:

¿Que es una VPN?

Una VPN, sirve como objetivo principal para comunicar 2 o más ubicaciones (redes) y que puedan trabajar como si estuviesen “virtualmente” en la misma ubicación, pudiendo así, compartir y acceder a los recursos de las ubicaciones.

Vale, pero ¿como funciona?

Bueno, simplificandolo mucho, una VPN establece un “tunel virtual” entre la red origen y la red destino. Es igual lo que haya por medio, veamos algunos ejemplos de uso con los que tal vez quede más claro:

RED1 — INTERNET — RED2   —> Aqui se establecería un “tunel virtual” que iría desde la red1 hasta la red2 cruzando internet, y permitiendo a la red1 acceder de forma “segura” a los recursos de la red2 y viceversa.

vpn1 vpn1

Photo Credit: DesktopSupport via Compfight cc

USUARIO REMOTO — INTERNET — RED_EMPRESA —> Este es otro ejemplo de uso, el caso sería igual que el anterior, pero difiere en que  es un usuario en concreto el que se podría conectar desde “cualquier parte del mundo” a la red de su empresa y acceder a los recursos de la misma,  cruzando internet a través del “tunel virtual”.

RED1 — RED2 — RED3 –> Este es otro escenario, en el que dentro de una empresa con 3 redes distintas, necesitamos que de alguna forma la RED1 acceda a los recursos de la RED3, cruzando la RED2. Y que la Red2 no tenga acceso a la RED1 ni a la RED3, evidentemente hay otras formas de realizar esto, pero es otra posiblidad.

vpn2

 

Photo Credit: DesktopSupport via Compfight cc

¿Es segura una VPN?

Ha día de hoy, hay que decir que depende de la implementación que se utilice, escenario, y demás… pero si se toman las medidas oportunas y se planifica correctamente, una VPN es “bastante segura”, hay varias protocolos a elegir para implementar VPN’s como pueden ser IPSEC, L2TP, PPTP, etc.

¿A quien puede servir montar una VPN?

A todo el mundo, ya que una VPN es barata dependiendo de lo que quieras realizar, muchos routers ya tienen la opción de crear VPN, y para usuarios remotos con tener un cliente VPN (Muchos Sistemas Operativos, ya lo traen por defecto instalado) ya está.

Tambien se puede montar por software, o sea que el que haga de servidor o servidores sea un software tipo OpenVPN o el RRAS de MS. Vamos que la infraestructura para montarlo esta al alcance de todo el mundo. Y proporciona seguridad, anonimato, y acceso a nuestras infraestructuras desde cualquier lugar.

Además, hay clientes VPN para dispositivos móviles, android, iphone, etc.

¿que más quereis?

Espero que este post os haya gustado.

Alternativas al netcat

El otro día en twitter tuve un pequeño lapsus sobre las alternativas a netcat, esta mañana me ha venido a la memoria que el socat no es parte del proyecto nmap, por lo tanto, he vuelto a mirar las opciones y aqui esta el resultado correcto:

cryptcat [http://cryptcat.sourceforge.net/] .-  Es una implementación de netcat que permite encriptación twofish, esta disponible para windows nt, BSD y linux.

socat [http://www.dest-unreach.org/socat/].- Tal y como dicen en su web es un netcat ++ permite multiples conexiones, redirección de puetos y mucho mas…. disponible para AIX, BSD, HP-UX, Linux, Solaris e.a. (UNIX).

ncat [http://nmap.org/ncat/].- Este SI pertenece al proyecto nmap, ha sido reimplementado por el equipo de nmap, tiene soporte para SSL,  conexiones a traves de proxy SOCKS4, esta disponible para LINUX, MAC Y WINDOWS. Y viene por defecto en el mismo paquete que el nmap. Es una herramienta un poco desconocida  pero  muy util, lástima que muchos no comprobemos lo que se instala cuando montamos algo en nuestros equipos.

Bueno espero que está mini explicación aclare un poco más el tema.

saludos a todos,

Mini chuleta de NETCAT

Hola a todos, hoy en twitter @SeguInfo hacia referencia a una gran herramienta que ha sido considerada como la navaja suiza del tcp/ip, bueno tras ver la notica y aunque se han escrito hasta libros referente a ella, os adjunto un mini-chuletario que realize en su día del uso de la misma, aqui viene.

Escanear puertos:
nc -vvw 2 ip_destino puerto/s
Ejemplo: c:\>nc -vvw 2 localhost 1-1024

Para guardar el resultado en un fichero.
nc -vvw 2 localhost 1-200 >nom_fichero 2>&1

Montar un miniservidor web
nc -lp 100 nom_fichero

Ejemplo:
El equipo origen tiene la ip 192.168.0.1
El equipo destino tiene la ip 192.168.0.2

Origen:
type hola.zip | nc -lp 900 192.168.0.2
Destino:
nc 192.168.0.1 900 >fichero.zip

Crear un Talkd, para conversación ip en plan irc.
El que crea la conversación (Servidor)
nc -lvvp puerto    ejemplo: nc -lvvp 1234

El que se conecta (cliente)
nc -tvv puerto     ejemplo: nc -tvv 1234

Para crear conexiones telnet

Para hacer de Servidor:
nc -tlp puerto -e cmd.exe

El cliente:
nc -t ip puerto

Para que el equipo remoto me envie una consola:
Destino:
nc -lp 5000 -nvv
Origen:
nc -e cmd.exe -n ip puerto
nc -e cmd.exe -n 127.0.0.1 5000

Para dejar escuchando el equipo en un puerto y cancelar si el equipo no tiene una ip determinada.
nc -lp 999 192.168.0.2
Nota: si yo hago un nc – t ip_destino y mi ip no es la 192.168.0.2 el nc se cancela.

Para hacer de cliente telnet
nc -tvv ip puerto

Para transferir ficheros
Origen:
type nom_fichero | nc -lp 900

Destino:
nc ip puerto > nom_fichero

Ejemplo:
El equipo origen tiene la ip 192.168.0.1
El equipo destino tiene la ip 192.168.0.2

Origen:
type hola.zip | nc -lp 900 192.168.0.2
Destino:
nc 192.168.0.1 900 >fichero.zip

Con el netcat6 de linux permite cortar la comunicación del fichero con la opción -q 0.
cat fich | nc6 -lp 900 -q 0

Si ya se que es repetir lo mismo una y otra vez, pero por si hay algún despistado por hay aqui tiene algo con lo que probar……

Nada como siempre espero que sea de ayuda…. saludos a todos,