HTTP Receiver protocol configuration options

To collect events from devices that forward HTTP or HTTPS requests, configure a log source to use the HTTP Receiver protocol.

The HTTP Receiver protocol is an inbound passive protocol. The HTTP Receiver acts as an HTTP server on the configured listening port and converts the request body of any received POST requests into events. It supports both HTTPS and HTTP requests.

Important: When you use the HTTP Receiver protocol, you must use a certificate that is issued by a certificate authority (CA). It can't be a self-signed certificate because it must be validated by a CA. For more information about setting up a CA certificate for HTTP Receiver, see Setting up certificate-based authentication for HTTP Receiver.

Important: If you are a QRadar on Cloud (QRoC) user, contact IBM support and open a support case to configure this certificate-based authentication if the target collector is the Console or Event Processor.

The following table describes the protocol-specific parameters for the HTTP Receiver protocol:

Table 1. HTTP Receiver protocol parameters
Parameter	Description
Protocol Configuration	From the list, select HTTP Receiver.
Log Source Identifier	Type a unique name for the log source. The Log Source Identifier can be any valid value and does not need to reference a specific server. It can also be the same value as the Log Source Name. Ensure that you give each log source a unique name.
Listen Port	The port that is used by IBM QRadar to accept incoming HTTP Receiver events. The default port is 12469. Important: Do not use port 514. Port 514 is used by the standard Syslog listener.
Communication Type	The type of HTTP server that is created by the protocol. HTTP Creates an HTTP Server without encryption and verification Important: Not supported for QRadar on Cloud (QRoC). HTTPs Creates an HTTP Server with encryption and verification HTTPs with Mutual TLS (mTLS) Creates an HTTP Server that uses Mutual TLS Authentication (mTLS)
Server Certificate	Choose one of the following server certificate options. PKCS12 Certificate Chain and Password If you select this option, you must configure a path to the PKCS12 file and provide the password. If there is more than one entry in the PKCS12 file, you must provide an alias to specify which certificate entry to use. Choose from QRadar Certificate Store If you select this option, you must upload a certificate in the IBM QRadar Certificate Management app. In the app, set the certificate's Purpose as `Server` or `Server Client`, and its Component as `Log Source`. Self-signed Generated Certificate (Deprecated) If you select this option, then a self-signed generated certificate is used. If a certificate was not already generated, then one is generated to use. This certificate is self-signed and is the same as the TLS Syslog configurations that are using generated certificates on the same host.
Server Certificate Friendly Name	The friendly name of a certificate that is available in the QRadar Certificate Store, which is uploaded in the QRadar Certificate Management app. Important: The QRadar Certificate Management app is supported on QRadar 7.3.3 Fix Pack 6 or later.
PKCS12 Server Certificate Path	The absolute path to a PKCS12 file that contains a private key and certificate chain. If you select PKCS12 Certificate Chain and Password as the server certificate option, this parameter is displayed.
PKCS12 Password	The password for the PKCS12 file. If you select PKCS12 Certificate Chain and Password as the server certificate option, this parameter is displayed.
PKCS12 Certificate Alias	The alias for the certificate entry in the PKCS12 file to use. If there is more than one entry in the PKCS12 file, then you must provide an alias to specify which certificate entry to use. When there is more than one certificate entry, leave this field blank to use the single certificate entry. If you select PKCS12 Certificate Chain and Password as the server certificate option, this parameter is displayed.
Use HTTP Authentication Token Header	This enables HTTP Header Authentication. When enabled, clients attempting to communicate with the HTTP Server must provide a valid access token via a Request Header.
Authentication Token Header Name	The HTTP Authentication Header is added to the HTTP request headers and contains information about the authentication header in use and the associated credentials. Authentication Header: This indicates the type of authentication in use. Common authentication headers include Basic, Digest, and Bearer.
Authentication Token Value	The Token Value included in the header depends on the authentication scheme under use. For example, in the case of Basic authentication, the Token Value consist of a username and password encoded in Base64 format.
Mutual TLS Authentication Truststore	If you select the HTTPs with Mutual TLS (mTLS) communication type, select one of these truststore types. System Truststore Initializes the server truststore by using the Operating System truststore on the target event collector. Custom Truststore Initializes the server truststore by using a user-provided Java™ keystore and password. Client Certificate On Disk (Deprecated) Ensures that the client certificate matches but does not validate the issuer. With this method, all clients must share one certificate.
Custom Truststore File Path	The absolute path to a custom truststore. You must copy the custom truststore to the QRadar Console or the Event Collector for the log source.
Custom Truststore Password	The password for the custom truststore.
Enable Issuer Verification	Verify that the client certificate was issued by a specific certificate or public key. A common use case is to verify that a specific intermediate CA was used to issue the client certificate.
Issuer Certificate or Public Key	The root or intermediate issuer's certificate or public key in PEM format. Enter the certificate, including this text: `-----BEGIN CERTIFICATE-----` `-----END CERTIFICATE-----` Or enter the public key, including this text: `-----BEGIN PUBLIC KEY-----` `-----END PUBLIC KEY-----` If you enabled the Enable Issuer Verification parameter, this parameter is displayed.
Use CN Allowlist	Specify lists or patterns of common names that client certificates must match after trust is established. Enter plain text or a regular expression. Define multiple entries by entering each entry on a new line. The following list shows examples of the types of common name entries to use in your CN Allowlist. Fixed name `127.0.0.1` `1.1.1.1` Wildcard name `1.1.1.` `.` Domain name `www.host.*.com` `localhost` By default, this parameter is disabled.
Check Certificate Revocation	Checks certificate revocation status against the client certificate revocation list. To configure this option, you must have network connectivity to the URL that is specified by the client certificate's CRL Distribution Points field in the X509v3 extension, and the URL must support only certificate revocation list (CRL) format. OSCP is not supported.
Client Certificate Path (Deprecated)	Set the absolute path to the client certificate. You must copy the client certificate to the QRadar Console or the Event Collector for the log source. If you select HTTPs with Mutual TLS (mTLS) as the Communication Type, and you select Client Certificate on Disk (Deprecated) as the Mutual TLS Authentication Truststore, this parameter is displayed.
Message Pattern (Optional)	By default, the entire HTTP POST is processed as a single event. To divide the POST into multiple single-line events, provide a regular expression to denote the start of each event. If the pattern matches with the regular expression at least once in a line, then the line is treated as an event.
Use As A Gateway Log Source	Select this option for the collected events to flow through the QRadar® Traffic Analysis engine and for QRadar to automatically detect one or more log sources.
Use Predictive Parsing	If you enable this parameter, an algorithm extracts log source identifier patterns from events without running the regex for every event, which increases the parsing speed. However, in rare circumstances the algorithm can make incorrect predictions. Enable predictive parsing only for log source types that you expect to receive high event rates and require faster parsing. When you enable the Use As A Gateway Log Source parameter, you can enable predictive parsing.
Log Source Identifier Pattern	When the Use As A Gateway Log Source option is selected, use this option to define a custom log source identifier for events that are processed. If the Log Source Identifier Pattern is not configured, QRadar receives events as unknown generic log sources. The Log Source Identifier Pattern field accepts key-value pairs, such as key=value, to define the custom Log Source Identifier for events that are being processed and for log sources to be automatically discovered, when applicable. Key is the Identifier Format String, which is the resulting source or origin value. Value is the associated regex pattern that is used to evaluate the current payload. The value (regex pattern) also supports capture groups, which can be used to further customize the key (Identifier Format String). Multiple key-value pairs can be defined by typing each pattern on a new line. When multiple patterns are used, they are evaluated in order until a match is found. When a match is found, a custom Log Source Identifier is displayed. The following examples show the multiple key-value pair functions: Patterns `VPC=\sREJECT\sFAILURE` `$1=\s(REJECT)\sOK` `VPC-$1-$2=\s(ACCEPT)\s(OK)` Events `{LogStreamName: LogStreamTest,Timestamp: 0,Message: ACCEPT OK,IngestionTime: 0,EventId: 0}` Resulting custom log source identifier `VPC-ACCEPT-OK`
EPS Throttle	The maximum number of events per second that QRadar ingests. If your data source exceeds the EPS throttle, data collection is delayed. Data is still collected and then it is ingested when the data source stops exceeding the EPS throttle. The default is 5000.
Enable Advanced Server Configuration Options	Enable this parameter to configure more server options. If you do not enable this parameter, the default values are used.
Max Payload Length (Byte)	The maximum payload size of a single event in bytes. The event is split when its payload size exceeds this value. The default value is 8192, and it must not be greater than 32767. When you enable the Enable Advanced Server Configuration Options parameter, this parameter is displayed.
TLS Protocols	The versions of TLS that can be accepted in this protocol. Send a request by using the same version that is selected for the server. TLSv1.3 is supported from QRadar 7.5.0 UP5 onwards. Important: TLSv1.0 and TLSv1.1 are no longer supported as of QRadar 7.3.3 FP10, 7.4.3 FP3, and 7.5.0 CR. Future releases might not support TLSv1.0 and TLSv1.1.
Max POST method Request Length (MB)	The max size of a POST method request body in MB. If a POST request body size exceeds this value, an HTTP 413 status code is returned. The default value is 5, and it must not be greater than 10. When you enable the Enable Advanced Server Configuration Options parameter, this parameter is displayed.