Como saber se alguém entrou no seu servidor sem permissão?

Publicado em 2026-10-17 por frfrand

Señales de intrusión en Linux, cambios sospechosos, registros que revisar y qué hacer sin destruir evidencias.

Seu site continua funcionando, o domínio abre e ninguém reclamou. Isso prova que seu servidor está seguro? Não necessariamente. Algumas invasões interrompem tudo; outras tentam passar despercebidas.

Saber se alguém entrou sem permissão consiste em buscar sinais, contrastá-los e determinar o que aconteceu. Não existe um único comando que garanta que o sistema nunca foi comprometido.

Quais são os sinais mais comuns?

Uma das primeiras pistas são os acessos que ninguém reconhece. Por exemplo, uma sessão administrativa iniciada de um local inesperado ou em um horário em que ninguém da equipe estava trabalhando.

Outra pista são usuários novos ou permissões alteradas. Se aparecer uma conta que sua equipe não criou, ou um aplicativo obtém permissões que não precisava, merece uma revisão.

Também podem aparecer processos desconhecidos consumindo CPU, conexões de saída estranhas, tarefas agendadas novas, arquivos modificados sem motivo ou alertas de segurança do provedor.

Mas cuidado: cada um desses sinais tem explicações legítimas. Um pico de CPU pode ser um backup. Um acesso de outro IP pode ser alguém usando uma VPN. O importante é investigar, não assumir.

Por onde começar no Linux?

Se você tem uma suspeita, o primeiro é evitar mudanças impulsivas. Antes de reiniciar ou excluir arquivos, reúna informações sobre o que aconteceu e quando.

Em um sistema com permissões adequadas, você pode começar com perguntas como estas:

• Quais pessoas deveriam ter acesso administrativo?
• Usuários, chaves SSH ou tarefas agendadas foram criados recentemente?
• Quais aplicativos e processos deveriam estar ativos?
• Há conexões ou destinos de rede que o serviço não precisa?
• Os registros mostram falhas repetidas de autenticação ou logins inesperados?

No Ubuntu, os registros de autenticação podem aparecer nos arquivos do sistema ou no journal, dependendo da configuração. Ferramentas como journalctl e last podem ajudar a reconstruir a atividade, mas não são uma prova definitiva. Um atacante com privilégios elevados poderia ter manipulado registros locais.

Um exemplo simples

Imagine um VPS que executa um site e um banco de dados. De repente, o processador permanece a 100% durante a madrugada e aparece um processo com um nome que a equipe desconhece.

Não significa automaticamente que haja um atacante. Primeiro compare o processo com implantações recentes, tarefas agendadas e software instalado. Se não houver uma explicação válida, investigue sua origem e conexões.

Se, além disso, você encontrar uma chave SSH desconhecida adicionada a uma conta privilegiada, o nível de suspeita aumenta muito. Sinais combinados costumam ser mais úteis que uma única anomalia.

O que fazer se acreditar que o servidor está comprometido?

A prioridade é conter o risco sem destruir evidências. Dependendo do impacto, pode ser necessário isolar a máquina de certos acessos, preservar registros e capturar informações úteis antes de excluir processos.

Em uma empresa, o adequado é ativar um plano de resposta a incidentes ou buscar ajuda especializada. Alterar senhas de um computador possivelmente comprometido ou restaurar sem investigar pode deixar o problema ativo.

Depois é preciso revisar credenciais, tokens, chaves de serviço, outros sistemas relacionados e possíveis vazamentos. Uma recuperação confiável pode exigir reconstruir a máquina a partir de uma imagem limpa e restaurar dados verificados, não simplesmente excluir um arquivo suspeito.

Como reduzir a possibilidade de que aconteça novamente?

Aplique atualizações, limite privilégios e acessos, use autenticação forte, revise serviços expostos e mantenha backups testados. Também convém centralizar registros importantes fora da própria máquina para que uma invasão não os apague facilmente.

Como se relaciona com ArduMaker?

Os VPS gerenciados na ArduMaker também executam processos, contas e serviços que convém supervisionar. O painel pode facilitar a operação, mas não substitui as boas práticas de acesso, revisão e resposta a incidentes.

Em uma frase: para saber se alguém entrou no seu servidor, você precisa comparar a atividade real com o que deveria estar acontecendo. Não se trata de procurar uma tela vermelha que diga «hackeado», mas de investigar provas e agir com ordem.

Referência: Guia de resposta a ransomware da CISA.