Um sistema Linux, mesmo considerado robusto, não está imunizado por padrão contra ataques. A segurança do Linux depende de um conjunto de configurações, regras de acesso e mecanismos de monitoramento que devem ser ativados e mantidos manualmente. Sem intervenção, um servidor ou uma estação recém-instalada expõe serviços desnecessários, portas abertas e contas com permissões excessivas.
Prioridade dos patches do kernel: o verdadeiro desafio da segurança do Linux
Os concorrentes repetem que é necessário atualizar o sistema. O conselho permanece válido, mas a realidade mudou. Em 2024, o kernel Linux registrou 3 108 CVE, um aumento de cerca de 79% em relação aos 1 736 CVE de 2023, segundo a base NVD do NIST.
Essa explosão não indica uma degradação do código. Ela resulta da melhoria das ferramentas de análise automatizadas, algumas das quais utilizam inteligência artificial para escanear as cerca de 40 milhões de linhas do kernel. Desde fevereiro de 2024, o kernel Linux se tornou sua própria autoridade de numeração CVE (CNA), o que acelera a declaração de cada vulnerabilidade detectada.
Para um administrador, aplicar cegamente cada patch publicado é como correr atrás de um fluxo quase contínuo de atualizações. A abordagem correta consiste em classificar os CVE por pontuação CVSS e pela exposição real do sistema. Uma vulnerabilidade crítica em um módulo de rede carregado em produção merece um patch imediato. Uma vulnerabilidade em um driver de hardware ausente da máquina pode esperar o próximo ciclo de manutenção.
Para acompanhar essas evoluções e entender seu impacto concreto, as informações de segurança no Hebdo Linux detalham regularmente os patches do kernel e os alertas associados às distribuições principais.
Redução da superfície de ataque em um servidor Linux
O hardening do sistema visa remover tudo o que não tem razão de existir na máquina. Cada serviço ativo, cada porta aberta e cada pacote instalado representa um ponto de entrada potencial para um atacante.
Serviços e pacotes desnecessários
Após uma instalação padrão, vários serviços estão em execução sem que ninguém os tenha solicitado: servidor de impressão (CUPS), Avahi para descoberta de rede local, ou ainda um agente de e-mail (Postfix, Exim). Em um servidor de produção, esses componentes não têm utilidade e ampliam a superfície de ataque. O comando systemctl list-unit-files –state=enabled permite identificar precisamente o que inicia automaticamente.
Desativar um serviço nem sempre é suficiente. Se o pacote permanecer instalado, uma reativação acidental ou uma exploração local ainda é possível. Remover o pacote inteiro é o método mais confiável.
Configuração de rede e firewall
Um firewall corretamente configurado é a primeira barreira entre a rede e os serviços internos. Nas distribuições mais recentes, nftables está substituindo gradualmente iptables. A lógica permanece a mesma: bloquear todo o tráfego de entrada por padrão e, em seguida, abrir apenas as portas necessárias.
- Permitir a porta 22 (SSH) apenas de endereços IP conhecidos, nunca de toda a internet.
- Fechar as portas relacionadas a bancos de dados (3306 para MySQL, 5432 para PostgreSQL) na interface pública e expô-las apenas na interface local ou em uma rede privada.
- Ativar o registro de pacotes rejeitados para detectar tentativas de varredura.
Controle de usuários e escalonamento de privilégios
A gestão das contas de usuários determina quem pode fazer o quê no sistema. Uma conta root usada diariamente continua sendo um dos erros mais comuns, inclusive em máquinas administradas por perfis técnicos.
Sudo deve substituir qualquer conexão direta como root. Cada comando executado via sudo é registrado com a identidade do usuário, criando um rastro de auditoria utilizável em caso de incidente. O arquivo /etc/sudoers permite restringir os comandos autorizados por usuário ou por grupo.
Além do sudo, módulos de controle de acesso obrigatório como SELinux (distribuições Red Hat, Fedora) ou AppArmor (Ubuntu, Debian) adicionam uma camada de restrição por processo. Mesmo que um atacante comprometa um serviço, o módulo impede o acesso a arquivos ou diretórios fora do escopo definido pela política de segurança.
- Aplicar o princípio do menor privilégio: cada usuário deve ter apenas os direitos necessários para sua tarefa.
- Desativar contas não utilizadas em vez de deixá-las inativas com uma senha fraca.
- Configurar uma expiração automática das senhas via chage para forçar uma renovação periódica.
- Verificar regularmente os arquivos /etc/passwd e /etc/group para identificar contas ou grupos inesperados.
Registro e detecção de comportamentos anormais no Linux
Um sistema pode ser comprometido por semanas sem que ninguém perceba se os logs não estiverem centralizados ou monitorados. O registro não serve apenas para análise pós-incidente: bem utilizado, ele permite detectar uma intrusão em andamento.
O registro do systemd (journalctl) centraliza os eventos do sistema, mas sua rotação padrão pode apagar rastros antes que sejam analisados. Exportar os logs para um servidor remoto (via rsyslog ou syslog-ng) garante que um atacante que tenha obtido acesso root não possa apagar seus próprios rastros localmente.
Para ir além, ferramentas como auditd permitem monitorar eventos específicos: modificação de um arquivo de configuração sensível, adição de um usuário, alteração de permissões em um diretório crítico. Cada regra de auditoria gera uma entrada com timestamp utilizável para reconstruir a cronologia de um incidente.
A combinação de um firewall rigoroso, controle de acesso granular e registro exportado cobre os três eixos da segurança do Linux: prevenção, restrição e detecção. Negligenciar um desses eixos é como deixar uma porta aberta, mesmo que os outros dois estejam trancados.
