Cette page a été traduite par l'API Cloud Translation.

Collecter les journaux système Linux auditd et AIX

Compatible avec :

Google SecOps SIEM

Cet analyseur gère les journaux d'audit Linux au format SYSLOG et les transforme en UDM. Il traite les messages de journaux au format JSON et en texte brut, extrait les champs à l'aide des techniques d'analyse grok, XML et JSON, et les mappe aux champs UDM appropriés en fonction du type d'événement. L'analyseur gère également les formats de journaux d'audit spécifiques des systèmes AIX et enrichit l'UDM avec des champs supplémentaires tels que security_result et des informations intermédiaires.

Avant de commencer

Assurez-vous de disposer d'une instance Google Security Operations.
Assurez-vous de disposer d'un accès racine à l'hôte Auditd.
Assurez-vous d'avoir installé rsyslog sur l'hôte Auditd.
Assurez-vous de disposer d'un hôte Windows 2012 SP2 ou version ultérieure, ou d'un hôte Linux avec systemd.
Si vous exécutez le programme derrière un proxy, assurez-vous que les ports du pare-feu sont ouverts.

Obtenir le fichier d'authentification d'ingestion Google SecOps

Connectez-vous à la console Google SecOps.
Accédez à Paramètres SIEM > Agents de collecte.
Téléchargez le fichier d'authentification d'ingestion.

Obtenir l'ID client Google SecOps

Connectez-vous à la console Google SecOps.
Accédez à Paramètres SIEM > Profil.
Copiez et enregistrez le numéro client de la section Informations sur l'organisation.

Installer l'agent BindPlane

Pour installer sous Windows, exécutez le script suivant :
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
Pour installer sous Linux, exécutez le script suivant :
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
Vous trouverez d'autres options d'installation dans ce guide d'installation.

Configurer l'agent Bindplane pour ingérer les journaux Syslog et les envoyer à Google SecOps

Accédez à la machine sur laquelle Bindplane est installé.

Modifiez le fichier config.yaml comme suit :

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

Redémarrez l'agent Bindplane pour appliquer les modifications à l'aide de la commande suivante : sudo systemctl bindplane restart

Exporter Syslog depuis Auditd

Accédez à la machine à partir de laquelle vous souhaitez exporter les journaux d'audit.
Ouvrez le fichier de configuration Auditd (généralement situé à l'adresse /etc/audit/auditd.conf).
```
sudo vi /etc/audit/auditd.conf
```

Recherchez ou ajoutez la ou les lignes suivantes pour configurer auditd :

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

Facultatif : Spécifiez la fonctionnalité Syslog : ajoutez ou modifiez la ligne suivante dans auditd.conf :

```none
syslog_facility = LOG_AUTHPRIV
```

Remarque : Les installations courantes incluent LOG_AUTHPRIV (pour les messages de sécurité/d'autorisation), LOG_LOCAL0 à LOG_LOCAL7 (pour les applications personnalisées).

Ouvrez le fichier de configuration audispd (généralement situé sous /etc/audisp/plugins.d/syslog.conf) :
```
sudo vi /etc/audisp/plugins.d/syslog.conf
```

Recherchez ou ajoutez la ou les lignes suivantes pour configurer audispd :

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

Redémarrez le service Auditd pour appliquer les modifications :
```
sudo systemctl restart auditd
```

Utilisez un outil tel que tail pour surveiller le syslog et vérifier que les journaux Auditd sont envoyés :

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

Modifiez le rsyslog.conf ou créez une configuration personnalisée :
```
sudo vi /etc/rsyslog.d/50-audit-forwarding.conf
```
Ajoutez une règle pour transférer les journaux :
- if $programname == 'auditd' then @@<Bindplane_Agent>:<Bindplane_Port>
- Utilisez @ pour UDP ou @@ pour TCP.
- Remplacez <BindPlane_Agent> par l'adresse IP ou le nom d'hôte de votre serveur.
- Remplacez <BindPlane_Port> par le port de votre serveur.
Redémarrez le service rsyslog pour appliquer les modifications :
```
sudo systemctl restart rsyslog
```

Table de mappage UDM

Champ du journal	Mappage UDM	Remarque
`acct`	`target.user.user_display_name`	La valeur de `acct` du journal brut est mappée sur le champ `target.user.user_display_name` de l'UDM. Il s'agit du compte associé à l'événement.
`addr`	`principal.ip`	La valeur de `addr` du journal brut est mappée sur le champ `principal.ip` de l'UDM. Il s'agit de l'adresse IP du compte principal impliqué dans l'événement.
`additional.fields`	`additional.fields`	Les champs supplémentaires issus des paires clé-valeur ou des libellés analysés sont ajoutés au tableau `additional.fields` dans l'UDM.
`agent.googleapis.com/log_file_path`	(Non mappé)	Ce libellé est présent dans certains journaux bruts, mais n'est pas mappé à l'objet IDM dans l'UDM.
`algo`	(Non utilisé dans cet exemple)	Bien que présent dans l'analyseur et certains journaux bruts, ce champ n'est pas utilisé dans l'exemple fourni et n'apparaît pas dans l'UDM final.
`application`	`principal.application`	Dérivé du champ `terminal` dans le journal brut ou d'autres champs tels que `exe`, selon le type de journal. Représente l'application concernée.
`arch`	`security_result.about.platform_version`	L'architecture du champ `arch` du journal brut est mappée sur `security_result.about.platform_version`.
`auid`	`about.user.userid`, `security_result.detection_fields.auid`	L'ID utilisateur de l'audit (`auid`) est mappé à `about.user.userid` et ajouté en tant que champ de détection dans `security_result`.
`cmd`	`target.process.command_line`	La commande du champ `cmd` du journal brut est mappée sur `target.process.command_line`.
`collection_time`	(Non mappé)	Ce champ correspond à l'heure de collecte des journaux et n'est pas mappé à l'objet IDM dans l'UDM.
`comm`	`principal.application`	Le nom de la commande (`comm`) est mappé sur `principal.application`.
`COMMAND`	`target.process.command_line`
`compute.googleapis.com/resource_name`	`principal.hostname`	Le nom de ressource de ce libellé est mappé sur `principal.hostname`.
`create_time`	(Non mappé)	Ce champ n'est pas mappé à l'objet IDM dans l'UDM.
`cwd`	`security_result.detection_fields.cwd`	Le répertoire de travail actuel (`cwd`) est ajouté en tant que champ de détection dans `security_result`.
`data`	(Traitée)	Le champ `data` contient le message de journal principal et est traité par l'analyseur pour extraire différents champs. Il n'est pas directement mappé sur un seul champ UDM.
`exe`	`target.process.file.full_path`	Le chemin d'accès exécutable (`exe`) est mappé sur `target.process.file.full_path`.
`extensions.auth.type`	`extensions.auth.type`	Le type d'authentification est défini par la logique du parseur en fonction du type d'événement. Souvent défini sur `MACHINE` ou `AUTHTYPE_UNSPECIFIED`.
`fp`	`network.tls.client.certificate.sha256`	L'empreinte (`fp`) est analysée pour extraire le hachage SHA256 et est mappée sur `network.tls.client.certificate.sha256`.
`_Item_Id`	`metadata.product_log_id`
`insertId`	(Non mappé)	Ce champ n'est pas mappé à l'objet IDM dans l'UDM.
`jsonPayload.message`	(Traitée)	Ce champ contient le message de journal principal au format JSON et est traité par l'analyseur.
`key`	`security_result.about.registry.registry_key`	Le champ clé est mappé sur `security_result.about.registry.registry_key`.
`labels`	(Traitée)	Les libellés du journal brut sont traités et mappés à différents champs UDM ou ajoutés à `additional.fields`.
`logName`	(Non mappé)	Ce champ n'est pas mappé à l'objet IDM dans l'UDM.
`metadata.product_event_type`	SECCOMP	La courbe d'échange de clés est extraite du journal brut et mappée à ce champ.
`msg`	`security_result.summary`	Le message (`msg`) est souvent utilisé pour remplir le champ `security_result.summary`.
`network.application_protocol`	`network.application_protocol`	Définie par la logique de l'analyseur en fonction du type d'événement (par exemple, SSH, HTTP).
`network.direction`	`network.direction`	Définie par la logique de l'analyseur en fonction du type d'événement (par exemple, INBOUND, OUTBOUND).
`network.ip_protocol`	`network.ip_protocol`	Défini par la logique du parseur, généralement sur TCP pour les événements SSH.
`network.session_id`	`network.session_id`	Mappé à partir du champ `ses` ou dérivé d'autres champs.
`network.tls.cipher`	`network.tls.cipher`	Les informations sur le chiffrement sont extraites du journal brut et mappées à ce champ.
`network.tls.curve`	`network.tls.curve`	La courbe d'échange de clés est extraite du journal brut et mappée à ce champ.
`pid`	`principal.process.pid`, `target.process.pid`	L'ID de processus (`pid`) est mappé sur `principal.process.pid` ou `target.process.pid` en fonction du contexte.
`ppid`	`principal.process.parent_process.pid`, `target.process.parent_process.pid`	L'ID du processus parent (`ppid`) est mappé sur `principal.process.parent_process.pid` ou `target.process.parent_process.pid` en fonction du contexte.
`principal.asset.hostname`	`principal.asset.hostname`	Copié depuis `principal.hostname`.
`principal.asset.ip`	`principal.asset.ip`	Copié depuis `principal.ip`.
`principal.platform`	`principal.platform`	Défini par la logique de l'analyseur en fonction du système d'exploitation (par exemple, LINUX).
`principal.port`	`principal.port`	Numéro de port associé au compte principal.
`principal.user.group_identifiers`	`principal.user.group_identifiers`	ID de groupe associés à l'utilisateur principal.
`process.name`	`target.process.file.full_path`
`receiveTimestamp`	(Non mappé)	Ce champ correspond au code temporel de réception du journal et n'est pas mappé à l'objet IDM dans l'UDM.
`res`	`security_result.action_details`	Le résultat (`res`) est mappé sur `security_result.action_details`.
`_Resource_Id`	`target.resource.product_object_id`
`resource.labels`	(Non mappé)	Ces libellés sont présents dans certains journaux bruts, mais ne sont pas mappés à l'objet IDM dans l'UDM.
`resource.type`	(Non mappé)	Ce champ est présent dans certains journaux bruts, mais n'est pas mappé à l'objet IDM dans l'UDM.
`security_result.action`	`security_result.action`	Définie par la logique de l'analyseur en fonction du champ `res` (par exemple, ALLOW, BLOCK).
`security_result.detection_fields`	`security_result.detection_fields`	Divers champs du journal brut sont ajoutés à ce tableau sous forme de paires clé-valeur pour le contexte.
`security_result.rule_id`	`security_result.rule_id`	Défini par la logique du parseur, souvent sur `type_name` pour les événements syscall.
`security_result.severity`	`security_result.severity`	Défini par la logique du parseur en fonction du niveau de gravité dans le journal brut.
`security_result.summary`	`security_result.summary`	Résumé de l'événement, souvent dérivé du champ `msg` ou d'autres champs pertinents.
`ses`	`network.session_id`	L'ID de session (`ses`) est mappé sur `network.session_id`.
`source`	(Non mappé)	Ce champ contient des métadonnées sur la source du journal et n'est pas mappé à l'objet IDM dans l'UDM.
`subj`	(Traitée)	Le champ "Objet" (`subj`) est traité pour extraire des informations sur le contexte utilisateur et de sécurité.
`syscall`	`security_result.about.labels.Syscall`	Le numéro de syscall est ajouté en tant que libellé dans `security_result.about`.
`target.administrative_domain`	`target.administrative_domain`	Domaine de l'utilisateur cible.
`target.group.group_display_name`	`target.group.group_display_name`	Nom du groupe cible.
`target.ip`	`target.ip`	Adresse IP de la cible.
`target.port`	`target.port`	Numéro de port associé à la cible.
`target.process.command_line`	`target.process.command_line`	Ligne de commande du processus cible.
`target.resource.type`	`target.resource.type`	Type de la ressource cible, défini par la logique de l'analyseur (par exemple, CREDENTIAL, SETTING).
`target.user.attribute.permissions`	`target.user.attribute.permissions`	Autorisations associées à l'utilisateur cible.
`target.user.group_identifiers`	`target.user.group_identifiers`	ID de groupe associés à l'utilisateur cible.
`target.user.userid`	`target.user.userid`	ID utilisateur de la cible.
`TenantId`	`metadata.product_deployment_id`
`textPayload`	(Traitée)	Charge utile de texte du journal, traitée par l'analyseur pour extraire différents champs.
`timestamp`	`metadata.event_timestamp`	Horodatage de l'événement.
`tty`	`security_result.about.labels.tty`	Le TTY est ajouté en tant que libellé dans `security_result.about`.
`type`	`metadata.product_event_type`	Le type d'événement (`type`) est mappé sur `metadata.product_event_type`.
`uid`	`target.user.userid`	L'ID utilisateur (`uid`) est mappé sur `target.user.userid`.

Référence du delta de mappage UDM

Le 23 septembre 2025, Google SecOps a publié une nouvelle version de l'analyseur Okta, qui inclut des modifications importantes concernant le mappage des champs de journaux Okta vers les champs UDM et le mappage des types d'événements.

Delta de mappage entre les champs de journaux

Le tableau suivant répertorie le delta de mappage pour les champs de journaux Okta vers UDM exposés avant le 23 septembre 2025 et après (listés respectivement dans les colonnes Ancien mappage et Mappage actuel).

Champ du journal	Ancienne correspondance	Mappage actuel	Exemple de journal de référence
`1.1.1.1` (adresse 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` (adresse 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` (utilisateur)	`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` (utilisateur)	`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 mappage des types d'événements

Plusieurs événements qui étaient auparavant classés comme événements génériques sont désormais correctement classés avec des types d'événements pertinents.

Le tableau suivant liste le delta pour la gestion des types d'événements Okta avant le 23 septembre 2025 et après (listés respectivement dans les colonnes Ancien event_type et event_type actuel).

eventType from log	Ancien 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`

Autres modifications

Suppression du mappage en double de res à partir de security_result.description. Il est enregistré dans security_result.action_details.
Suppression de auditd_msg_data inutile des champs supplémentaires.
Suppression de auditd_msg_data inutile de security_result.summary.
Lorsque type=ADD_USER, le mappage en double de acct vers target.user.display_name a été supprimé. Il est déjà mappé sous target.user.userid.
Suppression du mappage en double de comm à partir de principal.process.command_line et principal.process.file.names. Il est enregistré dans principal.application.
Suppression du mappage en double de target.hostname lorsque la valeur est présente dans principal.
Suppression du mappage codé en dur inutile de target.resource.type vers SETTING.
Suppression des mappages de libellés "À propos" qui sont obsolètes.
Mappage corrigé : les adresses IP sont désormais routées vers principal.ip et non vers principal.hostname.
Correction de la répétition des événements générés.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.