IPv6 support in QRadar

QRadar has included support for IPv6 deployments and data ingestion for a long time. However, the IPv6 support included many serious gaps which lead to incomplete coverage for use in dual-stack or pure IPv6 environments. Anyone who tried to setup QRadar before 7.5.0 UP10 will have noticed these gaps throughout, beginning with installation and network setup.

Issues with IPv6 support pre-UP10

Some of the most obvious issues with IPv6 prior to UP 10 include:

• Network setup screens did not include DNS configuration
• Host-based firewall (iptables) rules were broken and/or stateless
• Data balancing between Data Nodes would not work
• Parsing of "Device IP" in many log sources was inaccurate
• None of the vulnerability scanner integrations supported IPv6
• There were no data sources for IPv6 in Asset Profiles
• Several CRE rule tests had only IPv4 support
• GeoData updates via Auto Update did not include IPv6 networks

While some of these issues had work-arounds or were otherwise minor inconveniences, others significantly diminished the value of the SIEM in IPv6 networks and undermined the analytic capabilities of QRadar.

In QRadar 7.5.0 UP10, IPv6 support has been revamped and improved, and the major gaps have now been filled. More updates will follow to resolve remaining issues. These changes are welcome for those organizations or agencies mandated to adopt IPv6, allowing their investment in QRadar to continue returning value.

The changes start with QRadar installation and deployment where the network setup script and dialogs now provide DNS configuration and properly identify and warn against link-local addresses. Previously, it was necessary to manually edit configuration files to include nameservers and link-local addresses were allowed, causing QRadar apps to fail. Additionally, Data Node balancing works as expected when the hosts are using IPv6 as primary addresses.

The parsing of IPv6 addresses for "Device IP" or Log Source ID in DSMs has been repaired. This improvement is of particular importance for events that do not include addresses in syslog headers since the fallback to packet IP would create completely invalid addresses. This produced side-effects in correlation and in some cases events would bypass correlation rules completely. Now, IPv6 packet IPs are properly handled and fallback source and destination addresses are correctly reflected in Log Source IDs as expected. Furthermore, many of the DSMs have been re-evaluated for their support of IPv6 address parsing and this re-evaluation will continue through regular DSM maintenance.

Previously, none of the Vulnerability Scanner integrations supported IPv6 addresses at all.  There were no data fields for host IPv6 addresses and the scanners could not connect to IPv6 data sources. It wasn't even possible to schedule a scan against an IPv6 address range. All of this has changed in UP10, scanners will connect with IPv6 data sources and will collect IPv6 interface address information. Asset Profiles will now benefit from IPv6 scan data whereas IPv6 addresses could only be added manually in the past. This enrichment greatly improves asset searches, reporting and correlation.

Several of the older CRE function rule tests supported IPv4 only. Most of these are fixed in UP10 and the remaining couple will be addressed in future releases. There were alternatives for most of these tests but using them was inconvenient or complicated. Since the CRE is really the core of the SIEM, these improvements are critical. In addition, support for IPv6 geo data in the CRE has been completed and future Auto Update packages will include IPv6 geo data.

Some remaining issues

There are a few areas where improvement is still needed. While these are generally less critical than the above improvements, they are still noteworthy or require minor work-arounds. These include:

• There is currently no public IPv6 AutoUpdate server
• Dual-stack support for management interfaces is limited
• Superflows are not supported for IPv6 flows
• For the moment, cloud marketplace images do not support pure IPv6 deployments

There are plans in place to host Auto Update (AU) on servers with public IPv6 addresses but until that migration is complete alternatives are required in pure IPv6 deployments. The AU scripts on QRadar will work through a proxy and so a dual-stack proxy will solve the connectivity issue. It is also possible to set up a private AU server on a local IPv6 host by following this guidance https://www.ibm.com/docs/en/qsip/7.5?topic=tasks-manual-updates

For dual-stack networks, QRadar includes scripts for adding secondary addresses to the management interfaces in order to add hosts in mixed IPv6 and IPv4 environments. However, as described here https://www.ibm.com/docs/en/qsip/7.5?topic=mh-adding-ipv4-only-managed-host-in-dual-stack-environment this imposes some serious limitations on HA and other deployment planning. With the release of UP10 we include a description of an alternative approach to dual-stack, using multiple interfaces, which alleviates the HA issues https://www.ibm.com/docs/en/qsip/7.5?topic=hosts-alternative-dual-stack-deployments

In flow processing, superflows have been a useful data reduction technique for flows that represent port scans and other high-volume activities. For the moment superflow processing for IPv6 packets/flows has not been addressed. Whether or not IPv6 superflows will be implemented will depend on future analysis of real-world field experiences.

Support for pure IPv6 subnets in VPCs or VNets in our cloud marketplace images is not yet complete. This will be addressed in the upcoming marketplace image releases, starting with AWS. 

QRadar is IPv6-ready

With the release of 7.5.0 UP10 QRadar is now viable and ready for IPv6 migration or fresh deployment to pure IPv6 and dual-stack network environments. Any remaining IPv6 issues are minor and workable.