No Geolocation Data in ELK "OSSEC Alerts" Dashboard

[Alessandro Di Giuseppe]

I've carefully followed the instructions for setting up Wazuh OSSEC and ELK integration from the wazuh.com

 

 

 web site, but the geolocation data comes up blank ("No results found") in the ELK "OSSEC Alerts" dashboard, as well as the events in the "Discover" tab having no geolocation.

My Wazuh is split across two servers: an OSSEC manager and an ELK stack server; OSSEC logs are forwarded to the ELK server from the OSSEC manager by logstash-forwarder, however those events do not seem to be enriched with geolocation data on arrival by the logstash server.

Updated to Wazuh-OSSEC 1.1.1 today,up-to-date on Ubuntu 16.04 packages, as well as ELK stack - no help...

I am familiar with OSSEC, but am new to Wazuh/ELK, and I believe the issue is likely centered around the Logstash configuration, I've checked those logs, but they are virtually empty. Any advice on how to troubleshoot this would be appreciated...

Thanks,

Alessandro

[Jose Luis Ruiz]

Hi Alessandro, 

Are you running any OSSEC (manager or agent) in a server with public interface? 

The geolocation only works if detect any public ip to process.

-----------------------
Jose Luis Ruiz
Wazuh Inc.
jo...@wazuh.com

<image.png>

Thanks,

Alessandro

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/CAHQ-h5DRQ-8-Z6bp%2BA-%3Ds0ytpw9J35jjYPdESPcKLLMb53tLkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Santiago Bassett]

Just to clarify, the servers or agents do not need a public interface. They can also be behind a NAT, in a local network.

Only thing required is that one (or more) of the log messages analyzed by OSSEC contain a public IP address. Also check that it is decoded properly (using ossec-logtest). If so, Logstash should take care of adding geolocation information.

I hope it helps,

Santiago.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/12F2E999-F726-495B-ACAF-486C63BC4030%40wazuh.com.

[Alessandro Di Giuseppe]

Hi Jose,

I have many events with public source or destination IPs (see below for example), however they don't seem to get tagged by the GeoIP DB.

2016 May 11 15:32:40 WinEvtLog: Microsoft-Windows-Sysmon/Operational: INFORMATION(3): Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: server.anonymous.loca: Network connection detected:  UtcTime: 2016-05-11 19:32:40.006  ProcessGuid: {AB6C4F98-86DB-5733-0000-001068070100}  ProcessId: 296  Image: C:\Windows\System32\svchost.exe  User: NT AUTHORITY\NETWORK SERVICE  Protocol: udp  Initiated: false  SourceIsIpv6: false  SourceIp: ###.###.###.###  SourceHostname: server.anonymous.local  SourcePort: 54796  SourcePortName:   DestinationIsIpv6: false  DestinationIp: 208.67.222.222  DestinationHostname: resolver1.opendns.com  DestinationPort: 53  DestinationPortName: domain

[Santiago Bassett]

HI Alessandro,

on your Logstash server check that this file exists and is not empty:

/etc/logstash/GeoLiteCite.dat

As well check that your /etc/logstash/conf.d/01-ossec.conf contains this filter:

filter {

    geoip {

      source => "srcip"

      target => "geoip"

      database => "/etc/logstash/GeoLiteCity.dat"

      add_field => [ "[geoip][location]", "%{[geoip][longitude]}" ]

      add_field => [ "[geoip][location]", "%{[geoip][latitude]}"  ]

    }

    date {

        match => ["timestamp", "YYYY MMM dd HH:mm:ss"]

        target => "@timestamp"

    }

    mutate {

      convert => [ "[geoip][location]", "float"]

      rename => [ "hostname", "AgentName" ]

      rename => [ "geoip", "GeoLocation" ]

      rename => [ "file", "AlertsFile" ]

      rename => [ "agentip", "AgentIP" ]

      rename => [ "[rule][comment]", "[rule][description]" ]

      rename => [ "[rule][level]", "[rule][AlertLevel]" ]

      remove_field => [ "timestamp" ]

    }

}

I hope it helps,

Santiago.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/CAHQ-h5C3hswAvBp_Xg-zKJ0P-YrH%2BdggKFEgHSbdEHo72kxnDQ%40mail.gmail.com.

[Santiago Bassett]

Alessandro I just realized that your public IP is in the "dstip" field, instead of "srcip" as indicated in logstash configuration. That might be the reason.

[Alessandro Di Giuseppe]

Hi Santiago,

My log file and GeoLiteCite.dat file are same as above; should I augment the current logstash filter to also tag dstip with geoip? Is there a danger or drawback to doing that?

Would I simply add the line:

source => "dstip"

below the srcip?

[Santiago Bassett]

That probably won't work, unless you define to "geoip" filters. See here the documentation:

https://www.elastic.co/guide/en/logstash/current/plugins-filters-geoip.html#plugins-filters-geoip-source

Only requirement is that the source field needs to be an IP address. 

The question is if it really makes sense to do geolocation of destination IP addresses. Typically attackers will appear as source IP in your logs, not as destination. That is why default we use "srcip". Are those destination IP addresses yours?

I hope it helps,

Santiago.

[Alessandro Di Giuseppe]

The external/public destination IPs are not mine in most cases.

My thinking about tagging destinations with Geo-location is the scenario of a machine compromised by malware, the typical behaviour is for the compromised system to phone home to C&C; in this case, the destination IP is the attacker.

Thanks for the link, I will look into it and update this thread with my findings...

Alessandro

On Thursday, May 12, 2016 at 6:31:26 PM UTC-4, Santiago Bassett wrote:

That probably won't work, unless you define to "geoip" filters. See here the documentation:

https://www.elastic.co/guide/en/logstash/current/plugins-filters-geoip.html#plugins-filters-geoip-source

Only requirement is that the source field needs to be an IP address. 

The question is if it really makes sense to do geolocation of destination IP addresses. Typically attackers will appear as source IP in your logs, not as destination. That is why default we use "srcip". Are those destination IP addresses yours?

I hope it helps,

Santiago.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.

To post to this group, send email to wa...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/CAHQ-h5DRQ-8-Z6bp%2BA-%3Ds0ytpw9J35jjYPdESPcKLLMb53tLkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.

To post to this group, send email to wa...@googlegroups.com.

[KALRONG]

Sorry for bringing up an old thread but I faced the same problem and reached this thread before actually finding the solution, here is the link ot the issue in github that helped me:

https://github.com/wazuh/ossec-wazuh/issues/26

Hope it helps!

[Pedro Sanchez]

Hi KALRONG,

Thanks you so much for refering the link in this thread, I am sure it will help in the future to other people with same issue.

Geo IP Mapping for Windows Logs

SrcIP field in Windows logs

Solved:

https://github.com/wazuh/ossec-wazuh/issues/26

Best regards,

Pedro S.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.

To post to this group, send email to wa...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/f242b807-a8d1-428d-82a3-7db738f4ab3c%40googlegroups.com.