Proteja sua implementação SSH com autenticação de dois fatores WiKID

SSH oferece um canal altamente seguro para administração remota de servidores. No entanto, se você enfrentar uma auditoria por requisitos regulatórios ou comerciais, como PCI Visa/Mastercard, precisa estar ciente de algumas possíveis falhas relacionadas à autenticação que podem causar dores de cabeça em uma auditoria. Por exemplo:

Não há como controlar quais usuários têm autorização de chave pública
Não há como impor a complexidade da frase secreta (ou mesmo ter certeza de que uma está sendo usada)
Não há como expirar uma chave pública

Neste documento, vamos demonstrar como combinar a autenticação de dois fatores da WiKID com um servidor gateway SSH com chaves privadas hospedadas para criar uma solução de acesso remoto altamente segura, auditável e fácil de usar. O Sistema de Autenticação Forte WiKID é uma solução de autenticação de dois fatores comercial/código aberto. Primeiro, configuraremos um domínio no servidor WiKID, depois adicionaremos os servidores como clientes de rede ao servidor WiKID e, finalmente, configuraremos a caixa gateway e os servidores-alvo - no nosso caso, servidores Fedora Core 6.

Adicionando um domínio ao servidor WiKID

Criar domínio

Criar um cliente de rede

Após salvar as informações do domínio, clique na aba Cliente de Rede e Criar Novo Cliente de Rede. Insira um nome para este cliente e o Endereço IP do gateway SSH na rede interna. Selecione Radius como o protocolo e o domínio que você criou acima como o domínio.

Criar cliente de rede

Clique em Adicionar para ir para a próxima página e insira o segredo compartilhado para o Radius.

Criar cliente de rede 2

Você precisará repetir esse processo para cada servidor em sua rede.

Configurar o Gateway SSH

Agora vamos configurar o gateway SSH central. Esta caixa linux é o gateway/proxy para todos os servidores de produção na fazenda. Deve estar bem protegida, sem software ou serviços desnecessários em execução. Deve ter uma interface externa para conexões de entrada e uma interface interna para conexões internas. Primeiro, configuraremos a caixa gateway para usar WiKID para autenticação forte de usuários SSH. Edite seu arquivo /etc/pam.d/sshd da seguinte forma:

#%PAM-1.0   
auth       sufficient   /lib/security/pam_radius_auth.so   
auth       include      system-auth   
account    required     pam_nologin.so   
account    include      system-auth   
password   include      system-auth   
session    include      system-auth   
session    required     pam_loginuid.so

Adicione seu servidor WiKID ao arquivo /etc/raddb/server, usando o Endereço IP interno do servidor WiKID e o segredo compartilhado que você inseriu na página de criação do Cliente de Rede:

# server[:port] shared_secret      timeout (s)   
127.0.0.1       secret             1   
xxx.xxx.xxx.xx  wikidserver_secret 3

Vamos adicionar um pouco de segurança à configuração do SSH aqui também. Abra seu /etc/ssh/sshd_config (não o arquivo ssh_config próximo). Adicione estas opções de configuração:

#Protocol 2,1   
#Verifique se apenas o protocolo 2 é permitido:   
Protocol 2   
#Desautorizar login root:   
PermitRootLogin no   
#Desautorizar contas sem senhas:   
PermitEmptyPasswords no

Se você quiser mudar a porta, pode fazê-lo. Isso não impedirá um atacante, mas pode reduzir os eventos de log causados por script kiddies. Esta caixa gateway agora está configurada para usar senhas de uso único WiKID para autenticação SSH. Todos os usuários devem estar registrados no servidor WiKID e ninguém pode fazer login como root. Antes de deixarmos esta caixa, faremos algo um pouco diferente - faremos os usuários criarem sua chave privada RSA na gateway. Uma vez que cada usuário esteja logado na caixa com WiKID, peça que eles criem suas chaves:

ssh-keygen -t rsa

Na minha opinião, frases secretas para essas chaves são redundantes. Elas estão aqui apenas para criar uma funcionalidade de login único na fazenda de servidores. Obviamente, você deve ter cuidado para garantir que os usuários não tenham acesso a outras chaves.

Configurar os servidores-alvo

Obviamente, configuramos esses servidores para aceitar apenas solicitações SSH de entrada do gateway. Fazemos isso restringindo o acesso na porta 22 aos nossos endereços internos. Edite /etc/sysconfig/iptables e adicione ou edite a linha para SSH na porta 22:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

As chances são de que você possa usar a configuração padrão para sshd_config, que permite a autenticação de chave pública. Então, terminamos!

Conclusão

O SSH remoto agora está extremamente seguro. Nenhum usuário pode acessar a fazenda de servidores sem primeiro obter um código de uso único do servidor WiKID. Os dois fatores de autenticação são a posse do token WiKID (e sua chave criptográfica) e o conhecimento do PIN. Como o PIN é validado no servidor WiKID, é muito fácil desativar um usuário. Tudo é registrado e qualquer auditor deve ficar muito satisfeito.

Além disso, você pode exigir um código de uso único WiKID para acesso root em máquinas internas. Basta criar um novo domínio para su e editar /etc/pam.d/su adequadamente. Isso também permitirá que você divida os servidores em diferentes grupos para gerenciamento. Por exemplo, se você tiver um conjunto de servidores para RH aos quais apenas certos administradores têm acesso root, eles podem ser configurados para um domínio WiKID específico - permitindo controle de acesso granular e autenticação forte. Obtenha mais informações sobre autenticação de dois fatores no site da WiKID.