IDS News

<< Next Post - Previous Post >>

SELKS 2.0 vs. Security Onion

I have recently been testing SELKS v2.0 which is an open source Network Security Monitor (NSM) based on an ELK framework: Elasticsearch (search and analytics engine) Logstash (log normalisation) Kibana (visualisation). The NSM core engine is provided by the first "S" which stands for Suricata (Network IDS) and the last "S" which stands for Scirius (Management GUI for Suricata).
SELKS is provided as a live Linux distribution based on Debian 8 (Jessie) which is also installable.

SELKS V2.0 is a great improvement from SELKS V1.0, so much so that I now consider it a serious contender to Security Onion (SO) at least for home use. Having said that, Stamus Network , the company behind SELKS, also provides professional services which may be helpful for a pro deployment.

One of the main difference with SO, beside the ELK framework, is that SELKS only ships with Suricata, having only used Snort in the past and never Suricata (it is available on SO too) the learning curve was a bit steep (still is!), but once you realise it shares a lot with Snort such as rulesets, some config files as well as some operating logic it becomes easier to understand.
Suricata IS different from Snort on many levels, for example it is supposed to be more performant because it supports multithreading, but having run Suricata (SELKS) and Snort (SO) in parallel for a couple of weeks I am please to report they both detected similar alerts. It helped building trust in a new environment/technology I was not too acquainted with before.

SELKS v2.0 POSITIVES

  • Support for SELKS is great, the developers are proactive on IRC (#SELKS on Freenode) and github , they are refreshingly down to earth and you don't feel intimated to ask any questions. They know what they are doing, they like it and it shows!

  • The environment is brand new (Latest Debian, beta but stable software versions, etc), it means you get the latest features both in terms of security, performance and shiny gadgets

  • The framework is fast thanks to ELK and Suricata

  • Scirius makes it very easy to manage Suricata and IDS rules

  • No full packet capture means little space is used over time, you still get payload saved along with alerts so you can do most of your investigations just fine

  • The Kibana Dashboards are very comprehensive, very easy to navigate and beautiful to look at

  • Those dashboards also provides a lot of context surrounding your network traffic, not just security alerts. It really helps getting a good understanding of what is happening on your network, not just from a Security point of view. (i.e.: The DNS and TLS dashboards goes beyond the traditional HTTP only view)

    SELKS v2.0 NEGATIVES
  • I did list support as a positive, but when you compare it to the support you get for Security Onion (Doug Burks never sleeps!) and Snort, SELKS and Suricata fall a little short in comparison. There seems to be a wider community and knowledge base with Snort/SO hence why I am listing "support" as a negative if you compare it to SO. The information for troubleshooting is just not as easy to find.

  • Again, this is a positive (no pcap = low disk space) which also turns into a negative. This is one of the two negatives that prevent me from turning off SO right now. Because the payload is provided (base64 and printable) you can still get the core data you need to investigate a suspicious alert, but not having a pcap available means:
    a) you cannot replay the packets that triggered the alert, thus when troubleshooting potential missed alerts/bugs on SELKS I had to rely on SO to export pcap! I did open some Suricata issue tickets and had to provide SO/Snort pcap!
    b) quite often, if an alert is of interest being able to replay that session pcap in wireshark provides useful context.
    SO has Sguil which can easily export a given alert pcap into wireshark for further investigation. I miss this feature in SELKS. Speaking to the developers (and with the limited understanding I have of the issue) it seems to be a problem with Suricata and they are looking at different options. All we need is a way to save and export what triggered an alert so you can use it to test your rules when troubleshooting. If the pcap could be regenerated/exported from the dashboards then even better!

  • Here comes the second reason I still have SO running, and probably the main one, the threshold.conf (or threshold.config for Suricata) does not work if you try to suppress a rule for more than one IP. To me, it is a major flaw which prevents SELKS to be really useful. The reason is that you (yes, YOU!) need that level of granularity for any useful NSM. Depending of your policies, you may not just want to disable a noisy DROPBOX rule for all the devices on your network, or a TOR rule for that matter. You might have some devices for which having DROPBOX or TOR traffic is fine but for all other devices this could be a problem you would want to know about. Or it could be that a Poodle vulnerability on a given website (IP) is OK as non critical. Right now, you either have to create a suppress rule for each IP you whitelist or suppress the rule all together, this is not right and I am hoping this gets resolved soon. And if you could manage those suppress rules with an IP list from Scirius that would be an added bonus compare to SO.

  • There is no reporting capabilities out of the box with SELKS, it means you don't get a daily/weekly/monthly report nor can you get alerted when a specific alert is triggered. Although you do not get that with SO by default, it is possible to configure it fairly easily as per my previous post

    CONCLUSION
    I felt in love with SELKS, I can't get enough of it ;) (this is a wink to the SELKS' Desktop background, explaining your own jokes is never a good thing)
    Seriously, I really like both products.
    SO feels more mature, has a bigger following and therefore easier to get answers/troubleshoot. But I am somewhat getting frustrated by the fact it is still running on Ubuntu 12.04, in my view both its strength (stability) and weakness (outdated when also running other stuff on it, but then you may argue you shouldn't do that).
    SO works very well and with ELSA, BRO and SGUIL installed on that distribution by default you can access all the data you need. But that access isn't really user friendly, it is very powerful but not really eye candy. SNORBY does provide some eye candy/simple user interface though. I thought I saw a post by Doug in a SO forum stating Snorby will exit SO in the future but I couldn't find it whilst writing this post, I am hoping I am mistaken.
    I also found it wasn't easy to get enough network activity context with SO, hence why I wrote a guide on how to install SPLUNK with SO .

    SELKS feels more modern, very plug and play, really easy to use and the dashboards are not only pretty to look at, they provide great context and key information about what is happening on your network. It has a few shortcomings, especially around reporting, but I found at least one custom solution to get around that issue (which I will explain in a future post, here are two hints: wkhtmltopdf and elastalert)

    Finally, choosing SELKS or SO really depends of your business needs and how you want to use the information/intelligence they generate. However, it is clear that SELKS has gain in maturity from its first version to the current one and at the very least, it is a NSM distribution worth checking out and spending some time with!

  • << Next Post - Previous Post >>