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. With QRoC in particular, the DLC Guide is not very helpful as it has an on-premises focus. This post offers a concrete example of setting up a DLC to work with QRoC.
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 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. With DLC+QRoC half of this trust is taken care of by QRoC DevOps who will set up Let's Encrypt certificates for the server (console). The Let's Encrypt authority is widely trusted and so the RedHat or CentOS host used for DLC will already trust it and there's no extra work to be done. The DLC client certificates, however, have to be signed by another CA that won't be automatically trusted by QRoC. Some of the steps in this procedure are about establishing trust between QRoC and the CA used to sign DLC certificates.
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 egress or outbound IP address from which QRoC will 'see' the incoming DLC connection is known (be sure to consider firewalls and NAT)
- 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 - DLC CA".
Step 2
Open a support ticket for the DLC pre-requisites
With the CA established with a root certificate, you now have everything you need to make a request of QRoC DevOps. What you'll need them to do is put your pki/ca.crt file into truststore in the right location on the Console and any Event Processors in the environment. You will also need them to create the server-side certificates and place them in the correct locations; luckily DevOps has a process for this using Let's Encrypt.
You'll only need to do this once, for the first DLC. Adding additional DLCs will not require a ticket so long as you continue to use the same CA.
- Open a ticket and attach the pki/ca.crt. Ask for it to be added to a truststore placed in /opt/qradar/conf/trusted_certificates/ on all hosts.
- Also ask that the Let's Encrypt certificates for DLC be set up on the console and any event processors.
- The response will indicate the location of the Let's Encrypt keystore and its password. Typically, the keystores are placed in /opt/qradar/conf/key_stores/ on each host. The response will also specify the filename and password of the truststore.
Step 3
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 ( ./easyrsa import-req dlc-client.csr dlc-client )
- Sign the request as a client cert ( ./easyrsa sign-req client dlc-client )
- Filter out the extra text from the certificate file ( openssl x509 -in pki/issued/dlc-client.crt > dlc-client.crt )
- Return the signed certificate ( dlc-client.crt ) to the DLC host
Note that for subsequent DLC certificates, use a unique filename and import name. For example replace "dlc-client" in the above steps with "dlc-client2", or something memorable.
Step 4
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. dlc-client.crt) into the DLC config ( sudo /opt/ibm/si/services/dlc/current/script/generateCertificate.sh -p12 dlc-client.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 QRoC FQDN, respectively.
Step 5
Be sure the DLC connection is allowed
The DLC's egress IP, as seen by QRoC needs to be in the Allow List for the QRoC instance. This can be done in the QRoC self-serve app.
Step 6
Setup the DLC in the Log Source Management App on the QRoC console
You now have everything you need to complete the setup of the DLC protocol on the console. In the "Configure the protocol parameters" page:
- Key Store File Name will be the filename for the Let's Encrypt certificate given to you by DevOps
- Key Store Password will be the password given by DevOps for the above file
- Check Revocation should probably be turned off if you're using easy-rsa
- Trust Store File Path will be the path to your truststore from the ticket response in Step 2.
- Trust Store Password will be the one provided to you in the ticket response from Step 2.
Follow the DLC Guide and the DSM Guide for the remaining parameters.
References