Servidor Linux novo: primeiras 9 configurações de segurança essenciais

18 min de leitura  ·  Guia técnico

Configurações de segurança em servidor Linux novo são o conjunto de ajustes fundamentais que devem ser aplicados imediatamente após o provisionamento, antes de qualquer instalação de aplicação. Ignorar essa etapa deixa o servidor exposto a ataques automatizados que varrem a internet em minutos. Para proteger seu servidor Rocky Linux 9 recém-criado, siga estas etapas essenciais:

1. Atualizar todos os pacotes do sistema operacional
2. Criar usuário não-root com privilégios sudo
3. Desativar login root direto via SSH
4. Configurar autenticação por chave SSH e desativar senha
5. Ativar e configurar o firewall com firewalld
6. Instalar e configurar o Fail2Ban
7. Sincronizar o relógio com chrony (NTP)
8. Habilitar atualizações automáticas de segurança
9. Configurar limites de recursos e parâmetros do kernel

Pré-requisitos

• Acesso root inicial: credenciais root fornecidas pelo provedor no momento do provisionamento
• Sistema operacional: Rocky Linux 9 (os comandos são compatíveis com AlmaLinux 9 e, com pequenas adaptações, com Debian 12 e Ubuntu 24.04 LTS)
• Conexão SSH ativa: terminal local com cliente SSH instalado (OpenSSH, PuTTY ou similar)
• Par de chaves SSH gerado localmente: necessário antes de desativar autenticação por senha
• Acesso ao console de emergência do provedor: recomendado como fallback caso o acesso SSH seja perdido durante as configurações

Se você ainda não sabe como acessar seu servidor pela primeira vez, consulte o guia Acessando servidores VPS Linux da AviraHost antes de continuar.

1. Atualizar o sistema operacional: o ponto de partida obrigatório

A atualização completa dos pacotes é a primeira linha de defesa em qualquer servidor Linux recém-provisionado. Imagens de sistema operacional disponibilizadas por provedores frequentemente têm semanas ou meses de defasagem em relação aos repositórios oficiais, acumulando vulnerabilidades conhecidas com CVEs publicados.

Conecte-se ao servidor como root e execute:

dnf update -y && dnf upgrade -y

Output esperado:
Last metadata expiration check: ...
Dependencies resolved.
...
Complete!

Após a atualização, verifique se há novo kernel disponível e reinicie se necessário:

needs-restarting -r

Se o comando retornar código de saída 1, reinicie com reboot e aguarde o servidor voltar antes de continuar.

2. Criar usuário sudo e desativar root: hardening de acesso privilegiado

Operar diretamente como root é um risco desnecessário. Qualquer erro de digitação ou script malicioso executado nessa sessão tem permissão irrestrita sobre o sistema. Criar um usuário dedicado com privilégios sudo limita o raio de explosão de incidentes.

Crie o usuário e adicione ao grupo wheel (equivalente ao sudo no Rocky Linux 9):

useradd -m -s /bin/bash adminuser
passwd adminuser
usermod -aG wheel adminuser

Confirme que o usuário tem acesso sudo antes de prosseguir:

su - adminuser
sudo whoami

Output esperado:
root

Atenção: não feche a sessão root atual até confirmar que o novo usuário consegue executar comandos sudo com sucesso. Perder o acesso administrativo neste ponto exige intervenção pelo console de emergência do provedor.

Para referência sobre como trocar a senha root quando necessário, veja Como trocar a senha do usuário root do servidor VPS ou Dedicado.

3. Hardening de SSH: chaves criptográficas e desativação de senha

O hardening de SSH é o conjunto de ajustes no daemon sshd que reduz drasticamente a superfície de ataque do protocolo. Servidores com porta 22 aberta recebem tentativas de força bruta automatizadas em questão de minutos após o provisionamento — isso não é hipótese, é comportamento documentado e observável nos logs.

Primeiro, copie sua chave pública para o servidor a partir da sua máquina local:

ssh-copy-id adminuser@IP_DO_SERVIDOR

Ou manualmente no servidor:

mkdir -p /home/adminuser/.ssh
chmod 700 /home/adminuser/.ssh
echo "SUA_CHAVE_PUBLICA_AQUI" >> /home/adminuser/.ssh/authorized_keys
chmod 600 /home/adminuser/.ssh/authorized_keys
chown -R adminuser:adminuser /home/adminuser/.ssh

Agora edite o arquivo de configuração do SSH:

vi /etc/ssh/sshd_config

Localize e ajuste as seguintes diretivas:

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers adminuser

Atenção: ao mudar a porta SSH para 2222 (ou qualquer outra), libere essa porta no firewall antes de reiniciar o sshd. Caso contrário, você perderá o acesso remoto.

Reinicie o daemon:

systemctl restart sshd

Teste a conexão em uma nova janela de terminal antes de fechar a sessão atual:

ssh -p 2222 adminuser@IP_DO_SERVIDOR

4. Configurar firewalld: controle de tráfego de rede

Um servidor Linux recém-provisionado geralmente aceita conexões em todas as portas por padrão. O firewalld é o gerenciador de firewall padrão no Rocky Linux 9 e AlmaLinux 9, oferecendo uma interface de alto nível sobre nftables.

Verifique se o firewalld está ativo:

systemctl status firewalld

Se não estiver rodando, inicie e habilite:

systemctl enable --now firewalld

Configure as regras básicas — libere apenas o necessário:

firewall-cmd --permanent --remove-service=ssh
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Verifique as regras ativas:

firewall-cmd --list-all

Output esperado:
public (active)
  target: default
  ...
  ports: 2222/tcp
  services: http https
  ...

Para servidores que rodarão apenas aplicações web, bloqueie todo o restante. O comportamento padrão da zona public já rejeita conexões não listadas explicitamente.

5. Instalar Fail2Ban: proteção contra força bruta

O Fail2Ban monitora arquivos de log em tempo real e bane automaticamente endereços IP que apresentam comportamento suspeito — como múltiplas tentativas de autenticação falhas. É uma camada complementar ao hardening de SSH, especialmente útil para serviços como SSH, Nginx, Apache e Postfix.

Instale o Fail2Ban via repositório EPEL:

dnf install epel-release -y
dnf install fail2ban -y

Crie o arquivo de configuração local (nunca edite o jail.conf diretamente, pois é sobrescrito em atualizações):

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

Ajuste as configurações principais na seção [DEFAULT]:

[DEFAULT]
bantime  = 3600
findtime  = 600
maxretry = 5
backend = systemd

[sshd]
enabled = true
port    = 2222
logpath = %(sshd_log)s

Inicie e habilite o serviço:

systemctl enable --now fail2ban

Verifique o status das jails ativas:

fail2ban-client status sshd

Output esperado:
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  `- Total failed: 0
`- Actions
   |- Currently banned: 0
   `- Total banned: 0

6. Sincronização de tempo com chrony: NTP no Rocky Linux 9

A sincronização de tempo correta é frequentemente negligenciada em configurações iniciais, mas tem impacto direto na segurança. Certificados TLS podem ser rejeitados, logs ficam com timestamps incorretos dificultando análise forense, e ferramentas de autenticação baseadas em tempo (como TOTP/2FA) falham completamente quando o relógio do servidor está desalinhado.

No Rocky Linux 9, o chrony é o cliente NTP padrão e geralmente já vem instalado. Verifique:

systemctl status chronyd

Se não estiver instalado:

dnf install chrony -y
systemctl enable --now chronyd

Confirme a sincronização:

chronyc tracking

Output esperado:
Reference ID    : ...
Stratum         : 2
...
System time     : 0.000XXXXXX seconds fast of NTP time
...

Para verificar as fontes NTP em uso:

chronyc sources -v

7. Habilitar atualizações automáticas de segurança

Manter o sistema atualizado manualmente é inviável a longo prazo. O pacote dnf-automatic permite configurar atualizações automáticas de segurança, garantindo que patches críticos sejam aplicados sem intervenção manual.

dnf install dnf-automatic -y

Edite o arquivo de configuração:

vi /etc/dnf/automatic.conf

Ajuste as seguintes opções:

[commands]
upgrade_type = security
apply_updates = yes

[emitters]
emit_via = stdio

Habilite o timer systemd:

systemctl enable --now dnf-automatic.timer

Verifique se o timer está agendado:

systemctl list-timers dnf-automatic.timer

8. Configurar limites de recursos e parâmetros de kernel (sysctl)

Ajustes no kernel via sysctl fortalecem a postura de segurança do servidor ao desativar funcionalidades raramente necessárias em servidores de produção, mas frequentemente exploradas em ataques. Esta etapa de hardening de sistema operacional complementa as configurações de rede e acesso.

Crie um arquivo de configuração dedicado:

vi /etc/sysctl.d/99-security.conf

Adicione os seguintes parâmetros:

net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
fs.suid_dumpable = 0

Atenção: se o servidor for usado como roteador ou precisar de IP forwarding (por exemplo, para Docker com redes bridge), mantenha net.ipv4.ip_forward = 1. Altere apenas o que se aplica ao seu caso de uso.

Aplique as configurações imediatamente:

sysctl -p /etc/sysctl.d/99-security.conf

9. Configurar auditoria de sistema com auditd

O auditd é o daemon de auditoria do kernel Linux, responsável por registrar eventos de segurança como acesso a arquivos sensíveis, execução de comandos privilegiados e modificações em configurações críticas. Em ambientes de produção, logs de auditoria são essenciais para análise forense e conformidade.

Verifique se o auditd está instalado e ativo:

systemctl status auditd

No Rocky Linux 9, o auditd geralmente já vem instalado. Se necessário:

dnf install audit -y
systemctl enable --now auditd

Adicione regras básicas de auditoria para monitorar arquivos críticos:

auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/shadow -p wa -k identity
auditctl -w /etc/sudoers -p wa -k sudoers
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config

Para tornar as regras persistentes, adicione-as ao arquivo:

vi /etc/audit/rules.d/security.rules

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd_config

Recarregue as regras:

augenrules --load

Para consultar eventos registrados:

ausearch -k sshd_config

Para aprofundar as configurações do servidor após o hardening inicial, consulte também as Dicas de Otimização de Servidores Linux disponíveis na base de conhecimento.

Problemas comuns e como resolver

Sintoma: acesso SSH bloqueado após alterar a porta ou desativar senha

Causa: a nova porta SSH não foi liberada no firewall antes de reiniciar o sshd, ou a chave pública não foi copiada corretamente para o servidor.
Solução: acesse o servidor pelo console de emergência do provedor (KVM/VNC). Verifique se a porta está liberada com firewall-cmd --list-ports. Confirme que o arquivo authorized_keys tem permissão 600 e pertence ao usuário correto com ls -la /home/adminuser/.ssh/. Corrija as permissões com chmod 600 /home/adminuser/.ssh/authorized_keys e reinicie o sshd.

Sintoma: Fail2Ban não está banindo IPs mesmo com muitas tentativas falhas

Causa: o backend configurado não corresponde ao sistema de logging em uso. No Rocky Linux 9 com systemd, o backend deve ser systemd, não auto ou polling.
Solução: edite /etc/fail2ban/jail.local e defina backend = systemd na seção [DEFAULT]. Reinicie o serviço com systemctl restart fail2ban e verifique os logs com journalctl -u fail2ban -f.

Sintoma: chrony não sincroniza e exibe "No suitable source available"

Causa: o servidor não tem acesso à internet na porta UDP 123, ou as fontes NTP configuradas estão inacessíveis.
Solução: verifique se a porta 123/UDP está liberada no firewall com firewall-cmd --list-all. Teste conectividade com chronyc ntpdata. Se necessário, adicione servidores NTP alternativos em /etc/chrony.conf, como pool br.pool.ntp.org iburst, e reinicie o chronyd.

Sintoma: dnf-automatic não aplica atualizações automaticamente

Causa: o timer systemd não está habilitado, ou a opção apply_updates está definida como no no arquivo de configuração.
Solução: confirme o status do timer com systemctl status dnf-automatic.timer. Verifique o arquivo /etc/dnf/automatic.conf e certifique-se de que apply_updates = yes. Habilite o timer com systemctl enable --now dnf-automatic.timer.

Sintoma: sysctl retorna "No such file or directory" ao aplicar configurações

Causa: o parâmetro especificado não existe no kernel em execução, possivelmente porque o módulo de rede correspondente não está carregado.
Solução: identifique o parâmetro problemático no output do comando. Verifique se o módulo necessário está carregado com lsmod. Remova ou comente o parâmetro incompatível do arquivo /etc/sysctl.d/99-security.conf e execute novamente sysctl -p.

Perguntas frequentes sobre configurações de segurança em servidor Linux novo

Qual é a primeira coisa a configurar em um servidor Linux novo?

A primeira ação deve ser atualizar todos os pacotes do sistema operacional para fechar vulnerabilidades conhecidas. Em seguida, crie um usuário não-root com privilégios sudo e desative o login direto como root via SSH — isso elimina o vetor de ataque mais explorado em servidores expostos à internet. Essas duas etapas juntas formam a base sobre a qual todas as demais configurações de segurança são construídas.

Como desativar o login root via SSH no Rocky Linux 9?

Edite o arquivo /etc/ssh/sshd_config e altere a diretiva PermitRootLogin para no. Depois reinicie o daemon com systemctl restart sshd. Antes de fazer isso, certifique-se de que existe um usuário sudo funcional na sessão atual para não perder o acesso ao servidor. Teste sempre a conexão com o novo usuário em uma janela de terminal separada antes de encerrar a sessão root.

É obrigatório configurar firewall em um VPS Linux novo?

Sim. Um VPS recém-provisionado geralmente aceita conexões em todas as portas por padrão. Sem um firewall ativo — firewalld, nftables ou UFW — qualquer serviço que suba na máquina fica imediatamente exposto à internet. Configure o firewall antes de instalar qualquer aplicação, liberando apenas as portas estritamente necessárias para o funcionamento dos serviços planejados.

O que é hardening de SSH e por que é importante?

Hardening de SSH é o conjunto de ajustes no daemon sshd que reduzem a superfície de ataque do protocolo: desativar autenticação por senha, usar apenas chaves criptográficas, mudar a porta padrão 22, limitar usuários autorizados e definir tempo máximo de sessão inativa. Esses ajustes bloqueiam a grande maioria dos ataques de força bruta automatizados que varrem a internet continuamente, tornando o acesso remoto significativamente mais seguro sem comprometer a usabilidade.

Preciso configurar NTP em um servidor Linux novo?

Sim. Sem sincronização de tempo correta, certificados TLS podem ser rejeitados, logs ficam com timestamps incorretos e ferramentas de autenticação baseadas em tempo (como TOTP) falham. No Rocky Linux 9 e AlmaLinux 9, o chrony é o cliente NTP padrão e já vem instalado — basta verificar se está ativo com systemctl status chronyd. A sincronização de tempo é um requisito silencioso que afeta múltiplas camadas de segurança e operação do servidor.

Conclusão

• Execute as 9 configurações em sequência: cada etapa depende da anterior — não pule a criação do usuário sudo antes de desativar o root, e não desative a autenticação por senha antes de confirmar que as chaves SSH funcionam.
• Documente cada alteração feita: registre a porta SSH escolhida, o nome do usuário administrativo criado e as regras de firewall aplicadas. Essa documentação é essencial para troubleshooting futuro e para replicar a configuração em novos servidores.
• Revise periodicamente: hardening não é uma tarefa única. Revise as configurações de segurança a cada atualização maior do sistema operacional, verifique os logs do Fail2Ban regularmente e mantenha o auditd ativo para rastreabilidade de eventos críticos.

Leia também

• Otimizar a Segurança do SSH em VPS Linux e Servidor Dedicado: Passos Essenciais
• Solucionar problemas de bloqueio de IP por fail2ban em VPS Linux e servidor dedicado
• Checklist para Segurança de VPS Linux: Guia Completo de Proteção

Precisa de ajuda com segurança no seu servidor Linux?

Configurar um servidor Linux seguro do zero exige atenção a detalhes que podem passar despercebidos, especialmente sob pressão de prazo. Os planos de VPS da AviraHost incluem suporte técnico especializado para auxiliar nas configurações iniciais e garantir que seu ambiente esteja protegido desde o primeiro acesso.

Conheça os planos de VPS Linux da AviraHost