Aula 33: Resposta a incidentes — detectando, contendo e recuperando de comprometimentos
A resposta a incidentes é, sem exagero, a disciplina mais decisiva da segurança ofensiva e defensiva em ambientes Linux. Não importa o quanto você invista em prevenção: sistemas bem configurados também falham, aplicações possuem vulnerabilidades desconhecidas e usuários cometem erros. Quando um comprometimento acontece, o que separa um incidente controlado de um desastre completo é a capacidade de detectar rapidamente, conter de forma cirúrgica e recuperar o ambiente sem perder evidências críticas. Nesta aula avançada, você vai executar um ciclo completo de resposta a incidentes em um servidor Linux, utilizando ferramentas nativas e complementares, técnicas forenses e procedimentos que podem ser aplicados imediatamente em produção.
O objetivo desta aula é transformar você em um profissional capaz de agir sob pressão com método. Você vai aprender a identificar sinais de comprometimento — desde processos suspeitos até alterações não autorizadas em binários e arquivos de configuração. Em seguida, vamos isolar o sistema comprometido sem destruir provas, coletar evidências voláteis e persistentes, erradicar a causa raiz e restaurar os serviços com segurança. Tudo isso será demonstrado com comandos reais, saídas esperadas e procedimentos replicáveis em distribuições Ubuntu/Debian e CentOS/RHEL/Rocky Linux.
Por que este tema importa tanto? Porque, em um incidente real, a janela de tempo é curta e a pressão é imensa. Sem um processo claro, a tendência é cometer erros como desligar o servidor imediatamente, apagar arquivos suspeitos ou restaurar um backup sem investigar a causa — ações que podem destruir evidências e permitir que o atacante retorne. Aqui, você aprenderá uma abordagem estruturada baseada em fases: detecção, contenção, análise, erradicação e recuperação. Esse fluxo é utilizado por equipes de segurança em todo o mundo, incluindo os especialistas da JRT Technology Solutions em projetos de resposta a incidentes e hardening de infraestrutura Linux.
Ao final da aula, você será capaz de conduzir uma investigação completa em um servidor Linux comprometido, documentar cada etapa, preservar evidências com integridade e devolver o ambiente à operação com um nível de confiança muito maior. Terá também um runbook prático que pode ser adaptado à sua organização. Vamos começar.
O que você vai aprender nesta aula
- Compreender o ciclo completo de resposta a incidentes aplicado a sistemas Linux.
- Detectar comprometimentos por meio de processos, portas, logs, integridade de arquivos e anomalias de sistema.
- Contêiner e isolar um servidor afetado sem destruir evidências voláteis.
- Coletar e preservar evidências forenses de memória, disco e rede.
- Erradicar causas raiz, como backdoors, cron jobs maliciosos e serviços adulterados.
- Recuperar o ambiente com backups e validar a integridade antes de retornar à produção.
- Configurar ferramentas essenciais como auditd, AIDE, rkhunter, Lynis e osquery.
- Interpretar saídas de verificação e resolver erros comuns durante a investigação.
Pré-requisitos e Ambiente
Para acompanhar esta aula, você precisará de um servidor Linux com acesso root ou sudo, de preferência uma máquina de teste que possa ser comprometida e restaurada. Recomendamos uma VM isolada em rede NAT ou um container dedicado. Você deve estar confortável com terminal, gerenciamento de serviços via systemd, manipulação de logs e noções de redes TCP/IP. Como trabalharemos com ferramentas de auditoria e forense, é importante que o kernel suporte auditd e que você tenha espaço em disco para imagens forenses, caso pratique a coleta de evidências.
Os procedimentos foram testados em Ubuntu 22.04/24.04, Debian 12, CentOS Stream 9, RHEL 9 e Rocky Linux 9. Em todas as distribuições, utilizaremos os gerenciadores de pacotes nativos: apt para Debian/Ubuntu e dnf para RHEL/CentOS/Rocky. Antes de iniciar, atualize os repositórios e instale um conjunto básico de utilidades. Execute os comandos a seguir conforme sua distribuição.
# Ubuntu / Debian
sudo apt update
sudo apt install -y net-tools lsof psmisc file wget curl
# CentOS / RHEL / Rocky Linux
sudo dnf update -y
sudo dnf install -y net-tools lsof psmisc file wget curlAlém disso, é essencial ter acesso ao log do sistema e permissão para parar serviços. Se você estiver em um ambiente de produção, execute as ações de contenção com cuidado e sempre documente cada comando. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente esse mesmo conjunto de ferramentas em análises de comprometimento, por isso a sequência que você verá a seguir é validada em cenários reais.
Fundamentos de Resposta a Incidentes em Linux
Antes de executar qualquer procedimento, você precisa entender por que a resposta a incidentes segue um processo estruturado. Um incidente não é apenas uma falha de segurança; é um evento que viola a política de segurança ou as boas práticas aceitáveis. Quando um servidor Linux é comprometido, o atacante pode manter persistência por meio de backdoors, escalar privilégios, exfiltrar dados e mover-se lateralmente na rede. Portanto, a resposta deve ser rápida, mas nunca precipitada.
O modelo mais adotado no mercado é o ciclo de seis fases: preparação, identificação, contenção, erradicação, recuperação e lições aprendidas. Nesta aula, vamos focar nas fases de identificação até recuperação, partindo do pressuposto de que você já possui um baseline de segurança e backups funcionais. A preparação envolve ter ferramentas instaladas, políticas definidas e pessoas treinadas — algo que você verá como dica avançada ao final.
Um ponto crítico é a ordem de volatilidade: ao coletar evidências, você deve priorizar dados que desaparecem rapidamente, como conteúdo de memória, processos em execução, conexões de rede ativas e cache ARP. Artefatos em disco, como arquivos e logs, são mais persistentes e podem ser analisados depois. Se você desligar o servidor imediatamente, perderá informações valiosas da memória e dos processos. Por isso, a contenção deve ser planejada para isolar sem reinicializar, sempre que possível.
Outro conceito fundamental é a cadeia de custódia: toda evidência coletada deve ter registro de quem a manipulou, quando e como, com hashes criptográficos para garantir integridade. Em ambientes corporativos, isso pode ser exigido em processos judiciais ou auditorias. Mesmo em laboratório, seguiremos práticas de integridade usando sha256sum e md5sum para registrar o estado dos arquivos.
Por fim, a continuação do negócio deve sempre ser considerada. A contenção precisa equilibrar a necessidade de isolar o incidente com o impacto nos serviços. Em muitos casos, isolar a rede é a primeira ação segura; somente depois removemos a ameaça. Vamos agora partir para a prática, começando pela detecção.
Fase 1 — Detecção: Identificando Sinais de Comprometimento
A detecção é o ponto de partida. Em servidores Linux, os sinais de comprometimento podem aparecer em processos inesperados, conexões de saída para IPs externos, usuários recém-criados, arquivos modificados em diretórios sensíveis e comportamento anômalo de CPU ou rede. O primeiro passo é estabelecer uma linha de base do que está rodando normalmente. Em nossos projetos na JRT Technology Solutions, sempre recomendamos manter um inventário atualizado de processos, portas e hashes de binários críticos, pois isso acelera enormemente a comparação durante um incidente.
Comece listando os processos em execução, ordenados por uso de CPU e memória. O comando ps aux exibe todos os processos de todos os usuários; as opções –sort=-%cpu e –sort=-%mem priorizam os maiores consumidores. Procure por processos com nomes estranhos, execução a partir de /tmp, /dev/shm ou /var/tmp, e por processos rodando como root sem justificativa.
# Lista todos os processos ordenados por uso de CPU
ps aux --sort=-%cpu
# Lista todos os processos ordenados por uso de memória
ps aux --sort=-%mem
# Filtra processos executando a partir de diretórios suspeitos
ps aux | grep -E '/tmp|/dev/shm|/var/tmp'USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1247 99.0 0.0 23456 1024 ? R 14:22 0:10 /tmp/.x11-unix/00-update
www-data 1103 0.8 1.2 456780 50240 ? S 14:20 0:04 /usr/sbin/apache2 -k start
root 1122 0.5 0.3 345678 12580 ? Ss 14:20 0:02 sshd: /usr/sbin/sshd -DObserve a primeira linha da saída: um processo chamado /tmp/.x11-unix/00-update consumindo 99% de CPU. Esse é um forte indício de malware. Em um sistema saudável, processos críticos raramente executam a partir de diretórios temporários. Anote o PID para análise posterior, mas não o encerre ainda — precisamos entender o que ele faz.
Em seguida, verifique as portas abertas e as conexões de rede ativas. O comando ss -tulpn mostra sockets TCP/UDP em escuta, com o processo associado. Procure por portas incomuns, processos escutando em interfaces externas sem necessidade e conexões estabelecidas com destinos externos. O comando ss -tpn lista conexões TCP ativas com o processo responsável.
# Mostra portas em escuta com o processo e o PID
ss -tulpn
# Mostra conexões TCP estabelecidas (incluindo saída para a internet)
ss -tpn state establishedNetid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1122,fd=3))
tcp LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1050,fd=8))
tcp ESTAB 0 0 10.0.0.5:54322 203.0.113.7:4444 users:(("/tmp/.x11-unix/00-update",pid=1247,fd=4))A conexão de saída para 203.0.113.7:4444 é extremamente suspeita: a porta 4444 é frequentemente usada por backdoors e reverse shells. O processo associado é o mesmo que detectamos anteriormente. Agora temos uma forte evidência de comprometimento. Registre os endereços IP e portas envolvidos, pois serão úteis na contenção.
Verifique também os usuários criados recentemente e os arquivos de autenticação. Os arquivos /etc/passwd, /etc/shadow e /etc/group devem conter apenas contas legítimas. Use find para localizar contas com UID 0 além do root, e lastlog ou last para ver logs de login.
# Localiza usuários com UID 0 (root) que não são exatamente o root
awk -F: '($3 == 0) { print $1 }' /etc/passwd
# Mostra as últimas 20 entradas de login
last -20
# Lista arquivos ocultos em /tmp e /dev/shm
find /tmp /dev/shm /var/tmp -type f -name '.*' -lsO comando awk -F: ‘($3 == 0) { print $1 }’ /etc/passwd usa o awk para processar o arquivo /etc/passwd, definindo o delimitador como dois-pontos e exibindo o primeiro campo (nome de usuário) de qualquer linha cujo terceiro campo (UID) seja igual a zero. Se aparecer qualquer nome além de root, você encontrou uma conta de backdoor com privilégios administrativos. O last -20 exibe os últimos 20 logins registrados no /var/log/wtmp. Já o find com a máscara .* encontra arquivos ocultos, que são comumente usados por atacantes para armazenar ferramentas.
Por fim, examine os logs do sistema. Em Ubuntu/Debian, o principal arquivo é /var/log/auth.log; em CentOS/RHEL/Rocky, é /var/log/secure. Procure por tentativas de autenticação falhas, logins fora do horário normal, alterações de senha e execuções de sudo. Use o journalctl como alternativa centralizada.
# Ubuntu/Debian — últimas 50 linhas de autenticação
tail -n 50 /var/log/auth.log
# CentOS/RHEL/Rocky — últimas 50 linhas de autenticação
tail -n 50 /var/log/secure
# Verifica erros e alertas no journal dos sistemas
journalctl -p err -n 50 --no-pagerSep 16 14:22:31 servidor sshd[1122]: Failed password for invalid user admin from 203.0.113.7 port 55412 ssh2
Sep 16 14:23:05 servidor sshd[1130]: Accepted publickey for deploy from 10.0.0.10 port 55111 ssh2
Sep 16 14:23:09 servidor sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/vim /etc/cron.d/update-check
Sep 16 14:24:02 servidor sshd[1247]: Accepted password for root from 203.0.113.7 port 55550 ssh2Na saída, há dois eventos alarmantes: um login bem-sucedido como root vindo do mesmo IP suspeito 203.0.113.7, e um comando sudo vim /etc/cron.d/update-check executado pelo usuário deploy. Isso sugere que o atacante obteve credenciais e criou ou modificou um cron job para persistência. Vamos verificar esse arquivo na fase de contenção e erradicação.
Fase 2 — Contenção: Isolando o Sistema Afetado
A contenção tem um objetivo claro: impedir que o atacante continue operando no sistema ou se mova lateralmente, sem destruir evidências. A primeira decisão é se o servidor deve ser desconectado da rede ou apenas bloqueado seletivamente. Em cenários onde há suspeita de exfiltração de dados, o isolamento total pode ser necessário. Em outros casos, bloquear apenas o IP malicioso e encerrar processos específicos é suficiente e menos disruptivo.
Antes de isolar, execute uma coleta rápida de informações voláteis, como a lista de processos, conexões de rede e tabela ARP. Esses dados desaparecem se o sistema for reiniciado. Crie um diretório de evidências, por exemplo /root/evidencias, e salve as saídas com timestamps. Em nossos projetos na JRT Technology Solutions, sempre automatizamos essa coleta inicial com um script que captura ps, ss, lsof, arp e netstat.
# Cria diretório de evidências
mkdir -p /root/evidencias
# Coleta de dados voláteis
ps auxf > /root/evidencias/ps-$(date +%s).txt
ss -tulpn > /root/evidencias/ss-$(date +%s).txt
lsof -i > /root/evidencias/lsof-$(date +%s).txt
arp -an > /root/evidencias/arp-$(date +%s).txt
w > /root/evidencias/w-$(date +%s).txtCada comando acima redireciona a saída para um arquivo com timestamp Unix, garantindo que as evidências fiquem organizadas. O comando ps auxf exibe a árvore de processos no formato floresta, mostrando as relações pai-filho. O lsof -i lista arquivos abertos relacionados a sockets de rede. O arp -an mostra a tabela ARP, útil para identificar outros hosts comprometidos na mesma sub-rede.
Agora, execute a contenção. Comece bloqueando o IP malicioso no firewall local. Em distribuições modernas, você pode usar iptables ou nftables. No Ubuntu e no CentOS/RHEL, o iptables geralmente está disponível, mas o nftables é o subsistema padrão mais recente. Vamos demonstrar ambos.
# Usando iptables para bloquear IP de entrada e saída
sudo iptables -A INPUT -s 203.0.113.7 -j DROP
sudo iptables -A OUTPUT -d 203.0.113.7 -j DROP
# Usando nftables para bloquear o mesmo IP
sudo nft add table ip filter
sudo nft add chain ip filter input '{ type filter hook input priority 0; policy accept; }'
sudo nft add chain ip filter output '{ type filter hook output priority 0; policy accept; }'
sudo nft add rule ip filter input ip saddr 203.0.113.7 drop
sudo nft add rule ip filter output ip daddr 203.0.113.7 dropNo bloco com iptables, a opção -A adiciona uma regra ao final da cadeia especificada (INPUT ou OUTPUT). O parâmetro -s indica o endereço de origem e -d o de destino. O alvo DROP descarta silenciosamente os pacotes. No nftables, criamos uma tabela chamada filter, depois duas chains com hook de entrada e saída, e por fim regras que descartam pacotes com origem ou destino no IP malicioso. Essas regras são imediatas, mas não persistem após reinicialização — para produção, salve as regras com iptables-save ou nft list ruleset > /etc/nftables.conf conforme a distribuição.
Se o incidente for grave, isole completamente a rede. Você pode derrubar a interface ou usar um firewall que bloqueie todo tráfego, exceto acesso administrativo local. O comando nmcli networking off desabilita toda a rede no NetworkManager; já ip link set eth0 down desativa uma interface específica. Cuidado: em servidores remotos, isso corta seu acesso SSH. Se você estiver conectado remotamente, use o bloqueio seletivo ou combine com acesso via console/IPMI.
# Isolamento total via NetworkManager
sudo nmcli networking off
# Isolamento de interface específica
sudo ip link set eth0 down
# Bloqueia todo tráfego exceto o já estabelecido (permite SSH atual)
sudo iptables -P INPUT DROP
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTO comando iptables -P INPUT DROP define a política padrão da cadeia INPUT como DROP, bloqueando todas as novas conexões de entrada. A regra seguinte permite apenas conexões já estabelecidas ou relacionadas, mantendo sua sessão SSH atual ativa, mas impedindo novas conexões. Essa abordagem é elegante para contenção remota, pois preserva o controle ao mesmo tempo em que corta o acesso do atacante.
Depois de isolar a rede, encerre os processos maliciosos identificados. Use o PID obtido na detecção. Antes de matar, colete informações sobre o processo com cat /proc/<PID>/cmdline, ls -l /proc/<PID>/exe e strace -p <PID> -f -e trace=network se disponível. Em seguida, envie o sinal SIGSTOP (19) para pausar o processo temporariamente, permitindo análise; depois, SIGKILL (9) para encerrá-lo.
# Examina o processo antes de encerrar
cat /proc/1247/cmdline
ls -l /proc/1247/exe
# Pausa o processo para análise
sudo kill -STOP 1247
# Encerra o processo
sudo kill -KILL 1247Verifique também os serviços relacionados. Muitas vezes o malware se instala como um serviço do systemd ou como um script de inicialização. Use systemctl status para verificar serviços suspeitos, systemctl stop para pará-los e systemctl disable para impedir que iniciem no boot. Se o serviço não for reconhecido, examine os arquivos em /etc/systemd/system e /etc/cron*.
# Lista serviços com falhas ou recém-criados
systemctl list-unit-files --state=enabled | grep -i -E 'susp|update|backdoor'
# Para e desabilita um serviço suspeito
sudo systemctl stop update-check.service
sudo systemctl disable update-check.service
# Verifica o conteúdo do cron job suspeito
cat /etc/cron.d/update-check* * * * * root /tmp/.x11-unix/00-update >/dev/null 2>&1O arquivo /etc/cron.d/update-check contém uma entrada que executa o binário malicioso a cada minuto. Removeremos isso na fase de erradicação. Por ora, a contenção está concluída: o IP malicioso está bloqueado, o processo foi pausado e depois encerrado, e o cron job foi identificado. O sistema está isolado o suficiente para a análise forense.
Fase 3 — Coleta de Evidências e Análise Forense
A análise forense em Linux exige método e atenção à integridade. O objetivo é responder às perguntas: como o atacante entrou?, o que ele modificou?, quais dados foram acessados? e há persistência instalada?. Para isso, combinamos exame de processos, arquivos, logs e, se possível, cópia de imagem do disco e memória.
Comece coletando a memória RAM, se o sistema ainda estiver em execução. Ferramentas como LiME (Linux Memory Extractor) e AVML da Microsoft são frequentemente usadas. No Ubuntu, você pode instalar o lime-forensics-dkms; no CentOS/RHEL, compile o módulo ou use o AVML pré-compilado. Aqui, demonstraremos o uso do AVML por ser simples e não exigir compilação.
# Baixa o AVML (x86_64) e coleta a memória
wget https://github.com/microsoft/avml/releases/download/v0.4.0/avml -O /root/evidencias/avml
chmod +x /root/evidencias/avml
sudo /root/evidencias/avml /root/evidencias/memoria-$(date +%s).lime
# Calcula o hash SHA-256 da imagem de memória
sha256sum /root/evidencias/memoria-*.lime > /root/evidencias/memoria.sha256
cat /root/evidencias/memoria.sha256O comando wget baixa o binário do AVML; chmod +x torna-o executável; e sudo avml <arquivo> grava a memória no formato LiME. O sha256sum calcula o hash da imagem, gerando um arquivo de verificação que faz parte da cadeia de custódia. Guarde esse arquivo em um local seguro.
Em seguida, faça a cópia forense do disco ou das partições relevantes. O comando dd é universal e suficiente para a maioria dos casos. Use a opção bs=4M para acelerar a cópia e status=progress para acompanhar. Se preferir uma ferramenta com compressão e hash integrados, instale o dcfldd ou o guymager.
# Cria imagem forense do disco /dev/sda
sudo dd if=/dev/sda of=/root/evidencias/disk-sda.img bs=4M status=progress conv=noerror,sync
# Calcula o hash da imagem
sha256sum /root/evidencias/disk-sda.img > /root/evidencias/disk-sda.sha256
# Lista as partições e o sistema de arquivos
lsblk
fdisk -l /root/evidencias/disk-sda.imgO parâmetro conv=noerror,sync instrui o dd a continuar em caso de erro de leitura e a sincronizar os blocos, útil para discos com setores defeituosos. A imagem resultante pode ser montada em modo somente leitura ou analisada com ferramentas como The Sleuth Kit. Para instalar:
# Ubuntu / Debian
sudo apt install -y sleuthkit
# CentOS / RHEL / Rocky Linux
sudo dnf install -y sleuthkitCom o Sleuth Kit, você pode listar arquivos de um sistema de arquivos sem montar a imagem, evitando alterações. O comando fls -r -o 2048 /root/evidencias/disk-sda.img lista recursivamente os arquivos a partir do offset da partição. Para extrair um arquivo específico, use icat. Por exemplo, para recuperar o binário suspeito:
# Lista arquivos na imagem a partir do offset 2048 (setor da partição)
fls -r -o 2048 /root/evidencias/disk-sda.img | head -n 100
# Extrai o binário suspeito por inode
icat -o 2048 /root/evidencias/disk-sda.img 4587 > /root/evidencias/binario-suspeito
file /root/evidencias/binario-suspeitoO fls mostra nome, tipo e inode de cada arquivo. O parâmetro -o 2048 indica o offset em setores onde a partição começa — ajuste conforme o fdisk -l. O icat extrai o conteúdo do inode 4587 para um arquivo local. Depois, file identifica o tipo do binário. Esse processo permite analisar malware sem executar o código.
Além da imagem, examine os arquivos em busca de persistência. Os locais mais comuns são /etc/cron*, /etc/systemd/system, /etc/init.d, ~/.bashrc, ~/.profile e /etc/ld.so.preload. Use find para localizar arquivos modificados nas últimas 48 horas, excluindo diretórios virtuais.
# Arquivos modificados nas últimas 48 horas (excluindo /proc, /sys, /dev)
find / -type f -mtime -2 -ls 2>/dev/null | grep -v -E '^/proc|^/sys|^/dev'
# Verifica o conteúdo do pré-carregador de bibliotecas
cat /etc/ld.so.preload
# Verifica timestamps de binários críticos
stat /bin/ls /bin/ps /usr/bin/ssh /usr/sbin/sshdO find / -type f -mtime -2 -ls lista todos os arquivos modificados nos últimos dois dias. O redirecionamento 2>/dev/null descarta mensagens de erro, e o grep -v filtra os diretórios virtuais. O /etc/ld.so.preload, se existir, pode injetar bibliotecas em todos os processos — uma técnica sofisticada de rootkit. Os stat mostram os timestamps de binários essenciais; datas de modificação recentes em binários que não foram atualizados oficialmente indicam adulteração.
Para verificar a integridade dos binários e pacotes, use rpm -Va no CentOS/RHEL/Rocky e debsums no Debian/Ubuntu. Esses comandos comparam o estado atual dos arquivos com o registro do gerenciador de pacotes.
# CentOS / RHEL / Rocky — verifica integridade de todos os pacotes
rpm -Va | sort
# Ubuntu / Debian — instala debsums e verifica pacotes
sudo apt install -y debsums
sudo debsums -c..5....T. c /etc/ssh/sshd_config
S.5....T. c /etc/cron.d/update-check
.M....... /usr/bin/ls
..?...... /tmp/.x11-unix/00-updateA saída do rpm -Va usa códigos de verificação: o ponto . indica que o atributo passou, e caracteres como S (tamanho), 5 (MD5), M (modo), T (timestamp) indicam divergências. Aqui vemos /usr/bin/ls com hash diferente, sugerindo que o binário foi substituído por uma versão maliciosa — clássico de rootkit. O arquivo /etc/cron.d/update-check aparece como config com tamanho e timestamp alterados. Essas informações orientam a erradicação.
Configuração Detalhada — Ferramentas de Auditoria e Integridade
Uma resposta a incidentes eficiente depende de telemetria pré-existente. Nesta seção, você configurará três ferramentas fundamentais: auditd para auditoria do kernel, AIDE para integridade de arquivos e rkhunter para detecção de rootkits. Essas ferramentas devem ser instaladas e configuradas antes do incidente, mas se você está em um ambiente comprometido, instale-as agora para auxiliar na erradicação e evitar reincidência.
Comece instalando no Ubuntu/Debian:
sudo apt update
sudo apt install -y auditd audispd-plugins aide rkhunter chkrootkit lynisE no CentOS/RHEL/Rocky:
sudo dnf install -y audit audit-libs aide rkhunter chkrootkit lynisApós a instalação, configure o auditd para monitorar eventos críticos de segurança. O arquivo principal é /etc/audit/rules.d/audit.rules em muitas distribuições, mas a convenção moderna é criar arquivos em /etc/audit/rules.d/. Vamos criar um arquivo chamado hardening.rules com regras focadas em resposta a incidentes.
# Cria o arquivo de regras do auditd
sudo tee /etc/audit/rules.d/hardening.rules > /dev/null <<'EOF'
## Remove regras existentes e configura buffer
-D
-b 8192
-f 1
--backlog_wait_time 60000
## Monitora execução de comandos (execve)
-a always,exit -F arch=b64 -S execve -k execve-monitor
## Monitora alterações em arquivos de autenticação
-w /etc/passwd -p wa -k identity-changes
-w /etc/shadow -p wa -k identity-changes
-w /etc/group -p wa -k identity-changes
-w /etc/gshadow -p wa -k identity-changes
-w /etc/sudoers -p wa -k privilege-changes
-w /etc/sudoers.d/ -p wa -k privilege-changes
## Monitora configuração de cron e systemd
-w /etc/cron.d/ -p wa -k persistence-cron
-w /etc/cron.daily/ -p wa -k persistence-cron
-w /etc/crontab -p wa -k persistence-cron
-w /etc/systemd/system/ -p wa -k persistence-systemd
## Monitora binários críticos
-w /bin/ -p wa -k binaries
-w /usr/bin/ -p wa -k binaries
-w /usr/sbin/ -p wa -k binaries
-w /sbin/ -p wa -k binaries
## Monitora montagem de sistemas de arquivos
-a always,exit -F arch=b64 -S mount -k mount-events
-a always,exit -F arch=b32 -S mount -k mount-events
## Monitora mudanças de UID/GID e escalonamento
-a always,exit -F arch=b64 -S setuid,setgid -k privileges
-a always,exit -F arch=b32 -S setuid,setgid -k privileges
EOFO arquivo acima remove regras anteriores com -D, define o buffer para 8192 eventos e configura o modo de falha para 1, que encerra o sistema se o auditd não conseguir registrar — adequado para ambientes de alta segurança. As linhas -w monitoram arquivos e diretórios com permissões de escrita (w) e alteração de atributos (a), associando uma chave (-k) para facilitar buscas. As linhas -a always,exit -S execve registram toda execução de comando, essencial para reconstruir a cronologia do ataque. Ajuste a regra arch=b64 ou b32 conforme a arquitetura do sistema.
Agora configure o AIDE. Inicialize o banco de dados de integridade após garantir que o sistema esteja limpo. No Ubuntu/Debian, o arquivo de configuração padrão é /etc/aide/aide.conf; no CentOS/RHEL/Rocky, /etc/aide.conf. Use o comando aideinit (Debian) ou aide –init (
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Segurança Linux para equipes corporativas.
