auditd_enable="YES"
Esta tradução pode estar desatualizada. Para ajudar com as traduções, acesse a ferramenta de traduções do FreeBSD .
O sistema operacional FreeBSD inclui suporte para auditoria de eventos de segurança. A auditoria de eventos oferece suporte a registros confiáveis, detalhados e configuráveis de diversos eventos do sistema relevantes para a segurança, incluindo logins, alterações de configuração e acesso a arquivos e rede. Esses registros de log podem ser inestimáveis para monitoramento de sistema em tempo real, detecção de intrusão e análise "post mortem". O FreeBSD implementa a Application Programming Interface (API) Basic Security Module (BSM) publicada pela Sun™ e o formato de arquivo, e é interoperável com as implementações de auditoria do Solaris™ e do Mac OS™ X.
Este capítulo se concentra na instalação e configuração da auditoria de eventos. Ele explica as políticas de auditoria e fornece um exemplo de configuração de auditoria.
Depois de ler este capítulo, você saberá:
O que é auditoria de eventos e como funciona.
Como configurar a auditoria de eventos no FreeBSD para usuários e processos.
Como revisar o caminho da auditoria usando as ferramentas de auditoria para redução e revisão.
Antes de ler este capítulo, você deve:
Entender os fundamentos do UNIX™ e do FreeBSD ( Fundamentos do FreeBSD ).
Familiarize-se com os conceitos básicos de configuração/compilação do kernel ( Configurando o kernel do FreeBSD ).
Ter alguma familiaridade com segurança e como ela está presente no FreeBSD ( Segurança ).
|
O recurso de auditoria possui algumas limitações conhecidas. Nem todos os eventos do sistema que são relevantes para a segurança são auditáveis, e também alguns mecanismos de login, como gerenciadores de exibição baseados em Xorg e daemons de terceiros, não configuram adequadamente a auditoria para sessões de login do usuário. O recurso de auditoria de eventos de segurança é capaz de gerar logs muito detalhados da atividade do sistema. Em um sistema muito utilizado, os dados do arquivo de rastreamento podem ser muito grandes quando configurados para grandes detalhes, excedendo gigabytes por semana em algumas configurações. Os administradores devem levar em consideração os requisitos de espaço em disco associados a configurações de auditoria de alto volume. Por exemplo, pode ser desejável dedicar um sistema de arquivos ao /var/audit para que outros sistemas de arquivos não sejam afetados se o sistema de arquivos de auditoria ficar cheio. |
Os termos a seguir estão relacionados a auditoria de eventos de segurança:
event : um evento auditável é qualquer evento que pode ser registrado usando o subsistema de auditoria. Exemplos de eventos relevantes para a segurança incluem a criação de um arquivo, a construção de uma conexão de rede ou o logon de um usuário. Os eventos são "atribuíveis", o que significa que podem ser rastreados para um usuário autenticado, ou "não atribuível". Exemplos de eventos não atribuíveis são eventos que ocorrem antes da autenticação no processo de login, como tentativas de senha incorreta.
class : um conjunto nomeado de eventos relacionados que são usados em expressões de seleção. As classes de eventos comumente usadas incluem "file creation" (fc), "exec" (ex), e "login_logout" (lo).
record : uma entrada de log de auditoria que descreve um evento de segurança. Os registros contêm um tipo de evento de registro, informações sobre o assunto (usuário) executando a ação, informações de data e hora, informações sobre quaisquer objetos ou argumentos e uma condição de sucesso ou falha.
trail : um arquivo de log que consiste em uma série de registros de auditoria que descrevem eventos de segurança. As trilhas estão em ordem cronológica aproximada com relação aos eventos concluídos. Apenas processos autorizados podem enviar registros para a trilha de auditoria.
selection expression : uma string contendo uma lista de prefixos e nomes de classes de eventos de auditoria usados para combinar eventos.
preselection : o processo pelo qual o sistema identifica quais eventos são de interesse do administrador. A configuração de pré-seleção usa uma série de expressões de seleção para identificar quais classes de eventos auditar quais usuários, bem como configurações globais que se aplicam a processos autenticados e não autenticados.
reduction : o processo pelo qual os registros das trilhas de auditoria existentes são selecionados para preservação, impressão ou análise. Da mesma forma, o processo pelo qual os registros de auditoria indesejados são removidos da trilha de auditoria. Usando a redução, os administradores podem implementar políticas para a preservação de dados de auditoria. Por exemplo, trilhas de auditoria detalhadas podem ser mantidas por um mês, mas depois disso, as trilhas podem ser reduzidas para preservar apenas as informações de login para fins de arquivamento.
O suporte para auditoria de eventos no espaço do usuário é instalado como parte do sistema operacional básico do FreeBSD. O suporte a kernel está disponível no kernel GENERIC por padrão, e auditd(8) pode ser ativado adicionando a seguinte linha no /etc/rc.conf :
auditd_enable="YES"
Em seguida, inicie o daemon de auditoria:
# service auditd startUsuários que preferem compilar um kernel personalizado devem incluir a seguinte linha em seu arquivo de configuração de kernel personalizado:
options AUDIT
Expressões de seleção são usadas em vários lugares na configuração de auditoria para determinar quais eventos devem ser auditados. Expressões contêm uma lista de classes de eventos para correspondência. As expressões de seleção são avaliadas da esquerda para a direita e duas expressões são combinadas, acrescentando uma à outra.
Classes de Eventos de Auditoria Padrão resume as classes de eventos de auditoria padrão:
| Nome da classe | Descrição | Ação |
|---|---|---|
|
all |
all |
Corresponde todas as classes de eventos. |
|
aa |
autenticação e autorização |
|
|
ad |
administrativo |
Ações administrativas executadas no sistema como um todo. |
|
ap |
aplicação |
Ação definida pela aplicação. |
|
cl |
file close |
Auditar chamadas para a chamada de sistema
|
|
ex |
exec |
Execução do programa de auditoria. Auditoria de argumentos de linha de comando e variáveis de ambiente são controladas via
audit_control(5)
usando os parâmetros
|
|
fa |
acesso ao atributo de arquivo |
Audite o acesso de atributos de objetos como stat(1) e pathconf(2) . |
|
fc |
file create |
Eventos de auditoria em que um arquivo é criado. |
|
fd |
file delete |
Eventos de auditoria onde ocorre a exclusão de arquivos. |
|
fm |
file attribute modify |
Eventos de auditoria onde ocorre a modificação do atributo do arquivo, como chown(8) , chflags(1) , e flock(2) . |
|
fr |
file read |
Eventos de auditoria nos quais dados são lidos ou arquivos são abertos para leitura. |
|
fw |
file write |
Eventos de auditoria nos quais os dados são gravados ou os arquivos são gravados ou modificados. |
|
io |
ioctl |
Auditar o uso da chamada de sistema
|
|
ip |
ipc |
Auditar várias formas de comunicação entre processos, incluindo pipes POSIX e operações IPC do System V. |
|
lo |
login_logout |
|
|
na |
não atribuível |
Auditar eventos não atribuíveis. |
|
no |
classe inválida |
Não coincidir com eventos de auditoria. |
|
nt |
rede (network) |
Eventos de auditoria relacionados a ações de rede, como connect(2) e accept(2) . |
|
ot |
outros |
Auditoria de eventos diversos. |
|
pc |
processo |
Essas classes de eventos de auditoria podem ser personalizadas modificando os arquivos de configuração audit_class e audit_event .
Cada classe de eventos de auditoria pode ser combinada com um prefixo indicando se as operações com êxito/falha são correspondidas e se a entrada está adicionando ou removendo a correspondência para a classe e o tipo. Prefixos para Classes de Eventos de Auditoria resume os prefixos disponíveis:
| Prefixo | Ação |
|---|---|
|
+ |
Auditoria de eventos bem sucedidos nesta classe. |
|
- |
Auditoria de eventos com falha nesta classe. |
|
^ |
Auditoria de eventos nem com sucesso e nem com falha nesta classe. |
|
^+ |
Não faça auditoria de eventos bem-sucedidos nesta classe. |
|
^- |
Não audite eventos com falha nesta classe. |
Se nenhum prefixo estiver presente, as instâncias com êxito e com falha do evento serão auditadas.
O seguinte exemplo de sequência de seleção seleciona eventos de login/logout bem-sucedidos e com falha, mas apenas eventos de execução bem-sucedidos:
lo,+ex
Os seguintes arquivos de configuração para auditoria de eventos de segurança são encontrados em /etc/security :
audit_class : contém as definições das classes de auditoria.
audit_control : controla os aspectos do subsistema de auditoria, como as classes de auditoria padrão, o espaço em disco mínimo a ser deixado no volume do log de auditoria e o tamanho máximo da trilha de auditoria.
audit_event : nomes e descrições textuais de eventos de auditoria do sistema e uma lista de quais classes cada evento está.
audit_user : requisitos de auditoria específicos do usuário a serem combinados com os padrões globais no login.
audit_warn : um script de shell personalizável usado pelo auditd(8) para gerar mensagens de aviso em situações excepcionais, como quando o espaço para registros de auditoria está baixo ou quando o arquivo de trilha de auditoria foi rotacionado.
|
Os arquivos de configuração de auditoria devem ser editados e mantidos com cuidado, pois erros na configuração podem resultar no registro inadequado de eventos. |
Na maioria dos casos, os administradores precisarão modificar apenas audit_control e audit_user . O primeiro arquivo controla as políticas e as propriedades de auditoria de todo o sistema, e o segundo arquivo pode ser usado para ajustar a auditoria pelo usuário.
Vários padrões para o subsistema de auditoria são especificados em audit_control :
dir:/var/audit dist:off flags:lo,aa minfree:5 naflags:lo,aa policy:cnt,argv filesz:2M expire-after:10M
A entrada
dir
é usada para definir um ou mais diretórios onde os logs de auditoria serão armazenados. Se mais de uma entrada de diretório aparecer, elas serão usadas em ordem à medida que forem preenchidas. É comum configurar a auditoria para que os logs de auditoria sejam armazenados em um sistema de arquivos dedicado, para evitar a interferência entre o subsistema de auditoria e outros subsistemas, se o sistema de arquivos encher.
Se o campo
dist
estiver definido como
on
ou
yes
, os links físicos serão criados para todos os arquivos de rastreio em
/var/audit/dist
.
O campo
flags
define a máscara de pré-seleção padrão para todo o sistema para eventos atribuíveis. No exemplo acima, eventos de login/logout bem-sucedidos e com falha, bem como autenticação e autorização, são auditados para todos os usuários.
A entrada
minfree
define a porcentagem mínima de espaço livre para o sistema de arquivos no qual a trilha de auditoria está armazenada.
A entrada
naflags
especifica as classes de auditoria a serem auditadas para eventos não atribuídos, como o processo de login/logout e autenticação e autorização.
A entrada
policy
especifica uma lista separada por vírgula de sinalizadores de política que controla vários aspectos do comportamento de auditoria. O
cnt
indica que o sistema deve continuar em execução apesar de uma falha de auditoria (este sinalizador é altamente recomendado). O outro sinalizador,
argv
, faz com que os argumentos da linha de comando para a chamada de sistema
execve(2)
sejam auditados como parte de execução de comando.
A entrada
filesz
especifica o tamanho máximo para uma trilha de auditoria antes de finalizar e rotacionar automaticamente o arquivo de trilha. Um valor de
0
desabilita a rotação automática de log. Se o tamanho do arquivo solicitado estiver abaixo do mínimo de 512k, ele será ignorado e uma mensagem de log será gerada.
O campo
expire-after
especifica quando os arquivos de log de auditoria expirarão e serão removidos.
O administrador pode especificar requisitos adicionais de auditoria para usuários específicos em
audit_user
. Cada linha configura a auditoria para um usuário através de dois campos: o campo
alwaysaudit
especifica um conjunto de eventos que devem sempre ser auditados para o usuário, e o campo
neveraudit
especifica um conjunto de eventos que nunca devem ser auditados para o usuário.
As entradas de exemplo a seguir auditam os eventos de login/logout e a execução bem-sucedida do comando para
root
e criação de arquivos e execução de comando bem-sucedida para
www
. Se usado com o
audit_control
, a entrada
lo
para
root
é redundante, e os eventos login/logout também serão auditados para
www
.
root:lo,+ex:no www:fc,+ex:no
Como as trilhas de auditoria são armazenadas no formato binário BSM, várias ferramentas internas estão disponíveis para modificar ou converter essas trilhas em texto. Para converter arquivos de trilha em um formato de texto simples, use o
praudit
. Para reduzir o arquivo de trilha de auditoria para fins de análise, arquivamento ou impressão, use o
auditreduce
. Esse utilitário suporta vários parâmetros de seleção, incluindo tipo de evento, classe de evento, usuário, data ou hora do evento e o caminho ou objeto do arquivo em questão.
Por exemplo, para baixar todo o conteúdo de um log de auditoria especificado em texto simples:
# praudit /var/audit/AUDITFILEOnde AUDITFILE é o log de auditoria a ser descarregado.
As trilhas de auditoria consistem em uma série de registros de auditoria compostos por tokens, em que o
praudit
imprime sequencialmente, um por linha. Cada token é de um tipo específico, como
header
(um cabeçalho de registro de auditoria) ou
path
(um caminho de arquivo de uma pesquisa de nome). O seguinte é um exemplo de um evento
execve
:
header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec exec arg,finger,doug path,/usr/bin/finger attribute,555,root,wheel,90,24918,104944 subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100 return,success,0 trailer,133
Esta auditoria representa uma chamada
execve
bem-sucedida, na qual o comando
finger doug
foi executado. O token
exec arg
contém a linha de comando processada apresentada pelo shell ao kernel. O token
path
contém o caminho para o executável conforme procurado pelo kernel. O token
attribute
descreve o binário e inclui o modo de arquivo. O token
subject
armazena o ID do usuário de auditoria, ID do usuário e ID do grupo, ID do usuário real e ID do grupo, ID do processo, ID da sessão, ID da porta e endereço de login. Observe que o ID do usuário de auditoria e o ID do usuário real são diferentes quando o usuário
robert
mudou para a conta
root
antes de executar este comando, mas é auditado usando o usuário original autenticado. O token
return
indica a execução bem-sucedida e o
trailer
conclui o registro.
O formato de saída XML também é suportado e pode ser selecionado incluindo
-x
.
Como os logs de auditoria podem ser muito grandes, um subconjunto de registros pode ser selecionado usando
auditreduce
. Este exemplo seleciona todos os registros de auditoria produzidos para o usuário
trhodes
armazenados em
AUDITFILE
:
# auditreduce -u trhodes /var/audit/AUDITFILE | praudit
Os membros do grupo
audit
têm permissão para ler trilhas de auditoria em
/var/audit
. Por padrão, esse grupo está vazio, portanto, apenas o usuário
root
pode ler trilhas de auditoria. Os usuários podem ser adicionados ao grupo
auditoria
para delegar direitos de revisão de auditoria. Como a capacidade de rastrear o conteúdo do log de auditoria fornece informações significativas sobre o comportamento dos usuários e processos, recomenda-se que a delegação dos direitos de revisão de auditoria seja executada com cautela.
Pipes de auditoria são pseudo-dispositivos clones que permitem que os aplicativos acessem o fluxo de registro de auditoria em tempo real. Isto é principalmente de interesse para os autores de aplicações de detecção de intrusão e monitoramento de sistemas. No entanto, o dispositivo de canal de auditoria é uma maneira conveniente para o administrador permitir o monitoramento ao vivo sem incorrer em problemas com a propriedade do arquivo de trilha de auditoria ou a rotação de log interrompendo o fluxo de eventos. Para acompanhar o fluxo de eventos de auditoria em tempo real:
# praudit /dev/auditpipe
Por padrão, os nós de dispositivo dos pipes de auditoria são acessíveis apenas para o usuário
root
. Para torná-los acessíveis aos membros do grupo
audit
, adicione uma regra
devfs
para
/etc/devfs.rules
:
add path 'auditpipe*' mode 0440 group audit
Veja devfs.rules(5) para mais informações sobre como configurar o sistema de arquivos devfs.
|
É fácil produzir ciclos de feedback de evento de auditoria, nos quais a visualização de cada evento de auditoria resulta na geração de mais eventos de auditoria. Por exemplo, se toda a rede I/O for auditada e
|
As trilhas de auditoria são gravadas pelo kernel e gerenciadas pelo daemon de auditoria,
auditd(8)
. Os administradores não devem tentar usar o
newsyslog.conf(5)
ou outras ferramentas para rotacionar diretamente os logs de auditoria. Em vez disso, o
audit
deve ser usado para encerrar a auditoria, reconfigurar o sistema de auditoria e executar a rotação de log. O comando a seguir faz com que o daemon de auditoria crie um novo log de auditoria e sinalize ao kernel para alternar para o novo log. O log antigo será finalizado e renomeado, podendo então ser manipulado pelo administrador:
# audit -nSe auditd(8) não estiver em execução no momento, este comando falhará e uma mensagem de erro será apresentada.
Adicionar a seguinte linha ao /etc/crontab agendará essa rotação a cada doze horas:
0 */12 * * * root /usr/sbin/audit -n
A alteração terá efeito quando o /etc/crontab for salvo.
A rotação automática do arquivo de trilha de auditoria com base no tamanho do arquivo é possível usando
filesz
em
audit_control
, conforme descrito em
O arquivo
audit_control
.
Como os arquivos de trilha de auditoria podem se tornar muito grandes, geralmente é desejável compactar ou arquivar rastros depois que eles forem fechados pelo daemon de auditoria. O script audit_warn pode ser usado para executar operações personalizadas para uma variedade de eventos relacionados à auditoria, incluindo a terminação limpa de trilhas de auditoria quando elas são rotacionadas. Por exemplo, o seguinte pode ser adicionado ao /etc/security/audit_warn para compactar as trilhas de auditoria ao serem fechados:
#
# Compress audit trail files on close.
#
if [ "$1" = closefile ]; then
gzip -9 $2
fi
Outras atividades de arquivamento podem incluir a cópia de arquivos de trilha para um servidor centralizado, a exclusão de arquivos de trilha antigos ou a redução da trilha de auditoria para remover registros desnecessários. Este script será executado somente quando os arquivos da trilha de auditoria forem finalizados de forma limpa, portanto, não serão executados em trilhas deixadas sem serem eliminadas após um desligamento incorreto.
Última alteração em : 18 de fevereiro de 2025 por Fernando Apesteguía