Investigação e tentativas suspeitas de acesso SSH no Linux: Aprendendo analisar logs de autenticação

1. Introdução

Em ambientes corporativos, servidores em nuvem ou laboratórios de estudo, sistemas Linux representam a espinha dorsal de grande parte da infraestrutura moderna. Por serem administrados remotamente, esses servidores precisam manter canais de gerenciamento ativos — e, sempre que um serviço fica acessível pela rede, ele passa a receber sondagens constantes.

Para estudantes de tecnologia, administradores de sistemas e aspirantes a analistas de SOC (Security Operations Center) ou Blue Team, compreender como investigar tentativas suspeitas de acesso é uma competência prática indispensável. Mais do que conhecer ferramentas avançadas, a segurança defensiva começa pela visibilidade: saber onde o sistema registra eventos e como interpretar essas evidências.

2. O que é SSH e como funciona

O SSH (Secure Shell) é um protocolo de rede criptografado utilizado para estabelecer comunicação segura entre um cliente (como o computador do administrador) e um servidor remoto, operando por padrão na porta TCP 22. Ele substituiu protocolos antigos e inseguros, como o Telnet, ao garantir confidencialidade e integridade dos dados trafegados.

Na prática, uma conexão básica a partir do terminal segue a estrutura:

Bash

ssh usuario@192.168.1.100

(Nota: O endereço 192.168.1.100 é apenas um exemplo ilustrativo de rede local. Em atividades reais, utilize exclusivamente endereços de servidores aos quais você possui autorização formal de acesso).

Justamente por conceder acesso direto ao shell do sistema operacional, o serviço SSH (sshd) é um dos principais alvos de varreduras automatizadas na internet. Bots percorrem faixas de endereços IP continuamente testando combinações comuns de usuários e senhas na tentativa de obter acesso não autorizado.

3. A importância dos logs de autenticação

Logs são registros cronológicos gerados pelo sistema operacional e pelos serviços em execução. Na segurança defensiva, os logs de autenticação funcionam como a caixa-preta do controle de acesso: eles registram quem tentou entrar, por qual serviço, a partir de qual endereço IP, em qual horário e se a autenticação foi aceita ou rejeitada.

Sem a análise de logs, a equipe de infraestrutura opera às cegas, incapaz de distinguir um uso legítimo de uma tentativa de intrusão em andamento.

4. Onde encontrar os registros no Linux

A localização dos arquivos de log de autenticação varia de acordo com a família da distribuição Linux e com o sistema de gerenciamento de logs adotado:

• Distribuições baseadas em Debian (Ubuntu, Debian, Linux Mint, Kali): Os eventos de autenticação são gravados em /var/log/auth.log.
• Distribuições baseadas em Red Hat (RHEL, Rocky Linux, AlmaLinux, Fedora): Os registros ficam armazenados em /var/log/secure.
• Sistemas com systemd (journald): Além dos arquivos de texto tradicionais (ou em substituição a eles, em instalações mais recentes), o serviço systemd-journald centraliza registros binários que podem ser consultados por meio do utilitário journalctl.

Como esses arquivos contêm informações sensíveis de segurança, sua leitura exige privilégios administrativos (sudo ou usuário root).

5. Como identificar tentativas malsucedidas

Quando um usuário erra a senha ou tenta autenticar com uma conta inexistente via SSH, o daemon sshd registra uma mensagem padronizada contendo expressões como Failed password ou Invalid user.

Observe este exemplo ilustrativo de uma linha de log:

Plaintext

Nov 10 02:14:32 server sshd[1234]: Failed password for invalid user admin from 203.0.113.45 port 51234 ssh2

Cada segmento dessa linha fornece uma pista importante para a investigação:

1. Nov 10 02:14:32: Data e horário exatos em que o evento ocorreu no relógio do servidor.
2. server: Hostname (nome) da máquina que gerou o registro.
3. sshd[1234]: Nome do serviço responsável (daemon SSH) e o PID (identificador do processo).
4. Failed password: Resultado da tentativa — a senha fornecida foi rejeitada.
5. for invalid user admin: Indica que o atacante tentou usar o nome de usuário admin, que sequer existe cadastrado nesse servidor.
6. from 203.0.113.45 port 51234: Endereço IP de origem da conexão e a porta efêmera utilizada pelo cliente (nota: 203.0.113.0/24 é uma faixa reservada pela RFC 5737 exclusivamente para documentação e exemplos).
7. ssh2: Versão do protocolo SSH utilizada.

6. Como reconhecer possíveis ataques de força bruta

Um erro de digitação cometido por um administrador legítimo gera uma linha de Failed password. Portanto, uma tentativa falha isolada não caracteriza um ataque nem uma invasão.

A suspeita de ataque de força bruta (brute force) ou pulverização de senhas (password spraying) surge quando observamos padrões anômalos, tais como:

• Alta frequência em curto intervalo: Dezenas ou centenas de falhas ocorrendo em poucos segundos.
• Enumeração de usuários: Tentativas sequenciais com contas padrão ou genéricas (root, admin, user, test, ubuntu, postgres).
• Persistência de origem: Um mesmo endereço IP (ou bloco de IPs) gerando falhas contínuas.
• Horários atípicos: Picos de tentativas durante a madrugada ou fora da janela operacional da equipe.

7. Investigação prática utilizando comandos Linux

Para investigar esses registros diretamente no terminal (utilizando como base um sistema Ubuntu/Debian), podemos combinar ferramentas nativas de filtragem de texto:

1. Filtrar todas as tentativas com senha incorreta:

Bash

sudo grep "Failed password" /var/log/auth.log

O comando grep busca o padrão textual "Failed password" dentro do arquivo especificado, exibindo apenas as linhas correspondentes.

2. Verificar se alguma tentativa foi bem-sucedida:

Bash

sudo grep "Accepted" /var/log/auth.log

Este é um dos comandos mais críticos da triagem: ele mostra quais conexões realmente obtiveram sucesso (seja por senha via Accepted password ou por chave pública via Accepted publickey).

3. Monitorar eventos de autenticação em tempo real:

Bash

sudo tail -f /var/log/auth.log

A opção -f (follow) mantém o terminal aberto exibindo novas linhas assim que são gravadas no arquivo, permitindo observar ataques em andamento.

4. Investigar logs usando journalctl:

Bash

sudo journalctl -u ssh --since today

Filtra os registros da unidade de serviço ssh ocorridos desde o início do dia atual. (Atenção: em distribuições baseadas em RHEL/Rocky Linux, o nome da unidade geralmente é sshd, alterando o comando para sudo journalctl -u sshd --since today).

8. Como interpretar os resultados

Durante a análise, o analista deve cruzar as saídas dos comandos anteriores para classificar a gravidade do cenário:

• Cenário A — Apenas registros Failed password de IPs desconhecidos: Indica sondagem ou tentativa automatizada de força bruta bloqueada pela própria autenticação. Requer monitoramento e reforço preventivo, mas não indica comprometimento.
• Cenário B — Sequência de Failed password seguida de Accepted password do mesmo IP suspeito: Sinal de alerta crítico. Indica que o atacante acertou a senha após múltiplas tentativas e obteve acesso ao sistema.
• Cenário C — Registro Accepted em horário incomum ou de origem não reconhecida: Mesmo sem falhas anteriores, pode indicar uso de credenciais vazadas e exige verificação imediata dos comandos executados na sessão e dos processos ativos.

9. Medidas defensivas e boas práticas

Ao confirmar atividade suspeita, a resposta deve ser estruturada e proporcional ao contexto do ambiente:

1. Preservação de evidências: Copie os trechos relevantes dos logs para um local seguro antes de realizar alterações, garantindo integridade para análises futuras.
2. Contenção contextual: Avalie o bloqueio do endereço IP de origem via firewall (como ufw, iptables ou grupos de segurança na nuvem) ou utilize ferramentas automatizadas como o Fail2ban, que bane temporariamente IPs após múltiplas falhas. Lembre-se de que o bloqueio de um IP é uma medida tática pontual, pois atacantes frequentemente alternam endereços.
3. Hardening do serviço SSH (/etc/ssh/sshd_config):

• Priorize chaves criptográficas: Configure a autenticação por par de chaves pública/privada e desabilite a autenticação por senha (PasswordAuthentication no) sempre que viável.
• Bloqueie o login direto do superusuário: Defina PermitRootLogin no para impedir ataques diretos à conta root.
• Restrinja a superfície de exposição: Limite o acesso à porta SSH apenas a IPs corporativos confiáveis, bastions ou redes VPN.
• Mantenha o sistema atualizado: Aplique correções de segurança regularmente nos pacotes do sistema e no OpenSSH.

10. Conclusão

Investigar tentativas suspeitas de acesso SSH não exige ferramentas complexas para começar — exige método, leitura atenta e compreensão do funcionamento do Linux. Ao dominar a localização dos logs e comandos essenciais como grep, tail e journalctl, você desenvolve a base analítica necessária para atuar na defesa de infraestruturas reais e evoluir sua carreira em cibersegurança.