Securizando el servidor de Linode

written by uve 16 September 2010

Aprovechando la migración voy a tratar de escribir una serie de artículos acerca de algunos aspectos con los que he tenido que lidiar. Lo primero es preparar el acceso al servidor.

Cuando contratas un "Linode" (LInuxNODE, así es como llaman en Linode a los servidores que alquilan) debemos especificar una contraseña de root. Además, por defecto, el servidor SSH viene preparado para que podamos acceder.

Brevemente voy a hablar de dos aspectos importantes: el tratamiento de usuarios del sistema y la configuración del servidor SSH.

Como imagino que sabréis, no es buena praxis trabajar como root. Para ello, lo primero es crear un usuario con el que trabajaremos. Así que empezamos conectándonos al servidor:

$ ssh root@xxx.xxx.xxx.xxx

donde xxx.xxx.xxx.xxx es la dirección IP de tu Linode. Nos pedirá la contraseña de root y una vez dentro, procederemos a crear la cuenta que usemos habitualmente:

# useradd user -m
# passwd user
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Y seguimos dando permisos al usuario:

# visudo

y añadimos la siguiente línea:

...
# User privilege specification
user     ALL=(ALL) ALL
...

Ya podemos salir del servidor y probar que todo va bien:

# exit
logout
Connection to xxx.xxx.xxx.xxx closed.
$ ssh user@xxx.xxx.xxx.xxx

Una vez que todo está funcionando, lo siguiente es fortalecer SSH mediante una clave pública. De esta forma añadimos un elemento de seguridad extra a nuestra conexión. Es recomendable cambiar la clave pública cada 6 meses o cada año, que nunca se sabe.

Lo siguiente es conectarnos nuevamente al servidor y configurar SSH para limitar el acceso:

$ ssh user@178.79.142.130
$ sudo su
[sudo] password for user:
# nano /etc/ssh/sshd_config

Mi consejo es, que una vez que todas las claves públicas de todos los usuarios estén en el servidor, no se permita autenticación mediante password. Y una cosa muy importante, restringir el acceso de root, que es donde van dirigidos la mayoría de los ataques. Otra buena idea es utilizar un puerto aleatorio en lugar del puerto por defecto. La primera configuración que he utilizado es la siguiente:

...
RSAAuthentication yes
PubkeyAuthentication yes
PermitRootLogin no
PermitEmptyPasswords no
PasswordAuthentication no
...

Ahora es necesario reiniciar el servicio, y todo estará listo.

# service ssh restart
ssh start/running, process 2265
# exit
exit
$ exit
logout
Connection to xxx.xxx.xxx.xxx closed.
$

Podemos probar que todo va bien intentando acceder como root :)

$ ssh root@xxx.xxx.xxx.xxx
Permission denied (publickey).

Tags

La teoría es cuando crees saber algo, pero no funciona.
La práctica es cuando algo funciona, pero no sabes por qué.
Los programadores combinan la teoría y la práctica:
Nada funciona y no saben por qué.