Esta página foi traduzida pela API Cloud Translation.

Recolha registos de sistemas Linux auditd e AIX

Compatível com:

Google secops SIEM

Este analisador processa registos de auditoria do Linux no formato SYSLOG, transformando-os em UDM. Processa mensagens de registo formatadas em JSON e texto simples, extraindo campos através de técnicas de análise grok, XML e JSON, e mapeando-os para os campos UDM adequados com base no tipo de evento. O analisador também processa formatos de registos de auditoria específicos de sistemas AIX e enriquece o UDM com campos adicionais, como security_result e detalhes intermediários.

Antes de começar

Certifique-se de que tem uma instância do Google Security Operations.
Certifique-se de que tem acesso de raiz ao anfitrião do Auditd.
Certifique-se de que instalou o rsyslog no anfitrião do Auditd.
Certifique-se de que tem um anfitrião Windows 2012 SP2 ou posterior, ou Linux com systemd.
Se estiver a executar o serviço através de um proxy, certifique-se de que as portas da firewall estão abertas.

Obtenha o ficheiro de autenticação de carregamento do Google SecOps

Inicie sessão na consola Google SecOps.
Aceda a Definições do SIEM > Agentes de recolha.
Transfira o ficheiro de autenticação de carregamento.

Obtenha o ID de cliente do Google SecOps

Inicie sessão na consola Google SecOps.
Aceda a Definições do SIEM > Perfil.
Copie e guarde o ID do cliente da secção Detalhes da organização.

Instale o agente do Bindplane

Para a instalação do Windows, execute o seguinte script:
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
Para a instalação do Linux, execute o seguinte script:
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
Pode encontrar opções de instalação adicionais neste guia de instalação.

Configure o agente Bindplane para carregar o Syslog e enviá-lo para o Google SecOps

Aceda à máquina onde o Bindplane está instalado.

Edite o ficheiro config.yaml da seguinte forma:

receivers:
  tcplog:
    # Replace the below port <54525> and IP <0.0.0.0> with your specific values
    listen_address: "0.0.0.0:54525" 

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the creds location below according the placement of the credentials file you downloaded
        creds: '{ json file for creds }'
        # Replace <customer_id> below with your actual ID that you copied
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        # You can apply ingestion labels below as preferred
        ingestion_labels:
        log_type: SYSLOG
        namespace: auditd
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Reinicie o agente do Bindplane para aplicar as alterações através do seguinte comando: sudo systemctl bindplane restart

Exportar Syslog do Auditd

Aceda à máquina a partir da qual quer exportar os registos de auditoria.
Abra o ficheiro de configuração do Auditd (normalmente localizado em /etc/audit/auditd.conf).
```
sudo vi /etc/audit/auditd.conf
```

Encontre ou adicione as seguintes linhas para configurar o auditd:

active = yes
output = syslog
log_format = ENRICHED
dispatcher = /sbin/audispd

Opcional: especifique a funcionalidade Syslog: adicione ou modifique a seguinte linha em auditd.conf:

```none
syslog_facility = LOG_AUTHPRIV
```

Abra o ficheiro de configuração do audispd (normalmente localizado em /etc/audisp/plugins.d/syslog.conf):
```
sudo vi /etc/audisp/plugins.d/syslog.conf
```

Encontre ou adicione as seguintes linhas para configurar o audispd:

active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string

Reinicie o serviço Auditd para aplicar as alterações:
```
sudo systemctl restart auditd
```

Use uma ferramenta como tail para monitorizar o syslog e verificar se os registos do Auditd estão a ser enviados:

tail -f /var/log/syslog | grep auditd # Follow syslog and filter for auditd messages (path may vary depending on your system)

Edite o rsyslog.conf ou crie uma configuração personalizada:
```
sudo vi /etc/rsyslog.d/50-audit-forwarding.conf
```
Adicione uma regra para encaminhar registos:
- if $programname == 'auditd' then @@<Bindplane_Agent>:<Bindplane_Port>
- Use @ para UDP ou @@ para TCP
- Substitua <BindPlane_Agent> pelo IP/nome de anfitrião do seu servidor.
- Substitua <BindPlane_Port> pela porta do seu servidor.
Reinicie o serviço rsyslog para aplicar as alterações:
```
sudo systemctl restart rsyslog
```

Tabela de mapeamento do UDM

Campo de registo	Mapeamento do UDM	Observação
`acct`	`target.user.user_display_name`	O valor de `acct` do registo não processado é mapeado para o campo `target.user.user_display_name` no UDM. Isto representa a conta associada ao evento.
`addr`	`principal.ip`	O valor de `addr` do registo não processado é mapeado para o campo `principal.ip` no UDM. Isto representa o endereço IP do principal envolvido no evento.
`additional.fields`	`additional.fields`	Os campos adicionais dos pares de chave-valor ou das etiquetas analisados são adicionados à matriz `additional.fields` no UDM.
`agent.googleapis.com/log_file_path`	(Não mapeado)	Esta etiqueta está presente em alguns registos não processados, mas não está mapeada para o objeto IDM no UDM.
`algo`	(Não usado neste exemplo)	Embora esteja presente no analisador e em alguns registos não processados, este campo não é usado no exemplo fornecido e não aparece no UDM final.
`application`	`principal.application`	Derivado do campo `terminal` no registo não processado ou noutros campos, como `exe`, consoante o tipo de registo. Representa a aplicação envolvida.
`arch`	`security_result.about.platform_version`	A arquitetura do campo `arch` do registo não processado é mapeada para `security_result.about.platform_version`.
`auid`	`about.user.userid`, `security_result.detection_fields.auid`	O ID do utilizador de auditoria (`auid`) é mapeado para `about.user.userid` e adicionado como um campo de deteção em `security_result`.
`cmd`	`target.process.command_line`	O comando do campo `cmd` do registo não processado é mapeado para `target.process.command_line`.
`collection_time`	(Não mapeado)	Este campo é a hora de recolha do registo e não está mapeado para o objeto IDM no UDM.
`comm`	`principal.application`	O nome do comando (`comm`) está mapeado para `principal.application`.
`COMMAND`	`target.process.command_line`
`compute.googleapis.com/resource_name`	`principal.hostname`	O nome do recurso desta etiqueta está mapeado para `principal.hostname`.
`create_time`	(Não mapeado)	Este campo não está mapeado para o objeto IDM no UDM.
`cwd`	`security_result.detection_fields.cwd`	O diretório de trabalho atual (`cwd`) é adicionado como um campo de deteção em `security_result`.
`data`	(Processado)	O campo `data` contém a mensagem de registo principal e é processado pelo analisador para extrair vários campos. Não está diretamente mapeado para um único campo UDM.
`exe`	`target.process.file.full_path`	O caminho executável (`exe`) está mapeado para `target.process.file.full_path`.
`extensions.auth.type`	`extensions.auth.type`	O tipo de autenticação é definido pela lógica do analisador com base no tipo de evento. Muitas vezes, definido como `MACHINE` ou `AUTHTYPE_UNSPECIFIED`.
`fp`	`network.tls.client.certificate.sha256`	A impressão digital (`fp`) é analisada para extrair o hash SHA256 e mapeada para `network.tls.client.certificate.sha256`.
`_Item_Id`	`metadata.product_log_id`
`insertId`	(Não mapeado)	Este campo não está mapeado para o objeto IDM no UDM.
`jsonPayload.message`	(Processado)	Este campo contém a mensagem de registo principal no formato JSON e é processado pelo analisador.
`key`	`security_result.about.registry.registry_key`	O campo principal está mapeado para `security_result.about.registry.registry_key`.
`labels`	(Processado)	As etiquetas do registo não processado são processadas e mapeadas para vários campos da UDM ou adicionadas a `additional.fields`.
`logName`	(Não mapeado)	Este campo não está mapeado para o objeto IDM no UDM.
`metadata.product_event_type`	SECCOMP	A curva de troca de chaves é extraída do registo não processado e mapeada para este campo.
`msg`	`security_result.summary`	A mensagem (`msg`) é frequentemente usada para preencher o campo `security_result.summary`.
`network.application_protocol`	`network.application_protocol`	Definido pela lógica do analisador com base no tipo de evento (por exemplo, SSH e HTTP).
`network.direction`	`network.direction`	Definido pela lógica do analisador com base no tipo de evento (por exemplo, INBOUND e OUTBOUND).
`network.ip_protocol`	`network.ip_protocol`	Definido pela lógica do analisador, normalmente para TCP para eventos SSH.
`network.session_id`	`network.session_id`	Mapeado a partir do campo `ses` ou derivado de outros campos.
`network.tls.cipher`	`network.tls.cipher`	As informações de cifragem são extraídas do registo não processado e mapeadas para este campo.
`network.tls.curve`	`network.tls.curve`	A curva de troca de chaves é extraída do registo não processado e mapeada para este campo.
`pid`	`principal.process.pid`, `target.process.pid`	O ID do processo (`pid`) é mapeado para `principal.process.pid` ou `target.process.pid`, consoante o contexto.
`ppid`	`principal.process.parent_process.pid`, `target.process.parent_process.pid`	O ID do processo principal (`ppid`) é mapeado para `principal.process.parent_process.pid` ou `target.process.parent_process.pid`, consoante o contexto.
`principal.asset.hostname`	`principal.asset.hostname`	Copiado de `principal.hostname`.
`principal.asset.ip`	`principal.asset.ip`	Copiado de `principal.ip`.
`principal.platform`	`principal.platform`	Definido pela lógica do analisador com base no sistema operativo (por exemplo, LINUX).
`principal.port`	`principal.port`	O número da porta associado ao principal.
`principal.user.group_identifiers`	`principal.user.group_identifiers`	IDs de grupos associados ao utilizador principal.
`process.name`	`target.process.file.full_path`
`receiveTimestamp`	(Não mapeado)	Este campo é a data/hora de receção do registo e não está mapeado para o objeto IDM no UDM.
`res`	`security_result.action_details`	O resultado (`res`) está mapeado para `security_result.action_details`.
`_Resource_Id`	`target.resource.product_object_id`
`resource.labels`	(Não mapeado)	Estas etiquetas estão presentes em alguns registos não processados, mas não estão mapeadas para o objeto IDM no UDM.
`resource.type`	(Não mapeado)	Este campo está presente em alguns registos não processados, mas não está mapeado para o objeto IDM no UDM.
`security_result.action`	`security_result.action`	Definido pela lógica do analisador com base no campo `res` (por exemplo, PERMITIR ou BLOQUEAR).
`security_result.detection_fields`	`security_result.detection_fields`	Vários campos do registo não processado são adicionados como pares de chave-valor a esta matriz para contexto.
`security_result.rule_id`	`security_result.rule_id`	Definido pela lógica do analisador, muitas vezes para `type_name` para eventos de chamadas do sistema.
`security_result.severity`	`security_result.severity`	Definido pela lógica do analisador com base no nível de gravidade no registo não processado.
`security_result.summary`	`security_result.summary`	Um resumo do evento, muitas vezes derivado do campo `msg` ou de outros campos relevantes.
`ses`	`network.session_id`	O ID da sessão (`ses`) está mapeado para `network.session_id`.
`source`	(Não mapeado)	Este campo contém metadados sobre a origem do registo e não está mapeado para o objeto IDM no UDM.
`subj`	(Processado)	O campo de assunto (`subj`) é processado para extrair informações de contexto de utilizador e de segurança.
`syscall`	`security_result.about.labels.Syscall`	O número de chamada do sistema é adicionado como uma etiqueta em `security_result.about`.
`target.administrative_domain`	`target.administrative_domain`	O domínio do utilizador alvo.
`target.group.group_display_name`	`target.group.group_display_name`	O nome do grupo-alvo.
`target.ip`	`target.ip`	O endereço IP do destino.
`target.port`	`target.port`	O número da porta associado ao destino.
`target.process.command_line`	`target.process.command_line`	A linha de comandos do processo de destino.
`target.resource.type`	`target.resource.type`	O tipo do recurso de destino, definido pela lógica do analisador (por exemplo, CREDENTIAL, SETTING).
`target.user.attribute.permissions`	`target.user.attribute.permissions`	Autorizações relacionadas com o utilizador de destino.
`target.user.group_identifiers`	`target.user.group_identifiers`	IDs de grupos associados ao utilizador de destino.
`target.user.userid`	`target.user.userid`	O ID do utilizador do alvo.
`TenantId`	`metadata.product_deployment_id`
`textPayload`	(Processado)	A carga útil de texto do registo, processada pelo analisador para extrair vários campos.
`timestamp`	`metadata.event_timestamp`	A data/hora do evento.
`tty`	`security_result.about.labels.tty`	O TTY é adicionado como uma etiqueta em `security_result.about`.
`type`	`metadata.product_event_type`	O tipo de evento (`type`) está mapeado para `metadata.product_event_type`.
`uid`	`target.user.userid`	O ID do utilizador (`uid`) está mapeado para `target.user.userid`.

Referência delta do mapeamento de UDM

A 23 de setembro de 2025, o Google SecOps lançou uma nova versão do analisador Okta, que inclui alterações significativas ao mapeamento de campos de registo do Okta para campos UDM e alterações ao mapeamento de tipos de eventos.

Delta do mapeamento de campos de registo

A tabela seguinte indica o delta de mapeamento para os campos de registo do Okta expostos antes de 23 de setembro de 2025 e posteriormente (indicados nas colunas Mapeamento antigo e Mapeamento atual, respetivamente).

Campo de registo	Mapeamento antigo	Mapeamento atual	Exemplo de registo de referência
`1.1.1.1` (endereço IP)	`src.ip`	`principal.ip`	"<163>Apr 10 09:00:05 hostname.com sshd[3318513]: Accepted password for abc from 1.1.1.1 port 33988 ssh2"
`1.1.1.1` (endereço IP)	`principal.ip`	`target.ip`	"<29>Oct 5 08:37:16 abc ProxySG: E0000 Access Log HTTP (main): Connecting to server 1.1.1.1 on port 4433.(0) NORMAL_EVENT alog_stream_http.cpp 261"
`abc` (utilizador)	`principal.user.userid`	`target.user.userid`	"<85>Feb 27 08:26:55 offozcav login: FAILED LOGIN 1 FROM ::ffff:1.1.1.1 FOR abc, Authentication failure\r\n\r\n"
`abc.abc` (utilizador)	`principal.user.userid`	`target.user.userid`	"<86>Feb 27 08:29:19 offozcav login: LOGIN ON pts/43 BY abc.abc FROM\r\n\r\n::ffff:1.1.1.1"
`COMMAND`	`principal.process.command_line`	`target.process.command_line`	"<85>Sep 24 14:33:59 abc sudo: abc : \r\nTTY=unknown ; PWD=/abc ; USER=abc ; COMMAND=/sbin/iptables -t nat -nL \r\n--line-number"
`exe`	`target.process.file.full_path`	`principal.process.file.full_path`
`_ItemId`	`additional.fields`	`metadata.product_log_id`
`metadata.product_event_type`	`PATH`	`SECCOMP`
`process.name`	`principal.process.file.full_path`	`target.process.file.full_path`
`_ResourceId`	`additional.fields`	`target.resource.product_object_id`
`TenantId`	`additional.fields`	`metadata.product_deployment_id`
`uid`	`principal.user.userid`	`target.user.userid`
`USER`	`principal.user.user_display_name`	`target.user.userid`	"<85>Sep 24 14:33:59 abc sudo: abc : \r\nTTY=unknown ; PWD=/abc ; USER=abc ; COMMAND=/sbin/iptables -t nat -nL \r\n--line-number"
`user`	`principal.user.userid`	`target.user.userid`	"29>Jan 16 11:28:00 san-auth-1-irl2 tac_plus[17329]: login failure: user 1.1.1.1 (1.1.1.1) vty0"
`user`	`principal.user.userid`	`target.user.userid`	"<87>Jul 15 10:27:01 xpgjrconfdb01 crond[1045]: pam_unix(crond:account): expired password for user root (password aged)"

Delta de mapeamento de tipo de evento

Vários eventos que foram classificados anteriormente como eventos genéricos são agora classificados corretamente com tipos de eventos significativos.

A tabela seguinte lista a diferença no processamento dos tipos de eventos do Okta antes de 23 de setembro de 2025 e posteriormente (indicados nas colunas Old event_type e Current event-type, respetivamente).

eventType do registo	Old event_type	Current event_type
`aix_event_type=CRON_Start`	`USER_LOGIN`	`PROCESS_LAUNCH`
`CRYPTO_KEY_USER`	`NETWORK_CONNECTION`	`USER_LOGIN`
`FILE_Mknod`	`USER_LOGIN`	`FILE_CREATION`
`FILE_Rename`	`USER_LOGIN`	`FILE_MODIFICATION`
`FILE_Stat`	`USER_LOGIN`	`FILE_OPEN`
`FILE_Unlink`	`USER_LOGIN`	`FILE_DELETION`
`FS_Chabc`	`USER_LOGIN`	`PROCESS_UNCATEGORIZED`
`FS_Mkdir`	`USER_LOGIN`	`FILE_CREATION`
`FS_Rmdir`	`USER_LOGIN`	`FILE_DELETION`
`PROC_Execute`	`USER_LOGIN`	`PROCESS_LAUNCH`
`type=ANOM_ABEND`	`STATUS_UPDATE`	`PROCESS_TERMINATION`
`type=ANOM_PROMISCUOUS`		`SETTING_MODIFICATION`
`type=CRED_REFR`	`USER_LOGIN`	`USER_CHANGE_PERMISSIONS`
`type=PROCTILE`	`PROCESS_UNCATEGORIZED`	`PROCESS_LAUNCH`
`type=SERVICE_START`	`USER_RESOURCE_ACCESS`	`SERVICE_START`
`type=SERVICE_STOP`	`USER_RESOURCE_ACCESS`	`SERVICE_STOP`
`type=USER_ACCT`	`USER_LOGIN/SETTING_MODIFICTION`	`USER_LOGIN`
`type=USER_MGMT`	`SETTING_MODIFICATION/GROUP_MODIFICATION`	`GROUP_MODIFICATION`
`USER_ERR`	`USER_LOGOUT`	`USER_LOGIN`

Alterações adicionais

Foi removido o mapeamento duplicado de res de security_result.description. É captado em security_result.action_details.
Removemos o auditd_msg_data desnecessário dos campos adicionais.
auditd_msg_data desnecessário removido de security_result.summary.
Quando type=ADD_USER, removeu o mapeamento duplicado de acct para target.user.display_name. Já está mapeado em target.user.userid.
Foi removida a associação duplicada de comm de principal.process.command_line e principal.process.file.names. É captado em principal.application.
Mapeamento duplicado de target.hostname removido quando o valor está em principal.
Foi removido o mapeamento codificado desnecessário de target.resource.type para SETTING.
Foram removidos os mapeamentos de etiquetas acerca de, uma vez que estão descontinuados.
Mapeamento corrigido: os IPs encaminham agora para principal.ip e não para principal.hostname.
Foi corrigida a repetição de eventos gerados.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.