Events are not received on the Receiver after you add a data source. In addition, you might see an existing data source that was functioning, stops sending data.
NOTE: The inability to collect events from a given data source affects visibility and can reduce compliance for data retention and logging.
Cause
There are several potential causes for a failure to get events. Typically, the cause is one of the following:
The data source is not sending data to the Receiver, possibly because of misconfiguration.
A collector problem on the Receiver is causing the Receiver to not store the received event data.
The parser process is unable to decode the raw logs into events.
The events might not be inserted into the ESM database.
The network or firewall is blocking a needed port, preventing syslog.
A problem with the SIEM policy.
Solution
To resolve this issue, work though each of these solutions in order.
Verify that the data source is configured to send data to the Receiver:
Determine which Ethernet adapter is in use. On non-HA Receivers, it is usually eth0, and on HA Receivers it is usually eth1or the 'floating' IP address.
SSH to the Receiver, type the following command, and then press Enter:
tcpdump –nni ethx host x.x.x.x
Where x.x.x.x is the IP address of the data source, and ethxis the Ethernet adapter in use.
NOTE: For syslog data sources, incoming traffic is seen on port 514 UDP. Slower data sources might need a few minutes of observation before a packet is observed. Faster ones, such as a firewall, are almost immediate. If no packets are observed, there might be a firewall or endpoint issue.
If data is not observed, double check the IP address and Ethernet number. If they are correct, the problem is likely to be on the endpoint (for example, the device was not configured properly). For non-syslog data sources, perform a connection test from the graphical user interface while running tcpdump. WMI will 'pull' data over port 135, and SQL pulls data over port 1433.
NOTE: If the IP address and port information are correct and you don't see incoming traffic in the tcpdump, a firewall or the network could be preventing inbound traffic over the specified port. Contact your network administrator for further troubleshooting steps.
Type the following command and press Enter:
iptables –n –v –L|grep x.x.x.x
NOTE:Make sure that there is a rule in place for the data source IP address that allows it through the firewall. A typical output from iptables includes the port and IP address of the data source. For example, 10.10.10.10 514 for syslog.
Select the data source in the ESM user interface and choose the Device Status dashboard. After loading, scroll down in the bottom window and find the vipsid number of the data source next to the letter v.
SSH to the Receiver and run the following command:
ls –al /var/log/data/inline/thirdparty.logs/##/XXX/in
Where ## is the vipsID number and XXX is the type of collector like syslogcollector, NPP_C, or gsql.
If there is a Data.xxxxxxfile and it is not 0 bytes, continue to Solution 2.
Make sure that the correct parser is selected. In instances where there is more than one possible parser, choose the one with (ASP) in the title. Also, make sure that the delivery and format settings are at the default unless you are using MEF or non-syslog data sources.
The data source settings and policy might not be current. Open the data source properties and change any line. For example, add a space to the name and then remove the space.
Click OK, and then click Write to write out the data source settings to the Receiver.
Roll out the policy by selecting the Receiver in the device tree and, in the Policy Editor, click Operations, Roll Out Policy. Enable the checkbox in the lower-left corner to Update Anyway.
If it is a syslog data source, enable Log Unknown syslog in the data source settings in the graphical user interface. With this action, if an event can't be parsed, it shows up as unknown and is not discarded.
Select the Interface tab and make sure that the port numbers are complete and correct for the type of data source in question. For example, 514 for syslog, 135 for WMI, 139 for RPC, 1433 for SQL.
Rules might not be turned on for the data source, so with the data source selected, open the Policy Editor. Make sure that the rules listed for that data source are enabled.
NOTE: It is normal for the default policy rules to be disabled. Do not enable policy at the default level.
If these steps do not resolve the issue, continue to Solution 3.
There might be a problem inserting events into the ESM. To see if there is a problem:
Check and see if other data sources are unable to collect data. If they are, go to Receiver Properties and perform a stop and start operation on the Receiver.
Check to determine if other data sources are working as expected.
If these steps do not resolve the issue, continue to Solution 4.
If you are still experiencing issues, it is possible that the needed changes have not been written out. The SIEM needs to write out data source settings to the Receiver and roll out the policy to enforce changes:
Open the Receiver Properties and click the Data Source tab:
If the Write button is available, continue to step 2.
If the Write button is not available, select any data source and edit it. Make a small change such as adding and removing a space to the name/description, and then click OK to force Write to become enabled.
Click Write to write out the data source settings to the Receiver.
If Policy Rollout appears, select the lower-left box to force a rollout to all devices, and then click OK.
NOTE: If it does not appear automatically, go back to the dashboard, select the ESM, click Policy Editor at the top, and then click Operations, Rollout Policy.
If you still experience issues and have followed the steps in all solutions provided, contact Technical Support for further assistance.
