#Protezione del Nodo

L'obiettivo di questa guida è di accompagnarti attraverso i passaggi che puoi intraprendere per proteggere il tuo nodo da attori malintenzionati. Che tu stia gestendo un server locale a casa o un server VPS / macchina virtuale nel cloud, i suggerimenti qui ti aiuteranno a rafforzare il tuo nodo contro gli attacchi esterni e a proteggerlo durante la sua vita operativa.

Questa sezione descriverà sia azioni essenziali, che devi intraprendere, sia azioni utili ma non obbligatorie, che sono d'aiuto ma non richieste.

#Presupposti in Questa Guida

Questa guida presuppone che il tuo nodo esegua Ubuntu 20.04 LTS. I concetti si applicheranno anche ad altri sistemi ma i comandi di esempio potrebbero non funzionare.

Come per tutti i comandi in questa guida, presumiamo che tu ti stia connettendo da remoto al terminale a riga di comando del tuo nodo usando ssh. Se hai bisogno di un ripasso su come usare ssh, dai un'occhiata prima alla guida Introduzione a Secure Shell.

#ESSENZIALE: Mantieni Sicura la Tua Macchina Client

La maggior parte degli operatori Smartnode interagisce con il proprio nodo da remoto connettendosi al suo terminale da un altro computer usando ssh:

• La macchina a cui ti connetti (in questo caso, la tua macchina nodo) è chiamata server.
• La macchina da cui ti connetti (come il tuo laptop, desktop, o anche il tuo telefono) è il client.

Una delle cose più importanti che puoi fare per proteggere il tuo Smartnode è mantenere sicura la tua macchina client. Se la tua macchina client è compromessa e la usi per accedere al tuo nodo, allora la maggior parte delle impostazioni di sicurezza che applichi al nodo possono essere bypassate.

Per esempio: se usi un laptop come client SSH, e ha un keylogger installato, allora qualsiasi cosa segreta che digiti sul nodo (come la tua password o il mnemonic di recupero) quando connesso tramite SSH verrà rubata.

Non esiste una guida definitiva per mantenere sicura la tua macchina client, ma essere consapevole che è un fattore nella tua sicurezza è un buon primo passo. Assicurati che la tua macchina client sia il più sicura possibile.

Ecco alcuni suggerimenti:

• Non usare la tua macchina client per attività rischiose (come visitare siti web non affidabili o installare programmi non necessari)
• Mantieni la tua macchina client aggiornata con le ultime patch di sicurezza
• Se possibile, usa un programma di protezione da malware e antivirus per il tuo sistema operativo

Per la massima sicurezza, potresti voler usare una macchina dedicata come client SSH, anche se questo potrebbe non essere pratico per te.

#ESSENZIALE: Proteggi il Tuo Accesso SSH

Che tu gestisca il tuo Smartnode a casa o usi un VPS in un datacenter remoto, è probabile che tu vi acceda tramite SSH, o che SSH sia abilitato anche se non lo usi.

Le connessioni SSH si basano su crittografia sicura, ma come con ogni sistema sicuro, la vera sicurezza deriva dall'usarlo correttamente. Ci sono due cose principali da fare per le tue impostazioni SSH:

1. Usare una chiave SSH per accedere da remoto invece di un nome utente e password
2. Disabilitare completamente l'autenticazione basata su password, in modo che le chiavi SSH siano l'unica opzione di login remoto

Come probabilmente sai ormai, il modo predefinito per accedere al tuo nodo tramite SSH è con un nome utente e una password. Lo svantaggio è che la tua password è tipicamente qualcosa di piuttosto "corto" e suscettibile ad attacchi brute-force.

Fortunatamente, c'è un modo alternativo per accedere tramite SSH: una coppia di chiavi SSH.

Le coppie di chiavi SSH funzionano in modo simile ai wallet blockchain; vengono con una parte pubblica (come il tuo indirizzo wallet) e una parte privata (la chiave privata per il tuo indirizzo wallet):

• Fornisci la parte pubblica al tuo nodo. In questo modo, il nodo sa che sei autorizzato a connetterti, e sa che sei davvero tu che stai cercando di connetterti.
• Tieni la parte privata per te sulla tua macchina client. In questo modo, tu (e solo tu) puoi connetterti al tuo nodo.
  • Puoi (e dovresti!) proteggere la parte privata con una password, così qualcuno che ruba la tua chiave non può usarla.
• Dal punto di vista di un computer, la chiave privata è esponenzialmente più difficile da craccare rispetto a una password. Questo mitiga il rischio di un attacco brute-force contro il tuo nodo.

#Creazione di una Coppia di Chiavi SSH

Iniziamo creando una nuova coppia di chiavi SSH sulla tua macchina client. Ci sono molte varietà di chiavi disponibili, ma useremo un tipo di chiave chiamato ed25519 che fornisce un'eccellente sicurezza.

Esegui il seguente comando sulla tua macchina client (cioè, non dovresti eseguirlo mentre sei già connesso tramite SSH alla tua macchina nodo - se lo sei, esci prima da SSH):

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

Vedrai quanto segue:

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

Questo ti chiede dove vorresti salvare il tuo file di chiave privata. SSH è compatibile con il percorso predefinito fornito e lo userà automaticamente per te se lo selezioni. Tuttavia, hai l'opzione di cambiarlo in qualcos'altro se lo desideri.

Se ti senti a tuo agio con l'impostazione predefinita, premi semplicemente Enter.

Altrimenti, digita la tua posizione desiderata per la chiave. Deve essere un percorso assoluto (ad es. /home/username/.ssh/rocketpool_key su Linux, o /Users/username/.ssh/rocketpool_key su OSX). Premi Enter quando hai finito.

Dopo aver premuto Enter, vedrai:

Enter passphrase (empty for no passphrase):

Questa diventerà la password per la chiave privata stessa. Ogni volta che usi la chiave per connetterti al tuo nodo, dovrai prima inserire questa password.

Una volta finito di digitare la password, premi Enter. Ti chiederà di riscriverla per conferma.

Dopo di che, vedrai un output simile al seguente:

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 prima riga indica la posizione della chiave privata, che è chiamata id_ed25519 per impostazione predefinita (nota che non ha un'estensione di file). Ubuntu caricherà questa chiave per te automaticamente quando usi ssh se questo file di chiave privata si trova nella posizione predefinita.

La seconda riga indica la posizione della chiave pubblica, che è chiamata id_ed25519.pub per impostazione predefinita. Avremo bisogno della chiave pubblica per il prossimo passaggio.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

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

#Aggiunta della Chiave Pubblica al Tuo Nodo

Una volta che hai la tua coppia di chiavi SSH, puoi ora aggiungere la chiave pubblica al tuo nodo. Questo ti permetterà di connetterti tramite ssh usando la chiave privata che hai appena generato, invece del tuo nome utente e password.

Ci sono due modi per farlo - se uno non funziona, prova l'altro modo:

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

Ora dovresti essere in grado di connetterti al nodo tramite ssh come faresti normalmente, ma ora non dovrai digitare la password dell'account utente.

Invece, dovrai digitare la password della tua chiave privata SSH. A seconda delle impostazioni del tuo sistema, potresti dover farlo solo una volta per riavvio, o potresti doverlo fare ogni volta che usi la chiave per connetterti al tuo nodo.

#Disabilitare l'Accesso via Password

Anche se hai una coppia di chiavi SSH configurata, il tuo nodo permetterà comunque ad altre macchine di provare ad accedere usando il metodo nome utente e password. Questo vanifica l'intero scopo dell'uso delle chiavi SSH, quindi il prossimo passaggio è disabilitarle.

Inizia accedendo alla tua macchina usando ssh come al solito:

ssh user@your.node.ip.address

Come promemoria, dovresti farlo due volte su due terminali separati così hai una sessione di backup nel caso. Puoi ignorare la sessione di backup per ora - ti diremo quando ne avrai bisogno. Esegui i seguenti comandi solo nella prima sessione.

Apri il file di configurazione per il server SSH:

sudo nano /etc/ssh/sshd_config

Come per tutti i comandi che iniziano con sudo, questo ti chiederà la password del tuo account utente. Questo è un file grande, quindi dovrai navigare attraverso di esso usando i tasti freccia sulla tua tastiera o Page Up / Page Down.

Apporta le seguenti modifiche:

1. Decommenta #AuthorizedKeysFile se è commentato (rimuovendo il # davanti ad esso)
2. Cambia KbdInteractiveAuthentication yes in KbdInteractiveAuthentication no e decommenta (rimuovendo il # davanti ad esso) - nota che le versioni più vecchie di SSH chiamano questa opzione ChallengeResponseAuthentication invece di KbdInteractiveAuthentication
3. Cambia PasswordAuthentication yes in PasswordAuthentication no e decommenta (rimuovendo il # davanti ad esso)
4. Cambia PermitRootLogin yes in PermitRootLogin prohibit-password a meno che non sia già impostato così e abbia un # davanti ad esso

Una volta finito, salva con Ctrl+O e Enter, poi esci con Ctrl+X.

Infine, esegui sudo sshd -T | grep -i passwordauthentication e assicurati che stampi passwordauthentication no. Se non lo fa, potresti dover eseguire sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf e impostare PasswordAuthentication yes su PasswordAuthentication no anche in quel file. Salva ed esci come prima, con Ctrl+O e Enter, poi Ctrl+X

Successivamente, riavvia il server SSH così acquisisce le nuove impostazioni:

sudo systemctl restart ssh.service

Dopo questo, l'accesso a SSH tramite nome utente e password dovrebbe essere disabilitato.

#(Opzionale) Abilitare l'Autenticazione a Due Fattori

L'autenticazione a due fattori implica richiedere una seconda misura di sicurezza oltre alla tua password o chiave SSH, di solito su un dispositivo separato da quello principale.

Per esempio, potresti avere familiarità con l'accesso a un sito web come un exchange crypto usando sia una password che un codice Google Authenticator (o un codice SMS). Questo processo in due passaggi è un esempio di autenticazione a due fattori.

SSH può anche essere configurato per richiedere un codice Google Authenticator, il che significa che un attaccante che in qualche modo ha compromesso la tua chiave SSH e la sua passphrase avrebbe ancora bisogno del dispositivo con l'app authenticator (presumibilmente il tuo telefono). Questo aggiunge un ulteriore livello di sicurezza al tuo sistema.

Inizia installando Google Authenticator (o un equivalente compatibile) sul tuo telefono se non ce l'hai già. Per gli utenti Android, considera andOTP che è un'alternativa open-source che supporta il blocco con password e comodi backup.

Successivamente, installa il modulo Google Authenticator sul tuo nodo con questo comando:

sudo apt install -y libpam-google-authenticator

Ora di' al PAM (pluggable authentication modules) di usare questo modulo. Prima, apri il file di configurazione:

sudo nano /etc/pam.d/sshd

Trova @include common-auth (dovrebbe essere in alto) e commentalo aggiungendo un # davanti ad esso, così appare così:

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

Successivamente, aggiungi queste righe all'inizio del file:

# Enable Google Authenticator
auth required pam_google_authenticator.so

Poi salva ed esci dal file con Ctrl+O, Enter, e Ctrl+X.

Ora che PAM sa di usare Google Authenticator, il prossimo passaggio è dire a sshd di usare PAM. Apri il file di configurazione sshd:

sudo nano /etc/ssh/sshd_config

Ora cambia la riga KbdInteractiveAuthentication no in KbdInteractiveAuthentication yes così appare così:

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

(Le versioni più vecchie di SSH chiamano questa opzione ChallengeResponseAuthentication invece di KbdInteractiveAuthentication.)

Aggiungi la seguente riga alla fine del file, che indica a sshd che ha bisogno sia di una chiave SSH che del codice Google Authenticator:

AuthenticationMethods publickey,keyboard-interactive:pam

Poi salva ed esci dal file con Ctrl+O, Enter, e Ctrl+X.

Ora che sshd è configurato, dobbiamo creare i nostri codici 2FA. Nel tuo terminale, esegui:

google-authenticator

Prima, ti chiederà dei token basati sul tempo. Rispondi y a questa domanda:

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

Ora vedrai un grande codice QR sul tuo schermo; scansionalo con la tua app Google Authenticator per aggiungerlo. Vedrai anche il tuo segreto e alcuni codici di backup simili a questo:

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

Infine, ti chiederà altri parametri; i valori predefiniti raccomandati sono i seguenti:

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 volta finito, riavvia sshd così acquisisce le nuove impostazioni:

sudo systemctl restart sshd

Quando provi a connetterti tramite SSH al tuo server con le tue chiavi SSH, ora dovresti anche essere richiesto di un codice di verifica 2FA, ma non di una password.

#ESSENZIALE: Abilitare gli Aggiornamenti di Sicurezza Automatici

I fornitori di sistemi operativi pubblicano routinariamente aggiornamenti e correzioni di sicurezza, quindi è importante che tu mantenga il tuo sistema aggiornato con le ultime patch. Il modo più semplice per farlo è abilitare gli aggiornamenti automatici.

Esegui i seguenti comandi sulla tua macchina nodo:

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

Puoi modificare le impostazioni di aggiornamento automatico modificando /etc/apt/apt.conf.d/20auto-upgrades:

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

Questo è un esempio di impostazioni di aggiornamento automatico ragionevoli:

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";

Quando hai finito di aggiungere le tue modifiche, salva con Ctrl+O e Enter, poi esci con Ctrl+X.

Dopo, assicurati di caricare le nuove impostazioni:

sudo systemctl restart unattended-upgrades

#ESSENZIALE: Abilitare un Firewall

In generale, la tua macchina dovrebbe accettare solo traffico di rete sulle porte che il tuo client Execution, client Consensus e stack Smartnode usano. Per imporre questo e prevenire qualsiasi traffico inaspettato o indesiderato, possiamo installare un firewall sul nodo.

Ubuntu viene con ufw installato per impostazione predefinita (il firewall uncomplicated fire wall), che è un'utilità conveniente per gestire le impostazioni del firewall del tuo nodo.

I seguenti comandi configureranno ufw con una buona configurazione predefinita per il tuo Smartnode. Esegui questi sulla tua macchina nodo.

Disabilita le connessioni a meno che non siano esplicitamente permesse da regole successive:

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

Permetti SSH:

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

Permetti il client execution (precedentemente chiamato 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'

Permetti il client consensus (precedentemente chiamato 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'

Se esegui lighthouse client v4.5.0+, puoi usare il protocollo quic per ridurre la latenza / aumentare la larghezza di banda, il protocollo quic usa la --port di lighthouse + 1 per ascoltare i messaggi quic per impostazione predefinita: https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

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

Infine, abilita ufw:

sudo ufw enable

#(Opzionale) Abilitare la Protezione da Attacchi Brute-Force e DDoS

Per proteggere il tuo server da attacchi DDoS e tentativi di connessione brute-force, puoi installare fail2ban. Questo programma monitorerà le connessioni in entrata e bloccherà gli indirizzi IP che provano ripetutamente ad accedere con credenziali errate.

Vedi questa guida per ulteriori informazioni sulla prevenzione delle intrusioni.

Esegui i seguenti comandi sulla tua macchina nodo:

Installa il servizio:

sudo apt install -y fail2ban

Successivamente, apri /etc/fail2ban/jail.d/ssh.local:

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

Aggiungi il seguente contenuto:

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

Puoi modificare l'impostazione maxretry, che è il numero di tentativi che permetterà prima di bloccare l'indirizzo incriminato.

Una volta finito, salva ed esci con Ctrl+O e Enter, poi Ctrl+X.

Infine, riavvia il servizio:

sudo systemctl restart fail2ban

E con questo, hai appena migliorato notevolmente la postura di sicurezza del tuo nodo. Congratulazioni!