Passo a passo para auditoria de segurança no AlmaLinux 9

18 min de leitura  ·  Guia técnico

Auditoria de segurança no AlmaLinux 9 é o processo sistemático de verificar o estado de exposição, configuração e vulnerabilidades de um servidor Linux para identificar riscos antes que sejam explorados. Para executar uma auditoria completa, siga estes passos:

1. Atualizar todos os pacotes e verificar CVEs pendentes com dnf
2. Auditar usuários, senhas e permissões de arquivos críticos
3. Verificar portas abertas e regras de firewall com ss e firewall-cmd
4. Instalar e configurar o daemon auditd para rastreamento de eventos
5. Verificar serviços ativos e desabilitar os desnecessários
6. Analisar logs de autenticação e gerar relatório com Lynis

Pré-requisitos para a auditoria de segurança no AlmaLinux 9

• Acesso root ou usuário com privilégios sudo ao servidor
• AlmaLinux 9.x instalado (verifique com cat /etc/almalinux-release)
• Conexão SSH ativa — consulte como acessar servidores VPS Linux da AviraHost se precisar configurar o acesso
• Repositórios EPEL habilitados para instalar ferramentas como Lynis
• Snapshot ou backup recente do servidor antes de aplicar qualquer correção
• Tempo estimado: 60 a 90 minutos para uma auditoria completa

Passo 1: atualizar pacotes e verificar vulnerabilidades conhecidas

O primeiro ponto de uma auditoria de segurança no AlmaLinux 9 é garantir que o sistema esteja com todos os pacotes atualizados, eliminando CVEs já corrigidos pelos mantenedores. Pacotes desatualizados são a causa mais comum de comprometimento em servidores de produção.

Execute a atualização completa do sistema:

sudo dnf update -y && sudo dnf upgrade -y

Para listar apenas atualizações relacionadas a segurança sem aplicá-las ainda:

sudo dnf updateinfo list security

Output esperado:
ALSA-2024:1234 Important/Sec. kernel-5.14.0-362.el9.x86_64
ALSA-2024:5678 Moderate/Sec.  openssl-3.0.7-27.el9.x86_64
...

Cada linha indica um advisory de segurança com severidade. Priorize os marcados como Important ou Critical. Após identificar, aplique somente as atualizações de segurança:

sudo dnf update --security -y

Verifique também se o kernel em execução corresponde ao mais recente instalado:

uname -r
rpm -q kernel | tail -1

Se os valores divergirem, um reboot é necessário para carregar o kernel atualizado. Em servidores de produção, planeje uma janela de manutenção para isso.

Passo 2: auditar usuários, grupos e permissões de arquivos críticos

A gestão de contas é um dos vetores mais explorados em ataques a servidores Linux. Nesta etapa da verificação de segurança, o objetivo é identificar contas sem senha, usuários com UID 0 indevido e permissões incorretas em arquivos sensíveis.

Liste todos os usuários com shell interativo:

grep -v '/sbin/nologin\|/bin/false' /etc/passwd

Output esperado:
root:x:0:0:root:/root:/bin/bash
seu_usuario:x:1000:1000::/home/seu_usuario:/bin/bash

Qualquer conta de sistema (como daemon, bin, mail) que apareça com shell interativo representa um risco. Corrija com:

sudo usermod -s /sbin/nologin nome_da_conta

Verifique contas com UID 0 além do root — qualquer resultado além de root é crítico:

awk -F: '($3 == 0) {print $1}' /etc/passwd

Para identificar contas sem senha ou com senha bloqueada:

sudo awk -F: '($2 == "" || $2 == "!") {print $1}' /etc/shadow

Verifique as permissões dos arquivos mais sensíveis do sistema:

stat /etc/passwd /etc/shadow /etc/sudoers

Output esperado:
/etc/passwd:  644 (rw-r--r--)
/etc/shadow:  000 ou 640 (root:shadow)
/etc/sudoers: 440 (r--r-----)  

Se /etc/shadow estiver com permissão 644 ou superior, corrija imediatamente:

sudo chmod 000 /etc/shadow
sudo chmod 440 /etc/sudoers

Procure por arquivos SUID/SGID fora dos diretórios padrão — eles podem ser usados para escalonamento de privilégios:

sudo find / -perm /6000 -type f 2>/dev/null | grep -v '/usr/\|/bin/\|/sbin/'

Qualquer resultado inesperado deve ser investigado antes de prosseguir.

Passo 3: verificar portas abertas e regras de firewall

O mapeamento de superfície de ataque via análise de portas expostas é essencial em qualquer checklist de hardening Linux. No AlmaLinux 9, o firewall padrão é o firewalld, mas é comum encontrar servidores com regras inconsistentes.

Liste todas as portas TCP em estado LISTEN com o processo responsável:

ss -tlnp

Output esperado:
State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       128     0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=1234))
LISTEN  0       128     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=5678))
LISTEN  0       128     127.0.0.1:3306      0.0.0.0:*          users:(("mysqld",pid=9012))

Portas como 23 (Telnet), 111 (RPC/portmapper), 6000 (X11) e 512-514 (rsh/rlogin) raramente são necessárias em servidores de produção. Verifique o status do firewalld:

sudo firewall-cmd --state
sudo firewall-cmd --list-all

Para bloquear uma porta específica que não deveria estar exposta:

sudo firewall-cmd --permanent --remove-port=23/tcp
sudo firewall-cmd --reload

Verifique também se o SSH está configurado para escutar apenas em interfaces necessárias. Edite /etc/ssh/sshd_config e confirme:

grep -E "^Port|^ListenAddress|^PermitRootLogin|^PasswordAuthentication" /etc/ssh/sshd_config

Output esperado (configuração segura):
Port 22
ListenAddress 0.0.0.0
PermitRootLogin no
PasswordAuthentication no

Se PermitRootLogin estiver como yes, altere para no e reinicie o serviço:

sudo sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Atenção: antes de reiniciar o SSH, certifique-se de que você tem outra sessão ativa ou acesso ao console do servidor para evitar bloqueio acidental. Veja como trocar a senha do usuário root do servidor VPS ou Dedicado caso precise recuperar acesso.

Passo 4: instalar e configurar o auditd no AlmaLinux 9

O daemon de auditoria do kernel Linux, auditd, é a ferramenta nativa para rastreamento de eventos de segurança em tempo real. Ele registra tentativas de login, modificações em arquivos críticos e execução de comandos privilegiados no arquivo /var/log/audit/audit.log.

Instale o pacote se ainda não estiver presente:

sudo dnf install -y audit audispd-plugins

Habilite e inicie o serviço:

sudo systemctl enable --now auditd
sudo systemctl status auditd

Output esperado:
● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled)
   Active: active (running) since ...

Adicione regras de auditoria para monitorar arquivos críticos. Edite /etc/audit/rules.d/audit.rules:

sudo tee /etc/audit/rules.d/security-audit.rules << 'EOF'
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege_escalation
-w /var/log/auth.log -p wa -k auth_log
-a always,exit -F arch=b64 -S execve -k exec_commands
EOF

Recarregue as regras:

sudo augenrules --load

Para consultar eventos registrados relacionados a alterações de identidade:

sudo ausearch -k identity --start today

Para gerar um relatório resumido de atividades auditadas:

sudo aureport --summary

Passo 5: verificar serviços ativos e desabilitar os desnecessários

Reduzir a superfície de ataque eliminando serviços ociosos é uma das práticas mais eficazes de endurecimento de servidor Linux. Cada serviço em execução representa um processo que pode conter vulnerabilidades.

Liste todos os serviços habilitados para iniciar automaticamente:

sudo systemctl list-unit-files --type=service --state=enabled

Verifique quais estão atualmente em execução:

sudo systemctl list-units --type=service --state=running

Serviços que raramente são necessários em servidores de produção e devem ser avaliados para desativação:

• bluetooth.service — sem uso em servidores
• cups.service — serviço de impressão
• avahi-daemon.service — descoberta de rede local (mDNS)
• rpcbind.service — necessário apenas para NFS
• postfix.service — se não for um servidor de e-mail

Para desabilitar um serviço desnecessário:

sudo systemctl disable --now bluetooth.service
sudo systemctl disable --now cups.service

Confirme que o serviço foi parado e não reiniciará:

sudo systemctl is-enabled bluetooth.service
sudo systemctl is-active bluetooth.service

Output esperado:
disabled
inactive

Passo 6: análise automatizada com Lynis

O Lynis é uma ferramenta de auditoria de conformidade e segurança para sistemas Unix/Linux que verifica centenas de pontos de controle e gera um relatório com pontuação e recomendações priorizadas. É amplamente usado para verificação de conformidade CIS Benchmark no AlmaLinux 9.

Instale o Lynis via EPEL:

sudo dnf install -y epel-release
sudo dnf install -y lynis

Execute a auditoria completa do sistema:

sudo lynis audit system

O processo leva alguns minutos. Ao final, você verá uma saída semelhante a:

Output esperado:
================================================================================
  Lynis security scan details:
  Hardening index : 67 [#############       ]
  Tests performed : 248
  Plugins enabled : 2

  Components:
  - Firewall               [V]
  - Malware scanner        [X]

  Lynis Warnings (2):
  - FIRE-4512: iptables module is not loaded
  - AUTH-9286: No password set for single user mode

  Suggestions (34):
  - Consider hardening SSH configuration [SSH-7408]
  ...
================================================================================

O Hardening index indica o nível atual de segurança (0-100). Abaixo de 70 indica que há pontos críticos a corrigir. Cada sugestão vem com um código de referência que pode ser pesquisado na documentação do Lynis para implementação detalhada.

O relatório completo é salvo em /var/log/lynis.log e o relatório de dados em /var/log/lynis-report.dat. Para verificações periódicas, consulte também as dicas de otimização de servidores Linux para complementar a auditoria com ajustes de performance.

Passo 7: verificar integridade de arquivos e detectar rootkits

A detecção de modificações não autorizadas em binários do sistema é o último passo da inspeção de segurança em servidores Linux. Ferramentas como aide e rkhunter automatizam essa verificação.

Instale o AIDE (Advanced Intrusion Detection Environment):

sudo dnf install -y aide

Inicialize o banco de dados de referência (execute apenas uma vez, em estado limpo):

sudo aide --init

Output esperado:
Start timestamp: 2024-01-15 10:30:00 -0300
AIDE initialized database at /var/lib/aide/aide.db.new.gz

Mova o banco para o local de produção:

sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Para verificações futuras, compare o estado atual com o banco de referência:

sudo aide --check

Instale e execute o rkhunter para detecção de rootkits:

sudo dnf install -y rkhunter
sudo rkhunter --update
sudo rkhunter --check --skip-keypress

Output esperado (sistema limpo):
System checks summary
=====================
File properties checks...
  Files checked: 147
  Suspect files: 0

Rootkit checks...
  Rootkits checked : 497
  Possible rootkits: 0

Applications checks...
  All checks skipped

System checks status: All checks passed

Atenção: qualquer resultado diferente de zero em "Possible rootkits" deve ser investigado imediatamente. Não reinicie o servidor antes de analisar os logs em /var/log/rkhunter.log.

Problemas comuns e como resolver

Sintoma: auditd não inicia após instalação

Causa: conflito com o SELinux em modo enforcing ou regras de auditoria com sintaxe incorreta no arquivo /etc/audit/rules.d/.
Solução: verifique o status do SELinux com getenforce. Se retornar Enforcing, consulte os logs com sudo ausearch -m avc -ts recent. Para validar as regras de auditoria antes de carregar, execute sudo auditctl -R /etc/audit/rules.d/audit.rules e observe erros de sintaxe. Corrija a linha indicada e tente novamente com sudo systemctl start auditd.

Sintoma: Lynis reporta "No password set for single user mode"

Causa: o modo de usuário único (runlevel 1) no AlmaLinux 9 não exige senha de root por padrão, o que permite acesso irrestrito ao sistema via console físico ou KVM.
Solução: edite o arquivo /etc/sysconfig/init ou configure o GRUB para exigir senha. A forma mais direta é garantir que o root tenha senha definida (sudo passwd root) e habilitar a proteção no GRUB com grub2-setpassword. Após definir a senha, execute sudo grub2-mkconfig -o /boot/grub2/grub.cfg.

Sintoma: rkhunter reporta falsos positivos em scripts do sistema

Causa: o rkhunter compara hashes de binários com um banco de dados interno. Após atualizações legítimas de pacotes, os hashes mudam e são reportados como suspeitos.
Solução: após confirmar que a atualização foi legítima (via rpm -V nome-do-pacote), atualize o banco de dados do rkhunter com sudo rkhunter --propupd. Isso registra os novos hashes como estado válido. Execute sempre após atualizações de sistema para evitar alertas desnecessários.

Sintoma: ss mostra porta 111 (rpcbind) aberta sem NFS configurado

Causa: o serviço rpcbind é instalado como dependência de outros pacotes e habilitado automaticamente, mesmo sem uso de NFS ou RPC.
Solução: desabilite e pare o serviço: sudo systemctl disable --now rpcbind rpcbind.socket. Em seguida, bloqueie a porta no firewall: sudo firewall-cmd --permanent --remove-service=rpc-bind && sudo firewall-cmd --reload. Verifique com ss -tlnp | grep 111 que a porta não aparece mais.

Perguntas frequentes sobre auditoria de segurança no AlmaLinux 9

Com que frequência devo realizar uma auditoria de segurança no servidor Linux?

O recomendado é realizar uma auditoria completa ao menos uma vez por mês em servidores de produção. Além disso, execute verificações pontuais sempre que instalar novos pacotes, adicionar usuários ou alterar regras de firewall, pois cada mudança pode introduzir novas superfícies de ataque. Ferramentas como o Lynis podem ser agendadas via cron para gerar relatórios automáticos semanais.

O que o comando auditd faz no AlmaLinux 9?

O auditd é o daemon de auditoria do kernel Linux responsável por registrar eventos de segurança como tentativas de login, alterações em arquivos críticos e execução de comandos privilegiados. No AlmaLinux 9 ele vem disponível via pacote audit e grava logs em /var/log/audit/audit.log, permitindo rastrear atividades suspeitas com precisão. As regras de auditoria são configuráveis via /etc/audit/rules.d/ e carregadas com augenrules --load.

Como verificar se há portas abertas desnecessárias no servidor?

Execute ss -tlnp ou netstat -tlnp para listar todas as portas TCP em estado LISTEN com o processo responsável. Compare a lista com os serviços que você realmente precisa expor e feche as demais com firewalld ou nftables. Portas como 23 (Telnet), 111 (RPC) e 6000 (X11) raramente são necessárias em servidores de produção e devem ser bloqueadas imediatamente.

Como identificar usuários com senha fraca ou sem senha no Linux?

Execute awk -F: '($2 == "" || $2 == "!") {print $1}' /etc/shadow para listar contas sem senha ou bloqueadas. Para verificar a política de senhas ativa, consulte /etc/security/pwquality.conf e /etc/login.defs. Contas de sistema sem shell interativo devem ter o shell definido como /sbin/nologin para impedir login direto e reduzir a superfície de ataque.

Qual a diferença entre hardening e auditoria de segurança no Linux?

Auditoria de segurança é o processo de verificar o estado atual do servidor — identificar o que está exposto, mal configurado ou vulnerável. Hardening é a etapa seguinte: aplicar as correções encontradas na auditoria, como desabilitar serviços desnecessários, restringir permissões e configurar políticas de senha. A auditoria precede e orienta o hardening — sem ela, as ações de endurecimento podem ser incompletas ou mal direcionadas.

Conclusão

• Execute a auditoria em ciclos regulares: agende o Lynis via cron mensalmente e revise os logs do auditd semanalmente para detectar anomalias antes que se tornem incidentes.
• Priorize por severidade: comece pelos itens marcados como Warning no Lynis e CVEs classificados como Critical ou Important no dnf updateinfo — eles representam o maior risco imediato.
• Documente cada mudança: registre quais serviços foram desabilitados, quais regras de firewall foram adicionadas e quais contas foram modificadas para facilitar auditorias futuras e troubleshooting.

Leia também

• Checklist de Segurança: Fail2ban vs CSF para proteger servidores Linux
• Checklist de Segurança para Servidor Linux em Produção 2026
• Como Instalar e Configurar o Firewall CSF no VPS Linux para Segurança Avançada

Precisa de ajuda com segurança no seu servidor Linux?

Manter um servidor AlmaLinux 9 seguro exige atenção contínua e conhecimento técnico atualizado. Na AviraHost, nossos planos de VPS Linux incluem suporte especializado para auxiliar na configuração inicial de segurança e boas práticas de hardening.

Conheça os planos de VPS Linux da AviraHost