Blog List – Alternate Layout – Load More


This first edition of SELKS 4 is available from Stamus Networks thanks to a great and helpful feedback from our open source community – Thank you! This new major release features a version jump for all the main software stacks. Suricata switches from 3.2 to 4.0, Elastic stack is ugpraded from 2.5 to 5.5 and even Debian is now Stretch, the latest stable release.

SELKS is both Live and installable Network Security Management ISO based on Debian implementing and focusing on a complete and ready to use Suricata IDS/IPS ecosystem with its own graphic rule manager. Stamus Networks is a proud member of the Open Source community and SELKS is released under GPLv3 license.

This is a major new release featuring all components upgrade and of course latest Suricata.

New Features

  • Suricata IDS/IPS/NSM 4.0.x – latest Suricata packaged with Hyperscan enabled for extra performance boost. The latest edition of Suricata among many fixes and improvements includes:
    • extra alert data like for example http body added to the alert json logs wherever available
    • protocol renegociation which means STARTTLS and CONNECT support
  • Major upgrade from Elasticsearch/Kibana/Logtsash (ELK) 2.x to the ELK 5 stack making available a ton of new features and enhancements.
  • Scirius 1.2.4 – bugfixes, better correlation capability with EveBox and introduction of IPS rules support.
  • Evebox – many new features including reporting and comments on the log events.
  • Debian Stretch – All new OS features, kernel and tools.

As always – as a Stamus Networks extra sauce the latest stable kernel (4.12.8 at the time of this writing) is available for install if you wish.


To download SELKS 4:

  • SELKS with desktop: Torrent, HTTP (MD5sum: 70783e4d441932103c3410c0b778b401)
  • SELKS without desktop: Torrent, HTTP (MD5sum: 335e31cd2b3a864f432c7d57efe007cd)


To remotely access the web management interface :

  • – Scirius ruleset management and a central point for all dashboards and EveBox alert and event management.

Usage and logon credentials (OS and web management user)

  • user: selks-user
  • password: selks-user (password in Live mode is live)

The default root password is StamusNetworks

Visual tour

Some visuals to give you a glimpse of the things you can do with SELKS.

Scirius – ruleset manager and dashboard central management console.

Scirius – rule availability by ruleset information.

Scirius- “google” search your rules

Dashboards – mail attachments

Dashboards – mail application supplemental info

Dashboards – DNS geoip heat map

Dashboards – VLAN supplemental info

Dashboards – availability of full events correlation via EveBox and Scirius

Dashboards – extra http data for better visibility.

Dashboards – ssh data available for drill/break downs as well.

Dashboards – dns events at a glance

Dashboards – alert supplemental log information.

EveBox reporting

Dashboards – valuable break down of alert data information.

Dashboards – break down of http user agents that have generated alerts

EveBox – alert comments availability.




Upgrade from SELKS 3

To upgrade your existing SELKS 3 to SELKS 4 preview, please refer to SELKS-3.0-to-SELKS-4.0-upgrades wiki page.

Create your own ISO

SELKS 4 is available for download ready to use (as explained at the beginning of the article).

However – if you want to you can create and/or customize your own SELKS 4 ISO

Once installed
  • Please refer to Initial Setup section of the documentation
  • Keep your SELKS up to date
  • Recommended initial set up for SELKS 4.0 is 2CPUs 5-6Gb RAM
  • If you need to reset/reload all the dashboards  – you can do like so
    • In Scirius on the top left corner drop down menu select System Settings
    • click on the Kibana tab
    • choose Reset SN dashboards

Feedback is welcome

Any feedback as always is greatly appreciated! 🙂

Give us feedback and get help on:

Thank you!

Suricata 4.0 and why it does matter

Suricata 4.0 is out and this switch from 3.x to 4.x is not marketing driven because the changes are really important. This post is not exhaustive on changes. It is Stamus Networks’ take on some of the important changes that have been introduced in this version.

Rust addition

This is the big step forward on the technology side. Suricata is written in C language. This gives performances and a good control over memory. But it goes with a series of well known problems. I name here buffer overflows, use after free, …

And the worse is that Suricata is parsing traffic content which is a kind of vice supercharged user input. If one should not trust user input, guess how careful we should be with network traffic. At Suricon 2016, Pierre Chifflier did present a proof of concept implementation of protocol parsers in Rust. The idea is to use the property of Rust that has been designed to avoid complete class of attacks on memory handling. But there is more in the approach as the implementation is using Nom which is a Rust parser combinator framework. It allows you to write protocol parser easily and in a reusable way. Thus the addition of Rust is two things at the same time: more security and easier code. Which means a lot of new protocols should be added in the near future.

Suricata 4.0 Rust support comes with NFS, DNS and NTP. NTP support is implemented via an external crate (read library): ntp-parser.

As mentioned before, the code uses Nom and the syntax is very different from traditional code. For instance, here is the code of ntp-parser parsing NTP extension:

named!(pub parse_ntp_extension,
           ty: be_u16
        >> len: be_u16 // len includes the padding
        >> data: take!(len)
        >> (

This define a parsing function that read the stream of data. The code says, take 16 bits, store them as unsigned integer in ty. Then store the next 16 bits as unsigned integer in len. Then store in data a chunck of data of length len. And with that build a NTP extension structure. If the writing is concise and efficient, the best thing with Nom is under the hood. Nom is taking care of detecting the invalidities. For instance we could have a chunck of data of length 50, and len being set to 1000 (remember Heartbleed ?). Nom will see that there is not enough data available in the chunck and return it wants more data.

Better alerts

As you may know, the preferred output of Suricata is the EVE JSON format. It is flexible, easy to extend and easy to read by human and tools. Suricata 4.0 is introducing some major changes here:

  • ‘vars’ extraction mechanism
  • The new target keyword
  • HTTP bodies logging
HTTP body output

Suricata is able to uncompressed HTTP body on the fly and match on the uncompressed content. This means that if you get the payload of the stream triggering the alert in your event, you will just see compression noise and won’t be able to analyze why the alert was triggered. Suricata is now able to include the HTTP bodies in the alert. The analyst can then directly see from the event the content that did trigger the alert.

The following event shows how payload_printable is completely compression noise and the http_response_body_printable is readable:

Target keyword

The new target keyword is a fix on a very old problem. It is not possible to know in an alert event which side of the source or destination is the target of the attack. This is a problem as it is not possible to automate things due to that lack of information. The target keyword allow the rules writer to specify which is side is the target. Doing so automated analysis and better visualization can be made.

Usage is simple, signature has to contain the target keyword with value dest_ip or src_ip. For example, in a simple scan alert we have:

alert tcp $EXTERNAL_NET any -> $HOME_NET 3306 (msg:"ET POLICY Suspicious inbound to mySQL port 3306"; flow:to_server; flags:S; threshold: type limit, count 5, seconds 60, track by_src; reference:url,; classtype:bad-unknown; target: dest_ip; sid:2010937; rev:2;)

If target is present in a signature, the alert is added an alert.source and field:

For example, on a visualization where node are IP address and links are alerts between the two, we can get an idea of the possible compromised path. With the target addition, we can switch from a non oriented graph:

To an oriented graph that show which paths were really possible:

If you know French, you can learn more about this subject with Eric Leblond’s talk at SSTIC 2017.

Vars extraction

This is one of the most expected feature of Suricata 4.0. This has been described by Victor Julien in an extensive blog post. The concept is to be able to define in signature data to extract and store them in a key value form. There is a lot of possible usage ranging from application version extraction to getting exfiltred data. For example, let’s consider there is a domain we are interested in. One interesting information is the list of email addresses where mail are sent to. To do so we can use the following signature:

alert smtp any any -> any any (msg:"Mail to stamus"; content:"rcpt to|3A|"; nocase; content:""; within: 200; fast_pattern; pcre:"/^RCPT TO\x3a\s*<([\w-\.]>/ism pkt:email"; flow:established,to_server; sid:1; rev:1;)

The magix here is the groupe in the regular expression ([\w-\.] that is save in a packet var named email by the pkt:email in the regular expression definition.

Using that signature we get this kind of alerts:

The key point here is the vars sub object:

  "vars": {
    "pktvars": [
        "email": ""

We have an extraction of the data and this can be easily search by tool like Elasticsearch or Splunk.


Suricata 4.0 is really an important milestone for the project. Introduction of Rust is opening a really interesting path. The alerts improvement may change the way signatures are written and it will help to provide really accurate information to the analysts.

Suricata 4.0 is already available in SELKS and it will be available in Stamus Probe by the end of August. To conclude on a personal note, we, Stamus Networks, are really happy to have contributed to this release with features such as via HTTP body logging and target keyword.