Security Onion / Logstash / Kibana

[Brad Turnbough]

Hi All,

I'm looking into possibly using Security Onion, but I have some questions.

I was thinking about using Logstash and Kibana for reporting purposes for the management teams and the executive teams.

Does security Onion include Logstash and Kibana?

Brad

[Wes]

Brad,

Security Onion does not include Logstash and/or Kibana. You could still set up syslog and other logs to forward to these interfaces if you would like them as a separate, auxiliary platform. Security Onion currently uses ELSA to gather and review various logs.

Thanks,
Wes

[Daniel]

Somewhat related, but the OSSEC Server Appliance VM does include them if you wanted to use it for testing.
http://www.ossec.net/?page_id=19

I would use logstash-forwarder (or the new Filebeat) instead of syslog to send the data over.
https://www.elastic.co/products/beats/filebeat

>
> Brad

[Doug Burks]

Hi Brad,

What exactly are you looking to do with Logstash and Kibana? Perhaps
there is some way to do it with ELSA (already included in Security
Onion).

> --
> 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-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com

[Brad Turnbough]

Centralized log management.

We use iptables for our firewalling, and currently log to Logstash / Kibana. It'd be nice to be able to (additionally) centralize all of that logging to a database such as that so that we'd have a greater understanding of historical timelines.

[Doug Burks]

ELSA can definitely do log management. If you enable ELSA when
deploying Security Onion, then each Security Onion sensor becomes its
own log collector. You can send logs from your infrastructure devices
to their nearest Security Onion box using standard syslog (port 514
udp or tcp) or using an OSSEC agent which gives you encrypted log
transport, file integrity checking, rootkit detection, and more. Your
central ELSA web interface can then slice and dice all logs across
your entire enterprise.

Here are some screenshots of some firewall logs being parsed:
http://blog.securityonion.net/2015/03/four-package-updates.html

[Brian Kellogg]

+1 for for Doug's comment

Combining OSSEC and ELSA capabilities with logs is very powerful.

Having all your network IDS/Bro logs combined with your host logs presents a lot of utility both in the ELSA web interface and mining ELSA from the command line.

[Kevin Branch]

From a resource level, ELSA definitely gives you the most bang for your buck.  I've experimented with the ELK stack and I can't even come close to handling the data ingestion loads that ELSA takes in stride, with similar hardware running an ELK stack.  ELK is way cool, and it appears to have plenty of advantages, but for my huge volumes of NSM sensor data like my Bro events, I'm sticking with ELSA.   

One thing to consider about log centralization with ELSA:  If you have a high volume of NSM events on a standalone SO setup, and then you start centralizing logs from elsewhere on that same ELSA instance, then the huge volume of your NSM log records may cause you to have far less retention for other log types than you were hoping.  For example, I've got an ELSA instance limited to 1TB of data on a standalone SO server, which is only getting me about 20 days of log retention, not near long enough for what I'd need for pulling in Linux and Windows logs for example.  This would be a good case for using a distributed SO deployment where the site-wide log centralization happens on the SO server ELSA instance but the huge log streams generated on the SO sensors stay on the ELSA instances of the sensors.  Or you could use ELSA for the NSM sensor log streams and a separate ELK setup for centralizing general logs.  It depends on the relative merits of being able to pivot between SO and non-SO log data, vs having access to the advanced log aggregation/analysis features that ELK offers.

Kevin