SIEM Hosts/All Hosts Tables Empty

Started playing with SIEM after upgrading our Stack and some agents to 7.2. I currently have winlogbeat and auditbeat sending data to our stack. Auditbeat has the host and process modules enabled, winlogbeat is sending Application, Security, and System logs. The Overview page shows the following:


However, going into the Hosts section, most of the tables are empty.

What agent/configurations are needed to pull this information or are these tables only filled by non-Windows systems?

Hi Walker, thanks for trying the Elastic SIEM beta!

Beats running 7.2 or later write events that conform to the Elastic Common Schema.

The default index patterns for SIEM events are auditbeat-* , winlogbeat-* , filebeat-* , and packetbeat-*.

If the indices named above are only populated with data from older versions of Beats that don't yet conform to the Elastic Common Schema, the widgets in the SIEM app won't show much, if any data.

The SIEM Guide (Beta) 7.2 » Get up and running guide includes links to the latest versions of Beats that populate events that conform to the Elastic Common Schema.

I must be doing something wrong with my Elastic Stack in general, everytime I update, then manually setup the template for beats agents, I have to delete previous indices to resolve mapping conflicts.

In general, for the All Hosts table to work, you need documents containing a field. Can you check you do, and maybe post an example JSON document from the Auditbeat Process dataset?

Hi, I'm in same case.
I have Filebeat with system module and Auditbeat with all default module (except process and socket) and my hosts table in SIEM is empty (also Authentication).

In auditbeat error log I have this error : "error encoding host information: gob: type host.Host has no exported fields "

In JSON document is defined.

Autidbeat and Filebeat send document to logstash

Elasticsearch 7.2
Filebeat 7.2
Auditbeat 7.2
Logstash 7.2

To resolve my issue, I had to delete all winlogbeat indices and manually reload the index template from a winlogbeat agent.

There's probably a better way to do it without loosing data, but that's how I did it. The same with stuff that populates from auditbeat (such as the OS name in the host info).

I resolve a part of my issue too, I had 2 filebeat-* pattern in my kibana index and one of them needed to "refresh field list". I had to delete both and recreated a new one.

But I still have an error with auditbeat module host "error encoding host information: gob: type host.Host has no exported fields ". No IP address, no mac address and no Authentications.

Hi @Gael_RICHIER, the error from the host dataset is a bug, I've just submitted a fix.

The error message means it cannot write the host information to disk to persist between restarts, but it should still send host events containing IPs and MACs to Elasticsearch. Can you confirm that you have no documents with event.dataset: host in your data?

On authentications, this is collected by the Login dataset, and from your screenshot of the Host Events widget it looks like you have login events?

Hi @cwurm, finally I deleted auditbeat elastic index and kibana index pattern and I re-setup autidbeat ('auditbeat setup') . After that, SIEM Authentication, IPs and MACs work ! :slight_smile: .

Thanks for your help.

PS: I encountered an other issue with auditbeat 7.2 on an Ubuntu 14.04 , kernel 3.13, but I think that it's not in the same subject. After started auditbeat, I have an infinite loop error on log file ('select() error: Operation not permitted').

We also had this happen after indices were set to read-only due to low disk. I expanded the disk, set ES to write again. I deleted all indices and index patterns. Still no hosts in SIEM aside from local Filebeat. Running all 7.2

I believe the host data is pulled via the auditbeat agent.

All Beats should be reporting a since 7.0 if using the default configuration (via the add_host_metadata processor). If that field is filled, it should show up in the All Hosts table.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.