This is a companion for my previous post about connecting DLC with QRoC, some of that post is repeated here so that this will function as a stand-alone article. If you're trying to connect a DLC to QRoC, refer to that post instead.
The Disconnected Log Collector (DLC) for QRadar enables a new set of deployment scenarios and can provide significant data protection improvements in multi-tenant deployments. However, a lot of users struggle to set up the TLS certificates. This can be challenging, especially for the first time, but it may not be as complex and confusing as it first seems. The DLC guide leaves some steps up to the user and simply reading through it may not clarify all the steps. This post offers a concrete example of setting up a DLC to work with QRadar.
I hope this will provide a useful, and relatively easy sample for first-time DLC users or a repeatable template for those working on demos and PoCs.
Preamble
Part of the reason why users, and even technical support staff, find this difficult is that the usage and function of certificates is not well understood. An entire essay could be written on the subject but the key points are fairly simple.
In a 'mutual' TLS (mTLS) connection, both client and server are configured with certificates. When the client connects to the server, the server first presents its certificate to prove its identity. The client will check to make sure the certificate was issued by a trusted authority (more on that below) and then will check to make sure the certificate includes the expected host name. This part is exactly what browsers do when connecting to websites. If that succeeds, the client will then present its own certificate to the server to prove its identity. The server will check that the client certificate was issued by a trusted authority and then check to make sure it includes a known identity (UUID in this case).
The success of this exchange depends upon having trusted authorities so that the identities within certificates can be validated as legitimate and not spoofed or faked. This is the first major decision point for the QRadar administrators to consider since different deployments may require different PKI patterns. For the sake of creating a simple example to start with I will use a single CA for all certificates and both QRadar and the DLC will trust it. The Private CA will sign certificates for the DLC client and for the QRadar server, both QRadar and the DLC will trust this CA and therefore DLC and QRadar will be able to prove their identity to one another.
Starting State
Below is a step-by-step example of the network and certificate configuration for a DLC. As a starting point, this guide assumes that these three steps have already been performed:
- The DLC software is already installed on a host and ready to be configured for the first time
- The QRadar deployment is up and running with at least an All-In-One Console and all the latest Patches and AutoUpdates have been applied.
- DLC communication has not yet been configured and the default config.json is still in place.
Also, many of the sample commands given are meant for a UNIX-like command line (i.e. a terminal on Linux or Mac). Windows users may have to adjust accordingly or use WSL.
Step 1
Locate a Certificate Authority (CA) to sign DLC certificates
First and foremost: remember that many organisations have a corporate policy governing the use of PKI (Certificates). Be sure that you're aware of this before potentially heading down a path toward non-compliance. In this example I have the freedom to choose any CA so I'll use easy-rsa; it is well-known, well-travelled and produces certificates that work well with DLC.
Also, since this is just a demo, I simply used my own workstation to host the CA. However, in production a CA is considered very sensitive and should be hosted on a dedicated, security hardened host. In any case do not use the DLC host for this; there should always be a separation of duties between a CA and the endpoints that use certificates.
- clone the easy-rsa project. (e.g: git clone git@github.com:OpenVPN/easy-rsa.git) and read through the README.quickstart.md
- change into the directory where all the CA commands will be issued (cd easy-rsa/easyrsa3)
- Initialize the CA structure and generate the root key. You'll be prompted for a passphrase, guard this carefully. I put mine in my password manager. (./easyrsa init-pki && ./easyrsa build-ca )
- You will also be prompted for a common name. This is the identity of the CA to be embedded in the CA certificate. Choose a name appropriate for the environment, customer, etc. I chose "IBM Demo CA".
Step 2
Establish Trust in the CA
With the CA created with a root certificate, you can create trust between the Console and the CA as well as between the DLC and the CA. This is done by importing the CA's public root certificate into the "trust store" on each host. You'll only need to do this once for each QRadar machine and each DLC. For each one:
- Copy the pki/ca.crt file from the CA to /etc/pki/ca-trust/source/anchors/ directory on every QRadar and DLC host.
- On each host, run the update-ca-trust command (as root).
Step 3
Create the DLC server keys and certificates for QRadar.
Easy-RSA will create keys and certificates for us one step. It will also package them up into a "key store" suitable for use with QRadar. Repeat the following for each QRadar Console and Event Processor host, replacing qradar.host.name with the actual FQDN of the host:
- On the CA, generate the key and certificate. ( ./easyrsa build-server-full qradar.host.name nopass )
- Generate the key store for the key and certificate, create a good password when prompted and remember it ( ./easyrsa export-p12 qradar.host.name )
- Copy the key store pki/private/qradar.host.name.p12 to the matching QRadar host in the directory /opt/qradar/conf/key_stores/.
Note: the "QRadar FQDN" must be the full hostname that the DLC will use to reach the QRadar host so keep in mind any NAT devices.
Step 4
Setup the DLC in the Log Source Management App on the QRadar console
You now have everything you need to complete the setup of the DLC protocol on the Console or EPs. Follow the guidance in the DLC Guide for setting up the DLC on QRadar. When you get to the "Configure the protocol parameters" page, use the following:
- CN/Alias Allowlist can be left empty for the moment (we'll come back to it)
- Key Store File Name will be the actual filename of the qradar.host.name.p12 from Step 3
- Key Store Password will be the password created in Step 3
- Check Revocation should probably be turned off when using easy-rsa
Follow the DLC Guide and the DSM Guide for the remaining parameters, all should be set to the defaults or suggested values. Repeat the above for each "Target Event Collector" using the proper key store file for each hostname. Don't forget to deploy the changes.
Step 5
Create the signature request on DLC using the generate script.
This step follows the DLC Guide for creating the signing request fairly closely by using the generate script.
- On the DLC, create the request. ( sudo /opt/ibm/si/services/dlc/current/script/generateCertificate.sh -csr -2k )
- Note the UUID in the common name of the request ( xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxxx)
- Transfer a copy of the CSR ( /opt/ibm/si/services/dlc/keystore/*/dlc-client.csr ) to your CA host, in the easyrsa3 directory
- On the CA host, import the request to the easy-rsa CA, replace UUID with the actual UUID above ( ./easyrsa import-req dlc-client.csr UUID )
- Sign the request as a client cert ( ./easyrsa sign-req client UUID )
- Filter out the extra text from the certificate file ( openssl x509 -in pki/issued/UUID.crt > UUID.crt )
- Return the signed certificate ( UUID.crt ) to the DLC host
Repeat the above for each DLC.
Step 6
Create the keystore on the DLC
The DLC needs to have the certificate joined with its private key in a keystore so that the Java process can load it. We use the generate script provided by the DLC for this.
- Import the cert (e.g. UUID.crt) into the DLC config ( sudo /opt/ibm/si/services/dlc/current/script/generateCertificate.sh -p12 UUID.crt )
- The above prompts for a password, choose a good one. The import script automatically encrypts it for you in the config.json
- At this point the DLC's config.json has been updated with a TLS section that points to the keystore and has the encrypted password for it. But, the Destination is still localhost/UDP
- So, edit the /opt/ibm/si/services/dlc/conf/config.json file and change the values for destination.type and destination.ip with "TLS" and the desired QRadar FQDN, respectively.
- restart the dlc service ( sudo systemctl restart dlc )
Step 7
Add the DLC UUID(s) via the Log Source Management App
Return to the Log Source Management App the "CN/Alias Allowlist" with the UUIDs from Step 5, repeat for each DLC Protocol configuration you created in Step 4.
At this point, the DLCs should all be connected to QRadar and able to forward events. On the DLC(s) the following log message indicates successful connection:
2022-06-22 17:03:10,261 [DLC Sec Event Forward Thread] com.q1labs.audit.Q1X509TrustManager.Validation.ValidationPassed: [INFO] [Q1X509TrustManager] [Validation] [ValidationPassed] (dlc) Validating certificate chain succeeded. chain:[0]X509Certificate : { SubjectDN : CN=eqradar.host.name, IssuerDN : CN=IBM Demo CA},[1]X509Certificate : { SubjectDN : CN=IBM Demo CA, IssuerDN : CN=IBM Demo CA},
References
