Tutorial de Linux / Proteja o servidor com firewall, contas e atualizações

Linux

Criado em 2026-10-30 Última atualização 2026-10-30

Proteger um servidor Linux combina contas e portas limitadas ao necessário, privilégios administrativos controlados, atualizações de segurança e um meio de recuperação. Antes de alterar o acesso remoto, mantenha a sessão atual e o acesso ao console; teste uma nova conexão após cada mudança.

Antes de alterar regras remotamente, confirme o acesso SSH e prepare a recuperação pelo console da máquina virtual, em inglês. Feche a sessão original somente depois de validar uma nova conexão.

As referências para a configuração são máquinas virtuais com instalações convencionais do Ubuntu 26.04 LTS ou Rocky Linux 9. Contêineres, WSL e outras versões podem ter serviços e pacotes diferentes. Anote as versões e teste o console de recuperação antes do exercício.

Inventarie a exposição e preserve o acesso de recuperação

id
getent group sudo
getent group wheel
sudo ss -lntup
systemctl --failed

O Ubuntu costuma usar o grupo sudo e o Rocky Linux o grupo wheel para administração, mas a política efetiva depende da configuração sudoers. Compare as portas em escuta com os serviços instalados e os usos legítimos. Depois de avaliar dependências, pare ou desative serviços desnecessários e permita somente o tráfego necessário. Grupos de segurança da nuvem e firewall do host são camadas distintas.

Teste um canal de recuperação independente do SSH, como o console da VM ou o console serial da nuvem. Registre o estado do firewall, a configuração SSH e as contas, e faça backup das configurações. Uma sessão existente continuar aberta não prova que novos logins são permitidos.

Valide o acesso por chave antes de alterar a política SSH

Em uma nova sessão com uma conta administrativa comum, teste a autenticação por chave e o uso de sudo. Antes de restringir senhas, examine os arquivos incluídos, blocos Match e configurações de provisionamento. Acrescentar diretivas repetidas pode produzir um resultado diferente do esperado.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E "^(port|permitrootlogin|passwordauthentication|pubkeyauthentication) "

sshd -t verifica a configuração e as chaves; -T mostra os valores efetivos. Se houver regras Match, teste o contexto de conexão relevante com -C. Depois de validar, recarregue a unidade correta da distribuição e teste um novo login. Se falhar, use a sessão mantida ou o console para restaurar o backup e validar novamente. Em instalações com ativação por socket, confira também o socket e a forma de aplicação da configuração apropriada à distribuição.

Permita o acesso de administração antes de ativar o UFW

Este exemplo de laboratório pressupõe que o SSH realmente use a porta TCP 22; se usar outra, substitua 22 pelo valor confirmado em todos os comandos. Restringir a origem pode ser adequado, mas um endereço de saída NAT ou VPN incorreto pode bloquear o acesso. Consulte o estado, acrescente a regra necessária e só então habilite o firewall.

sudo ufw status verbose
sudo ufw --dry-run allow 22/tcp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status numbered

Essa regra permite 22/tcp de todas as origens e não constitui uma política final para um servidor exposto à internet. Teste uma nova conexão; acrescente e valide antes qualquer regra mais restrita e retire a regra ampla somente depois que a substituta funcionar. Compare a lista numerada atual com o estado inicial e remova exclusivamente a regra desejada.

Diferencie zonas, runtime e configuração permanente no firewalld

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone

Identifique a zona aplicada à interface e ao tráfego de administração; regras por origem e outras políticas também podem afetar a seleção. Substitua REPLACE_WITH_ACTIVE_ZONE pela zona correta e consulte --info-service=ssh para confirmar se a definição corresponde à porta SSH real. Teste primeiro a alteração em runtime e salve permanentemente apenas a regra pretendida.

zone=REPLACE_WITH_ACTIVE_ZONE
sudo firewall-cmd --info-service=ssh
sudo firewall-cmd --zone="$zone" --add-service=ssh
sudo firewall-cmd --zone="$zone" --list-all
sudo firewall-cmd --permanent --zone="$zone" --add-service=ssh
sudo firewall-cmd --permanent --zone="$zone" --list-all

Os estados runtime e permanente são diferentes: um reload pode descartar alterações runtime não salvas. Copiar todo o estado runtime para a configuração permanente pode manter permissões temporárias sem intenção. Para desfazer, remova apenas as regras acrescentadas neste exercício e ausentes antes, em cada estado aplicável; preserve o acesso de administração até validar uma alternativa.

Mantenha as atualizações sem desativar o SELinux

sudo apt update
apt list --upgradable

sudo dnf check-update
getenforce

O primeiro bloco consulta o Ubuntu; o segundo, o Rocky Linux. dnf check-update pode retornar estado 100 quando há atualizações disponíveis, o que deve ser distinguido de uma falha genérica. Aplique atualizações depois de revisar backups, impacto nos serviços e necessidade de reinicialização. Em seguida, confira respostas dos serviços e o estado após reiniciar.

No Rocky Linux, o SELinux controla acesso por rótulos e políticas de processos. Se um serviço web não conseguir ler um arquivo, verifique permissões, rótulos e registros de auditoria antes de considerar mudanças de política. Caminhos fora dos diretórios padrão podem exigir regras persistentes de rotulagem e restorecon. SELinux e firewall aplicam restrições de tipos diferentes.

Referências oficiais

Linux