Menu

<embrolio/>

Seguridad para conexión SSH

La manera más usual para conectarnos a un servidor Linux es usando ssh. Esto lo sabemos nosotros y también algún usuario malicioso. De hecho cuando recibo el email de logwatch encuentro cosas como esta:

sshd:
    Authentication Failures:
       root (58.218.198.151): 5245 Time(s)
       root (116.31.116.28): 2060 Time(s)
       root (59.45.175.67): 360 Time(s)
       root (59.45.175.62): 274 Time(s)
       root (221.194.47.252): 237 Time(s)
       root (121.18.238.123): 226 Time(s)
       root (121.18.238.119): 192 Time(s)
       root (59.45.175.56): 186 Time(s)
       root (221.194.44.240): 153 Time(s)
       root (59.45.175.88): 141 Time(s)
       root (59.45.175.66): 135 Time(s)

Como ven, muchos intentos de ingresar al server, por lo que siempre es mejor agregarle una capa extra de seguridad a nuestro acceso.

Asegurando el servidor

Vamos a hacer 3 cosas básicas para que nuestro server quede un poco más seguro:

Deshabilitar el acceso del usuario root por ssh

Lo primero que tenemos que hacer para no quedarnos afuera de nuestro propio server es crear un usuario y darle permisos de sudo:

Nos logueamos como root a nuestro nuevo server y agregamos un usuario:

ssh root@ip_del_server

adduser usuario

Nos va a pedir password y varios datos del nuevo usuario. Recuerden usar una password que sea segura, los demás datos son opcionales.

El siguiente paso es agregar al usuario al grupo de sudoers, lo hacemos con el siguiente comando:

usermod -aG sudo usuario

En este punto ya deberiamos poder ejecutar comandos sudo con el usuario, para comprobarlo nos cambiamos a su cuenta y hacemos un test cualquiera (por ejemplo un ls de la carpeta /root, normalmente solo accesible al usuario root):

su - usuario
usuario$ sudo ls -la /root

Una vez confirmado esto, nos deslogueamos y nos logueamos con el nuevo usuario y vamos a modificar el archivo /etc/ssh/sshd_config (usando sudo, ya que este archivo solo es modificable por el root):

PermitRootLogin no

Guardamos y reiniciamos el ssh daemon:

sudo service ssh restart

Ahora probamos loguearnos nuevamente con el usuario root y no deberíamos poder. Podemos avanzar al siguiente paso.

Deshabilitar el acceso con contraseña

El acceso con contraseña es siempre menos seguro que utilizar nuestra propia clave ssh para acceder al servidor. Vamos a suponer que ya tienen creada la clave SSH en su entorno local, lo que hay que hacer es copiar la clave pública al archivo authorized_keys dentro del home del nuevo usuario en el server. Desde linux la forma más sencilla es usar el comando ssh-copy-id, pero si dicho comando no está disponible podemos hacerlo a mano en 3 simples pasos:

  1. Copiamos el contenido de nuestra clave pública (por default en linux es ~/.ssh/id_rsa.pub)
  2. Nos logueamos al server y abrimos (o creamos) el archivo /home/usuario/.ssh/authorized_keys
  3. Agregamos nuestra clave pública al archivo authorized_keys

Una vez hecho esto, nos deslogueamos y el próximo login no nos debería solicitar password, sino que entramos directamente con nuestra key ssh. Si todo anduvo ok, vamos a modificar nuevamente el archivo /etc/ssh/sshd_config:

PasswordAuthentication no

Guardamos y reiniciamos ssh nuevamente:

sudo service ssh restart

Y listo, en este momento nuestro server está mucho más seguro, al no permitir login de usuario root ni permitir login con passwords.

Solo nos queda el último (y más controversial) punto

Modificar el puerto SSH

La idea es simple: muchos atacantes van a buscar alguna vulnerabilidad en el puerto 22, por lo que al cambiar el puerto evitamos que lleguen siquiera a intentarlo (security by obscurity, te suena?). Hay algunos argumentos a favor (Changing your ssh server’s port from the default: Is it worth it?) y otros en contra (Why putting SSH on another port than 22 is bad idea), pero en caso de que querramos hacerlo, es muy simple: nuevamente editamos /etc/ssh/sshd_config y en la primera linea cambiamos el puerto:

# What ports, IPs and protocols we listen for
Port 22

En lugar de 22 ponemos el puerto que querramos (siempre y cuando lo recordemos, sino nos bloqueamos de nuestro server) y listo. Guardamos, reiniciamos ssh y salimos. Un detalle importante: si el server tiene un firewall, no olvidar permitir conexiones en el nuevo puerto asignado a SSH!

Y eso es todo, con esto tenemos un server mucho más seguro. Y ustedes, que medidas toman para asegurar sus servidores?

Escrito por Mariano el 1 de junio de 2017

Enlace permanente - Categorías: Linux, Hosting - Tags: Seguridad, SSH

« Logwatch para monitorear los logs del servidor - Sistema actualizado con unattended-upgrades »

comments powered by Disqus