Seu servidor Linux está seguro ou apenas funcionando?

Instalar um servidor, configurar um serviço e conseguir acessá-lo remotamente traz uma sensação muito boa.

O sistema iniciou. O SSH respondeu. A conexão funcionou.

Missão cumprida, certo?

Não necessariamente.

Um servidor pode estar funcionando perfeitamente e, ao mesmo tempo, possuir configurações inseguras, serviços expostos e permissões inadequadas. Essa é uma das primeiras lições que estou aprendendo ao montar meu próprio laboratório com Ubuntu Server.

Fazer funcionar é apenas o começo. O próximo passo é perguntar: quem consegue acessar, como esse acesso acontece e o que pode dar errado?

Funcionamento e segurança não são a mesma coisa

Quando um serviço responde corretamente, sabemos que sua configuração básica está operacional. Entretanto, isso não significa que ele esteja protegido.

Um servidor pode aceitar conexões SSH normalmente, mas ainda apresentar problemas como:

Autenticação apenas por senha;
Login direto como root;
Usuários desnecessários autorizados;
Número ilimitado de tentativas de acesso;
Serviços ativos que ninguém utiliza;
Portas abertas sem necessidade;
Permissões excessivas em arquivos;
Ausência de monitoramento dos logs.

Nenhum desses pontos impede necessariamente o funcionamento do servidor. É justamente por isso que podem permanecer esquecidos.

O sistema continua disponível, mas a superfície de ataque aumenta silenciosamente.

1. A autenticação por senha é suficiente?

Uma senha forte ainda é importante, mas depende do comportamento do usuário e pode ser alvo de tentativas automatizadas, reutilização de credenciais ou vazamentos.

No meu laboratório, configurei uma chave ED25519 para realizar o acesso SSH. Nesse modelo, existem duas partes:

A chave pública fica cadastrada no servidor;
A chave privada permanece protegida no computador do usuário.

O servidor verifica se quem está tentando entrar possui a chave privada correspondente. Essa abordagem reduz a dependência exclusiva de senhas.

Mas existe um cuidado importante: nunca devemos desativar o acesso por senha antes de testar a autenticação por chave em outra sessão. Uma alteração feita na ordem errada pode bloquear o próprio administrador.

Antes de restringir qualquer método de acesso, confirme que o método alternativo está realmente funcionando.

2. O usuário root precisa acessar remotamente?

O usuário root possui controle total sobre o sistema. Por isso, permitir seu acesso remoto direto aumenta o impacto de uma credencial comprometida.

Uma prática comum de segurança é utilizar uma conta administrativa individual e elevar privilégios somente quando necessário por meio do sudo.

No SSH, a diretiva abaixo pode impedir o login remoto direto como root:

PermitRootLogin no

A ideia não é eliminar a administração do sistema, mas evitar que a conta mais poderosa seja também o alvo mais óbvio.

Esse princípio está diretamente relacionado ao menor privilégio: cada usuário deve possuir apenas os acessos necessários para executar suas atividades.

3. Todos os usuários precisam acessar por SSH?

Em muitos ambientes, poucas contas realmente precisam realizar conexões remotas.

A diretiva AllowUsers permite informar quais usuários estão autorizados:

AllowUsers david

Também é possível limitar o número de tentativas de autenticação:

MaxAuthTries 3

Essas configurações não substituem outras camadas de segurança, mas ajudam a reduzir acessos desnecessários e tentativas repetidas.

Depois de alterar a configuração, é importante validar a sintaxe antes de reiniciar o serviço:

sudo sshd -t

Um pequeno erro no arquivo de configuração pode impedir novas conexões.

4. Permissões também fazem parte da segurança

Durante a configuração da autenticação por chave, validei as permissões do diretório .ssh e do arquivo authorized_keys.

Uma configuração comum é:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Esses números não são apenas detalhes técnicos.

A permissão 700 permite que somente o proprietário acesse o diretório .ssh. Já a permissão 600 permite que somente o proprietário leia e altere o arquivo authorized_keys.

Se outras pessoas puderem modificar esse arquivo, poderão adicionar novas chaves e conseguir acesso à conta.

Por isso, aplicar chmod 777 apenas para “resolver rapidamente” um problema pode criar outro muito maior. Quando concedemos permissão total para todos, também eliminamos parte do controle sobre o recurso.

5. Se o serviço não é utilizado, por que está ativo?

Cada serviço em execução representa uma funcionalidade, mas também pode representar uma nova possibilidade de falha.

Antes de manter um serviço ativo, vale perguntar:

Ele é realmente necessário?
Em qual porta está escutando?
Quem precisa acessá-lo?
Está atualizado?
Seus registros estão sendo acompanhados?

No Linux, podemos verificar portas em escuta com:

ss -lnt

O objetivo não é fechar tudo sem análise. É conhecer o que está exposto e manter apenas o necessário.

Um firewall também pode limitar quais conexões serão aceitas. Porém, ele não corrige senhas fracas, permissões inadequadas ou serviços vulneráveis. Segurança depende de camadas trabalhando juntas.

6. Um ataque deixa sinais — alguém está observando?

Impedir todos os incidentes é uma expectativa pouco realista. Por isso, além de proteger, precisamos detectar.

Tentativas repetidas de autenticação, conexões incomuns e alterações em arquivos podem aparecer nos registros do sistema.

Algumas perguntas importantes são:

Houve várias tentativas de acesso em pouco tempo?
Um usuário entrou em um horário incomum?
Algum serviço começou a apresentar falhas?
Uma configuração importante foi modificada?
O servidor está enviando dados para um destino inesperado?

Logs guardados, mas nunca analisados, possuem valor limitado.

Ferramentas de monitoramento e SIEM, como o Wazuh, podem centralizar eventos e ajudar na criação de alertas. Porém, antes da ferramenta, precisamos entender quais comportamentos desejamos identificar.

7. E se tudo falhar?

Mesmo com boas configurações, atualizações, firewall e monitoramento, incidentes ainda podem acontecer.

Nesse momento, surge outra pergunta:

Existe um backup ou existe um processo de recuperação testado?

Fazer uma cópia não garante que os dados poderão ser restaurados quando forem necessários.

É preciso verificar:

Onde o backup está armazenado;
Quem possui acesso;
Se ele também está protegido;
Quando ocorreu a última cópia;
Se a restauração já foi testada;
Quanto tempo a recuperação levaria.

Um backup nunca testado é apenas uma esperança.

Segurança não é uma configuração única

Não existe um comando capaz de transformar instantaneamente um servidor em um ambiente seguro.

Segurança é um processo contínuo:

Conhecer os ativos;
Reduzir serviços desnecessários;
Controlar acessos;
Corrigir vulnerabilidades;
Monitorar eventos;
Responder a comportamentos suspeitos;
Testar a recuperação;
Revisar tudo novamente.

Essa percepção mudou minha forma de estudar Linux.

Antes, meu objetivo era fazer o serviço funcionar. Agora, procuro entender também quais riscos uma configuração pode criar e como validar se as proteções foram realmente aplicadas.

Um checklist inicial

Ao terminar a instalação de um servidor Linux, podemos começar verificando:

O sistema está atualizado?
Apenas os serviços necessários estão ativos?
As portas abertas são conhecidas?
O acesso SSH utiliza chave?
O login remoto de root está bloqueado?
Apenas usuários autorizados conseguem acessar?
As permissões dos arquivos estão adequadas?
O firewall possui regras claras?
Os logs estão sendo monitorados?
O processo de recuperação foi testado?

Esse checklist não cobre todos os cenários, mas ajuda a substituir a pergunta “está funcionando?” por outra muito mais importante:

“Está funcionando da maneira mais segura que consigo validar?”

Estou construindo minha transição profissional para cibersegurança por meio de estudos, laboratórios e projetos envolvendo Linux, redes, segurança e preparação para SOC. Compartilho esse processo para consolidar meu aprendizado e trocar experiências com outras pessoas da área.

Agora quero deixar uma pergunta para você:

Qual é a primeira configuração de segurança que você verifica ao receber um servidor Linux?