Bastionado de servidores ssh

Recientemente adquirí un servidor dedicado que utilizo para, entre otras cosas, compartir ficheros entre amigos. En principio, la compartición de ficheros se iba a hacer mediante HTTPS, por lo que el servidor SSH no tenía ninguna configuración fuera de lo normal. Bastó con algunos cambios de la configuración por defecto para tener algo un poco más robusto:

Port X
Protocol 2
ServerKeyBits 4096
LoginGraceTime 30s
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers usuario

Sé que me he dejado varias cosas importantes, como toda la gama de los forwardings, y que cambiando el puerto en el que escucha el demonio SSH no se soluciona nada (seguridad por oscuridad)… excepto todos los intentos realizados por bots, que creedme, son bastantes.

Como se puede comprobar, los cambios en la configuración del cuadro anterior, fuerzan el protocolo 2 (a estas alturas, el protocolo 1 no debería ser utilizado bajo ningún concepto) y aumentan el nivel de cifrado a 4096 bits, además de disminuir el tiempo permitido para realizar la autenticación y la cantidad de intentos permitidos. Como complemento a la directiva MaxAuthTries, se puede utilizar fail2ban o un HIDS como OSSEC (entre otras aplicaciones) para bloquear cualquier IP que esté realizando un ataque de fuerza bruta de manera automática.

Por último, también se deshabilita cualquier tipo de autenticación que no haga uso de la criptografía simétrica (llave pública/privada), y se limita el uso del servicio SSH al usuario “usuario”.

Pues bien, aunque en un principio todo esto era suficiente, llegó el día que todo sysadmin teme: el día que un amigo, con conocimientos suficientes para hacerte pasar un mal rato, te pide acceso al servidor para, en este caso, subir unos ficheros. Paranoico que es uno, busqué la mejor manera de limitarle cualquier acción realizada que tuviese fines educativos, por lo que hice los siguientes cambios en la configuración de SSH:

Subsystem       sftp    internal-sftp
AllowUsers usuario usuario2
Match Group grupo2
    ChrootDirectory /home/incoming
    ForceCommand internal-sftp
    PasswordAuthentication yes
    ChallengeResponseAuthentication yes

De este modo, todas las restricciones propuestas originalmente permanecen establecidas por defecto, excepto para el grupo “grupo2” (si se cambia la directiva Match Group por Match User, haríamos la excepción para el usuario que viene a continuación, y si se cambia por Match address, la haríamos para la IP que establezcamos).

Con todos estos cambios, se evita que el usuario obtenga una $SHELL y/o ejecute cualquier comando en el sistema, quedando prohibido cualquier acceso que no venga a través del protocolo sftp (scp también queda prohibido). Tampoco se permite que pueda leer y/o escribir en cualquier directorio/fichero que quede fuera del chroot definido con anterioridad.

Una vez mi amigo acabó de subir ficheros, procedí a dejar la configuración original y eliminar el usuario recientemente creado. ¿Y vosotros, qué métodos utilizáis para proteger vuestro servicio SSH?

Comments

  1. http://gmuslera says

    Desactivar TCP/X11 forwarding tiene sentido si ese servidor no esta aislado y tenes permiso para el para acceder a otros lados o servicios, incluso en el mismo equipo (no se si se podria usar para acceder a cosas habilitadas para localhost, como el /server-status del apache)

    Otra cosa que se puede usar (para evitar que te exploten en el futuro alguna vulnerabilidad que eventualmente aparezca o no conozcas aun del ssh) es usar portknocking (tal vez con certificado, como hace el fwknop) para que el puerto sea visible solo para la gente que tiene ese certificado o sabe la secuencia para abrir el puerto.

  2. Gracias por la información.

    Saludos

Trackbacks

  1. […] publicó un post relacionado con este, del cual recomiendo su lectura íntegramente (https://www.securityartwork.es/2013/10/23/bastionado-de-servidores-ssh/). Para no repetir recomendaciones, mostraré a continuación puntos en los que […]