Suriflaska – Flask server for testing Snort / Suricata rules

This post is a small follow-up on the network detection theme that I have been posting the last couple months. Recently I got more into writing rules for detecting network threats and wanted to create something similar to what is used in some bigger blue team companies.

So without going too much in the why’s, and for the people that want to just use the tool: hi.

What is suriflaska?

Suriflaska is a mix of using suricata with the Python Flask framework. The front-end of the script is build with Flask, it’s an easy and convenient way for non-web developing people like myself to quickly spin up an instance to work with.

This tool can be used to test out your newly written Snort / Suricata rule against the PCAP that you provide. The system will run the suricata command for replaying PCAP’s with a given ruleset and output whether your rule matches the signature, doesn’t match, or simply has some errors in the syntax.

There’s also an option to pick from the earlier uploaded PCAP’s with a little drop-down menu (fancy stuff huh?).

The suriflaska interface

How it works

It’s actually a very simple idea (thanks for the input Mike!), based on the ‘-r’ option that can be given to suricata when run from the terminal. The ‘-r’ option is the replay option of suricata which the user can replay PCAP’s with, you are free to give more flags that specify things like the configuration file to use, which run mode, a specific rule file, and much more.

In this case the following command gets executed:

suricata -c suricata.yaml --runmode autofp -S match.rules -r test.pcapng -l log/ 2>error/log && cat log/fast.log

The default YAML configuration file used by suricata has to be changed a little bit to check if a rule matches a given signature. For this application I specified a rule file that gets it’s rules from the Flask front end shown above. This way a rule can be tested quick and easy.


This part will go over the command that is shown above, I will go into every flag and option briefly.


The first thing that needed to be changed was the YAML configuration file that suricata uses. By default it does not output the ‘fast.log’ file which is the log file holding the match if a certain signature matches data present in the network traffic. The suricata configuration file that is present in the repository has the change already and can be used ‘out of the box’.

Suricata Run modes

The next thing was figuring out the right run mode to use, there are a couple run modes for production environments:

  • Single – Single Threaded Mode;
  • AutoFP – Processing a packet is pipelined to multiple stages. Every thread handles a stage;
  • Workers – Multiple workers, each worker handles the packet it’s assigned to.

I chose to use the AutoFP runmode, in this mode multiple threads try to acquire packets, and then put the packets through a pipeline for further processing. Since I intended this to be run in a Docker instance I did a little research and found this article. It is written in a way that makes it seem suricata wastes performance, but in the end AutoFP seems to be the better choice for running it in a Docker container.


Suricata uses text-files containing ‘rules’ that check for any matching signatures when monitoring and/or replaying network traffic. If a certain packet contains data (like a GET request, DNS lookup, etc.) that matches given signature, it will ring the bell. For this application a specific rules file is given, this file is empty and will be populated with the signature the uses writes in the front end of the Flask application. This way the user can write rules easy without the need to rewrite the rule every time.

Replaying PCAP files

As you might’ve guessed this is done with the ‘-r’ flag. You can either upload a new PCAP file, or pick one already uploaded in the past by clicking on the drop-down menu.

Log output

The ‘-l’ option specifies where to output the log files that are generated by suricata. I set this to use the log folder that is present in the repository. The ‘fast.log’ file will get populated with data if a rule matches a signature, this is also the file that will be checked every time the user submits a query.

  • If a rule matches the traffic in the given PCAP it will display ‘Signature matches!’;
  • If a rule does not match the traffic in the given PCAP, but does not contain syntax errors it will simply display ‘Signature doesn’t match’;
  • If a rule contains syntax errors these will be displayed below, it will be up to the user to check the output and fix the rule.


This application was build to be run in a docker instance, I am fairly certain that this application is not secure at all so please do not use this in a production environment.

To use the Docker instance, install Docker and run the following command in the ‘suriflaska-docker’ folder to build the docker image:

sudo docker build -t suriflaska .

After the Docker image is build you can run the application with the following command:

sudo docker run -p 5000:5000 suriflaska

Check if it is running by opening a browser and navigating to


I build this application because I wanted to easily test rules without having to replay a PCAP against my SecurityOnion instance every time. This way it costs me less time to test out rules and writing a rule is more convenient this way than it is to edit a rules file, updating the rule signature of the whole SecurityOnion instance, replaying the PCAP and waiting another minute or so to see the results.

Again, I did not come up with this idea as I have seen more stylish and robust applications build this way. This is my poor implementation of this idea, suited to what I needed and nothing more. If you have any questions/rants/critique/suggestions/etc. feel free to contact me at