IBM Support

QRadar: Using tcpdump and Wireshark to troubleshoot and analyze IBM Security QRadar SIEM

Question & Answer


Question

How do you use tcpdump to troubleshoot and Wireshark to analyze the IBM Security QRadar SIEM?

Answer

Administrators can troubleshoot IBM QRadar SIEM by collecting IP traffic to QRadar that uses the tcpdump utility and analyzing this IP traffic with Wireshark. Tcpdump can define the interface, port, source IP addresses, and destination IP addresses of the network traffic. Tcpdump can also write the packet data on-screen to help users determine whether the QRadar SIEM receives events. However, writing this packet data to a .pcap file is often more beneficial, which can be shared with QRadar support or post-analyzed using Wireshark. The following videos demonstrate tcpdump options for advanced troubleshooting steps and Wireshark for post-analysis steps.
An example of troubleshooting Syslogs events

Before you can troubleshoot Syslog events being sent to an IBM QRadar SIEM, you need to review the source sending Syslog events and verify the IP address. The Syslog destination configured on your device is where you need to troubleshoot. The tcpdump command must be run on the appliance receiving the events from your device.

Note: By default, QRadar appliances are always configured to listen for Syslog events on TCP and UDP port 514. There is no need to touch the firewall on your QRadar appliance.

The following commands allow administrators to review IP traffic, including the full Syslog payload for events from a remote Syslog source.

  1. Using SSH, log in to your QRadar Console as root.
  2. Optional. If the Syslog destination is another appliance, such as an Event Collector appliance, SSH to the event collector.
  3. Type one of the following commands:
  • For TCP Syslog, type:
    tcpdump -s 0 -A host Device_Address and port 514
  • For UDP Syslog, type:
    tcpdump -s 0 -A host Device_Address and udp port 514
Note: Device_Address must be an IPv4 address or a hostname. For example,
tcpdump -s 0 -A host x.x.x.x and port 514
Note: If Device_Address is an IPv6 address, “host” is preceded by “ipv6”.
tcpdump -s 0 -A ipv6 host x:x:x:x:x:x:x:x and port 514

If you do not see any IP traffic in the command line, it is likely that either the device is not sending Syslog events or a firewall is blocking communication.

  1. Verify with your firewall administrator or operations group that no firewalls are blocking communication between the QRadar appliance and the device sending Syslog events.
  2. Typically, an easy method to verify whether a TCP port is open is to telnet from QRadar to the device. From the QRadar command line, type telnet Device_IPAddress 514. (Remember, it is telnet ipv6 Device_IPAddress 514 for an IPv6 Address)
  3. Review the Syslog configuration of your remote device to ensure that it is configured to send events to the appropriate QRadar appliance.
  4. If the remote appliance is Linux UNIX-based, administrators can verify the event source is sending data to the QRadar appliance with the following command: tcpdump dst QRadar_Appliance_IPAddress (Again, if the remote address is IPv6, then “dst” is preceded by “ipv6”)

You can save IP traffic for post-analysis if you see IP traffic in the command line. It can be done by directing the tcpdump commands to a ”.Pcap” file by using the “-w” switch followed by the ”.Pcap” file name. For example, 

tcpdump -s 0 -A host x.x.x.x and port 514 -w syslog-traffic.pcap

Note: Once the traffic is redirected to a Pcap file, you no longer see IP traffic in the ssh shell.

The tcpdump collection must be allowed to continue for a period, which is sufficient to ensure that a sample of IP traffic is collected (it varies with log source type and protocol used).

To finish the collection of IP traffic and close the “.Pcap” file, type “Control C” in the ssh console.

The saved ”.Pcap” file can now be post-analyzed using Wireshark by simply clicking the ”.Pcap”. It opens the file and is presented in a format such as

Screen

Here you notice several points.

  1. In the main window, "Source" represents the log source's IP or fully qualified domain name (FQDN) emitting the events.
  2. "Destination" represents the IP or fully qualified domain name (FQDN) of the Event Collector receiving the events. 
  3. "Protocol", while listed as "Syslog", is based purely on the fact that it's using the Syslog port number (514). There is no validation of the IP payloads to ensure that the traffic is, in fact, valid Syslog traffic.

Next, the IP "Conversations" contained within the "Pcap" file must be analyzed. It can be done by selecting "Statistics" and then "Conversations", an example of which is

Screen

It produces a new open window showing all IP traffic arranged into a list of IP connections (“Conversations”) between the QRadar event collector and the log source. 
An example of this is

Screen

Next, select one of the conversations listed (using your mouse) and click “Follow Stream.”

Screen

It opens a new window showing the payload of this “Conversation”

Screen

Inside this window, the Syslog payload must comply with rfc-3164 or rfc-5424, as specified by a sample event in the QRadar DSM guide. If the format of this event doesn’t satisfy these conditions, QRadar cannot recognize it, and it discards the event.


The collected ”Pcap” will be uploaded to QRadar support for review and verification.

[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwt0AAA","label":"Log Source"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
17 May 2023

UID

ibm16966924