Nos dias de hoje, é comum ver empresas adotando estratégias de virtualização e almejando chegar à computação em nuvem. O começo dessa automação normalmente passa pelo emprego de modelos (templates) de Máquinas Virtuais. Normalmente algum sabor de *nix (Linux, Unix, BSD, etc) existe e nestes sistemas operacionais o serviço de Shell Seguro (SSH) é habilitado. É aqui que um administrador pode introduzir um problema/risco de segurança.
O uso dos modelos é benéfico, pois economiza muito tempo e recursos, uma vez que uma máquina padronizada é preparada com todos os softwares e customizações necessárias e então transformada em modelo, e este é utilizado como base para novas máquinas.
Administradores *nix estão familiarizados com o uso da CLI (Command Line Interface) para realizar a administração do sistema. É natural que o SSH, que permite o acesso seguro esteja presente para facilitar o acesso remoto aos equipamentos.
Quando a máquina de referência é transformada em modelo, o serviço de SSH já foi instalado e configurado, permitindo assim o acesso remoto assim que a máquina é instanciada.
O que muitos administradores esquecem de fazer antes de transformar a VM em modelo é a gerência dos pares de chaves. Durante a instalação do SSH é comum que os pares de chaves necessários sejam gerados automaticamente. É importante tomar uma ação para que as máquinas baseadas neste modelo não usem os mesmos pares de chaves!
Imaginem o possível impacto, em uma Nuvem, seja ela pública ou privada, se todos os servidores compartilharem os mesmos pares de chaves. Isto introduz brechas de segurança. Mas as ramificações e possíveis vetores de ataque não fazem parte do escopo deste Tech Tip. Aqui abordaremos como evitar que o problema aconteça em primeiro lugar!
É importante que as chaves existentes sejam removidas e que tenhamos garantias de que na 1ª inicialização, novos pares de chaves sejam gerados.
Para evitar o problema descrito, basta remover os arquivos das chaves, sem esquecer de apagar tanto a chave pública, quanto a privada. Geralmente as chaves ficam localizadas em “/etc/ssh”.
Se você compilou o openSSH manualmente, ou usa outro produto ou sabor de *nix, consulte a documentação para saber o diretório correto.
Figura 1 – Lista das chaves de SSH
Observe na figura acima, que existe sempre um par para cada algoritmo.
ssh_host_ecdsa_key = Chave privada para o algoritmo ECDSA
ssh_host_ecdsa_key.pub = Chave pública para o algoritmo ECDSA
Os arquivos sem extensão armazenam as chaves privadas e os arquivos com final “.pub” armazenam as chaves públicas.
Como dito anteriormente, antes de gerar o modelo, basta remover os arquivos das chaves, e se certificar que novas chaves sejam geradas. A seguir vamos abordar o que deve ser feito para que novas chaves sejam geradas.
Normalmente as distribuições de Linux empacotam uma versão do OpenSSH, originalmente escrito e mantido pela equipe do OpenBSD. Algumas implementações geram as chaves que estejam faltantes automaticamente, enquanto em outras versões o serviço inicia mas loga um erro de que as chaves não estão acessíveis, e na prática, o acesso não funciona.
Abaixo ilustraremos o exemplo do comportamento do OpenSSH como fornecido no pacote do CentOS 7, que gera as chaves automaticamente.
Figura 2- OpenSSH gerando as chaves faltantes automaticamente
Já no Ubuntu Linux, por padrão, novos pares de chaves não serão gerados automaticamente. Sem as chaves existentes, o serviço inicia, mas loga o erro de que as chaves não foram encontradas e não permitirá acesso.
Figura 3 – OpenSSH gerando erro de que as chaves não foram encontradas
Observe que o serviço tentou carregar chaves RSA, DAS, ECDSA e ED25519. Como nenhuma deles foi encontrada, o sistema loga um erro fatal de que nenhum algoritmo de troca de chaves está funcional, ou seja, o login não será permitido, pois nenhum algoritmo criptográfico funcional está disponível. Se pelo menos um deles estivesse disponível, ele poderia ser utilizado.
Você pode, se assim desejar, trocar os nomes dos arquivos que armazenam as chaves. Se o fizer, deve atualizar o arquivo “sshd_config”, que é o arquivo de configuração do serviço. Recomendamos que não faça alterações, a menos que esteja certo do que está fazendo.
Se a sua distribuição gerar automaticamente, você está pronto, pode converter a VM em modelo! Se precisar automatizar a geração das chaves, vamos mostrar como fazer isto.
Da mesma forma que vários caminhos levam a Roma, existem muitas maneiras de automatizar a geração das chaves. Cada uma delas tem suas vantagens e desvantagens, e talvez o time de S.O. de sua empresa tenham algum guideline ou melhor prática de como implementar esta ação. Verifique com eles a melhor forma de manter isso dentro dos padrões organizacionais.
Vamos mostrar uma forma rápida e prática de maneira manual, e depois vamos mostrar um exemplo desta automação.
O comando “ssh-keygen” é bem flexível, e sua lista de opções é grande. Para este Tech Tip, vamos nos ater a este comando com a opção “-A” (atenção a caixa alta/baixa).
Este comendo irá verificar todos os algoritmos suportados e se há chave(s) que está(ão) faltante(s) e em caso afirmativo, será(ão) gerada(s) (somente aquelas que estiverem faltando). Se a chave estiver presente, o comando não gera uma nova que sobrepõe o arquivo, o que facilita muito a nossa vida e a tarefa de automação.
Nota: Observar que este comando deverá ser executado como “root” ou super usuário equivalente.
Abaixo vamos ilustrar a execução do comando com todas as chaves faltantes.
Figura 4- Uso do “ssh-keygen” para gerar as chaves.
Observe na Figura acima que que as chaves RSA, RSA1, DSA, ECDSA e ED25519 foram geradas, pois todas elas estavam faltantes.
Se executarmos o comando uma segunda vez, não teremos nenhuma chave listadas, pois elas estão presentes, conforme figura abaixo.
Figura 5 – Execução do “ssh-keygen” sem geração de chaves
Como mostra a figura 5, o comando retorna sem nenhuma informação, pois nenhuma chave teve de ser gerada. Isso facilita nossa automação, pois pode-se configurar a execução do comando em todo o boot, e em caso de algum “acidente”, novas chaves serão geradas automaticamente. A troca dos pares de chaves deve ser uma ação planejada e controlada, mas caso o comando seja executado em todo o boot, isto ajuda a manter o serviço de SSH disponível. Consulte seu time de segurança ou procedimentos existentes para determinar a melhor maneira de garantir a segurança do ambiente.
Uma forma simples para automatizar a execução do comando acima é criar um script, aqui chamado de “S06gerachaves” no diretório “/etc/rcS.d” com o seguinte conteúdo:
#!/bin/bash
echo "Gerando chaves para o SSH"
/usr/bin/ssh-keygen -A
service ssh restart
rm /etc/rcS.d/S06gerachaves
Salve o arquivo e torne-o executável com o comando “chmod +x /etc/rcS.d/S06gerachaves”.
Este script é minimamente funcional e pode ser melhorado de diversas maneira. É importante observar que a última linha apaga o script. Se você desejar que ele seja executado toda vez que o servidor for reiniciado basta remover esta linha.
Nota: o comando “service ssh restart”, do script acima é válido no Ubuntu Linux. Em outras distribuições o comando para reiniciar um serviço pode ser diferente. Modifique o script para refletir o comando corretamente.
Nota: A execução de scripts existentes no diretório “/etc/rcS.d” funciona no Ubuntu Linux. Para a sua distribuição ou versão pode não funcionar. Consulte a documentação de sua distribuição ou procedimento já existente em sua companhia.
Como citamos anteriormente, o comando “ssh-keygen –A” irá gerar toda e qualquer chave suportada pelo OpenSSH. Talvez em seu ambiente você tenha restrições a alguns algoritmos criptográficos, e tenha que gerar as chaves apenas para algoritmos específicos.
Se você tiver que ser mais específico, pode modificar o script acima e utilizar o comando para gerar apenas a(s) chave(s) que desejar, como demostrado abaixo.
Para gerar um par de chaves utilizando RSA
ssh-keygen -q -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key
Para gerar um par de chaves utilizando ECDSA
ssh-keygen -q -t ecdsa -N "" -f /etc/ssh/ssh_host_ecdsa_key
Nota: Os comandos acima não irão verificar se o par de chaves já existe. Caso opte por este modo, certifique-se de remover a execução do script em todo boot, pois isto pode causar efeitos indesejados.
Automatizar a instalação e configuração de servidores é benéfica e traz uma série de vantagens, mas devemos tomar os cuidados necessários para não diminuirmos a segurança de nosso ambiente ou de nossos clientes.