QRadar on Cloud: Support FAQ and common questions

1. Administrators need to configure their firewall to allow outgoing and related traffic to the console at <HTTPS IP> and to IBMs VPN server at <VPN IP>, both on port 443.
2. Your gateway must be behind a NAT firewall. Publicly routable IP addresses cause internal routing issues to the VPN server.
3. There must be no URL blocking device, IPS, or deep-packet inspection methods blocking traffic to either the Console or IBMs VPN IP addresses.
4. When you choose an internal IP for your Data Gateway, you cannot use an IP address in the 192.168.0.0/16 range. If you use this subnet range, routing issues can occur. Supported static IP addresses are:

   CIDR	IP address range
   10/8	10.0.0.0 - 10.255.255.255
   172.16/12	172.16.0.0 - 172.31.255.255

5. To locate the ISO to install the Data Gateway
   1. Log in to the Console User Interface.
   2. Click Admin > Hosted QRadar.
   3. Download the ISO.
   4. Go to Fix Central and locate the Fix Pack or Update Package associated with your version of QRadar on Cloud. 
   5. Install the Fix Pack or Update Package on your Data Gateway.
6. To locate the token for the Data Gateway.
   1. Click Admin > Hosted QRadar.
   2. Copy the token to use with the Data Gateway installation.
7. You can install more than one Data Gateway, but they need to be done sequentially. After you complete the installation of each Data Gateway, run Deploy Changes from the Admin tab.
8. When you create a root password, do not use special characters.
9. Use a root password scheme based on your organizations security policy for each Data Gateway installation.
   Note: You might be prompted to add the root password more than once.
10. Do not break the installation process at any time, even if an error is displayed. A typical installation might take more than 20 minutes after it connects to the console and begins the add process.
11. When the installation is complete, the command prompt displays an installation status of success or error. 
12. If the installation generates an error or installs with errors, open a case with QRadar support.
13. The guide to getting started with QRadar on Cloud is available from IBM documentation teams. For the QRadar on Cloud documentation, see: Getting started with QRadar on Cloud.

1. Download the QRadar ISO.
   1. Log in to the QRadar Console.
   2. Click Admin tab > Hosted QRadar.
   3. Download the ISO.
   4. Go to Fix Central and locate the Fix Pack or Update Package associated with your version of QRadar on Cloud. 
   5. Install the Fix Pack or Update Package on your Data Gateway.
2. To install an Appliance type of 7000, select Appliance install  > Event Collector Gateway.
3. Assign a private IP address.
   Note: The IP address must not be located in a 192.168.x.x/16 subnet.
4. Configure NAT 1:1 within the private and public egress IP address.
5. Add the Public egress IP to the allow list by using the Self-Serv app.
6. Generate a token for the Data Gateway by using the Self-Serv app.
7. Allow communication to the Console and VPN server on port 443 and establish and related traffic inbound.
8. If the Console is at a newer version, patch the Data Gateway to match the Consoles version so it can be added to the deployment.
    

Data Gateways can be installed on a VM hosted any place. QRadar on Cloud has guides on how to install the Data. Gateway on most Cloud providers such as Azure, Google Cloud, and AWS. Refer to QRadar documentation on how to install a Data Gateway on supported Cloud providers.
 

Data Gateways do not support high-availability (HA) clustering currently. Administrators who want resiliency for events can add a load balancer in front of their Data Gateway appliances.
 

A load balancer can be used for ease of administration and resiliency. The impact is mainly for UDP syslog-based Log Sources that push data. Administrators need to point their event sources to the load balancer IP address instead of the Data Gateway. Log Sources that use protocols that poll for data, such as APIs, JDBC, or the Log File Protocol are not impacted as these protocols establish outbound TCP sessions. 

Load balancer requirements:

• The load balancer must be on the same layer 2 network as the data gateway and act as the default gateway for the data gateway
• Log Source management requires that the data gateway sees the source IP address of the Log Source. If the load balancer replaces Syslog header or injects new Syslog headers, the event data can appear to be generated by the load balancer and not the correct event source.

Administrators who need to update their network configuration on the Data Gateway appliance, such as changing the IP address, hostname, or DNS server information must open a case with the DevOps team so that we can coordinate these changes with your team. The Data Gateway must first be removed from the QRadar on Cloud deployment before network changes can be made to the host.

1. Create a QRadar on Cloud support ticket to have IBM remove the managed host from the QRadar on Cloud deployment.
2. Note: When you open a support case refer to the knowledge center article, QRadar on Cloud support ticket.
3. Using an Integrated Management Module (IMM) or direct connection to the Data Gateway appliance open a remote session.
4. Type qchange_netsetup to change the network interface settings.
5. Verify or update the allowlist from the Self Serve App - Manage access to the Console.
6. Generate a new token by using the Self Serve App - Generating a new token for a data gateway.
7. To add the Data Gateway back to the QRadar on Cloud deployment, type the command and enter your new token:
   /opt/qradar/bin/setup_qradar_host.py mh_setup interactive -r
    

Third-party software installation is not supported on any Managed hosts including Data Gateways. QRadar has a built-in firewall and allows administration access only through a secure connection that requires encrypted and authenticated access and provides controlled upgrades and updates. QRadar data gateways do not require or support traditional anti-virus or malware agents or support the installation of third-party packages or programs.

For more information, see: Third-party software on data gateways.

The bandwidth allocation must take into consideration.

• Your license for Events per second and Flows per minute.
• Your internet dedicated bandwidth connection.
   

QRadar Consoles do not allow clients to SSH to the Console appliance as QRadar on Cloud DevOps manages it. Clients can have access to Data Gateways to perform basic actions over any Console utility such as IMM, iLO, iDRAC, KVM, XCC or equivalent.
 

To enable a Data Gateway so it can be accessed by using SSH, administrators need to perform these steps on the Data Gateway.

1. Back up the file by using the command:

   cp /opt/qradar/conf/iptables.pre /storetmp 

2. Use an editor and open /opt/qradar/conf/iptables.pre

   vi /opt/qradar/conf/iptables.pre

3. Add a line to the file to allow an SSH connection to the Data Gateway, where <ipaddress> is the IP address needed to allow an SSH session to the Data Gateway.

    -A INPUT -p tcp -s <ipaddress> --dport 22 -j ACCEPT

4. Save the changes to the file.
5. Reload iptables by using the command

    /opt/qradar/bin/iptables_update.pl

The Log Source keeps sending events to the Data Gateway. If the connection is broken, it buffers these events until it reaches its /store partition capacity value. When the connection is restored, the events are forwarded. If the connection does not get restored, the events fill the /store partition causing QRadar to shut down services. Stopping services causes events to be dropped.

Important: Stopping services causes an interruption in collecting events, reports, searches, and offense investigations. Administrators with strict outage policies are advised to schedule a maintenance window for their organization if services need to be stopped.

To enable extra interfaces on a Data Gateway for events and flows collection, the administrators must refer to QRadar on Cloud: How to configure extra collection interfaces on Data Gateways.

• Generate tokens for Data Gateway appliances
• Add allowlist IP addresses and subnets to access QRadar on Cloud instances. Subnet masks are supported within /24 to /32.
• Perform User Management such as Adding, Editing, Deleting user roles on other administration functions.
• Generate service authorized tokens for applications.
   

Administrators can open cases for questions or concerns about their QRadar on Cloud deployment. Some administrative actions must be performed by the DevOps team that manages your QRadar on Cloud instance. For a list of actions that require a support case or DevOps  to open tickets can be found the QRadar on Cloud production documentation.
 

New features can be requested from the IBM Ideas website. All requests for IBM application features can be logged and voted on if you make your request public.

For more information about IBM Ideas, see the QRadar: Requesting new features on IBM Ideas.

1. Network
   When you do a search, click Current statistics > More details. The expected value is all of the managed host at 100% with the smaller time.
   • If a managed host displays zero, it can indicate the Console cannot connect to the Ariel service on the managed host.
   • If the managed host becomes hung, it might indicate higher latency on the link and the appliance system resources.
     
     Submit a new case to IBM Support to determine the reason and fix it.
2. Inefficient searches
   • Searches that are too broad can cause subsequent searches to be queued. General searches can take a long time to complete and demand numerous resources within QRadar.
   • Use searches with more accurate criteria. The links provided illustrate how to efficiently search in QRadar.
         Searching Your QRadar Data Efficently : Part 1
         Searching Your QRadar Data Efficently : Part 2
         Searching Your QRadar Data Efficently : Part 3

It is possible that some rules do not match the exact same criteria as they were on premises.
To resolve this issue make sure to review each rule criteria to match your current related data including building blocks, Regex, log source, email.

Reports are based on criteria. If one is not met the report is not triggered not the functions associated to it such as email delivery. 
To resolve this issue, verify the criteria are correct for your report. 

If the review of the criteria is correct, it is likely that other constraints such as report, size format limitations, and others are the cause.  If you are still having issues, submit a case to IBM Support.

Rules
A full configuration backup is completed daily through QRadar's configuration backup feature, which is managed by the DevOps team. The tools required to complete a manual content export is only accessible through QRadar's command line. To resolve this issue, submit a case with IBM Support to request a content export from your QRadar on Cloud Console appliance.

Custom log source configurations
In QRadar V7.3.3 and later, you can export your custom content that you create in the DSM Editor. Click the Export button in the DSM Editor to export your content from one QRadar deployment to another, or to external media.

This can be tested by using the curl command. An example of a query to the log source API end point would be:

curl -k -x http://<proxy_server_ip>:80 --proxy-user <proxyuser>:<proxypassword> -X GET -H 'SEC: API TOKEN' -H 'Range: items=0-49' -H 'Version: 11.0' -H 'Accept: application/json' 'https://<console-xxxxx.qradar.ibmcloud.com>/api/config/event_sources/log_source_management/log_sources' -vvv  

Where:
<proxy_server_ip> is the IP address of your proxy server.
<console-xxx.qradar.ibm.cloud.com> is the URL for your QRadar on Cloud Console.

The generation of admin tokens to be used for API Calls is handled by QRadar on Cloud DevOps. Submit a new case to IBM Support.
 

The RESTful API overview can be used for testing. For other access, authorized service tokens must be used.

In most scenarios, the Data Gateway appliance is your Target Event Collector.

• Passive or Push protocols supply data streams that arrive at QRadar by themselves.
• Active or Pull protocols create a connection from the Target Event Collector field defined in the log source configuration to obtain data. If you have multiple Data Gateway appliances or move a connection from one Data Gateway to another, you can update the Target Event Collector field using the Log Source Management application. 
   

Review the Protocol Configuration options page from the QRadar DSM Configuration guide for a group list of common examples.

Installing a certificate varies based on the protocol. The location for certificates on your Data Gateway appliance is /opt/qradar/conf/trusted-certificates.

• If the certificate needs to be installed on the Data Gateway, you can use SCP or similar protocol to transfer the certificate to the trusted-certificates directory. 
  Review the section on How can access over SSH be configured on Data Gateways from this FAQ.
• If the certificate needs to be installed on the Console, you need QRadar on Cloud DevOps to install it for you.
  Submit a new case to IBM Support.
   

For more information, see the QRadar DSM Configuration Guide.

Use the Log Source Management (LSM) app testing capability to start the troubleshooting. The Log Source Management (LSM) app has many Protocol tests available to test your installation configuration. The number of tests are increasing with each new QRadar release. If the Log Source with the issue uses a Protocol that includes a test, enable debug options for advanced testing before you click the test button.
 

For Syslog, SNMP, or protocols that push data to QRadar, there must be a connection between the log source sender and the Data Gateway. Administrators can review the following steps provided to test the connectivity:

1. Ensure the log source is forwarding event data.
2. Use tcpdump to confirm the Data Gateway is receiving the event data.
   • QRadar: Using tcpdump to troubleshoot IBM Security QRadar SIEM
   • QRadar: Tcpdump with grep to capture specific syslog packet
   • QRadar: Using the command-line to troubleshoot a Syslog event source

For connections that pull data from the remote source, such as APIs, Log File protocol, or JDBC, the connection originates from the QRadar appliance. The connection must be able to connect and authenticate to the remote source. Administrators might be required to update firewalls rules in their networks to ensure that the Data Gateway appliance can establish connections to hosts that contain event data. To test connectivity:

1. Use the Log Source Management app to test the log source configuration. Most protocols that establish connections from QRadar include tests for connectivity and other configuration parameters.
2. Verify the device is on the network.
3. Ensure the remote device does not include an access control list that might prevent a connection. 
4. Confirm any firewalls or network devices that might block traffic between the Data Gateway appliance and your event source.
5. Ensure QRadar is sending the request. If you are unsure, open a new case with IBM Support.
    

Use the Log Source Management (LSM) app testing capability to start the troubleshooting. The Log Source Management app includes protocol tests that can confirm remote connections, credentials, certificates, file paths, and other configuration parameters. The number of tests are increasing with each new QRadar release. If the log source includes a test button, you can enable debug options before you test your log source configuration.

To enable debug

1. Click the step to Test Protocol Parameters
   image 6975
2. Click the Gear.
3. Click Show Debug Messages.
4. Click Skip Test and Finish.
   image 6974