Pular para o conteúdo principal

Segurando Um Validador

Cada candidato a validador é incentivado a executar suas operações de forma independente, pois configurações diversificadas aumentam a resiliência da rede. Os candidatos a validador devem iniciar sua fase de configuração agora para estarem prontos para o lançamento.

Gerenciamento de Chaves - HSM

É de missão crítica que um invasor não possa roubar a chave de um validador. Se isso for possível, coloca em risco todo o stake delegado ao validador comprometido. Módulos de segurança de hardware são uma estratégia importante para mitigar esse risco.

Módulos HSM devem suportar assinaturas ed25519 para o hub. O YubiHSM2 suporta ed25519 e esta biblioteca yubikey está disponível. O YubiHSM pode proteger uma chave privada, mas não pode garantir em um ambiente seguro que não assinará o mesmo bloco duas vezes.

A equipe Tendermint também está trabalhando para estender nosso aplicativo Ledger Nano S para suportar a assinatura de validadores. Este aplicativo pode armazenar blocos recentes e mitigar ataques de assinaturas duplicadas.

Atualizaremos esta página quando mais soluções de armazenamento de chaves estiverem disponíveis.

Tipos de Chaves

Existem dois tipos de chaves:

  • Chave Tendermint: Uma chave única usada para assinar votos de consenso.
    • Está associada a uma chave pública mpvalconspub (Para obter esse valor, execute crossfid tendermint show-validator)
    • É gerada quando o nó é criado com crossfid init.
  • Chave de Aplicação: Esta chave é criada a partir do binário crossfid e é usada para assinar transações. As chaves de aplicação estão associadas a uma chave pública que é prefixada por cosmospub e um endereço que é prefixado por cosmos.

A chave Tendermint e a chave de aplicação são derivadas das chaves da conta geradas pelo comando crossfid keys add.

Nota: A chave do operador de um validador está diretamente ligada a uma chave de aplicação e utiliza os prefixos mpvaloper e mpvaloperpub que são reservados exclusivamente para esse fim.

Nódulos de Sentinela (Proteção DDOS)

Os validadores são responsáveis por garantir que a rede possa sustentar ataques de negação de serviço.

Uma maneira recomendada de mitigar esses riscos é que os validadores estruturam cuidadosamente sua topologia de rede em uma arquitetura chamada de nódulo de sentinela.

Os nós validadores devem se conectar apenas a nós completos de confiança porque eles mesmos os operam ou são executados por outros validadores que eles conhecem socialmente. Um nó validador normalmente é executado em um data center. A maioria dos data centers fornece links diretos para as redes dos principais provedores de nuvem. O validador pode usar esses links para se conectar a nódulos de sentinela na nuvem, transferindo a carga de negação de serviço do nó do validador diretamente para seus nódulos de sentinela, podendo exigir a ativação de novos nódulos de sentinela para mitigar os ataques em nódulos já existentes.

Os nódulos de sentinela podem ser rapidamente ativados ou mudar seus endereços IP. Como os links para os nódulos de sentinela estão em espaço IP privado, um ataque baseado na internet não pode perturbá-los diretamente. Isso garantirá que as propostas de bloco do validador e os votos sempre cheguem ao restante da rede.

Para configurar sua arquitetura de nódulo de sentinela, você pode seguir as instruções abaixo:

Os nós validadores devem editar seu config.toml:


# Lista separada por vírgulas de nós para manter conexões persistentes

# Não adicione pares privados a esta lista se não quiser que eles sejam anunciados
pares_persistentes =[lista de nódulos de sentinela]

# Coloque verdadeiro para ativar o reator de troca de pares
pex = false

Os nós de sentinela devem editar seu config.toml:


# Lista separada por vírgulas de IDs de pares a serem mantidos privados (não serão propagados a outros pares)

# Exemplo de ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656

private_peer_ids = "node_ids_of_private_peers"

Como os validadores podem se proteger de ataques de negação de serviço?

Ataques de negação de serviço ocorrem quando um invasor envia uma enxurrada de tráfego de internet para um endereço IP para impedir que o servidor no endereço IP se conecte à internet.

Um invasor escaneia a rede, tenta descobrir o endereço IP de vários nós validadores e os desconecta da comunicação inundando-os com tráfego.

Uma maneira recomendada de mitigar esses riscos é que os validadores estruturam cuidadosamente sua topologia de rede utilizando uma arquitetura de nó sentinela.

Espera-se que os nós validadores se conectem apenas a nós completos de confiança porque eles operam os nós completos ou os nós completos de confiança são operados por outros validadores que eles conhecem socialmente. Um nó validador é normalmente executado em um data center. A maioria dos data centers fornece links diretos para as redes dos principais fornecedores de nuvem. O validador pode usar esses links para se conectar a nódulos sentinela na nuvem. Essa mitigação transfere a carga de negação de serviço do nó do validador diretamente para seus nódulos sentinela, podendo exigir que novos nódulos sentinela sejam ativados para mitigar ataques aos já existentes.

Os nódulos sentinela podem ser rapidamente ativados ou mudar seus endereços IP. Como os links para os nódulos sentinela estão em espaço IP privado, um ataque baseado na internet não pode perturbá-los diretamente. Esta estratégia garante que as propostas de bloco do validador e os votos tenham uma chance muito maior de chegar ao restante da rede.

Para mais detalhes sobre nódulos sentinela, consulte a Documentação Tendermint ou o Visão Geral da Arquitetura de Nó Sentinela no fórum.