IBM Support

QRadar: Troubleshooting events that are visible in TCPDump but not in Log Activity (martian packets)

Troubleshooting


Problem

A user creates a new log sources and sends the data to QRadar, but the events are not visible in the Log Activity tab. If the user checks in the command line, the tcpdump command shows the packets being received from the source device, but are not displayed in the user interface. This technical note explains how to validate if the interface believes the packets are spoofed or malformed (martian) and how to correct this problem.

Symptom

Events can be seen from the event source by using the tcpdump command, but are not displayed in the Log Activity tab of the user interface.

Cause

The network interface can assign packets as 'martian', meaning that the network interface believes the packet to be incorrectly forwarded, spoofed, or malformed. When Syslog events are sent to QRadar, but the network interface flags them as martian, the packets are dropped before they enter the event pipeline (ecs-ec-ingress) and a message is written to /var/log/messages. The Syslog event is not parsed by QRadar and does not appear in the Log Activity tab.

Diagnosing The Problem

The most common scenario for 'martian' packets is redirected, spoofed IP addresses, or incorrectly routed packets in the network. Administrators who experience issues with martin packets logged in /var/log/messages/ need to contact their network team to determine why the network interface is routing or modifying packets incorrectly.

Procedure
  1. Use SSH to log in to the QRadar Console as the root user.
  2. Open an SSH session to the QRadar appliance receiving the events.
  3. Type the following command to verify whether the interface is logging packets from your source device as 'martian': 
    /var/log/messages | grep martian
    For example, the QRadar appliance is identifying events on eth1 interface as a martian source. 
    Sep 25 14:13:51 radar kernel: martian source xx.xx.xx.xx from xx.xx.xx.xx, on dev eth1
    Results
  • If your appliance is reporting events from a device in tcpdump, but not identifying any martian sources, contact QRadar Support for more assistance with this issue.
  • If your appliance is reporting martian sources for events, see the Resolving the problem section.

Resolving The Problem

If martian sources are reported in /var/log/messages, contact your network administrator to correct the routing or packet spoofing issues. If you continue to experience issues, you can modify your rp_filter settings. As these settings alter how appliances prevent IP spoofing from DDos attacks, strict mode is enabled by default per RFC3704 on QRadar appliances.

Procedure
If your appliance is proxied or firewalled, discuss a change with your network admin to consider loose or setting the disable option for rp_filte on IPv4 addresses. Disabling filtering by setting the configuration to 'No source validation' can resolve this issue when network errors cannot be easily correct, but might expose your appliance interfaces to security issues.

  1. Use SSH to log in to the QRadar Console as the root user.
  2. Open an SSH session to the QRadar appliance receiving the martian events.
  3. Edit the /etc/sysctl.conf file.
  4. Modify the value of the net.ipv4.conf.all.rp_filter parameter to allow the configuration change to persist after a reboot: 
    net.ipv4.conf.all.rp_filter = {integer}
    Options
    0 -  No source validation.
    1 -  Strict mode filtering as defined in RFC 3704 (default).
    2 - Loose mode filtering as defined in RFC 3704.
  5. Modify the value of the net.ipv4.conf.{interface}.rp_filter parameter to allow a specific interface to use a new filtering value: 
    net.ipv4.conf.{interface}.rp_filter = {integer}
    For example, to set loose filtering on eth1, type: 
    net.ipv4.conf.eth1.rp_filter = 2
    Options
    0 -  No source validation.
    1 -  Strict mode filtering as defined in RFC 3704 (default).
    2 - Loose mode filtering as defined in RFC 3704.
  6. To restart the network service, type: 
    sysctl -p
  7. To confirm the rp_filter configuration is correct after the service restart, type: 
    cat proc/sys/net/ipv4/conf/<NIC>/rp_filter
    Results
    After the service restarts, log in to the QRadar Console and verify events are visible in the Log Activity tab. If you continue to experience issues with martian packets, contact your network team for further assistance or repeat this procedure to disable filtering, if advised by your network security team.

Document Location

Worldwide

[{"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":"a8m0z000000cwtEAAQ","label":"Log Activity"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions"}]

Document Information

Modified date:
31 August 2022

UID

ibm16606669

Page Feedback