instalacion de un servidor shh

Este texto es sacado del sigueinte post orignial

INSTALANDO UN SERVIDOR SSH SECURIZADO

1. INTRODUCCIÓN.

Uno de nuestros clientes nos ha pedido que le instalemos, con urgencia, un servidor de ssh securizado, teniendo en cuenta que va a estar "abierto a internet", ni siquiera un triste firewall delante. Dicho servidor se usará como "puerta trasera" para acceder a ciertos servicios en caso de caída del firewall. Un poco rebuscado, pero es lo que han decidido ... Mientras lo voy preparando, voy a aprovechar para explicar las medidas a adoptar.

Con lo feliz que estaba yo poniendo en producción mi IPS ...

2. INSTALANDO EL SERVIDOR.

El servidor dará el servicio VPN para alcanzar ciertos servidores de la empresa. Hay un firewall detrás del servidor, pero no hay nada delante. VPN, en principio, puede considerarse un servicio seguro. Eso sí, el software de vpn es considerablemente más complicado que el de ssh, así que he decidido que voy a poner un servidor de ssh y que, una vez loggeado, root levantará el software de vpn.

Si recordáis, mis temores no son infundados. Hace poco tiempo hubo una vulnerabilidad gravísima que permitía sacar todos los certificados hechos con ciertas versiones del openssl (openssl -- predictable random number generator).

Lo primero es elegir el sistema operativo que, por supuesto, NO va a ser windows. Si bien es cierto que los BSD's son los más seguros que el resto de *nix, también lo es que son un poco latazo de configurar. Y como nosotros queremos que el servidor esté configurado en una tarde (bueno, yo no, pero los que mandan sí), y que podamos arreglar cualquier inconveniente en segundos e instalar software adicional (openvpn), vamos a elegir un RHE5, última versión.

3. DESHABILITAR SERVICIOS.

Lo primero será deshabilitar todos los servicios innecesarios. Aparte de poner IPTABLES es importante que ningún servicio esté escuchando en las interfaces de red, ya que un descuido podría ser fatal. Para ello, miramos los servicios activados con el commando setup y quitamos aquellos que no hacen falta, como gpm, hplip, mcstrans, setroubleshoot, atm, ... y también el siempre olvidado portmap.

Después de esto, el único que debería escuchar es ssh. Esto lo comprobamos así:

#netstat -nlp|grep -v 127.0.0.1
tcp 0 0 :::61022 :::* LISTEN 2428/sshd


En caso de una caída o vulnerabilidad de IPTABLES, esto nos salvará de que alguien se conecte a algún servicio "olvidado", como pudiera ser cups, y nos entre con algún exploit. Conviene recordar que los firewalls sólo ayudan en caso de descuidos. Nada más.

Esta es la lista de servicios que ha quedado tras hacer limpieza:


acpid
apmd
autofs
cpuspeed
crond
haldaemon
hidd
iptables
irqbalance
lm_sensors
mdmonitor
messagebus
microcode_ctl
network
ossec
readahead_early
smartd
snortd
sshd
syslog
sysstat



4. MODIFICAR SSH.

Vamos a hacer que ssh escuche en un puerto por defecto que no sea el 22. Para ello, modificaremos la línea PORT en el fichero /etc/ssh/sshd_config y pondremos uno conveniéntemente elegido, en nuestro caso el 50127. Con esta medida, nos quitamos de encima escaneos automatizados.

Aparte, para que no sepan qué servicio está escuchando en el puerto 50127, vamos a modificar el banner del ssh. Creamos un fichero /etc/ssh/sshd_banner vacío y cambiamos la correspondiente línea en /etc/ssh/sshd_config (buscar Banner). De esta forma, nmap ni se entera del servicio que hay escuchando en el puerto. Podéis comprobarlo con nmap -sV -p0 -p 50127 192.168.1.1. Nota: un día de estos hablaremos de los scanners de vulnerabilidades (nessus, metasploit, nmap, cain&abel, ... y su utilidad REAL, no lo que nos venden).

Finalmente, crearemos un usuario, NO root, que será el único que tenga permitido el acceso por ssh: useradd miusuario. Para restringir el acceso a sólo este usuario, añadimos una nueva línea al final del /etc/ssh/sshd_config que ponga AllowUser miusuario, lo cual impide el acceso a root al mismo tiempo que lo abre a nuestro nuevo usuario. Y para permitir que este usuario pueda hacer su root modificamos /etc/group y lo metemos en el grupo wheel. Observar que no le hemos puesto password al usuario. Esto es porque queremos que SOLO se entre con certificado. Nada más.

Para hacer login con nuestro usuario: ssh -p 50127 miusuario@servidor.com -i /path/to/private/key

5. IPTABLES.

Aparte de quitar todos los servicios posibles, vamos a crear nuestro propio firewall con iptables. Lo que haremos es:

- permitir todas las conexiones entrantes al puerto del ssh, el 50127.
- denegar todo lo demás.
- permitir sólo el tráfico desde direcciones ip de España (excelente medidad para evitar sustos).

Nuestras reglas, aparte de un montón de DROPs para cortar ssh desde subredes peligrosas, quedarán básicamente como siguen:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport $PUERTO_SSH -m state --state NEW -j ACCEPT
-A INPUT -j DROP


6. CERTIFICADO.

Por supuesto, no entraremos con password y nada más. Vamos a crear un certificado dsa de 1024 bits para el usuario "miusuario". De esta forma, nadie podrá reventar el password por fuerza bruta. Deberemos guardar una copia del certificado en sitio seguro, y esto incluye un backup convenientemente cifrado en algún lugar apropiado.

Para generar las claves públicas y privadas, hacemos ssh-keygen -t dsa -b 1024. El archivo id_dsa.pub tenemos que copiarlo al home del nuevo usuario que hemos creado y la clave privada será la que usemos para entrar.


7. DETECCIÓN DE INTRUSOS: snort y ossec.

No es el momento de dar detalles de cómo se instalan estas herramientas. Simplemente decir que instalaremos ambos detectores de intrusos, y pondremos ossec a leer los logs de snort y enviar alertas por correo a nuestra cuenta del trabajo.

Al instalar ossec es importante poner la opción respuesta activa a yes, para que cuando alguien intente entrar por fuerza bruta ossec banee su IP.

Dentro del ossec.conf, para evitar que nos fría con falsos positivos, vamos a eliminar todas las reglas excepto las siguientes:


rules_config.xml
pam_rules.xml
sshd_rules.xml
syslog_rules.xml
ids_rules.xml
ossec_rules.xml
attack_rules.xml
local_rules.xml


Es posible que en el futuro tengamos que quitar más, pero de momento lo que hemos quitado es más que suficiente. Notar también como la respuesta activa de ossec se ha activado sola, suponiendo que hayamos elegido active response => yes al instalar ossec..

8. QUITAR PAQUETES INNECESARIOS.

Si nos entran con un 0-day de ssh, nos damos por jod****. Si alguien es capaz de hacer algo así, podemos estar seguros de que no encontrar el rpm de gcc no va a suponer un gran problema. Este paso, en el que tanto se suele insistir, nos lo vamos a saltar.

9. PARTICIONES.

De la misma forma, no necesitamos preocuparnos de cómo está configurada la tabla de particiones. Rotaremos los logs normalmente y punto. No es un apache en el que puede haber una denegación de servicio a base de freir el servidor a peticiones.

10. LYNIS.

Ya hemos hablado de esta herramienta. Lynis chequea defectos de configuración para buscar posibles fallos (p.ej. ficheros setuidados) y da un report al final con las indicaciones que necesitamos. Ejecutarla es tan sencillo como esto:

wget http://www.rootkit.nl/files/lynis-1.2.6.tar.gz
tar xzf lynis-1.2.6.tar.gz
cd lynis-1.2.6
./lynis --check-all -Q


Y al final tenemos nuestro report. En nuestro caso, la lista de sugerencia es bastante inútil:

- [09:52:49] Suggestion: Confirm that freshclam is properly configured and keeps updating the ClamAV database [test:MALW-3286]

No haremos caso, porque nuestro servidor es sólo una pasarela hacia otros servidores, sin discos compartidos ni nada así. De hecho, tener una tarea del cron corriendo y bajándose cosas de un servidor, clamav, e instalándolas es peligroso. Podrían hackear el servidor y, a la vez, usarlo para entrar en el nuestro.


11. CONCLUSION.

En este artículo, hemos visto como se configura un servidor ssh seguro abierto a internet. Los pasos son sencillos y el nivel de seguridad conseguido es bastante alto (la única forma de entrar es con un exploit para ssh, imposible a día de hoy). El servidor puede ser usado para acceder a segmentos de red sensibles desde internet de forma segura, siempre y cuando el sitio desde el que accedemos sea seguro.

Saludos y hasta pronto.

PD: si alguien quiere hacer alguna sugerencia, estaré encantado de escucharla ...

FUENTE:http://hacking-avanzado.blogspot.com/2009/04/instalando-un-servidor-ssh-securizado.html