Hardening de VPS Linux: Chaves SSH e Segurança Avançada

A segurança de um servidor virtual privado (VPS) é a linha de defesa mais crítica contra acessos não autorizados e ataques automatizados. Entre as múltiplas camadas de proteção disponíveis, a autenticação baseada em chaves SSH (Secure Shell) destaca-se como o padrão ouro da indústria. Ao substituir senhas por pares de chaves pública/privada, você elimina a vulnerabilidade clássica de força bruta e garante que apenas dispositivos com a chave privada correta possam estabelecer conexão.

Neste tutorial técnico, detalhamos o processo completo de geração, configuração e implementação de chaves SSH em um ambiente Linux. Abordaremos desde a criação local das chaves até a hardening do servidor remoto, incluindo a desativação do login por senha e a integração com ferramentas de mitigação como UFW, Fail2ban e Crowdsec para uma postura de segurança robusta.

Geração do Par de Chaves SSH

O primeiro passo ocorre na sua máquina local (estação de trabalho ou laptop), onde você gerará os arquivos que atuarão como sua identidade digital. Recomendamos o uso do algoritmo Ed25519, que oferece excelente segurança com chaves menores e performance superior ao tradicional RSA em comparação direta.

Abra seu terminal no Linux, macOS ou no Git Bash/PowerShell no Windows e execute o comando abaixo:

ssh-keygen -t ed25519 -C "[email protected]"

O parâmetro -C adiciona um comentário (geralmente seu e-mail) ao final da chave pública, facilitando a identificação futura se você gerenciar múltiplas chaves. Ao rodar o comando, o sistema solicitará dois inputs:

1. Caminho do arquivo de salvamento: Pressione Enter para aceitar o caminho padrão (~/.ssh/id_ed25519). Isso mantém a organização dentro da pasta oculta .ssh.
2. Senha (passphrase): Digite uma senha forte e única. Embora opcional, essa camada extra de segurança é altamente recomendada. Ela impede que, caso sua chave privada seja roubada, o atacante a utilize sem precisar decifrar sua senha localmente.

Ao concluir, dois arquivos foram gerados na pasta ~/.ssh/:

• id_ed25519: Sua chave privada. Nunca compartilhe este arquivo nem o envie por e-mail.
• id_ed25519.pub: Sua chave pública. Este é o arquivo que será copiado para o servidor.

Cópia da Chave Pública para a VPS

Agora, precisamos transferir a chave pública para o diretório .ssh do usuário no seu servidor Linux. A ferramenta ssh-copy-id automatiza esse processo, criando as permissões corretas automaticamente.

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@seu_ip_vps

O sistema solicitará a senha atual do usuário no servidor. Após a autenticação bem-sucedida, o conteúdo da chave pública será anexado ao arquivo ~/.ssh/authorized_keys do servidor.

Dica de Pro: Se você estiver usando uma porta SSH não padrão (diferente da 22), especifique-a com a flag -p:

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 usuario@seu_ip_vps

Após a execução, teste a conexão manualmente para verificar se a chave está sendo reconhecida:

ssh usuario@seu_ip_vps

Se configurado com passphrase, você será solicitado a inseri-la. Se configurado sem, o login será imediato. Se o acesso for negado, verifique as permissões do arquivo authorized_keys no servidor.

Hardening do Servidor: Desabilitando Senhas

Apenas adicionar a chave pública não torna seu servidor imune. O serviço SSH ainda aceitará logins com senha, mantendo a porta vulnerável a ataques de dicionário e força bruta. Para garantir uma vps segura, devemos forçar o uso exclusivo de autenticação por chaves.

Acesse seu servidor via SSH (ainda usando a senha atual, se necessário) e edite o arquivo de configuração do daemon OpenSSH:

sudo nano /etc/ssh/sshd_config

Localize as seguintes diretrizes e ajuste os valores conforme abaixo. Se estiverem comentadas (com # no início), descomente-as alterando o valor para "no":

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Explicação técnica das alterações:

• PermitRootLogin no: Bloqueia o login direto como root. Isso obriga o administrador a acessar como usuário comum e elevar privilégios via sudo, criando um rastro de auditoria.
• PasswordAuthentication no: O comando mais crítico. Desativa qualquer tentativa de autenticação baseada em senha, forçando o uso da chave privada.
• PubkeyAuthentication yes: Garante explicitamente que a verificação de chaves públicas está habilitada.

Salve o arquivo (Ctrl+O, Enter, Ctrl+X no nano) e reinicie o serviço SSH para aplicar as mudanças:

sudo systemctl restart sshd

Atenção Crítica: Antes de fechar sua sessão atual, mantenha outro terminal aberto e tente se conectar novamente. Se a configuração estiver correta, você entrará sem pedir senha (ou pedindo a passphrase local). Se falhar, use o segundo terminal para reverter as alterações ou recuperar acesso via painel de controle da hospedagem.

Configuração do Firewall com UFW

Com a autenticação reforçada, o próximo passo é restringir quem pode alcançar a porta SSH. O Uncomplicated Firewall (UFW) é uma interface amigável para o iptables, padrão em distribuições Debian/Ubuntu.

Primeiro, verifique se o UFW está ativo:

sudo ufw status

Se inativo, ative-o. Aviso: Certifique-se de ter liberado a porta SSH antes de ativar o firewall para não se bloquear fora do servidor.

sudo ufw allow 22/tcp
sudo ufw enable

Se você alterou a porta padrão do SSH (ex: 2222), libere essa nova porta em vez da 22:

sudo ufw allow 2222/tcp

O UFW agora bloqueará todas as conexões de entrada, exceto as explicitamente permitidas. Isso reduz drasticamente a superfície de ataque exposta na internet.

Mitigação de Ataques com Fail2ban e Crowdsec

Apesar do firewall e das chaves SSH, scanners automatizados varrerão sua porta aberta 24/7 buscando tentativas de login. Ferramentas como fail2ban e Crowdsec atuam na camada de aplicação, monitorando logs em tempo real.

Fail2ban: O Guardião Clássico

O Fail2ban analisa os logs do sistema e bloqueia endereços IP que exibem comportamento malicioso, como múltiplas falhas de autenticação.

Instale o pacote:

sudo apt install fail2ban

Copie o arquivo de configuração padrão para criar uma cópia editável, evitando que atualizações sobrescrevam suas regras:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edite /etc/fail2ban/jail.local e configure as ações para o serviço SSH. Adicione ou modifique:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

Essa configuração diz ao Fail2ban para banir qualquer IP que falhar o login SSH três vezes, bloqueando-o por uma hora (3600 segundos). Reinicie o serviço:

sudo systemctl restart fail2ban

Crowdsec: Inteligência Coletiva e Moderna

O Crowdsec é uma ferramenta mais moderna que complementa ou substitui o Fail2ban. Diferente do Fail2ban, que atua localmente, o Crowdsec compartilha blocos de IPs maliciosos com a comunidade (banco de dados global). Se um IP tentar invadir seu servidor e for banido pelo Crowdsec, ele pode já estar na lista negra global.

A instalação varia conforme a distro. Para Debian/Ubuntu:

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec

Após a instalação, instale o "bouncer" do SSH para integrar o Crowdsec ao serviço:

sudo apt install crowdsec-bouncer-ssh

O Crowdsec monitorará os logs e tomará ações automáticas. Para visualizar alertas de monitoramento invasao, use:

cscli decisions list

A combinação de UFW, Fail2ban e Crowdsec cria uma defesa em profundidade (defense in depth) eficaz contra a maioria das ameaças externas.

Otimizações Avançadas de Segurança

Para elevar ainda mais o nível de hardening linux, considere implementar as seguintes práticas complementares:

Mudança de Porta Padrão

Embora não seja uma segurança por si só (security through obscurity), mover o SSH da porta 22 para uma porta aleatória alta reduz drasticamente o ruído dos bots genéricos. No arquivo /etc/ssh/sshd_config:

Port 45000

Lembre-se de atualizar as regras do UFW e tentar a conexão usando ssh -p 45000 usuario@ip.

Limitação de Usuários e Grupos

Restrinja quem pode fazer login via SSH. Adicione ao final do sshd_config:

AllowUsers admin devuser
DenyUsers root nobody

Iso impede que usuários não listados, mesmo que possuam chaves válidas, autentiquem-se no sistema.

Timeout de Sessão Inativa

Configure o cliente SSH para fechar conexões ociosas rapidamente, reduzindo a janela de oportunidade para ataques man-in-the-middle ou exploração de sessões esquecidas. No arquivo /etc/ssh/sshd_config:

ClientAliveInterval 300
ClientAliveCountMax 2

Isso mantém a conexão viva apenas se houver atividade a cada 5 minutos (300 segundos), desconnectando após duas falhas de resposta.

Boas Práticas de Gerenciamento de Chaves

A segurança depende tanto da configuração técnica quanto dos hábitos do administrador. Para manter sua vps segura:

• Backup das Chaves Privadas: Armazene uma cópia offline (em um pen drive criptografado ou gerenciador de senhas) da chave privada. Se você perder o acesso à máquina local e não tiver backup, precisará restaurar o servidor via console de recuperação.
• Rotação de Chaves: Periodicamente, gere novas chaves e remova as antigas do arquivo authorized_keys. Isso limita o dano caso uma chave privada seja comprometida silenciosamente.
• Monitoramento Contínuo: Utilize ferramentas como Crowdsec ou auditores de logs para identificar tentativas de acesso. Logs em /var/log/auth.log devem ser revisados regularmente.
• Proteção da Chave Privada Local: Garanta que o arquivo id_ed25519 tenha permissões restritas (chmod 600 ~/.ssh/id_ed25519). Se outro usuário ou processo puder ler sua chave privada, toda a segurança é anulada.

Conclusão

A migração para autenticação por chaves SSH é uma das ações mais impactantes que um administrador pode realizar na mitigacao ddos e ataques de intrusão. Ao combinar chaves fortes Ed25519, desativação de senhas, firewall rigoroso e sistemas de resposta a incidentes como Fail2ban e Crowdsec, você transforma seu servidor em uma fortaleza digital difícil de ser violada.

Lembre-se: segurança não é um produto, mas um processo contínuo. Mantenha seus sistemas atualizados, revise suas permissões periodicamente e nunca confie cegamente em configurações padrão. Com essa base sólida, você estará preparado para lidar com as ameaças modernas à infraestrutura de TI.