#Asegurar tu Nodo

El objetivo de esta guía es guiarte a través de pasos que puedes tomar para asegurar tu nodo contra actores maliciosos. Ya sea que estés ejecutando un servidor local en casa o un servidor VPS / máquina virtual en la nube, los consejos aquí te ayudarán a fortalecer tu nodo contra ataques externos y ayudar a protegerlo durante su vida útil.

Esta sección describirá tanto acciones esenciales, que debes tomar, como acciones convenientes, que son útiles pero no requeridas.

#Suposiciones en Esta Guía

Esta guía asume que tu nodo ejecuta Ubuntu 20.04 LTS. Los conceptos se aplicarán a otros sistemas pero los comandos de ejemplo pueden no hacerlo.

Como con todos los comandos en esta guía, asumimos que te estás conectando remotamente a la terminal de comandos de tu nodo usando ssh. Si necesitas un repaso sobre cómo usar ssh, echa un vistazo primero a la guía Introducción a Secure Shell.

#ESENCIAL: Mantén Segura tu Máquina Cliente

La mayoría de los operadores de Smartnode interactúan con su nodo remotamente conectándose a su terminal desde otra computadora usando ssh:

• La máquina a la que te conectas (en este caso, tu máquina de nodo) se llama el servidor.
• La máquina desde la que te conectas (como tu laptop, escritorio, o incluso tu teléfono) es el cliente.

Una de las cosas más importantes que puedes hacer para asegurar tu Smartnode es mantener segura tu máquina cliente. Si tu máquina cliente está comprometida y la usas para iniciar sesión en tu nodo, entonces la mayoría de las configuraciones de seguridad que apliques al nodo pueden ser evitadas.

Por ejemplo: si usas una laptop como cliente SSH, y tiene un keylogger instalado, entonces cualquier cosa secreta que escribas en el nodo (como tu contraseña o mnemónico de recuperación) cuando estés conectado vía SSH será robada.

No existe una guía definitiva para mantener segura tu máquina cliente, pero estar consciente de que es un factor en tu seguridad es un buen primer paso. Asegúrate de que tu máquina cliente sea tan segura como pueda ser.

Aquí hay algunos consejos:

• No uses tu máquina cliente para actividades riesgosas (como visitar sitios web no confiables o instalar programas innecesarios)
• Mantén tu máquina cliente actualizada con los últimos parches de seguridad
• Si es posible, usa un programa de protección contra malware y antivirus para tu Sistema Operativo

Para máxima seguridad, podrías querer usar una máquina dedicada como tu cliente SSH, aunque esto puede no ser práctico para ti.

#ESENCIAL: Asegura tu Acceso SSH

Ya sea que ejecutes tu Smartnode en casa o uses un VPS en un datacenter remoto, es probable que o bien accedas a él a través de SSH, o que SSH esté habilitado incluso si no lo usas.

Las conexiones SSH se basan en criptografía segura, pero como con cualquier sistema seguro, la seguridad real proviene de usarlo correctamente. Hay dos cosas principales que hacer para tus configuraciones de SSH:

1. Usar una clave SSH para iniciar sesión remotamente en lugar de un nombre de usuario y contraseña
2. Deshabilitar completamente la autenticación basada en contraseña, para que las claves SSH sean la única opción de inicio de sesión remoto

Como probablemente estés familiarizado ahora, la forma predeterminada de iniciar sesión en tu nodo vía SSH es con un nombre de usuario y contraseña. La desventaja de esto es que tu contraseña es típicamente algo bastante "corto" y susceptible a ataques de fuerza bruta.

Afortunadamente, existe una forma alternativa de iniciar sesión vía SSH: un par de claves SSH.

Los pares de claves SSH funcionan de manera similar a las wallets de blockchain; vienen con una parte pública (como la dirección de tu wallet) y una parte privada (la clave privada para la dirección de tu wallet):

• Proporcionas la parte pública a tu nodo. De esta manera, el nodo sabe que tienes permitido conectarte a él, y sabe que realmente eres tú intentando conectarte.
• Mantienes la parte privada para ti en tu máquina cliente. De esta manera, tú (y solo tú) puedes conectarte a tu nodo.
  • Puedes (¡y debes!) proteger la parte privada con una contraseña, para que alguien que robe tu clave no pueda usarla.
• Desde la perspectiva de una computadora, la clave privada es exponencialmente más difícil de descifrar que una contraseña. Esto mitiga el riesgo de un ataque de fuerza bruta contra tu nodo.

#Crear un Par de Claves SSH

Comencemos creando un nuevo par de claves SSH en tu máquina cliente. Hay muchas variedades de claves disponibles, pero vamos a usar un tipo de clave llamado ed25519 que proporciona excelente seguridad.

Ejecuta el siguiente comando en tu máquina cliente (es decir, no debes ejecutar esto mientras ya estés conectado vía SSH a tu máquina de nodo - si lo estás, sal de SSH primero):

ssh-keygen -t ed25519 -C "your_email@example.com"

Verás lo siguiente:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519):

Esto te pregunta dónde te gustaría guardar tu archivo de clave privada. SSH es compatible con el valor predeterminado proporcionado y lo usará automáticamente si lo seleccionas. Sin embargo, tienes la opción de cambiarlo a algo más si lo deseas.

Si te sientes cómodo con la configuración predeterminada, simplemente presiona Enter.

De lo contrario, escribe la ubicación deseada para la clave. Debe ser una ruta absoluta (ej. /home/username/.ssh/rocketpool_key en Linux, o /Users/username/.ssh/rocketpool_key en OSX). Presiona Enter cuando hayas terminado.

Después de presionar Enter, verás:

Enter passphrase (empty for no passphrase):

Esto se convertirá en la contraseña para la clave privada en sí. Siempre que uses la clave para conectarte a tu nodo, necesitarás ingresar esta contraseña primero.

Una vez que termines de escribir la contraseña, presiona Enter. Te pedirá que la vuelvas a escribir para confirmar.

Después de eso, verás algo como la siguiente salida:

Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:CASbPZETiQ83lLhpUO2aoT05TxMVLwqiWtdsRtoPt4s your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
| .o*==..         |
|. +=O...         |
|..+B++o .        |
|..=.+X o         |
|.+.=+.O S        |
|o.B.oo + .       |
|.  = .  o        |
|    .  . .       |
|      E .        |
+----[SHA256]-----+

La primera línea indica la ubicación de la clave privada, que se llama id_ed25519 por defecto (nota que no tiene una extensión de archivo). Ubuntu cargará esta clave automáticamente cuando uses ssh si este archivo de clave privada está en la ubicación predeterminada.

La segunda línea indica la ubicación de la clave pública, que se llama id_ed25519.pub por defecto. Necesitaremos la clave pública para el siguiente paso.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

alias loadkey='ssh-add $HOME/.ssh/id_ed25519'

#Agregar la Clave Pública a tu Nodo

Una vez que tengas tu par de claves SSH, ahora puedes agregar la clave pública a tu nodo. Esto te permitirá conectarte a él mediante ssh usando la clave privada que acabas de generar, en lugar de tu nombre de usuario y contraseña.

Hay dos formas de hacer esto - si una no funciona, prueba la otra:

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub username@node.ip.address

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub staker@192.168.1.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine with:   "ssh 'username@node.ip.address'"
and check to make sure that only the key(s) you wanted were added.

cat ~/.ssh/id_ed25519.pub

type %USERPROFILE%\.ssh\id_ed25519.pub

type $ENV:UserProfile\.ssh\id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGUgU3a6mNjy3N1TyWOwY+VA/nifAeABl2Ch2yIl1bGa your_email@example.com

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

Ahora deberías poder hacer ssh al nodo como lo harías normalmente, pero ahora no tendrás que escribir la contraseña de la cuenta de usuario.

En su lugar, tendrás que escribir la contraseña de tu clave privada SSH. Dependiendo de la configuración de tu sistema, es posible que solo tengas que hacer esto una vez por reinicio, o que tengas que hacerlo cada vez que uses la clave para conectarte a tu nodo.

#Deshabilitar Inicio de Sesión vía Contraseña

Aunque tengas un par de claves SSH configurado, tu nodo todavía permitirá que otras máquinas intenten iniciar sesión usando el método de nombre de usuario y contraseña. Esto derrota todo el propósito de usar claves SSH en primer lugar, por lo que el siguiente paso es deshabilitar esas.

Comienza iniciando sesión en tu máquina usando ssh como de costumbre:

ssh user@your.node.ip.address

Como recordatorio, debes hacer esto dos veces en dos terminales separadas para que tengas una sesión de respaldo por si acaso. Puedes ignorar la sesión de respaldo por ahora - te diremos cuándo la necesitas. Ejecuta los siguientes comandos solo en la primera sesión.

Abre el archivo de configuración para el servidor SSH:

sudo nano /etc/ssh/sshd_config

Como con todos los comandos que comienzan con sudo, esto te pedirá la contraseña de tu cuenta de usuario. Este es un archivo grande, por lo que tendrás que navegar a través de él usando las teclas de flecha en tu teclado o Page Up / Page Down.

Realiza los siguientes cambios:

1. Descomenta #AuthorizedKeysFile si está comentado (eliminando el # delante de él)
2. Cambia KbdInteractiveAuthentication yes a KbdInteractiveAuthentication no y descomenta (eliminando el # delante de él) - nota que versiones anteriores de SSH llaman a esta opción ChallengeResponseAuthentication en lugar de KbdInteractiveAuthentication
3. Cambia PasswordAuthentication yes a PasswordAuthentication no y descomenta (eliminando el # delante de él)
4. Cambia PermitRootLogin yes a PermitRootLogin prohibit-password a menos que ya esté configurado así y tenga un # delante

Una vez que hayas terminado, guarda con Ctrl+O y Enter, luego sal con Ctrl+X.

Finalmente, ejecuta sudo sshd -T | grep -i passwordauthentication y asegúrate de que imprima passwordauthentication no. Si no lo hace, es posible que necesites ejecutar sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf y cambiar PasswordAuthentication yes a PasswordAuthentication no en ese archivo también. Guarda y sal como antes, con Ctrl+O y Enter, luego Ctrl+X

Luego, reinicia el servidor SSH para que tome la nueva configuración:

sudo systemctl restart ssh.service

Después de esto, iniciar sesión en SSH vía nombre de usuario y contraseña debería estar deshabilitado.

#(Opcional) Habilitar Autenticación de Dos Factores

La autenticación de dos factores implica requerir una segunda medida de seguridad además de tu contraseña o clave SSH, usualmente en un dispositivo separado de tu principal.

Por ejemplo, puedes estar familiarizado con iniciar sesión en un sitio web como un exchange de criptomonedas usando tanto una contraseña como un código de Google Authenticator (o un código SMS). Este proceso de dos pasos es un ejemplo de autenticación de dos factores.

SSH también puede ser configurado para requerir un código de Google Authenticator, lo que significa que un atacante que de alguna manera comprometiera tu clave SSH y su contraseña todavía necesitaría el dispositivo con la app de autenticación (presumiblemente tu teléfono). Esto agrega una capa extra de seguridad a tu sistema.

Comienza instalando Google Authenticator (o un equivalente compatible) en tu teléfono si aún no lo tienes. Para usuarios de Android, considera andOTP que es una alternativa de código abierto que soporta bloqueo con contraseña y respaldos convenientes.

Luego, instala el módulo de Google Authenticator en tu nodo con este comando:

sudo apt install -y libpam-google-authenticator

Ahora indica a PAM (pluggable authentication modules) que use este módulo. Primero, abre el archivo de configuración:

sudo nano /etc/pam.d/sshd

Encuentra @include common-auth (debería estar en la parte superior) y coméntalo agregando un # delante de él, para que se vea así:

# Standard Un*x authentication.
#@include common-auth

Luego, agrega estas líneas en la parte superior del archivo:

# Enable Google Authenticator
auth required pam_google_authenticator.so

Luego guarda y sal del archivo con Ctrl+O, Enter, y Ctrl+X.

Ahora que PAM sabe usar Google Authenticator, el siguiente paso es decirle a sshd que use PAM. Abre el archivo de configuración de sshd:

sudo nano /etc/ssh/sshd_config

Ahora cambia la línea KbdInteractiveAuthentication no a KbdInteractiveAuthentication yes para que se vea así:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication yes

(Las versiones anteriores de SSH llaman a esta opción ChallengeResponseAuthentication en lugar de KbdInteractiveAuthentication.)

Agrega la siguiente línea al final del archivo, que indica a sshd que necesita tanto una clave SSH como el código de Google Authenticator:

AuthenticationMethods publickey,keyboard-interactive:pam

Luego guarda y sal del archivo con Ctrl+O, Enter, y Ctrl+X.

Ahora que sshd está configurado, necesitamos crear nuestros códigos 2FA. En tu terminal, ejecuta:

google-authenticator

Primero, te preguntará sobre tokens basados en tiempo. Di y a esta pregunta:

Do you want authentication tokens to be time-based: y

Ahora verás un gran código QR en tu pantalla; escanéalo con tu app de Google Authenticator para agregarlo. También verás tu secreto y algunos códigos de respaldo que se ven así:

Your new secret key is: IRG2TALMR5U2LK5VQ5AQIG3HA4
Your verification code is 282436
Your emergency scratch codes are:
  29778030
  86888537
  50553659
  41403052
  82649596

Finalmente, te preguntará por algunos parámetros más; los valores predeterminados recomendados son los siguientes:

Do you want me to update your "/<username>/.google_authenticator" file: y
Do you want to disallow multiple uses of the same authentication token: y
By default... < long story about time skew > ... Do you want to do so: n
Do you want to enable rate-limiting: y

Una vez que hayas terminado, reinicia sshd para que tome la nueva configuración:

sudo systemctl restart sshd

Cuando intentes hacer SSH a tu servidor con tus claves SSH, ahora también se te debería pedir un código de verificación 2FA, pero no una contraseña.

#ESENCIAL: Habilitar Actualizaciones de Seguridad Automáticas

Los proveedores de Sistemas Operativos publican rutinariamente actualizaciones y correcciones de seguridad, por lo que es importante que mantengas tu sistema actualizado con los últimos parches. La forma más fácil de hacer esto es habilitar las actualizaciones automáticas.

Ejecuta los siguientes comandos en tu máquina de nodo:

sudo apt update
sudo apt install -y unattended-upgrades update-notifier-common

Puedes cambiar la configuración de actualizaciones automáticas editando /etc/apt/apt.conf.d/20auto-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Este es un ejemplo de configuración razonable de actualizaciones automáticas:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

# This is the most important choice: auto-reboot.
# This should be fine since Rocketpool auto-starts on reboot.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Cuando hayas terminado de agregar tus cambios, guarda con Ctrl+O y Enter, luego sal con Ctrl+X.

Después, asegúrate de cargar la nueva configuración:

sudo systemctl restart unattended-upgrades

#ESENCIAL: Habilitar un Firewall

En general, tu máquina solo debería aceptar tráfico de red en puertos que tu cliente de Ejecución, cliente de Consenso y stack de Smartnode usen. Para hacer cumplir eso y prevenir cualquier tráfico inesperado o indeseable, podemos instalar un firewall en el nodo.

Ubuntu viene con ufw instalado por defecto (el firewall uncomplicated fire wall), que es una utilidad conveniente para administrar la configuración de firewall de tu nodo.

Los siguientes comandos configurarán ufw con una buena configuración predeterminada para tu Smartnode. Ejecuta estos en tu máquina de nodo.

Deshabilita las conexiones a menos que estén explícitamente permitidas por reglas posteriores:

sudo ufw default deny incoming comment 'Deny all incoming traffic'

Permite SSH:

sudo ufw allow "22/tcp" comment 'Allow SSH'

Permite el cliente de ejecución (antes llamado ETH1):

sudo ufw allow 30303/tcp comment 'Execution client port, standardized by Rocket Pool'
sudo ufw allow 30303/udp comment 'Execution client port, standardized by Rocket Pool'

Permite el cliente de consenso (antes llamado ETH2):

sudo ufw allow 9001/tcp comment 'Consensus client port, standardized by Rocket Pool'
sudo ufw allow 9001/udp comment 'Consensus client port, standardized by Rocket Pool'

Si ejecutas el cliente lighthouse v4.5.0+, puedes usar el protocolo quic para reducir latencia / aumentar ancho de banda, el protocolo quic usa --port + 1 de lighthouse para escuchar mensajes quic por defecto: https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

sudo ufw allow 8001/udp comment 'Consensus client port, standardised by Rocket Pool'

Finalmente, habilita ufw:

sudo ufw enable

#(Opcional) Habilitar Protección contra Fuerza Bruta y DDoS

Para proteger tu servidor contra ataques DDoS e intentos de conexión por fuerza bruta, puedes instalar fail2ban. Este programa monitoreará las conexiones entrantes y bloqueará direcciones IP que intenten iniciar sesión con credenciales defectuosas repetidamente.

Consulta esta guía para más información sobre prevención de intrusiones.

Ejecuta los siguientes comandos en tu máquina de nodo:

Instala el servicio:

sudo apt install -y fail2ban

Luego, abre /etc/fail2ban/jail.d/ssh.local:

sudo nano /etc/fail2ban/jail.d/ssh.local

Agrega los siguientes contenidos:

[sshd]
enabled = true
banaction = ufw
port = 22
filter = sshd
logpath = %(sshd_log)s
maxretry = 5

Puedes cambiar la configuración maxretry, que es el número de intentos que permitirá antes de bloquear la dirección infractora.

Una vez que hayas terminado, guarda y sal con Ctrl+O y Enter, luego Ctrl+X.

Finalmente, reinicia el servicio:

sudo systemctl restart fail2ban

Y con eso, acabas de mejorar enormemente la postura de seguridad de tu nodo. ¡Felicidades!