Windows Log Ingestion to Elasticstack

[jesse...@gmail.com]

Hello all,

I want to ingest Windows 7 logs into the new implementation of Security Onion with elasticstack (ELK). I'm planning on doing this using VMware with a single Windows 7 Enterprise VM, and the newest version of Security Onion with elasticstack built in (14.04.5.4 ISO) for test purposes only. Does anyone have advice on how to do this easily?

I was thinking winlogbeats would be a good solution, but wanted to ask the community prior to executing. Any guidance is highly appreciated.

[Josh Silvestro]

Jesse,

I'm going to be moving to winlogbeat from OSSEC for reasons such as Wes described. Let me know how setup goes, I had a few moments today, installed Winlogbeat on a server, pointed it at my security onion host for elastic search over port 9200, allowed in firewall via "ufw allow 9200." Yet the server logs are showing errors that security onion is actively rejecting it. I've not had more time to poke around, but curious what you come up with.

Thanks,
Josh

[jesse...@gmail.com]

Thanks Josh,

I will give it a shot, although it doesn't appear as though ingestion using winlogbeats is supported out the box with Security Onion at this point.

I wanted to include Wes's input on this thread:

Jesse,

You have a few options here.

You could use OSSEC to forward your Windows logs to Elastic, simply adding an agent to your Windows box and opening up the firewall on your SO box for that agent. However, due to the format of the logs and the way they are handled, they can sometimes be difficult to parse consistently/accurately.

Another option would be to use Winlogbeat (as you mentioned), or even NXLog, but these may required additional configuration not already present in Security Onion.

Thanks,
Wes

[Josh Silvestro]

Right, which I understand. I did add the allow in UFW so not sure what else is needed at this point I'll try later.

[Josh Silvestro]

On Monday, November 6, 2017 at 4:53:22 PM UTC-5, Josh Silvestro wrote:
> Right, which I understand. I did add the allow in UFW so not sure what else is needed at this point I'll try later.

Jesse,

Have you given this a go yet? Any luck? I've been unable to get the logs in to elasticsearch.

[Wes Lambert]

Josh,

Do you perchance have an index created for Winlogbeat and/or have you added/selected an index pattern to search through this data?

Thanks,

Wes

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Josh Silvestro]

So that may be the step I'm missing. I see via tcpdump my Windows host attempting to send logs, and when I test the config on the Windows host it gives me the "OK."

I went to create an index pattern in Kibana and it says winlogbeat-* doesn't exist. Which I assume I need to create, but based on reading the winlogbeat docs they make it seem as the Winhost uses the template to create this.

[Josh Silvestro]

Hmm maybe note, I see it in tcpdump but now reviewing the winlogbeat logs on the host it's still denying the connection.

2017-11-11T08:24:17-05:00 ERR Connecting error publishing events (retrying): Get http://X.X.X.X:9200: dial tcp X.X.X:9200: connectex: No connection could be made because the target machine actively refused it.

UFW Rule:
9200 ALLOW Anywhere

I event broadly opened the port to rule that out as an issue.

[Josh Silvestro]

Just ran a telnet from the Windows host and it gets a connection denied, however I see in tcpdump on Security Onion that it's seeing the traffic so it's definitely making it out past the windows host, something in SO is denying it.

[Josh Silvestro]

Just rubber ducking here . . . . So I "think" the issue lies in so-elasticsearch docker image ports.

Looking at docker ps : 127.0.0.1:9200->9200/tcp, 127.0.0.1:9300->9300/tcp which from my understanding means only that host can access those ports. I noticed logstash has standalone ports such as 5044/tcp, which I assume means (outside of UFW) any host can access that port. I'm hoping I don't need to modify docker images, something that would just be overwritten after updates anyways.

[Wes Lambert]

Yes, Josh.  

These ports are only locally accessible.  This means that currently, the only way to send info via a beat would be through an SSH tunnel with a local port forward, or by modifying how the ports published in so-elastic-start, and modifying the iptables rules as necessary.  This is something that we will have to look at and determine the best direction to take.

Thanks,

Wes  

On Sat, Nov 11, 2017 at 9:38 AM, 'Josh Silvestro' via security-onion <securit...@googlegroups.com> wrote:

Just rubber ducking here . . . .  So I "think" the issue lies in so-elasticsearch docker image ports.

Looking at docker ps :  127.0.0.1:9200->9200/tcp, 127.0.0.1:9300->9300/tcp which from my understanding means only that host can access those ports. I noticed logstash has standalone ports such as 5044/tcp, which I assume means (outside of UFW) any host can access that port. I'm hoping I don't need to modify docker images, something that would just be overwritten after updates anyways.

[Josh Silvestro]

Awesome, thanks for the clarification. For ease of use (or re-install if needed) I'll leave the beats alone for now and still with OSSEC and hopefully future versions of SO have support. Thanks!

[Josh Silvestro]

On that note, one follow up question. I've sent over OSSEC logs, but I noticed they're not being parsed by logstash.

Is there a different process than the old so-allow ossec and ossec manage_agents to get it to Logstash?

[jesse...@gmail.com]

Sorry for the delay, it's been a busy week! Unfortunately, I have had no success with winlogbeat ingestion to SO. I've experienced pretty much the same issues you've been having.