Auditoria de Conformidade no Linux com Lynis e CIS Benchmarks: Guia Prático 2026
Guia prático para auditar conformidade no Linux com Lynis 3.1.3 e CIS Benchmarks em Ubuntu 24.04, RHEL 9, Debian 12 e Rocky 10. Inclui instalação, leitura do Hardening Index, automação via systemd e integração com Prometheus, Wazuh e Elastic Stack.
A auditoria de conformidade no Linux com Lynis e CIS Benchmarks é o processo de medir, automaticamente, o quanto a configuração de um servidor se afasta das recomendações de segurança publicadas pelo Center for Internet Security (CIS) e pela comunidade Lynis. Na prática, você instala o Lynis 3.1.x, executa lynis audit system, lê o "Hardening Index" e aplica os controles do CIS Benchmark correspondente à sua distribuição (Ubuntu 24.04, RHEL 9, Debian 12 ou Rocky 10) até atingir a pontuação mínima exigida pela sua política interna ou pela norma (PCI-DSS 4.0, ISO 27001, LGPD, SOC 2).
Lynis 3.1.3 (abril de 2026) traz suporte completo a Ubuntu 24.04 LTS, RHEL 9, Rocky 10, AlmaLinux 10 e openSUSE Leap 15.6, com mais de 300 testes automatizados.
O CIS Benchmark é a referência de fato para hardening regulado; cada controle tem um nível (L1 ou L2) e um perfil (Server ou Workstation) que deve ser escolhido conforme o caso de uso.
Um Hardening Index acima de 75 já indica postura defensiva sólida; abaixo de 60 é sinal claro de configuração padrão sem ajustes.
Lynis cobre auditoria contínua e leve (sem agente), enquanto OpenSCAP/SCAP Security Guide fornecem perfis SCAP oficiais alinhados a STIG, HIPAA e PCI-DSS.
Automação com cron, systemd timers e exportação para o Wazuh ou para o Elastic Stack transforma a auditoria pontual em monitoramento de conformidade contínuo.
A combinação Lynis + OpenSCAP + Auditd cobre os três pilares: avaliação de configuração, remediação guiada por SCAP e trilha de auditoria forense.
O que é o Lynis e por que ele importa em 2026?
Lynis é uma ferramenta de auditoria de segurança open source mantida pela CISOfy, escrita em shell puro e distribuída sob licença GPLv3. Ela executa centenas de testes locais (sem agente residente, sem banco de dados, sem dependências exóticas) e produz dois artefatos: um relatório legível em /var/log/lynis-report.dat e um log detalhado em /var/log/lynis.log. Em 2026, o projeto está na versão 3.1.3, lançada em abril, e adicionou testes específicos para systemd-homed, nftables, WireGuard e contêineres Podman rootless.
O que torna o Lynis especialmente útil para times pequenos é a relação custo-benefício. Você executa lynis audit system em um servidor de produção e, em menos de dois minutos, recebe uma lista priorizada de sugestões com referências cruzadas a CIS, NIST SP 800-53 e ISO 27001. Honestamente, eu uso o Lynis há anos como primeiro passo de qualquer hardening (antes mesmo de abrir o CIS Benchmark) porque ele evidencia rapidamente os pontos óbvios que ferramentas SCAP, mais formais, podem demorar a destacar.
É importante entender o que o Lynis não faz: ele não corrige nada automaticamente. A escolha foi deliberada, e faz sentido. Remediação automática em servidores legados é uma das principais causas de incidentes pós-hardening. Para remediação dirigida por playbooks, combine o Lynis com Ansible, Bash idempotente ou OpenSCAP Remediation. A combinação com a estratégia de hardening de AppArmor no Ubuntu e Debian fecha bem o ciclo: AppArmor confina processos, e o Lynis valida que os perfis estão ativos.
O que é um CIS Benchmark para Linux?
O CIS Benchmark é um documento técnico publicado pelo Center for Internet Security que descreve, controle por controle, como endurecer um sistema operacional ou aplicação. Cada controle tem um identificador (por exemplo, "1.1.1.1 Ensure mounting of cramfs filesystems is disabled"), um nível de aplicação (L1 ou L2) e um perfil (Server ou Workstation). Em 2026, os benchmarks mais consultados pela comunidade Linux são:
CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0 (publicado em janeiro de 2026).
CIS Red Hat Enterprise Linux 9 Benchmark v2.1.0 (revisão de março de 2026).
CIS Debian Linux 12 Benchmark v1.1.0.
CIS Rocky Linux 10 Benchmark v1.0.0.
CIS Distribution Independent Linux Benchmark v3.0.0, usado quando você roda algo como Arch, Gentoo ou uma distro derivada que não tem benchmark oficial.
A distinção entre Level 1 e Level 2 importa muito. L1 é o mínimo defensável: configurações que reduzem superfície de ataque sem quebrar funcionalidade típica de produção. L2 endurece de forma mais agressiva (desativa USB, bloqueia compiladores, restringe sudo a um conjunto mínimo) e tipicamente exige análise de impacto. Aplicar L2 cegamente em um servidor de build ou em uma workstation de DevOps é receita para chamados infinitos no suporte. Você pode ler a íntegra dos benchmarks diretamente no site do Center for Internet Security após cadastro gratuito.
Como instalar o Lynis no Ubuntu 24.04, RHEL 9 e Debian 12
O Lynis está em quase todos os repositórios oficiais, mas as versões empacotadas costumam ficar 6 a 12 meses atrás. Para auditoria séria, instale a versão upstream da CISOfy. Ela é assinada com GPG e está sempre atualizada.
Ubuntu 24.04 LTS e Debian 12
# Adicionar repositório oficial CISOfy
wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | \
sudo gpg --dearmor -o /usr/share/keyrings/cisofy.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/cisofy.gpg] \
https://packages.cisofy.com/community/lynis/deb/ stable main" | \
sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt update
sudo apt install -y lynis
# Verificar versão
lynis show version
# Saída esperada (junho/2026): 3.1.3
RHEL 9, Rocky Linux 10 e AlmaLinux 10
sudo tee /etc/yum.repos.d/cisofy-lynis.repo <<'EOF'
[lynis]
name=CISOfy Software - Lynis package
baseurl=https://packages.cisofy.com/community/lynis/rpm/
enabled=1
gpgkey=https://packages.cisofy.com/keys/cisofy-software-rpms-public.key
gpgcheck=1
EOF
sudo dnf install -y lynis
lynis show version
Executando a primeira auditoria e lendo o Hardening Index
A auditoria padrão é uma única linha de comando, mas a leitura do resultado é onde a maioria dos administradores erra. Execute como root para que o Lynis acesse /etc/shadow, módulos do kernel e configurações de PAM:
sudo lynis audit system --quick --no-colors --report-file /var/log/lynis-report.dat
# Para auditoria mais detalhada com saida no formato cron-friendly:
sudo lynis audit system --cronjob --auditor "DevSecOps Team" \
--report-file /var/log/lynis-report-$(date +%Y%m%d).dat
Ao final, o Lynis exibe três métricas críticas:
Hardening index (0 a 100): quanto maior, melhor. 70 é aceitável, 80+ é bom, 90+ é excelente.
Tests performed: tipicamente 250 a 320 testes em servidor padrão.
Suggestions e Warnings: a lista priorizada de ações.
Para extrair apenas os pontos acionáveis do relatório:
# Listar todas as sugestoes
grep "suggestion\[\]=" /var/log/lynis-report.dat | cut -d= -f2-
# Listar avisos criticos
grep "warning\[\]=" /var/log/lynis-report.dat
# Pegar apenas o indice de hardening
grep "hardening_index=" /var/log/lynis-report.dat
Como aplicar controles do CIS Benchmark na prática
Aplicar um CIS Benchmark inteiro de uma vez quebra servidores. A abordagem que funciona é dividir os controles em ondas. Em projetos reais, organizamos da seguinte forma.
Onda 1: controles de filesystem e módulos do kernel (L1)
São controles seguros, raramente quebram serviços e geram ganho imediato no índice Lynis. Por exemplo, desativar módulos de filesystem legados:
Configure regras de auditoria alinhadas ao CIS 4.1.x:
# /etc/audit/rules.d/cis.rules (extrato CIS RHEL9 v2.1.0)
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d/ -p wa -k scope
-w /var/log/sudo.log -p wa -k actions
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k privileged-elevation
# Recarregar
sudo augenrules --load
sudo systemctl restart auditd
Para o SSH, o controle CIS 5.2.x cobre mais de 20 parâmetros. Não vou repetir aqui o que já trabalhamos no guia completo de hardening SSH com OpenSSH 10, mas vale destacar que o Lynis cobra MaxAuthTries 4, ClientAliveInterval 300, LoginGraceTime 60 e a desativação explícita de HostbasedAuthentication.
Onda 3: políticas de senha, sudo e MFA
Aqui entram controles mais sensíveis: força de senha via pwquality, bloqueio após tentativas falhas com pam_faillock, e exigência de senha para sudo (CIS 5.3.4). Esses controles podem deixar usuários trancados se houver erro de digitação no PAM stack, então sempre teste em VM antes. Já vi um time inteiro perder acesso SSH a um cluster por causa de uma vírgula trocada no system-auth. Não é experiência que se queira repetir.
Lynis vs OpenSCAP: qual escolher?
Essa é a pergunta que mais aparece em projetos de conformidade. A resposta curta: use os dois. A longa está na tabela abaixo.
Critério
Lynis 3.1.3
OpenSCAP 1.4 / SCAP Security Guide
Modelo de execução
Shell script, sem agente, sem servidor
CLI + biblioteca C, perfis XCCDF/OVAL
Cobertura SCAP oficial
Não (referencia CIS/NIST de forma textual)
Sim, com perfis assinados para PCI-DSS, STIG, HIPAA, CUI
Remediação automática
Não
Sim, gera scripts Bash/Ansible/Puppet
Curva de aprendizado
Baixa, uma linha de comando
Média (perfis, customização XML, datastreams)
Tempo de execução
1 a 3 minutos
3 a 15 minutos por perfil
Ideal para
Auditoria contínua, primeiro hardening, contêineres
Conformidade regulatória formal, relatórios para auditores
Saída para SIEM
Texto plano + JSON parseável
HTML, XML, ARF (Asset Reporting Format)
No fluxo que recomendo, o Lynis roda diariamente via cron como termômetro de saúde, e o OpenSCAP roda semanalmente com o perfil específico da norma (ex.: xccdf_org.ssgproject.content_profile_pci-dss). Quando o auditor pede o ARF assinado, você gera com OpenSCAP; quando o time interno quer saber "ainda estamos bem hoje?", consulta o painel alimentado pelo Lynis. Para mais detalhes sobre datastreams, consulte o projeto ComplianceAsCode (SCAP Security Guide).
Como automatizar a auditoria de conformidade
Auditoria que roda só na véspera da certificação é teatro. Para ter conformidade contínua, agende o Lynis e exporte o índice para um sistema central. A forma mais limpa em 2026 é usar um systemd timer com dependência de unidade, em vez de cron.
# /etc/systemd/system/lynis-audit.service
[Unit]
Description=Auditoria diaria de conformidade Lynis
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/lynis audit system --cronjob --quiet \
--report-file /var/log/lynis/report-%%Y%%m%%d.dat
ExecStartPost=/usr/local/bin/lynis-export-prometheus.sh
Nice=19
IOSchedulingClass=idle
# /etc/systemd/system/lynis-audit.timer
[Unit]
Description=Executar Lynis todo dia as 03:30
[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=900
Persistent=true
[Install]
WantedBy=timers.target
Ative com sudo systemctl enable --now lynis-audit.timer. O hook ExecStartPost aponta para um pequeno script que extrai o Hardening Index e o expõe ao Prometheus via node_exporter textfile collector:
#!/usr/bin/env bash
# /usr/local/bin/lynis-export-prometheus.sh
set -euo pipefail
REPORT="/var/log/lynis-report.dat"
OUT="/var/lib/node_exporter/textfile_collector/lynis.prom"
INDEX=$(awk -F= '/^hardening_index=/{print $2}' "$REPORT")
WARNINGS=$(grep -c '^warning\[\]=' "$REPORT" || true)
SUGGESTIONS=$(grep -c '^suggestion\[\]=' "$REPORT" || true)
cat > "$OUT" <<EOF
# HELP lynis_hardening_index Hardening index from last Lynis run (0-100)
# TYPE lynis_hardening_index gauge
lynis_hardening_index ${INDEX:-0}
# HELP lynis_warnings_total Total Lynis warnings
# TYPE lynis_warnings_total gauge
lynis_warnings_total ${WARNINGS}
# HELP lynis_suggestions_total Total Lynis suggestions
# TYPE lynis_suggestions_total gauge
lynis_suggestions_total ${SUGGESTIONS}
EOF
Com isso, o Grafana mostra a evolução do índice ao longo do tempo, e você pode criar alertas (Alertmanager) para quando o índice cair abaixo de 75 ou quando o número de warnings aumentar, sinal claro de drift de configuração.
Integração com SIEM e relatórios para auditores
O relatório bruto do Lynis (.dat) é texto chave=valor, o que facilita a ingestão em SIEMs. Para o Wazuh, basta um decoder customizado em /var/ossec/etc/decoders/local_decoder.xml. Para o Elastic Stack, use Filebeat com um pipeline de ingestão que faz parse de cada linha. Esse padrão se encaixa bem com o que cobrimos no artigo sobre detecção de intrusões com Wazuh, Auditd e Osquery, fechando o ciclo entre postura preventiva e detectiva.
Para o auditor humano, o ideal é gerar um PDF executivo a partir do relatório. O lynis-report-converter (Perl, mantido na comunidade) converte o .dat em HTML, e qualquer ferramenta como wkhtmltopdf ou weasyprint finaliza o PDF. Em organizações reguladas, eu costumo anexar três coisas ao pacote de auditoria: o relatório Lynis bruto, o ARF assinado do OpenSCAP, e um sumário executivo com a evolução do índice nos últimos 90 dias. Quem prefere referência canônica encontra o detalhamento no manual oficial do Lynis (CISOfy).
Erros comuns ao seguir o CIS Benchmark
Vejo os mesmos erros se repetirem em quase todo projeto de conformidade:
Aplicar L2 em todos os servidores. L2 é para hosts de alta sensibilidade. Em servidor de build com compiladores, L2 quebra a esteira.
Forçar noexec em /tmp sem mapear consequências. Alguns instaladores (npm, pip, apt hooks) escrevem e executam em /tmp. Use noexec em /var/tmp primeiro e monitore antes de avançar.
Desativar IPv6 globalmente. O CIS exige justificativa por escrito quando IPv6 não é usado. Desativar quebra localhost em algumas aplicações Java/Node.
Não testar o PAM stack em VM. Um erro em /etc/pam.d/system-auth tranca o root. Sempre mantenha uma sessão TTY de root aberta enquanto edita PAM.
Aceitar o CIS sem mapear exceções. Toda exceção precisa de risk acceptance documentado, ou a próxima auditoria gera ressalvas.
Esquecer de versionar os arquivos de exceção. Use Git para /etc (etckeeper resolve isso bem). Sem histórico, você não consegue provar quem mudou o quê e quando.
Por fim, lembre-se que conformidade não é segurança. Um servidor com Hardening Index 95 ainda pode cair por uma vulnerabilidade zero-day em uma aplicação web. Use o resultado da auditoria como linha de base e complemente com scanning de vulnerabilidades (Trivy, Grype), threat hunting com Osquery e revisões periódicas de IAM. O caminho para um ambiente Linux verdadeiramente endurecido envolve cinco camadas: hardening de SO (CIS), confinamento de processos (AppArmor/SELinux), firewall em estado (nftables), detecção (Wazuh/Auditd) e auditoria contínua (Lynis/OpenSCAP).
Perguntas frequentes
O Lynis é gratuito para uso comercial?
Sim. O Lynis Community Edition é distribuído sob licença GPLv3 e pode ser usado livremente em ambientes comerciais. A CISOfy também oferece o Lynis Enterprise (proprietário) com painel centralizado, gerenciamento multi-host e integrações comerciais, mas isso não é necessário para a auditoria descrita neste guia.
Qual é a diferença entre o CIS Benchmark e o CIS Controls?
CIS Benchmarks são guias técnicos específicos por produto (Ubuntu, RHEL, Apache, MySQL). CIS Controls v8.1 é um framework de mais alto nível com 18 controles estratégicos. Em um projeto de conformidade, os Controls definem o "quê" e os Benchmarks fornecem o "como" para cada componente.
Posso usar o Lynis em contêineres Docker e Podman?
Sim, mas com o flag --pentest e ciente de que muitos testes de kernel/fstab não se aplicam. Para imagens base, recomendo executar o Lynis durante o build (em uma camada descartável) e armazenar o índice como label OCI. Para hosts que rodam Podman rootless, audite o host normalmente; o confinamento extra já vem dos namespaces.
O que é um bom Hardening Index para passar em uma auditoria PCI-DSS?
Não há índice oficial exigido pelo PCI-DSS 4.0. Na prática, auditores QSA aceitam valores acima de 80 quando combinados com evidência de processo (cron de auditoria, tickets de remediação, exceções documentadas). Abaixo de 70 costuma gerar achado de "configuração insegura padrão" (requisito 2.2).
Com que frequência devo executar a auditoria Lynis em produção?
Para servidores estáveis, diariamente via systemd timer já é suficiente. Em ambientes com deploys frequentes ou mutáveis (Kubernetes nodes, autoscaling groups), execute o Lynis no boot e em cada novo nó antes de adicioná-lo ao pool. Combine com diff do índice entre execuções para detectar drift.
