Slips: behavioral network IDS/IPS with machine learning, Zeek and Redis

The gap Slips targets: behavior, not signatures

Signature engines match known patterns. Slips is built around the opposite premise: that malicious activity can be identified from how hosts behave over time, even when no signature exists. The README describes it as a behavioral machine learning-based IDS/IPS for endpoints, and says detection combines machine learning models trained to detect malicious behaviors, more than 40 threat intelligence feeds, and expert heuristics. The stated audience is anyone who needs detection on their own machine rather than at a perimeter appliance: the project began in 2012 at the Stratosphere Laboratory, AIC, FEE, Czech Technical University in Prague, and the README frames the goal as a local IDS/IPS. That local framing matters. A tool that observes one endpoint's traffic sees a narrower slice of the network than a span port does, but it also sees encrypted flows, timing and per-host repetition that a central sensor may miss. Slips also accepts PCAP files and flows from Suricata, Zeek/Bro and Argus, so it can be used offline for analysis rather than only as a live sensor. If your problem is "we have no signatures for this" or "we want to replay last week's capture and see what stands out," that is the gap this project addresses.

Evidence accumulation: how an alert actually gets raised

The mechanism the README is most explicit about is evidence accumulation. Slips does not fire on a single model score. It gathers evidence of malicious behavior and uses extensively trained thresholds to trigger alerts when enough evidence is accumulated. Read that sentence as the architecture in miniature: models, feeds and heuristics each contribute signals, those signals are stored as evidence attached to a profile, and a threshold decides when the pile is large enough to alert. The practical consequence is that a single suspicious event is unlikely to produce an alert, while a host that repeatedly trips several weak signals will. That is a deliberate trade of latency for precision, and it explains why the tool is described as behavioral rather than signature based. The README does not document the threshold values, how they were trained, or how to change them, and it does not publish false positive or false negative rates. That is the largest documentation gap in the material available, and it is the thing a prospective operator most needs. The README also does not explain how the evidence for a given alert can be inspected beyond reading alerts.log, so plan to spend time with the output format before trusting a threshold you cannot see.

Zeek and Redis are hard dependencies, not options

Slips is Python-based and relies on the Zeek network analysis framework for capturing live traffic and analyzing PCAPs, and relies on Redis >= 7.0.4 for interprocess communication. Both are load-bearing. Zeek produces the connection-level records the behavioral analysis consumes, which means Slips inherits Zeek's capture path and its performance profile; if Zeek cannot see the traffic, Slips has nothing to score. Redis sits between the processes that make up Slips, so a Redis that is unavailable or too old breaks the pipeline rather than degrading it. The README states the requirement as Python 3.10.12 and at least 4 GBs of RAM to run smoothly, and the Docker examples reserve 8 GB of memory and memory-swap. Note the version pin on Python: 3.10.12 is a specific patch release, not a floor, and the README does not say whether newer 3.10.x or 3.11 will work. If you are installing natively rather than through Docker, that pin is the first thing to verify against your distribution's packages.

Getting it running: Docker first, then a PCAP

The README recommends Docker as the way to run Slips, and the Linux and Windows command is explicit about the privileges involved: docker run --rm -it -p 55000:55000 --cpu-shares "700" --memory="8g" --memory-swap="8g" --net=host --cap-add=NET_ADMIN --name slips stratosphereips/slips:latest. Three flags deserve attention before you paste that. --net=host plus --cap-add=NET_ADMIN is what lets the container capture live traffic, and it also means the container is not network-isolated from the host. The 55000 port mapping is for the web interface. The memory caps match the stated 4 GB requirement with headroom. On macOS the README gives a different image and drops --net=host, because you cannot reach the container's internal ports from the host if you use it: docker run --rm -it -p 55000:55000 --platform linux/amd64 --cpu-shares "700" --memory="8g" --memory-swap="8g" --cap-add=NET_ADMIN --name slips stratosphereips/slips_macos_m1:latest. Once inside, the documented analysis flow is ./slips.py -f dataset/test7-malicious.pcap -o output_dir followed by cat output_dir/alerts.log. For the web interface, add -w and -e 1: ./slips.py -e 1 -f dataset/test7-malicious.pcap -o output_dir -w, then open http://localhost:55000/. The README points to the usage docs for a full parameter list rather than reproducing it, so treat -f, -o, -e and -w as the four you can confirm from this page. There is also an optional terminal interface, Kalipso, kept in a separate repository and pulled in with git submodule update --init --recursive modules/kalipso.

Blocking is Linux-only, and the README says so plainly

The limitation is stated up front: Slips is supported on Linux, MacOS, and windows dockers only, and the blocking features of Slips are only supported on Linux. So on macOS and on Windows you get detection, not prevention, even though the project name and description include IPS. Anyone evaluating Slips as an inline blocking control should read that line twice. There is a second, quieter constraint: the recommended deployment is a container started with --net=host and NET_ADMIN, which is a privileged position on the host. That is normal for a network sensor, but it means Slips belongs on a machine you are prepared to give capture privileges to, not on an arbitrary developer laptop. The README does not describe how to fail safe if Slips stops, how blocking decisions are reversed, or what happens when Redis or Zeek dies mid-capture. Those are the operational questions an IPS deployment normally needs answered, and the supplied material does not answer them. Treat the IPS label as aspirational until you have confirmed the blocking path yourself on Linux.

Where Suricata fits, and why you might run both

Suricata appears in this README as a source of network flows that Slips can consume, not as a rival. That is the honest way to read the relationship. Suricata is a signature engine: rules are written, matched and counted, and an alert maps to a rule you can read and edit. Slips is a scoring engine: models, feeds and heuristics produce evidence, and an alert maps to a threshold you cannot see in the README. The difference in approach shows up in two places. First, explainability. With Suricata you can point at the rule that fired. With Slips you can point at the accumulated evidence, but the threshold that decided it was enough is not documented here. Second, coverage. A signature engine cannot alert on traffic nobody has written a rule for; a behavioral engine can, at the cost of alerting on things that turn out to be benign. The README positions Slips alongside Suricata, Zeek/Bro and Argus as flow sources, which suggests the intended deployment is complementary: keep the signature engine for known-bad and add Slips for the behavioral layer. If you already run Suricata, feeding it into Slips is a smaller change than replacing it.

Maintenance, releases and the GPL-2.0 obligation

The release cadence visible in the material is roughly monthly: v1.1.21 in June 2026, v1.1.22 in July, v1.1.23 in September, with the last push to master on 2026-09-09. That is frequent enough that a pinned Docker tag will drift from master, and the README's own examples use stratosphereips/slips:latest, which is the opposite of pinned. If you need reproducible behaviour, pin a version tag rather than latest, because the behavioural thresholds that decide alerts are part of the code you are pulling. The upgrade cost is mostly the dependency chain: a Slips bump can imply a Zeek or Redis change, and Redis has a hard floor of >= 7.0.4. On licensing, Slips is GPL-2.0. That is a copyleft licence, and it matters if you plan to redistribute Slips inside a product or link it into a proprietary appliance. The README does not discuss commercial licensing or exceptions, and this is not legal advice; if redistribution is on your roadmap, get the question answered by someone qualified before you build on it. For internal detection use, the licence is unlikely to be the deciding factor.

Editorial conclusion

Slips is worth adopting if you already run Zeek or Suricata and want behavioral scoring on top of signature alerts, and you accept that blocking only works on Linux and that the README does not document threshold tuning. It is the wrong tool if you need a signature engine with per-rule latency guarantees, or if you cannot give it Python 3.10.12, Redis >= 7.0.4 and 4 GB of RAM. Before deploying, run the documented pcap and inspect the evidence behind each alert: ./slips.py -f dataset/test7-malicious.pcap -o output_dir then cat output_dir/alerts.log.

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. stratosphereips/StratosphereLinuxIPS on GitHub