Options de configuration du protocole HTTP Receiver

Pour collecter des événements à partir de dispositifs qui transfèrent des demandes HTTP ou HTTPS, configurez une source de journal pour utiliser le protocole HTTP Receiver.

Le protocole HTTP Receiver est un protocole passif entrant. HTTP Receiver agit en tant que serveur HTTP sur le port d'écoute configuré et convertit le corps de toutes les demandes POST reçues en événements. Il prend en charge les demandes HTTP et HTTPS.

Important : lorsque vous utilisez le protocole HTTP Receiver, vous devez utiliser un certificat émis par une autorité de certification (CA). Il ne peut pas s'agir d'un certificat autosigné car il doit être validé par une autorité de certification. Pour plus d'informations sur la configuration d'un certificat CA pour le récepteur HTTP, voir Configuration de l'authentification par certificat pour le récepteur HTTP.

Important: Si vous êtes un utilisateur QRadar on Cloud (QRoC), contactez le support IBM et ouvrez un cas de support pour configurer cette authentification par certificat si le collecteur cible est la console ou le processeur d'événements.

Le tableau suivant décrit les paramètres spécifiques au protocole HTTP Receiver :

Tableau 1. Paramètres du protocole HTTP Receiver
Paramètre	Descriptif
Configuration du protocole	Dans la liste, sélectionnez HTTP Receiver.
Identificateur de source de journal	Entrez un nom unique pour la source de journal. L'identificateur de source de journal peut être n'importe quelle valeur valide et n'a pas besoin de faire référence à un serveur spécifique. Il peut également s'agir de la même valeur que le Nom de la source de journal. Veillez à attribuer un nom unique à chaque source de journal.
Port d'écoute	Port utilisé par IBM QRadar pour accepter les événements HTTP Receiver entrants. Le port par défaut est 12469. Important: N'utilisez pas le port 514. Le port 514 est utilisé par le programme d'écoute Syslog standard.
Type de communication	Type de serveur HTTP créé par le protocole. HTTP Crée un serveur HTTP Server sans chiffrement ni vérification Important: Non pris en charge pour QRadar on Cloud (QRoC). https Crée un serveur HTTP Server avec chiffrement et vérification HTTPS avec TLS mutuel ( mTLS ) Crée un HTTP Server utilisant l'authentification TLS mutuelle ( mTLS ).
Certificat serveur	Choisissez l'une des options de certificat serveur suivantes. Chaîne de certificats et mot de passe PKCS12 Si vous sélectionnez cette option, vous devez configurer un chemin d'accès au fichier PKCS12 et fournir le mot de passe. S'il existe plusieurs entrées dans le fichier PKCS12 , vous devez fournir un alias pour spécifier l'entrée de certificat à utiliser. Choisissez parmi QRadar la boutique de certificats (obsolète) Si vous sélectionnez cette option, vous devez télécharger un certificat dans IBM QRadar Certificate Management app. Dans l'application, définissez le but du certificat sur `Server` ou `Server Client`, et son composant sur `Log Source`. Certificat généré autosigné (obsolète) Si vous sélectionnez cette option, un certificat généré autosigné est utilisé. Si un certificat n'a pas déjà été généré, un certificat est généré pour être utilisé. Ce certificat est auto-signé et correspond aux configurations Syslog d' TLS, qui utilisent des certificats générés sur le même hôte.
PKCS12 Chemin d'accès au certificat du serveur	Chemin d'accès absolu à un fichier PKCS12 qui contient une clé privée et une chaîne de certificats. Si vous sélectionnez PKCS12 Chaîne de certificats et mot de passe comme option de certificat serveur, ce paramètre s'affiche.
PKCS12 Mot de passe	Mot de passe du fichier PKCS12 . Si vous sélectionnez PKCS12 Chaîne de certificats et mot de passe comme option de certificat serveur, ce paramètre s'affiche.
PKCS12 Alias de certificat	Alias de l'entrée de certificat dans le fichier PKCS12 à utiliser. S'il existe plusieurs entrées dans le fichier PKCS12 , vous devez fournir un alias pour spécifier l'entrée de certificat à utiliser. S'il existe plusieurs entrées de certificat, laissez cette zone vide pour utiliser l'entrée de certificat unique. Si vous sélectionnez PKCS12 Chaîne de certificats et mot de passe comme option de certificat serveur, ce paramètre s'affiche.
Utiliser l'en-tête du jeton d'authentification HTTP	Cela permet d'activer l'authentification de l'en-tête HTTP. Lorsque cette option est activée, les clients qui tentent de communiquer avec le HTTP Server doivent fournir un jeton d'accès valide par l'intermédiaire d'un en-tête de requête.
Nom d'en-tête du jeton d'authentification	L'en-tête d'authentification HTTP est ajouté aux en-têtes de requête HTTP et contient des informations sur l'en-tête d'authentification utilisé et les informations d'identification associées. En-tête d'authentification: indique le type d'authentification utilisé. Les en-têtes d'authentification communs incluent Basic, Digest et Bearer.
Valeur du jeton d'authentification	La valeur de jeton incluse dans l'en-tête dépend du schéma d'authentification utilisé. Par exemple, dans le cas de l'authentification de base, la valeur de jeton se compose d'un nom d'utilisateur et d'un mot de passe codés au format Base64 .
Authentification mutuelle par le magasin de certificats d' TLS	Si vous sélectionnez le type de communication HTTPS avec TLS mutuel ( mTLS ), sélectionnez l'un de ces types de magasin de clés de confiance. Magasin de clés de confiance du système Initialise le magasin de clés de confiance du serveur à l'aide du magasin de clés de confiance du système d'exploitation sur le collecteur d'événements cible. Magasin de clés de confiance personnalisé Initialise le magasin de clés de confiance du serveur à l'aide d'un magasin de clés Java™ et d'un mot de passe fournis par l'utilisateur. Certificat client sur disque (obsolète) S'assure que le certificat client correspond mais ne valide pas l'émetteur. Avec cette méthode, tous les clients doivent partager un certificat.
Chemin d'accès au fichier de clés certifiées personnalisé	Chemin d'accès absolu à un magasin de clés de confiance personnalisé. Vous devez copier le magasin de clés de confiance personnalisé dans QRadar Console ou dans Event Collector pour la source de journal.
Mot de passe du magasin de clés de confiance personnalisé	Mot de passe du magasin de clés de confiance personnalisé.
Activer la vérification de l'émetteur	Vérifiez que le certificat client a été émis par un certificat ou une clé publique spécifique. Un cas d'utilisation courant consiste à vérifier qu'une autorité de certification intermédiaire spécifique a été utilisée pour émettre le certificat client.
Certificat de l'émetteur ou clé publique	Le certificat ou la clé publique de l'émetteur racine ou intermédiaire au format « PEM ». Entrez le certificat, y compris le texte suivant: `-----BEGIN CERTIFICATE-----` `-----END CERTIFICATE-----` Ou entrez la clé publique, y compris le texte suivant: `-----BEGIN PUBLIC KEY-----` `-----END PUBLIC KEY-----` Si vous avez activé le paramètre Activer la vérification de l'émetteur , ce paramètre s'affiche.
Utiliser la liste autorisée de CN	Spécifiez des listes ou des modèles de noms communs auxquels les certificats client doivent correspondre après l'établissement de la confiance. Entrez un texte en clair ou une expression régulière. Définissez plusieurs entrées en entrant chaque entrée sur une nouvelle ligne. La liste suivante présente des exemples de types d'entrées de nom usuel à utiliser dans votre liste autorisée CN. Nom fixe `127.0.0.1` `1.1.1.1` Nom générique `1.1.1.` `.` Nom de domaine `www.host.*.com` `localhost` Par défaut, ce paramètre est désactivé.
Vérifier la révocation du certificat	Vérifie le statut de révocation de certificat par rapport à la liste de révocation de certificat client. Pour configurer cette option, vous devez disposer d'une connectivité réseau avec l' URL spécifiée par le champ Points de distribution CRL du certificat client dans l'extension X509v3, et l' URL doit prendre en charge uniquement le format de liste de révocation de certificats (CRL). OSCP n'est pas pris en charge.
Chemin d'accès au certificat client (obsolète)	Définissez le chemin d'accès absolu au certificat client. Vous devez copier le certificat client dans QRadar Console ou dans Event Collector pour la source de journal. Si vous sélectionnez HTTPS avec TLS mutuel ( mTLS ) comme type de communication et que vous sélectionnez Certificat client sur disque (obsolète) comme magasin de certificats de confiance pour l'authentification TLS mutuelle, ce paramètre s'affiche.
Méthode d'analyse des événements	Événement par HTTP Post Traiter l'ensemble du poste HTTP comme un événement unique sans modèle spécifique. Événement par ligne Divisez le message en plusieurs événements d'une seule ligne en utilisant une expression régulière pour marquer le début de chaque événement. Si vous sélectionnez Événements par ligne, les deux champs suivants sont visibles : Correspondre à des lignes spécifiques : Par défaut, un événement est traité par ligne. L'activer pour qu'il corresponde à des lignes spécifiques selon le modèle de message. Message Pattern : Saisir une expression régulière pour diviser le message en plusieurs événements d'une seule ligne Événement par tableau JSON Spécifier un chemin JSON (JPath) pour identifier la racine du tableau JSON, chaque entrée du tableau étant un événement distinct. Si vous sélectionnez Événement par tableau JSON, le champ suivant est visible : Expression du chemin JSON : Entrez un chemin JSON pour identifier la racine du tableau JSON, chaque entrée du tableau étant un événement distinct. Un chemin JSON doit commencer par une barre oblique ('/') pour indiquer la racine de l'objet JSON et doit être suivi d'un ou plusieurs noms de champs JSON entre guillemets. Par exemple : `JSON: {"topic":"device-events","events":[{"device_name":"device 1"}, {"device_name":"device 2"}]} JSON Path expression: /"events"` Préserver la structure JSON externe : Si cette option est activée, elle inclut la structure JSON en dehors de l' expression du chemin JSON dans la sortie. Par défaut, seuls les éléments du tableau dans l' expression du chemin JSON sont inclus. Par exemple : `{"topic": "device","events": [{"audit_id": "audit 1","ap_name": "ap 1", "device_type": "device type 1"},{"audit_id": "audit 2","ap_name": "ap 2", "device_type": "device type 2"}]}` Il sera converti en plusieurs événements comme suit : `{"topic": "device","events": [{"audit_id": "audit 1","ap_name": "ap 1", "device_type": "device type 1"}]}` `{"topic": "device","events": [{"audit_id": "audit 2","ap_name": "ap 2", "device_type": "device type 2"}]}`
Utiliser comme source de journal de passerelle	Sélectionnez cette option pour que les événements collectés passent par le moteur d'analyse du trafic QRadar® et pour que QRadar détecte automatiquement une ou plusieurs sources de journaux.
Utiliser l'analyse syntaxique prédictive	Si vous activez ce paramètre, un algorithme extrait les modèles d'identificateur de source de journal des événements sans exécuter le regex pour chaque événement, ce qui augmente la vitesse d'analyse. Cependant, dans de rares cas, l'algorithme peut faire des prévisions incorrectes. Activez l'analyse prédictive uniquement pour les types de source de journal desquels vous prévoyez recevoir des taux d'événements élevés et nécessitant une analyse plus rapide. Lorsque vous activez le paramètre Utiliser en tant que source de journal de passerelle , vous pouvez activer l'analyse syntaxique prédictive.
Modèle d'identificateur de source de journal	Lorsque l'option Utiliser comme source de journal de passerelle est sélectionnée, utilisez-la pour définir un identificateur de source de journal personnalisé pour les événements traités. Si Modèle d'identificateur de source de journal n'est pas configuré, QRadar reçoit des événements en tant que sources de journal génériques inconnues. La zone Modèle d'identificateur de source de journal accepte les paires clé-valeur, telles que key= value, pour définir l'identificateur de source de journal personnalisé pour les événements en cours de traitement et pour les sources de journal à reconnaître automatiquement, le cas échéant. Clé est la chaîne de format d'identificateur, qui est la source ou la valeur d'origine qui en résulte. La valeur est le modèle d'expression régulière associé utilisé pour évaluer le contenu actuel. La valeur (modèle regex) prend également en charge les groupes de capture, qui peuvent être utilisés pour personnaliser davantage la clé (String Format String). Plusieurs paires clé-valeur peuvent être définies en entrant chaque modèle sur une nouvelle ligne. Lorsque plusieurs modèles sont utilisés, ils sont évalués dans l'ordre jusqu'à ce qu'une correspondance soit trouvée. Lorsqu'une correspondance est trouvée, un identificateur de source de journal personnalisé s'affiche. Les exemples suivants illustrent les fonctions de paires clé-valeur multiples: Schémas `VPC=\sREJECT\sFAILURE` `$1=\s(REJECT)\sOK` `VPC-$1-$2=\s(ACCEPT)\s(OK)` Evénements `{LogStreamName: LogStreamTest,Timestamp: 0,Message: ACCEPT OK,IngestionTime: 0,EventId: 0}` ID source de journal personnalisé résultant `VPC-ACCEPT-OK`
Régulation des EPS	Nombre maximal d'événements par seconde que QRadar ingère. Si votre source de données dépasse la régulation EPS, la collecte de données est retardée. Les données sont toujours collectées, puis elles sont ingérées lorsque la source de données cesse de dépasser le régulateur EPS. La valeur par défaut est 5000.
Activer les options de configuration avancées du serveur	Activez ce paramètre pour configurer d'autres options de serveur. Si vous n'activez pas ce paramètre, les valeurs par défaut sont utilisées.
Longueur maximale du contenu (octet)	Taille maximale du contenu d'un événement unique, en octets. L'événement est divisé lorsque sa taille de contenu dépasse cette valeur. La valeur par défaut est 8 192 et la valeur ne doit pas être supérieure à 32 767. Lorsque vous activez le paramètre Activer les options de configuration avancées du serveur , ce paramètre s'affiche.
Protocoles TLS	Les versions d' TLS acceptées dans le cadre de ce protocole. Envoyez une demande en utilisant la même version que celle sélectionnée pour le serveur. TLSv1.3 est pris en charge à partir de QRadar 7.5.0 UP5 . Important: TLSv1.0 et TLSv1.1 ne sont plus pris en charge à partir de QRadar 7.3.3 FP10, 7.4.3 FP3et 7.5.0 CR. Il se peut que les éditions futures ne prennent pas en charge TLSv1.0 et TLSv1.1.
Longueur maximale de la demande de méthode POST (Mo)	Taille maximale du corps d'une demande de méthode POST, en Mo. Si la taille de corps d'une demande POST dépasse cette valeur, le code d'état HTTP 413 est renvoyé. La valeur par défaut est 5 et la valeur ne doit pas être supérieure à 10. Lorsque vous activez le paramètre Activer les options de configuration avancées du serveur , ce paramètre s'affiche.
Threads du gestionnaire de requêtes postales	Le nombre de threads de traitement alloués pour traiter les demandes de messages entrantes. Si les fils de traitement ne peuvent pas suivre le rythme des données postales entrantes, un message HTTP 429 est renvoyé. Lorsque vous activez le paramètre Activer les options de configuration avancées du serveur , ce paramètre s'affiche.