Linux Auditd – Registar corretamente os eventos de segurança

Linux Auditd regista eventos relevantes para a segurança diretamente a partir do kernel e fornece-me uma pista de auditoria completa para inícios de sessão, alterações de ficheiros, execução de comandos e chamadas ao sistema. Correto Quando o configuro, deteto ataques numa fase precoce, cumpro os requisitos de conformidade, como a norma ISO 27001 ou a PCI DSS, e analiso os incidentes de forma forense e fiável.

Pontos centrais

Este Resumo esta visão geral de forma deliberadamente concisa, prática e sem clichés, para que compreendas imediatamente como definir regras de auditoria, proteger registos e extrair conclusões. I Indique os componentes mais importantes, os casos de utilização típicos, as regras úteis e as fontes de erro que, em muitos ambientes, dão origem a pontos cegos. Então podes ver num relance quais são as definições relevantes no ficheiro auditd.conf e quais as ferramentas disponíveis para a análise. Posteriormente Aprofundo cada tema com exemplos, recomendações claras e uma tabela com os parâmetros decisivos. Portanto, isso consegues passar de „O Auditd está a funcionar“ para „O Auditd fornece sinais de segurança úteis“.

• Pista de auditoria: rastreabilidade total das ações relevantes para a segurança
• Regras: ficheiros críticos específicos, execve, privilégios e configurações
• Proteção de registos: Rotação, acionamento por stock, resposta em caso de escassez
• Remoto: recolha centralizada via TCP/TLS e integração com o SIEM
• Análise: ausearch, aureport, chaves claras e documentação bem organizada

O Auditd do Linux no conceito de segurança

Auditd complementa os registos de sistema clássicos, concentrando-se especificamente em ações relevantes para a segurança e registando os eventos através da interface do kernel. O Por predefinição, o Daemon regista estes eventos em /var/log/audit/audit.log e regista qual o utilizador que realizou cada ação e em que momento. Assim, posso verificar rapidamente situações suspeitas, como, por exemplo, alterações indesejadas em /etc/ssh/sshd_config ou em ficheiros confidenciais, como /etc/shadow. Em Em ambientes regulamentados, garanto assim provas de violações das diretrizes e cumpro os requisitos relativos a um registo fiável. Em frente a Ao contrário dos dados clássicos de registos ou Syslog, o Auditd oferece uma visão aprofundada e centrada na segurança, que é fundamental para a análise de ataques.

Arquitetura: Kernel, Daemon, Ferramentas

O O sistema de auditoria divide-se num subsistema do kernel para o registo e no serviço do espaço do utilizador auditado para o armazenamento e ferramentas de gestão e análise. Sobre auditctl defino regras em tempo de execução ou carrego regras persistentes no arranque /etc/audit/rules.d/*.rules. Com ausearch filtro os eventos por hora, utilizador, chave ou ficheiro, enquanto aureport gera relatórios concisos. Então Combino a recolha de dados com controlo granular com uma análise rápida e mantenho a trilha de auditoria rastreável do início ao fim. Importante é uma nomenclatura consistente em relação a -k Chaves, para que as consultas posteriores funcionem corretamente.

Instalação e ativação

Em Vou instalar o RHEL/CentOS auditoria via dnf install audit ou yum install audit, no Debian/Ubuntu utilizo apt install auditd audispd-plugins. De acordo com Após a instalação, inicio e ativo o serviço com systemctl start auditd e systemctl enable auditd, verifico o estado com systemctl status auditd. Logo que Quando o subsistema de auditoria e o serviço estão em execução, os eventos são encaminhados, de acordo com as regras, para /var/log/audit/audit.log. I Verifique se está a funcionar corretamente através de um acesso específico a um ficheiro monitorizado e, em seguida, procure o evento com ausearch -k keyname. Para Para garantir um arranque consistente em cada inicialização, asseguro que existam regras persistentes e que estas sejam carregadas corretamente.

Início antecipado, carteira de trabalhos e proteção por regras

Para Para não perder os eventos iniciais do arranque, ativo o subsistema de auditoria logo no arranque do kernel. A este respeito Defino os parâmetros do kernel e um tamanho de backlog suficiente para que os eventos não se percam durante a fase de arranque. Além disso Após o carregamento, bloqueio a base de regras para impedir a sua manipulação.

• Parâmetros do kernel: audit=1 audit_backlog_limit=8192 em /etc/default/grub completar e, em seguida, update-grub (Debian/Ubuntu) ou grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS).
• Pendências nas regras: Nas regras de início, defino -b 8192, para dimensionar adequadamente a fila do kernel.
• Bloquear regras: Após carregar a base de regras definitiva, ativo o modo imutável com -e 2. As alterações só serão possíveis após o reinício – uma proteção eficaz contra manipulações em tempo real.
• Comportamento em caso de transbordamento: Em /etc/audit/auditd.conf defino overflow_action (por exemplo. SYSLOG ou SINGLE), para que, com o buffer cheio, obtenha reações claramente definidas.

Definir corretamente as regras de auditoria

O A qualidade da pista de auditoria depende de regras claras e específicas, que abranjam as ações críticas e evitem ruído desnecessário. Para Os ficheiros confidenciais, por exemplo, eu coloco -w /etc/passwd -p warx -k passwd_changes e adicione regras adequadas para /etc/shadow, /etc/sudoers ou /etc/ssh/. Para Para registar a execução de comandos, utilizo -a always,exit -F arch=b64 -S execve bem como a versão de 32 bits, para que cada versão permaneça visível, mesmo através de raiz. Para Filtro programas de utilitários como o Apache de forma específica através do caminho do ficheiro binário, por exemplo -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. I Documenta cada regra com comentários sucintos e chaves unívocas, para que as análises sejam reproduzíveis e os colegas consigam perceber a intenção.

Exemplos de regras avançadas e ajuste

Para Para aprofundar ainda mais, estou a criar um conjunto específico que torna visíveis as alterações de privilégios, as intervenções no kernel, as alterações de tempo e de rede, bem como os mecanismos persistentes – sem ruído relacionado com pacotes ou cópias de segurança.

• Apenas utilizadores interativos: -F auid>=1000 -F auid!=4294967295 complementado com execve-Regras para excluir os serviços do sistema.
• Alteração de privilégios: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change e a versão de 32 bits. Opcional: -C uid!=euid, caso sejam suportadas comparações de campos.
• Módulos do kernel: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; além disso: -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
• Alterações de horário: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change e -w /etc/localtime -p wa -k time_change.
• Montagens e sistema de ficheiros: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
• Base de rede: -a always,exit -F arch=b64 -S sethostname,setdomainname -k net_conf; -w /etc/hosts -p wa -k net_conf, -w /etc/hostname -p wa -k net_conf, -w /etc/resolv.conf -p wa -k net_conf.
• Cron e temporizador: -w /etc/crontab -p wa -k sched, -w /etc/cron.d/ -p wa -k sched, -w /var/spool/cron/ -p wa -k sched, -w /etc/systemd/system/ -p wa -k sched, -w /usr/lib/systemd/system/ -p wa -k sched.
• Persistência através do SSH: -w /root/.ssh/ -p wa -k ssh_keys, -w /home/ -p wa -k ssh_keys (caminho estreito em authorized_keys(limite de ficheiros por utilizador, para evitar ruído).
• Conter o uso indevido de SUID/SGID: Concentrar-se em diretórios executáveis: -w /usr/bin/ -p wa -k bin_change, -w /usr/sbin/ -p wa -k bin_change, -w /bin/ -p wa -k bin_change, -w /sbin/ -p wa -k bin_change.
• Registar apenas os erros (para chamadas de sistema ruidosas): -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
• Reduzir o ruído: Excluir gestores de pacotes/cópias de segurança, por exemplo,. -a never,exit -F exe=/usr/bin/dpkg, -a never,exit -F exe=/usr/bin/apt, -a never,exit -F exe=/usr/bin/yum, -a never,exit -F exe=/usr/bin/rpm, -a never,exit -F exe=/usr/bin/rsync (Verificar o caminho para cada distribuição).

Gestão de registos e proteção contra a perda de registos

Sem Sem uma rotação adequada e sem limites bem definidos, os registos de auditoria correm o risco de perder dados valiosos ou de encher o sistema de ficheiros. Em /etc/audit/auditd.conf Defino, entre outras coisas, max_log_file, max_log_file_action, num_logs, space_left e reações como space_left_action, disk_full_action ou disk_error_action. I prefiro ações como ROTATE e uma notificação atempada no Syslog, para que eu possa reagir a tempo em caso de congestionamentos. Além disso Guardo os registos de auditoria num servidor separado, para dificultar a manipulação do sistema em questão e preservar as provas. O A tabela seguinte classifica os parâmetros principais e apresenta configurações típicas e adequadas à prática.

Parâmetros	Objetivo	Exemplo	Nota
ficheiro_de_registo	Local de armazenamento dos registos de auditoria	/var/log/audit/audit.log	Manter o caminho padrão e garantir a segurança dos direitos
log_format	Formato dos eventos	RAW	O formato RAW facilita a análise forense sem perda de informação
max_log_file	Tamanho máximo do ficheiro (MB)	100 até 500	Ajustar o tamanho em função do volume de eventos e da capacidade de armazenamento
max_log_file_action	Ação ao atingir o tamanho	ROTATE	A rotação evita a paragem ou a sobrescrita
num_logs	Número de ficheiros armazenados	5 até 10	Histórico suficiente para análises, sem ocupar muita memória
space_left	Limite de memória livre (MB)	1024 ou superior	Os alertas precoces permitem um tempo de reação
space_left_action	Reação em caso de valor inferior ao previsto	SYSLOG	Considerar também o envio de um e-mail ou de um alarme SIEM
disk_full_action	Comportamento quando o suporte de dados está cheio	SUSPENDER ou PARE	Uma decisão clara depende da aceitação do risco

Registo remoto e análise centralizada

Para Em muitos servidores, opto por um registo centralizado via TCP/TLS, controlado por parâmetros como tcp_listen_port e terminais correspondentes. Sobre Através dos plug-ins audispd ou do rsyslog, encaminho eventos para uma plataforma SIEM ou de segurança, correlacionando erros de início de sessão, alterações de configuração e inícios de processos suspeitos. Então reconheço padrões que, num único servidor, parecem inofensivos, mas que, quando analisados em conjunto, desencadeiam imediatamente um alarme. Quem quem já utiliza painéis de controlo beneficia de Agregação de registos no alojamento, porque os eventos de auditoria são lá combinados com outros dados de telemetria. I Assegure também que o percurso de transporte seja seguro e que haja uma separação clara entre os sistemas produtivos e a instância de recolha.

Análise: utilizar o ausearch e o aureport de forma orientada para os objetivos

Dados em bruto não servem para nada se não as conseguir filtrar rapidamente; por isso, começo com chaves claras e utilizo ausearch para consultas específicas. Com ausearch -k passwd_changes -ts today analisarei, por exemplo, as alterações recentes a /etc/passwd ; se for necessário, ajusto o intervalo de tempo e os filtros de utilizadores. Para Fornece relatórios de síntese aureport --summary tabelas compactas que mostram os inícios de sessão suspeitos, as alterações nos ficheiros e a frequência das chamadas de sistema. Além disso Complemento a visão sobre o início dos processos e a utilização dos recursos com Contabilidade de processos, para correlacionar cadeias de execuções e picos de carga. Em O que importa é que consigo responder a perguntas em segundos: quem, o quê, quando, onde e por que meio.

Aprofundar a análise: interpretar corretamente os campos de eventos

Portanto, isso Para que as análises sejam precisas, conheço os campos e os tipos de eventos mais importantes. SYSCALL- As entradas incluem, entre outras coisas,. auid (UID de registo), uid/euid/suid (UID real/efetivo/guardado), ses (ID da sessão) e exe (ficheiro executável). PATH-Os blocos indicam os caminhos afetados, EXECVE enumera os argumentos, CWD fornece o diretório de trabalho. Com ausearch -m SYSCALL -sc execve -ua 1000 -ts recent centro-me em apresentações interativas; aureport -x --summary -i mostra-me as frequências e as anomalias num só olhar. Importante: auid fica por sudo ou os saltos setuid são constantes e, por isso, constituem o critério de filtragem mais robusto para determinar „Quem o iniciou?“.

Evitar erros típicos

Para Regras demasiado abrangentes tornam os registos excessivamente volumosos e ocultam as informações realmente importantes; por isso, concentro-me em ficheiros críticos, no comando `execve`, nas mudanças de privilégios e nas configurações relevantes para a segurança. Falta Uma rotação bem organizada; caso contrário, os sistemas ficam em risco, pelo que estabeleço limites claros quanto ao tamanho, ao número e às medidas a tomar em caso de estrangulamentos. I verifique também a configuração de auditoria e o diretório /var/log/audit/, porque os atacantes querem apagar os vestígios. E Documento cada regra com a chave, o objetivo e uma breve justificação, para que as análises se mantenham consistentes. Quem Quem tenha preocupações com o desempenho deve filtrar com precisão, eliminar percursos desnecessários e verificar primeiro, através de testes, o impacto das novas regras.

Desempenho, estabilidade e controlos de qualidade

Auditoria não deve atrasar o funcionamento. I verifica regularmente com auditctl -s, se perdido- Verifique se ocorrem eventos e acompanhe os valores do backlog após alterações nas regras. Em Em caso de elevado volume de eventos, aumento a fila do despachante (q_depth) dos plug-ins audispd e defina overflow_action conscientemente. Onde execve-Como as regras geram demasiado volume, limito-as através de auid ou através de exe=-Defina listas brancas/listas negras e, no caso de chamadas de sistema ruidosas, registe apenas as falhas. Antes de Antes da implementação em grande escala, valido as novas regras no ambiente de teste, avalio a taxa de eventos e a carga da CPU e comparo aureport --summary antes/depois da alteração, para quantificar o efeito.

Ambientes de contentores e virtualização

Em Para além dos hosts dos contentores, o kernel também regista os processos dos contentores – isto é intencional, mas pode gerar muito ruído. I baseio-me na proteção do anfitrião (por exemplo,. dockerd ou Podman), percursos binários e configurações seguras e filtrar a visualização do utilizador através de auid. Exemplos: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, além de regras genéricas de anfitrião, tais como execve com auid-Filtro. Em No que diz respeito às máquinas virtuais, trato os registos de auditoria como dados voláteis: ativo o reencaminhamento remoto, defino um intervalo curto para a rotação e, no caso dos instantâneos, presto atenção à consistência temporal. Importante É essencial que a sincronização NTP/Chrony seja precisa, para que as análises da linha do tempo sejam fiáveis.

Conformidade e manutenção de registos

Para De acordo com a norma ISO 27001 (n.º A.12.4 «Registo/Monitorização», n.º A.16 «Gestão de Incidentes», entre outros) e a norma PCI DSS (Capítulo 10), elaboro documentação comprovativa que pode ser verificada: O que É registado durante quanto tempo, quem tem acesso e como é garantida a integridade? I Mantenha a base de regras com versões, documente as chaves e as finalidades, assine os registos de arquivo com hashes e armazene-os de forma a impedir a sua manipulação. Em No que diz respeito aos dados pessoais, aplico o princípio da minimização de dados (regras específicas, prazos de conservação curtos) e defino processos claros de eliminação. Então São elaborados relatórios que convencem os auditores e que, em caso de incidente, fornecem efetivamente respostas.

Operações, monitorização e manuais de procedimentos

Em Para um trabalho contínuo, preciso de rotinas fixas: verificações diárias com aureport, alarmes em caso de perdido > 0, Verificar a partição de auditoria livre e o reencaminhamento remoto. I Criar Playbooks: „Executivos que se destacam“ (filtro por exe= e auid), „Ficheiro crítico alterado“ (correlacionar com PATH, SYSCALL, EXECVE), „Intervenção no kernel“ (regras relativas a init_module e montar). Conhecido Tipos de eventos como ANOM_PROMÍSCUO (Interface no modo promíscuo) ou MAC_POLICY_LOAD (Política MAC carregada) avalio por ordem de prioridade e inicio as etapas de resposta.

Resolução de problemas e reinício

Quando Se não chegarem eventos, verifico primeiro ausearch -m DAEMON -ts today e auditctl -s (Estado/Pendências). Falta Regras, vou carregá-las com augenrules --load novo e verifica com auditctl -l. É o modo imutável está ativo (-e 2), a única solução é reiniciar o sistema com regras de arranque ajustadas. Em Problemas de autorização em /var/log/audit/ Restauro o proprietário e o modo; caso o SELinux esteja ativo, corrijo os contextos. E Confirmo que log_format = RAW está definido – dados de entrada legíveis para análise forense e analisadores sintáticos.

Auditoria em ambientes de alojamento

Direto Em configurações de alojamento com muitas cargas de trabalho, o Auditd ajuda-me a garantir a transparência na separação de clientes e a detetar precocemente eventuais abusos. I Monitorizar servidores Web, de bases de dados e de aplicações com conjuntos de regras por níveis e integrar os eventos no sistema de monitorização e resposta a incidentes já existente. Para Asseguro uma separação clara através de um armazenamento centralizado, funções distintas e direitos restritos nas pastas de registos. Para Se necessário, recorro ao diagnóstico complementar do sistema journalctl para a resolução de problemas, mas mantenho as análises críticas para a segurança principalmente no canal de auditoria. Então cria-se uma pista de auditoria fiável que concilia os interesses dos clientes, os requisitos de conformidade e a eficiência operacional.

Em poucas palavras: o meu método

I Comece com uma visão clara do objetivo, formule regras específicas para ficheiros críticos, o comando `execve` e a alteração de privilégios, e proteja a rotação contra a perda de dados. Então Ativo o reencaminhamento remoto com TLS, registo as chaves e testo o efeito de cada regra antes de a implementar em grande escala. Para No meu trabalho diário, concentro-me em ausearch e aureport, realize pesquisas específicas e elabore relatórios claros para as áreas de operações e segurança. Em Quando deteto anomalias, cruzo os eventos de auditoria com outros sinais, como dados de processos ou de rede, para identificar rapidamente a causa. Então O Auditd do Linux não me fornece uma enxurrada de registos, mas sim respostas claras a questões relacionadas com a segurança em ambientes de produção.