Securizar SSH

La seguridad es un tema controvertido ya que por mucho que "securices" un servicio (como ssh en este caso) siempre puedes estar expuesto a un bug de otro servicio y/o aplicación, pero hay que intentar no ponerlo fácil.

Hace poco me pidieron consejo ya que vieron en los logs de ssh un nada despreciable número de ataques al día. Cuando ves esto te da un poco de (como mínimo) respeto ya que piensas que alguno puede lograr algo. Se que de ssh se ha escrito mucho y quizás no aporte nada nuevo, pero para ayudar a alguien o para reunir información os retoco el mail que le envié.

Todos los cambios en ssh se realizan en el siguiente fichero

sudo vim /etc/ssh/sshd_config

y después de estos para que surjan efecto se reinicia el servicio.

sudo /etc/init.d/ssh restart

Una cosa muy sencilla y que reduce sensiblemente los ataques es cambiar el puerto de escucha del servicio por otro de nuestra elección. Así salimos de los escaneos rápidos y no se identifica el servidor a simple vista.

Port xxxx

Si queremos que solo se acceda desde una interfaz de red, segmento de esta, ...

ListenAddress xxx.xxx.xxx.xxx

Aunque si instalamos actualmente cualquier servidor ssh éste ya viene compilado con el protocolo 2, (ya que el 1 esta en desuso y tiene varias vulnerabilidades importantes), no está de mas comprobarlo

Protocol 2

Para llevar más control de lo que pasa en el servidor, ataques, logueos, ... podemos aumentar el nivel de log del servidor. Las opciones superiores a la INFO (casi siempre por defecto) son DEBUG (este nivel es muy completo pero vulnera la intimidad de los usuarios), DEBUG2, DEBUG3 y VERBOSE (es cuestión de probar y ver cual nos es mas útil)¹.

LogLevel DEBUGx

Reducir el tiempo del que disponemos para logarnos en el servidor, el que estiméis suficiente para dicho fin en segundos

LoginGraceTime xx

Otra buena opción es evitar que el usuario root pueda logarse. Yo personalmente siempre evito los nombres de usuario tipo nombre propio o algo sencillo de adivinar ya que casi todo el mundo toma medidas con su contraseña pero olvidamos que el usuario es la mitad de la llave y root siempre existe.

PermitRootLogin no

Nos aseguramos que los archivos del directorio home de los usuarios como claves, ... no tengan permisos de escritura para cualquiera antes de aceptar el login

StrictModes yes

Evitamos la aceptación de ficheros rhost, shost y que los ususarios puedan entrar sin contraseña

IgnoreRhosts yes

Esta es bastante obvia, no permitir los passwords vacios

PermitEmptyPasswords no

Si no tienes previsto permitir la ejecución de aplicaciones del servidor de las X a través de ssh puedes restringirlo

X11Forwarding no

Reduciremos también el número de intentos para logarnos. Y asi conseguimos quitarnos de encima algunos scripts que intentan entrar por fuerza bruta

MaxAuthTries 2

Aunque lo podemos hacer creando un grupo de usuarios y permitir a este grupo el uso de ssh, tenemos también la opción de restringir su uso por aquí, simplemente al usuario o al usuario desde una ip en concreto. Con esta opción solo podrán usar el servidor los usuarios indicados

AllowUsers fulano mengano@xxx.xxx.xxx.xxx

También tenemos denegar usuario, permitir grupo y denegar grupo para apoyar las restricciones por si quisieras indicarlas de esta manera

DenyUsers fulano
DenyGroups fulanos
AllowGroups menganos

Como este articulo se esta haciendo muy largo lo divido y dejo para próximos los siguientes puntos:
- Crear par de claves rsa
- SPA: Single Packet Authentication
-¹Separar el log de Ssh