Collecter les journaux Infoblox

Compatible avec:

Ce document explique comment collecter des journaux Infoblox à l'aide d'un transfert Google Security Operations.

Pour en savoir plus, consultez Ingestion de données dans Google Security Operations.

Un libellé d'ingestion identifie l'analyseur qui normalise les données de journal brutes au format UDM structuré. Les informations présentées dans ce document s'appliquent à l'analyseur avec le libellé d'ingestion INFOBLOX_DNS.

Configurer Infoblox

  1. Connectez-vous à l'interface utilisateur Web d'Infoblox.
  2. Dans l'UI Web Infoblox, sélectionnez System (Système) > System properties editor (Éditeur de propriétés système) > Monitoring (Surveillance).
  3. Cochez la case Journaliser sur des serveurs syslog externes.
  4. Dans la section External syslog servers (Serveurs Syslog externes), cliquez sur le signe plus (+) pour ajouter un serveur Syslog pour le transfert Google Security Operations.
  5. Dans le champ Address (Adresse), saisissez l'adresse IP du serveur de transfert Google Security Operations.
  6. Dans la liste Transport, sélectionnez TCP ou UDP.
  7. Dans le champ Port, saisissez le numéro de port.
  8. Dans la liste ID de nœud, sélectionnez LAN pour inclure l'adresse IP Infoblox dans l'en-tête syslog.
  9. Dans la liste Disponibles, sélectionnez les éléments suivants, puis déplacez-les vers la liste Sélectionnés :
    • Requêtes DNS
    • Réponses DNS
    • Processus DHCP

Le serveur Infoblox transfère les journaux de requêtes et de réponses à l'aide de syslog au transmetteur Google Security Operations.

Configurer le transfert Google Security Operations et le protocole syslog pour ingérer les journaux Infoblox

  1. Sélectionnez Paramètres du SIEM > Transferts.
  2. Cliquez sur Ajouter un forwarder.
  3. Saisissez un nom unique dans le champ Nom du transmettant.
  4. Cliquez sur Envoyer, puis sur Confirmer. Le forwarder est ajouté, et la fenêtre Ajouter une configuration de collecteur s'affiche.
  5. Dans le champ Nom du collecteur, saisissez un nom unique pour le collecteur.
  6. Sélectionnez Infoblox comme type de journal.
  7. Sélectionnez Syslog comme type de collecteur.
  8. Configurez les paramètres d'entrée suivants :
    • Protocole: spécifiez le protocole de connexion que le collecteur utilisera pour écouter les données syslog.
    • Address (Adresse) : spécifiez l'adresse IP ou le nom d'hôte cible où le collecteur réside et écoute les données syslog.
    • Port: spécifiez le port cible sur lequel se trouve le collecteur et qui écoute les données syslog.
  9. Cliquez sur Envoyer.

Pour en savoir plus sur les transferts Google Security Operations, consultez la documentation sur les transferts Google Security Operations. Pour en savoir plus sur les exigences de chaque type de forwarder, consultez la section Configuration du forwarder par type.

Si vous rencontrez des problèmes lors de la création de transmetteurs, contactez l'assistance Google Security Operations.

Référence du mappage de champs

Cet analyseur extrait les journaux DNS Infoblox au format SYSLOG ou CEF, et les normalise en UDM. Il gère différents formats de journaux à l'aide de modèles Grok, extrait des champs clés tels que l'adresse IP source ou de destination, les détails des requêtes DNS et les informations de sécurité, et les met en correspondance avec les champs UDM appropriés.

Tableau de mappage UDM

Champ de journal Mappage UDM Logique
agent.hostname principal.hostname Pour les journaux au format CEF, si agent.hostname existe, il est mappé sur principal.hostname.
client_ip principal.ip Pour les journaux au format CEF, si client_ip existe, il est mappé sur principal.ip.
client_port principal.port Pour les journaux au format CEF, si client_port existe, il est mappé sur principal.port.
data answers.data Extrait du champ data de la section answers dans le journal brut. Plusieurs occurrences sont mappées en tant qu'objets answers distincts.
description metadata.description Mappées directement à partir du champ description du journal brut ou extraites à l'aide de modèles Grok à partir d'autres champs tels que message et msg2.
dest_ip1 target.ip Extrait du journal brut et mappé sur target.ip.
destinationDnsDomain dns_question.name Pour les journaux au format CEF, si destinationDnsDomain existe, il est mappé sur dns_question.name.
dns_class dns_question.class Mappé à l'aide de la table de recherche dns_query_class_mapping.include.
dns_domain dns_question.name Extrait du champ message du journal brut à l'aide de modèles Grok et mappé sur dns_question.name.
dns_name dns_question.name Extrait du champ dns_domain à l'aide de modèles Grok et mappé sur dns_question.name.
dns_records answers.data Pour les journaux au format CEF, si dns_records existe, il est mappé sur answers.data. Plusieurs occurrences sont mappées en tant qu'objets answers distincts.
dst_ip target.ip ou target.hostname Extrait du champ message du journal brut à l'aide de modèles Grok. S'il s'agit d'une adresse IP valide, elle est mappée sur target.ip. Dans le cas contraire, elle est mappée sur target.hostname.
dst_ip1 target.ip ou target.hostname Extrait du champ message ou msg2 du journal brut à l'aide de modèles Grok. S'il s'agit d'une adresse IP valide, elle est mappée sur target.ip. Dans le cas contraire, elle est mappée sur target.hostname. Mappé uniquement s'il est différent de dst_ip.
evt_type metadata.product_event_type Mappé directement à partir du champ evt_type du journal brut, qui est extrait du champ message à l'aide de modèles Grok.
InfobloxB1OPHIPAddress principal.ip Pour les journaux au format CEF, si InfobloxB1OPHIPAddress existe, il est mappé sur principal.ip.
InfobloxB1Region principal.location.country_or_region Pour les journaux au format CEF, si InfobloxB1Region existe, il est mappé sur principal.location.country_or_region.
InfobloxDNSQType dns_question.type Pour les journaux au format CEF, si InfobloxDNSQType existe, il est mappé sur dns_question.type.
intermediary intermediary.ip ou intermediary.hostname Extrait du champ message du journal brut à l'aide de modèles Grok. S'il s'agit d'une adresse IP valide, elle est mappée sur intermediary.ip. Dans le cas contraire, elle est mappée sur intermediary.hostname.
msg2 metadata.description, dns.response_code, dns_question.name, target.ip, target.hostname, answers.name, answers.ttl, answers.data, answers.class, answers.type, security_result.severity Extrait du champ message du journal brut à l'aide de modèles Grok. Utilisé pour extraire divers champs, mais pas directement mappés sur l'UDM.
name1 answers.name Extrait du champ msg2 du journal brut à l'aide de modèles Grok et mappé sur answers.name.
name2 answers.name Extrait du champ msg2 du journal brut à l'aide de modèles Grok et mappé sur answers.name.
protocol network.ip_protocol Mappé directement à partir du champ protocol du journal brut s'il correspond à des protocoles connus.
qclass dns_question.class Champ intermédiaire utilisé pour mapper dns_class à UDM.
qclass1 answers.class Champ intermédiaire utilisé pour mapper dns_class1 à UDM.
qclass2 answers.class Champ intermédiaire utilisé pour mapper dns_class2 à UDM.
query_type dns_question.type Mappé à l'aide de la table de recherche dns_record_type.include.
query_type1 answers.type Mappé à l'aide de la table de recherche dns_record_type.include.
query_type2 answers.type Mappé à l'aide de la table de recherche dns_record_type.include.
recursion_flag network.dns.recursion_desired Si recursion_flag contient un "+", il est mappé sur network.dns.recursion_desired en tant que valeur "true".
record_type dns_question.type Champ intermédiaire utilisé pour mapper query_type à UDM.
record_type1 answers.type Champ intermédiaire utilisé pour mapper query_type1 à UDM.
record_type2 answers.type Champ intermédiaire utilisé pour mapper query_type2 à UDM.
res_code network.dns.response_code Mappé à l'aide de la table de recherche dns_response_code.include.
response_code network.dns.response_code Pour les journaux au format CEF, si response_code existe, il est mappé sur network.dns.response_code à l'aide de la table de recherche dns_response_code.include.
security_action security_result.action Dérivé du champ status. Si status est défini sur "denied", security_action est défini sur "BLOCK". Sinon, il est défini sur "ALLOW".
severity security_result.severity Pour les journaux au format CEF, si severity existe et est "informatif", il est mappé sur security_result.severity en tant que "INFORMATIONAL".
src_host principal.hostname Extrait du champ description ou message du journal brut à l'aide de modèles Grok et mappé sur principal.hostname.
src_ip principal.ip ou principal.hostname Extrait du champ message du journal brut à l'aide de modèles Grok. S'il s'agit d'une adresse IP valide, elle est mappée sur principal.ip. Dans le cas contraire, elle est mappée sur principal.hostname.
src_port principal.port Extrait du champ message du journal brut à l'aide de modèles Grok et mappé sur principal.port.
ttl1 answers.ttl Extrait du champ msg2 du journal brut à l'aide de modèles Grok et mappé sur answers.ttl.
ttl2 answers.ttl Extrait du champ msg2 du journal brut à l'aide de modèles Grok et mappé sur answers.ttl.
metadata.event_type metadata.event_type Dérivé de divers champs et de la logique de l'analyseur. Valeur par défaut : GENERIC_EVENT si aucun autre type d'événement n'est identifié. Les valeurs possibles sont NETWORK_DNS, NETWORK_CONNECTION et STATUS_UPDATE.
metadata.log_type metadata.log_type Défini sur "INFOBLOX_DNS" par l'analyseur.
metadata.product_name metadata.product_name Défini sur "Infoblox DNS" par l'analyseur.
metadata.vendor_name metadata.vendor_name Défini sur "INFOBLOX" par l'analyseur.
metadata.product_version metadata.product_version Extrait des messages CEF.
metadata.event_timestamp metadata.event_timestamp Copié à partir du champ timestamp.
network.application_protocol network.application_protocol Défini sur "DNS" si event_type n'est pas "GENERIC_EVENT" ou "STATUS_UPDATE".

Modifications

2023-10-17

  • Ajout d'un modèle Grok pour gérer les journaux non analysés.

2023-06-19

  • J'ai écrit un modèle Grok pour extraire "hostname", "ip" et "port", et j'ai modifié "event_type" en conséquence.

2022-02-09

  • J 'ai écrit un Grok pour extraire le nom d'hôte et modifié "event_type" en conséquence.
  • Mappage de "src_host" sur "principal.hostname".
  • Mappage du type d'événement approprié.

2023-01-19

  • Ajout d'un format Grok pour prendre en charge le nouveau Syslog.
  • Ajout de mappage pour les éléments suivants:
  • Si le journal contient un protocole IP, tel que TCP ou UDP, la valeur est mappée sur "network.ip_protocol".
  • Si le journal contient une adresse IP ou un nom d'hôte intermédiaire, la valeur est mappée sur "intermediary.ip/intermediary.hostname".

2022-09-09

  • Modification et mappage corrects du champ "syslog_timestamp" sur "metadata.event_timestamp".

2022-08-25

  • Mappage du champ "syslog_timestamp" sur "metadata.event_timestamp".
  • Ajout de vérifications grok et conditionnelles pour le champ "smac" mappé sur "principal.mac".
  • Ajout de vérifications conditionnelles pour le champ "dns_domain" mappé sur "network.dns.questions".
  • Ajout de vérifications conditionnelles pour le champ "name1" mappé sur "network.dns.answers.name".
  • Ajout de vérifications conditionnelles pour le champ "ttl1" mappé sur "network.dns.answers.ttl".

2022-07-15

  • Correction de bug : suppression du dernier caractère s'il s'agit d'un point dans network.dns.questions.name, network.dns.answers.name et network.dns.answers.data

2022-06-02

  • Correction de bug : l'adresse IP n'était pas correctement extraite du journal syslog. Nous avons donc modifié le grok pour l'extraire correctement.
  • Amélioration : prise en charge des journaux au format CEF.
  • Mappage des nouveaux champs suivants :
  • InfobloxB1OPHIPAddress vers principal.ip
  • InfobloxDNSQType vers dns.questions.type
  • destinationDnsDomain à dns.questions.name
  • InfobloxB1Region à principal.location.country_or_region

2022-04-28

  • Suppression du mot supplémentaire "query:" du champ "network.dns.questions.name".