The latest builds of EveBox support an embedded SQLite database that allow it to be used without Elastic Search for lighter loads. The SQLite support was added to support two use cases that may be of interest to some.
One Shot Mode
One shot mode is the loading of a single eve.json into a temporary database and allowing the user to work with it, then cleaning up on exit. Probably most useful for loading up the Suricata log file after running over a PCAP, or just trying out EveBox for the first time. Example usage:
./evebox oneshot /path/to/eve.json
If all goes well your browser should eventually open up and display the EveBox Inbox.
Self Contained Mode
For lack of a better name, self contained mode is the usage of EveBox without any external dependencies. This is suitable for lighter loads when running EveBox on the same machine that is running Suricata. Example usage:
./evebox server --datastore sqlite --input /var/log/suricata/eve.log
The idea here is just a simple way to get a GUI for your Suricata events without messing around with any configuration or databases. However, you may want to create a configuration file and setup a retention period to keep your SQLite database size in check (more documentation coming soon).
If you have multiple Suricata instances, and believe the load to be light, you can configure an EveBox agent to send events to the SQLite enabled server, but your mileage will vary as you add more load.
Using Elastic Search?
If using Elastic Search the agent and/or the –input option may still be interesting as alternatives for shipping eve logs to Elastic Search, and open up future options for dealing with the real time event feeds from your Suricata instances.
I’ve been asked a few times now for “stable” APT and Yum repositories as the current ones are marked “development”, in fact they contain the packages created on Travis-CI runs of the master branch.
So I’ve added stable repos for Yum and Apt. For the short term they still contain builds out of the master branch, but uploaded by me instead of the output CI, and they will transition to only tagged releases after the next release, 0.6.0 which I will probably tag soon.
The builds in the repos above should work with any modern x86_64 Fedora, CentOS, EL, Debian or Ubuntu distribution.
And if you’d rather just get at the files, I’ve made it a little easier than the Bintray URLs make it — https://evebox.org/files/development/.
I recently installed some honeypot software and am logging the traffic with Suricata into Elastic Search with Logstash. I know its a bit of a risk to expose Elastic Search like this, but I thought it could make a good demo for EveBox.
To check it out head over to https://demo.evebox.org/ with the username “evebox” with the same as the password.
This probably won’t be up for too long, it will depend on how useful the honeypot is to me at this time.
Update – 2017-11-24 – Update URL to point to the EveBox demo.
While getting familiar the very popular Docker Linux container tool, I went against best practice and put Suricata, Logstash, Elastic Search and Kibana into a container that is looking promising for demonstration purposes. If you already run this stack on one machine, it might be suitable for real use as well.
What you get is a very simple to run application container that abstracts all the tools above into a single application.
Assuming you have Docker already installed, you can get a feel for Suricata + ELK with a couple commands:
git pull https://github.com/jasonish/docker-suricata-elk.git cd docker-suricata-elk ./launcher start -i eth0
The first time ./launcher start is run, Docker will pull down the container file system layers so it may take a while. Subsequent starts will be much quicker.
Once it looks like it is up and running, point your browser at http://localhost:7777.
A few notes:
- Docker containers are more or less stateless. Changes to the filesystem inside the container are not persisted over a restart. Instead any data that needs to be persisted will end up in the ./data directory where you started the launcher.
- This container uses host networking instead of the usual isolated network you find with Docker containers. This is to give the container access to your physical interfaces. This alone has me questioning Docker for network monitoring deployments.
- As host networking is used, the container will probably fail if you have existing applications bound to port 7777 or 9200. Making these ports configurable is on the todo.
- The containers log directory is available from the host system. Take a look in ./data/log.
- Suricata is built from git master.
./launcher enterwill give you a shell inside the running container. This is useful to take a look around the runtime environment. Just remember that any changes you make will not be persistent.
./launcher bashwill start a new container with the bash shell and nothing running. This is mostly useul for development.
- If running a VM, allocate 2GB of memory and/or create a swap file. These are not lightweight applications.
Kibana is really good for getting a high level overview of your Suricata events, but I didn’t find it very useful for reviewing individual events, and I’m not really sure if Kibana is really built around that idea, so I created EveBox, a web based event viewer for Suricata events being logged to Elastic Search in “eve” format with a focus on keyboard navigation:
Yes, forgive the “yet another bootstrap app” looks, but I’m not a designer nor do I pretend to be.
If you log thousands, or even hundreds of events per second, then EveBox is probably not for you, the “inbox” will be unmanageable. However, if you run a highly tuned ruleset, EveBox gives you full keyboard navigation review of those events.
Its still a little crude in some areas, for example, if you open an event to get further details you are just going to see the JSON as returned by Elastic Search, personally I like this but I think something a little easier on the eyes is needed. It will also be more useful with eve logs the alert packet, but for now it pivot to Dumpy (a rather basic daemonlogger spool directory frontend) to get a packet capture of the alert triggering data.
I’ve also learned that while Elastic Search is great (well, more like awesome) for searching, its not the best tool for mass updates of records such as “tagging” every entry that matches a query. For such cases it might be useful to introduce a backend at some point so the HTML5 application can hand off some of the grunt work to a backend server that can handle the batch tasks. PostgreSQL 9.4 with its new JSON(b) column could also prove to a very capable data store for Suricata eve events (Cassandra might be another option as well).
If you would like to try, go get the latest release and drop it on a web server. For now its just straight up HTML like Kibana, so its basically a 0 effort install. If that sounds to hard head over to http://codemonkey.net/evebox, click on settings and enter the URL to your Elastic Search server. The “inbox” won’t be there until you configure Logstash accordingly, but you can still review events under “All’. NOTE: My server will not connect to your Elastic Search, the settings only tell the HTML5 application where to connect to Elastic Search).
If you are not yet using Suricata, Snort can easily be used instead. For more info on sending Snort events to Elastic Search in “eve” format see my post Snort, Logstash, Elastic Search and Kibana…