Voltar para blog

Do diagnóstico à defesa: hardening de servidores Linux com Lynis

23/02/2026 · 4 min · Infraestrutura

Compartilhar

Em uma auditoria de rotina em ambiente Linux de produção, executei o Lynis para medir postura real de segurança e não apenas disponibilidade. O host estava estável para carga, mas o relatório final trouxe 1 warning e 37 suggestions.

Na prática operacional, "serviço no ar" não significa "superfície de ataque aceitável". Este artigo documenta exatamente o que eu fiz, em sequência, arquivo por arquivo, comando por comando, até fechar o ciclo com validação pós-mudança e novo scan.

1) Linha de base: execução da auditoria e leitura dos achados

Iniciei a coleta com snapshot da configuração atual e execução completa do Lynis no perfil de sistema.

hostnamectl
cat /etc/os-release
uname -r
lynis --version

lynis audit system \
  --verbose \
  --report-file /var/log/lynis-report-$(date +%F).dat \
  --log-file /var/log/lynis-$(date +%F).log

Após a execução, concentrei análise em:

Principais pontos atacados na mesma janela de manutenção:

  1. [KRNL-5830] indicando reboot pendente para ativar kernel atualizado.
  2. baseline permissiva em SSH.
  3. política de senha e umask desalinhadas para ambiente de produção.
  4. falta de bloqueio explícito para protocolos de rede não usados.
  5. auditd ativo sem regra útil de trilha para arquivos críticos.

2) Correção do warning crítico de kernel ([KRNL-5830])

O warning apontava pacote de kernel atualizado, porém não carregado pelo host. Nesse cenário, correção sem reboot não elimina risco.

Checklist antes de reiniciar:

  1. validar janela de manutenção aprovada.
  2. checar estado de aplicação e conexões ativas.
  3. registrar versão atual e alvo de boot.
rpm -qa | grep -E '^kernel(-core|-modules)?'
uname -r
who -b
systemctl list-units --type=service --state=running | wc -l

Execução da etapa:

reboot

Validação pós-reboot:

uname -r
journalctl -b -p err --no-pager

Critério de aceite: kernel em execução igual ao kernel atualizado instalado e sem erro crítico de boot no journal.

3) Hardening de SSH (porta de entrada)

No meu fluxo, SSH sempre entra no topo da lista. Ajustei /etc/ssh/sshd_config com política de menor privilégio e redução de ataque por força bruta.

Parâmetros aplicados:

Trecho efetivamente aplicado:

cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)

cat >> /etc/ssh/sshd_config <<'SSHCFG'
PermitRootLogin no
MaxAuthTries 3
LogLevel VERBOSE
X11Forwarding no
AllowTcpForwarding no
PasswordAuthentication no
ClientAliveInterval 300
ClientAliveCountMax 2
SSHCFG

Validação sem derrubar acesso administrativo:

sshd -t
systemctl reload sshd
systemctl status sshd --no-pager

Conferência prática: mantive uma sessão SSH aberta, testei nova sessão com chave válida e confirmei recusa de autenticação por senha.

4) Política de identidade e senha (login.defs + PAM)

A seção AUTH do Lynis apontou postura permissiva para senha e padrões de criação de arquivos. Corrigi em duas camadas: envelhecimento de senha e permissão padrão.

Arquivo /etc/login.defs ajustado:

cp -a /etc/login.defs /etc/login.defs.bak.$(date +%F-%H%M)

sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS\t90/' /etc/login.defs
sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS\t1/' /etc/login.defs
sed -i 's/^PASS_WARN_AGE.*/PASS_WARN_AGE\t14/' /etc/login.defs
sed -i 's/^UMASK.*/UMASK\t027/' /etc/login.defs

Em PAM, ativei hashing forte e qualidade mínima de senha, conforme módulo da distro (pam_pwquality / pam_unix).

Exemplo de parâmetros aplicados:

Validação operacional:

grep -E 'PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE|UMASK' /etc/login.defs
chage -l <usuario_admin>

Efeito esperado:

  1. rotação periódica de credenciais administrativas.
  2. criação de arquivos novos sem leitura global indevida.
  3. redução de reutilização de senhas recentes.

5) Hardening de memória, kernel e rede (sysctl + limits)

5.1) Bloqueio de core dumps

Para reduzir exposição de memória em disco após crash de processo:

cp -a /etc/security/limits.conf /etc/security/limits.conf.bak.$(date +%F-%H%M)
echo '* hard core 0' >> /etc/security/limits.conf

5.2) Desativação de protocolos não utilizados

No host auditado, a função operacional era HTTP/HTTPS e administração. DCCP, SCTP e RDS não tinham justificativa de negócio.

cat > /etc/modprobe.d/99-hardening-protocols.conf <<'MODP'
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
MODP

modprobe -n -v dccp
modprobe -n -v sctp
modprobe -n -v rds

5.3) Parâmetros de rede seguros

Apliquei baseline de sysctl para reduzir vetores clássicos de spoofing e respostas indevidas de stack de rede.

cat > /etc/sysctl.d/99-lynis-hardening.conf <<'SYSCTL'
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
SYSCTL

sysctl --system

Validação de parâmetros críticos:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.all.accept_redirects
sysctl kernel.randomize_va_space

6) Auditoria ativa de eventos com auditd

O Lynis apontou cenário comum: auditd ativo, mas sem cobertura prática para arquivos críticos de identidade. Corrigi com regras objetivas para detectar alterações em contas, grupos e autenticação.

cat > /etc/audit/rules.d/99-identity-monitor.rules <<'AUDIT'
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k priv_esc
-w /etc/ssh/sshd_config -p wa -k ssh_change
AUDIT

augenrules --load
systemctl restart auditd
systemctl status auditd --no-pager

Teste prático de trilha:

auditctl -l
ausearch -k identity -ts today

Objetivo: qualquer alteração nesses arquivos gera evento rastreável para investigação e compliance.

7) Anti-malware e integridade com rkhunter

Implementei varredura periódica com rkhunter para detectar assinatura conhecida, arquivo alterado e anomalias de binários.

dnf install -y rkhunter
rkhunter --update
rkhunter --propupd
rkhunter --check --sk

Para rotina operacional, configurei execução diária via cron/systemd timer (conforme padrão do host) e envio de relatório para caixa técnica.

Ponto importante: rkhunter não substitui EDR, mas adiciona camada útil de verificação de integridade em host Linux tradicional.

8) Reexecução do Lynis e validação de resultado

Com mudanças aplicadas, executei nova auditoria para confirmar redução de risco.

lynis audit system \
  --quick \
  --report-file /var/log/lynis-report-postfix-$(date +%F).dat \
  --log-file /var/log/lynis-postfix-$(date +%F).log

Validação que eu sempre fecho no relatório:

  1. warning crítico eliminado (KRNL-5830 resolvido após reboot).
  2. redução objetiva de sugestões relacionadas a SSH/AUTH/ACCOUNTING.
  3. hardening index superior ao baseline inicial.
  4. serviços de aplicação íntegros após endurecimento.

Comandos de sanidade pós-hardening:

systemctl --failed
ss -lntup
journalctl -p err -b --no-pager

9) Checklist operacional aplicado

Esse trabalho reforçou uma regra operacional simples: segurança real em Linux não é habilitar ferramenta, é fechar ciclo técnico completo.

No meu dia a dia, o Lynis é usado como motor de diagnóstico e priorização. O valor vem da execução disciplinada: ler achado, corrigir com critério, validar impacto, auditar novamente e documentar evidência.

Para ambientes de produção em cPanel, DirectAdmin ou hosts puros em CLI, essa abordagem transforma "sugestões" em defesa concreta e auditável.

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.