Slips: a behavioral machine learning IDS/IPS you run on the endpoint

What Slips is for, and who ends up running it

Slips is an endpoint behavioral intrusion prevention and detection system. That phrasing matters: it is not a perimeter appliance that watches a span port for a whole network. It sits on a host, consumes traffic that host can see, and scores behaviour rather than matching signatures. The README describes detection as a combination of machine learning models trained to detect malicious behaviours, more than 40 threat intelligence feeds, and expert heuristics. Alerts fire when accumulated evidence crosses thresholds the project says were extensively trained.

The audience is narrow and specific. You are a security engineer or researcher who already understands Zeek output, who is comfortable reading a Python codebase, and who wants per-host behavioural judgement instead of another signature list. The project began in 2012 at the Stratosphere Laboratory at the Czech Technical University in Prague, and the repository still reads like a research tool that ships as software: a dataset directory with test PCAPs, a tests directory, and modules that can be enabled or disabled. If you want a product with a support contract, this is not that. If you want to see why a host was flagged, the evidence model is the point.

Zeek captures, Redis passes, modules decide

The architecture is visible from the requirements and the top-level layout. Slips is Python based and relies on the Zeek network analysis framework for capturing live traffic and analysing PCAPs. It relies on Redis 7.0.4 or newer for interprocess communication. So the data flow starts outside Slips: Zeek turns packets into connection-level events, those events reach Slips processes, and Redis carries messages between them. That is why the Docker run command needs NET_ADMIN and host networking: Zeek needs to see interfaces, and the processes need to talk to each other.

Input is not limited to packets. The README lists real-time traffic, PCAP files, and network flows from Suricata, Zeek/Bro and Argus. That means you can feed Slips from an existing Zeek deployment instead of running a second capture stack, which is the sensible path if you already have Zeek.

Detection is layered rather than a single model call. Machine learning models, threat intelligence feeds and heuristics each contribute, and the system gathers evidence until thresholds are met. The repository layout reflects this: separate managers, modules, databases, config and slips_files directories, plus zeek-scripts for the capture side. The practical consequence is that a false positive is usually traceable to which evidence source pushed the score over the line. The cost is that you are running several moving parts, not one binary.

Installing Slips with Docker and running a first PCAP

The README states that the recommended way to use Slips is on Docker, and that for Linux users this is the easiest path. The image is published as stratosphereips/slips:latest. The command below is the Linux and Windows host variant from the README: it maps port 55000, caps memory at 8 GB, uses host networking, and grants NET_ADMIN so Zeek can capture.

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

On macOS the README warns not to use --net=host if you want to reach the container's internal ports from the host, and it points at a different image, stratosphereips/slips_macos_m1:latest, with --platform linux/amd64.

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 container, run Slips against a bundled sample PCAP and write results to a directory. The README gives exactly this:

./slips.py -f dataset/test7-malicious.pcap -o output_dir

Then read the alerts file, which is the plain-text output you should inspect before touching any graphical interface:

cat output_dir/alerts.log

If you want the web interface instead of reading the log, the README shows adding -w and enabling the interface with -e 1, then opening http://localhost:55000/ in a browser. The same README notes Kalipso, a terminal interface, is maintained in a separate repository and pulled in as an optional submodule with git submodule update --init --recursive modules/kalipso.

Blocking is Linux only, and the memory floor is real

The sharpest limitation is stated plainly in the introduction: Slips is supported on Linux, macOS and Windows dockers only, and the blocking features of Slips are only supported on Linux. Read that twice before planning a deployment. On macOS and Windows you get detection through the Docker image, but the prevention half of the IDS/IPS label does not apply. If your requirement is inline blocking on a Windows fleet, this is the wrong tool and no amount of configuration changes that.

The resource requirement is the second constraint. Slips requires Python 3.10.12 and at least 4 GB of RAM to run smoothly. The Docker examples cap memory at 8 GB, which suggests the project expects headroom above the minimum. On a small edge device, a Raspberry Pi or a low-spec VM, you should expect to tune what runs: the repository has an rpi_scripts directory and a config directory, and modules can be enabled or disabled, but the README does not document a reduced-footprint profile. Treat the 4 GB figure as a floor for a host you also use for other work, not a target.

There is also an operational dependency worth naming. Redis 7.0.4 or newer is required for interprocess communication, and Zeek must be present for capture and PCAP analysis. In the Docker image those are handled for you. In a native install they become your problem, and the README defers native setup details to the installation documentation rather than spelling them out.

How Slips differs from Suricata and Zeek on their own

The natural comparison is with the tools Slips already consumes. Suricata and Zeek are the incumbents here, and Slips lists flows from both as inputs, which tells you the project sees itself as sitting above them rather than replacing them.

Suricata is primarily a signature and rule engine. You write or subscribe to rules, and an alert means traffic matched a pattern someone described in advance. It is fast, predictable, and easy to explain to an auditor. Its weakness is exactly what Slips targets: behaviour that no rule describes yet, spread across many connections, where each individual connection looks unremarkable. Slips accumulates evidence across connections and scores it with models and feeds, so it can flag a host whose aggregate behaviour is suspicious even when no single packet matches anything.

Zeek is a platform, not a detector. It produces rich connection, DNS, HTTP and file logs, and leaves detection to scripts you write. Slips is, in effect, one opinionated answer to what those scripts should do, shipped with models and threat intelligence instead of an empty scripting surface. The trade-off is the inverse of Zeek's flexibility: you get detection logic out of the box, but you inherit its thresholds and its false positive profile. If your team already maintains a mature Zeek script set tuned to your environment, Slips is an addition to evaluate against that, not an obvious replacement.

Licence, releases and what upgrading costs you

Slips is licensed under GPL-2.0, as stated in the README badge and the LICENSE file. For most internal security deployments that is unremarkable. It becomes a consideration if you intend to embed Slips in a product you distribute, because GPL-2.0 carries copyleft obligations that a permissive licence would not. That is a question for your own legal review, not something this article can settle.

On maintenance, the repository is not archived and the last push was on 2026-09-09. The release cadence visible in the version history is roughly monthly: v1.1.21 on 2026-06-01, v1.1.22 on 2026-07-04, v1.1.23 on 2026-09-01. The README header itself tracks the version, showing Slips v1.1.23. A roughly monthly minor release suggests a project that is still being changed rather than frozen, though the version numbers staying in the 1.1.x line also suggests incremental work rather than a rewrite.

The upgrade cost is the part the README does not document. There is no rollback procedure in it, and no migration notes for configuration between releases. The repository has a config directory and a CHANGELOG.md, so the changelog is where you would look before upgrading, but the README does not describe what changes between versions or whether config keys are stable. If you pin the Docker image by tag rather than using latest, you control when you move; the README's own examples use latest, which means following them literally gives you whatever was published most recently.

Editorial conclusion

Adopt Slips if you already run Zeek and want behavioural scoring on a Linux endpoint, since that is the only platform where its blocking features work. Do not adopt it if you need inline prevention on macOS or Windows, where the documentation says only the Docker image is supported. Before committing, verify the Python 3.10.12 and 4 GB RAM requirements against your host, and confirm that the 40+ threat intelligence feeds reachable from your network are the ones you want your alerts to depend on.

Frequently asked questions

Official sources

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