O núcleo Linux agora corrige mais de 1.500 CVEs por versão principal, e as projeções para o Linux 7.3 se aproximam de 2.000 CVEs por release. Essa inflação, impulsionada por ferramentas de análise de código assistidas por IA, muda radicalmente o cenário para os administradores de sistema. Proteger um sistema Linux não se resume mais a ativar um firewall e executar um apt upgrade semanal: é um trabalho de triagem, priorização e arquitetura defensiva contínua.
Triagem dos CVEs do núcleo Linux: gerenciar a avalanche de correções
Entre as versões 6.9 e 6.19 do núcleo, a taxa girava em torno de 500 CVEs corrigidas por release. Desde o Linux 7.0, esse volume dobrou, depois triplicou. Os mantenedores afirmam estar “completamente sobrecarregados” pelo fluxo de relatórios gerados por ferramentas automatizadas.
Para um administrador, isso significa que o patching sistemático de cada CVE se tornou irrealista sem ferramentas de priorização. Aplicar todos os patches cegamente resulta em reiniciar os serviços continuamente, com risco de regressão funcional em cargas de produção.
Um score CVSS bruto de 7.5 em uma vulnerabilidade de rede não tem o mesmo impacto em um servidor isolado atrás de uma rede privada do que em uma máquina exposta em DMZ. Uma abordagem por score CVSS contextual permite priorizar os patches realmente críticos.
Ferramentas como KernelCare (patching ao vivo sem reinício) ou os fluxos OVAL fornecidos pelas distribuições filtram os CVEs aplicáveis à sua configuração real. Os recursos dedicados à segurança no Hebdo Linux complementam essa vigilância técnica de forma útil.
Configuração SSH e controle de acesso privilegiado no Linux
SSH continua sendo o vetor de ataque mais visado em servidores Linux expostos. A configuração padrão do OpenSSH na maioria das distribuições é funcional, mas não segura.
Parâmetros sshd_config a serem bloqueados prioritariamente
- PermitRootLogin no e desativação da autenticação por senha (PasswordAuthentication no): apenas a autenticação por chave Ed25519 ou ECDSA deve ser permitida em um servidor de produção
- Restrição dos algoritmos de criptografia a suítes modernas via KexAlgorithms e Ciphers, excluindo explicitamente diffie-hellman-group1-sha1 e CBC
- Ativação de AllowUsers ou AllowGroups para limitar o acesso SSH a uma lista nomeada de contas, em vez de depender apenas do firewall
- MaxAuthTries fixado em 3 e LoginGraceTime reduzido para 30 segundos para limitar a janela de força bruta
Gerenciamento da escalada de privilégios com sudo
A configuração do sudoers merece tanta atenção quanto o SSH. Um arquivo sudoers muito permissivo anula toda política de menor privilégio. Observa-se regularmente configurações onde uma conta de aplicativo possui ALL=(ALL) NOPASSWD: ALL, o que equivale a conceder acesso root permanente.
A boa prática consiste em criar aliases de comandos direcionados (Cmnd_Alias) para cada papel de aplicativo e registrar cada invocação sudo via syslog. Juntamente com auditd, isso fornece uma rastreabilidade completa das ações privilegiadas.
Redução da superfície de ataque de rede em um servidor Linux
Cada porta aberta e cada serviço ativo representa um ponto de entrada potencial. A redução da superfície de ataque começa com um inventário rigoroso.
O comando ss -tulnp (que substitui netstat) lista os sockets em escuta com o processo associado. Em um servidor web típico, apenas as portas 22, 80 e 443 devem aparecer. Todo serviço adicional (postfix, cups, avahi-daemon, rpcbind) deve ser desativado via systemctl disable se não for necessário, e então mascarado com systemctl mask para impedir uma reativação acidental.
Para filtragem de rede, nftables substituiu iptables como framework padrão nos núcleos recentes. Sua sintaxe declarativa por conjuntos (sets) e mapas (maps) simplifica a gestão de regras em grande escala. Uma política padrão de drop nas cadeias input e forward, com abertura explícita dos fluxos necessários, permanece a base.
Auditoria e registro: auditd, journald e detecção de intrusão no Linux
Sem registro centralizado, qualquer comprometimento permanece invisível até que os danos sejam constatados. O framework de auditoria do núcleo Linux (auditd) permite monitorar chamadas de sistema críticas com granularidade fina.
As regras a serem configuradas prioritariamente dizem respeito à monitorização de alterações em /etc/passwd, /etc/shadow, /etc/sudoers e nos arquivos de configuração SSH. Uma regra auditctl do tipo -w /etc/shadow -p wa -k shadow_changes registra qualquer escrita ou modificação de atributos no arquivo.
Para a detecção de intrusão em nível de arquivo, AIDE (Advanced Intrusion Detection Environment) gera uma impressão criptográfica da árvore de diretórios do sistema. Qualquer modificação não autorizada de um binário ou de um arquivo de configuração aciona um alerta na próxima varredura. Uma varredura diária via cron com envio do relatório por canal criptografado constitui um mínimo viável.
Journald, combinado com uma agregação remota (via systemd-journal-remote ou um coletor como rsyslog para um SIEM), permite correlacionar eventos entre vários servidores. Um atacante que compromete uma máquina tentará limpar os logs locais. O envio dos registros para um servidor de terceiros torna essa limpeza ineficaz.
Cyber Resilience Act e conformidade dos sistemas Linux na Europa
O Cyber Resilience Act (CRA) impõe aos editores de software comerciais, incluindo aqueles que integram componentes de código aberto, obrigações de monitoramento de vulnerabilidades e fornecimento de correções durante todo o ciclo de vida do produto. As primeiras obrigações de relatório entram em vigor em setembro de 2026.
Para as equipes que implantam Linux em ambientes profissionais, o CRA significa concretamente que a rastreabilidade dos componentes (SBOM, Software Bill of Materials) e a capacidade de demonstrar um processo de gerenciamento de correções se tornam requisitos regulatórios, não apenas boas práticas. As distribuições principais começaram a fornecer SBOMs utilizáveis, mas a responsabilidade pela conformidade permanece com a entidade que coloca o produto no mercado europeu.
A combinação de um núcleo que gera quase 2.000 CVEs por release e um quadro regulatório que exige uma gestão documentada de cada vulnerabilidade torna as ferramentas de live patching e automação da triagem não mais opcionais, mas estruturalmente necessárias para toda infraestrutura Linux em produção.
