Questão de Segurança da Informação — Hardening — INSTITUTO AOCP 2026

Hardening de Servidores Linux

Gabarito: letra B. O hardening é o processo de reforço da segurança de um sistema por meio da redução de sua superfície de ataque, e a alternativa B contempla exatamente as práticas centrais recomendadas por frameworks como CIS Benchmarks: desabilitar serviços desnecessários, endurecer o SSH (desabilitar login de root e usar chave pública), aplicar patches de segurança, configurar firewall e ativar SELinux/AppArmor. As demais alternativas ou mantêm serviços inseguros, ou propõem medidas que aumentam o risco, ou contradizem as boas práticas de segurança.

O hardening, também chamado de fortalecimento de sistemas, é um processo contínuo que visa eliminar ou mitigar vulnerabilidades em servidores e estações de trabalho. Ele parte do princípio da superfície de ataque mínima: quanto menos serviços, portas, usuários e softwares desnecessários estiverem ativos, menores são as chances de um invasor encontrar uma brecha para explorar. O relatório da auditoria do IFCE apontou exatamente os problemas clássicos que o hardening combate: serviços inseguros em execução (FTP, Telnet, rpcbind), SSH com autenticação fraca (senha e root habilitado), falta de atualizações e permissões incorretas.

As boas práticas de hardening, alinhadas a frameworks como CIS Benchmarks e ao guia de segurança do próprio Linux, seguem uma lógica de defesa em profundidade: não basta corrigir um único ponto; é preciso aplicar camadas de proteção. Isso inclui:

• Redução da superfície de ataque: desabilitar e remover serviços que não são essenciais para a função do servidor. O FTP e o Telnet, por exemplo, transmitem dados e credenciais em texto claro, sendo extremamente vulneráveis a interceptação. O rpcbind é um serviço de mapeamento de portas que historicamente apresenta diversas vulnerabilidades.

• Endurecimento do acesso remoto: o SSH deve ser configurado para desabilitar o login direto do usuário root, forçando o uso de um usuário comum com escalonamento de privilégios via sudo. A autenticação por chave pública é amplamente superior à autenticação por senha, pois elimina o risco de ataques de força bruta e de senhas fracas ou vazadas.

• Gestão de patches: aplicar atualizações de segurança regularmente é fundamental para corrigir vulnerabilidades conhecidas. A ausência de atualizações por seis meses, como no caso do IFCE, deixa o sistema exposto a exploits já conhecidos e corrigidos pelos fabricantes.

• Configuração de firewall: o firewall deve ser configurado para permitir apenas o tráfego autorizado e necessário, bloqueando todo o resto. Isso limita o acesso à rede e impede que serviços não intencionais fiquem expostos.

• Ativação de mecanismos de segurança do kernel: SELinux (Security-Enhanced Linux) e AppArmor são módulos de segurança do kernel Linux que implementam controle de acesso obrigatório (MAC). Ativá-los em modo enforce (impondo as políticas) adiciona uma camada extra de proteção, limitando o que cada processo pode fazer, mesmo que uma aplicação seja comprometida.

A pegadinha central desta questão é que a banca mistura práticas corretas com práticas inseguras ou irrelevantes dentro de cada alternativa. O candidato precisa identificar o conjunto que é coerente com a lógica de segurança — não basta uma alternativa ter um item correto se ela também contém uma recomendação perigosa. A alternativa B é a única que apresenta um conjunto completo e consistente de boas práticas, atacando diretamente cada vulnerabilidade apontada no relatório da auditoria.

Alternativa A — ❌ Incorreta

Esta alternativa mantém o serviço de FTP ativo, o que é um erro grave. O FTP (File Transfer Protocol) transmite dados e credenciais em texto claro, sendo vulnerável a interceptação. A justificativa de que o FTP é "mais eficiente que o SCP" para transferência de logs internos é falsa e contrária às boas práticas de segurança. O SCP (Secure Copy) ou o SFTP (SSH File Transfer Protocol) são as opções seguras, pois utilizam criptografia. Além disso, a alternativa sugere manter a autenticação por senha no SSH, o que é uma prática fraca, mesmo com senhas complexas integradas ao PAM. A recomendação correta é usar autenticação por chave pública.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta alternativa descreve com precisão o conjunto de boas práticas de hardening para servidores Linux. Ela aborda diretamente cada vulnerabilidade apontada no relatório: desabilitar e remover serviços desnecessários (FTP, Telnet, rpcbind), configurar o SSH para desabilitar o login de root e usar autenticação por chave pública (em vez de senha), aplicar atualizações de segurança regularmente, configurar firewall para permitir apenas tráfego autorizado e ativar SELinux ou AppArmor em modo enforce. Todas essas ações são recomendadas por frameworks como CIS Benchmarks e constituem a base de um plano de hardening eficaz.

Alternativa C — ❌ Incorreta

Esta alternativa propõe substituir o firewall iptables por um NIDS (Network Intrusion Detection System) e desativar o SELinux. Isso é um erro conceitual: o firewall e o NIDS têm funções complementares, não substitutas. O firewall é um mecanismo de prevenção que bloqueia tráfego não autorizado, enquanto o NIDS é um mecanismo de detecção que monitora o tráfego em busca de atividades suspeitas. Desativar o SELinux para "evitar conflitos" é uma prática contrária à segurança, pois o SELinux é uma camada de proteção importante. A recomendação correta é manter o firewall ativo e o SELinux em modo enforce.

Alternativa D — ❌ Incorreta

Embora a criptografia de disco completo (FDE) seja uma boa prática de segurança, a alternativa contém erros graves. Aplicar patches "trimestralmente" é um intervalo muito longo para correções de segurança críticas; a recomendação é aplicar patches de segurança assim que disponíveis, ou pelo menos em um ciclo mensal. Além disso, manter permissões de execução ativas nos diretórios /tmp e /var/tmp é uma prática insegura, pois esses diretórios são mundialmente graváveis e frequentemente explorados por atacantes para armazenar e executar malware. A recomendação é montar esses diretórios com a opção noexec (não executar) para impedir a execução de binários a partir deles.

Alternativa E — ❌ Incorreta

Esta alternativa propõe centralizar a autenticação via LDAP transmitido em texto claro, o que é uma violação grave de segurança. O LDAP (Lightweight Directory Access Protocol) em texto claro expõe credenciais e dados de autenticação a interceptação na rede. A recomendação correta é usar LDAPS (LDAP sobre SSL/TLS) ou Kerberos, que criptografam a comunicação. Além disso, delegar privilégios administrativos temporários aos desenvolvedores, sem um controle rigoroso, contraria o princípio do menor privilégio e pode aumentar a superfície de ataque. A delegação de privilégios deve ser feita com mecanismos como sudo com políticas bem definidas e auditoria.

Gabarito: letra B