SLIPS on Ubuntu 24.04 LTS on Azure
This image ships SLIPS (Stratosphere Linux IPS) v1.1.22 on Ubuntu 24.04 LTS, ready to inspect this machine's traffic from the first boot of every deployed virtual machine. SLIPS is installed unmodified from the Stratosphere Laboratory's own source release, and the complete corresponding source is present on the image at /opt/slips.
SLIPS is a behavioural, flow-based network intrusion detection and prevention system. Rather than matching packets against fixed signatures, it hands captured traffic to Zeek to reconstruct connection flows, builds a behavioural profile for every host it sees inside Redis, and raises evidence and alerts from a suite of detection modules covering port scans, long and unusual connections, threat intelligence blacklists, command and control channel behaviour and malicious TLS fingerprints. It runs on a live interface, as an inline sensor on traffic routed through it, or offline over packet captures for forensics.
What this sensor can and cannot see on Azure
Read this section before you deploy. It is the difference between a sensor that does what you think it does and one that quietly does not.
SLIPS's core mechanism works exactly as designed on Azure. It profiles the traffic it is given, and on an Azure virtual machine it is genuinely given this machine's traffic. That was verified during the build of this image: SLIPS was run against a real malicious packet capture and Zeek reconstructed hundreds of connection flows which SLIPS ingested into its analysis database and profiled into per host behaviour.
What Azure constrains is not the mechanism, it is the visibility scope. An Azure virtual network interface receives only the frames addressed to it. The software defined network does not flood, there is no promiscuous mode that would let one virtual machine see a neighbour's traffic, and Azure Virtual Network TAP, which would have been the packet mirror source, never reached general availability. So three topologies are real, and they are the ones this guide documents:
- Host IDS. Inspect this virtual machine's own ingress and egress on the primary interface. This is the shipped default and needs no configuration.
- Inline network virtual appliance. With IP forwarding enabled and a user defined route pointing a subnet's next hop at this machine, SLIPS inspects everything routed through it. This is the only honest way to cover other machines, and it is a first class Azure pattern.
- Offline. Analyse packet captures taken elsewhere with
slips.py -f capture.pcap.
What this appliance cannot do is passively monitor a subnet the way a physical network tap or a SPAN port can. If you need that, use topology 2 and route the traffic through this machine deliberately.
What makes this image different
SLIPS is installed unmodified from upstream, and the whole machine learning stack is present in a Python virtual environment at /opt/slips/venv. To run reliably within the memory footprint of the recommended virtual machine size, the two most memory intensive modules (the TensorFlow RNN command and control model and the river flow machine learning model) are disabled in the shipped configuration, exactly as the upstream slips_light variant does. The full behavioural and threat intelligence detection core stays enabled, and you can re-enable the machine learning modules on a larger machine (see the troubleshooting section).
Redis is the heart of SLIPS, and SLIPS does not support a Redis password. This image therefore binds every Redis instance to 127.0.0.1 only, so the datastore is never reachable off the machine, and the only network port open is SSH using the key you supplied. There is no login, no web interface and no bootstrap credential anywhere in the image to leak.
The capture interface is a fact about your machine, not ours, so the shipped configuration is a template the service deliberately refuses to start on until first boot has rendered it against this instance's own interface. Two independent levers enforce that, and both are tested to fail closed during the build.
1. Deploy the virtual machine
Deploy the offering from the Azure Marketplace. The recommended size is Standard_B2s (2 vCPU, 4 GiB), which matches SLIPS's documented minimum and the footprint proven at build time. For busy live interfaces with the machine learning modules re-enabled, choose Standard_B2ms (8 GiB) or larger. Provide your SSH public key when prompted; there is no password login.
Open only SSH (port 22) to your own address. SLIPS exposes no other network service.
2. Connect to the virtual machine
ssh azureuser@<vm-ip>
Replace <vm-ip> with the public IP address of your virtual machine.
3. Confirm the appliance is running
SLIPS and its Redis datastore start automatically at boot, after a first boot service has rendered this machine's capture interface into the configuration.
sudo systemctl is-active slips redis-server
test -f /var/lib/cloudimg/slips-firstboot.done && echo "first boot: complete"
cat /opt/slips/VERSION
grep SLIPS_IFACE /etc/slips/slips.env
You should see both services active, first boot reported complete, the SLIPS version, and the capture interface resolved to this machine's primary network device.
4. Confirm SLIPS is profiling the interface
SLIPS launches one worker per detection module. You can see the modules it loaded and confirm the datastore is bound to loopback only.
sudo redis-cli -h 127.0.0.1 ping
ss -lntp | awk 'NR==1 || /redis/'
pgrep -c -f slips.py
Redis answers PONG on loopback and is listening only on 127.0.0.1, and the process count shows the SLIPS worker fleet is up and analysing the interface. An Azure NIC only receives its own traffic, so on a quiet machine SLIPS profiles this host's own flows; route traffic through it (topology 2) to profile more.
5. Prove the analysis pipeline on a bundled capture
The image ships the upstream sample captures at /opt/slips/dataset. Analyse the bundled malicious sample offline to see the full pipeline run end to end: Zeek reconstructs the capture into connection flows, and SLIPS profiles the hosts it sees into its analysis database. On a 2 vCPU machine, stop the live sensor first so the offline analysis has the machine's full resources; it takes a minute or two, and you restart the sensor afterwards.
cd /opt/slips
sudo systemctl stop slips
sudo rm -rf /tmp/slips /tmp/slips-demo
sudo timeout -s KILL 110 env -u SUDO_USER -u SUDO_UID -u SUDO_GID ./venv/bin/python slips.py -f dataset/test7-malicious.pcap -o /tmp/slips-demo -m </dev/null 2>&1 | tail -6 || true
sudo sh -c 'echo "Zeek reconstructed flows: $(grep -vc "^#" /tmp/slips-demo/zeek_files/conn.log 2>/dev/null || echo 0)"; echo "analysis database: $(ls -1 /tmp/slips-demo/databases/flows.sqlite 2>/dev/null || echo none)"'
sudo systemctl start slips
The output reports how many connection flows Zeek reconstructed from the capture and confirms SLIPS wrote a populated analysis database. On a live interface SLIPS additionally raises evidence and alerts as its threat intelligence feeds and detection modules build a picture over time.
6. Where SLIPS writes its findings
The live service writes into /var/log/slips. Each run produces alerts.json and alerts.txt (the raised alerts), the reconstructed Zeek logs, and a SQLite flows database.
sudo ls -1 /var/log/slips/ | head
sudo find /var/log/slips -maxdepth 2 -name 'alerts.*' 2>/dev/null | head
7. Deploy inline to inspect other machines
To inspect traffic for machines other than this one, route their traffic through this virtual machine. Enable IP forwarding on this machine, enable IP forwarding on its Azure network interface, and add a user defined route in the subnet whose next hop is this machine's private IP.
# On this VM: enable forwarding (persist across reboots)
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-slips-forward.conf
sudo sysctl -w net.ipv4.ip_forward=1
Then, in Azure (from your workstation, replacing the names to match your deployment):
# Enable IP forwarding on this VM's NIC, then route a subnet's traffic through it.
# Replace the placeholders with your resource group, region, NIC id and this VM's private IP.
az network nic update --ids <your-nic-id> --ip-forwarding true
az network route-table create -g <your-rg> -n slips-inspect-rt -l <your-region>
az network route-table route create -g <your-rg> --route-table-name slips-inspect-rt \
-n via-slips --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance \
--next-hop-ip-address <private-ip>
SLIPS now profiles every flow routed through this machine. This is the honest, first class Azure way to cover other machines; nothing else lets a cloud sensor see a neighbour's traffic.
8. Scanning scope and authorisation
Only inspect traffic you are authorised to inspect. Topology 2 routes other machines' traffic through this appliance deliberately and with your control; do not attempt to capture traffic you do not own or have permission to monitor.
9. Security posture
The appliance ships with no credentials because it has no authenticated surface. The per instance note records this machine's facts, Redis is bound to loopback only, and the first boot service refuses to render the configuration on a machine that has not resolved its own interface.
sudo sed -n '1,16p' /root/slips-instance.txt
grep -E '^bind|^protected-mode' /etc/redis/redis.conf
The note confirms there are no credentials, and Redis is bound to 127.0.0.1 with protected mode on. The preflight check that guards the service is re-asserted on every start, independently of the first boot service.
10. Logs and troubleshooting
# Service health and recent log
sudo systemctl status slips --no-pager | head -20
sudo journalctl -u slips --no-pager | tail -30
To re-enable the machine learning modules (the TensorFlow RNN command and control model and the river flow model), edit /opt/slips/config/slips.yaml, remove rnn_cc_detection and flow_ml_detection from the modules.disable list, and restart on a machine with at least 8 GiB of memory:
sudo systemctl restart slips
11. Licence
SLIPS is licensed under the GNU General Public License, version 2. The complete corresponding source for the exact version on this image is present at /opt/slips, and a written offer for the source is shipped at /usr/share/doc/cloudimg/SLIPS-GPL-2-WRITTEN-OFFER.txt. SLIPS's Python dependencies and Zeek are third party components under their own licences, distributed by their own providers.
Support
cloudimg images are backed by 24/7 expert support. Contact support@cloudimg.co.uk.