SLIPS

What this sensor can and cannot see on Azure

Read this section before you deploy. It explains exactly which traffic the sensor can inspect on Azure.

SLIPS's core mechanism works as designed on Azure. It profiles the traffic it is given, and on an Azure virtual machine it is given the machine's own traffic. This was verified during the build of this image: SLIPS was run against a real malicious packet capture, and Zeek reconstructed hundreds of connection flows. SLIPS ingested those flows into its analysis database and profiled them into per-host behaviour.

Azure constrains the visibility scope, not the mechanism. An Azure virtual network interface receives only the frames addressed to it. The software-defined network does not flood, and there is no promiscuous mode that would let one virtual machine see a neighbour's traffic. Azure Virtual Network TAP, which would have been the packet mirror source, never reached general availability. Three topologies are therefore available, and this guide documents all three:

• 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. Enable IP forwarding and add a user-defined route that points a subnet's next hop at this machine. SLIPS then inspects everything routed through it. This is the only 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.

This appliance cannot 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 shipped configuration disables the two most memory-intensive modules: the TensorFlow RNN command and control model and the river flow machine learning model. The upstream slips_light variant does the same. The full behavioural and threat intelligence detection core stays enabled. You can re-enable the machine learning modules on a larger machine (see section 10).

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. The only open network port is SSH, using the key you supplied. The image contains no login, no web interface and no bootstrap credential.

The capture interface depends on your machine, so the shipped configuration is a template. The service deliberately refuses to start until first boot has rendered the template against this instance's own interface. Two independent levers enforce that, and both were 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), and only to your own address. SLIPS exposes no other network service.

2. Connect to the virtual machine

Connect over SSH as azureuser. Replace <vm-ip> with the public IP address of your virtual machine.

ssh azureuser@<vm-ip>

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. Run:

sudo systemctl is-active slips redis-server test -f /var/lib/sac/data/slips-firstboot.done && echo "first boot: complete" cat /opt/slips/VERSION grep SLIPS_IFACE /etc/slips/slips.env

The output shows 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. Check that Redis answers, that the datastore is bound to loopback only, and how many SLIPS workers are running.

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 listens only on 127.0.0.1. The process count shows that the SLIPS workers are up and analysing the interface.

An Azure NIC receives only its own traffic, so on a quiet machine SLIPS profiles this host's own flows. Route traffic through the machine (topology 2) to profile more.

5. Verify 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. The analysis takes a minute or two, and the last command restarts the sensor.

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 that SLIPS wrote a populated analysis database. On a live interface, SLIPS also 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 to /var/log/slips. Each run produces alerts.json and alerts.txt (the raised alerts), the reconstructed Zeek logs, and a SQLite flows database. List them with:

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 other machines, route their traffic through this virtual machine. Enable IP forwarding on this machine and on its Azure network interface. Then add a user-defined route in the subnet whose next hop is this machine's private IP.

First, on this VM, enable forwarding and persist it across reboots:

# 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, from your workstation, configure Azure. Replace the names in angle brackets 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 first-class Azure way to cover other machines, because nothing else lets a cloud sensor see a neighbour's traffic.

8. Scanning scope and authorisation

Inspect only traffic you are authorised to inspect. Topology 2 routes other machines' traffic through this appliance deliberately and under your control. Do not attempt to capture traffic that you do not own or have no 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. Inspect the note and the Redis settings:

sudo sed -n '1,16p' /root/slips-instance.txt grep -E '^bind|^protected-mode' /etc/redis/redis.conf

The note confirms that there are no credentials, and Redis is bound to 127.0.0.1 with protected mode on. The preflight check that guards the service runs again on every start, independently of the first-boot service.

10. Logs and troubleshooting

Check the service status and recent log output:

# 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), use a machine with at least 8 GiB of memory. Edit /opt/slips/config/slips.yaml and remove rnn_cc_detection and flow_ml_detection from the modules.disable list. Then restart the service:

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 at /opt/slips, and a written offer for the source is at /usr/share/doc/sac/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

SecureAnyCloud images are backed by 24/7 expert support. For questions about this SLIPS image or help with your deployment, contact sales@secureanycloud.com.

Deploy on Azure

Launch SLIPS on Ubuntu 24.04 LTS by SecureAnyCloud with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com