Um sistema Linux acabado de instalar não é um sistema seguro. As distribuições de uso geral vêm com configurações pensadas para funcionar rapidamente, não para resistir a uma tentativa de intrusão. Reforçar a segurança do seu sistema Linux no dia a dia depende de algumas medidas específicas, repetidas regularmente, que reduzem a superfície de ataque sem transformar o seu computador numa fortaleza inutilizável.
Sandboxing do systemd: confinar cada serviço Linux individualmente
A maioria dos guias de segurança Linux fala sobre contas de utilizador e permissões de ficheiros. Menos abordado é o confinamento dos próprios serviços. Um servidor web ou um gestor de bases de dados costuma funcionar com permissões muito mais amplas do que as necessárias.
Já reparou que um serviço comprometido pode ler ficheiros sem qualquer relação com a sua função? É exatamente isso que o sandboxing do systemd corrige. Três diretivas fazem toda a diferença:
- ProtectSystem=strict monta o sistema de ficheiros raiz como só de leitura para o serviço em questão, impedindo qualquer alteração fora das pastas explicitamente autorizadas.
- PrivateTmp=true atribui ao serviço um diretório temporário isolado, invisível para os outros processos. Um atacante que aceda ao /tmp do serviço não consegue ver o do sistema.
- NoNewPrivileges=true impede qualquer escalada de privilégios após o arranque do serviço, mesmo que exista um binário setuid no caminho de execução.
Estas opções são configuradas no ficheiro unit do serviço, na secção [Service]. Após cada alteração, reinicie o serviço e verifique se está a funcionar normalmente. Uma diretiva demasiado restritiva pode bloquear o acesso legítimo a um socket ou ficheiro de configuração.
Para aprofundar esta abordagem e conhecer outros métodos de reforço da segurança, as recomendações de segurança da Hebdo Linux apresentam vários cenários adequados tanto a computadores pessoais como a servidores.
Verificar o estado real do SELinux e do AppArmor no seu sistema
Ter o SELinux ou o AppArmor instalado não significa que estes mecanismos estejam a proteger alguma coisa. Porque é que este aspeto é tantas vezes ignorado? Porque a presença de um módulo de segurança no kernel cria uma falsa sensação de proteção.
Um módulo de segurança inativo não protege nenhum processo. Numa distribuição como o Ubuntu, o AppArmor está presente por predefinição, mas nem todos os perfis estão no modo “enforce”. Alguns funcionam no modo “complain”, que apenas regista as violações sem as bloquear.
Comandos práticos de verificação
Para o AppArmor, o comando aa-status apresenta a lista de perfis carregados e o respetivo modo. Cada perfil no modo “complain” é uma porta aberta. Para o SELinux, sestatus indica se o modo é “enforcing”, “permissive” ou “disabled”.
Verificar estes estados é uma das verificações diárias mais úteis. Um script executado pelo cron ou por um timer do systemd pode enviar um alerta se o modo passar para permissive após um reinício ou uma atualização do kernel. Este tipo de regressão silenciosa é frequente durante as atualizações de versão.
Correções do Linux: verificar se a atualização está realmente ativa
Instalar uma correção não é suficiente. Após uma atualização do kernel, a máquina pode continuar a funcionar com o kernel antigo até ser reiniciada. O gestor de pacotes indica que está “atualizado”, mas o sistema continua vulnerável.
Verifique qual é o kernel ativo após cada atualização crítica. O comando uname -r apresenta a versão do kernel em execução. Compare-a com a versão mais recente instalada, visível no gestor de pacotes. Se forem diferentes, é necessário reiniciar.
Gestão de correções num servidor em produção
Num servidor, nem sempre é possível reiniciar de imediato. Registe a diferença entre o kernel instalado e o kernel ativo. Algumas distribuições oferecem um mecanismo de “live patching”, que aplica correções ao kernel sem reiniciar, mas este mecanismo não abrange todos os tipos de vulnerabilidade.
Um aspeto muitas vezes esquecido: as opções de arranque alternativas. Se o gestor de arranque mantiver kernels antigos, um reinício acidental com uma opção obsoleta volta a introduzir as falhas já corrigidas. Remova regularmente os kernels antigos da lista de arranque depois de confirmar a estabilidade do novo.
Reduzir diariamente a superfície de rede exposta
Cada porta aberta é um potencial ponto de entrada. Num computador Linux, serviços como o CUPS (impressão), o Avahi (descoberta de rede) ou um servidor SSH podem estar à escuta sem que se aperceba.
O comando ss -tlnp lista todas as portas à escuta e o processo associado. Analise a lista:
- Um serviço que não utiliza (o Avahi num computador sem impressora de rede, por exemplo) pode ser desativado com
systemctl disable --now, seguido do nome do serviço. - Um servidor SSH exposto na porta padrão (22) fica mais protegido com autenticação por chave pública em vez de palavra-passe. Desative a autenticação por palavra-passe em
/etc/ssh/sshd_configcomPasswordAuthentication no. - O firewall nftables (ou iptables, consoante a distribuição) deve definir uma política predefinida de rejeição do tráfego de entrada, com exceções explícitas apenas para os serviços necessários.
Menos serviços à escuta significa uma superfície de ataque menor para monitorizar. Esta verificação demora apenas alguns minutos e reduz consideravelmente o risco de exploração remota.
Proteger um sistema Linux não é uma tarefa pontual. Confinar os serviços, verificar se os módulos de segurança estão ativos, confirmar que as correções estão realmente em execução e fechar as portas desnecessárias formam um ciclo curto. Repetido todas as semanas, este ciclo cobre a maioria dos vetores de ataque comuns num computador ou servidor Linux.
