#Protegendo seu Node

O objetivo deste guia é orientá-lo através das etapas que você pode tomar para proteger seu node contra agentes maliciosos. Seja você executando um servidor local em casa ou um servidor VPS / máquina virtual na nuvem, as dicas aqui ajudarão você a fortalecer seu node contra ataques externos e ajudá-lo a protegê-lo durante sua vida útil.

Esta seção descreverá ações essenciais, que você deve tomar, e ações boas de ter, que são úteis, mas não obrigatórias.

#Premissas neste Guia

Este guia assume que seu node executa Ubuntu 20.04 LTS. Os conceitos serão transferidos para outros sistemas, mas os comandos de exemplo podem não funcionar.

Como em todos os comandos neste guia, assumimos que você está se conectando remotamente ao terminal de comando do seu node usando ssh. Se você precisar de uma recapitulação sobre como usar ssh, dê uma olhada primeiro no guia Introdução ao Secure Shell.

#ESSENCIAL: Mantenha sua Máquina Cliente Segura

A maioria dos operadores de Smartnode interage com seu node remotamente conectando-se ao seu terminal de outro computador usando ssh:

• A máquina à qual você se conecta (neste caso, a máquina do seu node) é chamada de servidor.
• A máquina da qual você se conecta (como seu laptop, desktop ou até mesmo seu telefone) é o cliente.

Uma das coisas mais importantes que você pode fazer para proteger seu Smartnode é manter sua máquina cliente segura. Se sua máquina cliente estiver comprometida e você a usar para fazer login no seu node, então a maioria das configurações de segurança que você aplicar ao node poderá ser ignorada.

Por exemplo: se você usar um laptop como cliente SSH e ele tiver um keylogger instalado, então quaisquer coisas secretas que você digitar no node (como sua senha ou mnemônico de recuperação) quando conectado via SSH serão roubadas.

Não há um guia definitivo para manter sua máquina cliente segura, mas estar ciente de que é um fator em sua segurança é um bom primeiro passo. Certifique-se de que sua máquina cliente esteja tão segura quanto possível.

Aqui estão algumas dicas:

• Não use sua máquina cliente para atividades arriscadas (como visitar sites não confiáveis ou instalar programas desnecessários)
• Mantenha sua máquina cliente atualizada com os patches de segurança mais recentes
• Se possível, use um programa de proteção contra malware e antivírus para seu Sistema Operacional

Para máxima segurança, você pode querer usar uma máquina dedicada como seu cliente SSH, embora isso possa não ser prático para você.

#ESSENCIAL: Proteja seu Acesso SSH

Seja você executando seu Smartnode em casa ou usando um VPS em um datacenter remoto, é provável que você acesse através de SSH, ou que o SSH esteja habilitado mesmo que você não o use.

As conexões SSH são baseadas em criptografia segura, mas como em qualquer sistema seguro, a segurança real vem de usá-lo corretamente. Há duas coisas principais a fazer para suas configurações SSH:

1. Use uma chave SSH para fazer login remotamente em vez de um nome de usuário e senha
2. Desabilite completamente a autenticação baseada em senha, para que as chaves SSH sejam a única opção de login remoto

Como você provavelmente está familiarizado agora, a maneira padrão de fazer login no seu node via SSH é com um nome de usuário e senha. A desvantagem disso é que sua senha é tipicamente algo bastante "curto" e suscetível a ataques de força bruta.

Felizmente, há uma maneira alternativa de fazer login via SSH: um par de chaves SSH.

Os pares de chaves SSH funcionam de forma semelhante às carteiras blockchain; eles vêm com uma parte pública (como seu endereço de carteira) e uma parte privada (a chave privada para seu endereço de carteira):

• Você fornece a parte pública ao seu node. Dessa forma, o node sabe que você tem permissão para se conectar a ele e sabe que é realmente você tentando se conectar.
• Você mantém a parte privada consigo na sua máquina cliente. Dessa forma, você (e somente você) pode se conectar ao seu node.
  • Você pode (e deve!) proteger a parte privada com uma senha, para que alguém que roube sua chave não possa usá-la.
• Do ponto de vista de um computador, a chave privada é exponencialmente mais difícil de quebrar do que uma senha. Isso mitiga o risco de um ataque de força bruta contra seu node.

#Criando um Par de Chaves SSH

Vamos começar criando um novo par de chaves SSH na sua máquina cliente. Existem muitas variedades de chaves por aí, mas vamos usar um tipo de chave chamado ed25519 que fornece excelente segurança.

Execute o seguinte comando na sua máquina cliente (ou seja, você não deve executar isso enquanto já estiver conectado via SSH à máquina do seu node - se estiver, saia do SSH primeiro):

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

Você verá o seguinte:

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

Isso pergunta onde você gostaria de salvar seu arquivo de chave privada. O SSH é compatível com o padrão fornecido e o usará automaticamente para você se você selecioná-lo. No entanto, você tem a opção de alterá-lo para outra coisa se desejar.

Se você estiver confortável com a configuração padrão, simplesmente pressione Enter.

Caso contrário, digite o local desejado para a chave. Deve ser um caminho absoluto (por exemplo, /home/username/.ssh/rocketpool_key no Linux, ou /Users/username/.ssh/rocketpool_key no OSX). Pressione Enter quando terminar.

Após pressionar Enter, você verá:

Enter passphrase (empty for no passphrase):

Esta será a senha para a própria chave privada. Sempre que você usar a chave para se conectar ao seu node, você precisará digitar esta senha primeiro.

Depois de terminar de digitar a senha, pressione Enter. Ele pedirá que você a digite novamente para confirmação.

Depois disso, você verá algo como a seguinte saída:

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]-----+

A primeira linha indica a localização da chave privada, que é chamada de id_ed25519 por padrão (observe que ela não tem uma extensão de arquivo). O Ubuntu carregará esta chave para você automaticamente quando você usar ssh se este arquivo de chave privada estiver no local padrão.

A segunda linha indica a localização da chave pública, que é chamada de id_ed25519.pub por padrão. Precisaremos da chave pública para a próxima etapa.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

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

#Adicionando a Chave Pública ao seu Node

Depois de ter seu par de chaves SSH, você pode agora adicionar a chave pública ao seu node. Isso permitirá que você se conecte a ele via ssh usando a chave privada que você acabou de gerar, em vez do seu nome de usuário e senha.

Existem duas maneiras de fazer isso - se uma não funcionar, tente a outra:

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

Agora você deve ser capaz de usar ssh no node como normalmente faria, mas agora não precisará digitar a senha da conta de usuário.

Em vez disso, você terá que digitar a senha da sua chave privada SSH. Dependendo das configurações do seu sistema, você pode ter que fazer isso apenas uma vez por reinicialização, ou pode ter que fazer isso toda vez que usar a chave para se conectar ao seu node.

#Desabilitar Login via Senha

Mesmo que você tenha um par de chaves SSH configurado, seu node ainda permitirá que outras máquinas tentem fazer login usando o método de nome de usuário e senha. Isso anula todo o propósito de usar chaves SSH em primeiro lugar, então o próximo passo é desabilitar isso.

Comece fazendo login na sua máquina usando ssh como de costume:

ssh user@your.node.ip.address

Como lembrete, você deve fazer isso duas vezes em dois terminais separados para ter uma sessão de backup por precaução. Você pode ignorar a sessão de backup por enquanto - diremos quando você precisar dela. Execute os seguintes comandos apenas na primeira sessão.

Abra o arquivo de configuração do servidor SSH:

sudo nano /etc/ssh/sshd_config

Como em todos os comandos que começam com sudo, isso solicitará a senha da sua conta de usuário. Este é um arquivo grande, então você terá que navegar por ele usando as teclas de seta do seu teclado ou Page Up / Page Down.

Faça as seguintes alterações:

1. Descomente #AuthorizedKeysFile se estiver comentado (removendo o # na frente dele)
2. Altere KbdInteractiveAuthentication yes para KbdInteractiveAuthentication no e descomente (removendo o # na frente dele) - observe que versões mais antigas do SSH chamam esta opção de ChallengeResponseAuthentication em vez de KbdInteractiveAuthentication
3. Altere PasswordAuthentication yes para PasswordAuthentication no e descomente (removendo o # na frente dele)
4. Altere PermitRootLogin yes para PermitRootLogin prohibit-password a menos que já esteja definido assim e tenha um # na frente

Depois de terminar, salve com Ctrl+O e Enter, depois saia com Ctrl+X.

Por fim, execute sudo sshd -T | grep -i passwordauthentication e certifique-se de que imprime passwordauthentication no. Se não imprimir, você pode precisar executar sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf e definir PasswordAuthentication yes para PasswordAuthentication no nesse arquivo também. Salve e saia como antes, com Ctrl+O e Enter, depois Ctrl+X

Em seguida, reinicie o servidor SSH para que ele pegue as novas configurações:

sudo systemctl restart ssh.service

Depois disso, fazer login no SSH via nome de usuário e senha deve estar desabilitado.

#(Opcional) Habilitar Autenticação de Dois Fatores

A autenticação de dois fatores envolve exigir uma segunda medida de segurança além da sua senha ou chave SSH, geralmente em um dispositivo separado do seu primário.

Por exemplo, você pode estar familiarizado com fazer login em um site como uma exchange de cripto usando tanto uma senha quanto um código do Google Authenticator (ou um código SMS). Este processo de dois passos é um exemplo de autenticação de dois fatores.

O SSH também pode ser configurado para exigir um código do Google Authenticator, o que significa que um atacante que de alguma forma comprometeu sua chave SSH e sua senha ainda precisaria do dispositivo com o aplicativo autenticador nele (presumivelmente seu telefone). Isso adiciona uma camada extra de segurança ao seu sistema.

Comece instalando o Google Authenticator (ou um equivalente compatível) no seu telefone se você ainda não o tiver. Para usuários do Android, considere andOTP que é uma alternativa de código aberto que suporta bloqueio por senha e backups convenientes.

Em seguida, instale o módulo Google Authenticator no seu node com este comando:

sudo apt install -y libpam-google-authenticator

Agora diga ao PAM (módulos de autenticação plugáveis) para usar este módulo. Primeiro, abra o arquivo de configuração:

sudo nano /etc/pam.d/sshd

Encontre @include common-auth (deve estar no topo) e comente-o adicionando um # na frente, para que fique assim:

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

Em seguida, adicione estas linhas ao topo do arquivo:

# Enable Google Authenticator
auth required pam_google_authenticator.so

Então salve e saia do arquivo com Ctrl+O, Enter e Ctrl+X.

Agora que o PAM sabe usar o Google Authenticator, o próximo passo é dizer ao sshd para usar o PAM. Abra o arquivo de configuração do sshd:

sudo nano /etc/ssh/sshd_config

Agora altere a linha KbdInteractiveAuthentication no para KbdInteractiveAuthentication yes para que fique assim:

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

(Versões mais antigas do SSH chamam esta opção de ChallengeResponseAuthentication em vez de KbdInteractiveAuthentication.)

Adicione a seguinte linha ao final do arquivo, que indica ao sshd que ele precisa tanto de uma chave SSH quanto do código do Google Authenticator:

AuthenticationMethods publickey,keyboard-interactive:pam

Então salve e saia do arquivo com Ctrl+O, Enter e Ctrl+X.

Agora que o sshd está configurado, precisamos criar nossos códigos 2FA. No seu terminal, execute:

google-authenticator

Primeiro, ele perguntará sobre tokens baseados em tempo. Diga y para esta pergunta:

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

Agora você verá um grande código QR na sua tela; escaneie-o com seu aplicativo Google Authenticator para adicioná-lo. Você também verá seu segredo e alguns códigos de backup assim:

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

Finalmente, ele perguntará sobre mais alguns parâmetros; os padrões recomendados são os seguintes:

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

Quando terminar, reinicie o sshd para que ele pegue as novas configurações:

sudo systemctl restart sshd

Quando você tentar fazer SSH no seu servidor com suas chaves SSH, agora você também deverá ser solicitado a fornecer um código de verificação 2FA, mas não uma senha.

#ESSENCIAL: Habilitar Atualizações Automáticas de Segurança

Os fornecedores de Sistemas Operacionais publicam rotineiramente atualizações e correções de segurança, por isso é importante que você mantenha seu sistema atualizado com os patches mais recentes. A maneira mais fácil de fazer isso é habilitar atualizações automáticas.

Execute os seguintes comandos na máquina do seu node:

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

Você pode alterar as configurações de atualização automática editando /etc/apt/apt.conf.d/20auto-upgrades:

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

Este é um exemplo de configurações de atualização automática razoáveis:

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 terminar de adicionar suas alterações, salve com Ctrl+O e Enter, depois saia com Ctrl+X.

Depois, certifique-se de carregar as novas configurações:

sudo systemctl restart unattended-upgrades

#ESSENCIAL: Habilitar um Firewall

Em geral, sua máquina deve aceitar apenas tráfego de rede nas portas que seu cliente Execution, cliente Consensus e pilha Smartnode usam. Para impor isso e prevenir qualquer tráfego inesperado ou indesejável, podemos instalar um firewall no node.

O Ubuntu vem com ufw instalado por padrão (o firewall descomplicado), que é um utilitário conveniente para gerenciar as configurações de firewall do seu node.

Os seguintes comandos configurarão o ufw com uma boa configuração padrão para o seu Smartnode. Execute-os na máquina do seu node.

Desabilite conexões a menos que sejam explicitamente permitidas por regras posteriores:

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

Permita SSH:

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

Permita cliente execution (anteriormente referido como 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'

Permita cliente consensus (anteriormente referido como 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 você executar o cliente lighthouse v4.5.0+, você pode usar o protocolo quic para reduzir a latência / aumentar a largura de banda, o protocolo quic usa lighthouse's --port + 1 para escutar mensagens quic por padrão: https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

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

Finalmente, habilite o ufw:

sudo ufw enable

#(Opcional) Habilitar Proteção contra Força Bruta e DDoS

Para proteger seu servidor contra ataques DDoS e tentativas de conexão de força bruta, você pode instalar o fail2ban. Este programa monitorará conexões recebidas e bloqueará endereços IP que tentam fazer login com credenciais incorretas repetidamente.

Consulte este guia para mais informações sobre prevenção de intrusão.

Execute os seguintes comandos na máquina do seu node:

Instale o serviço:

sudo apt install -y fail2ban

Em seguida, abra /etc/fail2ban/jail.d/ssh.local:

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

Adicione o seguinte conteúdo a ele:

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

Você pode alterar a configuração maxretry, que é o número de tentativas que permitirá antes de bloquear o endereço ofensor.

Quando terminar, salve e saia com Ctrl+O e Enter, depois Ctrl+X.

Finalmente, reinicie o serviço:

sudo systemctl restart fail2ban

E com isso, você acabou de melhorar muito a postura de segurança do seu node. Parabéns!